• Workspace ONE


  • Document


  • Advanced


  • Operational Tutorial


  • Workspace ONE Access
  • Workspace ONE UEM


  • Windows 10


  • Deploy


  • Modern Management

Troubleshooting Windows 10: VMware Workspace ONE Operational Tutorial

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



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


This operational tutorial is intended for IT professionals and Workspace ONE administrators of existing production environments. Both current and new administrators can benefit from using this tutorial. Familiarity with networking and storage in a virtual environment is assumed, including Active Directory, identity management, and directory services. Knowledge of additional technologies such as VMware Workspace ONE® Access (formerly VMware Identity Manager) and VMware Workspace ONE® UEM is also helpful.

Troubleshooting Windows 10


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

Windows 10 Troubleshooting Cheat-Sheet

This section contains a checklist for common troubleshooting scenarios, as well as helpful background information to jump-start your problem solving. 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.

If you'd prefer a paper format you can keep at your desk, download the PDF linked below.

Understanding the Basics

The following tables highlight the key clients and services used in Workspace ONE UEM for Windows 10.

Native MDM client built into the device. Used for device communication, enrollment, profile configuration Microsoft CSPs, software distribution metadata delivery, and VMware CSPs. Communicates using WNS.
Workspace ONE Intelligent Hub
Used for local policy enforcement, profile configuration, and product provisioning. Communicates using AWCM.
Software Distribution Client
Used to install Win32 apps.
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 Management
Service Description Hostname & Ports
Windows Notification Service (WNS)
Provides real-time communication for the built-in OMA-DM client.

* over 80/443 (IP List -

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

Troubleshooting Checklists

The checklist items listed below are presented from most likely to least likely cause.

Troubleshooting Profiles

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

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

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

☐ For Custom Settings:

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

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

☐ In Fiddler check error codes.

Troubleshooting Windows 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.

☐ Navigate to Windows Settings>Accounts>Access Work or School, and verify that you see Update. Then, click your enrollment account, and selecting Info.

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

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

☐ The following PowerShell cmdlets are helpful:

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

Troubleshooting Software Distribution

☐ 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

☐ 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 App.

☐ Staging workflows (command-line, PPKG, etc.) where the device is auto-reassigned to the end user need to have "Fixed Organization Group" or "User Group Organization Group" set atDevices & 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.

Important Event Viewer and Log Locations

Name Location
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) – Windows Information Protection (WIP)

Collects logs related to WIP and Audits

Event Viewer (Local) > Applications and Services > Microsoft > Windows > EDP *
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 

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 
For a complete list of Windows Error Codes, see the article Windows Error List.

Important Device Registry Keys

All MDM Profiles/Apps Pushed to Device

Lists all the profiles (not values) pushed to the device, including applications. These are broken down by device/user profiles identified by user's SID.

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\EnterpriseModernAppManagement
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseAppManagement
MSI/Desktop Apps*

Status of Workspace ONE Intelligent Hub, Software Distribution Client (used for installing Win32 apps) and all MSI app installations before SFD is enabled.

Software Distribution Apps*

Status of app installations along with additional information.

Non-SCEP Certificates

Certificate information for installed certificates.


*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 — Logs where S-1-5-18 contains apps pushed to the device and S-1-5-21-X contains apps pushed to the user. 

Logging Directories

Workspace ONE Intelligent Hub


  • AWProcessCommands.log - Installations that use the agent, such as encryption and product provisioning
  • NativeEnrollment.log - Agent-based enrollments
  • PowershellExecute.log - PowerShell commands run through product provisioning
  • TaskScheduler.log - Task Scheduler's local enforcement of policies, and samples sent to the console
  • AwclClient.log - Communications between AWCM client and Workspace ONE UEM
  • Updater.log - Agent auto-updates
  • AwAirWatchIpc.log - Communications with the Workspace ONE app and other services
  •  WorkspaceOneProvisioning.log - Workspace ONE app installations and downloads
Software Distribution Cache
Workspace ONE AirLift

