Managing Updates for Windows Devices: Workspace ONE Operational Tutorial
VMware Workspace ONE UEM 2011 and laterOverview
Introduction
Note: This content was created for Windows 10, but the basic principles and tasks outlined also apply to your deployment of Windows 11.
VMware provides this operational tutorial to help you with your VMware Workspace ONE® environment. This tutorial helps you to manage Windows 10 updates with VMware Workspace ONE® UEM (unified endpoint management). Procedures include syncing Active Directory Organization Units to Workspace ONE UEM, creating distribution rings using smart groups, and creating an Updates profile. This tutorial also mentions the use of VMware Workspace ONE® Intelligence to provide visibility of managed Windows 10 devices and the security risks associated with each device.
Audience
This operational tutorial is intended for IT professionals and Workspace ONE administrators of existing production environments. Both current and new administrators can benefit from using this tutorial.
Familiarity with networking and storage in a virtual environment is assumed, including Active Directory, identity management, and directory services. Knowledge of additional technologies such as VMware Workspace ONE® Access (formerly VMware Identity Manager) and VMware Workspace ONE® UEM and Microsoft Store for Business is also helpful.
Windows Update for Business Overview
Introduction
The Workspace ONE UEM update service for Windows 10 provides tailored functionality to address the unique constraints of managing updates in the cloud. Traditional operating system upgrades use a wipe-and-replace model. In contrast, the update-as-a-service model pushes the approval and configurations for the periodic operating system and feature updates. Windows 10 updates occur on a frequent and dynamic basis to ensure that end-users always have access to up-to-date operating system features.

The Windows update-as-a-service requires a new architecture and the above image shows how updates are approved by Workspace ONE UEM and Workspace ONE Intelligence.
- Workspace ONE UEM managed Windows 10 devices reach out to Microsoft Update Servers to query available updates.
- A list of KBs/Updates are 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.
- Workspace ONE UEM pulls in additional information from Microsoft about each available update.
- If Workspace ONE Intelligence is integrated, updates data is also sent to Workspace ONE Intelligence.
- If Workspace ONE Intelligence is integrated, CVE feed is ingested into Workspace ONE Intelligence daily.
- If Workspace ONE Intelligence is integrated, Workspace ONE Intelligence correlates CVEs and KBs.
- If Workspace ONE Intelligence is integrated, configurable automation updates are approved.
- Based on approvals via the Workspace ONE UEM console or automation in Workspace ONE Intelligence, authorized approved updates (metadata) are sent to the devices.
- On the next update scan by the device, or manual scan by the user, the device will fetch the authorized updates.
- If Delivery Optimization is configured, devices will leverage Peer-to-Peer delivery when downloading updates.
- Lastly, the update results are sent to the Workspace ONE UEM console on the next Windows Update sample interval.
Diagnostic & Usage Telemetry Data
Important: When using Workspace ONE UEM to manage Windows Updates, the minimum required diagnostic data setting is Basic or Required. No Windows Update information is collected when diagnostic data is set to Security or Off; therefore, Workspace ONE UEM doesn't receive information about updates. For more details, refer to diagnostic data settings that provide insight into the type of data collected at each level.
You can configure the diagnostic and usage telemetry settings by leveraging a Restrictions profile in the Workspace ONE UEM console. You will want to ensure that the recommended value for the Send Diagnostic and Usage Telemetry Data setting is set to Basic or above and NOT set to Security.

Windows Update for Business
Windows 10 leverages a system called Windows Update for Business, also known as WUfB, that is responsible for scans, downloads, and installations of device updates. Windows updates fall into the following two categories: Feature Updates and Quality Updates.
For more information, refer to What is Windows Update for Business?
Feature Updates
Microsoft releases new significant updates roughly every six months, known as Semi-Annual or Feature Updates. These updates typically become available during Spring and Fall and include new features, visual improvements, experience changes, and security enhancements. These updates can be sizeable and require more testing than the smaller Quality Updates, which follow a weekly or sometimes daily release cadence.
Quality Updates
Microsoft releases smaller, minor updates more frequently called Quality Updates. In a business environment, you control certain aspects of how and when these get deployed to devices through the Mobile Device Management (MDM) framework. Unlike Feature Updates, they do not include new features but instead focus on bug fixes, errors, reliability, and security. The updates are minor and tend to be much less disruptive than a Feature Update; however, it is crucial to ensure you have the same plans to handle these updates as you do for Feature Updates. Once a month, multiple Quality Updates are combined into a Cumulative Update. These updates combine multiple versions of a KB (Knowledge Base, or the solution patch to a known issue which corresponds to a knowledge base) into a single update, simplifying deployment and lowering user and device disruption. Cumulative Updates operate and are managed almost exactly like Quality Updates with one key exception; they are not eligible for rollback. While individual KBs may be removed from a device (depending on classification) and reverted to the previous version, cumulative updates include multiple versions. Therefore, they cannot rollback since there is no previous all-inclusive version to revert to once installed.
Comparison between Windows Server Update Services (WSUS) and Windows Update for Business
The following is a breakdown of the key differences between the legacy Windows Server Update Services (WSUS) methodology and the modern approach using Windows Update for Business (WUfB):
- Updates are downloaded directly by the device from Windows Update, in the Windows Update for Business (WUfB).
- Deployment rings are used to determine which devices receive updates and when these updates are received.
- With auto-approved patches, updates can only be deferred for a maximum of 365 days for Feature and 30 days for Quality to allow for testing. After this period, updates not configured to require approval will auto-install.
- Specific updates can be approved from within the Workspace ONE UEM Console. Still, not all updates will adhere to the approval process; in some cases, Microsoft will circumvent the approval process for specific update types to remediate a vulnerability.
Controlling and Restricting Updates
Introduction
Several methods are available to control how and when to apply updates to a device or set of devices.
- Deferral: Setting a deferral period of up to 30 days postpones updates from being applied to a device for that duration. This functionality provides a window for IT teams to test and validate all updates before deploying to production machines. Deferral periods begin from the update’s “Release Date.”
- Pause: When paused, the device will no longer scan for updates from Windows Update for a maximum of 35 days from the beginning of the user-specified pause date. After the 35 days have expired, updates continue to process as normal. The pause process allows short pauses to deployments to help resolve issues encountered during patch or update deployment.
- Target Release Version: Through a custom policy, a device can now stay on a specific Feature Update while receiving all Quality Updates. Due to the way Feature Updates are designed to supersede Quality Updates after deferral has expired, it’s now possible to set a device to a specific OS version but continue to keep it securely patched with the latest available updates. This offers flexibility beyond the normal deferral process. For configuration information reference CSP TargetReleaseVersion Profile Configuration.
- Require Update Approval: With required update approval enabled, updates are not allowed on a device until they are approved in the console by an administrator. There are some considerations with this process to keep in mind. The next sections cover these considerations in more detail. The deferral process is the preferred method since it removes some of the manual effort required to process approvals and prevents necessary approvals from being accidentally missed.
Note on the usage of Deferral and Pause: It is imperative, to both the security of the Windows devices and the smooth running of all software, to thoroughly test all patches, and any issues are remediated where needed, within the 30-day deferral period (365 days for Feature updates) or the 35 day pause period. At the end of these periods, patches may automatically begin to download and install.
Suppose an admin has decided to configure all updates to Require Update Approval by the administrator. Require Update Approval negates the need to use the pause or deferral settings since all updates are made available to devices only after being approved.
Considerations for Requiring Update Approval
Mobile Device Management (MDM) controls provided by Microsoft to allow integration with Windows Update for Business only allow limited capabilities to approve updates. Microsoft also retains the ability to override any approval process, forcing updates to be applied to devices circumventing approval processes.
The following table details each Windows Update category, the granularity level supported for controlling update approvals, and an estimated frequency based on historical trending. Partial Approval Control does not mean that all updates within that category disregard the setting, just that there are some updates within this category that Microsoft can configure to override this setting. Frequency estimates are based on how frequently Microsoft has published updates recently and should not be interpreted to indicate how these are published in the future.
Updates that override the approval controls may also not report to the Workspace ONE UEM Console: either available for the device or installed on the device.
Update Category | Details | Approval Control | Frequency Estimate |
Critical | Widely released fix addressing a critical, non-security-related bug. A typical example: Update to Windows Update framework. | Partial | Medium |
Cumulative Updates | A cumulative set of all hotfixes, security, critical, and updates fixes targeting a specific part of the product, such as security or services. | Full | |
Definition | Frequent updates add to the product definition database and are often used to detect attributes like malicious code, phishing sites, and junk mail. E.g., Security Intelligence Update for Windows Defender Antivirus. | Full | |
Driver | Software controls for Input and Output of a device. | Full | |
Feature Pack | New functionality distributed outside of a product release, typically before the next full release. E.g., .NET Framework updates. | Partial | Low |
Feature Update | Twice-yearly windows feature update. | Full | |
Security | Widely released fix addressing product-specific, security-related vulnerabilities. | Partial | Low |
Service Pack | A cumulative set of all hotfixes, security, critical, and updates fixes for internally found bugs or customer-requested changes and/or features. | Partial | Low |
Tool | A utility of feature that helps complete a task or set of tasks. | Partial | Medium-Low |
Update | A widely released fix for a specific problem addressing non-critical, non-security-related bug. | Partial | Low |
Update Rollup | A cumulative set of all hotfixes, security, critical, and updates fixes targeting a specific part of the product, such as security or services. Replaced by Cumulative Updates. E.g., Windows Malicious Software Removal Tool. | Partial | Low |
Leveraging update deferral ensures devices do not install any of these updates. Before the expiration of the deferral period, test all updates.
Updates do not install until the deferral period has lapsed, even if the update is approved before the lapse when using update approval in conjunction with deferrals.
Updates left in an un-approved state require approval before installing. However, there are exceptions to this, including end-of-service dates and Microsoft's ability to force specific updates at any time regardless of the approval process.
Windows Patch Rollback
The Workspace ONE UEM Console does not currently offer any native capability to rollback patches applied to a device. However, the following Update CSP nodes can be used to rollback the latest Feature or Quality update:
CSP | Eligibility Criteria |
Rollback/QualityUpdate | Condition 1: Device must be running version 1803 or newer Condition 2: Device must be Windows Update for Business Connected Condition 3: Device must be in a Paused State (windows updates paused) Condition 4: Device must have the Latest Quality Update installed on the device (Current State) |
Rollback/FeatureUpdate | Condition 1: Device must be running version 1803 or newer Condition 2: Device must be in the Semi-Annual Channel Targeted Condition 3: Device must be Windows Update for Business Connected Condition 4: Device must be in Paused State (windows updates paused) Condition 5: Device must have the Latest Feature Update Installed on the device (Current State) Condition 6: Machine should be within the uninstall period (2-60 days) |
For devices that require rollback, leverage the CSP nodes to build a custom settings profile. Note, after a quality update rollback; the update appears in Windows Setting > Updates > History.
Example profile to remove the last feature update. Replace FeatureUpdate with QualityUpdate to remove the last Quality Update:
<Exec>
<CmdID>bbd7be5a-2409-40a6-ac41-d77fe60b98f7</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/Update/Rollback/FeatureUpdate</LocURI>
</Target>
<Meta>
<Format xmlns="syncml:metinf">null</Format>
<Type>text/plain</Type>
</Meta>
<Data />
</Item>
</Exec>
Click to copy
Updates can also be removed with the Windows Update Standalone Installer (wusa.exe) or the Deployment Image Servicing and Management utility (DISM). Both these utilities can be invoked by deploying either an Apps & Books package, Scripts, or by using Product Provisioning:
Example WUSA command. For more details, refer to the Description of the Windows Update Standalone Installer in Windows.
wusa /uninstall /kb:{KB ID} /quiet /norestart
Windows OS Patching (Quality Updates)
Standard Deployment
The standard deployment approach leverages Windows Server Update Services (WSUS) to deploy updates.

