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.

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

}

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

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?  

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.  

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.

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.  

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.

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.  

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"}})

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?  

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

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?

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.  

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.

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.