%PROGRAMDATA%\VMware\VMware Airlift\logs

  • AirLift-<current_date>.txt - AirLift Windows Service logs
  • AirLift-Tool-<current_date>.txt - AirLift Command Line Tool logs 
  • %LOCALAPPDATA%\Temp - AirLift Setup Logs  

Understanding the Solution Stack

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

1. Communication Methods

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

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

2. Management Clients

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

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

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

Management Clients

OMA-DM VMware Workspace ONE Intelligent Hub
Native MDM client built into the device
Workspace ONE Intelligent Hub installed on the device
  • Device communication
  • Device enrollment
  • Profile configuration using Microsoft CSPs
  • Software distribution metadata delivery using VMware CSPs
  • Local policy enforcement
  • Profile configuration
  • Product provisioning

3. Background Management Clients

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

Software Distribution Client
Used to install Win32 applications
Adaptiva Client
Enables peer-to-peer distribution of Win32 apps
SCCM Integration Client
Prevents SCCM from disabling MDM enrollment
Workspace ONE Intelligent Hub
Used for communication, profiles, policies, and product provisioning
VMware AirWatch Agent (UWP - Store) Provides GPS location (Downloaded from the Microsoft Store)
Note: OMA-DM Location Tracking was introduced in Workspace ONE UEM 1811. GPS location data no longer requires an agent.
AirWatch Provisioning Client
Discovers where pre-registered Dell devices enroll
Dell Client Command Suite
Enables OEM updates and BIOS settings

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 Workspace ONE UEM for 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

  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

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

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

  • Hub > Agents >
    • Application Deployment Agent: contains logs (RegistryExport.txt and AirWatchMDM-*.etl) related to deploying Win32 (EXE, MSI, ZIP) applications to devices. These logs are helpful to provide to your Workspace ONE UEM support representative when app deployment is not working as expected. Refer to the Troubleshooting Application Management section of this tutorial for more details understanding these logs.
    • Windows Unified Agent: contains all the Workspace ONE Intelligent Hub log files. For more details refer to Workspace ONE UEM Logs section of this tutorial.
    • Provisioning Agent: contains the Provisioning Agent Event Log. For more details refer to Workspace ONE UEM Logs section of this tutorial.
  • System > Device >
    • PCRefresh: contains logs related to Enterprise Reset. More logs are visible after performing the Enterprise Reset action on the device.
    • Windows: Contains the System & MDM Event Logs as well as a registry export of HKLM\SOFTWARE\Microsoft\EnterpriseResourceManager which shows a list of successfully applied CSPs (profiles and apps) on the device.
      • Environment: Processes.txt and Services.txt contain an export of currently registered services and running processes.

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

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.

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

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

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 
Provisioning Service for Dell Cloud Provisioning
Collects information pertaining to the Provisioning Service
  • Event Viewer (Local) > Applications and Services > AirWatch-ProvisioningAgent > Operational section

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 agent, Software Distribution Client, Adaptiva Client, and all MSI app installations
  • 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
Adaptiva Client Settings
  • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Adaptiva\client
*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
  • AWProcessCommands.log — Installations that use the agent, such as encryption and product provisioning
  • NativeEnrollment.log — Agent-based enrollments
  • PowershellExecute.log — PowerShell commands run through product provisioning
  • TaskScheduler.log — Task Scheduler's local enforcement of policies, and samples sent to the console
  • AwclClient.log — Communications between AWCM client and Workspace ONE UEM
  • SSOCommunicationHandler.log — Agent post-enrollment single sign-on 
  • Updater.log — Agent auto-updates
  • AwAirWatchIpc.log — Communications with the Workspace ONE app and other services
  • WorkspaceOneProvisioning.log — Workspace ONE app installations and downloads
AirWatch Provisioning Client

Adaptiva Client
  • AdaptivaClientMSISetup.log
  • AdaptivaClientSetup.log