Example Standard Deployment Timeline for February 2020
- Updates are provided by WSUS.
- Patch Tuesday updates manually administered to the Client Validation team the day of release. If the Client Validation team approves the updates, they are then published to the UAT group.
- The pilot group consists of 100+ devices around the world and are mainly technical and IT staff. Pilot devices are added to one or more smart groups.
- Patches are tested, and a sync up call is scheduled for the following week to determine go/no go. In no-go instances, patches are held back (unapproved) until the issue is remediated.
- Patches are then made available to all users in a phase-based approach depending on environment size and diversity.
- Patches are forced to be installed by the last Friday of the month.
- Zero-day and similar patches follow the same process but are accelerated and are dealt with separately.
Modern Deployment
The modern deployment approach uses multiple deployment rings with a production deployment ring set to Require Approval for all patches. Earlier “feedback” rings are configured for auto-approval. It may be decided after some time to move the production rings to be auto-approved as well.

Example Modern Deployment Timeline for February 2020 showing GO and NO-GO Scenarios
- Updates provided directly from Microsoft to devices in feedback rings, saving time collating, and publishing updates.
- Ring 0 – shown above as R0 is the testing and validation ring. Devices are updated automatically as soon as updates are available—deferral value of 0.
- Testing can begin immediately, allowing an earlier go/no-go result and additional time to remediate should there be issues with an update.
- In a GO scenario, patches are approved for production one ring at a time.
- In a NO-GO scenario, updates can be paused, allowing time to remediate. Once remediation is complete, updates can be un-paused for each ring one at a time.
- Zero-day patches follow the same process but are dealt with as a separate patch.
Windows OS Updates (Feature Updates)
Standard Deployment
The standard deployment approach leverages Windows Server Update Services (WSUS) to deploy updates.
- WSUS provides updates.
- Devices are updated once a year with the “Fall” update
- No “Standard” timescale for testing and deployment of the update. The update is applied to test devices and promoted to production once validation is complete.
- Insider updates are not tested; testing begins when the update GAs.
Modern Deployment
The following modern deployment approach is recommended by VMware to provide a more modernized update procedure and to take advantage of the update functionality provided by Microsoft and Workspace ONE UEM.
- Updates are provided directly by Windows Update.
- Optionally subscribe to Insider Updates (release level) for earlier testing feedback.
- Feature updates applied to test ring devices immediately, allowing testing to begin as soon as possible; Deferral value of 0.
- Auto-Approved Updates are deactivated in production for Feature updates. Timeline shown below is an estimated timeline of when these items are approved for the various rings.
- Use the TargetReleaseVersion CSP to ensure that devices do not move past the approved release version and can continue to receive quality updates for that release even after newer feature updates would have prevented further updates from being discovered.

Example deployment timeline for 1909 release (GA November 12, 2019)
Windows Insider Updates
Overview
If additional testing is needed, Windows Insider Updates could have advantages in highlighting any potential software incompatibilities sooner, providing additional time to remediate. Deployment of Insider builds follow the same policies applicable to Feature Updates on the Semi-Annual Channel and Quality Updates (Cumulative Only).
For more information, refer to Create a Deployment Plan - Preview Ring.
Windows Update Approval Process
Overview
For updates controlled using the Approval process, approvals can be set at either the device level (per-device) or for all devices within a Smart Group. Updates can also be approved using Workspace ONE Intelligence, covered in the Approvals using Workspace ONE Intelligence section.
Device Level Approval
Updates can be approved or unapproved at a device level (per-device) from within the console by selecting that device. Available updates are marked with a gray circle with a hyphen and, once selected, can be approved. Upon approval, that update installs at the next sync. Updates that are Approved can be Unapproved in the same way. Unapproving an Approved update stops the update from installing on devices where it was previously approved, as long as the installation of that update has not started.
Smart Group Approval
From the Devices > Device Updates > Windows screen, all updates reported by all devices in the deployment are shown, and from here, it is possible to assign the updates to Smart Groups. When assigning an update to a Smart Group, the update is approved for each device in the Smart Group. In cases where an update is assigned to an ineligible device, that update is still shown as approved for the device but is never downloaded. Using the same method, it is possible to unassign updates from Smart Groups, which stops the update from installing on devices where it was previously approved.
Approving or assigning an update that is ineligible (e.g., update is superseded or unsupported platform architecture) on the target device results in a status of “unknown” in reporting details. This is due to the update having never been available to the device being queried for a corresponding status.

