- This topic has 9 replies, 4 voices, and was last updated 6 years, 9 months ago by
.
-
Posts
-
Odd issue today. We are currently running 8.3_109 as our standard. Wyse 5010s w/ PCoIP. Our terminals autologin via credentials provided via a mac.ini, and connect to a Horizon pool of floating VMs.
Our guys went to upgrade a pilot group, and the 7 terminals they touched, all upgraded their firmware fine (even showed in WDM as 8.4_108), but, after autologging to the terminal, just sat at their desktop with the Horizon pool there to be clicked. When clicked, they went nowhere. Along with that, when I went to VNC to them, I got a “connection closed by remote server” immediately.
We placed the 8.3 firmware back out in wnos, and sure enough the 7 rolled back fine 100%. I don’t get it. We tested on devices here and the issue didn’t happen. We even brought a terminal back from the problem area and again, the testing went fine. Has anyone ever seen anything remotely close to this?
Thanks in advance.
To give a bit more detail:
- We’re not deploying the horizon.pkg at this time.
- We’ve never deployed any add on packages in this environment.
- Below is my wnos.ini
Speaking with a Dell counterpart, he mentioned that they have seen buggy issues upgrading from 8.1, 8.2, 8.3 to 8.4, but not 8.0 Which seems odd to me. I’m wondering if we have to step up first to say 8.4_009, then go to 8.4_108?
;*************************************************************
;* *
;* This wnos.ini file was generated with the *
;* Configuration File Generator 6.3.06 *
;* Copyright by Thomas Moellerbernd *
;* *
;* https://technicalhelp.de *
;* *
;*************************************************************;*************************************************************
;* General 1 *
;*************************************************************autoload=1
AdminMode=yes Admin-Username=MEAFMNABMK Admin-Password=PASSWORD
Privilege=None Lockdown=yes
MirrorFileServer=yes;*************************************************************
;* General 2 *
;*************************************************************FormURL=V10.jpg
;*************************************************************
;* General 3 *
;*************************************************************Autopower=yes
AutoSignoff=yes Reboot=yes
Shutdowncounter=10
SysMode=Classic toolbardelay=0 ToolbarStay=1
AddCertificate=wc-may2016.crt
AddCertificate=ca.cer;*************************************************************
;* Display *
;*************************************************************DeskColor=”0 51 102″
Desktop=BG_SW.jpg
Screensaver=10 LockTerminal=no Type=3 PictureTimer=10 PictureCheck=always
Dualhead=yes MonitorAutoDetect=yes;*************************************************************
;* Peripherals *
;*************************************************************Device=audio Volume=25
;*************************************************************
;* Time *
;*************************************************************TimeZone=’GMT – 05:00′ ManualOverride=yes Daylight=yes Start=030207 End=110107 TimeZoneName=”Eastern Standard Time” DayLightName=”Eastern Daylight Time”
;*************************************************************
;* Redirection *
;*************************************************************Device=vusb ForceRedirect=0x0911,0x0c1c,0x01,0x01,0x00
;*************************************************************
;* Network *
;*************************************************************Device=Ethernet KeepAlive=600
VDIBroker=BROKER
SignOn=Yes
DomainList=”1, 2″
PasswordServer=DOMAIN
MaxVNCD=1
VncPassword=”PASS” Encrypt=yes
ConnectionBroker=VMware Securitymode=None
OneSignServer=https://imprivata KioskMode=yes TapToLock=0 AutoAccess=VMW EnableFUS=yes SecurityMode=Full
SessionConfig=PCoIP USBRedirection=TCX;*************************************************************
;* Wireless / 802.1x *
;*************************************************************IEEE8021X=yes network=wireless access=WPA2-ENT eap=yes eaptype=EAP-PEAP peapeap=EAP-MSCHAPV2 peapmschapun=account peapmschappwdEnc=PASS peapmschapdm=Domain
Device=Wireless Mode=Infrastructure SSID=SSID RoamSensitive=Medium DisableBand=2.4G DisableWLAN=EnetUp;*************************************************************
;* General Session *
;*************************************************************SessionConfig=ALL MapDisks=yes DisableSound=No
;*************************************************************
;* RDP *
;*************************************************************SessionConfig=RDP DefaultColor=2
Include=$mac.ini“We even brought a terminal back from the problem area and again, the testing went fine…”
This is the part that I find odd. It makes you think that it is a network issue, since that is the variable changing when you move the device and it behaves differently. Not real sure where to start troubleshooting here…but there were MANY changes to the wireless between 8.3_109 – 8.4_108.
- I’d start by upgrading a device, and then performing a “Reset the system setting to factory defaults” to clear out any leftover settings from 8.3_109. Especially since you use the MirrorFileServer=yes setting.
- SessionConfig=PCoIP USBRedirection=TCX ? Are you using the old style TCX? We use SessionConfig=PCoIP USBRedirection=PCoIP
- Imprivata Client issues – What version of Imprivata are you using on the backend? Maybe there is an issue with the Imprivata USB Channel? That was modified in the 8.4_108 version. (CIR92764 – Resolved an Imprivata virtual channel issue that could result in slow desktop reconnects.) You could try disabling it to see if it makes a difference. SessionConfig=ALL EnableImprivataVC=no
- Disable VNC to see if it’s having an issue. Service=VNCD disable=yes
And finally…there is a new Beta 8.4_109 that you COULD try if all else fails… 😉
All of the devices they tested were wired devices on 8.3_109. We planned on also upgrading wireless terminals that were on 8.4_007 (beta) but held off after the issues.
We actually use TCX to utilize the Philips SpeechMike. We had an issue where after X amount of unplugs (Doctors roam with their mics) the VMs would stop recognizing new mics, unless a logoff of the VM occurred and they got a brand new session. Utilizing TCX fixed it, we can unplug infinitely and the mic is always present.
Our backend Imprivata is 5.4 It actually was just upgraded from 5.2. Our VMs though are still utilizing the 5.2 Hotfix 6 agent.
I was told by the higher up Dell Wyse engineer after 8.0 upgrade, the upgrade process should be able to go from one firmware to the next or skip firmware and work w/o any issues
Thomas,
Would you mind commenting on this, particularly if it has a link to your post in General about WTOS updating procedures? I’m wondering if my issues with the upgrade are possibly related to that SecurityPolicy= setting.
Thanks.
Found out some more info after trying to go to 8.4_110.
We went out to the same area from a few weeks ago where we had attempted to upgrade a few terminals from 8.3_109 to 8.4_108. They did indeed upgrade, but would not connect to their Horizon pools. In the system information window they would just sit at “PCoIP: Connecting to POOL NAME….” and that’s it. So at the time, we reverted back to 8.3_109 and everything worked again.
Fast forward to today. The plan this time was upgrade to 8.4_110, the latest available. The first few terminals we hit, all upgraded fine and logged in perfectly. Everything looking good.
But then we hit a few that did the same thing as before. Upgrade goes well, autologin stops. What we noticed/discovered:
–the terminals that updated fine this time, we believe are the terminals from last month that updated/had the issue/rolled back. It’s almost like an upgrade, a revert, and an upgrade again fixes the issue.
–terminals that we cannot repeat the issue on are our wireless terminals, who are running beta code, 8.4_007.07. Those, in our limited testing, never experience the issue.
I have opened a ticket with Dell. My guess is we have to hop to another 8.4 version, then perhaps to even another, to then go to 110. Kind of sucks, so, hoping they have a better answer. The wireless units at least seem like they can go right to 110.
Got my reply from Dell. Looks like we have a path forward. Not as direct as I would have hoped, but, it’s a plan.
When updating the Thin Clients it is recommended to step them up to the latest revision.
In this scenario it looks as though the 8.3_109 clients will need to go to 8.4_009 first and then up to the latest but I would test that on a client first. If this does not work as desired it would need to be updated through the entire path of updates as follows;
8.3_B109 to 8.4_B009
8.4_B009 to 8.4_B108
8.4_B108 to 8.4_B110
It is recommended to update clients in this matter to prevent issues such as you are experiencing. Please test and let us know if this proves to be successful.
Let me know if this really fixes your issue.
It would be the first time 😉
Those steps are not needed normally as written in my General post.CG
- You must be logged in to reply to this topic.