Troubleshooting Windows Devices: Workspace ONE Operational Tutorial

VMware Workspace ONE UEM 2101 and later
VMware Workspace ONE UEM 9.2



Note: This content was created for Windows 10, but the basic principles and tasks outlined also apply to your deployment of Windows 11.

VMware provides this operational tutorial to help you with your VMware Workspace ONE® environment. In this tutorial, you learn how to troubleshoot Windows Desktop 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 Desktop troubleshooting guide provides general troubleshooting guidance, as well as solutions to specific problems for various Windows Desktop features in Workspace ONE UEM. The exercises in this tutorial are targeted to those with previous Windows Desktop management experience in the Workspace ONE UEM product.


This operational tutorial is intended for IT professionals and Workspace ONE UEM administrators of existing production environments.

Knowledge of additional technologies such as network, VPN configuration,  VMware Workspace ONE® Intelligence and VMware Workspace ONE® UEM is also helpful.

Getting Started with Windows 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 Troubleshooting Cheat-Sheet

The following Windows 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 Profiles

Use these steps to identify the 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 that the setting is supported on the Windows edition/version being used.

☐In Fiddler, check error codes.

Troubleshooting Windows 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 that 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 and Windows 11

☐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

☐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, and so on.) 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 and Windows 11

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 and Windows 11 devices. This section explores these components in detail. It is important to understand these components before proceeding with log analysis and Windows 10 and Windows 11 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

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
Description Native MDM client built into the device Workspace ONE Intelligent Hub installed on the device
Communication WNS AWCM
  • 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.

Client Uses
Software Distribution Client (SFD/SFX) Used to install Win32 applications.
Adaptiva Client Enables peer-to-peer distribution of Win32 apps.
SCCM Integration Client Prevents SCCM (ConfigMgr) from deactivating 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. Allows end-users to access the unified app catalog, people search, notifications, and account settings. 
Workspace ONE 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 and Windows 11

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

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. CDN*
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.

1. 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.1. Request Device Log

To start troubleshooting Windows 10, request Windows 10 device logs in the Workspace ONE UEM console.
  1. Navigate to the desired device you want to collect logs from, then click More Actions.
  2. Click Request Device Log.

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

1.4. View Logs

Extract logs for troubleshooting Windows 10.

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 on understanding these logs.
    • CbLauncher: contains logs related to Carbon Black launcher. For more details, refer to the Workspace ONE UEM Logs section of this tutorial.
    • 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 the 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 the 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 the 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.

2. 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 in the Workspace ONE Intelligent Hub.

On the taskbar 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.

Note: Users can now access Hub Status directly within the Workspace ONE Intelligent Hub by navigating to their account page, then clicking on Hub Status.

When troubleshooting windows, you can access Hub status directly within Workspace ONE Intelligent Hub.

3. 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 
BITS Client
Collects BITS information, this is important when encountering issues with apps and Windows Updates not downloading properly.
  • Event Viewer (Local) > Applications and Services > Microsoft > Windows > Bits-Client

4. 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. 

5. 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
Workspace ONE Intelligent Hub Device-Level logs
  • 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 — [Deprecated - renamed AwWindowsIpc, see User-Level Logs below] 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.


Workspace ONE Intelligent Hub UI Logs

  • 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. 

Workspace ONE Intelligent Hub User-Level Logs

  • AwWindowsIpc-YYYYMMDD.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.
C:\Program Files (x86)\Airwatch\AgentUI\Baseline
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. 
Workspace ONE 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 Assist
  • aplog-YYMMDD-hhmmssms.log — Logs contains details regarding to remote support using Workspace ONE Assist. 

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

6. 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.  

6.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.

6.2. Update Logging Level

Update logging level in the configuration file to help with Windows troubleshooting.

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 Deactivates logging for the service.
Error Only captures ERROR events.
Warning Captures both WARN and ERROR events. 
Information 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. 

7. Using Workspace ONE Discovery for Troubleshooting

The following tool is a VMware Fling and is not officially supported, however, it's a must have tool for troubleshooting or to use during your evaluation of Workspace ONE for Windows 10 management.

The Workspace ONE Discovery Fling enables you to quickly view installed apps, certificates, updates, and basic enrollment info from the device point of view and review the Workspace ONE related services. The Discovery tool shows which applications have been successfully deployed, use the granular view to see exactly what has been configured with Profiles, view User & Machine certificates and see which Microsoft Windows Updates have been applied.

Overview – shows you who enrolled the device, which Workspace ONE UEM tenant it is enrolled to and which services are running in relation to Workspace ONE.

Packages – Lists the applications that have been installed by Workspace ONE UEM to the endpoint.

Profiles – Lists the changes made to the endpoint based on the profiles pushed by Workspace ONE UEM.