Windows Update Admin Role
Access to assign updates from the Devices > Device Updates screen is available only from the top-level Organization Group. Where needed, a separate role can be configured with the following permissions to allow access:
- All > Device Management > Device Details > Device Details [General] > Device Details Updates
- All > Device Management > Device Details > Device Details [General] > Update Edit Assignments
- All > Device Management > Device Details > Device Details [General] > View Updates
- All > Device Management > Dashboard > Dashboard [Asset Tracking] > Approve Update
- All > Device Management > Dashboard > Dashboard [Asset Tracking] > Unapprove Update
- All > Device Management > Dashboard > Dashboard [Asset Tracking] > View Update Devices
- All > Groups > Smart Groups > Smart Groups [Smart Groups] > Smart Group View
To add a new Admin Role:
- Navigate to Accounts > Administrators > Roles.
- Click Add Role.
- Provide a Name, Description, and add the above permissions.
- Click Save to create the new admin role. You can then assign this role to any of your admins.
To simplify this process, you can find the exported admin role by clicking the More tab at the top of this page, then downloading the Export-DeviceUpdatesAdmin.xml file, then clicking Import Role on the Accounts > Administrators > Roles page.

Windows Update for Business Migration Methodology
Introduction
In a typical enterprise, Windows operating system (OS) updates rely on using WSUS with SCCM to control and deploy updates to all endpoints. When switching to an MDM-based deployment using WUfB, the relationship between the devices and WSUS must be broken to allow the MDM managed update mechanism to take over. Keep in mind that doing this will also affect any other updates that are provided via the SCCM/WSUS mechanism. In addition, any GPO settings that are in place to control Windows Update must also be removed from the device.
For more information on how to deploy GPOs and policies via Workspace ONE UEM, refer to the Understanding Windows 10 Group Policies: VMware Workspace ONE Operational Tutorial.
Testing Windows Update for Business in UAT
Devices used for the initial testing must have SCCM software updates deactivated. This can be done in SCCM by creating a collection and adding the test devices to this collection. With the software updates deactivated, the WUfB profile can be pushed to the test devices and validated. These devices must also be excluded from receiving any GPO settings that control Windows Updates since conflict could arise if both MDM and GPO are configured to control updates. If needed, a sensor can be used to detect if MDM update controls have been applied and if so, remove the GPO settings.
For more information regarding transitioning from SCCM, refer to the Modernizing Windows 10 Management: VMware Workspace ONE Operational Tutorial.
Deploying Windows Update for Business in Production
The following steps detail moving a set of production devices over from WSUS/SCCM controlled updates to MDM controlled updates using WUfB with Workspace ONE UEM. It is understood that this is to occur in a phased process over time for selected batches of devices.
Deploy the Windows Update Profile
Configuring the Workspace ONE UEM Windows Updates profile and assigning to all batch Smart Groups prepares the devices for using WUfB but doesn't activate this update method until the devices are removed from SCCM for Software Update management. Since deploying the profile alone does not activate it, it is safe to deploy to all devices at once.
Exclude Devices from SCCM Updates
SCCM can create multiple collections with membership based on a percentage of the total device count. Software updates can be deactivated on these collections one at a time, allowing a phased approach to moving to WUfB.
Exclude Devices from GPO Updates
GPO settings for Windows Update should also be removed for devices that are being migrated to WUfB. Any GPOs that contain mixed settings (Windows Update settings and other settings) need to be revised and updated to remove the Windows Update settings. If applicable, GPO exclusions should be applied to all devices added subject to GPO policy within a domain.
Deploy GPO Removal Sensor
The following Workspace ONE Sensor can be used to overwrite the GPO Windows Update settings if the MDM WUfB profile has been applied. Deploying this sensor catches any device that is not connected to the domain. This sensor detects if the profile has been applied to the device and then removes the Registry settings associated with GPO, restarts the Windows Update service, and performs a scan. The result returned by the sensor can be used to validate that the devices have switched over from GPO management.
Leveraging Workspace ONE Scripts over Sensors is the best practice for this use-case; however, this feature is currently in Tech Preview. For more information regarding Scripts, refer to the Getting Started with Freestyle Orchestrator Tech Preview Tutorial.
function Test-RegistryValue {
param (
[parameter(Mandatory = $true)]
[ValidateNotNullOrEmpty()]$Path,
[parameter(Mandatory = $true)]
[ValidateNotNullOrEmpty()]$Value
)
try {
Get-ItemProperty -Path $Path | Select-Object -ExpandProperty $Value -ErrorAction Stop | Out-Null
return $true
}
catch {
return $false
}
}
if (Test-Path -Path 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update') {
if (Test-RegistryValue -Path 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update' -Value 'AllowAutoUpdate') { #MDM Updates are configured
if (Test-Path -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate") { #Windows updates are also configured
Remove-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -Recurse
Restart-Service wuauserv
c:\windows\system32\usoclient.exe startscan
Return 'GPO Update configuration removed in favor of MDM'
}
else {
Return 'Device O/S updates controlled via MDM'
}
}
}
else {
Return 'Device not yet configured for MDM Updates, using GPO settings'
}
Click to copy
Windows Feature Update Readiness Detection
Readiness Detection
Before Feature Updates are applied to devices, each device must be evaluated to ensure it does not have versions of software installed that are not supported by the new version of the OS. For example, for an upgrade to Windows 10 version 1909, the list might be as follows:
Application / Package | Version (Minimum) |
Data Protection Agent | No version is compatible |
Data Encryption Agent 64-bit | 10.6 |
ECAT | No version is compatible |
Cylance PROTECT | 2.0.1450 |
McAfee Agent | 5.5 |
McAfee Endpoint Security Platform | 10.5 |
In addition to this list, free disk space must be at a minimum of 20GB.
A sensor is used to determine the readiness of each device (see Appendix: Feature Updates Readiness Dashboard), which returns one of the following results:
DPE, DEA, ECAT, CYLANCE, MCAFEE_AGENT, MCAFEE_ENS, DISK_SPACE, READY_FOR_1909_FEATURE_UPGRADE, OS_ALREADY_1909
Devices returning READY_FOR_1909_FEATURE_UPGRADE
meet the minimum requirements, with devices returning all other values except OS_ALREADY_1909
requiring remediation based on the value returned.
Status can be tracked in Workspace ONE Intelligence using the sensor result to build dashboards (examples shown in Appendix: Feature Updates Readiness Dashboard).
Readiness Remediation
In most instances, devices should pass the software prerequisites for the OS update since the newer versions of the applications will have Auto deployment method configured. In instances where the installation may have failed or when the application deployment method was set to On Demand, automation can be used to push the newer app to affected devices.
Direct Assignment via Workspace ONE Intelligence Automation
If a device already has the newer version of the application assigned to it, a Workspace ONE Intelligence automation can be used to push the application directly to the device:
The Application ID can be obtained by hovering over the app’s name in the Workspace ONE UEM Console.

Assignment via Tags and Smart Groups
In instances where the application has not been assigned to the device, it can either be assigned and the direct deployment method used as described above or the device can be tagged and a Smart Group configured to build membership based on the tagged devices:
Tag ID’s can be obtained from the Workspace ONE UEM Console by hovering over the tag.
- Navigate to Settings > Devices & Users > Advanced > Tags.
- Hover over the tag, then view the Tag ID in the URL.

Disk Space Remediation
Devices reporting low disk space can be remediated in a few different ways:
- Replace with larger disk
- Free up disk space by deleting known temporary files
- Informing the user that their device is low on disk space and that they should attempt to free up some space
- Raising a helpdesk ticket to obtain assistance
Other than the first option of replacing the disk, Workspace ONE UEM has the ability to push an application/script which can delete known large temporary files, it can also send an email to the user informing them of the amount of space that needs to be freed up or it can automatically open a helpdesk support request to obtain assistance in having the issue remedied.
All these actions can be carried out as Workspace ONE Intelligence automations using a Workspace ONE UEM sensor to report disk space.
os_disk_free_space.ps1 Sensor Sample also hosted on GitHub.
# Returns C: Drive Available Free Space (Bytes)
# Return Type: Integer
# Execution Context: System
$cdrive=Get-WmiObject -Class Win32_logicaldisk | where DeviceID -eq "C:" | Select-Object -Property "FreeSpace"
write-output $cdrive.FreeSpace
Click to copy

Windows Update for Business Feature Update Approval
Device Reporting of Updates
Windows Feature Updates are released twice per year; however, a new cumulative version of the update is released every month. These Cumulative Updates contain the Feature Update and any subsequent monthly Cumulative Updates released since the Feature Update’s initial release date. This simplifies the update process since it means that after updating, the device is immediately up-to-date and does not require previously released patches.
The Workspace ONE UEM console reports all versions of a Feature Upgrade reported by the managed devices in your organization.
When approving a Feature Update for distribution to devices, it is recommended to approve the latest version of the update for all devices. This means that once testing is completed for a Feature Update, it may be necessary to test the latest (current) cumulative update on a device that has already been updated with the Feature Update. Since no new features are introduced, testing should be limited to cover the delta between the tested Feature Update and the newly approved Feature Update.
The screenshot below shows all Feature Updates and their published date that have been reported by all enrolled devices.

