Start a Conversation

Solved!

Go to Solution

Closed

10 Posts

3270

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

 • 

697 Posts

March 23rd, 2023 10:00

WMS Pro (paid version) can be used on-premises or public cloud.  

It is a much better solution, includes support, BIOS management, reporting, Advanced software delivery policies, etc..

Free trial here

https://wysemanagementsuite.com/trial.aspx

 

3 Apprentice

 • 

697 Posts

March 20th, 2023 07:00

If you are using WMS Pro (Paid version) you can use Portal Administration> Setup to change the URL's used to the FQDN you are advertising.

buffalobound_0-1679320311389.png

If you are using the free version, then you will need to do it manually in the database. 

Here are some old notes I have, As always use at your own risk, and ensure you backup the WMS VM prior to updating and ensure you can recover if needed.

 

Change IP or FQDN of WMS Server or Local SWREP:

  • Update MongoDB Database Entries

*See Section on Database Access

Access MongoDB:

  • GUI
    • https://robomongo.org/download
      • Install tool
    • Click ‘create’ to add a new connection to a mongo server
      • Type: Direct Connection
      • Name: WMS Mongo
      • Address: localhost
      • Port:27017

 

  • Perform Authentication: CHECK
  • Database:admin
  • Username: stratus
  • Password:
  • Auth: SCRAM-SHA1
  • Default Database: admin

WMS Core Services:

  1. Update the bootstrapProperties collection in the mongodb
    • db.bootstrapProperties.update({name:"mqtt.server.url"},{$set: {value:"tcp:// :1883"}})
    • db.bootstrapProperties.update({name:"stratusapp.server.url"},{$set: {value:"https:// :443/ccm-web"}})
    • db.bootstrapProperties.update({name:"stratus.external.mqtt.url"},{$set: {value:"tcp:// :1883"}})
    • db.bootstrapProperties.update({name:"Memcached.Servers"},{$set: {value:" :11211"}})
  2. Save Changes
  3. Reboot server
  4. Update the certificate if still using the self-signed cert generated during install with the old name, otherwise HTTPS CA Validation will fail

 

WMS Local repo:

  1. Update the stratus app URL from the bootstrapProperties collection in the mongodb.

 

{

    "_id" : ObjectId("5a165f75e880aaa3492487e2"),

    "name" : "stratusapp.server.url",

    "value" : "https:// :443/ccm-web",

    "isActive" : true,

    "committed" : true

}

  1. Save Changes
  2. Reboot server
  3. Update the certificate if still using the self-signed cert generated during install with the old name, otherwise HTTPS CA Validation will fail

 

10 Posts

March 20th, 2023 09:00

Wow it's definitely hanging on to the old hostname in more places than I imagined.  That took some quick self training but I managed to get all of those values changed and rebooted.  Problem now is that my MFA emails are no longer being sent, so I can't login.  Any idea why that would break from this or perhaps what db.name that setting is stored in to turn off MFA?  

10 Posts

March 20th, 2023 10:00

That was my thought too.  Instead, I'm trying to revert the changes and reboot and test 1 by 1 to see which if any broke MFA.  I'll report back what I find.  

3 Apprentice

 • 

697 Posts

March 20th, 2023 10:00

I have not seen that, and cant imagine why it would be impacted.  You may want to roll back to a known good backup, disable MFA, repeat DB changes to change URL, then test MFA.

 

10 Posts

March 21st, 2023 09:00

Reverting changes was not successful, so I had to roll back.  Then rolling back did not resolve the MFA issues, so I had to roll back to before we enabled MFA.  I then made all of the URL changes and attempted to upgrade through the path from 3.1 to 4.  Each upgrade along the way was met with more and different errors from MongoDB to MariaDB, etc, etc, etc.  I made it to 3.6.1 and have decided to start from scratch.  

3 Apprentice

 • 

697 Posts

March 22nd, 2023 12:00

If you choose "Send a message" to the device, does it receive it right away, or does it only get iot after a reboot?

If it does NOT get it, then there is an issue with MQTT (port 1883) communication between the device and the WMS URL.

10 Posts

March 22nd, 2023 12:00

It never gets the message, but I can test-networkconnection in powershell on the hostname and port 1883 and it succeeds.  I also see in the thin client logs it says:

MQTT connection is successful.

MQTT TCP Connection is successful.

Preferred MQTT server is reachable.

MQTT Connection status changed to Connected.

 

So it seems like MQTT is working, but basically only from looking at the logs.  No other functions seem to work in WMS.  

isGoodTroubleshooting

10 Posts

March 22nd, 2023 12:00

I dont think we have Central Config with the free version, could be mistaken though.  I can confirm that the following values in MongoDB have been changed.  I found I needed to add a couple from your notes, which were external.preferred and external.secure

db.bootstrapProperties.update({name:"mqtt.server.url"},{$set: {value:"tcp://external.address.com:1883"}})
db.bootstrapProperties.update({name:"stratusapp.server.url"},{$set: {value:"https://external.address.com:443/ccm-web"}})
db.bootstrapProperties.update({name:"stratus.external.mqtt.url"},{$set: {value:"tcp://external.address.com:1883"}})
db.bootstrapProperties.update({name:"stratus.external.preferred.mqtt.url"},{$set: {value:"tcp://external.address.com:1883"}})
db.bootstrapProperties.update({name:"stratus.external.secure.mqtt.url"},{$set: {value:"tls://external.address.com:8443"}})

The one I didnt change was memcached, since it was pointed to 127.0.0.1, so it didnt seem any clients would ever use that address?  

db.bootstrapProperties.update({name:"Memcached.Servers"},{$set: {value:"not changed:11211"}})

10 Posts

March 22nd, 2023 12:00

I have everything rebuilt and URL's are good.  The device I'm testing with seems happy, logs say it connects to MQTT and everything fine.  When I reboot it it will checkin and get new policies, but if I change it's group it just sits in pending forever, if I try to push out an immediate app policy it never gets its, sending a message doesnt work, requesting logs doesnt work.  It's like once it boots up it never communicates again, even though WMS says its online.  Any idea why that may be?  

3 Apprentice

 • 

697 Posts

March 22nd, 2023 12:00

If you check Central configuration, WMS does the WMS and MQTT URL's match what you expect them to be?

 

 

3 Apprentice

 • 

697 Posts

March 22nd, 2023 13:00

My apologies, I missed this is WES, not ThinOS.
It looks right to me.  So the Wyse Device Agent in windows, when you login as admin, looks right?

 

10 Posts

March 22nd, 2023 13:00

Yes, it just shows the WMS Stratus URL, but that is correct, and its registered fine.  Then if I go to support in the WDA and look at the log is where I see it successfully connecting to MQTT.  

Actually, as I was typing this my test TC came up with an update request, then it updated and then it displayed all my messages.  Is there any heartbeat, or keepalive or setting like that I'm not aware of?  Some reason all these pushes and messages would just sit there until the TC is ready to check back in again?  Or should they be real time assuming the TC is connected to the internet?  

Once everything went through, I sent another message to see if the issue resolved itself, unfortunately, that message is sitting in Pending status again.  

3 Apprentice

 • 

697 Posts

March 23rd, 2023 05:00

The whole point of the MQTT is real-time communications, that is the point of the "Send a message" test.  

Any chance to test inside the network, ruling out any firewall issues?   Updating the WDA on the device is another idea.    Beyond that I am pretty stumped.

10 Posts

March 23rd, 2023 09:00

Trying that shortly, we'll see!  Any chance Dell offers a hosted WMS solution we could try out as well?  I see signs that they might but I cant find anywhere to sign up/trial.  

No Events found!

Top