Troubleshooting Windows 10: VMware Workspace ONE Operational Tutorial

VMware Workspace ONE UEM 9.3 and later

Overview

Introduction

VMware provides this operational tutorial to help you with your VMware Workspace ONE® environment. Workspace ONE simplifies access to cloud, mobile, and enterprise applications from supported devices. As an IT professional, you can use Workspace ONE to deploy, manage, and secure applications. At the same time, you can offer a flexible, bring-your-own-device (BYOD) initiative to your end users from a central location.

Purpose

This operational tutorial provides you with discussions and  exercises to help with your existing VMware Workspace ONE® production environment. VMware provides operational tutorials to help you with

  • Common procedures or best practices
  • Complex manual procedures
  • Troubleshooting

Note: Before you begin any operational tutorial, you must first deploy a production environment. For information about deployment, see the VMware Workspace ONE Documentation.

Audience

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

Troubleshooting Windows 10

Introduction

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.

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

Client Uses
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 UEM Agent Used for communication, profiles, policies, and product provisioning
VMware AirWatch Agent (UWP - Store) Provides GPS location (Downloaded from the Microsoft Store)
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.

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

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 of 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.
  • HKEY_LOCAL_MACHINE\SOFTWARE\AirWatchMDM\AppDeploymentAgent
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. 

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 UEM Agent
%ProgramData%\AirWatch\UnifiedAgent\Logs
  • 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
%ProgramData%\AwProvAgent
 
Adaptiva Client
%WINDIR%\AdaptivaSetupLogs\Client
  • AdaptivaClientMSISetup.log
  • AdaptivaClientSetup.log
Adaptiva Cache
C:\AdaptivaCache
Software Distribution Cache
%ProgramData%\AirWatchMDM\AppDeploymentCache
Workspace ONE App
C:\Users\{user}\AppData\Local\Packages\AirWatchLLC.VMwareWorkspaceONE_htcwkw4rx2gx4\LocalState\LogFiles\Workspace1.log

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

In the Workspace ONE UEM Console:

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

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

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

5. Confirm Shared Device Options

  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.

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 https://telerik.com/download/fiddler.

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, hol@hol.com 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 www.fiddler2.com.
  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, hol.awmdm.com.
  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, Workplace, Staging, or Bulk 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 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 & 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: EnterpriseEnrollment.awmdm.com
  • Workspace ONE UEM Auto-Discovery over port 443; discovery.awmdm.com
  • Azure Active Directory needs access to Microsoft Login Servers: https://login.microsoft.com and https://login.microsoftonline.com
  • Windows Notification Service (WNS) uses port 443: *.notify.windows.com for example, bn1 or bn2.notify.windows.com

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: https://ekop.intel.com/ekcertservice
      • For Qualcomm firmware TPM: https://ekcert.spserv.microsoft.com/
    • To provision AIK certificates and filter Internet access, you must authorize the following wildcard URL: https://*.microsoftaik.azure.net
    • Both device and Workspace ONE UEM servers must have access to has.spserv.microsoft.com using the TCP protocol on port 443 (HTTPS).
  • Microsoft Store
    • Public Store Apps: https://www.microsoft.com/store/apps
    • BSP Apps: https://bspmts.mp.microsoft.com
  • 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

Accounts

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

For more information about onboarding methods with non-admin accounts, see Migrating Devices and Users to Workspace ONE in the Operational Tutorial for VMware Workspace ONE and Onboarding in the Reviewer's Guide for Windows 10 Unified Endpoint Management in AirWatch.

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 & 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 UEM Agent (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 & 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.

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 Workplace 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 Workplace 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 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 https://awagent.com.

  1. Enter the email address, for example, testuser@hol.awmdm.com.
  2. Click Next.
  3. Enter the management endpoint URL, for example, hol.awmdm.com/deviceservices/discovery.aws.
  4. Click Next.

Note: To verify if an email domain is registered with Workspace ONE UEM Auto-Discovery, navigate to  https://discovery.awmdm.com/Autodiscovery/awcredentials.aws/v2/domainlookup/domain/{domain}

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

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

Now, return to the Fiddler application. The most important sessions which deal with enrollment are the Policy.aws and Enrollment.aws 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 watson.telemetry.microsoft.com.

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

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 for Cloud-Based VMware Workspace ONE Series.

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 UEM Agent 9.5 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 Agent (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
10 Initialized
20 Download in Progress
25 Retrying Download
30 Download Failed
40 Download Complete
50 Install in Progress
60 Install Failed
70 Install Complete
80 Uninstall in Progress
90 Uninstall Failed
100 Uninstall Complete
110 Hash Mismatch
120 Sideloading is not Enabled

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

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

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

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.

  • HKEY_LOCAL_MACHINE\SOFTWARE\AirWatchMDM\AppDeploymentAgent
    • 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 & 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

Webclips

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 *.edgekey.net). 
  • 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.

Summary and Additional Resources

Conclusion

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

 

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

About the Author

This tutorial was written by:

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

Feedback

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 euc_tech_content_feedback@vmware.com.