Adaptiva Cache
Software Distribution Cache
Workspace ONE App
Enterprise Reset
  • AWRefreshUnattend.xml: Unattend XML which executes RefreshRunOnce.cmd, deletes itself from Panther folder.
  • RefreshRunOnce.cmd: Completes the Workspace ONE Intelligent Hub command-line enrollment.
  • ResetConfig.xml: XML file which specifies what happens when a PC Reset is invoked; invokes VMwareRefreshBackup.cmd and then VMwareRefreshRecover.cmd to back up old PC and recover to new PC before resetting the device.
  • VMwareRefreshBackup.cmd: Backs up all enrollment data to C:\Recovery\OEM\VMware, Windows Refresh migrates C:\Recovery\OEM folder from old to new PC.
  • VMwareRefreshRecover.cmd: Restores all the backed-up data from old to new PC; copies AWRefreshUnattend.xml in the Panther folder as unattend.xml.
  • Contains logs and application data with the app deployment cache, Hub database with all configurations and settings, and registry settings with MDM device ID used to ensure the device checks in with the right console side record.
Workspace ONE AirLift
%PROGRAMDATA%\VMware\VMware Airlift\logs
  • AirLift-<current_date>.txt: AirLift Windows Service logs
  • AirLift-Tool-<current_date>.txt: AirLift Command Line Tool logs
AirLift Setup Logs: %LOCALAPPDATA%\Temp<!--[if !supportAnnotations]--><!--[endif]-->

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

Validating Console Settings

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

1. Navigate to All Settings

Checking Console Settings

In the Workspace ONE UEM Console:

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

2. Check Device Root Certificate

Device Root Certificate

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.

Ensure that:

  • The Device Root Certificate is generated.
  • The Device Root Certificate is of type Pfx and not Cer.
  • 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

AirWatch Protection Agent
  1. Navigate to Devices & Users > Windows > Windows Desktop > Agent Application

If you want to use the agent for Product Provisioning, local enforcement, BitLocker, and so on, then ensure it is enabled and assigned to the correct ownership types.

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

4. Check Azure AD Settings

Azure AD Settings
  1. Navigate to System > Enterprise Integration > Directory Services.

If your Azure AD enrollment is failing, check if Azure Integration is configured correctly in the console. Verify the Azure and Workspace ONE UEM console that the information is setup correctly.

Note: To set the Azure AD settings, ensure User Azure AD for Identity Services is set to ENABLED.

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:

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

Note: 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

Ensure you use Binary for objectGUID and String for any non-GUID value.

For more details, see Enrolling Windows 10 Devices Using Azure AD: VMware Workspace ONE UEM Operational Tutorial.

5. Confirm Shared Device Options

Shared Device
  1. Navigate to Devices & Users > General > Shared Devices.

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.

Note: Take a minute to explore your current enrollment restrictions and enrollment polices.

6. Verify TLS Mutual Auth for Windows Setting

  1. Navigate to Enrollment.
  2. Click Optional Prompt.
  3. Verify that Enable TLS Mutual Auth for Windows is set to your desired setting. Most customers have this disabled. If you are unsure, disable this setting to prevent communication issues with Windows devices.

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

Using Fiddler

Fiddler is a free web debugging proxy server tool which logs HTTP(S) traffic to quickly obtain all network communications to and from the device. Instead of requesting and analyzing verbose server logs, you can significantly reduce 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.

1. Install Fiddler

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

Click Free download.

1.2. Download for Windows

  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.

1.3. Run Fiddler Setup

Click FiddlerSetup.exe to run the Fiddler installer.

1.4. Accept License Agreement

Click I Agree.

1.5. Select Installation Folder

Click Install.

1.6. Complete Installation

Click Close.

2. Configure 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 allows you to see what Workspace ONE UEM is sending and receiving from the device.

2.1. Launch Fiddler

  1. Click the Windows logo to launch the Start Menu.
  2. Search for fiddler.
  3. Click Fiddler 4.

2.2. Disable Warning

Click Cancel.

2.2.1. Select WinConfig

Click WinConfig.

2.2.2. Dismiss Orphaned Exemption Record Found

Click No.

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

2.3. Decrypt HTTPS Traffic

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

2.3.1. Check Decrypt HTTPS Traffic

Select the Decrypt HTTPS traffic check box.

