Mastering WMS Policy Inheritance: Group Structure and Auto-Grouping Rules
You’ve finally nailed down your auto-discovery using DNS SRV records and DHCP tags. You boot up a fresh thin client, and like magic, it checks into your Wyse Management Suite (WMS) tenant.
But what happens next?
If you haven’t properly architected your WMS group structure, that seamless check-in turns into an administrative nightmare, and troubleshooting becomes a game of hunting through nested folders to find where a conflicting policy was configured.
To run a scalable, enterprise-grade EUC environment, you need a blueprint. Here is how to structure your WMS groups, master policy inheritance, and automate device placement so you never have to manually move a thin client again.
1. The Blueprint for WMS Groups: Architecture Matters
A common misconception is that you must silo your groups by the operating system to prevent devices from pulling the wrong configuration. The reality is that WMS policies are inherently OS-specific. You can safely place both ThinOS and Windows 11 IoT devices into the exact same policy group, and WMS will intelligently apply only the payload that corresponds to the OS the device is actually running.
However, your group architecture does need to account for testing and operational structure. Because you cannot block a policy from inheriting down from a top-level group, your root structure needs a built-in safety valve.
A Best-Practice Hierarchy:
- Tenant Root (Global): Keep this minimal. Immediately beneath the root, split your environment into two primary branches: Production and Test. Any new policy changes or firmware updates should always be vetted in the Test branch before touching your live environment.
- Structuring Your Branches (Two Ways): Beneath your Production (and Test) groups, you can organize your hierarchy using one of two methodologies, depending on what primarily dictates your configuration differences:
- Approach A (Use Case First, Location Second): Build your groups by use case first (e.g., Call Center, Kiosk Workstations, Standard Office), and then nest specific locations beneath them if regional variations exist.
- Approach B (Location First, Use Case Second): Build your groups by physical location or branch first (e.g., East Coast, West Coast), and then nest the specific use cases underneath each location.
- What is a "Use Case"? In this context, a use case refers to endpoints that require distinct thin client settings—such as specialized multi-monitor display layouts, strict USB redirection rules, unique security lockdown profiles, or targeted application payloads.
- The Quarantine / Staging Group: Always maintain an isolated top-level group for newly discovered devices. This prevents a brand-new, unpatched device from immediately pulling a production payload and rebooting while a user is trying to log in.
The WMS Interface: A Real-World Example
If you were to map out "Approach A" (Use Case First) inside the Groups & Configs tab of your WMS console, your navigation tree would look exactly like this:
This visual tree makes inheritance incredibly easy to manage. If you need to change the timezone settings for just your East Coast call center agents, you apply it at the 📍 East Coast Branch level. If you need to update the VoIP application for ALL call center agents globally, you apply it at the 📞 Call Center parent level, and it cascades down to both coasts automatically.
2. Understanding Policy Inheritance (The Waterfall Effect)
WMS utilizes a top-down inheritance model. Settings applied at a parent group cascade down to all child groups automatically.
How to leverage this:
Put your baseline security and connection settings at the Parent level (for example, at your Production or Call Center parent group). You might configure your standard VDI broker URLs, base domain join scripts for Windows, and baseline display settings there.
Child groups should only contain the delta—the settings that make that specific group unique. Your East Coast Branch child group might simply add a specific local printer payload and adjust the time zone, while inheriting everything else from the parent.
Pro Tip on Exceptions: WMS allows you to set policy exceptions at the child level, effectively overriding a parent setting. Use this sparingly! If you find yourself creating multiple exceptions in a child group to undo what the parent group is enforcing, your parent policy is too restrictive. Move those specific settings down a tier.
3. Dynamic Auto-Grouping Rules (The Magic Trick)
If you followed our auto-discovery guide, you are handing out a "Staging" or "Quarantine" Group Token via DHCP Option 199 or a DNS TXT record. Every new device lands there.
Instead of an admin logging in daily to drag and drop these devices into their proper production groups, we use Rules to automate the flow.
Navigate to Rules > Auto Grouping in WMS. Here, you can define logic that looks at the device checking in and automatically moves it to the correct child group based on specific criteria.
The best triggers for Auto-Grouping:
- Subnet Mapping: If your Call Center VLAN is
10.50.20.x, create a rule that says: If Device IP is in Subnet 10.50.20.0/24, move to Group: Production > Call Center > East Coast Branch. - Device Naming Conventions: If your endpoints are pre-staged in AD or renamed during imaging (e.g.,
KIOSK-W11-001), you can create a rule evaluating the device hostname. If Hostname begins with "KIOSK-", move to Group: Production > Kiosk Workstations. - Custom Tags: You can push custom device tags during the imaging process and use WMS to route them based on those exact strings.
The Workflow in Action:
- A new thin client boots up and grabs an IP address.
- DHCP Option tags point it to your WMS server and hand it the
defa-quarantinetoken. - The device registers in the Quarantine group and receives a minimal, safe baseline configuration.
- The WMS Auto-Grouping rule evaluates the device's Subnet or naming convention.
- WMS automatically moves the device to the correct production group.
- The device inherits the production policies tailored to its specific OS and use case, locks down the interface, and is ready for the end-user.