Start a Conversation

Solved!

Go to Solution

Closed

10 Posts

3333

March 16th, 2023 12:00

WMS Server Name Change

Hello - 

We have a WMS server that used to only be accessible internally, but we're testing from user's home offices.  So, before we were connecting to it with its .local DNS name, but now we've created a public DNS entry and are connecting to it that way.  We changed the address in the CCMProtocolConfig.xml file for WMS server and MQTT server.  This does work but somewhere, either in the WMS server or the thin client it's holding on to the old .local address.  

For example - periodically an event will appear for devices saying:

Generic Audit event received from "Hostname" - Failed to connect to WMS server https://internaldnsname.local:443/. Current WMS server https://externaldnsname.com:443/

This is ok and doesn't really break anything, but the problem is that when we try to push any applications out, they don't work, and we find this in the logs:

Download url https://internaldnsname.local:443/ccm-web/image/app/tc?fileName=Installer.msi , Downloading C:\Wyse\WDA\TaskMgmt\\AdvAppPolicy\\Downloads\\Installer\Installer.msi failed : Result : ERROR_SERVER_NOT_REACHABLE

We can Band-Aid this with a host file entry but would rather fix it correctly.  Does anyone know where the WMS server/TC/Both are holding on to the old hostname?  

3 Apprentice

 • 

712 Posts

March 23rd, 2023 11:00

Makes perfect sense.

glad it worked out.

10 Posts

March 23rd, 2023 11:00

Ya, everything works on this, is way faster, updated on its own, more features, and we'll actually pay slightly less per year than to run this Azure VM.  No brainer.  Thank you for all your help!  

1 Message

March 30th, 2023 10:00

It sounds like there may be some residual references to the old .local address that are causing issues with the connection to the WMS server. While updating the address in the CCMProtocolConfig.xml file should have resolved most of the issues, there may be other configuration files or settings that still reference the old address.

One possible solution is to perform a comprehensive search across all configuration files and settings for any instances of the old address and update them to the new address. This can be a time-consuming process but should help to ensure that all references to the old address have been updated.

Alternatively, it may be possible to clear any cached information or settings related to the old address. For example, clearing the DNS cache on the thin client may help to ensure that it is not still holding onto the old address.

It may also be worth checking the logs on the WMS server to see if there are any errors or warnings related to the connection attempts from the thin client. This could help to pinpoint any specific issues that are causing the connection to fail.

Overall, it may require some troubleshooting and investigation to determine the root cause of the issue and ensure that all references to the old address have been updated.

No Events found!

Top