Troubleshooting Windows 10: VMware Workspace ONE Operational Tutorial

VMware Workspace ONE UEM 9.3 and later
VMware Workspace ONE UEM 9.2



VMware provides this operational tutorial to help you with your VMware Workspace ONE® environment. In this tutorial, you learn how to troubleshoot Windows 10 features in a Workspace ONE UEM environment. Procedures include locating log files and registry keys, validating console settings, and using Fiddler as a troubleshooting tool.

This Windows 10 troubleshooting guide provides general troubleshooting guidance, as well as solutions to specific problems for various Windows 10 features in Workspace ONE UEM. The exercises in this tutorial are targeted to those with previous Windows 10 management experience in the Workspace ONE UEM product.


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 is also helpful.

Getting Started with Windows 10 Troubleshooting


This section contains a checklist for common troubleshooting scenarios, and helpful background information. For more detailed troubleshooting guidance, skip this section and go straight to the other sections in this tutorial, which walk through each troubleshooting scenario step-by-step.

Using the Windows 10 Troubleshooting Cheat-Sheet

The following Windows 10 Troubleshooting checklist walks through potential issues from most likely to least likely cause. If you'd prefer a paper format you can keep at your desk, download the PDF linked above on the MORE button.

Troubleshooting Windows 10 Profiles

Use these steps to identify reasons why a profile failed to install.

☐ Check Event Viewer logs for a 404 failure message: App and Service Logs>Microsoft>Windows> DeviceManagement-Enterprise-Diagnostics-Provider>Admin.

☐ Confirm that the correct action is used: Add/Replace/Delete/Exec.

☐ For Custom Settings:

  • Check that XML is in between CDATA tags.
  • Confirm that the correct data format is sent.

☐ Confirm setting is supported on the W10 edition/version being used.

☐ In Fiddler check error codes.

Troubleshooting Windows 10 Updates

Use these steps to identify why a Windows update failed to push to devices.

☐ Navigate to Windows Settings>Update & Security>Troubleshoot>Windows Update, and select Run the Troubleshooter.

☐ Verify that you see Update under Windows Settings > Accounts > Access Work or School, then selecting on our enrollment account, then selecting Info. Ensure you see Update under Areas managed by Workspace ONE, then under Policies.

☐ Using Regedit, validate all of the configured update values are set correctly: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update

☐ Use Event Viewer to obtain more information about errors: Microsoft-Windows-WindowsUpdateClient/Operational

☐ The following PowerShell cmdlets are helpful:

  • Get-Hotfix - This cmdlet retrieves installed hotfixes (also called updates) including those installed manually by users.
  • Get-WindowsUpdateLog - This cmdlet merges and converts Windows Update event trace log (ETL) files into a single, readable WindowsUpdate.log file.

Troubleshooting Software Distribution for Windows 10

☐ Check installation status of Software Distribution client at HKLM\SOFTWARE\Microsoft\EnterpriseDesktopAppManagement\MSI:

  • Success= 70
  • Failure= 30, 60, 120

☐ Navigate to  HKEY_LOCAL_MACHINE>SOFTWARE>AirWatchMDM>AppDeploymentAgent and review the registries.

☐   Check the Queue path and the S-1-5-18/S-1-X-X path for any processes. Then, check the LastDeploymentLog and LastStatusCode for more details.

☐    Scripts are supported for Install, Uninstall, and Detection. The following lists examples for each type:

  • PowerShell: PowerShell -ExecutionPolicy Bypass -File file.ps1
  • VBScript: cmd /C file.vbs    
  • JScript: cmd /C file.js

☐    BranchCache Status (P2P) run bcstatus from PowerShell, then run perfmon, add BranchCache counters, view data using the Report View.

Troubleshooting Console Settings and Enrollment for Windows 10

☐ Navigate to System > Advanced > Device Root Certificate and verify a PFX Device Root Certificate generated (NOT a CER).

☐ Confirm that the Hub app is published Devices & Users>Windows>Windows Desktop>Intelligent Hub Application.

☐ Staging workflows (command-line, PPKG, etc.) where the device is auto-reassigned to the end user need to have "Fixed Organization Group" or "User Group Organization Group" set at Devices & Users>General>Shared Devices.

☐ For Azure based enrollment, ensure Immutable ID Mapping Attribute is correctly set. Most commonly objectGUID or mS-DS-ConsistencyGuid. Ensure that Binary is used for objectGUID and String for any non-GUID value.

Enrollment Flows for Windows 10

Admin staging (staged enrollment to admin account, log out/login to domain user)

msiexec /i AirwatchAgent.msi /quiet ENROLL=Y SERVER=[server] LGNAME=[og id] USERNAME=[staging username] PASSWORD=[password]

Brownfield domain joined (in domain user profile):

msiexec /i AirwatchAgent.msi /quiet ENROLL=Y SERVER=[server] LGNAME=[og id] USERNAME=[staging username] PASSWORD=[password] ASSIGNTOLOGGEDINUSER=Y

☐ Azure AD Premium: Enable Azure AD Integration. Settings > System > Enterprise Integration > Directory Services > Azure AD Integration and Use Azure AD For Identity Services set to Enabled.

Understanding the Workspace ONE UEM Solution Stack

There are many communication methods and clients used to manage Windows 10 devices. This section explores these components in detail. It is important to understand these components before proceeding with log analysis and Windows 10 troubleshooting.

1. Communication Methods

Real-time communication with Workspace ONE occurs over one of two services:

  • Windows Notification Service (WNS)
  • AirWatch Cloud Messaging (AWCM)

2. Management Clients

Clients communicate to Workspace ONE UEM on behalf of the device. There are two primary management clients:

  • OMA-DM (Open Mobile Alliance Device Management)
  • Workspace ONE Intelligent Hub (formerly AirWatch Protection Agent)

The clients serves their own, distinct purposes, and rely on different services to establish real-time communication with Workspace ONE UEM. The following table compares them in more detail.

Management Clients

OMA-DM VMware Workspace ONE Intelligent Hub
Native MDM client built into the device
Workspace ONE Intelligent Hub installed on the device
  • Device communication
  • Device enrollment
  • Profile configuration using Microsoft CSPs
  • Software distribution metadata delivery using VMware CSPs
  • Profile configuration
  • Local policy enforcement
  • Sensors, Scripts, & Workflows
  • Baselines
  • Unified App Catalog
  • Hub Services
  • Product provisioning

3. Background Management Clients

In addition to the primary management clients, there are several background clients used to manage Windows 10 devices. The following table lists these clients and their primary functions.

Software Distribution Client (SFD)
Used to install Win32 applications
Adaptiva Client
Enables peer-to-peer distribution of Win32 apps
SCCM Integration Client
Prevents SCCM (ConfigMgr) from disabling MDM enrollment. Only required if using either SCCM (ConfigMgr) pre-1710 or Windows 10 pre-1709.
Workspace ONE Intelligent Hub
Used for communication, profiles, policies, workflows, sensors, scripts, and product provisioning
VMware AirWatch Agent (UWP - Store) Provides GPS location (Downloaded from the Microsoft Store)
Note: OMA-DM Location Tracking was introduced in Workspace ONE UEM 1811. GPS location data no longer requires an agent.
AirWatch Provisioning Client
Discovers where pre-registered OEM devices enroll
Dell Client Command Suite
Enables OEM (requires Dell Command | Update) updates and BIOS (requires Dell Command | Monitor) settings
Workspace ONE Assist Client Allows for remote control, file management, and executing remote shell commands using Remote Assist
Workspace ONE Tunnel Client Workspace ONE Tunnel enables secure access for mobile workers and devices.
VMware Digital Experience Telemetry
Allows for sending telemetry data directly to Workspace ONE Intelligence.

Workspace ONE Services Used for Windows 10

In addition to the clients listed above, the following table highlight the key services used in Workspace ONE UEM for Windows 10.

Service Description Hostname & Ports
Windows Notification Service (WNS)
Provides real-time communication for the built-in OMA-DM client.

