Bulletproof WMS Auto-Discovery: Ditching CNAME for DNS SRV and DHCP Option Tags
If you’ve been deploying Dell thin clients, you know that Wyse Management Suite (WMS) is the undisputed central nervous system of your EUC environment. But before we get to policy inheritances and firmware updates, we have to talk about step one: getting the clients to actually talk to the server right out of the box.
Before diving into the auto-discovery configuration, let’s quickly recap your WMS architecture options to ensure you are routing clients to the right place:
- WMS Standard: This is your on-premises only solution. Keep in mind that Standard requires registration now, but it is completely free.
- WMS Pro: The enterprise tier, which is offered both as cloud and on-prem.
Regardless of which tier you're running, you need a solid auto-discovery foundation. A lot of old documentation and community posts still talk about using CNAME records for auto-discovery. Let’s clear this up right now: CNAME is not the right way to do this. A CNAME just points a name to a name. It doesn’t tell the client which port to use, nor does it provide a mechanism to deliver vital Group Tokens or CA Validation flags.
If you want a robust, production-ready discovery process, you need to rely on DHCP option tags and DNS SRV records. Here is exactly how to set them up so your thin clients connect seamlessly.
Method 1: DHCP Option Tags (The Legacy Standard)
DHCP is often the most reliable way to hand out configuration data because it hits the client the exact second it gets an IP address on the network. For WMS, we need to create specific string-based predefined option tags on your DHCP server (usually Windows Server).
| Option Code | Name | Data Type | Example Value |
|---|---|---|---|
| 165 | WMS_Server | String | https://wms.yourdomain.com:443 |
| 166 | MQTT_Server | String | wms.yourdomain.com:1883 |
| 167 | CA Validation | String | FALSE (or TRUE if using a trusted cert) |
| 199 | Group Token | String | defa-quarantine |
Pro Tip: In Windows DHCP Server, you cannot just add these to a scope immediately. You need to right-click IPv4, select Set Predefined Options, and manually add these custom classes in first. Once they exist at the server level, you can assign them to your specific VLAN scopes.
Method 2: DNS SRV & TXT Records (The Flexible Alternative)
If you don’t have control over DHCP or your networking team prefers to manage discovery at the domain level, DNS records are the proper alternative. An SRV record provides much more than a simple alias—it specifies the host, port, and protocol, which is exactly what the WMS agent needs to handshake properly.
In your DNS manager, you need to create two SRV records (for management and MQTT traffic) and two TXT records (for the group token and CA validation):
1. WMS Management Server (SRV Record)
- Service:
_WMS_MGMT - Protocol:
_tcp - Port Number:
443 - Host offering this service:
wms.yourdomain.com
2. WMS MQTT Server (SRV Record)
- Service:
_WMS_MQTT - Protocol:
_tcp - Port Number:
1883(Note: Use8443if you are connecting to WMS Cloud) - Host offering this service:
wms.yourdomain.com
3. WMS Group Token (TXT Record)
- Record Name:
_WMS_GROUPTOKEN - Text Value:
defa-quarantine
4. WMS CA Validation (TXT Record)
- Record Name:
_WMS_CAVALIDATION - Text Value:
TRUEorFALSE
Method 3: Secure Auto-Discovery (Newer WMS Feature)
In newer versions of Wyse Management Suite, Dell introduced Secure Auto-Discovery to prevent exposing your WMS server URL and group tokens in plaintext across your network. Instead of broadcasting the standard names, you generate an encrypted string for the endpoints to use.
To set this up, log into your WMS console and navigate to Portal Administration > Console Settings > WMS Discovery. Enter your plaintext group token, choose your discovery type (DHCP or DNS), and click Generate Details to create your encrypted strings.
Using Secure DHCP Option Tags
If you selected DHCP as your discovery type, WMS will give you encrypted strings to place in two new Option Tags instead of the legacy ones:
- Option 201 (Secure WMS Server): Enter the generated encrypted URL string.
- Option 202 (Secure Group Token): Enter the generated encrypted token string.
Note: You still use Option 166 (MQTT) and 167 (CA Validation) alongside these new secure tags.
Using Secure DNS TXT Records
If you selected DNS as your discovery type, you will replace your legacy _WMS_MGMT (SRV) and _WMS_GROUPTOKEN (TXT) records with two new secure TXT records:
- _WMS_MGMTV2 (TXT Record): Contains the encrypted WMS URL string.
- _WMS_GROUPTOKENV2 (TXT Record): Contains the encrypted group token string.
Note: If you have both the legacy and secure DNS records configured on your network, the secure V2 records will take priority automatically.
Troubleshooting & Verification
Before rolling out 500 thin clients, you should prove your network configuration is actually broadcasting the correct information. The easiest way to verify your DNS setup is from a standard Windows command prompt using the nslookup tool.
Verifying DNS Records with Nslookup
To confirm your SRV and TXT records are reachable from the client VLAN, run the following commands on a machine within that network:
C:\> nslookup -type=txt _WMS_GROUPTOKEN.yourdomain.com
If the records are configured correctly, the output will list your WMS server hostnames, assigned ports, and plaintext (or secure V2) group tokens. If it times out or returns a non-existent domain error, you likely have a DNS replication issue or a firewall blocking UDP/TCP port 53.
Checking the Client-Side Logs
If your nslookup is successful but the thin client still refuses to show up in the Wyse Management Suite console, you need to check the logs on the endpoint itself to see exactly where the handshake is failing.
- Windows 11 IoT Enterprise: Open the Wyse Device Agent (WDA) application from the system tray, navigate to the Support tab, and enable Support Mode. The WDA logs, which document the entire discovery process, are located at
C:\Wyse\WDA. - ThinOS 9.x / 10.x: On the local ThinOS interface, pull down the toolbar and navigate to Settings > Troubleshooting > Event Logs. You can view the check-in attempts directly here or use the Export Logs option to save the full system dump to a FAT32 formatted USB drive.
Always verify your endpoints can reach the WMS server on TCP 443 (Management) and TCP 1883 (MQTT for on-prem) or TCP 8443 (MQTT for WMS Cloud). A blocked MQTT port will allow the device to register initially, but it will never receive real-time commands or reboot tasks.
By ditching CNAMEs and utilizing DHCP tags or a complete set of SRV/TXT records, you give the endpoint the complete context it needs to securely register itself in the correct WMS tenant with zero manual intervention.