Clicking on the “View” link shows devices that have reported this update, along with the current status. Older updates that report no devices are standard since the new updates replace those updates.
Approvals using the Workspace ONE
Approving All Devices without any Exclusions
You can follow the standard approval process, where updates are assigned to a Smart Group representing a distribution ring. The assigned devices receive the go-ahead to download the update at the next Windows Update scan.
Excluding Specific Devices, Models, or Users
Windows Updates are approved by assigning them to a set of Smart Groups, for example, Ring0 through Ringn. The Smart Groups, by default, include all devices irrespective of device models. A new set of Smart Groups can be created to include only the compatible models for the given patch. The example below shows a Smart Group for Ring0, which can include only the applicable models which are compatible. Once created, these Smart Groups can be used instead of the regular Smart Groups. When the issues related to the patch are remediated, the Smart Group can be updated to include the missing devices, or the patch can be assigned to the regular Ring0 through n Smart Groups.

Excluding Devices with a Specific Application
The Workspace ONE UEM Console does not currently allow the approval of Windows Updates based on the presence of a specific application or application version on the device. To achieve this, we need to leverage Workspace ONE Intelligence, which is covered in the next section.
Starting with Workspace ONE UEM 2011, VMware released the Freestyle Orchestrator Tech Preview, enabling the ability to target devices based on attributes like app or app version.
Excluding Devices Running Specific OS Branches/Versions
Windows Updates are approved by assigning them to a set of Smart Groups (Ring0 through Ringn). The Smart Groups, by default, include all devices irrespective of its current OS version. A new set of Smart Groups can be created to include only the compatible OS versions. The example below shows a Smart Group for Ring0 with all devices except devices running Windows 10.0.18362 and Windows 10.0.18363. Once created, these Smart Groups can be used instead of the regular Smart Groups. When the issues related to the patch are remediated, the Smart Group can be updated to include the missing devices, or the patch can be assigned to the regular Ring0 through n Smart Groups.

Approvals using Workspace ONE Intelligence
For more details on leveraging Workspace ONE Intelligence, refer to the Automating Patch Remediation with Workspace ONE Intelligence tutorial.
Smart Group Based
Workspace ONE Intelligence automation can be used to tag devices that are eligible for updates based on multiple Sensor data points to determine if the device is eligible for the upgrade. If the device is allowed to upgrade, then the first character of the device GUID (16 in total) is used to push the upgrade in a distribution ring model. Workspace ONE Intelligence will check the criteria, then apply the corresponding tag, and then Workspace ONE UEM approves the update to the device based on that tag, which is tied to the Smart Group. This method allows for a more phased approach to distributing the update instead of merely assigning all the devices to one eligible Smart Group.

Tag and Smart Group configuration details should look like the following:
Tag Name (ID) | Smart Group Name |
Win10_1909_Upgrade_Ring_0 (10026) | Win10_1909_Upgrade_Ring_0 |
Win10_1909_Upgrade_Ring_1 (10027) | Win10_1909_Upgrade_Ring_1 |
Win10_1909_Upgrade_Ring_2 (10028) | Win10_1909_Upgrade_Ring_2 |
Win10_1909_Upgrade_Ring_3 (10029) | Win10_1909_Upgrade_Ring_3 |
Win10_1909_Upgrade_Ring_4 (10030) | Win10_1909_Upgrade_Ring_4 |
Win10_1909_Upgrade_Ring_5 (10031) | Win10_1909_Upgrade_Ring_5 |
Win10_1909_Upgrade_Ring_6 (10032) | Win10_1909_Upgrade_Ring_6 |
Win10_1909_Upgrade_Ring_7 (10033) | Win10_1909_Upgrade_Ring_7 |
Win10_1909_Upgrade_Ring_8 (10034) | Win10_1909_Upgrade_Ring_8 |
Win10_1909_Upgrade_Ring_9 (10035) | Win10_1909_Upgrade_Ring_9 |
Win10_1909_Upgrade_Ring_10 (10036) | Win10_1909_Upgrade_Ring_10 |
Win10_1909_Upgrade_Ring_11 (10037) | Win10_1909_Upgrade_Ring_11 |
Win10_1909_Upgrade_Ring_12 (10038) | Win10_1909_Upgrade_Ring_12 |
Win10_1909_Upgrade_Ring_13 (10039) | Win10_1909_Upgrade_Ring_13 |
Win10_1909_Upgrade_Ring_14 (10040) | Win10_1909_Upgrade_Ring_14 |
Win10_1909_Upgrade_Ring_15 (10041) | Win10_1909_Upgrade_Ring_15 |
Automation configuration details should look like the following:
Automation Name | Device GUID Begins With | Tag ID |
---|---|---|
Win10 Approve 1909 Ring 0 | 0 | 10026 |
Win10 Approve 1909 Ring 1 | 1 | 10027 |
Win10 Approve 1909 Ring 2 | 2 | 10028 |
Win10 Approve 1909 Ring 3 | 3 | 10029 |
Win10 Approve 1909 Ring 4 | 4 | 10030 |
Win10 Approve 1909 Ring 5 | 5 | 10031 |
Win10 Approve 1909 Ring 6 | 6 | 10032 |
Win10 Approve 1909 Ring 7 | 7 | 10033 |
Win10 Approve 1909 Ring 8 | 8 | 10034 |
Win10 Approve 1909 Ring 9 | 9 | 10035 |
Win10 Approve 1909 Ring 10 | A | 10036 |
Win10 Approve 1909 Ring 11 | B | 10037 |
Win10 Approve 1909 Ring 12 | C | 10038 |
Win10 Approve 1909 Ring 13 | D | 10039 |
Win10 Approve 1909 Ring 14 | E | 10040 |
Win10 Approve 1909 Ring 15 | F | 10041 |
Sensors | Automation | Tags | Smart Groups | Assign | |
Detect Eligibility for Windows 1909 update | Win10 Approve 1909 Ring 0 | Win10 Upgrade 1909 Ring 0 | Win10 Upgrade 1909 Ring 0 | Assign updates to Smart Groups as needed | |
Win10 Approve 1909 Ring 1 | Win10 Upgrade 1909 Ring 1 | Win10 Upgrade 1909 Ring 1 | |||
Win10 Approve 1909 Ring 2 | Win10 Upgrade 1909 Ring 2 | Win10 Upgrade 1909 Ring 2 | |||
Win10 Approve 1909 Ring 3 | Win10 Upgrade 1909 Ring 3 | Win10 Upgrade 1909 Ring 3 | |||
Win10 Approve 1909 Ring 4 | Win10 Upgrade 1909 Ring 4 | Win10 Upgrade 1909 Ring 4 | |||
Win10 Approve 1909 Ring 5 | Win10 Upgrade 1909 Ring 5 | Win10 Upgrade 1909 Ring 5 | |||
Win10 Approve 1909 Ring 6 | Win10 Upgrade 1909 Ring 6 | Win10 Upgrade 1909 Ring 6 | |||
Win10 Approve 1909 Ring 7 | Win10 Upgrade 1909 Ring 7 | Win10 Upgrade 1909 Ring 7 | |||
Win10 Approve 1909 Ring 8 | Win10 Upgrade 1909 Ring 8 | Win10 Upgrade 1909 Ring 8 | |||
Win10 Approve 1909 Ring 9 | Win10 Upgrade 1909 Ring 9 | Win10 Upgrade 1909 Ring 9 | |||
Win10 Approve 1909 Ring 10 | Win10 Upgrade 1909 Ring 10 | Win10 Upgrade 1909 Ring 10 | |||
Win10 Approve 1909 Ring 11 | Win10 Upgrade 1909 Ring 11 | Win10 Upgrade 1909 Ring 11 | |||
Win10 Approve 1909 Ring 12 | Win10 Upgrade 1909 Ring 12 | Win10 Upgrade 1909 Ring 12 | |||
Win10 Approve 1909 Ring 13 | Win10 Upgrade 1909 Ring 13 | Win10 Upgrade 1909 Ring 13 | |||
Win10 Approve 1909 Ring 14 | Win10 Upgrade 1909 Ring 14 | Win10 Upgrade 1909 Ring 14 | |||
Win10 Approve 1909 Ring 15 | Win10 Upgrade 1909 Ring 15 | Win10 Upgrade 1909 Ring 15 | |||
Monitor Deployment using Workspace ONE Intelligence |
Automation Based
Once confidence is gained in the update process, a more hands-off approach can be leveraged for approving Feature Updates. A Workspace ONE Intelligence automation workflow can be used to automatically approve updates for devices once the device has been deemed eligible for the update. This simplifies the management of the deployment process, but the tradeoff is reduced control around which devices and how many will be upgraded. The previous method might be preferred in larger environments since the administrators have more control over the actual assignments.
The screenshot below shows the sample automation to approve the Feature Update using the Sensor discussed previously.
The revision ID for the feature update is obtained from within the Workspace ONE UEM Console by hovering over the patch link at either the Device Updates page or the actual device details page under the updates section:

