Run an SCCM task sequence during Autopilot HAADJ

My previous post on this topic covered how to do this with Azure AD Join. In that scenario, getting the Configuration Manager client installed and functioning is easier to do since it supports using an Azure AD user token for authentication. The same thing doesn’t work for Hybrid Azure AD Join (even though there should be an Azure AD user token available, since it is used to get the device enrolled in Intune), so you have to use a different mechanism. There are two other options available, PKI or bulk registration tokens. We’ll talk about the challenges of PKI later and focus on using a bulk registration token first.

Typically, a bulk registration token is only good for up to 7 days (although in my previous post I show how to increase that to 90 days), so you have to change this every so often, but at least that isn’t too hard. First, you need to generate a token using the BulkRegistrationTokenTool.exe:

Then you can take the resulting token and add it to the Intune Co-management settings (the full value is the same as in the AADJ post, with just the /regtoken:<token string> value added to the command line arguments):

With that assigned to your HAADJ device groups, Intune will take care of deploying the SCCM client to your devices during the Autopilot process. The SCCM client will run the specified task sequence (identified by its deployment ID, PRI20013), and the Enrollment Status Page will track that task sequence (as an “app”) until its completion.

The behind-the-scenes behavior of this is typically a little messier than it is in the AADJ case. It’s useful to look at the steps involved to understand why:

• The device is enrolled in Intune, which receives a signal from the device that an ODJ blob is needed to complete the AD join (HAADJ) process.
• Intune continues sending policies to the device, including MSI app installs. The first MSI installed is Intune Management Extensions (sidecar), and the SCCM client MSI (ccmsetup.msi) will install right after that.
• The ccmsetup.msi will kick off CCMSETUP.EXE as a service to complete the SCCM client installation process.
• Often before the SCCM client installation process can complete, the machine will reboot when the ODJ blob is received from Intune.
• After the reboot, the CCMSETUP service will try the SCCM client installation process again.

Until this process completes, ESP will stay at “Preparing your device for mobile management” because it’s waiting for a notification from the SCCM client about the “apps” that it needs to track. Once the SCCM client starts up and sees that it needs to run a task sequence, it will provide that notification. ESP will only wait 15 minutes by default for this notification, so it is possible that this will time out — I doubt there has been much verification done when clients are connected across slower internet connections where that might not be sufficient time.

Once that completes, the task sequence will start, but you won’t be able to see the TS progress UI — it’s there and you’ll see a thumbnail for it if you press Alt-Tab, but the only way to make it visible is to press Shift-F10 to open a command prompt, then Alt-Tab to see the TS progress UI dialog:

The cause of that is the subject for another blog. For now, we can just trust that everything is working as expected. Once the task sequence (and anything delivered from Intune that is tracked) completes, device ESP will complete. Since you typically don’t want to have user ESP enabled for HAADJ devices due to the challenges around getting the device fully registered (you can read more about that here, and see the SkipUserStatusPage details here), the end of the device ESP process should result in the device provisioning process completing and dropping you at the Windows logon screen. Assuming you have connectivity (e.g. Always-On VPN or any other supported VPN client), you can log into Windows using your AD credentials at that point.

If you see a timeout from ESP with an error due to apps not installing in the allotted time, you may need to configure the Co-management settings to specify that Intune should be used for all workloads:

This can happen when you are also delivering apps from Intune: it will tell ESP to wait for these apps, but then refuse to install the apps because it doesn’t own the workloads. This won’t affect the SCCM task sequence or apps delivered by the SCCM client, but it can affect other workloads (e.g. patching) so test accordingly.

Overall, the process works and appears to be fairly reliable, but as with the AADJ equivalent, it’s not a quick process by any means.

So what’s wrong with using PKI certificates?

By default, the SCCM client requires a PKI certificate generated by an internal certificate authority, where the name on the certificate matches the name of the computer. That sounds simple enough, but it can be messy during HAADJ. You can create a certificate device configuration profile to issue a cert, specifying CN={{DeviceName}} as the subject name format. (More information on those can be found in the docs.) But that will be applied to the machine before it is renamed by the ODJ-triggered reboot. Or you can create a certificate profile that specifies CN={{FullyQualifiedDomainName}} that can’t be processed until after the ODJ-triggered reboot. But that certificate might not be enrolled in time for the SCCM client to see it. (This would be less of an issue if you deployed the SCCM client as a Win32 app, but even that’s not 100% guaranteed, and it has other potential gotchas due to “workload flip-flopping,” which is what the Co-management settings are designed to solve.)

In theory, you can modify the SCCM client’s behavior using the available client installation properties. Some values of interest are:

• CCMCERTNAMECHECK=0. From the docs, setting this will cause the SCCM client to ignore the computer name and choose any cert that otherwise meets the criteria, as long as there is only one of those certs.
• CCMCERTISSUERS. This lets you specify your CA details, e.g. “CN=contosomn-CONTOSO-DC-CA; DC=contosomn; DC=com”, so that it only considers certs from that issuer. (This is helpful to get it to ignore the Intune device cert generated during MDM enrollment.)
• SMSPublicRootKey. This lets you specify that certs with this root key are trusted.

I can *almost* get this to work using two certificate templates, one that can be enrolled prior to the ODJ reboot (using the device serial number) and another that can be enrolled after (using {{FullyQualifiedDomainName}}). But when I try, it fails with an error that says it couldn’t find the SMSSiteCode in the device’s registry. OK, but I specified this in the command line (“SMSSITECODE=PRI”) so it shouldn’t be trying the registry. I see no obvious way to get past this, and the documentation is very vague on these properties overall. If you know any tricks to make this work, let me know. But for now, I’ll use a bulk enrollment token.