Troubleshooting Windows Devices: Workspace ONE Operational Tutorial

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

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

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

☐For Custom Settings:

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

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

☐In Fiddler, check error codes.

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

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

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

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

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

☐The following PowerShell cmdlets are helpful:

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

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

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

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

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

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

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

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

☐ Brownfield domain joined (in domain user profile):

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

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

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

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

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

• OMA-DM (Open Mobile Alliance Device Management)
• Workspace ONE Intelligent Hub

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

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.

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

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.

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

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

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

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

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.

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.

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

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

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

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

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

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

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

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

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

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

In the Workspace ONE UEM Console:

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

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

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

1. Navigate to Devices & Users > Windows > Windows Desktop > Intelligent Hub Application
2. If you want to use the Hub for Product Provisioning, local enforcement, BitLocker, and so on, then ensure it is enabled and assigned to the correct ownership types.

1. Navigate to System > Enterprise Integration > Directory Services.
2. Verify Azure Integration is configured correctly in the console. The most common errors with Azure integration are as follows.
   • Not adding the on-premises app in Azure for URLs other than .awmdm.com
   • Not matching the Immutable ID Mapping Attribute
   • Not using the correct data type for Immutable ID
   • Not using the Binary for objectGUID or ms-DS-ConsistencyGuid and String for any non-GUID value.

Workspace ONE UEM can integrate with Azure in two models:

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

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

1. Navigate to Devices & Users > General > Enrollment.
2. Click Optional Prompt. 
3. If you are on the latest version of the console, you will not see this option. If you are on an older version, verify that Enable TLS Mutual Auth for Windows is set to your required setting. Most customers have this deactivated. If you are unsure, deactivate this setting to prevent communication issues with Windows devices.

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.

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

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

To download the latest version of SyncML Viewer, go to: https://github.com/okieselbach/SyncMLViewer/tree/master/SyncMLViewer/dist

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

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

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.

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

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

After a successful enrollment, you should have two certificates from Workspace ONE UEM. The Enrollment certificate is located in Certificates - (Local Computer) > Personal > Certificates and the Application certificate is located in Certificates - Current User > Personal > Certificates, as shown in the screenshots. Verify that these certificates are not present before enrolling or your enrollment will fail (delete all certificates then re-enroll). Previously, we confirmed that the Device Root Certificate was generated.

Enrollment Certificate: 

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

Application Certificate: 

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

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

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

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

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

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

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

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

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

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

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

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 leads up to these endpoints. Explore some of the entries and inspect the traffic to the right. Complete a successful enrollment and save your results—this will be helpful for troubleshooting at a later stage. Again, Fiddler can be used to see if some of the endpoints are not accessible. In this example, you can see 117 and 119 where the network is blocking access to watson.telemetry.microsoft.com.

In the Workspace ONE UEM Console:

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

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

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.

In Event Viewer:

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

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

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.

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

For more details, see Group Policy Processing and Precedence and Group Policy Hierarchy.

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

It is also important to note that throughout the tutorial we discuss leveraging Workspace ONE Baselines. Baselines are based on GPOs and depending on the policy can be applied on the device using DEM, SecEdit, AuditPol, or LGPO (only custom baselines).

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

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

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

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

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

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

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

Note the following information:

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

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

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.  

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.

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

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

Note: For more details, see VMware Knowledge Base: Software Distribution: Tips and Troubleshooting (2960987).

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

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

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

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

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

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

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-Xcontains apps being pushed to the user context.
    • Includes InstallCountvalue:
      • 0: The application is not installed and is not actively being deployed.
      • 1: The application is installed, or installation is being attempted. If a dependency application, the dependency is installed and only one package depends on it.
      • 0x8000001: The application (or dependency application) is externally installed, and assume management is not applied.
      • 2+: The dependency is installed and has x applications dependent on it, for example, if InstallCount for a dependency is 3, it is installed and three individual application packages depend on it.

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

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

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

The following list details StatusCode entries.

• 0x000: Deployment operation queued
• 0x100: First detection in progress
• 0x101: First detection failed
• 0x102: First detection successful
   
• 0x200: Check reference count in progress
• 0x201: Check reference count failed
• 0x202: Check reference count successful
   
• 0x300: Requirements evaluation in progress
• 0x301: Requirements evaluation failed
• 0x302: Requirements evaluation successful
   
• 0x400: Dependency deployment in progress
• 0x401: Dependency failed
• 0x402: Dependency successful
   
• 0x500: Sanitize cache in progress
• 0x501: Sanitize cache failed
• 0x502: Sanitize cache successful
   
• 0x600: Pending network connectivity
• 0x601: Download in progress
• 0x602: Pending download retry
• 0x603: Download content failed
• 0x604: Download content successful
   
• 0x700: Transform cache in progress (decompressing zip packages)
• 0x701: Transform cache failed
• 0x702: Transform cache successful
   
• 0x800: Pending user session
• 0x801: Install in progress
• 0x802: Pending deployment retry 
• 0x803: Deployment failed
• 0x804: Deployment successful
• 0x805: Pending reboot
   
• 0x900: Final detection evaluation in progress
• 0x901: Final detection failed
• 0x902: Final detection successful
   
• 0xC0000000: Deployment operation suspended
• 0xC0000602: Deployment suspended — pending download retry
• 0xC0000802: Deployment suspended — pending install retry
• 0x40000000: Deployment operation failed
• 0x40000603: Deployment failed — download failed
• 0x40000803: Deployment failed — installation failed
• 0x80000000: Deployment operation succeeded
• 0x80000402: Application is externally installed
• 0x80000902: Deployment succeeded — final detection passed

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.