- This topic has 3 replies, 2 voices, and was last updated 5 years ago by
.
-
Posts
-
I’m currently working to migrate 75 Windows 7 Embedded devices from a WDM 5.7.2 server to WMS 1.4. Unfortunately, the WDM server is not consistently working to upgrade the agents to 14.2 and above which is currently what is required to manage the devices with WMS. DCHP options 186 WDM Server IP, 190 WDM Secure Port, and WDM Server Port are configured and the clients check in to the WDM 5.7.2 server.
I am currently upgrading the agents on each of the devices one by one. Since the DHCP options are configured when the agent first checks in it finds the WDM server. I have to unregister the device and register it manually entering the WMS server information.
Once I upgrade all of the devices I’m planning on disabling the DCHP options and using DNS discovery to point to the new server. I am approaching this the right way?
I have not disabled the DCHP options because I want the devices to check in with the WDM server to keep track of what devices I need to upgrade the agents on. Once I manually upgrade the agent and point it to the WMS server I do a force delete from the WDM server to remove it from the console.
Can anyone advise if I’m approaching this the right way?
Sounds like a good plan. If all your clients are already registered to WDM, you can go ahead and setup the WMS SRV record, and sunset the DHCP options. This way when you upgrade WDA, unregister the client from WDM, and finally reboot, client will automatically register to WMS .
Alternatively, if you are still registering net new client to WDM, then you can have the DHCP option in place alongside the WMS SRV records. The DHCP option will be recognized first by the client, and once you are ready you can register the client to WMS. Once fully migrated then you can sunset the DHCP option tags. Or stick to you current plan.
Another option, thought slightly more complicated and more work. I would recommend using the first approach and then applying a custom image(Factory image with latest WDA) via WMS. You will lose stetting like computer name, but will have a fresh new install with client checking into WMS, applying only setting you desire, and dumping any orphaned or adopted settings.
El producto,
Thank you for your response. Yes, all the clients are already registered with WDM so I guess like you suggested I can sunset the DHCP options and setup WSM SRV record.
I was under the impression that if I removed the DHCP options the registered devices will no longer have the server they will need to check with, but I looks like once they registered with the server the agent retains that information. I was concerned that removing the DHCP options will prevent the existing devices from checking in.
Also I’m working on creating a new image with the latest WDA for devices that need to be redeployed.
Sounds like I should remove the DHCP options and implement WMS SRV record.
I am pretty sure the agent retains WDM settings, but I would recommend you setup a test environment. Being that you are only using DHCP options, SRV & TXT record testing should be relatively easy to setup during your transition. You just need to test on a subnet that has options, and then on a subnet that does not have DHCP option tags defined. For the subnet with DHCP options, setup the new DNS records, then restart a client to make sure it continues to report into WDM.
BTW, the manual contains what I have identified to WYSE support as wrong FQDNs fro WMS TXT records. WYSE support has not gotten around to updating the manual since WMS 1.3 manual. I have called out the TXT records identified below. You do not need to define the _WMS_GROUPTOKEN TXT record if you do not have ThinOS clients.
WMS Manual Recommended TXT Record
_WMS_GROUPTOKEN._tcp.<Domainname>
_WMS_CAVALIDATION._tcp.<Domainname>What Works for Me
_WMS_GROUPTOKEN.<Domainname>
_WMS_CAVALIDATION.<Domainname>
- You must be logged in to reply to this topic.