Co-Managing Windows Autopilot Hybrid Join Devices

As both Microsoft Intune and Configuration Manager are a match made in heaven, there are many reasons to still utilise both, either using Co-Management or just plain old Tenant Attach, so imagine my joy when Microsoft released Co-Management Authority in Intune, and I thought the days of packaging the Configuration Manager Client were over.

Now imagine my face when I read the requirements and the fact it doesn’t support Autopilot Hybrid Join scenarios.

I get it, installing the client during Autopilot will pretty much break the deployment, but there should be a way to install the client and not have it bend over and only accept Configuration Manager deployed workloads.

Packaging the Configuration Manager Client has been covered, many, many, many, many times, almost to death in fact, so I’m not going to show you how to package the client files, what I am going to show you is a couple of tricks to make the installation easier, and not break Autopilot.

App Requirement Rules

#

To stop the application from running during the Autopilot process, we can add in a Requirement Rule to ensure that we’re not in the Out of Box Experience (OOBE). We’ve got a couple of options here, whether it’s detecting if the CloudExperienceHostBroker Service is running, or if the User account context is running under defaultUser0.

I’ve gone with the Service approach, as it saves Intune having to run Get-ComputerInfo -Property CsUserName every time it wants to check if the requirement has been met.

With this, we can create a Requirement Rule Script using the below to check if the CloudExperienceHostBroker service is running, and if not returning Install:

$ESPProcess = Get-Process -Name CloudExperienceHostBroker -ErrorAction SilentlyContinue
if ($ESPProcess.Count -eq 0) {
    Return 'Install'
}

Pretty straight forward for one of my documented scripts, but either way, save the file locally as something you can remember.

Create the rule in Intune with the below settings:

Giving us something like this:

This will now stop the installation from even starting during Autopilot phase, and only start the installation once the requirement has been met.

App Detection Methods

#

Now that we can control when the Client is installed, we need a way to detect that it has installed, and to be honest, we don’t actually care if the Client itself has installed correctly, as the Client setup will just sit and try to install itself every ten minutes until it can.

If we had a detection rule for either the MSI product code, or a File check for the client itself, we’d be waiting for an absolute age for Intune to be happy and confirm the installation state. We do not want this.

What we do want, is a quick and easy way to ensure that the setup files exist on the device, then we can let the ccmsetup.exe do it’s magical thing and install the Client and the associated service.

So for the detection rule, we’ll just look for the presence of the setup file:

This looks a little bit like the below:

Allowing for a quick and easy detection of the required setup files on the device.

Intune Only Mode

#

If you’re wanting Intune to manage all the workloads on the device, and not rely on Co-Managed Workloads at all, there is a solution for this, and one taken straight from Microsoft and their implementation of the Co-Management Authority in Intune.

This is the value that they’re on about:

HKLM:\SOFTWARE\Microsoft\DeviceManageabilityCSP\Provider\MS DM Server

Here’s the legend for the key:

• 1 – Intune
• 2 – Configuration Manager

Right, so if we really wanted to stick with Intune as the management authority here, we can leverage the above information and force the device to stick with Intune for it’s management needs, and in the case of App deployment, the device will still receive Apps from both Intune and Configuration Manger if the key value is set to Intune.

Proactive Remediation

#

As I’ve mentioned previously if you’re licensed to use Proactive Remediation Scripts, you should be using them, and in anger. We can throw together a script that looks for the registry key HKLM:\SOFTWARE\Microsoft\DeviceManageabilityCSP\Provider\MS DM Server\ConfigInfo, create it if it doesn’t exist, and set it to 1 telling the device to only deal with Intune.

Detection Script

#

As with all Proactive Remediation scripts, we need a method to detect, which is run initially upon assessment, and subsequently after remediation. A standard check, fix, check situation. For the detection method, we’re looking for both the Registry Key and the item.

Try {
    $Registry = 'HKLM:\SOFTWARE\Microsoft\DeviceManageabilityCSP\Provider\MS DM Server'
    $Path = Test-Path $Registry
    $Authority = Get-ItemPropertyValue -Path $Registry -Name ConfigInfo -ErrorAction SilentlyContinue

    if ($Path -eq $False) {
        Write-Warning 'Co-Management Authority Not Confgured'
        Exit 1
    }
    else {
        if ($Authority -ne '1') {
            Write-Warning 'Co-Management Authority set to Configuration Manager'
            Exit 1
        }
        else {
            Write-Output 'Co-Management Authority set to Intune'
            Exit 0
        }
    }
}
Catch {
    Write-Error $_.Exception
    Exit 2000
}

Remediation Script

#

If either the Key or the Data are not detected, we have a Remediation script that configures either the Key and the Data, or just the Data.

Try {
    $Registry = 'HKLM:\SOFTWARE\Microsoft\DeviceManageabilityCSP\Provider\MS DM Server'
    $Path = Test-Path $Registry
    $Authority = Get-ItemPropertyValue -Path $Registry -Name ConfigInfo -ErrorAction SilentlyContinue

    if ($Path -eq $false) {
        New-Item -Path $Registry -Force | Out-Null
        New-ItemProperty -Path $Registry -Name ConfigInfo -Value 1 -PropertyType String -Force
    }
    else {
        if ($Authority -ne '1') {
            New-ItemProperty -Path $Registry -Name ConfigInfo -Value 1 -PropertyType String -Force
        }
    }
}
Catch {
    Write-Error $_.Exception
    Exit 2000
}

Creating a Custom Script

#

With the above PowerShell scripts saved, we can now create our own Proactive Remediation Script and deploy this to the devices we only want to be managed by Intune, in this case, the Hybrid Joined Autopilot devices:

Make sure you’re using 64-bit PowerShell for this script, as we don’t want anything screwy going on with the registry settings.

Summary

#

We’ve managed to delay the installation of the Configuration Manager Client, as well as ensure it’s detected quickly once installed, and once it does install and the Client starts looking at Configuration Manager for it’s Co-Management settings, we’ve even got a way to tell Configuration Manager to look the other way and not break Autopilot whilst letting Intune do its thing.

All in all, although not a Microsoft supported method for deploying the Client, it is one that works. As you’ve realised by now, I’m not about documented good practice.