Managing Updates for Windows Devices: Workspace ONE Operational Tutorial
Windows Updates Overview
Workspace ONE® UEM (Unified Endpoint Management) provides tailored functionality to address Windows Updates within your enterprise. The Workspace ONE UEM update-as-a-service model not only automates and propagates Windows Updates, but it also enables administrators to pause, resume, and/or rollback updates.
Whether administering Windows 10 or Windows 11, this guide helps you understand:
- Options for deploying and managing Windows updates
- How to create distribution rings using Smart Groups, set up a patching policy, and build a Windows Updates profile
- Where and how to assess the status of Windows Update patches, as well as validation and reports
Workspace ONE UEM Windows Update Process Flow
Managing Windows Updates with Workspace ONE UEM is based on the following process flow:
Figure 1: Windows Update process flow.
- Workspace ONE UEM managed Windows desktop devices reach out to Microsoft Update source to query available updates.
- A list of KBs/Updates is sent back to the device in the form of metadata.
- Devices report available updates to Workspace ONE UEM on the next Windows Update sample interval.
- If Workspace ONE Intelligence is integrated, updates data is also sent to Workspace ONE Intelligence.
- Following the next update scan by the device or manual scan by the user, the device will fetch the authorized updates from either a peer device or Windows Update source, depending on configuration within the Workspace ONE UEM console.
Omnissa recommends:
- Pulling updates from Windows Update for Business, rather than Windows Server Update Services (WSUS)
- Peer-to-peer sharing, rather than individualized fetching, to reduce network bandwidth
Why are these options recommended? These settings save system, network, and administrative resources. As an example, eliminating the need for WSUS servers removes the need for these server resources, as well as licensing and associated administrative overhead.
Key Considerations for Successful Windows Update Deployment
When configuring Windows Update via Workspace ONE UEM, several key considerations and settings should be understood. Each of these items is detailed within this document.
- Windows Update Source and Types: Differentiation between Windows Update for Business or Windows Server Update Service, as well as deployment considerations associated with specific types of Windows Updates
- Windows Update Configuration: Workspace ONE Profile settings and configuration options, including deployment rings and related impact
- Validation and Status: Check the status of Windows Updates and determine whether subsequent action is necessary
Windows Update Source and Types
The source for Windows Updates can be Windows Update for Business or Windows Server Update Services (WSUS). Workspace ONE functions equally well via either mechanism; however, Windows Update for Business is recommended for Workspace ONE UEM due to cloud-based functionality and minimal administration.
Figure 2: Windows Update source comparison.
Several types of Windows Updates can be applied to Windows devices. This document will focus on Feature and Quality Updates. For a complete description of Windows Update types, see Microsoft learning documentation.
Feature and Quality updates may be directly controlled by administrators within Workspace ONE UEM, and this document will thus focus on the configuration of these types of updates:
- Feature Updates are released annually and contain new features and functionality. For example, the final feature release for Windows 10 was 2H22.
- Quality Updates are typically released as part of monthly “patch Tuesday” but may be released at any time. Quality updates are cumulative and address both security and standard issues. Quality updates may be configured to include Windows drivers and/or Microsoft application updates.
Windows Update Process
Before delving into how to configure Windows Updates, below is an overview of the activity flow when a new Windows Update becomes available:
Figure 3: Windows Update activity flow.
As shown in Figure 3, several key settings impact the behavior of Windows Updates after fetching, namely:
- Windows Update Profile, including numerous configurations such as scheduling, deployment based on update type, and reboot requirements
- Deployment Rings, including the manual creation of subsets of devices based on Smart Group designation
- Pause/Resume/Rollback, whether for specific devices or the entire profile
Each of these items will be discussed in subsequent sections of this document.
Windows Update Configuration
Windows Update may be configured within a Workspace ONE UEM CIS Leve1 Baseline, as well as a Profile. The Windows Security Baseline does not contain any Windows Updates items. For a detailed explanation regarding Workspace ONE Baselines and Profiles and functionality, please see the Workspace ONE UEM Baselines and Profiles Technical Walkthrough.
Within that document, Omnissa recommends using a template Baseline as the primary security setting. Please note the exception discussed below.
Note: Although several configuration settings related to Windows Updates are available within the CIS Level 1 Baseline, the options presented are minimal and do not enable a robust Windows Update solution that includes functionality such as selecting the Windows Update source and peer-to-peer access designations.
If the CIS Level 1 Baseline is used within your organization, the following settings should be changed to disabled under Computer Configuration\Administrative Templates\Windows Components\Windows Update\ in favor of settings that should be configured via a Workspace ONE Profile.
Figure 4: Setting that should be disabled within CIS L1 Baseline.
Omnissa does not recommend the application of Active Directory GPOs to Workspace One managed Windows devices; however, if you must incorporate GPOs, it is critical to ensure that Windows Updates settings are not duplicated and propagated via multiple policy types.
Omnissa recommends configuring all Windows Update settings within the Windows Update payload of a Workspace ONE Profile.
Figure 5: Configure all Windows Update settings within a Workspace One Profile.
To configure a Profile for Windows Updates, follow these steps:
Figure 6: Creating Device Profile for Windows Update.
Where an existing Profile focused on Windows Updates needs to be modified, the administrator would instead select the existing profile and change specific settings accordingly. The designated Windows Update source cannot be subsequently changed after profile creation; it is necessary to create a new profile if the Windows Update source is later modified. This is because of the applied best practices for the different sources. For example, if your enterprise currently uses WSUS as the source and then transitions to Windows Update for Business, that Profile cannot be modified; it would be necessary to create a new Windows device profile.
If your existing Windows Update Policy is based on what is labelled Windows Update (Legacy), you can easily migrate that policy to the newer version. Simply open the existing Profile and select migrate.
Windows Update Profile Options
Within Workspace ONE UEM, available options and recommended selections vary slightly based on the Windows Update source. For example, WSUS includes configuration options within the Definition section that are not applicable to Microsoft Update Service.
The following chart compares the Windows Update policy options and respective default settings based on selecting the source as Windows Update Services vs. WSUS:
| Item | Microsoft Update Service Default Setting | WSUS Default Setting |
Definition | Windows Update Source | [default] | |
WSUS Server URL | n/a | ||
Proxy Behavior | n/a | Allow system proxy only for HTTP scans | |
Telemetry | n/a | 0 - Security | |
Update Branch | General Availability Channel (Targeted) | General Availability Channel (Targeted) | |
Manage Preview Builds | Disable Preview Builds | Disable Preview Builds | |
Device Scheduling
| Disabled | Disabled | |
Enable Device Scheduling | Enable | Enable | |
Configure Automatic Update Behavior | Updates automatically download and install at an optimal time determined by the device | Updates automatically download and install at an optimal time determined by the device | |
Configuration Deadline Daily Reboot | Disabled | Disabled | |
Feature Update (Days) | 7 | 7 | |
Quality Update (Days) | 7 | 7 | |
Grace Period (Days) | 2 | 2 | |
Update Behavior
| Disabled | Disabled | |
Disable Dual Scan | n/a | Yes | |
Allow Windows Update Service | n/a | No | |
Allow Microsoft Application Updates | No | No | |
Feature Update Uninstall Period (Days) | 10 | 10 | |
Defer Feature Updates (Days) | 365 | 365 | |
Defer Quality Updates (Days) | 7 | 7 | |
Exclude Windows Drivers from Quality Updates | No | No | |
Disable Safe Guard | No | No | |
Allow Non-Microsoft Signed Update | n/a | No | |
Device Behavior
| Disabled | Disabled | |
Allow Auto Windows Update Download Over Metered Network | No | No | |
Ignore Cellular Data Download Limit for Application Updates | Yes | Yes | |
Ignore Cellular Data Download Limit for System Updates | Yes | Yes | |
Delivery Optimization
| Disabled | Disabled | |
Caching Source | Peer mode | Peer mode | |
Hosted Mode Cache Host Source | DHCP Option ID | DHCP Option ID | |
Hosted Mode Cache Host | |||
Download Mode | HTTP Blended with Peering Behind the Same NAT | HTTP Blended with Peering Behind the Same NAT | |
Max Cache Age (Days) | 0 | 0 | |
Cache Drive | |||
Absolute Max Cache Size (GB) | 20 | 20 | |
Allow VPN Peer Caching | No | No | |
Minimum Size to Cache (MB) | 50 | 50 | |
Non-Peer Download Delay: Foreground download delay (in seconds) | 60 | 60 | |
Non-Peer Download Delay: Background download delay (in seconds) | 60 | 60 | |
Network | Disable | Disable | |
Foreground Download Bandwidth (KB/s) | 0 | 0 | |
Background Download Bandwidth (KB/s) | 0 | 0 | |
Minimum Background QoS (KB/s) | 200 | 200 | |
Monthly Upload Data Limit (GB) | 0 | 0 | |
Restrict Peer Selection by Subnet | No | No | |
Device Requirements for Caching | Disable | Disable | |
Minimum Battery Limit (Percent) | 40 | 40 | |
Minimum Available Storage (GB) | 32 | 32 | |
Minimum Available Memory (GB) | 4 | 4 | |
Network Bandwidth Limitation | Disabled | Disabled | |
Time Period (Start) | 6:00 AM | 6:00 AM | |
Time Period (End) | 6:00 AM | 6:00 AM | |
Background Download Limit During Time Period (Percent) | 20 | 20 | |
Background Download Limit Outside of Time Period (Percent) | 20 | 20 | |
Foreground Download Limit During Time Period (Percent) | 20 | 20 | |
Foreground Download Limit Outside of Time Period (Percent) | 20 | 20 | |
OS Version
| Disabled | Disabled | |
Target Release Version | |||
Target Product Version | Windows 10 | Windows 10 |
When configuring profiles, ensure that Windows Active Directory GPOs do not have any Windows Update settings configured to avoid conflicts. As a best practice, Workspace ONE UEM should be the single source for Windows Update settings.
Although the maximum deferral period for Quality Updates is 30 days, this lengthy configuration timeframe is not recommended because it is possible that specific updates will be superseded before propagation. For example, if an update is released on “patch Tuesday” and then superseded 20 days later without having been deployed, the original update would no longer be available. For this reason, it is recommended that Windows Updates not align with the maximum deferral period settings but instead be configured for deployment as soon as reasonably practicable, optimally within 14 days.
Deployment Rings
The concept of Deployment Rings is a proven and effective methodology for applying Windows Updates. By systematically propagating Windows Updates to devices over a period of time rather than all at once, users are ensured a better experience. The following is an example of a Deployment Ring:
Figure 7: Sample Windows Update Deployment Ring.
Of course, you can set up Deployment Rings as is best suited for your environment. In this example, Ring 0 could be a basic test to ensure that the device boots, whereas Ring 1 users test core business applications and functionality. The initial internal users should have a dedication communication channel so that support requests feed to Workspace ONE administrators. Communicating with key users is important for learning about and addressing issues.
Smart Groups
When applying the Profile comprised of Windows Updates settings, carefully consider Smart Group membership for deployment rings to ensure that no Windows devices are inadvertently omitted.
Figure 8: Windows Profile sample Smart Group membership.
Smart Groups that are designated within the Profile(s) that address Windows Updates should be based only on Windows devices. At a minimum, the Platform and Operating System criteria should be designated as Windows. The specific version(s) should differentiate Windows 10 devices from Windows 11 devices.
To modify or create a Smart Group, go to Groups & Settings > Groups > Assignment Groups.
For example, if an administrator wishes to create a Smart Group that includes all versions of Windows 11 devices, the following could be configured:
Figure 9: Configuring a Smart Group based on all Windows 11 devices.
Additional criteria such as tags may be applied as part of the Smart Group configuration.
Sensors
When determining eligibility for Windows Updates deployment rings, Sensors may be a useful tool. In addition to the built-in sensors, administrators may create new sensors to query devices.
For example, if a minimum of 10 GB is required to install a Feature Update, first querying all Windows devices for available disk space would enable administrators to know which devices can and cannot accept the update. Devices that can accept the Feature Update could be placed into a deployment ring for immediate installation, whereas the other devices could be deferred until the administrator can address upgrade or clean-up requirements.
In this example, enabling and assigning the built-in os_disk_free_space sensor would be useful:
Figure 10: Sensor: os_disk_free_space.
Sensors must be subsequently assigned to a Smart Group.
Pause, Resume, Rollback
After Windows Updates have started to deploy, it may be necessary to pause, resume, or rollback. For example, if a specific update causes an issue, rolling back or pausing it may be necessary. Once the issue is resolved, deployment can be resumed.
Pause, resume, and rollback may now be executed directly within the Workspace ONE UEM console; it is no longer necessary to execute scripts to enable this functionality. All three of these actions may be accessed for individual devices, whereas pause and rollback options are available for the profile.
Figure 11: Device pause, resume, and rollback options.
To pause or rollback the Windows Update Profile, access Resources > Profiles. After selecting the Profile, the options to pause and rollback appear.
Figure 12: Windows Update Profile options.
If pause is selected, the administrator can select whether to pause feature and/or quality updates, as well as the start time.
Figure 13: Setting the amount of time to pause Windows Updates.
If rollback is selected, the administrator can choose feature updates or quality updates, along with a warning, as shown below.
Figure 14: Profile rollback functionality.
Validation and Status
There are several ways to validate the status of Windows Updates. Within the Workspace ONE UEM console, go to Devices > Device Updates. The Update Overview section shows numerous data points regarding Windows Updates, including details regarding each update.
Figure 15: Device Updates screen showing status of Windows Updates.
An administrator can select a device and view the Updates tab for a holistic view of all updates that have been installed on the device. The Update sources now uniquely include queries based on the Windows Update Agent (WUA), DISM, and WMI. Because these three sources are used, the accuracy and validity of the Windows Update status is ensured.
Figure 14: Device report showing Windows Updates by source.
Lastly, customizable dashboards can be created within Intelligence based on real-time Windows Updates metrics.
Figure 15: Intelligence Windows Updates data points.
Troubleshooting
If issues arise with the propagation of Windows Updates, several actions may be taken to troubleshoot.
Conflicting Settings
Firstly, ensure that conflicting settings are not present. Windows Update settings should not be configured in multiple places as this could cause intermittent and/or inconsistent results. Specifically, verify the following aspects of Windows Update configuration:
- Active Directory GPOs are not configured to enable Windows Updates.
- If a CIS L1 Baseline is deployed, the Windows Update settings are disabled.
- A Workspace ONE Profile with only the Windows Update payload has been deployed and the Smart Group is correctly configured.
Troubleshooting Tab
The Troubleshooting tab within the Devices view provides information regarding all events affecting a device, and line items regarding Profile failures may provide insight regarding issues. After selecting a device, select More > Troubleshooting.
Transitioning from Windows Update (Legacy) to New Windows Update Profile
If you encounter an issue transitioning from Windows Update (Legacy) Profile to the new Windows Update Profile, it is possible that some devices are not installing Windows Updates.
The first step is to ensure that the Windows Update (Legacy) profile has been properly unlinked/disabled and the new Windows Update policy has been configured and applied correctly. In particular, examine the Smart Group designation.
Secondarily, it is possible that some residual impact of the old policy remains on the Windows device, and this can be validated by checking registry keys on the Windows device.
Figure 16: Windows registry keys impacted by legacy and new Windows Update policies.
The next step is to ascertain which resource is being accessed for Windows Updates by checking the following registry key:
- HKLM\Software\Microsoft\PolicyManager\current\device\Update\UpdateServiceUrl
If this key points to the previous Windows Update resource, the new Windows Update policy has not been applied properly, and/or antiquated settings have not been correctly updated.
It may be necessary to remove the Windows Update registry keys from the following location:
- HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate
Of course, the registry should be backed up before making any changes.
If the Windows device still does not properly apply Windows Updates, it may be necessary to reset Windows Update components.
Local Device
In addition to the administrative views for validation presented above, data points on the user device may help pinpoint issues. On the local device, Settings > Windows Update provides two key tabs that may be used for further research:
- Update History showing the updates that have been installed on the device.
- Advanced Options provides details regarding configured update policies controlled by Workspace ONE, as well as delivery optimization data that may be useful for tracking down bandwidth utilization and the impact of peer-to-peer optimization.
Lastly, several additional actions can be undertaken on the endpoint to research issues:
- To see all Windows Updates settings, view the registry on the local device via Computer\HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update.
Figure 17: Registry details of Computer\HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update.
- On the local device, execute get-hotfix to see the Windows Updates that have been installed.
Figure 18: List of Windows Updates as shown via get-hotfix command.
- On the local device, execute get-windowsupdatelog to pull the related log files.
Figure 19: Windows Update logs as output from get-windowsupdate log command.
- Within the Event Viewer under Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational, various types of event logs will be displayed.
Figure 20: Event Viewer output as accessed from Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational.
Summary and Additional Resources
This document provided a comprehensive guide to managing Windows updates with Workspace ONE UEM, covering key concepts such as Windows Updates sources, deployment rings, Smart Groups, sensors, and validation steps.
Figure 21: Best Practices.
Additional Resources
For more information about configuring Workspace ONE UEM Profiles based on Windows Updates, please see:
Windows Security and Policy Management
Windows Modern Management Security Design and Implementation
Changelog
The following updates were made to this guide:
Date | Description of Changes |
2024/03 | Complete rewrite of this guide. |
2024/09 | Major content update to reflect new Windows Updates functionality, as well as Troubleshooting section. |
About the Author and Contributors
This guide was written by Jo Harder, Senior Technical Marketing Architect, Omnissa, and reviewed by:
- Saurabh Jhunjhunwala, EUC Customer Success Architect, Omnissa
- Grischa Ernst, EUC Product Manager, Omnissa
- Criselda Abarquez, Staff Solution Engineer, Omnissa
Feedback
Your feedback is valuable.
To comment on this paper, contact Omnissa Technical Marketing at tech_content_feedback@omnissa.com.