User Certificates – Lists the user certificates installed on the endpoint.

Machine Certificates – Lists the device certificates installed on the endpoint.

Windows Updates – Lists the Windows Updates installed on the endpoint.

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 > Intelligent Hub Application
  2. If you want to use the Hub 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 that 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 not selected.

4. Check Azure AD Settings

Azure AD Settings
  1. Navigate to System > Enterprise Integration > Directory Services.
  2. 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 or ms-DS-ConsistencyGuid 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. If you are on the latest version of the console, you will not see this option. If you are on an older version, verify that Enable TLS Mutual Auth for Windows is set to your required setting. Most customers have this deactivated. If you are unsure, deactivate 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 Desktops

Fiddler is a free web debugging proxy server tool that 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 helps 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. Deactivate 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 push 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.

Using SyncML Viewer for Troubleshooting Windows Desktops

The open-source SyncML tool, developed by Oliver Kieselbach (@okieselb), can present the SyncML protocol stream between the Windows 10 client and management system. In addition, it does some extra parsing to extract details and simplifies the analysis. If your goal is to only monitor/inspect the MDM (OMA-DM) traffic,  this tool is suitable. However, if you are also interested in inspecting traffic from the Workspace ONE Intelligent Hub then refer to Using Fiddler for Troubleshooting Windows 10.

The tool uses ETW to trace the MDM Sync session. In general, the tool can be very handy to troubleshoot policy issues. Tracing what the client actually sends and receives provides deep protocol insights. Verifying OMA-URIs and data field definitions. It makes it easy to get confirmation about queried or applied settings.

This exercise helps you to download, install, and use this open-source tool on a Windows 10 device.

For more info, refer to Oliver's blog Windows 10 MDM client activity monitoring with SyncML Viewer.

Installing SyncML Viewer

Find Fiddler download in Web search

To download the latest version of SyncML Viewer, go to:

  1. Find the latest version.
  2. Click the latest version.

1. Download SyncML Viewer

Click Fiddler free download button
  1. Click Download.
  2. Open the downloaded compressed folder (.zip).

2. Extract SyncML Viewer

Fields to complete Fiddler download.
  1. Select Extract.
  2. Click Extract all.

Finish extracting by following the on-screen prompts.

3. Run SyncML Viewer

Double-click SyncMLViewer.exe to run the SyncML Viewer application.

Tip: You can also drag the icon down to your taskbar for quick access.

Running and Analyzing SyncML Viewer Captures

In this section, use SyncML Viewer for troubleshooting Windows 10 issues. Learn how to run a quick capture, view the data, and save your captures.

1. Run the OMA-DM Syncs

Start and stop captures when troubleshooting windows 10.

When SyncML Viewer is running, it will automatically capture OMA-DM traffic. You can also choose to initiate syncs by clicking MDM Sync in SyncML Viewer, clicking Sync under Access Work or School account page locally on the device, or from the Workspace ONE UEM console.

  1. Click one of the Sync options to populate a stream.

The SyncML Representation Protocol Steam tab will show a running list of all SyncML data. You can also clear the stream or export as a .txt file by clicking Save As.

2. SyncML Sessions and Messages View

Inspect traffic for Windows 10 troubleshooting.

The SyncML Sessions/Messages tab provides an easier way to parse through the SyncML traffic. This is the main reason why I recommend this tool to anyone who is not comfortable using Fiddler. It provides a clean UI to easily see what is being received and sent by the device. In the above sample, you can see a standard sync reporting the device's ID, Manufacturer, and Model, along with other information.

Every sync action will generate a new entry under SyncML Sessions.

3. Additional Features

Check the About tab for helpful links on troubleshooting. This provides quick access to many of the same links mentioned in this guide. The Action menu option also provides quick access to helpful troubleshooting areas also mentioned in this tutorial.

Troubleshooting Windows Desktop 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 Desktop enrollment issues step by step.

Pro Tip: BEFORE following this troubleshooting section for Onboarding/Enrollment of Windows Desktop Devices, see the following tutorials for different methods of onboarding Windows Desktops.

Troubleshooting Common Workspace ONE UEM Enrollment Issues

This Windows Desktop 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 Date and Time Settings on Windows 10 Device to help with Windows troubleshooting.

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 Workspace ONE Network Requirements in the VMware Ports and Protocols site which lists required endpoints. For additional details, see the Microsoft article Manage Windows 10 Connection Endpoints.

2.1. Verify Network and Internet Settings

Check Network and Internet Settings on a Windows 10 device to help with Windows troubleshooting.

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

Verify Workspace ONE UEM and Microsoft endpoints to help with Windows troubleshooting.

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: more specifically
      • For AMD 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.
  • Windows Autopilot: Windows Autopilot depends on a variety of internet-based services. For more information, see Windows Autopilot networking requirements.

