- This topic is empty.
August 26, 2008 at 2:07 pm #1417
Hi, could anyone help with the following problem we are experiencing with our Wyse S10 terminals.
We have a thin client environment across our offices, currently around 800 Wyse s10 terminals with approximately 180 pcâ€™s that are scheduled to be converted to Wyse terminals shortly.
We are having a problem with a number of terminals in a number of offices where the Wyse simply drop the session to the Terminal Servers. This can happen a number of times each day and some users suffer from it regular, others not at all.
We have around 40 branches that are linked to our datacentre via a broadband VPN. The terminal servers are housed in our datacentre on IBM HS20 and HS21 blades and use RDP not ICA we are showing a reliable connection across branches.
Some PCs drop the occasional session as is inevitable but Wyse terminals seem to do it on a regular basis in some locations.
Swapping cables or location in the hub etc has no effect although on a few occasions we have used a local hub to plug a few terminals in temporarily, this has proved particularly bad.
We suspect that the clipboard may be having some affect on this but do not have any evidence of this.
The Wyse are in a DHCP environment configured to download firmware and settings via FTP. The latest firmware we have on the network is 4.4.079 but most terminals are on FW 5.3.09 â€“ 6.1.x
They download a file called wnos.ini which contains the following parameters
TimeZone=’Greenwich Mean Time’ ManualOverride=1
and load a profile under the users name like the one below.
description=”Xxxxx Network (Centrally Managed)”
Any help would be greatly appreciated.August 26, 2008 at 5:01 pm #13743
this sounds really strange and errors like this are normaly extremly hard to find.
Do you have any messages in the local WTOS or Windows server event log?
CGAugust 27, 2008 at 8:22 am #13756
@ Darren_r, thats a nice enviroment with Wyse devices 😛 (we have like 300-325 not even close to you)
Regarding your problem, we have something like that currently going on at our enviroment.
We use S10/1125/1150 and V10L (for dual screen solutions) with up to date firmware (6.2.08 for S10/V10L, 18.104.22.168 for 1150, 22.214.171.124 for 1125) and it happends just randomly that some lose there connection and if you look at the Citrix Access Management Console it says like ~30 disconnected session just in 2 seconds.
We made post about it on Citrix board, see if it is Citrix related.
I’m not sure if the problem i have at the moment are the same as yours, but i still thought to post it just for the info.
When the users are disconnected and you will take a look in the eventlog you will see something like this :
Session disconnected from winstation:
User Name: username
Logon ID: (0x0,0x1C31FC35)
Session Name: ICA-tcp#447
Client Name: DNA619
Client Address: xxx.xxx.xxx.xxxAugust 27, 2008 at 8:26 am #13757
Thanks CG for your reply.
We have not been able to find a solution yet despite numerous testing and googling the problem – no results on google generally mean others are not suffering.
We are not seeing any results in the event log – when it happens the wyse either locks up and hence you dont see the event log or it simply closes the session and goes direct to switch off time out.
We have also put the latest firmware from Wyse on now but this has not resolved.
Finally just to clarify some of our offices are connected via fibre and they have the problem as well so this is unlikely to be an issue with the ADSL that we use in most offices.
DarrenAugust 27, 2008 at 8:45 am #13758
We are currently testing a Wyse S10 with 126.96.36.199 connected a PS 4.5 up to date etc. etc. with running the follow command :
We are testing to see if the Wyse S10 will be disconnected at the same time when users will get disconnected, while keep generating user activity. Our policy is 15 min. idle = lock screen and monitor goes to standby mode, this will put the Wyse S10 also in idle mode and it will generate less data (using this command you prevent going to standby/lockscreen mode).
for now it’s working 14 hours and still running.August 28, 2008 at 2:30 pm #13772
Thanks for your comments, I’ve discovered that this does not happen on one of our older servers running 2k3 sp1 rather than sp2.
Currently investigating weather this is down to the hardware or the software and have read some interesting articles on broadcom NIC’s and Windows 2003.
We are currently investigating and I will post results as found. If anyone else has experienced this, I’d be keen to hear from them.
DarrenSeptember 25, 2008 at 2:49 am #13985
Did anyone find a fix for this problem. Have 4 S10 units and 4 1200LE units, the 4 s10’s are locking up yet the 1200LE’s are working fine. Tried updating the firmware to 6.2.0_08. Latest provided by Wyse. Same issues. No log showing any info of disconnections.
Any help would be appreciatedSeptember 25, 2008 at 7:10 am #13988
We couldn’t solve the problem and we also couldn’t found the source so we did put all the Wyse device in a VLAN and all disconnection problems where gone.
I know it doesn’t help much but this is how we solved our disconnection problem.September 25, 2008 at 7:23 am #13989
Thanks for the reply!
I will discuss it with the guys and see what we can do.
Once again. ThanksSeptember 25, 2008 at 7:36 pm #13990
Is anybody of you using Session reliability?
Try to disable it and test again (except aLIE who found solution 😉 )
CGSeptember 25, 2008 at 11:43 pm #13999
Do you guys also get the “Trap Protection Fault eip=” when the session disconnects?
I have looked high and low, and cannot find any explanation. Have spoken to Wyse, who also don’t know what is happening. One of the S10’s was swapped, but it has the same issue.September 28, 2008 at 9:27 pm #14012thinkthinMember
- Total Post: 1686
- Jacked into The Matrix
This is a really interesting thread, it would be nice to have it resolved. Bugantz, Trap Protection Fault are the Blue Screen of Death equivalent on WTOS. You should defiantly log this with Wyse to get fixed.
One of the posters mentioned they suspected the SP level of the server could be an issue. What windows version, SP level and Citrix PS version and updates are you using? Is there a common server backed here?
-TTSeptember 28, 2008 at 11:21 pm #14014
Thanks for the reply. Server is Win2k3 with SP1. Not using Citrix, just terminal services.October 2, 2008 at 7:26 am #14048
To all seeing this issue:
I highly recommend getting a trace from this issue by enabling trace on the S10.
The trace option is integrated in the OS itself.
You have to do the following:
-enable tracing by using this wnos.ini parameter
– create a folder /ftproot/wnos/trace with read/write rights
– start WTOS and do a right click on the desktop. You will see a new menu item
– select “Capture”
– optional you can play with the Delay on Trace feature. If â€œDelay on Traceâ€ is enabled in Capture mode, then every write to trace file will be delayed. This is useful to capture crashing bug. If no delay, then the last write of the captured data will likely get lost when the system crashes. For capturing crashing bugs, if short delay can not capture the crash, then we will should try the long delay. For capturing non-crashing bugs, this should be un-checked so that no degradation of normal behavior of the captured sessions
– now start your session. If you are using a RDP session all infos are stored in ftproot/wnos/trace/trace.rdp otherwise it is obviously called trace.ica.
– in playback mode this trace is used and you can lean back and see a playback of your work
As soon as you have this trace file you should contact Wyse and send these traces in.
CGNovember 7, 2008 at 7:22 pm #14334bcgjayMember
- Total Post: 11
- Regular Joe
Has anyone successfully found a solution for this yet? We’ve been having the same issue here across multiple sites using V10L’s with firmware 6.2.0_08. I’ve just escalated a Wyse support ticket on the issue.
I also just turned off session reliability hoping the problems would go away with it. We have two clients on firmware 6.1.0_08 that are not experiencing any problems – and that particular firmware does not support session reliability; which leads me to believe it may be related.
We also see other sporatic error messages along with our session drops: “Bad File Number”, “Invalid vdtw2 command” “No such device or address” and “Trap protection fault eip=0x16671d.”
After a disconnect/error message, a reboot usually gets the user logged back on ok. We’re using Citrix PS 4.5 and a published desktop.
- You must be logged in to reply to this topic.