Forum Replies Created
-
Posts
-
I had a similar problem. Deleted all the packages on the unit (manually from the admin interface on the unit) and then applied the update through the WMS and then it worked.
In order to disable the float bar in session:
- In User Experience Settings use the modern mode
- Set “Show Floatbar when mouse” to Delay
- Set “Delay Floatbar Activation in Milliseconds to “0”. The tool tip on the “info” icon tells you this.
The under “Account Privileges” you can enable Admin mode, if you want.
You can also set “Privilege Level” to “Custom” and disable everything.
Good luck!
I’m having this issue as well since 9.4 with my 3040:s and we have BIOS 1.2.5 on all machines.
I have just upgraded two clients to ThinOS 2303 and now I have this issue with the dual monitor clients as well.
I keep my units in the same group. They will ignore the update if it is the same version as the unit already has. This also mean that if I move other units into this group later they will also be upgraded.
There are many ways to skin a cat. If you want to keep your groups clean you could do it like this:
Main group (all common settings for all countries applies to all units)
— subgroup for firmware upgrades (if applied to all units at once)
— — sub sub group for Germany (localized settings for language, keyboard and more)
— — sub sub group for France (localized settings for language, keyboard and more)In this scenario you could first set the firmware upgrade group to upgrade all units to 9.1.3 and wait until all units are in compliance with the upgrade. In the next step you change settings and upgrade all units to 9.3.1 and they will follow.
The other way is as you described to have subgroups for upgrades in each country setting.
Main group (all common settings for all countries applies to all units)
— sub group for Germany (localized settings for language, keyboard and more)
— — sub sub group for firmware upgrade to 9.1.3
— — sub sub group for firmware upgrade to 9.3.1
— sub group for France (localized settings for language, keyboard and more)
— — sub sub group for firmware upgrade to 9.1.3
— — sub sub group for firmware upgrade to 9.3.1Since the issue for me only affected single monitor units I tried to switch the display to display port 2 and that seemed to solve the issue for now. Units with the single monitor in display port 2 does not have the resolution reset issue as of now. It might bee a bit too early to tell for sure, since I have only tried this for 2 days now, but it looks promising.
We’re 2 months in on a support case to get our finger print readers working with Imprivata on OS 9 with an Optiplex 3000. We’re at the point where we’re looking at other hardware vendors now.
I totally understand your frustration. ThinOS support for our smartcard identification fortunately works okey for us. From what I know other vendors of thin clients don’t have this support so we are stuck with ThinOS 9 for now. Dell should really get a grip on this. ThinOS 8.6 was great and worked fine for most of the time.
The lock feature of ThinOS just locks the thin client. The session in the background remains connected to the client. You could always diable the lock feature, set the clients to disconnect from the session and log out from ThinOS if idle for too long. That would force the user to reauthenticate to the broker/AD if you are concerned about security.
Sorry to hear that you had to revert your workstations back to 8.6. That is a pain to do, since it is all manual labour. Also strange that for me only my single monitor devices are be affected. We are living with the issue now since I will not downgrade 50 + clients manually to 8.6.
On my part I only have this issue on my 3040 clients with only single screens. My 3040 clients with dual screens does not appear to have this issue in our environment. @Justin_PedEnt is it the main screen or the secondary screen that has this issue for you? Have you managed to solve it?
Basically you create two groups in WMS and first move all clients to the first group to make the upgrade to 9.1.3129. This you do the last thing before you go home for the day (or from home if you are so inclined). The next day you move all the clients to the second group with the upgrade to 9.3.1129 before you go home. This will cause the leaste amount of disruptions. Even if the client promts for a reboot there is the option for the user to postpone this until the next time the client restarts.
I down-graded to ThinOS 9.1.6108 and now this is working as expected again.
Ah, that explains why I am having trouble with this after upgrading to ThinOS 2205. I am really dissappointed with how many bugs ThinOS 9 stil presents after over a year since version 9.1.