2.3.2. Trust Root Certificate

Click Yes.

2.3.3. Install Root Certificate

Click Yes.

2.3.4. Confirm Root Certificate Install

Click Yes.

2.3.5. Trust Root Certificate Added Success

Click OK.

2.3.6. Trust Root Certificate

Click X.

3. Run and Analyze Fiddler Captures

In this section, learn how to run a quick capture, view the data in RAW and XML formats, and save your captures.

3.1. Start and Stop Captures

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.

3.2. Inspect Traffic

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.2.1. Start and Stop Captures

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

3.2.2. Apply Filters

To filter out all the noise other than your device services server, you can add a filter:

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

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

Troubleshooting Enrollment

Many issues can occur during enrollment either with Azure AD, Access Work (Native), Command Line, or Dell Provisioning.

This exercise helps you to check the most common enrollment-related issues before checking logs and using Fiddler. 

1. Check Common Issues

First, validate these quick tips to rule out the most commonly occurring issues.

1.1. Check Date and Time

Check Date and Time

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

1.2. Check Internet Connection and Endpoints

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

1.2.1. Verify Network and Internet Settings

Network &amp; Internet Settings

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

1.2.2. Verify Endpoints

Verify Endpoints

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

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

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

A few more uncommon endpoints to check for are:

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

1.3. Check Accounts


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

1.3.1. Check Staging Accounts

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

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

1.4. Check Device Root Certificate and Application Certificate

Check Device Root Certificate &amp; Application Certificate

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

Enrollment Certificate: 

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

Application Certificate: 

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

1.5. Check OS Activation and Build

Check OS Activation &amp; Build

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

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

1.6. Check Required Services

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

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

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

Also, DiagTrack (Connected User Experiences and Telemetry) and Schedule (Task Scheduler) must be running on the device to ensure enrollment and other management features properly function.

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

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

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

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

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

2. Enrollment Troubleshooting Tips

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 Access Work app to complete the enrollment process. Windows Auto-Discovery is an optional method of enrolling devices that only requires the end-user's email address to begin the enrollment process. 

Enrollment can also require the downloading of the agent. This agent adds endpoint security to your Windows Desktop devices to ensure your data and devices remain secure wherever the device may go. The agent 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. For this exercise, you do not need the agent.

2.1. Find your Group ID

Finding your Group ID

The first step is to retrieve your Organization GroupID.

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

2.2. Capture Access Work Enrollment Traffic

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

2.2.1. Launch Settings

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

2.2.2. Access Accounts

Accessing Accounts

Select Accounts.

2.2.3. Access Work Enrollment

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

2.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, 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.2.5. Enter Group ID

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

2.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.2.7. Remember Sign-In Info

Remember Sign-In Info

Click Skip to not remember sign-in info

2.2.8. Complete Enrollment

Complete 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.2.9. Validate Successful Enrollment

Close Settings

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

2.3. Check Enrollment Traffic

Allowing Application to Make Changes

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

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

2.3.1. Check Enrollment Information

Allowing Application to Make Changes

Click your enrollment account, then click Info. 

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

2.3.3. Check Sync Traffic

Allowing Application to Make Changes

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

Troubleshooting Profiles

Profiles allow you to modify how the enrolled devices behave. This exercise helps you to check your restriction profile settings using Fiddler and Event Viewer. You must have a restrictions profile already configured to perform the steps in this section. To create a restrictions profile, see Configuring a Device Profile for Windows 10 in Managing Windows 10 Devices. This tutorial is part of the Quick-Start Tutorial Series for Cloud-Based VMware Workspace ONE.

1. Use Fiddler to Validate 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.1. Navigate to the Restrictions Profile

In the Workspace ONE UEM Console:

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

1.2. Republish Restrictions Profile

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

1.3. Review Changes in Fiddler

Quickly switch back to Fiddler and notice the new traffic:

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

2. Use Event Viewer to Check 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.

2.1. Review a Successful Event

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. 

2.2. Review a Profile Failure

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.

Troubleshooting Application Management

