Managing Updates for Windows Devices: Workspace ONE Operational Tutorial

VMware Workspace ONE UEM 2011 and later

Overview

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.

  1. Workspace ONE UEM managed Windows 10 devices reach out to Microsoft Update Servers to query available updates. 
  2. A list of KBs/Updates are sent back to the device in the form of metadata. 
  3. Devices report available updates to Workspace ONE UEM on the next Windows Update sample interval.
  4. Workspace ONE UEM pulls in additional information from Microsoft about each available update.
  5. If Workspace ONE Intelligence is integrated, updates data is also sent to Workspace ONE Intelligence. 
  6. If Workspace ONE Intelligence is integrated, CVE feed is ingested into Workspace ONE Intelligence daily.
  7. If Workspace ONE Intelligence is integrated, Workspace ONE Intelligence correlates CVEs and KBs. 
  8. If Workspace ONE Intelligence is integrated, configurable automation updates are approved.
  9. Based on approvals via the Workspace ONE UEM console or automation in Workspace ONE Intelligence, authorized approved updates (metadata) are sent to the devices.
  10. On the next update scan by the device, or manual scan by the user, the device will fetch the authorized updates. 
  11. If Delivery Optimization is configured, devices will leverage Peer-to-Peer delivery when downloading updates. 
  12. 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.

Quality Updates Standard Deployment

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.  

Quality Updates Modern Deployment

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.

Approving an Update

  1. Navigate to Devices > List View in the Workspace ONE UEM Console, then select a Windows 10 device.
  2. Click the Updates tab.
  3. Select an available update to approve.
  4. Click the Approve button, which appears above the listed updates.

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:

  1. Navigate to Accounts > Administrators > Roles.
  2. Click Add Role.
  3. Provide a Name, Description, and add the above permissions.
  4. 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.

  1. Navigate to Settings > Devices & Users > Advanced > Tags.
  2. 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.

  1. Navigate to Resources > Device Updates in the Workspace ONE UEM Console, then select the appropriate update.
  2. 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.

  1. Select your assignment groups.
  2. 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

  1. Go to Devices > Device Updates and select the appropriate update.
  2. 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:

  1. Select Apps & Books.
  2. Select Add > Application File.

1.1. Download Software

  1. First, download the latest version of the Dell Command | Update software. 
  2. 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

  1. Select the DellCommandUpdate.msi.
  2. 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

  1. Select 64-bit for the Supported Processor Architecture.
  2. 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.

  1. Enter 150 for the Disk Space Required, which specifies the amount of disk space the device must have available to install the application.
  2. Select MB for the Units of the Disk Space Required.
  3. Enter 25 for the Device Power Required, which specifies the battery power, in percentage, that the device must have to install the application.
  4. Enter 500 for the RAM Required, which specifies the amount of RAM the device must have to install the application.
  5. Enter MB for the Units of the RAM Required.

4. Add the Application Icon

  • Select the Images tab.

4.1. Open Icon Settings

  1. Select the Icon tab.
  2. Click the area labeled Click or drag files here.

4.2. Select the Icon File

  1. Navigate to the folder containing your Dell logo file.
  2. Select your Dell logo image.
  3. Click Open.

5. Assign and Publish

5.1. Save & Assign

  • Click Save & Assign.

5.2. Assign Dell Command | Update

  1. Name your Distribution.
  2. Select Dell for the Assignment Groups, or your custom created Assignment Group for your Dell devices.
  3. Select Auto for App Delivery Method.
  4. 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

  1. Select the Windows icon.
  2. 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

  1. Select General if it is not already selected.
  2. Enter a profile name in the Name text box, for example, Windows 10 - OEM Updates.
  3. Enter a description in the Description text box, for example, Configures Dell Command | Update.
  4. 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

  1. Scroll through the payload section on the left until you see the OEM Updates payload.
  2. Select the OEM Updates payload.
  3. 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:

  1. Select Weekly to set the interval used to Check for Updates. Supported values are Never, Weekly, and Monthly.
  2. Select Friday for the Day of the Week to check for updates.
  3. Set the Time to 10:00 PM. This sets the time of day to check for updates.
  4. 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.
  5. Select Manual Reboot for the Reboot Delay. Supported values are Manual Reboot, 5, 15, or 60 Minutes.
  6. 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.

  1. Using the scroll bar on the right, scroll down to the Update Type section.
  2. 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.

  1. 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:

  1. Click Add New.
  2. 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.
  3. 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.
  4. 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.

3. Verify the Profile Exists

Confirm that the newly created profile exists.

3.2. Locate the Profile in the List View

The Windows 10 - OEM Updates Profile now appears in the Device Profiles list view.

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

  1. You can quickly verify that the profiles and apps deployed to your device.
  2. The next steps review each of these configurations.

2.2. Validate the Windows 10 - OEM Updates Profile Installed

  1. Select the Profiles tab.
  2. 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.

  1. Select the More tab, then select OEM Updates.
  2. Click Intel HD Graphics driver, or any other update to view more details about that update.

 

3.2. OEM Updates Details

  1. Workspace ONE UEM reports on the OEM Updates and details such as Release ID, Version, Criticality, Update Type, Category, and the Date Applied.
  2. 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

  1. Click the settings icon.
  2. 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.

  1. Select Devices.
  2. Select Device Updates.
  3. 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:

  • Windows updates
  • Quality updates
  • Feature updates
  • OEM updates
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 

 Windows Onboarding 

 Windows Security and Policy Management 

 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.

Associated Content

home-carousel-icon From the action bar MORE button.

Filter Tags

Workspace ONE Workspace ONE UEM Document Operational Tutorial Advanced Win10 and Windows Desktop Deploy DEX Modern Management