Run an SCCM task sequence during Autopilot

When I first heard about Windows Autopilot (before it was even called Windows Autopilot), the first thing I thought (knowing how limited MDM-delivered configuration could be) was “how can I run an SCCM task sequence during a Windows Autopilot provisioning process.” So I tried it, and failed miserably. It was just too messy to do, for a variety of reasons.

It’s still messy today, but at least there are more pieces in place to make it work, as long as you want to do user-driven Azure AD (still doesn’t sound right to say “Entra ID”) scenarios.

The building blocks involved to make this work properly are:

• A properly-functioning, fully-configured Cloud Management Gateway. (Just because it’s working for your AD-joined devices doesn’t mean you are done here.)
• The PROVISIONTS command line parameter, which can be specified when installing the Configuration Manager client to tell it to automatically run the specified task sequence as soon as possible.
• “Co-management settings” (also labeled “Co-management authority” for inconsistency) in Intune that allow you to specify the command line options that will be used to *automatically* install the Configuration Manager client during the Autopilot process. You no longer need to use a Win32 app for this.
• Understanding in the Configuration Manager client that it should register itself to ESP so that the ESP will wait until the task sequence is complete before continuing. (There are two pieces to this, which I’ll discuss later — this is the main reason you shouldn’t use a Win32 app to install the Configuration Manager client.)
• Support in the Configuration Manager client and CMG for authenticating via an Azure AD user token. Without this, you would need to either use PKI certificates (which introduce timing challenges during the Autopilot process) or tokens (which are challenging to manage since they expire every seven days) to install the agent.

Getting the Cloud Management Gateway working

This is where I spent the bulk of my time trying to figure this out: I kept getting a variety of errors during the execution of CCMSETUP.EXE; it couldn’t complete the installation. The errors pointed to SSL certificate issues, certificate revocation list checking issues, and AAD authentication issues. Working through those, here’s my summary of what needs to be done:

• Don’t use a PKI certificate for your CMG. Even when adding the (internal) PKI trusted root cert and telling CCMSETUP to ignore CLR checking, it still didn’t work. Once I switched to a public cert (see this post) the SSL and certificate revocation list errors went away. You specify that certificate here:

• Make sure your AAD tenant details are published to the CMG. Even after fixing the SSL cert, I could see in the CCMSETUP.LOG that the client was trying to call a function to get AAD tenant info, and that was returning nothing. You can force that information to be re-published via the “Update Application Settings” action:

• Fix any errors you see. When I tried the “Update Application Settings” I got an error about the AAD application ID, causing the update to fail. When I tried to update the CMG settings, I got more errors. Even though my CMG had been working (been using it for AD-joined devices), it was definitely not in a good state. In the end, I completely removed it, removed the existing AAD objects (apps, storage group), and then started from scratch. I’m guessing this is a side effect of years of Insider Preview builds of Configuration Manager, leaving everything in an “odd” state.

• Make sure you enable “Enhanced HTTP” as it appears to be required for AAD-joined devices. (The docs appear to imply this, but they never explicitly state it.)

At this point, it would probably be best to try to manually install the Configuration Manager client on an AAD-joined device, since it’s pointless to try this during an Autopilot scenario if that simpler scenario isn’t working. To do that, you can run CCMSETUP.EXE directly with appropriate command line options from the “Cloud Attach” (co-management) enablement settings in Configuration Manager (more on that below).

Set up the “Co-management settings” in Intune

It seems that most of the Microsoft documentation assumes that you’ll want to co-manage devices by first getting them managed by Configuration Manager, and then by Intune. But when you’re using Autopilot, it’s the other way around. (Beware of licensing around this, as order can matter.)

To make this easier, a feature was being added to Intune to automatically install the Configuration Manager client and to set the workload configuration to solve some the problems that you’d otherwise run into (ever heard of “workload authority flip-flop”?). This was work that started years ago and I wasn’t sure it would ever ship, but then I saw a Twitter message at some point from Danny Guillory saying that it had shipped. Beyond the blog he posted, there isn’t much documentation available (at least not that I can find).

First, you need to find the settings, which are located in Intune with the rest of the Windows enrollment stuff:

From there, you can click “+ Create” to create a new “Co-management authority” specifying its name, and most importantly, the Configuration Manager client installation properties. (Intune will automatically download the needed Configuration Manager client bits.) You can then assign the settings/authority (seems they can’t make up their mind in the UI as to what it should be called) to Azure AD device groups. (While I included “Hybrid AADJ” devices in this, that won’t actually work. More on that later.)