For more details on Workspace ONE networking requirements, refer to Workspace ONE Network Requirements in the VMware Ports and Protocols site which lists required endpoints. In addition, for more details on Windows 10 connection endpoints, refer to Manage Windows 10 Connection Endpoints and for more details on Device Health Attestation requirements, refer to Control the health of Windows 10-based devices.

3. Check Accounts

Verify administrator access on a Windows 10 device to help with Windows troubleshooting.

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

Check staging accounts when troubleshooting Windows.

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

Check Windows 10 Device Root Certificate and Application Certificate when troubleshooting Windows.

After a successful enrollment, you should have two certificates from Workspace ONE UEM. The Enrollment certificate is located in Certificates - (Local Computer) > Personal > Certificates and the Application certificate is located in Certificates - Current User > Personal > Certificates, as shown in the screenshots. 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.

Enrollment Certificate: 

  • Subject Name Format - AW::{Token}::{Device Services URL}::{Token}
  • Issued by AwDeviceRoot
  • Workspace ONE Intelligent Hub will not successfully check-in without the Enrollment Certificate

Application Certificate: 

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

5. Check OS Activation and Build

Check OS Activation and Build for Windows troubleshooting.

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 for the best results. Knowing which Windows edition is being used is helpful 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.

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 deactivated.

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 deactivated.

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 deactivated as this is used to download various packages.

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

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

This exercise walks through troubleshooting Windows 10 native/built-in 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-users 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 window. The Group ID is required when enrolling your device.

2. Capture Access Work Enrollment Traffic

Note: Ensure that you have Fiddler in capture mode to capture all the network traffic during device enrollment. To learn how to get started with Fiddler, refer to Using Fiddler for Troubleshooting Windows 10.

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 leads 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, check the contents of profiles being pushed, and return error codes that 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 Desktop 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.

Pro Tip: BEFORE following this troubleshooting section for Policies of Windows Desktop Devices, please see the below tutorial for different methods of onboarding Windows Desktops.

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

Navigate to the Restrictions profile to help with Windows troubleshooting.

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

Review updates to Fiddler when troubleshooting Windows 10.

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 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 covers 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 commands 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 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. You can also leverage the Microsoft MDM Migration Analysis Tool (MMAT) to generate a report of which policies map to modern policies. This might be beneficial if you want to quickly run an assessment on your local domain-joined machine to get an idea of how many policies can be mapped to modern policies.

Pro Tip: BEFORE following this troubleshooting section for Policies of Windows Desktop Devices, please see the below tutorial for different methods of onboarding Windows Desktops.

Workspace ONE Baselines Process Flow

The most effective method to pinpoint why Workspace ONE Baselines are not functioning properly is to understand the high-level process flow. The following diagram shows which component to focus your troubleshooting efforts: Workspace ONE Intelligent Hub, the local Baselines folder, or the Workspace ONE server components.

After a Workspace ONE Baseline is assigned/updated or a device completes enrollment, the Workspace ONE Intelligent Hub will download the Baseline from Workspace ONE. The Intelligent Hub will process the metadata and store this metadata under the following directory: %ProgramFiles(x86)%\Airwatch\AgentUI\Baseline. Before attempting to apply the Baseline, the Intelligent Hub will generate backups of the current policies on the device, which will be used for reverting the policies when the Baseline is removed. The Intelligent Hub along with other clients on the device process the metadata and apply all of the policies. Please note that although policies are applied, some policies require a device reboot to fully apply. Therefore, policy compliance is sent back to Workspace ONE after a device reboot.

Understanding this flow allows you to focus your investigative efforts on pinpointing the root cause.

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. Example, GPO vs MDM CSP vs Workspace ONE Baselines.

When you leverage a new mechanism, it is best practice to deactivate/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. 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, see 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 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. 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).

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 higher precedence than GPO policies on the device. There is a CSP that can be deployed to managed devices that 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 win 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.

2.1.1. Install Settings

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

2.1.2. 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 the 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. 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. When you feel comfortable with the policies and how they are applied to the device, you can use 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 when troubleshooting Windows 10.

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 the command prompt to programmatically generate the report.

Option 1: Export your Management Log Files

Export the MDM diagnostic report from your Windows device when troubleshooting Windows 10.

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.

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

Review the MDM Diagnostic Report

Both of the previous options will generate the following report which contains detailed information (when expanded) about the device and its 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 Desktop introduces several new configuration service providers (CSP) to push out windows apps and desktop MSIs. Workspace ONE UEM supports not only MSIs (like most of our MDM competitors) but also supports MST, MSP, EXE, and ZIP through Software Distribution. 

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

It is important you read Deploying Traditional Win32 Applications to Windows Devices: Workspace ONE Operational Tutorial before troubleshooting. 

