WDM -> WMS MIGRATION PATH (DHCP OPTIONS & DNS RECORDS)

Good morning,

Since you have deployed your thin clients using per vlan DHCP OT, my advice would be to transition your devices on a per vlan basis from WDM/INI to WMS/Policies. 

The devices cannot check into both WDM and WMS, and you cannot have "Some" devices on a segment get their instructions from infrastructure and some not.   

If it were me, I would test my provisioning to WMS via DHCP OT until I get comfortable with it, and make sure that I build out a group structure and policy settings that allow a device to function from factory default.  I would then start with smaller subnets, change their DHCP, removing legacy WDM and file server references, and add new WMS entries and validate that they flow into WMS properly.  Be mindful of the "No Global INI" section in the advanced section of the policy and turn that on so that the device will no longer look for an INI on the file server. I would test taking a device from factory default all the way through to being provisioned entirely in WMS. ONce all of the devices on a subnet are migrated, validate in WDM that the device no longer is checking in, and delete from WDM.

I would then repeat this for each VLAN until completed it.  Yes it is tedious but is the safest way to ensure stability for the clients. I have used this method for 10'000 plus thin client deployments.

If you add the DNS_SRV record for WMS, that is a global setting.  All of your devices that have updated firmware would pickup on that, register with WMS in the group you provide, would no longer report into WDM, but likely would still get their INI from the file server.  This is another strategy, as you could get all devices registering into WMS in a group with no policies, edit the INI files to point to WMS on a per group basis, but it is a risk as it is global.

Keep in mind that ThinOS9, does not use INI files.  ThinOS9 ONLY uses WMS, and it uses separate policies in WMS that 8.x so you will need to have 2 policies for each group.  

Time for some lab testing. 

Good luck.

#Iwork4Dell

I tried to edit and correct my post above but the website is not allowing me to do so.

The correct version is below:

The behavior of ThinOS 8.x clients if both WDM and WMS DHCP scope options are present:

- after factory reset, if Enrollment Validation is NOT enabled in WMS the client checks in to WMS and applies WMS policy

- after factory reset, if Enrollment Validation is enabled in WMS but the client has NOT been yet validated, the client obtains WMS scope options (green) from DHCP and check-in to WMS but without applying WMS policy; the clients also checks in to WDM and apply wnos.ini settings, then restarts and apply WMS policy settings as soon as its enrolment in WMS  is validated

- if there are only WDM (yellow) DHCP scope options present and a client has already checked-in to WDM and applied wnos.ini config, then if subsequently WMS DHCP scope options (green) are added to DHCP, the client after a reboot will notice the new WMS options and will check in to WMS and will pick up WMS policy settings. If it has not been validated in WMS it will only check-in without applying WMS policy. After it’s been validated it will also immediately apply WMS settings. If you want to avoid clients to see/pick-up DHCP scope options for WMS after they have been added use “CCMEnable=no” wnos.ini entry.

Thanks for your help @buffalobound, I appreciate it.

After documenting WDM -> WMS migration process for myself, I thought I would also share it here in case someone finds it helpful. 

If anything is not correct or I have missed something please let me know.

DHCP scope options used by Wyse Device Manager (yellow) and Wyse Management Suite (green):

Please note “https://” prefix in “Wyse Management Suite server URL”. WMS documentation says it should be “eu1.wysemanagementsuite.com:443” instead but I found that this causes “unable to register” errors in client Event Log after firmware upgrade (at least in the ThinOS version I was using in Sep 2020).

The behavior of ThinOS 8.x clients if both WDM and WMS DHCP scope options are present:

- after a client checks in to WDM, it does not check-in to WMS after a reboot even if its enrollment is validated in WMS

- after factory reset, if Enrollment Validation is NOT enabled in WMS the client checks in to WMS

- after factory reset, if Enrollment Validation is enabled in WMS but the client is NOT yet validated, the client obtains WMS settings from DHCP without applying them, then restarts and checks in to WDM

- if there are only WDM (yellow) DHCP scope options present and a client has already checked-in to WDM and applied wnos.ini config, then if subsequently WMS DHCP scope options (green) are added to DHCP, the client after the reboot will notice the new WMS options and will check in to WMS and pick up WMS policy (NOTE: if it has not been validated in WMS it will only check-in without applying WMS config. After it’s been validated it will immediately apply WMS settings). If you want to avoid clients to check-in to WMS (and pick up DHCP scope options for WMS after they have been added) use “CCMEnable=no” wnos.ini entry.

ThinOS 9.x clients ignore WDM (yellow) 161, 162, 186, & 192 scope options.

After “unregistering” a ThinOS client in WMS, it checks in again to WMS after a reboot.

Thank you for these notes.  I am sure these will be very helpful to the community. 

#IWork4Dell