I copied the client installation settings from Configuration Manager:

And then I tweaked them slightly to add the “PROVISIONTS” value as well as /NoCRLcheck (not that it was really needed once I switched to a public cert).

Notice the PROVISONTS value of “PRI20013”. That’s the “Deployment ID” (advertisement ID) for the task sequence, not the task sequence ID. You can find the “Deployment ID” after you add the column on the Deployments tab:

So now Intune will automatically install the Configuration Manager client (right after it installs the Intune Management Extensions MSI) by delivering the CCMSETUP.MSI (bootstrapping CCMSETUP.EXE from there with the specified command line options), and then the Configuration Manager client will run the task sequence.

The interesting part of this setup is that Intune is aware of the “Co-management Settings” targeted to devices. When it sees a policy targeted to the device, it will tell ESP to expect a list of apps to track from two policy providers instead of just one. Normally, Intune would just specify these enrollment settings in the MDM WAP payload (something I covered in some previous presentations) saying to track Win32 apps delivered via the Intune Management Agent (separate from MDM policies), which it does by specifying “Sidecar” as the policy provider:

<characteristic type="EnrollmentStatusTracking">
  <characteristic type="PolicyProviders">
    <characteristic type="Sidecar" />
  </characteristic>
</characteristic>

But when you have “Co-management Settings” targeted, you get one more:

<characteristic type="EnrollmentStatusTracking">
  <characteristic type="PolicyProviders">
    <characteristic type="Sidecar" />
    <characteristic type="ConfigMgr" />
  </characteristic>
</characteristic>

So that tells ESP that it should expect some tracking details from both “Sidecar” and “ConfigMgr”. When I specify the PROVISIONTS command line option, I end up with one additional “app” to track:

When the task sequence completes, that item will be marked with a “complete” status and ESP can continue. What happens if no PROVISIONTS was specified? In that case, the “ConfigMgr” provider just tells ESP that there are no apps to track from the provider.

So that’s how the ESP will block while the task sequence is running in the background. You won’t see any progress — the task sequence progress UI is hidden behind the OOBE ESP display, but it is running.

Trying it all out

Now we should be able to do an end-to-end test: an Autopilot user-driven AAD join process, with targeted “Co-management Settings” that specify a task sequence to run. After the process finishes, we can see the results. In this case, my task sequence installed two apps from Configuration Manager, so that’s the obvious way to tell.

The end result was successful, but the process was slow: 26 minutes to run a task sequence that installs two small apps (7-Zip and MDT), with Intune delivering one more app (the Tanium agent). Looking through the logs, here is the timing:

• It took six minutes for the Intune Management Extension MSI (sidecar) to install. (I’ve seen lots of variability in this time, sometimes it’s faster, sometimes it’s slower.)
• Once that MSI installed, it could then install the next one, the Configuration Manager client. That took just over 7 minutes.
• After the Configuration Manager client initializes, the task sequence can start. That took about two minutes.
• The task sequence itself took about 7 minutes to run, installing two small apps.
• Sidecar (Intune Management Extensions) installed the Tanium agent shortly after it was installed (in parallel to the Configuration Manager client installation). Even though that finished quickly (two minute install time), it took another 15 minutes before that was reported to ESP. It’s not at all obvious why this was the case.

But hey, at least it worked.

Final words

In an ideal world, other vendors (e.g. Tanium) could easily hook into the Autopilot ESP tracking too. Since it is a “provider”-based mechanism, all it takes is a provider, right? Well, not quite. You also need to get the MDM platform to deliver the policy that enables the provider, something Intune doesn’t do. That doesn’t mean I’ve given up hope, just that it’s likely a lot more work than it otherwise would need to be.

And what about Hybrid Azure AD Join? That gets trickier since the Configuration Manager client can’t use the AAD user token to authenticate, and using a PKI cert can be problematic due to timing issues between when the cert is received and the ODJ process completes. So then you’re left with using a token, but those expire every seven days, so you would need an automated process to update Intune with the new value each week. Something for another day. (Yes, Microsoft tells you that “a kitten dies every time you do HAADJ” and tries to make it as painful as possible by not fixing any of the initial design flaws, but it still makes sense for some customers in some situations.)