Let's explore in this Blog Post the Workspace ONE UEM Console Hub Repair action and its weakness. Then, let me show you how to bridge this gap.

Introduction

Introduced with Workspace ONE UEM Version 2005, the Repair Hub action allows administrators to remotely re-establish communication between Windows 10 devices and the Workspace ONE Intelligent Hub for Windows. According to Workspace ONE UEM Release Notes, this action was introduced due to certain events can cause communication problems like HMAC errors and failed upgrades of the Workspace ONE Intelligent Hub for Windows.

In a nutshell, the Repair Hub action remotely trigger local MSI repair of the Workspace ONE Intelligent Hub. In other terms, it executes the following action:

msiexec.exe /f {{hubProductCode}} /quiet 

Hub Repair: Quick Overview

To use Hub Repair action:

1. Go to DEVICES > List View and open the Details View of a Windows 10 device.
   
2. In the upper right corner, click MORE ACTIONS then scroll down until accessing Admin section. Into that section, click Repair Hub.
   
3. Click OK when the following popup appears:
   
4. Finally, click OK when the following popup appears:
   

My Concerns

This process is obviously well known by everyone (at least, I hope so). However, this is my personal opinion but I noticed some lacks:

1. When launching Repair Hub, Workspace ONE does not collect any logs. Doing so, when I open troubleshoot tab, I have no information regarding Repair Hub progression. In my example, I launch Repair Hub action at 15h31 Device Time (1:31 AM Workspace ONE Console Time). Here is the Event Log details:
   
2. Repair Hub action is so much interesting that some of my clients wanted to launch this action in bulk. However, at this time, this is natively not possible with Workspace ONE UEM Console.

Understand Repair Hub action

The rest of this blog post focus on how Remote Repair Hub works in detail to be able to provide a new way to implement this action, bridging the gap with my concerns.

First Try: Playing with API

To understand how VMware implement this action, I first collected network traffic. My aim: Target the API used and reproduce the action with Postman.
Here is the API used:

Immediately, I did not recognize the usual API scheme:
Current Scheme: {{cnXXX.awmdm.com}}/AirWatch/...
Usual Scheme: {{cnXXX.awmdm.com}}/API/...

First try is a failure

Quick Workspace ONE UEM Solution Stack Reminder

Before detailing my second try, let's first go back to basics.
Windows 10 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
  
  By keeping in mind that I am currently trying to Repair Workspace ONE Intelligent Hub, I assume that Workspace ONE intelligent Hub Client is not usable.
  Hence, I have to focus on OMA-DM Client and CSP capabilities. At this moment of reflection, I am confused. As far as I know, there is no CSP able to execute msiexe. Anyway, let's begin the second try.

Second Try: Playing with CSP

Step 1: Intercept DM Sessions

To intercept DM Sessions, I used SyncMLViewer. As a reminder, I introduced this tool in my previous Blog post here.
Once launch Repair Hub, I found the following DMClient interesting CSP:

According to Microsoft documentation:

The DMClient configuration service provider (CSP) is used to specify additional enterprise-specific mobile device management (MDM) configuration settings for identifying the device in the enterprise domain, for security mitigation for certificate renewal, and for server-triggered enterprise unenrollment.

Step 2: Identify Registry Key

To identify the registry key matching the above CSP:

1. Open Registry Editor
2. Click Edit then Find...:
   
3. Enter CustomEnrollmentCompletePage then click Find Next:
   
4. Wait while Registry Editor found a match:
   
5. Here is the result:
   

For information, 1ABCE07B-D475-4E7D-B968-F924DC7FE118 corresponds to EnrollmentID.

I can find this value from Event Viewer console under Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin then target Event ID 208:

As I don't have any data, I try to launch again a Repair Hub action. This time, I can see under CustomEnrollmentCompletePage the Title Name associated with {'Action': 'RepairHub'} Data:

Step 3: Identify Logs To Go Further

