5070 Thin Clients not checking in with 9.1.2101?

Having exactly the same issue, i guess for me it happened after WMS rebooted (i'm on WMS 3.2) that clients never came back.

The upgrade to WMS 3.2.1 does NOT fix the problem. I still have 6 devices not checking in.

I am also having this issue with the cloud hosted WMS instance. Has anyone figured out a workaround?

Hi i have investigated the issue further, it looks like 80% of our devices already stopped checking in with having ThinOS 9.1.1131 and WMS 3.x.

I was accidentially thinking these werent in use but when i rolled out the update to 9.1.1121 i noticed only 10 devices actually pulled the upgrade after powering on all of them - it was really suspicious.

We were using WMS Group and Server assigment via WMS config.

My assumption is that after a timespan x the locally cached WMS config can no longer be decrypted.

You may ask why: i am unable to login via known working VNC password and the local administrator also gives bad user / password.

Does anyone know how we can even factory reset the devices? Im locked out of admin mode and the method via pressing G key upon boot seems to be no longer present.

Regards

No the G key is an option that is only available in version 8.x

I will say, if you think you are logged out of the BIOS, try every known password you can think of. Today, I managed to get into the BIOS of 2 previously locked out devices. The first had a BIOS password we set 2 years ago, and another (in the same group) had the default Dell password of Fireport.

I love consistency.

The ones I am managing to get back into are all being rebuilt on 8.6_710 using the Dell USB Imaging Tool

Luckily im not locked out of BIOS, but if would be neat to get the devices back without Merlin Image Flashing (which by the way works - the devices are registering again).

We are having almost 200 devices just for this group, assuming manual flash would needs to be done every month or so when the config becomes invalid and devices losing registration id rather replace these devices with a fatclient.

This ThinOS 9.x / WMS  release is in my opinion the worst and buggiest thing i've ever seen from Dell and everything is so poorly documented. What is their QM team doing?

Regards

Please make sure you are opening support tickets and providing engineering with diagnostics and logs so a root cause can be determined and resolved.

#IWork4Dell

I ended up resolving this issue by finally getting into the BIOS, enabling USB support, and re-imaging with the 8.6.710 Merlin image from USB.

All I can suggest is to try every password you have ever had for your BIOS password, including the default Dell password of Fireport and maybe eventually you will get in.

Of my 6 affected units, 2 had the default Fireport, one had a BIOS password we recently changed, and 3 had a BIOS password we had set on the units 3 years ago.

I had something similar a few weeks ago.   I found the cause though - in the policy for the group the terminals were connecting to, in the System Settings, WMS Settings section, I had inadvertently enabled WMS but not configured anything for group prefix and token.   So what was happening was terminals were connecting to the WMS server OK, but then having their token and prefix wiped out which stops them connecting in future.

Because I have DHCP options set to configure the terminals, a factory reset solved the issue in the short term, but again they would only connect once and then not be seen again.  After an hour or two I realised that in Central Configuration on the terminals, there was nothing set so I started to look into why and compared it to another group's policy and spotted the difference.

Worth a check, anyway.

The process i was given is this.  YMMV, and i am waiting on a more streamlined approach.  You will need physical access as you need to USB downgrade and the process breaks down half way and requires the device manually re-registered device side.

1: Downgrade to 8.6_710 via USB stick.
2: Assign to a group running 9.1.1131 and allow it to upgrade. (at this point you will be back where you started)
3: Manually re-register the device to a group that pushes 9.1.2101 (at this point we are still not in the clear)
4: Once at 9.1.2101 unregister the device from WMS and delete it from WMS. (Device won't do anything)
5: Re-register the device to the 9.1.2101 group.

That should (has in our testing) make a device check in and stay checked in.

If you could post that process, that would be great...for next time.

When I contacted Dell about a fix, they knew of nothing to resolve it, other than a reimage...providing you could get into the BIOS to enable USB boot that is.

That section is supposed to be blank, however it is a workaround to the issue.  I have an open ticket on this issue currently and a 6 step manual process has resolved it for one device.  Only another 500 to go..

@Sparkstack thanks for your feedback. Please keep us updated whether or not Dell can provide a solution.

Regards

Who else has an open ticket on this?  Back and forth with Dell and i seem to be repeating myself with the testing / explaining. 

I'm seeing this as well. What version of ThinOS were you upgrading from? I found that upgrading anything on a previous 9.x release to 3112 experiences this issue, but clients on 8.6.x that were upgraded to 9.1.3112 work fine.