The tutorial will assist you in tasks like:

  • Understanding Application Installation Behavior
  • Working with ZIP/EXE Files
  • Recommended Configurations for VMware Applications
  • Retrieving Application Installation/Uninstall Parameters

Windows Application Delivery Logic

Troubleshooting MSI Apps

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. In this section, you will learn how to troubleshoot these MSI apps.

1. Check Registry Key Status Codes

Check registry key enterprisedesktopappmanagement when troubleshooting Windows.

First, check the registry if your apps fail to install or take too long. 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 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) match a folder that already exists, then it will fail to install, thinking the application is already installed. This occurs only during a broken unenrollment. 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 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
10 Initialized
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

Check 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 EXE/ZIP Files

Workspace ONE UEM supports deploying any type of desktop (Win32) applications using software distribution, however, this is 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 VMware Knowledge Base: Software Distribution: Tips and Troubleshooting (2960987).

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 the 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, the registry hive must be in a 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 the device: The install command has been 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 the installation was successful but detection failed, the client will roll back the installation of the application using the provided uninstall command.
  • MDM removed: The application has successfully uninstalled following the initiation of the application removal through Workspace ONE UEM.

5. Check Device Registry Logs

Check device registry logs when troubleshooting Windows 10.

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-Xcontains apps being pushed to the user context.
      • Includes InstallCountvalue:
        • 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 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 installation failed. However, if the application was never installed, you already know it failed.

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.


Improving Performance with Content Delivery Network (CDN) Integration

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.
  • Improving software distribution performance - Similarly, CDN integration can be effective in improving the performance of software distribution for Windows Desktop 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), please refer to this KB article: Introducing IP Limited Content Distribution Network (CDN) capabilities in Managed Hosting SaaS Workspace ONE Environments.

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

On-premises Workspace ONE UEM environments using Workspace ONE UEM 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 on this page.
  3. Save your settings to enable CDN.