To be able to go further, I had to find if the Repair Hub action generated logs. According to Techzone:

Here is the generated logs:

I see Three interesting things:

1. It seems that VMware add VMwareHubHealthMonitoringJob Job as Task Scheduler. By searching into the Task Scheduler console, I did find VMwareHubHealthMonitoringJob Job:
   
   This Job monitor VMwareHubHealthMonitoring.exe located under Program Files (x86)\Airwatch\HealthMonitoring\Maintenance thanks for ValidateRecovery option.
2. It seems that VMware also add Health Monitoring Service. More precisely, it creates VMware Hub Health Monitoring Service which executes VMwareHubHealthMonitoring.exe but under Service folder instead of Maintenance Folder:
   
3. Finally, logs show the Repair Sequence:
   • VMware check registry for repair action.
   • If such key is found, VMware launch a repair action based on Workspace ONE Intelligent Hub ProductCode.
   • That is not logged above but once repair action is done, the key is deleted.

Step 4: Build The Entire Repair Hub Process

Based on previous information:

1. VMwareHubHealthMonitoringJob Job monitor VMware Hub Health Monitoring Service Service
2. VMware Hub Health Monitoring Service Service launch MSI repair of the Workspace ONE Intelligent Hub triggered by the existence of CustomEnrollmentCompletePage / Title Registry Key associated with {'Action': 'RepairHub'} Data.
3. CustomEnrollmentCompletePage / Title Registry Key associated with {'Action': 'RepairHub'} Data is sent from Workspace ONE UEM Console using the following CSP:

<Replace>
    <CmdID>afbdb9d0-e958-4048-9a16-4a3e7e26b003</CmdID>
    <Item>
        <Target>
            <LocURI>./Vendor/MSFT/DMClient/Provider/AirWatchMDM/CustomEnrollmentCompletePage/Title</LocURI>
        </Target>
        <Meta>
            <Format xmlns="syncml:metinf">chr</Format>
        </Meta>
        <Data>{'Action': 'RepairHub'}</Data>
    </Item>
</Replace>

Step 5: Reproduce Repair Hub Action With CSP

Now that I have all needed information about how Repair Hub action works, I can reproduce its functioning while answering the two concerns previously exposed.
To do so:

1. On Workspace ONE UEM Console, create a Windows Desktop Profile, targeting Device context. By creating a profile, I will have all needed analytics instead of Repair Hub action
2. Under the Payload General, add a Name and a Smart Group. Smart Group allows me to target a population of devices instead of only one device with Repair Hub action
3. Go to Custom Settings Payload then
   • Choose OMA DM Client as Target
   • Leave Make Commands Atomic ticked
4. Next to Install Settings, add:

<Replace>
    <CmdID>afbdb9d0-e958-4048-9a16-4a3e7e26b003</CmdID>
    <Item>
        <Target>
            <LocURI>./Vendor/MSFT/DMClient/Provider/AirWatchMDM/CustomEnrollmentCompletePage/Title</LocURI>
        </Target>
        <Meta>
            <Format xmlns="syncml:metinf">chr</Format>
        </Meta>
        <Data>{'Action': 'RepairHub'}</Data>
    </Item>
</Replace>

4. Next to Remove Settings, add:

<Delete>
    <CmdID>1</CmdID>
    <Item>
    <Target>
        <LocURI>./Vendor/MSFT/DMClient/Provider/AirWatchMDM/CustomEnrollmentCompletePage/Title</LocURI>
    </Target>
    <Meta>
        <Format xmlns="syncml:metinf">chr</Format>
    </Meta>
        <Data></Data>
    </Item>
</Delete>

The profile should look like this:

5. Click SAVE AND PUBLISH

Conclusion

CSP Policies are very powerful to configure Windows 10 policies. In this blog post, we also have seen that CSP Policies allow for complex but important mechanisms like this Repair Hub action.

Thanks for reading and stay tunned for more tech content on our Blog !