Windows Update “Kill Switch”
Since Microsoft can force updates to a device and the deferral/pause functionality allows only for a small window to remediate issues, another method is needed to “Turn Off” Windows updates when remediation cannot be completed within the deferral or pause window.
Microsoft doesn’t provide an MDM-managed method to achieve this; however, one way of addressing this is to stop and deactivate the Windows Update service. With this service deactivated, Windows will be unable to detect, download, or install any Windows Updates. This can be achieved using a PowerShell script deployed to the device. This should be used as a temporary last resort since it will prevent any Critical or Security patching while the service is not running.
To lock a device on a feature update version, refer to the Target Release Version section.
Windows Update Delivery Optimization
Delivery Optimization Options
Delivery optimization can be configured as part of the Windows Update profile and has the following configuration options.
If there are missing options in the Windows Update profile, consider deploying a custom settings profile.

Setting | Value | Description |
Allowed Peer-to-Peer Method | Use Peers On Same NAT only (Default) (CSP value = 1) |
Default mode that enables peering behind the same private network (NAT). Devices with the same public IP, as determined by the Delivery Optimization cloud service, will attempt to connect to peers using their private subnet IP. |
Use Peers on Same Local Network Domain (CSP Value = 2) |
Enables peering across the same AD site (if it exists) or the same domain. Note: By default, peering will occur across NATs. If you wish to limit peering, leverage the Group ID option. | |
Use Internet Peers (CSP Value = 3) |
Enables using Internet peer sources. | |
Simple Download Mode (CSP Value = 99) | Enables simple download mode without peering. Devices will not reach out to the Delivery Optimization cloud service. | |
Bypass Mode (CSP Value = 100) |
Bypasses the use of Delivery Optimization and leverages BITS, instead. This only is only used if you plan to leverage BranchCache and are using WSUS. | |
Limit Peer Usage to Members with the Same Group ID | Limit Do Not Limit (Default) Specify a GUID for the Group ID. |
A GUID value can be provided to assign Group ID’s to devices. Devices peer with other devices that have the same Group ID assigned. This is provided at a best effort and should not be relied on for authentication of identity. |
VPN Peer Caching | Allowed Now Allowed (Default) |
Enable to allow devices to participate in Peer Caching while connected to a VPN. |
For more details on the various Delivery Optimization options, refer to Policy CSP – DeliveryOptimization or Delivery Optimization for Windows 10 Updates.
Windows OS Patching Profile Configuration
Profile Configuration
The following table documents an example of the Windows OS updates profile configuration settings used for the example deployment used throughout this document. There are a total of six profiles with different deferral periods for the example used throughout this tutorial.

Windows Update Profile Settings | |||||
Branching and Deferral | |||||
Windows Update Service | Microsoft Update Service | ||||
Update Branch | Semi-Annual Channel | ||||
Insider Builds | Not Allowed | ||||
Defer Feature Updates (Days) | 0 | ||||
Pause Feature Updates | Disable | ||||
Defer Quality Updates (Days) | 0 | ||||
Pause Quality Updates | Disable | ||||
Update Installation Behavior | |||||
Automatic Updates | Install automatically, user scheduled restart | ||||
Active Hours Maximum | 12 | ||||
Active Hours Start time | 8 AM | ||||
Quality Updates Restart Deadline (Days) | 5 | ||||
Feature Updates Restart Deadline (Days) | 30 | ||||
Auto-Restart Notification (Minutes) | 120 | ||||
Auto-Restart Required Notification | User Dismissal | ||||
Quality Updates Engaged Restart (Days)** | 2 | ||||
Feature Updates Engaged Restart (Days)** | 2 | ||||
Quality Updates Engaged Snooze (Days)** | 3 | ||||
Feature Updates Engaged Snooze (Days)** | 3 | ||||
Scheduled Auto-Restart Warning (Hours) | 4 | ||||
Schedule Imminent Auto-Restart Warning (Minutes) | 60 | ||||
Update Policies | |||||
Allow Public Updates | Allowed | ||||
Allow Microsoft Updates | Allowed | ||||
Update Scan Frequency (Hours) | 8 | ||||
Dual Scan | Disable | ||||
Exclude Windows Update Drivers from Quality Updates | Enabled | ||||
Install Signed Updates from 3rd Party Entities | Not Allowed | ||||
Mobile Operator App Download Limit | Do Not Ignore | ||||
Mobile Operator Update Download Limit | Do Not Ignore | ||||
Administrator-Approved Updates | |||||
Require Update Approval | Enable | ||||
Auto-Approved Updates | Not Allowed* | ||||
Delivery Optimization | |||||
Peer-to-Peer Updates | Allowed | ||||
Allowed Peer-to-Peer Method | Peers on the same NAT only | ||||
Limit Peer Usage to Members with the Same Group ID | Do Not Limit | ||||
VPN Peer Caching | Not Allowed | ||||
Minimum Battery Required for Peer Uploads (%) | 40 | ||||
Memory | |||||
Maximum Allowed Cache Size | 10 | ||||
Maximum Cache Size that Delivery Optimization Can Use (%) | 20 | ||||
Maximum Time Each File is Held in the Delivery Optimization Cache (Seconds) | 259200 | ||||
Minimum Disk Size for Device to Use Peer Caching | 200 | ||||
Minimum RAM for Device to Use Peer Caching | 4 | ||||
Minimum Content File Size that Can Use Peer Caching | 4 | ||||
Drive Location Used for Peer Cache | %SystemDrive% | ||||
Network | |||||
Maximum Upload Bandwidth that a Device Will Use Across All Concurrent Upload Activity (KB/second) | 20,000 | ||||
Maximum Download Bandwidth that a Device Will Use (KB/second) | 0 | ||||
Maximum Download Bandwidth as a Percentage of Total Available (%) | 0 | ||||
Minimum QoS for Background Downloads (KB/second) | 500 | ||||
Monthly Upload Data Cap (GB) | 20 |
*Updates of certain categories may circumvent administrator approval.
** Microsoft does not recommend using this setting and is currently ignored by Workspace ONE UEM.
Target Release Version CSP using Custom Settings Profile
The following custom setting enables administrators to specify which Windows version they would like their device(s) to move to and/or stay on until they reach the end of service or reconfigure the policy. Windows Quality Updates continue to apply to these devices. The value in the <Data>
element specifies the version that the devices won’t upgrade past. The sample below uses 1909, meaning the devices are allowed to upgrade to 1909 and stay there until it is changed.
<Replace>
<CmdID>576f2a6a-a856-4d2d-a4f1-fefd2bcbe79d</CmdID>
<Item>
<Target>
<LocURI>./Vendor/MSFT/Policy/Config/Update/TargetReleaseVersion</LocURI>
</Target>
<Meta>
<Format xmlns="syncml:metinf">chr</Format>
</Meta>
<Data>1909</Data>
</Item>
</Replace>
Click to copy
Refer to the blog, Windows 10 Feature Upgrades Full Control, and the Target Release Version reference for more details.
Warning: This does not work for the 20H2 version at the time of publishing this tutorial. You can refer to the above links for updates. This is the first version to be alphanumeric, but the MDM-framework is still looking for all numerical values; for example, 1809, 1903, or 1909. Microsoft is aware of this issue and will be fixing this in a cumulative update soon. It is recommended holding off on going to this version until they patch the Update/TargetReleaseVersion CSP. If you need to get on it early for dev or test devices, then you will need to remove this CSP altogether and instead use deferrals and set them to zero.
Device Restart Flow and Prompts
Introduction
There are specific configuration items that determine the end-user experience when a device restart is required. These settings are under the Update Installation Behavior section of the Windows Updates profile.

