I mentioned in my previous post that I was able to use “Co-management Authority” (a.k.a. “Co-management settings”) to install the ConfigMgr agent and then initiate a task sequence (using PROVISIONTS) during an APv2 device provisioning process, but that I didn’t think that it was actually being monitored by APv2 since I saw no error when the SCCM client failed to install due to a CMG issue.

Background

I think this is a result of the new architecture being used with APv2 (a.k.a. Autopilot device provisioning) compared with APv1 (the old ESP). That requires some additional background, first on how APv1 worked. When provisioning a device using the original APv1 and ESP process, it’s up to the MDM service to provide ESP with a list of things that need to be tracked. ESP had a full understanding of MDM-based things (MSI and UWP apps, M365 Apps/Office, certs, network connections, policies) via their OMA-DM URIs; it was up to the MDM service to provide a list of which of those needed to be tracked. But there were “other things” that needed to be tracked beyond the things supported by the Windows MDM stack, e.g. Win32 apps. To support those, a “provider” model was implemented that allowed other agents to provide an additional list of things that needed to be tracked. That setup was documented as part of the Enrollment Status Tracking CSP. (Before the enrollment status page, ESP, got its name, it was called the enrollment status tracking page, hence the different CSP name.)

Microsoft initially implemented that provider model to be used with the Intune Management Extension so that Win32 apps could be tracked. Later, they added a second provider that allowed the ConfigMgr agent to tell ESP about a task sequence that needed to be monitored (done by treating that task sequence as “just another app”).

I had even built a policy provider of my own (see this blog post) that enabled tracking of other things. Presumably other MDM providers, e.g. Workspace One, did the same thing for their own Win32 app delivery mechanism. (One of these days I need to try that out to see what it looks like, as I’ve really only skimmed their docs. And yes, they support HAADJ.)

So with APv2, it appears that entire provider model is gone and is replaced by a simpler hand-off process. As I noted in my previous post about the APv2 progress display (I still call this ESP for simplicity), it’s not really tracking anything, it’s just counting down until either (a) it’s notified that things are done, or (b) the maximum time expires. So APv2’s ESP appears to be aware of IME being delivered (it’s pushed as an MSI app), installed, and initialized, but after that it just waits for it to signal completion. It’s IME that is doing all the work, through a new “BootstrapperAgent” component included in it. (Not surprisingly, the configuration for that is passed down as part of the initial MDM enrollment payload.)

This change is likely why the FAQ includes this note:

Windows Autopilot device preparation will support non-Microsoft MDMs. In this initial release, configuration is only possible via Intune.

There’s likely a new process that hasn’t yet been documented that other MDM providers (or me, trying to track “other stuff”) would need to use. Or at minimum, they haven’t yet been able to implement (or reverse-engineer?) the new setup.

Testing the theory

Since the new APv2 process tracks apps and not policies, there’s a simple way to try it out: remove all the apps, make sure the “Co-management Authority” targets either all devices or the same group as the APv2 profile, and have the co-management command line include the PROVISIONTS parameter that specifies the task sequence to run after the SCCM client is installed. (That setup is covered in the previous blog.) If the TS is tracked, it will wait for the TS to finish; if it isn’t, the device will that that “required setup is complete” before the TS even starts (since there’s nothing else to track). Sure enough, it ended up on the “required setup is complete” screen before the task sequence started:

Funnily enough, I couldn’t actually remove all the apps I had in the list because that generated an error in the Intune portal, so I had to leave one of them there. I left a small LOB/MSI app that installs quickly. That appears to be a bug: the only way to empty the list is to throw away the profile and create a new one from scratch.

Can we fix it? Yes we can.

Since we can add a PowerShell script to the list of things that APv2 will monitor, we can use that to wait for the task sequence to complete. There are a few steps that it needs to go through in that process, and it’s easiest if you tell it the ID of the task sequence that you want to key on so that it can find the task sequence result. But the results look reasonable:

(The task sequence progress dialog won’t appear unless you use a trick like the one discussed in this blog.)

The script is attached to this blog post in a zip file. You can add that script in the Intune portal at “Devices -> Scripts and remediations -> Platform scripts” and then click “Add” to create a new Windows 10 (or 11) script, paste in the script text, and save the script. Then add it to the list of scripts that APv2 should wait for during the device preparation process.

What does the script do? It basically goes through these phases:

• Make sure we’re in OOBE, if not bail out. (This makes the script safe to deploy to existing devices. It will only do something if run in OOBE. So it’s best to assign it to just the device group in question.)
• Check to see if the ConfigMgr policy provider status changes to 2 or 3. If it changes to 2 (“not needed”), there’s no task sequence to execute, so we can bail out. If it changes to 3 (“installed”) then we need to monitor the TS execution.
• See if we can find the task sequence results in the registry. If so, exit.

Here’s an (accelerated) look at the whole process:

Attachment: TSWatcher.zip