Forum Replies Created
-
Posts
-
We are running 2,000+ Dell 5040 ThinOS 8.6_013 and have the random Core Dump (GSOD) issue. My Core Dump says “MSG Daemon” instead…not sure if it’s the same issue. It does happen on both wired and wireless devices.
I see 8.6_015 on Dell’s Support site…but their Support site is a mess. It does not show all of the downloads for ThinOS devices. Ever since they moved from Digital Locker, it’s been a mess.
I had manually added it to our WDM server, and it works fine.
Must be a WMS issue…
It would be nice if Dell would state that from the pulled downloads…instead of leaving dead links.
I had to reach out to a contact at Dell to get the version for a 5040 PCoIP.
Dell’s new method of posting the builds, leaves a little to be desired…
SIX days and counting… The Dell 5040 D10 users have been left out in the cold (again) without a new build. The exact same thing happened last release 8.4_B112. it was almost a month before we got it. I’m not sure if it was a mistake, or there is something different/special about the D10DP devices…
I’m not feeling the love.
We use a specific dbm to fine tune our roaming level. It works great…
Device=Wireless Mode=Infrastructure SSID=”MYwireless” RoamSensitive=-69dbm PreferBand=5G DisableWLAN=EnetUp DisableAC=No DisableN=No
I know this has nothing to do with the VNCviewer mod…but was wondering how difficult it would be to add a new column into the WDM webui Device List display?
I’ve been asked to produce a report for devices, including the Serial number (Dell Service Tag). In the WDM.msc console, I created a Report that shows everything, but you cannot see it from the WebUI…so I figured I could just add the column to the default Device List.
Thoughts?
“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… 😉
For anyone struggling to get this to work, here’s a tip. I learned the hard way 😉
Do NOT Cut-n-paste the data from this site. The “ & ‘ characters may get messed up. Just type it out manually. I used Notepad ++ to double-check my formatting, since it color codes any errors.
Fantastic Mod!
For the benefit of those reading this post, and looking for ThinOS wireless answers. We’ve been working a couple cases with Dell Support and have found a few issues. We were running 8.3_108 & 8.3_109 and there is a ‘input lost on PCoIP session’ bug where you randomly lose keyboard/mouse input into the PCoIP session.
Dell support (depending on the Tech you get) may offer a couple options. I’m throwing those options out there for your consideration. For my specific PCoIP issue, they suggested the 8.4_006 beta. They have added “many enhancements” to the 8.4 wireless code. One of these is (finally) the removal of the -5 dBm threshold roaming limit. So far, the PCoIP input issue is gone, and the wireless seems to roam better. Your mileage may vary…
- The 8.3_210.36 is the 8.3 build with the DEMO code for the IEEE coredump patch applied.
- The 8.4 build is the BETA for 8.4 (containing the ‘input lost on PCoIP session‘ enhancements and the DEMO code for the IEEE coredump patch applied.
Here are my notes regarding the Imprivata Virtual Channel (VC)
1) We were having slight random delays in the login process from the Wyse 5040 devices. It would randomly have a 5-10 second delay when connecting to a disconnected session. We traced it back to the Imprivata Virtual Channel which is on by default. This ImprivataVC does USB redirection, and was conflicting with the VMware USB mapping from the ThinOS device. We disabled the Imprivata Virtual Channel in the WNOS.ini… and it seems to connect much faster.
SessionConfig=ALL EnableImprivataVC=no
Imprivata Support (9/20/2016): “EnableImprivataVC={yes,no}, tells the device to use USB Redirection to pass devices into the VM instead of using the virtual channel, which is what OneSign leverages to pass the device through. If attempting use USB Redirection when this setting is toggled to “yes”, the OneSign agent can get confused if it should use the USB device locally or in the virtual machine. If that’s the case, then toggling the setting to “no” should correct the issue. ”
@JohnTwilley
We have 12 Pilot medical carts, and are preferring 5G in our config.
I’d love to know what Dell shared with you, as we are struggling with wireless in the field. Dell was the one that told us we should be using 5G, because on of our earlier ThinOS builds would not connect to 5G, (PEAP) and they gave us a Beta build to use until the December release that supported 5G better…One thing that Dell figured out for us was that an old Imprivata virtual channel was causing delays upon connection, and asked we added the following to our config. We verified with Imprivata that this was no longer needed, and it did in fact help with connection timing.
SessionConfig=ALL EnableImprivataVC=no
Side-Note: I’d like to chat about your Imprivata configuration sometimes… I see you are using Autolog, and we never got that working well. We are connecting directly to each session as the User. Just wondering if you think it’s worth revisiting.