Note: For detailed step-by-step instructions for your on-premise customers, see VMware Docs: Configure a CDN for Provisioning, On-Prem Only.

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 Workspace ONE (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 Workspace ONE (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 Workspace ONE (AirWatch) Origin Server. Applications always reside at the origin server. Devices are pointed to the Workspace ONE (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 the 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 an 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 Workspace ONE (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 Workspace ONE (AirWatch) Origin Server. 
  5. Device completes the download and proceeds with application installation. 

Troubleshooting Workspace ONE Sensors


In Workspace ONE UEM, sensors allow you to query specific device data using PowerShell scripts for Windows Desktops. This exercise helps you to check your sensors and determine the root issue.

Note: You must have at least one sensor created and assigned to a device to follow these steps. You can find or bulk-add samples on GitHub.

Sensor Logging on the Device

Workspace ONE UEM does not directly store the data returned by the sensor. All sensor data is stored in Workspace ONE Intelligence. Devices execute the sensors and then send the data to a Device Services endpoint which processes the data and sends it to Workspace ONE Intelligence via the connector. It is possible to retrieve the sensor data via the Workspace ONE Intelligence API, however, most issues are with the sensor execution on the device. This section will focus on how to troubleshoot sensors on a managed Windows Desktop device and validate the data being sent from the device to Device Services.

Refer to Getting Started with Workspace ONE Intelligence APIs, Getting Started with Workspace ONE Intelligence Reports and Dashboards, and Automating Battery Replacement with Workspace ONE Intelligence for more details on using Workspace ONE Intelligence and Device Sensors to create reports, dashboards, and automations.

1. What does the Workspace ONE Intelligent Hub Log show us about Sensors?

The below sample AWProcessCommands.log shows the successful execution of the os_edition Sensor. This log has been changed from level information to debug to show that it is not necessary to set the logs to debug. The following logs contain information about the execution of a device sensor: AWProcessCommands.log, TaskScheduler.log, and PowershellExecutor.log. You will notice that none of the logs will display the contents (script) or the resultant value being returned to Workspace ONE. We will have to take a different approach to viewing this info.

Pro Tip: Refer to the Locating Log Files and Registry Keys for more information regarding the log files and how to verbose, collect, understand each of the logs.

Info 	VMware.WUA.DeviceSensor.Business.DeviceSensorSampleSender.DeviceSensorPowerShellExecutor.ExecuteSensor	Executing Sensor os_edition.  
Debug	AW.Win32.Utilities.Powershell.PowershellExecutionHelper.ExecutePowershellCommand	 Method: AW.Win32.Utilities.Powershell.PowershellExecutionHelper.ExecutePowershellCommand; Parameters: command = *****, timeout = 120, executionArchitecture = Either64Or32Bit, executionContext = SYSTEM;  
Info 	AW.Win32.Utilities.Powershell.PowershellExecutionHelper.ExecutePowershellCommand	Attempting to run Powershell command with architecture Either64Or32Bit in SYSTEM context with timeout 120  
Info 	AW.Win32.Utilities.Powershell.PowershellExecutionHelper.ExecutePowershellCommand	Launching powershell executor process  
Debug	AW.Win32.Utilities.GenericHelper.Helper.GetUInstalledPath	 Method: AW.Win32.Utilities.GenericHelper.Helper.GetUInstalledPath; Parameters: <N/A>;  
Debug	AW.Win32.Utilities.GenericHelper.Helper.GetUInstalledPath	 Method: AW.Win32.Utilities.GenericHelper.Helper.GetUInstalledPath; Returns: C:\Program Files (x86)\Airwatch; Duration: 0 ms;  
Debug	AW.Win32.Utilities.ProcessStartHelper.AwProcess.Start	 Method: AW.Win32.Utilities.ProcessStartHelper.AwProcess.Start; Parameters: info = System.Diagnostics.ProcessStartInfo;  
Debug	AW.Win32.Utilities.ProcessStartHelper.AwProcess.Start	 Method: AW.Win32.Utilities.ProcessStartHelper.AwProcess.Start; Returns: True; Duration: 0 ms;  
Info 	AW.Win32.Utilities.Powershell.PowershellExecutionHelper.ExecutePowershellCommand_$_	Powershell command run completed  
Debug	AW.Win32.Utilities.Powershell.PowershellExecutionHelper.ExecutePowershellCommand	 Method: AW.Win32.Utilities.Powershell.PowershellExecutionHelper.ExecutePowershellCommand; Returns: *****; Duration: 1078 ms;  
Info 	VMware.WUA.DeviceSensor.Business.DeviceSensorSampleSender.DeviceSensorPowerShellExecutor.ExecuteSensor	sensor exited with the exit code 0.   
Debug	VMware.WUA.DeviceSensor.Business.DeviceSensorSampleSender.DeviceSensorSampleSender.SendSample	 Method: VMware.WUA.DeviceSensor.Business.DeviceSensorSampleSender.DeviceSensorSampleSender.SendSample; Parameters: <N/A>;  
Debug	AW.Win32.Utilities.GenericHelper.Helper.GetServerName	 Method: AW.Win32.Utilities.GenericHelper.Helper.GetServerName; Parameters: <N/A>;  
Debug	AW.Win32.Utilities.GenericHelper.Helper.GetServerName	 Method: AW.Win32.Utilities.GenericHelper.Helper.GetServerName; Returns:; Duration: 0 ms;  
Debug	AW.Win32.Unified.Helper.UnifiedHelper.FetchUdidWindowsRt	Fetching UDID for WindowsRt.  
Debug	AW.Win32.Utilities.AwWebClient.InitializeAwWebRequest	 Method: AW.Win32.Utilities.AwWebClient.InitializeAwWebRequest; Parameters: pRequestUrl =, pRequestMethod = POST, deviceUdid = *****, hmacKeyBytes = *****, contentType = application/json, requestBody = System.Byte[], serverDateTime = 1/1/0001 12:00:00 AM, bundleId = com.airwatch.windowsprotectionagent, airWatchAuthToken = *****;  
Debug	AW.Win32.Utilities.AwWebClient.InitializeAwWebRequest	DateTime being used : 12/22/2020 8:41:15 PM  
Debug	AW.Win32.Utilities.AwWebClient.InitializeAwWebRequest	Generating Signed Body.  
Debug	AW.Win32.Utilities.AwWebClient.InitializeAwWebRequest	 Method: AW.Win32.Utilities.AwWebClient.InitializeAwWebRequest; Returns: <N/A>; Duration: 15 ms;  
Debug	AW.Win32.Utilities.ProxyHelper.ProxyHelper.DiscoverProxy	 Method: AW.Win32.Utilities.ProxyHelper.ProxyHelper.DiscoverProxy; Parameters: destinationUri =, isLoadCacheProxy = True;  
Debug	AW.Win32.Utilities.ProxyHelper.ProxyHelper.GetHostProxyFromRegistry	 Method: AW.Win32.Utilities.ProxyHelper.ProxyHelper.GetHostProxyFromRegistry; Parameters: hostName =;  
Debug	AW.Win32.Utilities.ProxyHelper.ProxyHelper.GetHostProxyFromRegistry	Proxy for host name found in Registry. Proxy DIRECT  
Debug	AW.Win32.Utilities.ProxyHelper.ProxyHelper.GetHostProxyFromRegistry	 Method: AW.Win32.Utilities.ProxyHelper.ProxyHelper.GetHostProxyFromRegistry; Returns: DIRECT; Duration: 0 ms;  
Debug	AW.Win32.Utilities.ProxyHelper.ProxyHelper.DiscoverProxy	 Method: AW.Win32.Utilities.ProxyHelper.ProxyHelper.DiscoverProxy; Returns: <N/A>; Duration: 0 ms;  
Info 	VMware.WUA.DeviceSensor.Business.DeviceSensorSampleSender.SampleServiceGateway.HandleDeviceSensorResponse_$_	Sensor data sent for : os_edition

The above log shows the successful execution of a device sensor. Each line starts with Info or Debug: showing what is included at the default (Info) level and what gets added when the log is verbose (Debug). All of the required information is included at the default (Info) log level.

The most important line is the one with: sensor exited with the exit code 0. You will see that this device sensor was successful, however, this is where you would also see your errors that are returned. This information is also reported to the Workspace ONE UEM Console, under More > Troubleshooting section under the Device Details view.

The second thing you want to check is the last line: Sensor data sent for : os_edition. This shows that the device was able to successfully send the sensor data to Workspace ONE. This log would also contain information regarding if this step was unsuccessful. In that case, you might want to set the logging level to Debug to get more details or check if there are any issues with Workspace ONE Intelligence or the connector.

2. Capturing the Device Sensor Request

In the previous step, we looked at the Workspace ONE Intelligence Hub logs. We saw that it was not possible to view the device sensor contents or the resultant data. This is due to the security of the product. All data is encrypted on the device and it is not possible to alter the device sensor data on the device. Now we will take a look at how we can view this data by using Fiddler to capture this data in real time.

Review: If you are not familiar with Fiddler, refer to the Using Fiddler for Troubleshooting Windows section of this document.

Capturing the device sensor request when troubleshooting Windows 10.

In the Workspace ONE UEM Console, run a Sensor Query (found under More Actions) for the managed Windows 10 device after launching Fiddler to capture in HTTPS decryption mode. In a few seconds, you should see a GET for https://{DeviceServicesURL}/deviceServices/deviceSensors/{SensorUUID}/definition. In the response (bottom) section of Fiddler switch to JSON view mode. You can now see all of the information about that device sensor including Trigger Type/Event Triggers, Name, Query Response Type, and Script Data. The Script Data is Base64 encoded. You can decode the Script Data from Fiddler or use an online tool.

2.1. Capturing the Device Sensor Response

Capturing the device sensor response when troubleshooting Windows 10.

More importantly, we would like to see the device sensor data being sent to Workspace ONE. Look for a POST request to https://{DeviceServicesURL}/deviceServices/devices/{DeviceUUID}/samples/devicesensor. Switch the Fiddler Inspector view to JSON and we can easily see the value is set to return "Enterprise" as the OS Edition.

Sensors Best Practices

The most common issues with device sensors are with creating the sensors. Follow these best practices to ensure a successful sensor deployment.

Note: Devices with Employee Owned ownership type will be automatically excluded from the Sensor assignment for user privacy reasons.

1. One Sensor per Data Point

Each sensor should only report one data point back to Workspace ONE. The sensor data is sent to Workspace ONE Intelligence and can be leveraged in dashboards, reports, and automations. Filtering and reporting work best when one data point is used and the correct value type is used. You can think of a sensor as the name of a report column. Let's look at a quick example.

Note: Device Sensor samples have a 1 KB limit per sensor with a total sample size limit of 128 KB for all sensors assigned per device. Validation warnings are generated if the device sensor sample size exceeds this limit. Additionally, both Scripts and Sensors have OS limitations on the character length of the script allowed. This may cause issues if you are running larger PowerShell scripts. For more information on these limitations, refer to the following KB article: Length Limits for Workspace ONE Desktop Scripts and Sensors (85891).

1.1. OS Architecture Example

Let's take a look at a quick and simple sensor sample that returns a string to report the OS Architecture as 32-bit or 64-bit. Below is the entire script which is used to report the OS Architecture data point. Notice that we use write-output then $os.OSArchitecture. This means we are accessing a data set and only reporting one attribute. Be sure to run all sensors locally to ensure only one data point is returned.

1.1.1. os_architecture.ps1

# Returns OS Architecture (32-bit or 64-bit)
# Return Type: String
# Execution Context: User
$os=(Get-WmiObject Win32_OperatingSystem)
write-output $os.OSArchitecture 

1.1.2. Returning all Properties

Now, if we were only to return $os, we would see several data points returned. This is why we use $os.OSArchitecture to only return a single data point. Run  Get-WmiObject -Class "Win32_OperatingSystem" | Format-List -Property * in an evaluated PowerShell terminal to see all of the possible properties for Win32_OperatingSystem. You will see OSArchitecture along with many other values. Keep in mind we would need to create a different sensor for each data point.

PSComputerName                            : jnegron-001
Status                                    : OK
Name                                      : Microsoft Windows 10 Enterprise|C:\WINDOWS|\Device\Harddisk0\Partition3
FreePhysicalMemory                        : 4026552
FreeSpaceInPagingFiles                    : 15937608
FreeVirtualMemory                         : 15770480
BootDevice                                : \Device\HarddiskVolume1
BuildNumber                               : 19042
BuildType                                 : Multiprocessor Free
Caption                                   : Microsoft Windows 10 Enterprise
CodeSet                                   : 1252
CountryCode                               : 1
CreationClassName                         : Win32_OperatingSystem
CSCreationClassName                       : Win32_ComputerSystem
CSDVersion                                : 
CSName                                    : jnegron-001
CurrentTimeZone                           : -360
DataExecutionPrevention_32BitApplications : True
DataExecutionPrevention_Available         : True
DataExecutionPrevention_Drivers           : True
DataExecutionPrevention_SupportPolicy     : 2
Debug                                     : False
Description                               : 
Distributed                               : False
EncryptionLevel                           : 256
ForegroundApplicationBoost                : 2
InstallDate                               : 20201023110444.000000-300
LargeSystemCache                          : 
LastBootUpTime                            : 20201222140400.500000-360
LocalDateTime                             : 20201223115116.177000-360
Locale                                    : 0409
Manufacturer                              : Microsoft Corporation
MaxNumberOfProcesses                      : 4294967295
MaxProcessMemorySize                      : 137438953344
MUILanguages                              : {en-US}
NumberOfLicensedUsers                     : 0
NumberOfProcesses                         : 326
NumberOfUsers                             : 2
OperatingSystemSKU                        : 4
Organization                              : 
OSArchitecture                            : 64-bit
OSLanguage                                : 1033
OSProductSuite                            : 256
OSType                                    : 18
OtherTypeDescription                      : 
PAEEnabled                                : 
PlusProductID                             : 
PlusVersionNumber                         : 
PortableOperatingSystem                   : False
Primary                                   : True
ProductType                               : 1
RegisteredUser                            : 
SerialNumber                              : 00319-10220-02938-AB796
ServicePackMajorVersion                   : 0
ServicePackMinorVersion                   : 0
SizeStoredInPagingFiles                   : 16777216
SuiteMask                                 : 272
SystemDevice                              : \Device\HarddiskVolume3
SystemDirectory                           : C:\WINDOWS\system32
SystemDrive                               : C:
TotalSwapSpaceSize                        : 
TotalVirtualMemorySize                    : 33209804
TotalVisibleMemorySize                    : 16432588
Version                                   : 10.0.19042
WindowsDirectory                          : C:\WINDOWS 

2. Be Mindful of Execution Context and Architecture

2.1. Execution Context

  • System: This runs in “system” context and does not depend on a logged-in user. Most sensors should be set to this. If a user is logged out, then sensors will only run on the agent schedule and the Workspace ONE Intelligent Hub will not respond to AWCM commands such as when you manually click Query > Sensors.
  • Current User: This runs as the logged-in user context. Keep in mind this has to be the same as the enrolled user. So if George P. Burdell logs into my system, but it’s enrolled to me, this user sensor won’t run.

2.2. Execution Architecture

Most of the time this should be set to Auto, but you can override the bitness if needed. 

Execution Architecture Description
Auto Runs based on the device's architecture.
32-bit (Forced) Runs in 32-bit regardless of the device's architecture.
32-bit Runs on 32-bit devices only.
64-bit Runs on 64-bit devices only.

3. Align Correct Sensor Response Data Type

The sensor Response Data Type cannot be changed once the sensor has been created. Therefore, select the most appropriate value type for the data that you want reported. It is suggested to poke around Workspace ONE Intelligence to understand how you might use the data and understand the operators for each value type.

Pro Tip: Based on the Sensor's Response Data Type you will see the above corresponding filter options in Workspace ONE Intelligence. Therefore, it is important to choose the right response data type for each of your sensors. This is especially important for versions or other integers and responses in date-time format.

3.1. Force PowerShell Data Type

If you get the following error in the logs or in the Workspace ONE UEM Console then you have a mismatch between the Response Data Type selected for the sensor and what the sensor is returning. To ensure you never run into these errors you can use the GetType() function in PowerShell.

3.1.1. Using GetType()

(write-output (hostname)).gettype()
(write-output (get-date)).gettype() 

You will see that the hostname is a String, while get-date returns as a DateTime data type.

3.1.2. Dynamic Casting

We can force the conversion to a specific data type by adding a prefix of the data type we want to force or convert. This prefix is known as the cast operator and forces the value or variable to the chosen data type.

# Casts String to Integer
# Casts a String variable to Integer
# Casts Get-Date (normally DateTime) to String 
# Casts the String $date variable back to DateTime
# Casts the $True Boolean to Integer
#Casts an Integer to Boolean

The above shows just a few examples, feel free to open up PowerShell ISE and run the commands to get more comfortable with dynamic casting as it is very important to send the correct data type when using sensors.

Note: For more information on dynamic casting or changing the data types in PowerShell refer to How-To: Define PowerShell Data Types.

3.2. Handling Exceptions

It’s recommended to handle exceptions on device sensors, otherwise, the sensor's data will not be returned. Instead, an error message will be available in the logs or on the Device Troubleshooting section in the Workspace ONE UEM Console.

3.2.1. os_java_version.ps1

# Returns Java Version e.g. 8.0.1910.12
# Return Type: String
# Execution Context: User

$javaver = (Get-Command java -ErrorVariable err -ErrorAction SilentlyContinue | Select-Object -ExpandProperty Version)

if ($err.Count -eq 0) {$javaver = $javaver.ToString()}
else {$javaver = "JAVA not found"}

write-output $javaver.ToString() 

We can see that this example has something different compared to the other samples shown so far. Notice we are using the Error Variable and Error Action. The Error Variable passes the error message to the variable you choose, in the above example err. We are then telling the script to silently continue if an error is encountered. In this example we are either returning the version number as a string or "JAVA not found".

If the errors are not handled then the following sample error would be returned to Workspace ONE.

Get-Command : The term 'java' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was 
included, verify that the path is correct and try again.
At line:1 char:11
+ $javaver=(Get-Command java | Select-Object -ExpandProperty Version)
+           ~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (java:String) [Get-Command], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.GetCommandCommand 

Pro Tip: If you want to return the error message gracefully to Workspace ONE, you can leverage the $err variable, however, you will want to access the first error message. E.g. $err[0].ToString()

4. Which Trigger is Best?

There are two types of triggers you can set when assigning sensors in the Workspace ONE UEM Console: schedule or event.

4.1. Schedule

Schedule sensors run based off of the Workspace ONE Intelligent Hub check-in time.

Pro Tip: You can also trigger manually by clicking Query > Sensors on device details page in the Workspace ONE UEM Console or by performing a Sync action from Workspace ONE Intelligent Hub on the device.

4.2. Event

There are a few Event triggers:

  • Login – Any user login event. This is not only tied to the enrolled user but to any user that logs in.
  • Log Out – Same as above but on logout.
  • Startup – Windows system boot up. Since there is no user context, this only works for ones that are configured to run in System context.
  • User Switch – Doing a user switch instead of full logout.

Pro Tip: You can select multiple Event Triggers.

Note: Every 24 hours all sensors will be reported to Workspace ONE irrespective of Event or Schedule Trigger type.

5. Community Sensor Samples

Pro Tip: Don't forget that there are many samples from the community hosted on GitHub.

Windows Update Troubleshooting


Keeping your Windows Desktop devices up-to-date helps to protect them from security risks and viruses. Because Microsoft has moved Windows 10 and 11 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 that they are set correctly.

How Do Windows Desktop 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 the 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.

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. For more information on how Workspace ONE manages Windows 10 updates, refer to Managing Updates for Windows 10 with Workspace ONE UEM.

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 when troubleshooting Windows.

Verifying Workspace ONE UEM Sent the Correct Windows 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 that the Device Received the Windows 10 Updates Profile when troubleshooting Windows 10.

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

Validate that the Windows update values are correct when troubleshooting Windows 10.

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

Validate settings using the registry when troubleshooting Windows.

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. For more info, refer to Understanding Windows 10 Group Policy Objects with Workspace ONE UEM.

4. Delivery Optimization Activity Monitor

Review the Activity Monitor when troubleshooting Windows 10.

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

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.

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.

For information about deployment, see Deploying Workspace ONE Intelligence and VMware Carbon Black Cloud: Workspace ONE Operational Tutorial.

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. 

For more information on how Workspace ONE can provide modern management for Windows, see Modernize Desktop Management on Tech Zone.


The following updates were made to this guide:

Date Description of Changes
  • Removed AirLift references as no longer supported 
  • Minor updates to some sections
  • Fixed broken GitHub EUC-Samples links.
  • Added information regarding KB 85891 in the Sensors Best Practices section.
  • Updated Operational Tutorial's title.
  • Updated troubleshooting cheat sheet.
  • Added new sections for troubleshooting baselines, sensors, and OEM integration.
  • Updated troubleshooting cheat sheet.
  • Updated logging locations and console screenshots.
  • Added new sections and updated the troubleshooting cheat sheet.
  • Initial publication.

About the Author and Contributors

This tutorial was written by:

With significant contributions from:

  • Adarsh Kesari, Consulting Architect, End-User-Computing, VMware.
  • Saurabh Jhunjhunwala, EUC Customer Success Architect, VMware.


Your feedback is valuable. 

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

Associated Content

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

Filter Tags

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