Windows 10 introduces several new configuration service providers (CSP) to push out universal applications (Store and Non-Store) and desktop applications (MSIs). Workspace ONE UEM supports integration with the Business Store Portal or the Microsoft Store for Business. This allows administrators to push public Store applications to devices without having end users sign into the Microsoft Store. However, if you only want the Workspace ONE app, install Workspace ONE Intelligent Hub which auto-downloads and installs the Workspace ONE app. Finally, Workspace ONE UEM supports not only MSIs (like most of our MDM competitors) but also supports MST, MSP, EXE, ZIP through Software Distribution. 

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

1. Troubleshoot MSI Apps Using EnterpriseDesktopAppManagement CSP

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

1.1. Check Registry Key Status Codes

Registry Key - Status

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

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

Note the following information:

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

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

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

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

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

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

1.2. Check MSI Installer Logs

MSI Installer Logs

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.

2. Troubleshoot Software Distribution

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

2.1. Application Failure Checklist

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

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

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

2.2. MSI versus EXE/ZIP Apps

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

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

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

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

2.4. Check Troubleshooting Logs Status Messages

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

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

2.5. Check Device Registry Logs

Check the following locations on the device for troubleshooting information. 

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

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

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

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

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

The following list details StatusCode entries.

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

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

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

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

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

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

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

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

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

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

3. Application Sideloading

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

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

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

3.1. Enable Sideloading Using Restrictions Profile

Enable Sideloading: Restrictions Profile

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

3.2. Enable Sideloading Manually

Enable Sideloading: Manually

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

4. Modern Applications

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.

4.1. Registry Key and Event Viewer Logs

Registry Key &amp; Event Viewer Logs

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

Registry Location: HKEY_CURRENT_USER\SOFTWARE\Microsoft\EnterpriseModernAppManagement

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

5. Check Web Clips


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

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

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

Troubleshooting Peer Distribution and Content Delivery Network

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

1. Peer Distribution Troubleshooting

Organizations can use P2P for application deployments by leveraging Workspace ONE UEM peer distribution capabilities. In this section, we will review a few basic logging locations.

1.1. Review Server Logs

  1. In Explorer, navigate to C:\Program Files\Adaptiva\AdaptivaServer\logs.

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

1.2. Navigate to %ProgramData%

  1. In Explorer, enter %ProgramData%.

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

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

1.3. Review P2P Client Logs

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

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

1.4. Check Client Registry Values

  1. In the registry, navigate to WOW6432Node > Adaptiva > client.

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

1.5. Check Adaptiva Cache Folder

In Explorer, enter C:\AdaptivaCache.

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

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

1.6. Connect to Adaptiva Database

Launch SQL Server Management Studio and click Connect.

1.6.1. Select Adaptiva Content Table

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

1.6.2. Find Content ID

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

2. Content Delivery Network Troubleshooting

Since AirWatch 8.4.1, the Workspace ONE UEM Console can integrate with Content Delivery Network (CDN) servers to assist with the downloading of large files, in particular when deploying internal applications. 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.

By integrating a Workspace ONE UEM environment with a CDN server, available bandwidth is greatly expanded and the risk of performance degradation due to file downloads is minimal. 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.

CDN integration is a requirement for applications deployed through the Microsoft Store for Business (BSP). With this system, you can purchase apps from the Microsoft app store and then distribute them to devices through Workspace ONE UEM in the same manner that internal apps are distributed. This process allows for CDN to be leveraged when deploying public applications to Windows devices.

Similarly, CDN integration can be effective in improving the performance of software distribution for Windows 10 devices and is required for SaaS environments.

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

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

2.1. CDN for On-Premises

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

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

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

Note: For detailed step-by-step instructions for your on-premise customers, see the CDN Integration Guide from VMware Docs.

2.2. Workspace ONE UEM with CDN Integration Workflow

Following are some general questions and answers concerning Workspace ONE UEM and CDN.

Q. Does Workspace ONE UEM leverage CDN for both content types and apps uploaded to the Workspace ONE UEM 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 components are there to the CDN integration?

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

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

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

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

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

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

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

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 which expires after 24 hours and a HMAC token which is based on the salt of the CDN account being used. 

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

