eziemendorf
asked on
Connection attempts on Xendesktop 7 fail intermittently using Wyse client and Storefront
We are having an intermittent connection issue and have gone through several troubleshooting steps with our vendor, Citrix and Wyse support. We are running out of ideas and are hoping it's not a firmware issue on the Wyse client. I thought I'd put it out to the experts and see if any of you can help. Here's what's going on:
We have a new Citrix Xendesktop 7 deployment for nonpersistant VDI desktops (workstation OS) and a few applications (server OS). We are using the newest Citrix Storefront to server up the web interface connections. We have 2 Storefront servers and 2 Delivery Controllers that are load balanced using round robin dns entries. We also use Profile Unity to manage several profile, registry and GPO options. Citrix servers are built on Windows Server 2012 r2 and the clients are Windows 7 x64.
All connections originating from a browser on a fat client work 100% of the time. Chrome, IE, and Firefox on Windows 7, 8 and 8.1 work every time. Fast and reliable.
The problem is when we connect using one of 250 Wyse Xenith c00x zero clients. Intermittently, when connecting on the latest firmware (and the previous one) after entering login credentials the connection never happens and the terminal reboots (which is it set to do at logoff). I'd say about 80% of the time we have no issue, but that's obviously unacceptable for a production environment. There are no errors in the Citrix Servers event logs, none in the Wyse terminal and no errors on the screen for the user. after a failed attempt future attempts will continue to fail. this will last anywhere from 1 minute up to 20 minutes of repeated failed login attempts and then suddenly it will work. If the user has a failed login and then goes to a fat client and logs in it will be successful and they can then log out and return to the Wyse client and log in successfully. Weird I know.
When a failed connection happens there is no record in the Delivery Controller (checked using Get-BrokerConnectionLog -Sortby establishmenttime). Also, there is no record in the Director Studio of a hung session or connection attempt.
We have tried firmware versions 2.0_105 and 2.0_210 which are the only 2 that support Citrix Xendesktop 7 and Storefront. The issue is present in both firmware versions. We are not running Storefront in Legacy mode, but we have tried that too, to no avail. We have checked, double checked, triple and quadruple checked the .ini file for the Wyse terminals and the settings have been confirmed as correct by Wyse. We also tried several settings and combinations that seemed to make sense but they all made no difference.
We have removed one of the Storefront servers and Delivery Controllers to eliminate the possibility of a load balancing issue, even though EVERY connection though the web interface yields a positive result.
We have tried several other things that escape me currently but I will be glad to give more specifics to any questions you may have.
We have a new Citrix Xendesktop 7 deployment for nonpersistant VDI desktops (workstation OS) and a few applications (server OS). We are using the newest Citrix Storefront to server up the web interface connections. We have 2 Storefront servers and 2 Delivery Controllers that are load balanced using round robin dns entries. We also use Profile Unity to manage several profile, registry and GPO options. Citrix servers are built on Windows Server 2012 r2 and the clients are Windows 7 x64.
All connections originating from a browser on a fat client work 100% of the time. Chrome, IE, and Firefox on Windows 7, 8 and 8.1 work every time. Fast and reliable.
The problem is when we connect using one of 250 Wyse Xenith c00x zero clients. Intermittently, when connecting on the latest firmware (and the previous one) after entering login credentials the connection never happens and the terminal reboots (which is it set to do at logoff). I'd say about 80% of the time we have no issue, but that's obviously unacceptable for a production environment. There are no errors in the Citrix Servers event logs, none in the Wyse terminal and no errors on the screen for the user. after a failed attempt future attempts will continue to fail. this will last anywhere from 1 minute up to 20 minutes of repeated failed login attempts and then suddenly it will work. If the user has a failed login and then goes to a fat client and logs in it will be successful and they can then log out and return to the Wyse client and log in successfully. Weird I know.
When a failed connection happens there is no record in the Delivery Controller (checked using Get-BrokerConnectionLog -Sortby establishmenttime). Also, there is no record in the Director Studio of a hung session or connection attempt.
We have tried firmware versions 2.0_105 and 2.0_210 which are the only 2 that support Citrix Xendesktop 7 and Storefront. The issue is present in both firmware versions. We are not running Storefront in Legacy mode, but we have tried that too, to no avail. We have checked, double checked, triple and quadruple checked the .ini file for the Wyse terminals and the settings have been confirmed as correct by Wyse. We also tried several settings and combinations that seemed to make sense but they all made no difference.
We have removed one of the Storefront servers and Delivery Controllers to eliminate the possibility of a load balancing issue, even though EVERY connection though the web interface yields a positive result.
We have tried several other things that escape me currently but I will be glad to give more specifics to any questions you may have.
ASKER
Update:
We purchased HP t410 and t510 terminals to test and we get the same issue.
I ended up geting a higher level Citrix Support person to show me how to gather their logs and read the traces. What I have seen so far is that the session is being closed from the VM client machine and that it is a graphics error that has caused the session to terminate. After seeing this I disabled the Citrix Display Mirror Drivers (we have 2 installed for some reason) and updated our image to test.
I no longer have the same issue, I have a different one. Instead of the session never opening, it will open but I have no video - only audio. So i'm thinking the issue it with using (or trying to use) the Citrix Mirror drivers. By default I believe it should be using the Citrix WDDM Driver.
Any ideas on the correct driver setup up for Citrix XenDesktop 7.1 running on a Windows 7 64 bit VM on VMware vSphere 5.5 would be greatly appreciated.
We purchased HP t410 and t510 terminals to test and we get the same issue.
I ended up geting a higher level Citrix Support person to show me how to gather their logs and read the traces. What I have seen so far is that the session is being closed from the VM client machine and that it is a graphics error that has caused the session to terminate. After seeing this I disabled the Citrix Display Mirror Drivers (we have 2 installed for some reason) and updated our image to test.
I no longer have the same issue, I have a different one. Instead of the session never opening, it will open but I have no video - only audio. So i'm thinking the issue it with using (or trying to use) the Citrix Mirror drivers. By default I believe it should be using the Citrix WDDM Driver.
Any ideas on the correct driver setup up for Citrix XenDesktop 7.1 running on a Windows 7 64 bit VM on VMware vSphere 5.5 would be greatly appreciated.
I think we are on to something. I now know one more thing -
5. This is related to dual monitor sessions.
i.e. - All the most highly affected users have dual monitors (and mac.ini files). When their login fails, they can go to a single monitor machine and log right in. Once in, they can return to their dual monitor machine and log in. The session leaves the single monitor machine (disconnected). The session does not move to the dual monitor machine, that machine returns to the login window. They can return to the single monitor machine and log in, and the session returns instantly just as it should, still in the same screen as when it was disconnected.
Actually, I (and WYSE support) believe there are two issues, the stuttering login issue, and the exasperated login issue with dual monitor users.
5. This is related to dual monitor sessions.
i.e. - All the most highly affected users have dual monitors (and mac.ini files). When their login fails, they can go to a single monitor machine and log right in. Once in, they can return to their dual monitor machine and log in. The session leaves the single monitor machine (disconnected). The session does not move to the dual monitor machine, that machine returns to the login window. They can return to the single monitor machine and log in, and the session returns instantly just as it should, still in the same screen as when it was disconnected.
Actually, I (and WYSE support) believe there are two issues, the stuttering login issue, and the exasperated login issue with dual monitor users.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I've requested that this question be closed as follows:
Accepted answer: 0 points for eziemendorf's comment #a39992360
for the following reason:
I solved the issue without assistance.
Accepted answer: 0 points for eziemendorf's comment #a39992360
for the following reason:
I solved the issue without assistance.
We have already done this, and we still have the issue. Citrix and Wyse are working closely with me on this, give me time to find out if I need to do the VMtools thing again, but that took two days last time.
Has anyone found a solution to this problem? I have been experiencing this problem for six months now with no help from HP or Citrix. Any further information would be greatly appreciated.
Thank you!
Thank you!
Things I know about this -
1. Web interface works first time every time, so XenDesktop 7.1 is good.
2. It is profile related, a new system created profile works every time for a week or so, then quits just like before.
3. It is not the WYSE hardware. Swapping the terminal offers no help, plus my test users log in first time every time on their WYSE terminal.
4. It is user related. The way they use their computer, always the same folks.
Can anyone add to this list? I think I'm missing a piece.
TIA