* over 80/443 (IP List -

AirWatch Cloud Messaging (AWCM)
Provides real-time communication for the Workspace ONE Intelligent Hub. (SaaS) and 2001 (On-Premises)
Content Distribution Network (CDN)
Used when downloading apps from Workspace ONE UEM.
Device Health Attestation
Cloud service used for determining device posture, can also be hosted on-premises.
Business Store Portal
Access to app from the Business Store Portal, also used if pushing online BSP apps.
Azure AD Authentication
Used when leveraging Azure AD for any authentication including enrollment.
Windows Updates
Endpoints used for Windows Update downloads of apps and OS updates.
* over 80/443

Locating Log Files and Registry Keys

Determining the root cause is a logical first step in troubleshooting. To diagnose, it is helpful to know where to look and which logs to examine. This section lists the logs and registries that are helpful when troubleshooting Windows 10.

Remote Log Collection

Windows 10 remote log collection, released in Workspace ONE UEM 1811, provides admins the ability to collect logs from managed Windows 10 devices without having to physically access the device. You can choose to collect Hub or System logs, which includes logs on Software Distribution, Provisioning Agent, Intelligent Hub, PC Refresh, MDM and System Event Logs, and other environmental data.

1. Request Device Log

  1. Navigate to the desired device you want to collect logs from, then click More Actions.
  2. Click Request Device Log.

2. Choose Log Source

Determine if you want Hub or System logs for Windows 10 troubleshooting in Workspace ONE UEM console.

Select either Hub or System.

  1. Hub: contains logs related to the Workspace ONE Intelligent Hub such as the Hub and application deployment logs.
  2. System: contains logs related to the system such as Event Viewer logs and registry export.

4. View Logs

After the download completes, extract the logs. A detailed explanation of all logs follows.

  • Hub > Agents >
    • Application Deployment Agent: contains logs (RegistryExport.txt and AirWatchMDM-*.etl) related to deploying Win32 (EXE, MSI, ZIP) applications to devices. These logs are helpful to provide to your Workspace ONE UEM support representative when app deployment is not working as expected. Refer to the Troubleshooting Application Management section of this tutorial for more details understanding these logs.
    • DEEM Telemetry Agent: contains logs related to osquery and the telemetry agent on the device. You can see the results of the osquery data being sent to Workspace ONE Intelligence as well as any errors.
    • Factory Provisioning Package: contains logs (PpkgInstallerLog.txt) related to installation of the provisioning package (PPKG) seeded at the factory to pre-load the apps on the device.
    • Provisioning Agent: contains the Provisioning Agent Event Log. For more details refer to Workspace ONE UEM Logs section of this tutorial.
    • Remote Management Client: contains logs related to errors with the Workspace ONE Assist client on the device during remote screen share/control, managing files, or launching the remote shell option from the Workspace ONE UEM console.
    • Workspace ONE Intelligent Hub: contains all the Workspace ONE Intelligent Hub log files. For more details refer to Workspace ONE UEM Logs section of this tutorial.
  • System > Device >
    • PCRefresh: contains logs related to Enterprise Reset. More logs are visible after performing the Enterprise Reset action on the device.
    • Windows: Contains the System & MDM Event Logs as well as a registry export of HKLM\SOFTWARE\Microsoft\EnterpriseResourceManager which shows a list of successfully applied CSPs (profiles and apps) on the device.
      • Environment: Processes.txt and Services.txt contain an export of currently registered services and running processes.

To watch a video demonstrating this feature, click the following video.

Local Log Collection Using Workspace ONE Intelligent Hub

You can also gather the same logs locally on the device automatically when using the Hub version 1902 or later.

Windows 10 troubleshooting options

On the task bar of your Windows 10 device, right-click the Workspace ONE Intelligent Hub icon, then select Troubleshoot. You are presented with the following options:

  • Collect Logs: You are prompted to select a local directory to save the logs. The same logs as remote log collection are exported locally on the device. For more details, see the Viewing Logs section.
  • Hub Status: This option performs a quick test and display some helpful information about the device and services running on the device. Ensure each device has a unique Device UDID, has all of the OMA-DM Services running, the device can reach the Management Server Address, and that the AirwatchService is running. HubStatus.html is generated and stored in %ProgramData%\AirWatch\UnifiedAgent\Logs.

Event Viewer Log

The Event Viewer Log organizes device logging categories into easily navigable folders. The following list provides the logs most commonly used in troubleshooting.

Note: To enable Debug logging, navigate to View > Show Analytic and Debug Logs.

Important Event Viewer Log Locations
OMA-DM Communication
Collects every interaction between the device and Workspace ONE UEM
  • Event Viewer (Local) > Applications and Services > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin
Enterprise Data Protection (EDP)
Collects logs related to WIP and Audits
  • Event Viewer (Local) > Applications and Services > Microsoft > Windows > EDP Audit Regular Channel
  • Event Viewer (Local) > Applications and Services > Microsoft > Windows > EDP Audit TCB Channel
  • Event Viewer (Local) > Applications and Services > Microsoft > Windows > EDP App Learning
AAD & User Device Registration
Collects all information related to Azure Active Directory and joining via AAD
  • Event Viewer (Local) > Applications and Services > Microsoft > Windows > AAD > Operational section
  • Event Viewer (Local) > Applications and Services > Microsoft > Windows > User Device Registration > Admin section
Modern App Deployments
Shows all errors and logs for AppX deployments
  • Event Viewer (Local) > Applications and Services > Microsoft > Windows > Apps and Appx 
Assigned Access
Collects information related to Single App Mode
  • Event Viewer (Local) > Applications and Services > Microsoft > Windows > AssignedAccess
 Collects BitLocker information, or use the manage-bde -Status C:command first
  • Event Viewer (Local) > Applications and Services > Microsoft > Windows > BitLocker-API and BitLocker-DrivePreperationTool 

Device Registry

The Device Registry records everything that happens to devices in Workspace ONE UEM. The following list outlines the registry keys most commonly used for troubleshooting.

Important Device Registry Keys
All MDM Profiles/Apps Pushed to Device
Lists all the profiles (LocURI not values) pushed to the device, including applications. These are broken down by device profiles and user profiles identified by user's SID.
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked
MDM Profiles and Values
Lists the device profiles default and updated values. These are broken down by device profiles and user profiles identified by user's SID.
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\providers\{EnrollmentGUID}\default\Device
Store/Modern Apps
Status of app installations along with additional information.
  • HKEY_CURRENT_USER\SOFTWARE\Microsoft\EnterpriseModernAppManageme
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseAppManagement
MSI/Desktop Apps*
Status of the Workspace ONE Intelligent Hub, Software Distribution Client, and all MSI app installations (when not using Software Distribution)
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseDesktopAppManagement
Software Distribution Apps*
Status of app installations along with additional information.
Non-SCEP Certificates
Certificate information for installed certificates.
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates
*The following folders are useful when troubleshooting apps:
  • AppManifests — Contain information about all of the settings selected in the console. 
  • ContentManifests — Contain where the device can download the software, such as Device Services URL, CDN URL, and P2P Content ID. 
  • Queue/S-1-5-X — Contain the install status and logs for each application, where S-1-5-18 contains apps pushed to the device and S-1-5-21-X contains apps pushed to the user. 

Workspace ONE UEM Logs

Workspace ONE logs record enrollment, application deployment, and other Workspace ONE interactions. The following list outlines the logging directories most commonly used for troubleshooting.

Logging Directories
Workspace ONE Intelligent Hub

  • AwclClient.log — Log contains communications between AWCM client and Workspace ONE UEM.
  • AWProcessCommands.log — Logs containing info regarding commands sent from Device Services to the Workspace ONE Intelligent Hub such as encryption/BitLocker, Baselines, Product Provisioning, etc. Refer to Understanding the Workspace ONE UEM Solution Stack to better understand which commands are captured in this log file. 
  • AwAirWatchIpc.log — Contains user context process communications along with the status of all actions performed. For example, installing the Workspace ONE Intelligent Hub UI component, Toast Notifications, getting INet proxy, etc.
  • ComExecution.log — Log contains details regarding user engaged restart for app deployments.
  • DeviceEnrollment.log — After native OMA-DM enrollment, these logs capture additional enrollment steps performed by Workspace ONE Intelligent Hub.
  • DSM.log — Log contains info regarding device state management.
  • HubAgentComLogsYYYY-MM-DD.log — [DeprecatedRefer to the other Hub Communication logs.
  • HubComLogs_AWProcessCommandsYYYY-MM-DD.log — Communication logs, not the most helpful log for troubleshooting, refer to the AWProcessCommands.log file. 
  • HubComLogs_TaskSchedulerYYYY-MM-DD.log — Communication logs, not the most helpful log for troubleshooting, refer to the TaskScheduler.log file. 
  • HubStatus.html — Created after right clicking on the Workspace ONE Intelligent Hub and selecting Troubleshoot -> Hub Status. Contains details around required Services and enrollment details. 
  • HubMSIUpdate.log — Contains the standard MSI log for the Workspace ONE Intelligent Hub upgrade.
  • InstallerLog_HHMMSS_DDMMYYYY.log — Installer logs will be created for each action performed by the Workspace ONE Intelligent Hub Installer (AirwatchAgent.msi): upgrade, install, uninstall and repair. These are standard MSI logs and contain details about actions performed on an installer session.
  • IntelligentHubInstallationGUID.log — Contains installation details of the Workspace ONE Intelligent Hub UI component. 
  • IntelligentHubUnInstallation-YYYY-MM-DD-HH-MM — Contains uninstall details of the Workspace ONE Intelligent Hub UI component. 
  • NativeEnrollment.log — Log contains details about the native OMA-DM enrollment completed by the Workspace ONE Intelligent Hub based enrollments.
  • PowershellExecutor.log — Details of the PowerShell commands executed through product provisioning and Sensors.
  • SSOCommunicationHandler.log — [DeprecatedWorkspace ONE Intelligent Hub post-enrollment single sign-on.
  • TaskScheduler.log — Log contains details regarding Workspace ONE Intelligent Hub task scheduler such as Hub re-starts, device re-assignments, enrollment request/response, etc. 
  • Updater.log — Workspace ONE Intelligent Hub auto-updates log.
  • Workflow.log — Log contains info regarding Workspace ONE Workflows execution. 
  • WorkspaceOneProvisioning.log — [DeprecatedRefer to the WorkspaceOneDownload.log and WorkspaceOneInstallation.log files. 
  • WorkspaceOneDownload.log — Checks to see if Workspace ONE App is downloaded, if not downloaded it will download the binaries. 
  • WorkspaceOneInstallation.log — Contains logs regarding the installation steps of the Workspace ONE App and its dependencies. 
  • ApplicationManager.log — [DeprecatedLog contains information regarding processing Product Provisioning packages. 
  • Archive — Folder containing older logs.
  • JobLogs\ProductProvisioningJobName_###.log — Contains either a success message (Jobs executed successfully) or more details regarding why your files/actions (Product Provisioning) script failed to process successfully. Each Product (Files/Actions) will contain a new log file, furthermore, each new attempt at re-pushing a Product will create a new log file. The standard naming format is Product Name followed by Job Number. 
  • Recovery\RecoveryService.log — Provides details on the status of the Workspace ONE Intelligent Hub auto recovery functionality. This can be trigger by an admin in the Workspace ONE UEM console, by preforming the Repair Hub action, under More Actions.


  • CommunicationServiceLogYYYY-MM-DD.log — Communication logs for the Hub UI component. 
  • HubCommLogsYYYY-MM-DD.log — Communication logs for the Hub UI component. 
  • IntelligentHubLogsYYYY-MM-DD.log — This log contains details about the Workspace ONE Intelligent Hub UI component's operations. For example, enrollment request/response and Hub Services related details such as branding, entitlements, and other details. 
C:\Program Files (x86)\Airwatch\AgentUI\BaselinesBackup
Telemetry Client
  • osqueryd.results.log — Log contains results of your scheduled queries. These are differential changes between the last query and current query execution. Each line item is a JSON string that indicates what data has been added/removed by which query. For more info please refer to osquery results log details. 
  • osqueryd.[INFO|WARNING|ERROR].YYYMMDD-hhmmss — Log contains Info, Warning, or Error details regarding issues running queries. 
  • vmwosqext.exe.[INFO|WARNING|ERROR].YYYMMDD-hhmmss — Log contains  Info, Warning, or Error details regarding issues running queries. 
Drop Ship (Factory) Provisioning
%SYSTEMDRIVE%\Temp\PpkgInstaller\PpkgInstallerLog.txt — Log contains details from applying the PPKG onto the system.
%ProgramData%\AirWatch\UnifiedAgent\Logs\PPKGFinalSummary.log — Log contains details from VMware Workspace ONE Provisioning Tool. 
AirWatch Provisioning Client
  • awProvAgent.log — Not a common log, but this log contains the provisioning agent event logging.
Adaptiva Client
  • AdaptivaClientMSISetup.log
  • AdaptivaClientSetup.log
Adaptiva Cache
Software Distribution Cache
Workspace ONE App (Not the Intelligent Hub)
Enterprise Reset
  • AWRefreshUnattend.xml  Unattend XML which executes RefreshRunOnce.cmd, deletes itself from Panther folder.
  • RefreshRunOnce.cmd  Completes the Workspace ONE Intelligent Hub command-line enrollment.
  • ResetConfig.xml  XML file which specifies what happens when a PC Reset is invoked; invokes VMwareRefreshBackup.cmd and then VMwareRefreshRecover.cmd to back up old PC and recover to new PC before resetting the device.
  • VMwareRefreshBackup.cmd — Backs up all enrollment data to C:\Recovery\OEM\VMware, Windows Refresh migrates C:\Recovery\OEM folder from old to new PC.
  • VMwareRefreshRecover.cmd  Restores all the backed-up data from old to new PC; copies AWRefreshUnattend.xml in the Panther folder as unattend.xml.
  • Contains logs and application data with the app deployment cache, Hub database with all configurations and settings, and registry settings with MDM device ID used to ensure the device checks in with the right console side record.
Workspace ONE AirLift
%PROGRAMDATA%\VMware\VMware Airlift\logs
  • AirLift-<current_date>.txt: AirLift Windows Service logs
  • AirLift-Tool-<current_date>.txt: AirLift Command Line Tool logs
AirLift Setup Logs: %LOCALAPPDATA%\Temp

Workspace ONE Assist
  • aplog-YYMMDD-hhmmssms.log — Logs contains details regarding to remote support using Workpace ONE Assist. 

Note: For more details about Workspace ONE UEM logging locations for other platforms and the server, see the VMware AirWatch Logging Guide in VMware Workspace ONE UEM Documentation.

Changing Logging Levels

During troubleshooting, it might be necessary to change the default logging levels. Logging levels can be updated from the service's configuration file which is normally located in the installation directory. We will focus on updating the logging level for the Workspace ONE Intelligent Hub for Windows.  

1. Opening Configuration Files

Locate the configuration file for the service you want to update. If you are using the default installation directory for the Workspace ONE Intelligent Hub then you will find these files at %ProgramFiles(x86)%\Airwatch\AgentUI\*.config.

2. Update Logging Level

When making edits to the configuration files you will need to have administrative rights on your text editor. Notepad++ will prompt you automatically to switch to Administrator Mode, however, if you are using Notepad you should launch this app with administrative permissions then open and edit the configuration files.

Log Level Description
None Disables logging for the service.
Error Only captures ERROR events.
Warning Captures both WARN and ERROR events. 
Captures informational level logs for the service. This is the default level for most services. This includes INFO, ERROR, and WARN events.
All, Verbose, Debug Most verbose option, used for gathering debug logs. This option should only be used when actively troubleshooting, then reverted back to the Information level. This level includes INFO, ERROR, WARN, and DEBUG events.

The LoggingConfiguration section in the configuration file contains all of the logging details.

Key Value Description
filePath Default: %programdata%//Airwatch//UnifiedAgent//Logs//*.log
Determines the file path of the log.
level Default: Information (NativeEnrollment defaults to All)
Sets the logging level to capture for the given service.
systemEventLogLevel Default: None (NativeEnrollment defaults to Information)
Sets the logging level to send to the Event Viewer. Logs are located under Event Viewer > Applications and Services Logs > AirWatch.
logFileRollSize Default: 2048
Size in kilobytes (KB) before log files are sent to the Archive folder. Log files are prepended with a number, starting with 0, for example, 0.AwWindowsIpc.log. Logs starting with a 0 will always be the newest archived log file. 
maxArchivedFiles Default: 10
The number of files to store in the Archive folder per service/log. 

Validating Workspace ONE UEM Console Settings

The first step when troubleshooting Windows devices is to check several of the console settings.

1. Navigate to All Settings

Open All Settings in Workspace ONE UEM Console

In the Workspace ONE UEM Console:

  1. Select Groups & Settings.
  2. Select All Settings.

2. Check Device Root Certificate

Check Device Root Certificate in Workspace ONE UEM Console

Although Workspace ONE UEM automatically generates the Device Root Certificate, you should always check this first. Checking the Device Root Certificate can save hours troubleshooting on the device.

  1. Navigate to System > Advanced > Device Root Certificate.
  2. Ensure that the Device Root Certificate is generated, and the Device Root Certificate is of type Pfx and not Cer.
  3. Check that the certificate is generated at your Organization Group and not Global—Global is sufficient for on-premises users but if you experience issues then generate at Customer Organization Group.

3. Check Workspace ONE Intelligent Hub

Verify the AirWatch Protection Agent is configured correctly in the Workspace ONE UEM console
  1. Navigate to Devices & Users > Windows > Windows Desktop > Agent Application
  2. If you want to use the agent for Product Provisioning, local enforcement, BitLocker, and so on, then ensure it is enabled and assigned to the correct ownership types.

Important: If you are enrolling devices which do not support pushing Win32 apps such as HoloLens, Surface Hub, Windows 10 Home, Windows 10 Core, and so on, then ensure that the agent is DISABLED.

4. Check Azure AD Settings

Azure AD Settings
  1. Navigate to System > Enterprise Integration > Directory Services.
  2. If your Azure AD enrollment is failing, ensure User Azure AD for Identity Services is set to ENABLED.
  3. Verify Azure Integration is configured correctly in the console. The most common errors with Azure integration are as follows.
    • Not adding the on-premises app in Azure for URLs other than
    • Not matching the Immutable ID Mapping Attribute
    • Not using the correct data type for Immutable ID
    • Not using the Binary for objectGUID and String for any non-GUID value.

Note: If you cannot save your Azure AD for Identity settings, save your Directory Services options before enabling Use Azure AD For Identity Services. For example, if you add a new directory, save before continuing, or if you remove your directory, save before adding Azure.

Workspace ONE UEM can integrate with Azure in two models:

  • Pure Azure AD — Accounts are directly created in Azure and are not sourced from anywhere else (for example, on-premises AD or another IdP). During out of box enrollment (OOBE) these accounts are automatically created in Workspace ONE UEM, just-in-time.
  • Hybrid Azure AD — Accounts are sourced from on-premises AD or a third-party identity provider. In this case, you must configure the Immutable ID Mapping Attribute to match the Source Anchor in Azure AD Connect, or the Immutable ID value being sent from the third-party.

5. Confirm Shared Device Options

Shared Device settings in the Workspace ONE UEM console.
  1. Navigate to Devices & Users > General > Shared Devices.
  2. If you use any of the staging workflows (command-line, PPKG, and so on) where the Windows 10 device is auto-reassigned to the end user by means of a staging account, validate that either Fixed Organization Group or User Group Organization Group is selected for the Group Assignment Mode.

Important: If you do not change the Group Assignment Mode, the agent prompts the end user for a group ID after reassignment. This can negatively impact the user experience.

6. Verify TLS Mutual Auth for Windows Setting

Disable TLS Mutual Auth for Windows 10 in the Workspace 1 UEM console
  1. Navigate to Devices & Users > General > Enrollment.
  2. Click Optional Prompt.
  3. Verify that Enable TLS Mutual Auth for Windows is set to your desired setting. Most customers have this disabled. If you are unsure, disable this setting to prevent communication issues with Windows devices.

Note: Enabling this option forces Windows devices to use endpoints secured by TLS Mutual Authentication. This requires additional setup and configuration.

Using Fiddler for Troubleshooting Windows 10

Fiddler is a free web debugging proxy server tool which logs HTTP(S) traffic to quickly obtain all network communications to and from the device. Instead of requesting and analyzing verbose server logs, you can significantly reduce Windows 10 troubleshooting efforts by using the Fiddler tool.

This exercise helps you to download, install, configure and use this free tool on a Windows 10 device.

Installing Fiddler

Find Fiddler download in Web search

In our already launched Google Chrome browser:

  1. Click the New Tab button.
  2. Enter fiddler in the Search box. 
  3. Select Fiddler - Free Web Debugging Proxy - Telerik.

Note: You can also navigate to

1. Free Download

Click Fiddler free download button

Click Free download.

2. Download for Windows

Fields to complete Fiddler download.
  1. Select Client application development/debugging in the drop-down menu.
  2. Enter your email address, for example, in Your Email field.
  3. Select the I accept the Fiddler End User License Agreement check box.
  4. Click Download for Windows.

3. Run Fiddler Setup

Click FiddlerSetup.exe to run the Fiddler installer.

4. Accept License Agreement

Fiddler license agreement

Click I Agree.

5. Select Installation Folder

Install Fiddler.

Click Install.

6. Complete Installation

Close fiddler installation box.

Click Close.

Configuring Fiddler

In this section, learn how to configure Fiddler on a Windows 10 device to capture all HTTP(S) traffic to and from the device. This aides Windows 10 troubleshooting, by allowing you to see what Workspace ONE UEM is sending and receiving from the device.

1. Launch Fiddler

Launch Fiddler on a Windows 10 device.
  1. Click the Windows logo to launch the Start Menu.
  2. Search for fiddler.
  3. Click Fiddler 4.

2. Disable Warning

Click Cancel.

3. Select WinConfig

Click WinConfig.

4. Dismiss Orphaned Exemption Record Found

Click No.

5. Configure AppContainer Loopback Exemption Utility

  1. Click Exempt All.
  2. Click Save Changes.
  3. Click the X to close the AppContainer Loopback Exemption Utility pop-up window.

Note: If you do not want to Exempt All, you can accept  Work or school account, or any of the immersive apps you want to capture traffic for. This setting captures UWP application traffic and setting on Windows 10. By default, Fiddler captures traffic only for Win32 app types.

6. Decrypt HTTPS Traffic

  1. Select Tools.
  2. Select Options...

7. Check Decrypt HTTPS Traffic

Select the Decrypt HTTPS traffic check box.

8. Trust Root Certificate

Click Yes.

9. Install Root Certificate

Click Yes.

10. Confirm Root Certificate Install

Click Yes.

11. Trust Root Certificate Added Success

Click OK.

12. Trust Root Certificate

Click X.

Running and Analyzing Fiddler Captures

In this section, use Fiddler for troubleshooting Windows 10 issues. Learn how to run a quick capture, view the data in RAW and XML formats, and save your captures.

1. Start and Stop Captures

Start and stop captures when troubleshooting windows 10.

To toggle Capture Traffic on and off, you can either press F12 or select File > Capture Traffic.

After initial installation, Fiddler starts capturing by default. Note the Capturing message in the bottom left corner.

2. Inspect Traffic

Inspect traffic for Windows 10 troubleshooting.

To toggle Capture Traffic on and off, you can either press F12 or select File > Capture Traffic.

  1. Select the first item in the list, where Host is
  2. Click Inspectors. 
  3. Select Raw or the most suitable view for your troubleshooting. Because most MDM communication is in SyncML format, for Windows 10, always select XML.
  4. Click Response body is encoded. Click to decode.
  5. Select Raw.

3. Start and Stop Captures

The upper window shows what is sent from the device to the endpoint, and the lower window shows the response from the server to the device. When Fiddler is first launched, it attempts to check for updates and sends its current version. The server then replies with the latest version of Fiddler and the release notes for the latest releases. This is a simple example to show the type of information we can retrieve, but for our troubleshooting we can use this method and tool to debug enrollment issues and pushing profiles, for example.

4. Apply Filters

Apply Fiddler filters for troubleshooting Windows 10.

When troubleshooting Windows 10, you can filter out all the noise other than your device services server, by adding a filter:

  1. Select the Filters tab.
  2. Select the Use Filters check box.
  3. Select Show only the following Hosts.
  4. Enter your host name, for example,
  5. Select Actions > Run Filterset now.

Note: You can also quickly filter and apply other helpful actions by right-clicking one of the traffic elements in the left pane. You can get advanced and replay requests and even modify data before replaying the request to see if it changes the response.

Troubleshooting Windows 10 Enrollment


Many issues can occur during enrollment either with Azure AD, Access Work (Native), Command Line, or Drop-Ship Provisioning. In this section, we walk through troubleshooting Windows 10 enrollment issues step by step.

Troubleshooting Common Workspace ONE UEM Enrollment Issues

This Windows 10 troubleshooting exercise helps you to check the most common enrollment-related issues before checking logs and using Fiddler. Go through the following quick checks to rule out the most commonly occurring issues.

1. Check Date and Time

Check if the device's date and time are correct, especially when using a virtual machine. This prevents any SSL-related errors due to the date and time being out of sync with the server time. This simple step should always be completed if you encounter enrollment issues or failed check-ins.

2. Check Internet Connection and Endpoints

After you have verified that the Date & Time settings are correct, next verify internet connectivity to all the endpoints which will be used. See On-premises Architecture Network Requirements in the VMware Workspace ONE UEM Documentation which lists required endpoints. For additional details, see the Microsoft article Manage Windows 10 Connection Endpoints .

2.1. Verify Network and Internet Settings

Ensure that the device has an active internet connection. If connected to a Proxy or VPN, make sure that access to Workspace ONE UEM endpoints or Microsoft endpoints is not affected.

2.2. Verify Endpoints

Workspace ONE UEM and Microsoft endpoints.

Ensure that you have a trusted connection to all Workspace ONE UEM and Microsoft endpoints. You must satisfy the following requirements.

  • Workspace ONE UEM Device Services URL over port 443
  • Windows Auto-Discovery URL (optional) over port 443; Cloud WADS:
  • Workspace ONE UEM Auto-Discovery over port 443;
  • Azure Active Directory needs access to Microsoft Login Servers: and
  • Windows Notification Service (WNS) uses port 443: * for example, bn1 or

Note: If you need to enable Telnet, add the Telnet Client using Turn Windows Features On or Off.

A few more uncommon endpoints to check for are:

  • Device Health Attestation 
    • Secure Boot protects the platform until the Windows kernel is loaded. Then protections like Trusted Boot, Hyper-V Code Integrity and ELAM take over. A device that uses Intel TPM or Qualcomm TPM gets a signed certificate online from the manufacturer that has created the chip and then stores the signed certificate in TPM storage. If you filter Internet access from your client devices, you must authorize the following URLs:
      • For Intel firmware TPM:
      • For Qualcomm firmware TPM:
    • To provision AIK certificates and filter Internet access, you must authorize the following wildcard URL: https://*
    • Both device and Workspace ONE UEM servers must have access to using the TCP protocol on port 443 (HTTPS).
  • Microsoft Store
    • Public Store Apps:
    • BSP Apps:
  • Microsoft License Activation: For more information, see Windows activation or validation fails with error code 0x8004FE33.
  • Windows Notification Service: For more information, see Microsoft Download Center.

For more details on Workspace ONE UEM networking requirements, refer to Workspace ONE UEM Ports and Protocols. In addition, for more details on Windows 10 connection endpoints, refer to Windows 10 Enterprise Connection Endpoints.

3. Check Accounts

For Access Work or any end-user driven enrollment, verify you are using an account with administrator access. Ensure you are not using the built-in administrator account as this account cannot enroll into MDM. For more details, refer to Enrollment Scenarios Not Supported.

3.1. Check Staging Accounts

When using any of the command-line options or any other staging workflow, you must use a staging account to enroll first before the device gets reassigned. You can either use the built-in staging account that Workspace ONE UEM creates when you first navigate to Settings > Devices & Users > Windows > Windows Desktop > Staging & Provisioning, or you can create a new staging account. Ensure your staging account's staging options match the settings in the screenshot.

Note: The staging account that Workspace ONE UEM creates will always be in the following format: staging@{GroupID}.com for the UPN and staging{GroupID} for the username. You must have a Group ID assigned to the organization group you plan to enroll and stage devices.

4. Check Device Root Certificate and Application Certificate

Windows 10 Device Root Certificate and Application Certificate

After a successful enrollment you should have two certificates from Workspace ONE UEM in Certificates - Current User > Personal > Certificates, as shown in the screenshot. Verify that these certificates are not present before enrolling or your enrollment will fail (delete all certificates then re-enroll). Previously, we confirmed that the Device Root Certificate was generated. To use any of the applications (SCL, Agent, Browser, Inbox), ensure that the Application Certificate is generated.

Enrollment Certificate: 

  • Subject Name Format - AW::{Token}::{DS URL}
  • Issued by AwDeviceRoot
  • Workspace ONE Intelligent Hub (formerly AirWatch Protection Agent) will not successfully check-in without the Enrollment Certificate

Application Certificate: 

  • Subject Name Format - {Device ID}:{Enrollment UPN}:{DS URL}:{One Time Token}:{Group ID}
  • Used by Workspace ONE UEM (formerly AirWatch) applications to retrieve device and environment information.
  • Ensure that the Device ID, Enrollment UPN, DS URL, and Group ID are correct or you will receive errors when attempting to use any of the Workspace ONE UEM applications.

5. Check OS Activation and Build

Inconsistent behavior has been noted on non-activated Windows devices and developer editions of Windows devices, therefore ensure you are running an activated version of Windows. Also, ensure you are using the latest general release build of Windows 10 for best results. It is helpful to know which Windows 10 edition is being used as not all editions support all features such as deploying apps and installing several profiles. For example, you cannot deploy software to Windows 10 Home.

Important: Workspace ONE UEM cannot guarantee 100 percent functionality on Windows Insider or TAP program builds which are not general release builds. Also, there are issues with earlier builds of Windows (pre-1703) so always ensure you are on the latest build.  

6. Check Required Services

troubleshooting Windows 10 required services.

If you enroll the device or configure the device to communicate with Workspace ONE UEM, then ensure the following services are running; DmEnrollmentSvc and dmwappushservice. These services do not run if there is no active attempt to enroll or sync the device. However, they should not be disabled.

Note: By default, Device Management Enrollment Service (DmEnrollmentSvc) should be set to Manual and the WAP Push Message Routing Service (dmwappushservice) should be set to Auto. The services run by default as LocalSystem and only start on-demand from a request by the user, an app, or another service. Attempting to enroll or sync the device automatically starts both services.

Note: Both DmEnrollmentSvc & dmwappushservice are dependent on Remote Procedure Call (RPC) service, therefore ensure that the PRC service is not set to disabled.

Also, DiagTrack (Connected User Experiences and Telemetry) and Schedule (Task Scheduler) must be running on the device to ensure enrollment and other management features properly function. BITS (Background Intelligent Transfer Service) should not be disabled as this is used to downloading various packages.

You can leverage the local log collection using Workspace ONE Intelligent Hub to quickly obtain troubleshooting logs, as well as click on Troubleshooting, then Hub Status to quickly see the status of the above services once the device is enrolled.

7. Check Registry Folders (Only for Pre-1703 Builds)

  1. Delete all the folders/keys under the following locations:
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\omadm\Accounts

If you have too many enrollment attempts (GUIDs in the registry) then you can be locked out from enrolling again. Or, if you experienced a malfunctioned un-enrollment then these folders were not removed properly and need to be manually removed before attempting to re-enroll.

  1. Delete all folders under MSI: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseDesktopAppManagement\{SID}\MSI

This only occurs for re-enrollment, new enrollments are not affected. Also, this occurs only if you are pushing down the agent, as a result the Pending Agent issue. When attempting to enroll again, if the folder under MSI was not deleted from the Registry then when Workspace ONE UEM tries to push the agent again, the console believes it is already installed, because the old registry folder still exists. Remove all folders, because this can also happen with other MSI installs.

Troubleshooting Windows 10 Native OMA-DM (Access Work or School) Enrollments

This exercise walks through troubleshooting Windows 10 native/builtin OMA-DM enrollment into Workspace ONE UEM. For this exercise, you do not need the Workspace ONE Intelligent Hub.

What is Windows 10 Enrollment into Workspace ONE UEM?

Device enrollment establishes the initial communication with Workspace ONE UEM to enable Mobile Device Management (MDM). The enrollment methods for Windows Desktop focus on adding features and functionality depending on how devices are enrolled. 

All Windows Desktop enrollments use the native OMA-DM protocol to complete the enrollment process in the background. Windows Auto-Discovery Service is an optional method of enrolling devices that only requires the end-user's email address to begin the enrollment process. 

Enrollment can also require the downloading of the Workspace ONE Intelligent Hub. This Intelligent Hub adds endpoint security to your Windows Desktop devices to ensure your data and devices remain secure wherever the device may go. The Intelligent Hub for Windows Desktop co-opts the native Windows Desktop functionality such as BitLocker encryption, Windows Firewall, and Windows Automatic Updates to keep devices secure and up-to-date.

It is recommended to only use native OMA-DM enrollment when required. This is required due to some limitations with various operating systems not supporting x32/x64 apps. For more information on selecting the most appropriate onboarding method for your use-case(s), refer to Selecting an Onboarding Workflow.

1. Find your Group ID

Finding your Group ID

The first step is to retrieve your Organization's Group ID.

  1. In Workspace ONE UEM Console, hover your mouse over the Organization Group tab at the top of the screen.
  2. Your Group ID is displayed at the bottom of the Organization Group pop up. The Group ID is required when enrolling your device.

2. Capture Access Work Enrollment Traffic

Note: Ensure you have Fiddler in capture mode to capture all the network traffic during device enrollment.

2.1. Launch Settings

Launching Settings
  1. Click the Start Menu icon.
  2. Click the Settings icon.

2.2. Access Accounts

Accessing Accounts

Select Accounts.

2.3. Access Work Enrollment

Accessing Workplace Enrollment
  1. Click Access work or school.
  2. Click Enroll only in device management.

2.4. Connect to Windows Auto Discovery Service

Connecting to Windows Auto Discovery Service

For this step, use a static or local email address. This is not the email address that you used to log in to your environment. Normally, your user community would enter their corporate email address which would then point their device to your Workspace ONE UEM environment. If you choose not to use a WADS server then the user would be forced to enter the enrollment URL manually. This is no longer the recommended enrollment method; end-users should enroll by navigating to

  1. Enter the email address, for example,
  2. Click Next.
  3. Enter the management endpoint URL (Device Services hostname), for example,
  4. Click Next.

Note: To verify if an email domain is registered with Workspace ONE UEM Auto-Discovery, navigate to{domain}

To verify if Windows Auto-Discovery is set up for a domain, navigate to https://EnterpriseEnrollment.{domain}/EnrollmentServer/

2.5. Enter Group ID

Group ID
  1. Enter your Group ID.
  2. Click Next.

2.6. Enter Username and Password

Username and Password
  1. Enter the testuser in the Username field.
  2. Enter the VMware1! in the Password field.
  3. Click Next.

2.7. Remember Sign-In Info

Remember Workspace ONE UEM Sign-In Info

Click Skip to not remember sign-in info

2.8. Complete Enrollment

Complete Workspace ONE UEM Enrollment

Click Got it.

Note: If you are prompted by User Account Control (UAC) to allow the app to make changes to your PC, click Yes.

2.9. Validate Successful Enrollment

Close Settings

Validate that you now see a new enrollment account under Access work or school.

3. Check Enrollment Traffic

Allowing Application to Make Changes

Now, return to the Fiddler application. The most important sessions which deal with enrollment are the and endpoints and the authentication traffic which lead up to these endpoints. Explore some of the entries and inspect the traffic to the right. Complete a successful enrollment and save your results—this will be helpful for troubleshooting at a later stage. Again, Fiddler can be used to see if some of the endpoints are not accessible. In this example, you can see 117 and 119 where the network is blocking access to

Note: For more information, see the Microsoft article Federated Authenticate Device Enrollment

3.1. Check Enrollment Information

Allowing Application to Make Changes

Click your enrollment account, then click Info. 

3.2. Sync Device

Allowing Application to Make Changes

The device sync status shows the last attempted sync time, and whether the last sync with Workspace ONE UEM was successful or unsuccessful.

3.3. Check Sync Traffic

Allowing Application to Make Changes

Again, when you click Sync, you will notice traffic in Fiddler. Return to the console, find your device and attempt several actions such as Lock, Query, or Query each category individually to see the differences. Fiddler can help to determine if the device can communicate with Workspace ONE UEM, to check contents of profiles being pushed, and to return error codes which Workspace ONE UEM might not always display.

You can also check the logs related to enrollment to find potential issues. For details on logging locations, refer to the Locating Log Files and Registry Keys section.

Troubleshooting Windows 10 Profiles in Workspace ONE UEM


In Workspace ONE UEM, profiles allow you to modify how enrolled devices behave. This exercise helps you to check your restriction profile settings using Fiddler and Event Viewer.

Note: You must have a restrictions profile already configured to perform the steps in this section. To create a restrictions profile, see Configure a Restrictions Payload for Windows 10 Devices in VMware Docs: Windows Desktop Device Management.

Using Fiddler to Validate Workspace ONE UEM Profiles

In this section, use Fiddler to check for communication from the server, and verify Workspace ONE UEM sent the correct values to the device.

1. Navigate to the Restrictions Profile

In the Workspace ONE UEM Console:

  1. Navigate to Resources > Profiles & Baselines > Profiles.
  2. Select your restrictions profile.

2. Republish Restrictions Profile

  1. Click Save & Publish.
  2. Click Publish.

3. Review Changes in Fiddler

Quickly switch back to Fiddler and notice the new traffic:

  1. Find the SyncML for our restrictions profile. 
  2. Notice it has a value of 0, because Cortana is disallowed.

Using Event Viewer to Check Workspace ONE UEM Profile Settings

In this section, use Event Viewer to review a successful and an unsuccessful profile deployment. The two most important Event IDs when dealing with profiles are 813 and 404, where 813 is Success and 404 is Failure.

1. Review a Successful Event

Troubleshooting Windows 10 profiles.

In Event Viewer:

  1. Navigate to Application and Service Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin.
  2. Notice the Event ID for the event is 813 — indicating success.
  3. Review the event details:
    • Policy (Allow Cortana) — Indicates the setting configured in the profile.
    • Context Use (Device) — Indicates the type of profile configured.
    • Int (0x0) — Indicates the configured setting. In this example, Allow Cortana is not allowed.

If troubleshooting without access to the console, use the registry to check the profile values set on the device. You can also leverage the builtin MDM Diagnostics management logs which make viewing configured profiles, policies, and group policies on the device straightforward.

2. Review a Profile Failure

Review this failed profile installation to understand Windows 10 troubleshooting.

This section analyzes a screenshot of a failed event. It does not provide step-by-step instructions for analysis.

In Event Viewer:

  1. Navigate to Application and Service Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin.
  2. Notice the Event ID for the event is 404 — indicating failure. 
  3. Review the Event Details. 404 messages list details such as not found, unsupported value, or unsupported edition. 
  4. The Result (The system cannot find the file specified) indicates that the profile is not supported on the version of the device in use.

Understand and Troubleshoot Custom Settings Profiles

The Custom Settings payload supports pushing custom configurations to both the Workspace ONE Intelligent Hub and the native OMA-DM client. For more information about these management clients refer back to the Understanding the Workspace ONE UEM Solution Stack section.

The Understanding Windows 10 Group Policies: VMware Workspace ONE Operational Tutorial contains an appendix section for Understanding Windows 10 Configuration Service Providers (CSPs) and Custom Settings Profiles. This section goes over all of the details needed to properly deploy and troubleshoot custom profiles. You can also refer to the previous sections on using Fiddler, Event Viewer, and MDM Diagnostic command to see the profile values and status.

Troubleshooting Policies, GPOs, and Baselines


Troubleshooting policies, GPOs, and Workspace ONE Baselines can be a complex task. You will first want to understand how and in what order these policies are applied. You can find more details in Group Policy (GPO) & MDM Policy (CSPs) Processing & Precedence. You might also find it vital to be able to confirm what policies are on the device. For quickly validating you can check Local Group Policy Editor on the managed device, but for more details refer to Validating Configured Policies.

Group Policy (GPO) & MDM Policy (CSPs) Processing & Precedence

Throughout the tutorial, various policy options were introduced and it quickly becomes apparent that having multiple mechanisms for setting/modifying the device's policies gets complex. We explored the overall best practices and methodology for modernizing and migrating policies. It is recommended to limit the overlap of technologies being used per device: for example, do not attempt to use AirLift's migration of policies to custom settings policies, baselines, and existing GPOs all applied to the same device. When you leverage a new mechanism its best practice to disable/un-assign the other method. However, we understand there will be use-cases where this is not possible; most notably when working across teams: Workspace ONE UEM admin versus Domain GPO admin. The following section attempts to explain the processing order of policies and which policy types take precedence over others.

1. GPO Processing and Precedence

group policy objects GPOs LGPO

First, let's understand the processing and precedence for group policy objects. Overall the last write/applied takes precedence and overwrites existing policies. Therefore, it is vital to understand the processing order for GPOs. Referring to the image you can see that local GPOs are processed first, therefore it also has the lowest precedence.

For more details on this topic refer to Group Policy Processing and Precedence and Group Policy Hierarchy.

2. Default Order of Precedence for GPOs and MDM Policies

The default when applying both GPOs and MDM policies on a device is that GPO policies win, or supersede, MDM policies. Therefore, by default GPOs have a higher precedence than MDM policies on the device. To more clearly define MDM policies, these are policies based on the Microsoft Configuration Service Providers (CSPs). Refer to Policy CSPs supported by Group Policy for more details regarding conflicts.

It is also important to note that throughout the tutorial we discuss leveraging Workspace ONE Baselines and AirLift to apply policies on the device. Baselines are based on GPOs and depending on the policy can be applied on the device using DEM, SecEdit, AuditPol, or LGPO (only custom baselines). Meanwhile, AirLift converts policies to CSPs and creates custom settings profiles in the Workspace ONE UEM console.

2.1. Enabling the Control Policy Conflict to Allow MDM to Win

There is a way to force MDM policies to win, or supersede, GPO policies. In this case, MDM policies would have a higher precedence than GPO policies on the device. Their is a CSP which can be deployed to managed devices which enable this behavior. You can leverage the Control Policy Conflict part of the Policy CSP which sets the MDM Wins Over GP policy to ensure MDM (Policy CSPs supported by Group Policy) policies wins over group policies.

Additionally, you can validate policy conflicts by Validating Configured Policies and using the MDM Diagnostics Tool to generate a report to see MDM versus GPO policy conflicts and which policy has precedence on the device.

Install Settings

			<Format xmlns="syncml:metinf">int</Format>

Remove Settings

			<Format xmlns="syncml:metinf">int</Format>


Validating Configured Policies

Using Microsoft Security Compliance Toolkit

You can use Policy Analyzer which is part of the Microsoft Security Compliance Toolkit to generate reports of the local policies applied to a device, or to compare local policies to various baselines for validation or even compare various baselines to each other.

  1. Download Policy Analyzer from the Microsoft Security Compliance Toolkit. You can choose to also download Windows 10 Security Baselines files. These can be used later to compare these policies to the local policies on the device.
  2. Extract the file, then launch PolicyAnalyzer.exe. Note for more information, refer to the Policy Analyzer PDF in the same directory.
  3. You can move any .PolicyRules files for a baseline into the Policy Rule sets in directory to have it appear as an option in Policy Analyzer. If you select to capture the Local policy Policy Analyzer will save a Policy Rule file, I would recommend renaming this file to provide you with some clarity.
  4. It is recommended to capture the Local Policy before applying baselines from Workspace ONE then again after. You can compare (click View/Compare) both the before and after to the targeted baseline to see the differences.  Once in the comparison window, navigate to View, then select Show only Conflicts.

Policy Analyzer is extremely useful for troubleshooting and for fully understanding what policies are being applied to the device. Once you feel comfortable with the policies and how they are applied to the device, you can move to using the built in Workspace ONE Baselines compliance capabilities.

The following image shows a sample comparison using Policy Analyzer of a Windows 10 1909 device local policies to the Windows 10 Version 1909 Security Baseline.

Using Policy Analyzer, part of the Microsoft Security Compliance Toolkit

Leveraging MDM Diagnostic Information

There are two ways to generate a report which shows the applied configuration service provider policies on the device. You can use the Windows 10 settings GUI or leverage command prompt to programmatically generate the report.

Option 1: Export your Management Log Files

Pull the MDM diagnostic report from your Windows device.

Open the Windows 10 settings menu, then navigate to Accounts.

  1. Click Access work or school.
  2. Click Export your management log files.
  3. Click Export.

Option 2: Use Command Prompts

Alternatively, from the command prompt on a managed Windows 10 device, run the following command to see all of the configured modern policies, blocked group policies, and unmanaged policies. This command validates what is configured on the device and is a great troubleshooting resource, as well.

%SYSTEMROOT%\System32\MDMDiagnosticsTool.exe -out <Output Folder Path>

Review the MDM Diagnostic Report

Both of the above options will generate the following report which contains detailed information (when expanded) about the device and it's configured policies. You can also use the Blocked Group Policies section to help visualize policy collisions between Workspace ONE UEM and group policies.

MDM Diagnostic Report Sample

Troubleshooting Windows Apps


Windows 10 introduces several new configuration service providers (CSP) to push out universal (Store and Non-Store) windows apps and desktop MSIs. Workspace ONE UEM supports integration with the Business Store Portal or the Microsoft Store for Business. This allows administrators to push public Windows app store applications to devices without having end users sign into the Microsoft Store.

However, if you only want the Workspace ONE app, you can install Workspace ONE Intelligent Hub which auto-downloads and installs the Workspace ONE app. Finally, Workspace ONE UEM supports not only MSIs (like most of our MDM competitors) but also supports MST, MSP, EXE, ZIP through Software Distribution. 

This exercise covers a high-level overview to troubleshoot all of these options.

Troubleshooting MSI Apps Using EnterpriseDesktopAppManagement CSP

Workspace ONE UEM deploys MSI agents, clients, and apps using the EnterpriseDesktopAppManagement CSP when using a Workspace ONE Standard license or when software distribution is not enabled. This method is used to push the Workspace ONE UEM Intelligent Hub (for native enrollment), the software distribution client, and the Adaptiva client. In this section, you will learn how to troubleshoot these MSI apps.

1. Check Registry Key Status Codes

enterprisedesktopappmanagement csp

If your apps fail to install or take too long to install, first check the registry. Navigate to    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseDesktopAppManagement and expand the MSI folder. The MSI folder contains keys (GUIDs) for every application sent down from Workspace ONE UEM. In the this example, Workspace ONE UEM installed Google Chrome on the device successfully.

Make sure that there are no entries in the MSI folder before enrolling. If the GUIDs (Product Version key) matches a folder that already exists, then it will fail to install, thinking the application is already installed. This occurs only during a broken un-enrollment. The ProductVersion or the GUID folder name matches the Build Version GUID in the Workspace ONE UEM console. To find this build version, click Edit on the application and see the build version.

Note the following information:

  • CommandLine: The command line arguments being sent down by Workspace ONE UEM. By default, /quiet is always sent, to perform a silent install.
  • CurrentDownloadURL: The device services/content delivery network (CDN) URL that the device is using to download the application. To verify that the application successfully uploaded to the console, manually copy and paste the URL into the browser and the application should download.
  • DownloadLocation: The file path where applications are downloaded.
  • LastError: Error code for failures. If you see a code, you will also see a new entry called ErrorDescription with details.
  • Status: Code of the current status.

The following table describes status codes for errors 10 to 120.

Status Code Description
20 Download in Progress
25 Retrying Download
30 Download Failed
40 Download Complete
50 Install in Progress
60 Install Failed
70 Install Complete
80 Uninstall in Progress
90 Uninstall Failed
100 Uninstall Complete
110 Hash Mismatch
120 Sideloading is not Enabled

Note: The most common error deals with error code 30—download failed. If you get a status of 30, then ensure that:

  • If using a CDN, the user is not blocking access to (users with restricted networks should not use CDN)
  • Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) URLs are accessible because by default, devices must verify the validity of the SSL certificate.

Finally, check the BITS log in Event Viewer for details as these applications are downloaded using BITS.  

2. Check MSI Installer Logs

MSI Installer Logs for Windows 10 Troubleshooting

You can find detailed, application-specific logs in C:\Windows\Temp. Another troubleshooting step is to manually install the MSI to verify if it is successful. If successful, attempt to install using the command prompt with the /quiet argument. For example, chrome.msi /quiet.

Troubleshooting Software Distribution

Workspace ONE UEM supports deploying any types of desktop (Win32) applications using software distribution, however, this the most difficult feature to troubleshoot. This section contains best practices and useful information for troubleshooting software distribution.

1. Review the Application Failure Checklist

The following list describes items to check if your application fails during software distribution.

  1. Check the Troubleshooting logs for the device within the Workspace ONE UEM Console under Devices > List View > [Select target Device] > More > Troubleshooting.
    • Deployment attempts and results are logged here, so check the logs and locate any events related to deploying/installing the application.
  2. On the target device, run regedit (Click Windows button > search regedit) and review the registries under HKEY_LOCAL_MACHINE > SOFTWARE > AirWatchMDM > AppDeploymentAgent.
    • Check the Queue path and the S-1-5-18/S-1-X-X path for any processes. If so, check the LastDeploymentLog and LastStatusCode for more details.
  3. In Explorer, navigate to %programdata%/AirWatchMDM/AppDeploymentCache/. Find the folder with the App Manifest ID and open it.
    • Ensure that the app folder (should be named the same as the app uploaded to the Workspace ONE UEM Console) is present and that the contents are extracted.
    • If the app did not download, you can attempt to re-push the application from Console or restart the Task Schedulers.
      1. Open WindowsTask Scheduler and navigate to Task Scheduler Library > VMware > AirWatch.
      2. Select both tasks (Install Validation Task and Software Distribution Queue Task), right-click and select End. Then select both tasks, right-click and select Start.
      3. Back in Regedit, delete all the paths under the AppDeploymentAgent path in HKEY_LOCAL_MACHINE > SOFTWARE > AirWatchMDM.
      4. Send the Install command to the device again from the Workspace ONE UEM Console by navigating to Devices > List View > [Select Target Device] > Apps > Select App > Install.

Note: For more details, see Software Distribution Troubleshooting Tips.

2. MSI versus EXE/ZIP Apps

The following list contains important information about MSI, ZIP, and EXE apps.

  • MSI applications update the install status immediately after completion; ZIPs and EXEs require an application list sample to process
  • MSI apps do not require any additional configurations from the admin; ZIPs and EXEs require uninstall command, install command, and detection criteria to be added
  • ZIPs and EXEs uploads use autogenerated information
  • ZIPs must contain either an EXE or MSI file
  • Folder name(s) for ZIPs must be included in the installation path, if applicable

Important: When using registry criteria, registry hive must be in shortened format, for example, HKLM rather than HKEY_LOCAL_MACHINE.

3. Scripts

Scripts are supported for Install, Uninstall, and Detection. The following lists examples for each type:

  • Powershell: powershell -executionpolicy bypass -file file.ps1
  • VBScript: cmd /C file.vbs
  • JScript: cmd /C file.js

4. Check Troubleshooting Logs Status Messages

The following list describes status messages in the console Troubleshooting logs.

  • Install command ready for device: The install command has queued for the device, but the device has not yet checked into Workspace ONE UEM and consumed the command.
  • Install command dispatched: The device has checked into Workspace ONE UEM and consumed the command. At this point, the registry should have entries in the AppManifests, ContentManifests, and Queue folders for this application.
  • Installed: The application has finished installing on the device and the detection criteria provided successfully confirms the installation status.
  • User installed: Detection criterion was fulfilled before Workspace ONE UEM-driven deployment began, indicating that the application was externally installed. As a result, it is reported as installed but unmanaged.
  • Failed: Some part of the process (download, requirement evaluation, dependencies, install, detection, and so on) was unsuccessful. Note that if installation was successful but detection failed, the client will rollback the installation of the application using the provided uninstall command.
  • MDM removed: Application has successfully uninstalled following the initiation of the application removal through Workspace ONE UEM.

5. Check Device Registry Logs

Check the following locations on the device for troubleshooting information. 

Note: For improved readability, you can copy and paste the registry data into a text editor for logs or XML editor for manifests.

    • AppManifests contains information regarding all of the settings selected in the console. For example, Deployment Options, Install and Uninstall Commands, Supported Architecture, Version, and so on.
    • ContentManifests contains details about where the device can download the software, such as Device Services URL, CDN URL, and P2P Content ID.
    • Queue/S-1-5-X  folders contain the install status and logs for each application, where S-1-5-18 contains apps being pushed to the device and S-1-5-21-X contains apps being pushed to the user context.
      • Includes InstallCount value:
        • 0: The application is not installed and is not actively being deployed.
        • 1: The application is installed, or installation is being attempted. If a dependency application, the dependency is installed and only one package depends on it.
        • 0x8000001: The application (or dependency application) is externally installed, and assume management is not applied.
        • 2+: The dependency is installed and has x applications dependent on it, for example, if InstallCount for a dependency is 3, it is installed and three individual application packages depend on it.

Note: If the application is pushed and only the ContentManifest is populated, it indicates the InstallApp command logged an error in the database.

Two of the most useful troubleshooting features are contained within the Queue folder:

  • The DeploymentLog entry contains the log of the current deployment, including any error codes and a description of the last error, if applicable
  • The StatusCode entry is a mapping to which part of the process the client is currently performing (for example, download, dependency evaluation, installation, and so on)

The following list details StatusCode entries.

  • 0x000: Deployment operation queued
  • 0x100: First detection in progress
  • 0x101: First detection failed
  • 0x102: First detection successful

  • 0x200: Check reference count in progress
  • 0x201: Check reference count failed
  • 0x202: Check reference count successful

  • 0x300: Requirements evaluation in progress
  • 0x301: Requirements evaluation failed
  • 0x302: Requirements evaluation successful

  • 0x400: Dependency deployment in progress
  • 0x401: Dependency failed
  • 0x402: Dependency successful

  • 0x500: Sanitize cache in progress
  • 0x501: Sanitize cache failed
  • 0x502: Sanitize cache successful

  • 0x600: Pending network connectivity
  • 0x601: Download in progress
  • 0x602: Pending download retry
  • 0x603: Download content failed
  • 0x604: Download content successful

  • 0x700: Transform cache in progress (decompressing zip packages)
  • 0x701: Transform cache failed
  • 0x702: Transform cache successful

  • 0x800: Pending user session
  • 0x801: Install in progress
  • 0x802: Pending deployment retry 
  • 0x803: Deployment failed
  • 0x804: Deployment successful
  • 0x805: Pending reboot

  • 0x900: Final detection evaluation in progress
  • 0x901: Final detection failed
  • 0x902: Final detection successful

  • 0xC0000000: Deployment operation suspended
  • 0xC0000602: Deployment suspended — pending download retry
  • 0xC0000802: Deployment suspended — pending install retry
  • 0x40000000: Deployment operation failed
  • 0x40000603: Deployment failed — download failed
  • 0x40000803: Deployment failed — installation failed
  • 0x80000000: Deployment operation succeeded
  • 0x80000402: Application is externally installed
  • 0x80000902: Deployment succeeded — final detection passed

Troubleshooting Application Sideloading

Sideloading activation keys were a requirement for Windows 8.1, however, this is no longer the case in Windows 10. When you sideload an app, you deploy a signed application package to a device. You maintain the signing, hosting, and deployment of these applications.

In Windows 10, sideloading is different than in earlier versions of Windows:

  • You can unlock a device for sideloading using a restrictions profile or manually through Settings.
  • License keys are not required
  • Devices do not have to be joined to a domain

1. Enable Sideloading Using Restrictions Profile

Enable Sideloading Windows 10  registry

In the Workspace ONE UEM console, you can use the restrictions profile to allow or disable sideloading applications on the device. Developer Unlock is required if you are using Powershell commands to sideload applications.

2. Enable Sideloading Manually

Enable Sideloading: Manually

On the device you can enable Sideloading through Settings > Updates & Security. Set the level above Store Apps, either Sideload apps or Developer mode will work.  

Troubleshooting Applications Using Registry Keys and Event Viewer

Workspace ONE UEM also deploys modern applications using the Workspace ONE UEM Console. When deploying internal applications many issues can occur. This section helps you to troubleshoot these applications.

1. Troubleshooting Internal Applications

The most efficient troubleshooting step for modern applications is to use the logging in Event Viewer. The registry reports an error only if the install failed. However, if the application never installed, you already know it failed. Therefore, check Event Viewer and if you do not understand the error, search for the error in Google and report this information back to the QE team (JIRA QE ESC) or the application developer.

Registry Location: HKEY_CURRENT_USER\SOFTWARE\Microsoft\EnterpriseModernAppManagement

Event Viewer Location: Microsoft-Windows-AppXDeployment-Server and Microsoft-Windows-AppxPackagingOM

Registry Key &amp; Event Viewer Logs

2. Validating Web Clips

Similar to the other registry locations, you can view the progress and status of all the web clips sent down to the device.

Registry Location: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\MDM\JobDB

For a list of status codes and descriptions, see the table in Registry Key — Status.


Troubleshooting Windows 10 Peer to Peer Networks


Another common issue with Windows 10 software distribution is that applications do not download correctly. This Windows 10 troubleshooting exercise covers possible issues when using peer to peer networks (P2P) and Content Delivery Networks (CDN).

Troubleshooting Peer to Peer Networks

Organizations can use peer to peer networks for application deployments by leveraging Workspace ONE UEM. In this section, we will review a few basic logging locations for Windows 10 troubleshooting.

1. Review Peer to Peer Server Logs

Troubleshooting Windows 10 Peer to Peer Networks using server logs and the Adaptiva log file.
  1. In Explorer, navigate to C:\Program Files\Adaptiva\AdaptivaServer\logs.

All of the Peer to Peer server logs are located here. Explore the adaptiva.log file for troubleshooting.

2. Navigate to %ProgramData%

Access the AirWatch directory and the AirWatch MDM directory.
  1. In Explorer, enter %ProgramData%.

The AirWatch directory contains agent logs including enrollment, product provisioning, and some profiles such as BitLocker.

The AirWatchMDM directory contains the software distribution cache folder. After the software packages are downloaded, they appear in this folder.

3. Review Client Logs for Peer to Peer Networking

Open Peer to Peer Networking Client logs for Windows 10

In Explorer, enter C:\Windows\AdaptivaSetupLogs\Client.

You can find the P2P client installation logs here—if you encounter installation issues, review these logs.

4. Check Client Registry Values for Peer to Peer Networking

Check client registry values for peer to peer networking
  1. In the registry, navigate to WOW6432Node > Adaptiva > client.

This location contains P2P client configuration information, such as the version, server it is connected to, and other granular details. Workspace ONE UEM handles installing and setting up this information.

5. Check Adaptiva Cache Folder

Use the Adaptiva cache folder when troublehooting windows 10 peer to peer networks.

In Explorer, enter C:\AdaptivaCache.

You should have the same content ID listed with the same file size for your application, therefore the next device to enroll or request this application will peer off of our first device. The content is in format: {contentID}.content

This folder is a hidden directory and uses VMware vSAN™ technology so that the space used goes unnoticed to the end user. When the end user needs more disk space, Adaptiva's self-managing cache deletes content.

6. Connect to Adaptiva Database

Connect to the Adaptiva database when troubleshooting Windows 10 peer to peer networks.

Launch SQL Server Management Studio and click Connect.

7. Select Adaptiva Content Table

Adaptiva content table
  1. Expand Databases > Adaptiva > Tables.
  2. Right-click dbo.ADAPTIVACONTENTS.
  3. Click Select Top 1000 Rows.

8. Find Content ID

Locate Adaptive Client content ID and Apps Content ID.

Content IDs were discussed in the previous steps—note that both of these IDs are on our devices cache for P2P. The database contains the apps metadata and you can explore the database for other information which might be helpful such as device IP/names, office locations, subnets, and so on.

Improving Performance with Content Delivery Network (CDN) Integration

Since AirWatch 8.4.1, the Workspace ONE UEM Console can integrate with Content Delivery Network (CDN) servers. This integration provides a number of benefits for your Workspace ONE UEM environment:

  • Assisting large file downloads - Normally, when an internal application is deployed to a device, the device downloads the app directly from the Workspace ONE UEM servers. However, in large environments, especially during large deployments of internal applications, this can lead to bandwidth issues and significant performance degradation. Integrating a Workspace ONE UEM environment with a Content Delivery Network server, available bandwidth is greatly expanded and the risk of performance degradation due to file downloads is minimal.
  • Deploying  Microsoft Store for Business (BSP) applications - CDN integration is a requirement for applications deployed through the Microsoft Store for Business (BSP). With this system, you can purchase apps from the Microsoft app store and then distribute them to devices through Workspace ONE UEM in the same manner that internal apps are distributed. This process allows for CDN to be leveraged when deploying public applications to Windows devices.
  • Improving software distribution performance - Similarly, CDN integration can be effective in improving the performance of software distribution for Windows 10 devices and is required for SaaS environments.

Integrating Workspace ONE UEM with a Content Delivery Network (CDN) Server

The process flow is as follows:

  1. A Workspace ONE UEM environment enables the use of a CDN at an environment-wide level.
  2. Newly uploaded applications will be deployed using CDN.
  3. Whenever a device requests to download an internal app from Workspace ONE UEM, the request is redirected to the CDN server.


Content Delivery Network

Important: As a requirement for environments using CDN servers for file distribution, enrolled devices must have open access to the internet. The CDN network has a distributed architecture around the globe, and VMware cannot guarantee that a specific file download to a device will come from any individual server. The system is designed to increase the likelihood that a device will download a file from a server in a similar geographic location.

If you have an environment where devices cannot connect to the CDN architecture (for example, due to a strict firewall configuration that allows access only to certain websites/servers), follow the next steps to disable CDN integration in your environment.

Integrating a Content Delivery Network with On-Premises Workspace ONE UEM

On-premises Workspace ONE UEM environments using AirWatch 8.4.1 and later can integrate with a CDN. However, you must have access to a corporate CDN account to enable the configuration. The process flow for downloads remains the same, although the IP requirements may be different, depending on the CDN system you use. VMware supports integration only with Akamai CDN accounts.

Follow the steps to configure CDN for on-premise environments:

  1. Navigate to Groups & Settings > All Settings > System > Enterprise Integration > CDN > Akamai, select Enabled.
  2. The values on this page can be retrieved by logging in to your CDN provider portal, locating the values, and entering them in this page.
  3. Save your settings to enable CDN.

Note: For detailed step-by-step instructions for your on-premise customers, see CDN Integration with Workspace ONE UEM from VMware Docs.

Workspace ONE UEM Integration with CDN FAQs

This section explores some general questions and answers concerning Workspace ONE UEM and CDN.

Q. Does Workspace ONE UEM leverage Content Delivery Network for both content types and apps uploaded to the Console? 

A. No, Workspace ONE UEM leverages CDN only for apps uploaded to the Workspace ONE UEM console. Workspace ONE UEM does not leverage CDN for content or any content uploaded for use with Product Provisioning. 

Q. What are the main components of Content Delivery Network integration?

A. The main components for CDN integration with Workspace ONE UEM are as follows:

  • The AirWatch Origin Server is the file server configured for storage of all files to be cached within Akamai on a pull model. This component has to be manually configured if you are using the on-premises deployment model. However, for SaaS users, this is already configured. 
  • The AirWatch Content Domain is the domain mapping to the configured Akamai Edge Server using CNAME (DNS plus * 
  • The Akamai Edge Server is responsible for caching and distributing files based on geographic location. It also authenticates resources that end users try to access.

Q. What is the general workflow for Content Delivery Network integration? Is there a failover method in place? 

A. See the Workspace ONE UEM with CDN Integration Workflow diagram. Note that applications are uploaded to the Workspace ONE UEM Console in the same way. Applications are still stored in the blob table in the database (unless you have file storage set up), but another step is added. After the application has been uploaded, a copy of the application is copied over to the AirWatch Origin Server. Applications always reside at the origin server. Devices are pointed to the AirWatch Content Domain to download the applications, and then the CDN provider’s logic determines which Akamai Edge Server will become the source of the download. If the edge server does not have the requested application then it obtains the application from the origin server (for SaaS there are origin servers at every data center). Akamai has logic to cache and purge their edge servers; however, the application is populated on the edge server upon the first request from a device. 

Lastly, if the connection to the CDN provider fails, the content (for example, an application) is pushed from the Workspace ONE UEM Device Services server, as it would be if CDN integration was not configured.

Note: There is an additional fallback for Windows devices provided by a feature built into the operating system. Workspace ONE UEM can send down multiple download URLs, therefore for software distribution, Workspace ONE UEM will send down the CDN URL as primary and the DS URL as a fallback URL. This is helpful for Windows devices because these devices might be connected to a closed VPN or a locked-down network at times.

Q. How are the applications secured and separated per user (or organization) on the Content Delivery Network?

A. Communications are secure and happen over HTTPS using SSL connections. Each application is uniquely identified through the blob ID, therefore users deploying the same applications will never share the same data. When the download URL is generated (see a sample URL in Workspace ONE UEM with CDN Integration Workflow) there is an attached token that expires after 24 hours and a HMAC token which is based on the salt of the CDN account being used. 

Q. When the Install command is processed (user-initiated, admin initiated, or auto) what occurs on the back end?

A. The process is as follows.

  1. First, Workspace ONE UEM makes a test connection to the AirWatch Content Domain URL, to ensure it is reachable. If this URL is non-reachable, then Workspace ONE UEM  generates a download URL pointing to the Workspace ONE UEM Device Services server, bypassing CDN. 
  2. If CDN is reachable, then Workspace ONE UEM generates the download URL and the HAMC and expiration tokens. 
  3. Device then navigates to the download URL, and uses download logic specific to that platform. For example, Timeout and Retry logic varies.
  4. Akamai decides which edge server to use. If the edge server does not have the application, it connects to the AirWatch Origin Server. 
  5. Device completes the download and proceeds with application installation. 

Windows Update Troubleshooting


Keeping your Windows 10 devices up-to-date helps to protect them from security risks and viruses. Because Microsoft has moved Windows 10 updates to a continuous cycle known as Windows as a Service, Workspace ONE UEM can now manage the update life cycle. This exercise helps you to explore some of the high-level windows update troubleshooting tasks to get updates working and validate they are set correctly.

How Do Windows 10 Updates Work?

Before you can begin Windows update troubleshooting, you need to understand how Windows 10 updates work. The following diagram walks through the high-level workflow of Windows 10 updates:

  1. Devices connect to Microsoft Update Servers for latest patches.
  2. Devices report patches (GUIDs) to Workspace ONE UEM.
  3. Workspace ONE UEM calls Microsoft API to obtain information about the patches to display in the console.
  4. Based on configured policies and admin actions, Workspace ONE UEM grants or declines the patch to be installed.
  5. Devices connect to Microsoft Update Servers to download and apply the patches.
  6. If Delivery Optimization is enabled, devices can also obtain patches from other devices and not directly from Microsoft.
Diagram showing the Windows 10 update workflow, useful for windows update troubleshooting.

Note: Workspace ONE UEM never handles the patches. Workspace ONE UEM is a management and reporting utility for the updates unlike Windows Server Update Services (WSUS) which downloads the patches from Microsoft then transfers the patches directly to the devices when on the corporate network. Therefore, with the modern approach, updates happen in real-time, in the cloud, backed by delivery optimization.

Running the Windows Update Troubleshooter

The fastest way to troubleshoot update issues on your Windows 10 device is to run the Windows Update Troubleshooter. This tool stops the Windows Update Service (wuauserv), clears out the download cache (C:\Windows\SoftwareDistribution) then restarts the Windows Update Service. Therefore, during Windows update troubleshooting, you do not have to check if the service is running or if there are any issues with the cache manually.

Run the Windows update troubleshooter from your Windows 10 device.

Verifying Workspace ONE UEM Sent the Correct Windows 10 Updates

The next steps help you to validate that the device is receiving the correct updates information from Workspace ONE UEM.

1. Validate the Device Received the Windows 10 Updates Profile

Validate the Device Received the Windows 10 Updates Profile

First, check that the device installed the profile successfully. If not, see the troubleshooting steps in the Troubleshooting Profiles section.

2. Validate Windows Update UI Shows Correct Values

If you recently pushed out a profile and do not see the Windows Update settings UI update (left screenshot), then perform the next steps:

  1. Restart the Windows Update Service (wuauserv).
  2. Click Check for Updates.
  3. Close and re-open settings and the settings should be updated (right screenshot).

Note: You can now View configured update policies (this setting does not show values). This displays all the settings that Workspace ONE UEM is controlling. These configured settings will also be grayed out for the end-user.

3. Validate Settings Using Registry

If you cannot update the Windows Update settings menu UI, then check the registry to view all the configured update values. For more details on using the registry to troubleshoot profiles, see the Troubleshooting Profiles section. This registry location shows only what was sent through MDM. If the domain is pushing out settings using GPO, these settings could be overridden on the device.

Note: If you are using GPO to configure Windows Updates and you want to use Workspace ONE UEM, consider sending down a custom settings profile leveraging the VMware Policy Builder to deploy the MDM Wins Over GP setting, part of the Policy/Control Policy Conflict CSP.

4. Delivery Optimization Activity Monitor

Organizations want to confirm if Delivery Optimization is reducing network traffic across the WAN. You can validate each device's delivery optimization activity by navigating to Settings > Update & Security > Windows Update > Advanced Options > Delivery Optimization > Activity Monitor. The activity monitor displays the download and upload statistics for this target machine.

Windows Update Troubleshooting Using Event Viewer and PowerShell cmdlets

If you have verified the Workspace ONE UEM configuration but Windows 10 updates fail, you need to seek further Windows update troubleshooting assistance. You can use Event Viewer to gather detailed error and status messages to check in Google or report back to Microsoft.

Windows Update Troubleshooting Using Event Viewer

The following PowerShell cmdlets are also helpful:

  • The Get-Hotfix cmdlet retrieves hotfixes (also called updates) that have been installed on either the local computer (or on specified remote computers) by Windows Update, Microsoft Update, or Windows Server Update Services; the cmdlet also retrieves hotfixes or updates that have been installed manually by users.
  • The Get-WindowsUpdateLog cmdlet merges and converts Windows Update event trace log (ETL) files into a single, readable WindowsUpdate.log file. Windows Update Agent uses Event Tracing for Windows (ETW) to generate diagnostic logs. Windows Update no longer directly produces a WindowsUpdate.log file. Instead, it produces ETL files that are not immediately readable as written.
Windows Update Troubleshooting Using PowerShell cmdlets

Troubleshooting Workspace ONE AirLift


VMware Workspace ONE AirLift is a server-side connector that simplifies and faciliates the journey to modern management. Workspace ONE AirLift bridges administrative frameworks between Microsoft System Center Configuration Manager (ConfigMgr) and Workspace ONE UEM.

This bridge allows administrators to focus on moving co-management workloads and applications to the appropriate platform without redefining device and group memberships. Workspace ONE AirLift provides seamless adoption of co-management benefits and eases the transition on a collection-by-collection basis addressed toward particular use cases.

This exercise helps you to explore some of the high-level troubleshooting tasks to get Workspace ONE AirLift setup and validate it can communicate with SCCM and Workspace ONE UEM correctly.

Troubleshooting Workspace ONE AirLift Installation

If the Workspace ONE AirLift install or uninstall fails for some reason, complete the following steps.

1. Enable Logging

You can enable logging for installing or uninstalling with the following command: “AirLiftSetup #.#.exe” -i -l install_log.txt

The installation logs are produced by MongoDB and Workspace ONE AirLift resides in the current directory where the previous command was called. The following log files are generated:

  • install_log.txt — high-level install log
  • install_001_MongoDbComunity.txt — verbose MongoDB install log
  • install_002_AirliftInstaller.txt — verbose install log

SQL Server Express 2017 installation logs reside in %PROGRAMFILES%\Microsoft SQL Server\140\Setup Bootstrap\Log. For more details, see SQL Server Setup Log Files.

2. Check Event Viewer

After reviewing the installation logs, always check Event Viewer logs (Windows Logs > System/Application) for details about other software or system configuration which might be interfering with Workspace ONE AirLift, MongoDB, or SQL Express.

3. Rule Out Common Issues

Following are some common issues you might encounter when installing or uninstalling the Workspace ONE AirLift product.

  • Pending Reboot or Upgrades
    • Ensure there are no pending reboots (third-party apps or Windows updates) before attempting to install Workspace ONE AirLift. If you attempt to install Workspace ONE AirLift with pending reboots, SQL Server will fail to install.
  • Reinstalling Workspace ONE AirLift using Different User Accounts
    • When reinstalling Workspace ONE AirLift with different user accounts, the user may encounter installation failures. The original (first) user to install Workspace ONE AirLift and SQL who has sysadmin/dbcreator privileges must remove the Workspace ONE AirLift database manually through SQL Server Management Studio - SSMS (or other means). The user can then create a new Security Login for the new installing user with sysadmin privileges or modify the permissions at the group level for the EXPRESS2017 instance.
  • Uninstalling Workspace ONE AirLift Fails Due to Files in Use
    • The uninstall fails if the program files directory is open or being used by another process. For example, command prompt (cmd) is opened in C:\Program Files\VMware\VMware Airlift.

4. Check for SQL Installation Failures

Because Workspace ONE AirLift installs SQL Server Express 2017, there may be situations when the SQL installation fails, such as:

  • There are existing SQL Server components installed on the machine (these versions may be incompatible with SQL Server Express 2017)
    • Remove all SQL Server components that are not actively used by another instance, then reboot and attempt to install Workspace ONE AirLift again.
      Note: Best practice is to install Workspace ONE AirLift on a clean machine dedicated to running Workspace ONE AirLift.
  • The machine needs certain updates and patches
  • A newer version of VC++ is installed, for example, 2017
  • The machine has pending updates/reboot
  • Existing Airlift.mdf when installing SQL Server
    • Best practice is to install Workspace ONE Airlift on a clean VM or remove existing *.mdf files under EXPRESS2017 instance data directories, for example, C:\Program Files\Microsoft SQL Server\MSSQL14.EXPRESS2017\MSSQL\DATA. If there is an existing Workspace ONE AirLift database under the SQL Server instance EXPRESS2017, the recommendation is to cleanly delete the database through SSMS.


Troubleshooting the SCCM Connection

Connecting Workspace ONE AirLift to SCCM and achieving successful synchronization can be challenging due to a range of environment factors. Because SCCM is critical infrastructure in any organization, SCCM is often deployed with tight networking, management, and access controls. Networking, transport restrictions, domain trusts, authentication methods, access controls, and SCCM settings can vary greatly between organizations. This section covers the SCCM connection flow and how to troubleshoot and resolve commonly experienced errors.

As in most troubleshooting cases, the Workspace ONE AirLift log files in %PROGRAMDATA%\VMware\VMware Airlift\logs are the best reference point.

1. Understand How AirLift Connects SCCM and Workspace ONE UEM

The SCCM connection flow is as follows:

  1. Workspace ONE AirLift attempts to establish a remote PowerShell session with the specified SCCM server.
  2. PowerShell uses a common Windows management service called Windows Remote Management, also commonly referred to as WinRM:
    1. This is established over HTTP on port 5985 or HTTPS on port 5986. In rare situations, WinRM is configured to use alternative ports.
    2. The incoming ports must be open on the firewall on the SCCM server.
    3. NAT traversal, port forwarding rules, HTTP proxy servers, and intermediate firewalls can impact the endpoint address, ports used, and connection configuration.
    4. If connecting over HTTPS, this requires the typical web flow for establishing certificate trust. Only server-side certificates are supported.
    5. The WinRM service authenticates the client using Kerberos, NTLM (or Negotiate), depending on WinRM configuration. In some rare circumstances, CredSSP can be used for double-hop authentication.
    6. The WinRM service uses access control based on certain security group memberships.
  3. After the remote PowerShell session is established, WMI queries are made on SCCM objects to extract data.
    1. WMI implements its own additional layer of access control.
    2. The SCCM WMI provider itself further authorizes the client based on SCCM roles, permissions, and security scope settings.

2. Review the SCCM Connection Checklist

The SCCM connection checklist is as follows:

  • Check Windows Remote Management (WinRM) is installed and configured.
  • Take note of WinRM configuration settings; in particular:
    • Transport (HTTP/S)
    • Port — Use of non-default ports requires additional configuration in Workspace ONE AirLift
    • Server Certificate — Required for server authentication when using HTTPS transport
    • Enabled Authentication Methods — Kerberos should be enabled, NTLM and Negotiate might be enabled
  • From the host running Workspace ONE AirLift:
    • Ensure SCCM is addressable and reachable, taking into consideration intermediate networking infrastructure such as router, NAT, firewalls, and web proxies.
    • If using HTTPS, ensure SCCM host name matches the server certification name exactly and certificate is trusted directly or has a chain of trust.
    • If Kerberos authentication is enforced in WinRM, check that the Workspace ONE AirLift machine is joined to the same domain as the SCCM host, or in a domain with a two-way trust relationship with the SCCM host domain.
    • If Negotiate or NTLM authentication is permitted in WinRM, the same strict domain-trust relationship is not required.
    • Ensure the SCCM service account specified has read permissions on the SCCM file share where applications and packages can be accessed. This is required if using the Workspace ONE AirLift application migration feature.
  • On the SCCM host:
    • The SCCM service account specified in Workspace ONE AirLift must have permissions to:
      • Establish a remote PowerShell (WinRM) session
      • Make calls to the SCCM WMI provider (also known as the SMS WMI Provider)
      • Query objects such as collections, devices and applications. A higher level of write permissions are required to create AirWatch enrollment applications in SCCM. For more details, see Workspace ONE AirLift Requirements in VMware product documentation.
    • If the account is a local administrator on the SCCM, WinRM and WMI permissions are implicitly on. Otherwise:
      • Ensure account is a member of the local Remote Management User group on the SCCM host.
      • Ensure account has permission to WMI namespace for the SMS\site_<site-code>. Use wmimgmt.msc to configure these settings.
  • Use the Save button on the SCCM connection settings view in the Workspace ONE AirLift web console to perform a full end-to-end connection test.

3. Review Common Errors

This section describes some common errors you might encounter when troubleshooting SCCM connection to Workspace ONE AirLift.

  • User Name and Password are Incorrect
    • This error indicates some form of client authentication problem. Often this is a simple case of having the wrong password but can also occur when there is a lack of domain trust which is incompatible with the authentication method. For example, if NTLM is disabled and Kerberos is enforced, a two-way trust relationship between the Workspace ONE AirLift and SCCM machines is mandatory. One common problem is the Workspace ONE AirLift machine is not joined to the domain.

      When receiving any form of authentication error, it is safe to assume the networking and WinRM transport connection has been established and working as expected.
  • Unauthorized (or Authorization Errors)
    • Authorization problems are common due to the extensive security features of SCCM and the Windows server it is hosted on.

      The first permission check is performed by the Windows Remote Management (WinRM) service for establishing the remote PowerShell session. If the client account is not a member of the local Administrators group, then either add the account to the Administrators group or add to the local Remote Management Users group. From a least privilege stance, adding to Remote Management Users is preferred.

      The second permission check is performed by WMI for the SCCM's WMI Provider, known as the SMS Provider. Account security permission can be configured either directly using wmimgmt.msc on the ROOT\SMS or ROOT\SMS\site_<site-code> namespace, or by adding to the local SCCM\SMS Admins group. If the log message indicates some form of WMI authorization failure, then it can be assumed the WinRM channel for the remote PowerShell session has been authorized and established.

      The final authorization is required on SCCM itself. The account must be a member of a sufficiently privileged role for Workspace ONE AirLift to perform the queries and actions required. These are set by roles, permissions and security scopes configured within SCCM.

For more details, see Workspace ONE AirLift Requirements in VMware product documentation.

When receiving any form of authorization failure, it is safe to assume the network connection, WinRM transport connection, and client authentication mechanism are working as expected.

  • WMI Quota Violation
    • The WMI provider service on the SCCM server has a strict memory limitation, called the WMI quota, by default set to 512MB. When extracting SCCM data in large environments, this memory limitation might be exceeded. This error might occur during the extraction of a large number of devices. The recommended solution is to increase the WMI quota on the SCCM server; increasing the MemoryPerHost WMI setting to at least 1GB should resolve this issue. Marginally increasing the memory allocated to the virtual machine running SCCM is advisable to accommodate this change.

For more details, see Increase WMI Quota Properties to Maximum Values.

  • Call Cancelled
    • This error can also occur due to reaching WMI memory limits, typically while extracting device data. The solution is to increase the WMI quota limit in the same way as previously described for WMI Quota Violation errors.

Summary and Additional Resources


This operational tutorial provided steps to troubleshoot Windows 10 features in a Workspace ONE UEM environment. Procedures included locating log files and registry keys, validating console settings, and using Fiddler as a troubleshooting tool. The following procedures were also included:

  • Troubleshooting Enrollment
  • Troubleshooting Profiles & Baselines
  • Troubleshooting App Management
  • Troubleshooting Peer to Peer Networks and CDNs
  • Windows Update Troubleshooting
  • Troubleshooting Workspace ONE AirLift

Additional Resources

For more information about Workspace ONE, explore the VMware Workspace ONE Activity Path. The activity path provides step-by-step guidance to help you level-up in your Workspace ONE knowledge. You will find everything from beginner to advanced curated assets in the form of articles, videos, and labs.

Additionally, you can check out the VMware Workspace ONE and VMware Horizon Reference Architecture which provides a framework and guidance for architecting an integrated digital workspace using VMware Workspace ONE and VMware Horizon. 


About the Author

This tutorial was written by:

  • Josue Negron, Staff Architect, End-User-Computing Technical Marketing, VMware


Your feedback is valuable. 

To comment on this tutorial, contact VMware End-User-Computing Technical Marketing at

Filter Tags

Workspace ONE Workspace ONE Access Workspace ONE UEM Document Operational Tutorial Advanced Windows 10 Deploy Modern Management