A. The process is as follows.

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

Troubleshooting Windows Updates

Because Microsoft has moved to a continuous update cycle known as Windows as a Service, Workspace ONE UEM can now manage the update life cycle. It is important to keep devices secure and up-to-date—this helps to protect your devices from security risks and viruses.

This exercise helps you to explore some of the high-level troubleshooting tasks to get updates working and validate they are set correctly.

1. Windows As a Service with Workspace ONE UEM

To understand how Windows Update management works with Workspace ONE UEM, see the following high-level workflow:

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

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.

2. Run Windows Update Troubleshooter

The fastest way to troubleshoot Windows 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, you do not have to check if the service is running or if there are any issues with the cache manually.

3. Confirm Updates on Device

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

3.1. Validate the Device Received the Profile

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

3.2. Validate Windows Update UI Shows Correct Values

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

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

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

3.3. Validate Settings Using Registry

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

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

3.4. Delivery Optimization Activity Monitor

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

4. Use Event Viewer

If you have verified the Workspace ONE UEM configuration but the device still cannot apply or obtain updates, you need to seek further assistance. You can use Event Viewer to gather detailed error and status messages to check in Google or report back to Microsoft.

5. Use PowerShell Cmdlets

The following PowerShell cmdlets are 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.

Troubleshooting Workspace ONE AirLift

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

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

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

1. Troubleshoot Workspace ONE AirLift Installation

If the Workspace ONE AirLift install or uninstall fails for some reason, ensure you have completed the following steps.

1.1. Enable Logging

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

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

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

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

1.2. Check Event Viewer

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

1.3. Common Issues

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

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

1.4. SQL Installation Failures

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

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


2. Troubleshoot SCCM Connection

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

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

2.1. SCCM Connection Flow

The SCCM connection flow is as follows:

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

2.2. SCCM Connection Checklist

The SCCM connection checklist is as follows:

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

2.3. Common Errors

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

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

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

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

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

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

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

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

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

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

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

Summary and Additional Resources


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

  • Troubleshooting Enrollment
  • Troubleshooting Profiles
  • Troubleshooting App Management
  • Troubleshooting Peer Distribution and Content Delivery Network
  • Troubleshooting Windows Updates
  • Troubleshooting Workspace ONE AirLift

Terminology Used in This Tutorial

The following terms are used in this tutorial:

application store A user interface (UI) framework that provides access to a self-service catalog, public examples of which include the Apple App Store, the Google Play Store, and the Microsoft Store.
auto-enrollment Auto-enrollment simplifies the enrollment process by automatically enrolling registered devices following the Out-of-Box-Experience.
catalog A user interface (UI) that displays a personalized set of virtual desktops and applications to users and administrators. These resources are available to be launched upon selection.
cloud Asset of securely accessed, network-based services and applications. A cloud can also host data storage. Clouds can be private or public, as well as hybrid, which is both private and public.
device enrollment The process of installing the mobile device management agent on an authorized device. This allows access to VMware products with application stores, such as Workspace ONE Access (formerly VMware Identity Manager).
identity provider (IdP) A mechanism used in a single-sign-on (SSO) framework to automatically give a user access to a resource based on their authentication to a different resource.
mobile device management
(MDM) agent
Software installed on an authorized device to monitor, manage, and secure end-user access to enterprise resources.
one-touch login A mechanism that provides single sign-on (SSO) from an authorized device to enterprise resources.
service provider (SP)
A host that offers resources, tools, and applications to users and devices.
virtual desktop The user interface of a virtual machine that is made available to an end user.
virtual machine A software-based computer, running an operating system or application environment, that is located in the data center and backed by the resources of a physical computer.

For more information, see the VMware Glossary.

Additional Resources

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

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


About the Author

This tutorial was written by:

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


The purpose of this tutorial is to assist you. Your feedback is valuable. To comment on this tutorial, contact VMware End-User-Computing Technical Marketing at

Filter Tags

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