WMS Network Requirements: Ports, DNS and Firewall Rules

For Dell Wyse Management Suite (WMS), the network requirements come down to five things: open TCP 443 and 1883 between thin clients and the server, publish DNS or DHCP records so devices can find WMS, allow WMS through any 802.1X or proxy controls, size the server for your device count, and add extra allow-list entries for optional features such as remote shadowing. This guide sets out each requirement, what it supports and where the documentation differs between versions.

This article covers Wyse Management Suite, the thin client management platform. If you searched for a warehouse management system, the network side of that topic is covered in our guide to warehouse wireless for logistics managers.

TL;DR

• WMS needs TCP 443 for HTTPS and TCP 1883 for MQTT push notifications. Dell’s deployment guide says the installer adds both to the firewall exception list.
• Secure MQTT changes the picture: Dell’s security guidance recommends keeping 443 open and disabling the 1883 message once secure MQTT is enabled.
• Devices find WMS through DNS SRV and TXT records or DHCP option tags. Secure records take priority over legacy ones.
• In an 802.1X wired network, the WMS server must be reachable from both the secure and the unsecure VLAN.
• Server capacity scales with device count: 40 GB disk and 8 GB RAM up to 10,000 devices, rising to 200 GB and 32 GB at 120,000.

Table of Contents

• What WMS network requirements cover
• Ports and protocols
• Firewall configuration between server and devices
• DNS, DHCP and certificates
• Proxy and 802.1X wired networks
• Optional features and version changes
• Server and capacity requirements
• Our perspective
• A pre-deployment checklist
• How Re-Solution can help
• FAQ
• Sources

What WMS network requirements cover

WMS has two halves. The management server (public cloud or private cloud on your own Windows Server) holds the console, the database and the messaging service. The managed devices, mainly thin clients running ThinOS, Windows 10 or 11 IoT Enterprise or Dell Hybrid Client, call back to that server.

The network therefore has to carry four kinds of traffic:

1. Administrator access to the console over HTTPS.
2. Device check-in and configuration over HTTPS.
3. Push notifications from server to device over MQTT.
4. Optional traffic: repository downloads of operating system and application images, remote shadowing, and connections to remote databases.

Each one maps to a port, and each port maps to a firewall rule.

Ports and protocols

The table below summarises the ports Dell lists for a private cloud deployment. Port numbers come from the Dell deployment guide for WMS 3.x, 4.x and 5.x.

The database and cache ports matter only when you split components across servers. On a single-server install they stay on the loopback interface and need no firewall rule between devices and server.

Where the documentation differs

Dell’s guides do not describe secure MQTT identically. The WMS 3.x security configuration guide states that new installations use HTTPS and MQTT on the secure 8443 port. The WMS 5.0 administrator guide refers to TLS 443 for secure MQTT and notes that default ports can be changed during installation. Check the guide for the exact version you run before you write firewall rules, and record the ports you chose at install time.

Firewall configuration between server and devices

A clean firewall policy for WMS is short. Dell’s deployment guide states that the WMS installer adds TCP 443 and 1883 to the firewall exception list, so admins can reach the console and the server can push notifications to thin clients. The repository installer adds TCP 443 and 8080 so devices can fetch images.

In practice, we suggest the following approach:

• Allow device networks to the WMS server on 443. This is the one rule every deployment needs.
• Allow 1883 only while legacy MQTT is in use. Dell’s security guidance recommends enabling 443 for secure communication and disabling the 1883 message once secure MQTT is on, so the rule can be removed after migration.
• Allow the secure MQTT port you actually configured (8443 or 443, depending on version and install choices).
• Keep database ports closed to the wider network unless MariaDB or MongoDB sit on separate hosts, and then restrict them to the WMS server’s address.
• Place the repository on its own server. Dell states that WMS.exe and WMS_Repo.exe must be installed on different servers.

From WMS 3.6, Dell supports the repository on Windows 2016 and 2019 virtual machines in Azure and AWS. The repository URL must then be edited to use the DNS name of that virtual machine before devices register, so that endpoints can reach it.

If your rule base has grown over several years, a firewall audit is a sensible step before adding more WMS exceptions. It shows which existing rules already cover this traffic.

DNS, DHCP and certificates

Devices need to know where WMS is and which group they belong to. There are two mechanisms.

Legacy DNS records

