Demystifying ThinOS Updates: Managing Firmware, BIOS, and App Packages via WMS

You’ve set up bulletproof auto-discovery. You’ve architected your WMS group structure to perfectly route endpoints using auto-grouping rules. Now it’s time for the real work: keeping those endpoints secure, updated, and functional without disrupting your end-users.

If you are coming from legacy environments (like ThinOS 8), you need to leave your old upgrade habits at the door. Modern ThinOS (9.x and 10.x) completely changed the game. It is no longer a monolithic, single-file upgrade.

Here is how to master the modular update system in Wyse Management Suite (WMS) to deploy the "Holy Trinity" of endpoints: OS Firmware, Hardware BIOS, and VDI Applications.

1. The Modular OS: Welcome to Modern ThinOS

Dell rebuilt ThinOS from the ground up starting with version 9.x. The biggest architectural shift was decoupling the VDI client applications (Citrix Workspace, VMware Horizon, Microsoft AVD) and Unified Communications plugins (Teams, Zoom, Cisco) from the base operating system.

Why does this matter?
In the past, if a critical vulnerability was found in the Zoom plugin, you had to wait for Dell to release an entirely new ThinOS firmware image, test the whole OS, and reboot the fleet. Today, if an update drops for Citrix Workspace, you simply deploy the new Citrix package. The base OS remains completely untouched. This modularity drastically reduces testing time and deployment risk.

2. Taming the WMS Repository

Before you can assign policies, you need to get your files into WMS. Navigate to Apps & Data in your WMS console. This is where organization is critical.

• OS Image Repository: This is strictly for your base ThinOS firmware files and Dell Hardware BIOS payloads.
• App Inventory: This is where you upload the modular .pkg files for your VDI clients (Horizon, Citrix) and UC plugins (Teams, Zoom).

The ThinOS 9 vs. ThinOS 10 Golden Rule:
You must be meticulous about version control and repository organization. ThinOS 9 and ThinOS 10 utilize fundamentally different package architectures. You cannot deploy a ThinOS 9 application or firmware package to a device running ThinOS 10 (or vice versa). The OS will strictly reject mismatched architectural packages.

When uploading files to your repository, adopt a strict naming convention (e.g., APP_CitrixWorkspace_2311_OS10) so that when you are building a policy 6 months from now, you know exactly which OS version that package belongs to.

3. Pushing the Holy Trinity: OS, BIOS, and Apps

Once your files are in the repository, you assign them at the Group Policy level. Because you followed our previous guide, you are going to apply these to your Test group first!

• The Base Firmware (OS): Inside your group policy, navigate to the Firmware upgrade section. WMS makes this incredibly easy—you simply select the target ThinOS version from a dropdown. WMS will instruct the client to pull the firmware and flash it on the next reboot.
• The Hardware BIOS: Often overlooked, but keeping the underlying Dell BIOS updated is critical for USB peripheral redirection and hardware offloading to work correctly in modern VDI. You can attach a BIOS .pkg file right alongside your OS firmware policy to keep the hardware in lockstep with the OS.
• The Application Payloads: Under the Application Policies section, you select the modular packages. Pay attention to dependencies. You cannot install the Citrix Teams Optimization plugin if the base Citrix Workspace App isn't installed first. WMS generally handles the installation order gracefully, but it’s best practice to group dependent applications in the same deployment wave.

4. Staging, Scheduling, and the End-User Experience

Pushing an update is easy. Pushing an update without angering your users is an art.

In WMS, the ThinOS Group Policy strictly defines the payload. If you simply assign a new firmware and click Save & Publish, WMS defaults to a Live Update and pushes it immediately—potentially dropping a call center agent from a live interaction. To establish a true maintenance window, you must use one of the two following methods:

Method 1: WMS Jobs (The True Scheduler)

Instead of relying on the policy to push updates on its own, you can control the exact timing using the WMS scheduler.

1. Navigate to the Jobs tab in your WMS console.
2. Select either Schedule App Policy or Schedule Image Policy.
3. Select your target group and define your exact maintenance window (e.g., Run between 2:00 AM and 5:00 AM).
4. Set it to execute on the Device Time Zone so your West Coast clients don't reboot at 11:00 PM their time.

Method 2: Scheduled Reboots & Disabled Live Update (The Policy Workaround)

If you prefer to keep your update logic tied directly to your group policies rather than creating separate Jobs, you can manipulate the endpoint's reboot behavior.

• Disable Live Update: Within your ThinOS policy, turn off Live Update. This instructs the thin client to silently download the new packages in the background, but it will wait to install them until its next reboot.
• Configure Scheduled Reboot: Navigate to Advanced > System Settings > Scheduled Reboot Settings within the policy. Here, you can configure a daily forced reboot window (e.g., 3:00 AM). This nightly reboot essentially becomes your maintenance window, ensuring devices process their pending updates while users are offline.

---

User Deferrals: Regardless of which method you choose, it is best practice to enable user deferrals for any daytime or critical patches. You can configure a pop-up that gives the user the option to delay an impending reboot up to 3 times before the system forces the installation.

Rollback Strategies: If you push a new Horizon client to your Test group and users report that a legacy published app is crashing, modularity saves you. You simply go into the policy, select the previous Horizon package version, and WMS will orchestrate the downgrade on the endpoint without forcing you to re-image the whole device.