Setting | Details |
---|---|
Quality Updates Auto Restart Deadline (Days) | Deadline in days for the device to restart automatically and silently outside of Active Hours. The system reboots on or after the specified deadline, and the reboot is prioritized over any configured Active Hours.Default: 7 days Supported values: 2-30 days |
Feature Updates Auto Restart Deadline (Days) | |
Auto-Restart Notification (Minutes) | Amount of time before displaying an auto-restart reminder notification to the end-user.Default: 15 minutes Supported Values: 15, 30, 60, 120, 240 minutes |
Auto-Restart Required Notification | Specifies how auto-restart notifications are dismissed.Supported Values: Auto Dismissal (Default), User Dismissal |
Quality Updates Engaged Restart Deadline (Days) | Deadline in days before auto-scheduling and executing a pending restart outside of Active Hours. The auto-restart transitions to engaged restart (pending user schedule), then auto executed within the specified period.Default: 14 days Support Values: 2-30 days |
Feature Updates Engaged Restart Deadline (Days) | |
Quality Updates Engaged Restart Snooze Deadline (Days) | Specifies the number of days a user can snooze engaged restart notifications.Default: 3 days Support Values: 1-3 days |
Feature Updates Engaged Restart Snooze Deadline (Days) | |
Scheduled Auto-Update Warning (Hours) | Specifies the amount of time before showing the auto-restart warning reminder notifications.Default: 4 hours Supported values: 2, 4, 8, 12, or 24 hours |
Schedule Imminent Auto-Restart Warning (Minutes) | Specifies the amount of time before showing the auto-restart imminent warning notifications.Default: 15 minutes Supported values: 15, 30, 60 minutes |
Refer to the Policy CSP – Update reference or Policies for update compliance, activity, and end-user experience for more information on the configuration options.
Devices attempt to restart outside of active hours unless/until a user specifies an alternate date/time. If the device could not restart within the auto-restart deadline, the device will force a restart, which may occur during active hours. The user receives at least two notifications informing them of the pending reboot.
End-User Prompts
Understanding how the end-users are notified and impacted allows for informed decisions to be made regarding how to configure the Update Installation Behavior section of the Windows Update profile. The Workspace ONE UEM’s Windows Update profile forces the admin to configure all settings and does not allow for excluding device restart options. The diagram shows a high-level flow of what the end-user can expect when an update is applied that requires a device reboot. If using the profile, Restart Deadlines Defined is always true; if you need to customize the restart behavior, you can create a custom settings profile. VMware is continuously updating the product to ensure that the best admin and end-user experiences are achievable.

For more information, refer to enforcing compliance deadlines for updates.
Windows Updates Day-2 Operations
Monthly Quality Updates
If monthly Quality Updates are configured to require Admin Approval, they will need to be approved after they have been successfully tested following standard testing practices.
- Navigate to Resources > Device Updates in the Workspace ONE UEM Console, then select the appropriate update.
- Click the Assign button to assign the update to appropriate Smart Groups. Smart Group selection will depend on the number of devices to be targeted and will be a phased approach building up the number of targeted devices by adding more Ring Smart Groups over time until all 16 Ring groups have been added.
Be sure to take advantage of the Classification filters, search list, and layout options, as well as to select multiple updates to assign at the same time.

- Select your assignment groups.
- Click Add.
Devices will download and install the update at the next Windows Update scan.
NOTE: Updates reported by devices are the updates that they can “see” via Windows Update for Business. If an update is superseded by a subsequent release, devices will no longer see the old version of the update. For the newer version of the update to be delivered to devices, this update must also be approved.
Monitor the deployment of this patch using a custom Dashboard Widget in Workspace ONE Intelligence. Within the Windows Quality Updates dashboard, create a new widget for that month’s patches. Add all the patches that will be deployed that month to the widget as follows:
Installation Status Widget for 2020-08 Patches

Widget configuration with KB Title of all patches to monitor added to a single filter line. OS version ensures that stats are only reported to devices that the patch is eligible for.

Annual Feature Updates
If Feature Updates are configured to require Admin Approval, then they will need to be approved after they have been successfully tested following standard testing practice. Devices that are eligible for the update will be tagged during the evaluation process, which will assign them to one of 16 Smart Groups based on their positive eligibility and the first character of the Device GUID.
1. Selecting the Feature Update

- Go to Devices > Device Updates and select the appropriate update.
- Click Assign.
Pro Tip: It is recommended that the latest version of the update be used since it will contain the most recent cumulative updates and will eventually be made available to all devices via WUfB, even if not currently showing as available. Filters and search can be used to locate the appropriate update where needed.
1.1. Feature Update Details
You can see additional information for each update by clicking the actual update to confirm the correct KB ID.

1.2. Add Assignment

Assign the update to the appropriate Smart Group(s), then save your assignments.
2. Monitoring with Workspace ONE Intelligence
Use Intelligence Dashboards to Monitor devices tagged for eligibility to help determine Smart Groups to be targeted.
2.1. Eligibility Status Widget

2.2. Widget Configuration

Monitor actual deployment status using dashboards like the quality updates dashboard shown above.
OEM Updates
Introduction
Workspace ONE UEM integrates with Dell Client Command Suite to enhance the modern device management of Dell Enterprise client systems. With the integration of Dell Command | Monitor, Workspace ONE UEM reports on custom system properties and reports and sets BIOS attributes. The integration with Dell Command | Update allows for OEM updates to be configured and applied on the device, such as applying driver, firmware, and BIOS updates to the device. This exercise helps you to configure these integrations in the Workspace ONE UEM console. In this exercise, you upload and deploy the Dell Command | Update app, configure the corresponding profile, and view the OEM Updates in the console. The steps are sequential and build upon one another, so make sure that you complete each step before going to the next step.
Integrate Workspace ONE UEM with Dell Client Command Suite
Integrating Workspace ONE UEM with Dell Client Command Suite enhances the information collected from enrolled devices, and allows you to configure device BIOS settings and to report on installed OEM updates. To watch a video demonstrating these features, click Dell Client Command Suite Integration with Workspace ONE UEM or click the video itself.
Prerequisites
Before you can perform the procedures in this exercise, you must satisfy the following requirements. For more information, see the VMware Workspace ONE UEM Documentation.
- Windows Pro or Enterprise device, enrolled in Workspace ONE UEM. For more information, compare Windows 10 editions, or contact a Microsoft representative.
- Meet the prerequisites for Dell Command | Update
- Supported Dell Enterprise client system: Dell OptiPlex™ desktop devices, Dell Precision Workstation™ desktop and laptop devices, Dell Latitude™ laptop devices, and Dell XPS Notebook™ devices.
For more information about supported Dell systems, see the Dell product documentation.
Adding the Dell Command | Update Software
Before you deploy the OEM Updates profile in the Workspace ONE UEM console, first upload and deploy the Dell Command | Update software to your managed Dell Enterprise client systems.
1. Upload the Dell Command | Update Software

In the Workspace ONE UEM console:
- Select Apps & Books.
- Select Add > Application File.
1.1. Download Software

- First, download the latest version of the Dell Command | Update software.
- Return to the Workspace ONE UEM console and select Upload.
Important: Dell Command | Update 3.0 or any of the Universal Windows Platform (UWP) versions are not supported with Workspace ONE UEM.
Be sure to select the link Windows 32 and 64-bit version for Microsoft Windows 7, 8, 8.1 and 10 to download the correct version of Dell Command | Update.
1.2. Browse

- Select Browse...
Before moving on to the next step, we will want to use the DellCommandUpdate.msi
and not the Dell-Command-Update_VERSION.EXE
. To extract the MSI needed for the next step, follow these steps:
1.3. Select Dell Command | Update MSI

- Select the
DellCommandUpdate.msi
. - Click Open.
1.4. Save Dell Command | Update EXE

- Click Save.
1.5. Continue to Add Application

- Keep the default values and click Continue.
2. Configure the Details Tab

- Select 64-bit for the Supported Processor Architecture.
- Verify the relevant processor architecture for your device.
Note: When uploading MSI
files, all possible fields are automatically pre-populated with all of the metadata. However, for ZIP
and EXE
packages, you must enter a Name and some of the Deployment options.
3. Configure Deployment Options

- Select the Deployment Options tab.
3.1. Define When to Install

Configure the details about requirements to install the application. This example uses suggested values which you can customize for your environment.
- Enter
150
for the Disk Space Required, which specifies the amount of disk space the device must have available to install the application. - Select MB for the Units of the Disk Space Required.
- Enter
25
for the Device Power Required, which specifies the battery power, in percentage, that the device must have to install the application. - Enter
500
for the RAM Required, which specifies the amount of RAM the device must have to install the application. - Enter MB for the Units of the RAM Required.
4. Add the Application Icon