The Dell WMS install guide specifies DNS SRV records: _WMS_MGMT._tcp pointing to the WMS server FQDN on port 443, and _WMS_MQTT._tcp pointing to the MQTT server on port 1883. TXT records carry the group token (_WMS_GROUPTOKEN) and certificate validation (_WMS_CAVALIDATION). Set _WMS_CAVALIDATION to True when you import SSL certificates from a well-known authority, and to False otherwise.

For public cloud, the same guide points European devices to eu1-pns.wysemanagementsuite.com and US devices to us1-pns.wysemanagementsuite.com. UK organisations on the public cloud should check which region their tenant sits in before allow-listing.

Secure DNS and DHCP records

The ThinOS 10.x 2502 and 2505 administrator guide describes secure TXT records: _WMS_MGMTV2 for the encrypted WMS URL string, _WMS_GROUPTOKENV2 for the encrypted group token, and _WMS_CAVALIDATION. If both secure and legacy records exist, the secure ones win.

DHCP works the same way. According to the ThinOS 10.x 2502, 2505 and 2508 guide, secure option tags 201 (WMS server) and 202 (group token) take priority over legacy tags, and the WMS server FQDN tag (code 16500) holds the URL without the HTTPS:// prefix.

The security guide explains why this matters. Secure Discovery has the administrator generate a secure WMS URL and group token, which thin clients use to discover and register with WMS. It is designed to mitigate rogue DHCP or DNS servers, and it is supported on WDA, ThinOS 10, DCA and DCA Enabler.

Outside the local network

For devices registering from home or branch sites, the WMS name must resolve both publicly and privately, and ports 443 and 1883 must be reachable from the internet side. Where the group token is missing at registration, Dell’s ThinOS 9.x guide says the device lands in the unmanaged or quarantine group, a common cause of “registered but not configured” tickets.

Proxy and 802.1X wired networks

Proxy servers

The WMS 5.4 administrator guide documents proxy configuration through WININET on Windows Embedded Standard WDA, and through DHCP option tags for WDA and Dell Hybrid Client DCA. Older ThinOS 8.6 guidance says proxy information can be set by DHCP options or DNS SRV records. Whichever method you use, the proxy must pass HTTPS to the WMS FQDN, and MQTT needs its own consideration, since a web proxy does not always forward it.

802.1X

The challenge with 802.1X is circular: a device needs its certificates and network settings from WMS, but needs network access to reach WMS. Dell’s 802.1X best practices article resolves this with two VLANs:

1. Configure the switch with a secure and an unsecure VLAN.
2. Make the WMS server accessible from both.
3. Publish DHCP options or DNS records on both VLANs, so a ThinOS device on the unsecure VLAN can attach to WMS.
4. Let the device retrieve its 802.1X configuration and certificates, then move to the secure VLAN.

For ThinOS 9.x, the same article describes the policy path: Advanced, Network Configuration, Ethernet Settings, 802.1X Authentication Settings. Choose EAP-TLS, enter a client certificate filename that includes “scep_cert_” and “.crt”, and enable Validate Server and Check Server for server name validation.

We cover the wider rollout in our phased plan for 802.1X deployment in UK networks, and the access control layer in our network access controller guide.

Optional features and version changes

Remote shadowing has its own requirements. The Dell community post on the WMS 5.5 release, published on 23 February 2026, says public cloud admins must allow-list a new signalling server for the improved peer-to-peer remote shadow: eu1-relay-direct.wysemanagementsuite.com for EU customers and us1-relay-direct.wysemanagementsuite.com for US customers. The improved feature needs client OS version 2602 or later on ThinOS 10, Windows 10 IoT Enterprise or Windows 11 IoT Enterprise.

The same release ends WMS support for ThinOS 8.x, ThinLinux, Linux, Software Thin Client, DHC 1.x, Edge Gateway and Embedded PC. If any of those remain in your estate, plan their replacement before upgrading.

On traffic, Dell’s June 2024 blog states that peer-to-peer remote shadow for ThinOS and WMS Pro needs no extra firewall or device configuration. It uses TLS to the signalling server and DTLS for the media transferred between the ThinOS device and the WMS console. If your firewall inspects or restricts UDP, test a shadow session across each site boundary.

Server and capacity requirements

For a private cloud deployment, the Dell deployment guide gives these minimums.

The guide lists Windows Server 2012 R2, 2016 or 2019 Standard as supported operating systems. Dell’s release notes for later versions may add or remove platforms, so confirm against the notes for the version you install.

