We setup the free version in Azure but had some issues with push connecitivty. It appears that the server needs to talk directly to the client on 443 (the thin client acting like a web server). The request however never gets to the client as we dont have direct connections to the endpoints.
1) could anyone confirm the above is how the product works?
2) given number 1, how does the paid for public cloud Dell product work? Surely they cant expect you to setup a NAT rule to every device. Does that work different?
The server (WMS) does not need to talk to the device directly to the client via NAT on 443. From a communications standpoint, the device needs to talk on 2 ports outgoing to WMS, 443 TCP and 1883 TCP.
WMS is supported in Azure.
If you were having issues with devices that check in (port 443), but you are unable to restart a device, send a message to a device, or push a package then the issue is likely with the message queuing communications (1883).
I have seen instances where the database in WMS is pushing out the incorrect server name (Netbios name instead of FQDN) and such would not be able to be communicated with when in Azure as the short name cannot be resolved. If that is teh case support can assist with that.
Hi! Thanks for the reply.
Note this is not over a VPN with Azure, but over the internet.
I added 1883 to the azure firewall as an allow but still getting same issue. I did a wireshark capture from the WES Thin Client and i cant see it trying to send anything out on that port, is it maybe a Linux thing to send on that port?
In fact, i could see no traffic at all in the 5m capture i setup to the IP of the azure server at all. Is that normal?
thats awesome, i have got further now and managed to push some settings. thanks so much! however I think i have this issue where it is trying to connect to the netbios name instead of the FQDN. See below for logs from the thin client.
mfg-az-wms-s01 is not going to work on its own and needs the FQDN of the azure instance. How can i get the agent to try to connect using that please?
Great news. That issue where it is trying to communicate with the NetBIOS name instead of the FQDN is something support is aware of and can assist with.
Essentially the database needs to have some update commands run against it to change the URL it is trying to handout for communication once checked in. I am not allowed to post that in a public forum 🙂
Assume you still have support on the Device you are attempting to manage I would suggest you open a ticket using the service tag of the device, for WMS.