- Select the Images tab.
4.1. Open Icon Settings

- Select the Icon tab.
- Click the area labeled Click or drag files here.
4.2. Select the Icon File

- Navigate to the folder containing your Dell logo file.
- Select your Dell logo image.
- Click Open.
5. Assign and Publish
5.1. Save & Assign

- Click Save & Assign.
5.2. Assign Dell Command | Update

- Name your Distribution.
- Select Dell for the Assignment Groups, or your custom created Assignment Group for your Dell devices.
- Select Auto for App Delivery Method.
- Click Create.
5.3. Save

- Click Save.
5.4. Publish

- Click Publish.
6. Confirm the Application Appears in the List View

In the Internal Applications List View, confirm that the Dell Command | Update application is displayed.
You have successfully added the Dell Command | Update app to Workspace ONE UEM for deployment.
Configuring the OEM Updates Profile
Profiles allow you to modify how the enrolled devices behave. This section helps you to configure an OEM Updates profile that you will verify applied to the device. When you push the OEM Updates profile to the device, this configures Dell Command | Update with the respective settings and prevents the end-user from modifying the settings on their devices. Users can still run scans and apply updates; however, all of the settings are deactivated for modifications.
1. Add a Profile
First, add a Windows profile.
1.2. Add a Windows Profile

- Select the Windows icon.
- Note: Make sure that you are selecting Windows and not Windows Rugged.
1.3. Add a Windows Desktop Profile

- Select Windows Desktop.
1.4. Select Context - Device Profile

- Select Device Profile.
2. Configure Profile Settings
Configure the profile general settings and OEM updates settings.
2.1. Define General Settings

- Select General if it is not already selected.
- Enter a profile name in the Name text box, for example,
Windows 10 - OEM Updates
. - Enter a description in the Description text box, for example,
Configures Dell Command | Update
. - Click within the Assigned Groups field. This will pop up the list of created Assignment Groups. Select the All Devices Assignment Group.
Note: You may need to scroll down to view the Assigned Groups field.
Note: You do not need to click Save & Publish at this point. This interface allows you to move around to different payload configuration screens before saving.
2.2. Open the OEM Updates Payload

- Scroll through the payload section on the left until you see the OEM Updates payload.
- Select the OEM Updates payload.
- Click the Configure button to begin configuring the payload settings.
Note: When initially setting a payload, a Configure button will show to reduce the risk of accidentally setting a payload configuration.
2.3. Configure OEM Updates Settings

Configure the Schedule and Level sections of the OEM Updates payload that match your organizational requirements. The following are some sample values:
- Select Weekly to set the interval used to Check for Updates. Supported values are Never, Weekly, and Monthly.
- Select Friday for the Day of the Week to check for updates.
- Set the Time to 10:00 PM. This sets the time of day to check for updates.
- Select Scan Download Notify for the Update Behavior. Supported values are Scan Notify, Scan Download Notify, or Scan Notify Apply Reboot.
- Scan — Scans for updates.
- Notify — Notifies the user that updates are available.
- Download — Downloads any available updates.
- Apply — Installs any available update.
- Reboot — Reboots the device according to the Reboot Delay configuration.
- Select Manual Reboot for the Reboot Delay. Supported values are Manual Reboot, 5, 15, or 60 Minutes.
- Select the Level of updates to scan for while checking for updates; any deactivated value will be ignored while scanning and applying updates.
Note: Configure the settings to match your organizational requirements. For more information about these options, see Configure the OEM Updates Profile (Windows Desktop) in the VMware Workspace ONE UEM Documentation.
Warning: For certain older versions of Dell Command | Update, you must close Dell Command | Update for the scheduler to check for updates during the scheduled interval.
Note: Dell Command | Update checks for updates at random intervals within 30 minutes of the time set in the Time field.
2.4. Configure Update Type Settings

Configure the Update Type section of the OEM Updates payload that matches your organizational requirements.
- Using the scroll bar on the right, scroll down to the Update Type section.
- Choose to enable or disable the different Update Types in this section of the profile; the default values are shown in the screenshot.
Note: Configure the settings to match your organizational requirements. For more information about these options, see Configure the OEM Updates Profile (Windows Desktop) in the VMware Workspace ONE UEM Documentation.
2.5. Configure Device Categories Settings

Configure the Device Categories section of the OEM Updates payload that match your organizational requirements.
- Using the scroll bar on the right, scroll down to the Device Categories section.
Note: Configure the settings to match your organizational requirements. For more information about these options, see Configure the OEM Updates Profile (Windows Desktop) in the VMware Workspace ONE UEM Documentation.
2.6. Configure Update Source Location


The Update Source Location allows the user to specify where to access the update information. By default, Default Source Location is selected which downloads and installs the updates from downloads.dell.com, shown above as Dell Update/Support Site. To add another Source Location:
- Click Add New.
- Enter the location of the
catalog.xml
file, which can be a local directory, network share, or public URL which points to the XML file. - Change the priority of the Update Source Location, if needed. If the catalog file loads successfully, Dell Command | Update uses the first source location. Dell Command | Update does not load each source location that is listed and aggregates the contents. Dell Command | Update does not check for signatures on any source location that is not available on dell.com.
- Click Save & Publish.
Note: Dell highly recommends applying the latest Dell Command | Update during your next scheduled update cycle. Updates contain feature enhancements or changes that improve the reliability and availability of your system.
Pro Tip: You can use Dell Command | Cloud Repository Manager to create a repository of system updates for Dell commercial client devices and help further streamline update efforts. Dell Command | Cloud Repository Manager is a cloud-based tool available in the Dell TechDirect portal, which can be accessed here. This tool allows users to build, manage, and share customized catalogs of the latest BIOS, driver, firmware, and application updates. These catalogs help to streamline the process of finding and determining system updates needed to keep commercial client devices ready and secure.
If a custom repository is created with Dell Command | Cloud Repository Manager, update the Update Source Location appropriately, pointing to the location of the custom catalog file that was created and downloaded.
2.7. Publish the OEM Updates Profile

- Click Publish.
Validating OEM Updates
When you push the OEM Updates profile to the device, it configures Dell Command | Update with the respective settings and prevents the end-user from modifying the settings on their devices. Users can still run scans and apply updates; however, all of the settings are disabled for modifications. In this section, you review the results of your integration on the device and in the console.
1. Select a Managed Device
First, select your Dell managed device.
1.2. Select Managed Device

- Click the friendly name of one of your Dell managed devices.
2. Validate App and Profile Applied
Confirm that the applications and profiles installed successfully.
2.1. Verify Apps and Profiles Installed
- You can quickly verify that the profiles and apps deployed to your device.
- The next steps review each of these configurations.
2.2. Validate the Windows 10 - OEM Updates Profile Installed

- Select the Profiles tab.
- Validate that the Windows 10 - OEM Updates profile was successfully installed before continuing.
3. Check OEM Updates and Configurations
In this section, confirm the OEM Updates settings and Dell Command | Update settings.
3.1. Check Applied OEM Updates

Workspace ONE UEM queries the device for all of the applied OEM Updates installed using Dell Command | Update.
- Select the More tab, then select OEM Updates.
- Click Intel HD Graphics driver, or any other update to view more details about that update.
3.2. OEM Updates Details

- Workspace ONE UEM reports on the OEM Updates and details such as Release ID, Version, Criticality, Update Type, Category, and the Date Applied.
- Click X to close the pop-up window.
3.3. Dell Command | Update History

- On your Dell enterprise managed device in the Dell Command | Update software, the Update History should also match the details in the Workspace ONE UEM console.
3.4. Dell Command | Update Settings

- Click the settings icon.
- Click Update Filter.
Note that the settings are unavailable (dimmed) and set to match the profile configuration options.
Important: If you set a scheduled time which does not have 00
for minutes (for example, ##:00
) then Dell Command | Update displays a blank value for Select the time field. Regardless of the blank value, the correct time is set on the device—you can validate by exporting the setting and comparing the scheduled minutes field.
3.5. OEM Updates Consolidated View