Capacity planning is not only about the server. Count the bandwidth at remote sites too: a branch with 200 thin clients pulling an operating system image from a central repository can saturate a small WAN link. Siting a repository close to large groups of devices avoids that.

Our perspective

Most WMS problems we see are network design problems wearing a device management label. A thin client that registers in the quarantine group, a branch that never receives its policy, a shadow session that drops: each traces back to a port, a record or a VLAN that nobody owned.

Our approach is to treat WMS as one more service on a managed network. It needs a documented flow matrix, DNS and DHCP records under change control, and a defined path through 802.1X. With 35+ years of Cisco experience, we build those into the wider design, so the thin client estate sits inside the same segmentation, monitoring and access policy as everything else.

For multi-site organisations such as schools, manufacturers and hospitality groups, this removes the guesswork. One team owns the switching, wireless, firewall and identity layers that WMS depends on, and a change in one is checked against the others before it reaches production.

Jacob

A pre-deployment checklist

Before going live, confirm each of these:

• Firewall rules permit 443, plus 1883 or your secure MQTT port, from every device network to the WMS server.
• The WMS FQDN resolves correctly on every VLAN and from remote locations.
• DNS or DHCP records carry the right group token, and secure records are set where you want them to take priority.
• Certificate validation settings match the certificates actually installed.
• Proxy settings are defined and tested for HTTPS to WMS.
• The 802.1X dual-VLAN path works for a freshly imaged device.
• The server meets the sizing for your device count, with the repository on a separate server.
• Public cloud allow-lists include the regional signalling and relay hostnames.

If the audit trail matters to your organisation, the network infrastructure checklist helps document it for compliance.

How Re-Solution can help

WMS depends on switching, wireless, firewalls and access control all being configured consistently. Re-Solution designs and runs Cisco networks for education, manufacturing, logistics, hospitality, shared workspaces and property developers, and we can review the flows a WMS deployment needs as part of a wider network audit.

If you would rather hand over day-to-day operation, our managed services cover monitoring and ongoing support, and our Network as a Service offer is available as a subscription. To discuss your estate, start from the Re-Solution homepage.

FAQ

Which ports does WMS use?

The essential ports are TCP 443 for HTTPS and TCP 1883 for MQTT. Optional ports include 8443 and 9443 for secure MQTT and the software vault, 3306 and 27017 for remote databases, 11211 for Memcached, and 8080 for the repository. Check the guide for your WMS version, as secure MQTT port details differ between releases.

Can thin clients reach WMS from outside the corporate network?

Yes. Ports 443 and 1883 need to be open, and the WMS server name should resolve both publicly and privately. Devices also need the correct group token, or they will land in the unmanaged or quarantine group.

How do I make WMS work on an 802.1X wired network?

Configure a secure and an unsecure VLAN and make the WMS server reachable from both. Publish DHCP options or DNS records on both VLANs. The device then fetches its 802.1X settings and certificates from the unsecure VLAN before joining the secure one.

What server specification does WMS need?

For up to 10,000 devices, Dell lists 40 GB disk, 8 GB RAM (12 GB with secure MQTT) and 4 CPUs. Up to 50,000 devices needs 120 GB, 16 GB and 4 CPUs. Up to 120,000 needs 200 GB, 32 GB and 16 CPUs. The repository must run on a separate server from the main WMS installation.

Does peer-to-peer remote shadow need extra firewall rules?

On private deployments Dell’s 2024 guidance says no extra configuration is needed. For WMS 5.5 on the public cloud, admins must allow-list the new regional relay hostname, and devices need client OS version 2602 or later.

Sources

• Dell Wyse Management Suite Version 3.x, 4.x and 5.x Deployment Guide
• Wyse Management Suite Security Configuration Guide
• Dell Wyse Management Suite Version 5.0 Administrator Guide
• Dell Wyse Management Suite Install Guide
• Dell ThinOS 10.x 2502 and 2505 Administrator Guide
• Dell ThinOS 10.x 2502, 2505 and 2508 Administrator Guide
• Dell ThinOS 9.x Administrator Guide
• Dell Wyse Management Suite Version 5.4 Administrator Guide
• Best Practices For 802.1x Wired Environments in Wyse Management Suite
• WMS 5.5 released
• Latest in Cloud Client Workspace Innovation to Simplify IT

Recommended

• Explaining firewall policies: a practical guide for IT teams
• Network infrastructure checklist: optimise compliance
• Understanding firewall security: a 2026 guide
• One Artefact Per Step: Firewall Audit Checklist for IT Security