Workspace ONE UEM provides a consolidated view of the deployed OEM Updates to your managed devices. You can filter the updates by Type and click any of the updates to see which devices have that update installed.
- Select Devices.
- Select Device Updates.
- Select OEM Updates.
You have successfully integrated Workspace ONE UEM with Dell Command | Update, and validated the settings are applied and OEM Updates are reported to the Workspace ONE UEM console.
Summary and Additional Resources
Conclusion
This tutorial shows you how to use Workspace ONE UEM to manage Windows 10 updates through a series of exercises.
Changelog
The following updates were made to this guide:
Date | Description of Changes |
---|---|
2021-07-20 | Added the Diagnostic & Usage Telemetry Data section. |
2021-01-12 |
Content overhaul of entire tutorial, including control, restriction, readiness, approval, and delivery of updating and patching processes, migration methodology, and Day-2 operations:
|
2019-04-01 | Original operational tutorial published. |
About the Authors
This tutorial was written by Josué Negrón, EUC Staff Architect, End-User-Computing Technical Marketing, VMware, and Hannah Jernigan, Technical Writer, End-User-Computing Technical Marketing, VMware, with appreciation and acknowledgment for considerable contributions from the following subject matter experts:
- Ryan Kremkau, Author, Product Line Manager, VMware
- Glyn Dobson, Author, Consultant, VMware
- Criselda Abarquez, Co-Author, Senior Systems Engineer, VMware
- Arun BalaJi Giridharan, Co-Author, Senior Consultant, VMware
- Brooks Peppin, Contributor, Senior Solutions Architect, VMware
- Darren Weatherly, Contributor, Senior Technical Marketing Architect, VMware
- Mike Nelson, Contributor, Senior Solutions Architect, VMware
- Saurabh Jhunjhunwala, Contributor, EUC Customer Success Architect, VMware.
Feedback
Your feedback is valuable.
To comment on this tutorial, contact VMware End-User-Computing Technical Marketing at euc_tech_content_feedback@vmware.com.
Additional Resources
For more information about Windows Modern Management with Workspace ONE, you can explore the following resources:
Getting Started with Windows Modern Management
- Creating a Windows Virtual Machine to Test Workspace ONE
- Planning Your Windows Deployment: Workspace ONE Operational Tutorial
Windows Onboarding
- Onboarding Windows Devices Using Command-Line Enrollment: Workspace ONE Operational Tutorial
- Enrolling Windows Devices Using Azure AD: Workspace ONE UEM Operational Tutorial
- Drop Ship Provisioning: Workspace ONE Operational Tutorial
Windows Security and Policy Management
- Windows Modern Management Security Design and Implementation
- Understanding Windows Group Policies: Workspace ONE Operational Tutorial
- Deploying VMware Workspace ONE Tunnel: Workspace ONE Operational Tutorial
- Enabling BitLocker Encryption to Remote Windows Devices: Workspace ONE Operational Tutorial
Windows Application Management
Windows OS Patching
Windows Troubleshooting
Appendix
FAQ
The following are Frequently Asked Questions about Windows Update:
Where do the updates shown in the Workspace ONE UEM Console come from?
- They come directly from the managed-devices in your organization. They do not come directly from Microsoft Windows Update servers.
Why don’t specific updates show up in the Workspace ONE UEM Console?
- If a device does not see an update, neither will the console. This also extends to things like localized or OS-specific updates that may not apply to any of the devices in your environment.
Why don’t the devices see the updates from Microsoft?
- Devices have a scan frequency value, which is configurable in Workspace ONE from 1-22 hours. The default value is 22 hours. If Microsoft releases an update, but your devices haven’t scanned yet, it won’t appear on the device, which means it won’t show in the console.
The devices scan and see updates, but why do they still not show up in the Workspace ONE UEM Console?
- The console communicates (checks-in) with devices at specific intervals (samples) unique to each type of data they are sampling. The Update Sample is set to 1 day (24 hours) and is not configurable to a lower value. Even if the device sees the update, it can be up to 24 hours before the console sees it from a device.
The Workspace ONE UEM Console now shows the update, and I have approved (or it was auto-approved); some devices are installing it right away while others are not; why?
- Not all devices have necessarily seen the update yet. While you may have approved it for all devices, the fact it shows in the console only indicates that at least one device has seen it and is ready to install it, given its approval.
What happens if I approve an update, but the device has not scanned and seen it from Microsoft yet?
- This is ideal. Once seen, the device immediately downloads and installs it because you have already approved it. If you were to delay approvals and the device scanned, it would not be allowed to download and would have to wait until the next scan (up to 22 hours) before it can scan again.
I approved the updates, the device discovered/downloaded/installed it, but the Workspace ONE UEM Console indicates it is in a state other than the installed status; why?
- The Update Sample has not occurred yet. If the device has fully completed all the steps (downloads, installs, reboots) but has not been sampled by the console, then whatever the last status during the sample was still the indicated status.
What is the maximum amount of time it should take from approving an update to seeing it in “Installed” status in the console?
- If you approved an update for all devices, it is likely that some have not yet discovered it. This process can be up to 22 hours. Once discovered, it will download and install, and then it can be up to 24 hours until the device communicates back to the console. This means that it can be around 46 hours to see an update as installed if approved, even with no other variables.
It’s been over 46 hours, and I still don’t see a status, or the status has not changed; why?
- Many variables can impact timing. While 46 hours would be the maximum for an approved update, the following can impact that timing:
- Device Availability
- Deferrals
- Required and Auto Approvals
- Device Active Hours
- Update Sample < 24 hours
- Restart Requirements
- Bandwidth (WAN and LAN) Limitations
Feature Updates Readiness Dashboard
Widget | Category | Filter |
---|---|---|
Active Devices | Workspace ONE UEM: Devices | Device Organization Group Name Equals TMX Last Seen Within Last 21 day(s) |
Sensor Result | Workspace ONE UEM: Device Sensors | windows_1909_feture_upgrade_ready_check_v2 Does Not Include DUMMY_VALUE Last Sync Time Within Last 21 day(s) |
OS Already 1909+ | Workspace ONE UEM: Device Sensors | windows_1909_feture_upgrade_ready_check_v2 Equals OS_ALREADY_1909 |
Upgrade Ready | Workspace ONE UEM: Device Sensors | windows_1909_feture_upgrade_ready_check_v2 Equals READY FOR 1909 FEATURE UPGRADE |
Issue: ECAT | Workspace ONE UEM: Device Sensors | windows_1909_feture_upgrade_ready_check_v2 Equals ECAT |
Issue: DDPE | Workspace ONE UEM: Device Sensors | windows_1909_feture_upgrade_ready_check_v2 Equals DDPE |
Issue: DDPE (Legacy) | Workspace ONE UEM: Device Sensors | windows_1909_feture_upgrade_ready_check_v2 Equals L_DDPE |
Issue: Cylance | Workspace ONE UEM: Device Sensors | windows_1909_feture_upgrade_ready_check_v2 Equals CYLANCE |
Issue: Disk Space | Workspace ONE UEM: Device Sensors | windows_1909_feture_upgrade_ready_check_v2 Equals DISK_SPACE |
Issue: ENS | Workspace ONE UEM: Device Sensors | windows_1909_feture_upgrade_ready_check_v2 Equals ENS |
Issue: McAfee Agent | Workspace ONE UEM: Device Sensors | windows_1909_feture_upgrade_ready_check_v2 Equals MCAFEE_AGENT |
Windows Update Categories (Classifications) and GUIDs
Category | GUID |
---|---|
Application | 5C9376AB-8CE6-464A-B136-22113DD69801 |
Connectors | 434DE588-ED14-48F5-8EED-A15E09A991F6 |
Critical Updates | E6CF1350-C01B-414D-A61F-263D14D133B4 |
Definition Updates | E0789628-CE08-4437-BE74-2495B842F43B |
Developer Kits | E140075D-8433-45C3-AD87-E72345B36078 |
Drivers | EBFC1FC5-71A4-4F7B-9ACA-3B9A503104A0 |
Feature Packs | B54E7D24-7ADD-428F-8B75-90A396FA584F |
Feature Updates | 3689BDC8-B205-4AF4-8D4A-A63924C5E9D5 |
Guidance | 9511D615-35B2-47BB-927F-F73D8E9260BB |
OS Updates | CD5FFD1E-E932-4E3A-BF74-18BF0B1BBD83 |
Security Updates | 0FA1201D-4330-4FA8-8AE9-B877473B6441 |
Service Packs | 68C5B0A3-D1A6-4553-AE49-01D3A7827828 |
Tools | B4832BD8-E735-4761-8DAF-37F882276DAB |
Update Rollups | 28BC880E-0592-4CBF-8F95-C79B17911D5F |
For more information, refer to description of the standard terminology that is used to describe Microsoft software updates and Mobile device management (MDM) for device updates.