I’ve mentioned in presentations over the past couple of years that the first thing I tried to do with Windows Autopilot was to run a task sequence, bridging the old and the new.  The idea is simple enough:  Autopilot joins the device to Azure AD or Active Directory and enrolls it in Intune; Intune installs the ConfigMgr client; then ConfigMgr runs a task sequence.  It’s not that it didn’t work – it just took forever, waiting for the client to install and initialize, report discover and inventory details, wait for collection evaluation, and polling for new policies.  Without some “more than fine” tuning, that could easily take an hour or more.

But now ConfigMgr can do this much more quickly (with some constraints, as described below).  Since my lab environments run ConfigMgr tech preview releases, that’s what I’ll focus on:  the TP 1912 capability to immediately run a task sequence after the ConfigMgr client installs and initializes.

So let’s walk through the steps as described in the documentation.

First, create a non-OSD task sequence to do whatever you want.  It won’t boot into Windows PE, so you don’t need to attach a boot image to it.  I called mine “Provision device.”

That task sequence should then be deployed to the new “All Provisioning Devices” collection, which works kind of like the “All Unknown Computers” collection, enabling this task sequence to be run by new devices being provisioned that aren’t yet known to ConfigMgr.  The documentation doesn’t say whether “required” or “available’” should be specified for the deployment, so I chose “required” and that worked fine, but I suspect “available” would work as well.

Make sure that deployment is configured how you want it.  For example, it’s quite likely that this will need to be run over the internet, so that needs to be enabled:

Notice that the documentation says to note the task sequence deployment ID, which isn’t actually displayed in the list of deployments.  Fortunately, you can right-click on the column headers (toward the bottom right, in the list of deployments) and add the “Deployment ID” column to the list by selecting it from the pop-up menu:

Then you can see the “Deployment ID” value that you need:

See the “PRI20003” value toward the bottom right?  That’s what you need.

Next, you need to deploy the ConfigMgr client via Intune.  (Make sure you are using the 5.0.8923.1000 build from TP1912, or something newer.)  The ConfigMgr documentation has a good section on how to do this.  The trickiest part is the command-line arguments that need to be specified:

Here’s what I ended up with for my environment:

CCMSETUPCMD=”/nocrlcheck /UsePKICert /mp:https://CONTOSOCM.CONTOSOCM.COM/CCM_Proxy_MutualAuth/72057594037927953  CCMHOSTNAME=CONTOSOCM.CONTOSOCM.COM/CCM_Proxy_MutualAuth/72057594037927953 SMSSiteCode=PRI PROVISIONTS=PRI20003″

Your values will be different (and don’t try copying the quotes, they’ll likely be turned into smart quotes by the process) – just consider this an example.  Make sure that app is deployed to an appropriate group of devices so that it is installed by Intune.  And you’re all set – if you did everything correctly, the task sequence you specified should run automatically after the client installs and initializes.  (That initializes piece is fairly important:  Because there is a 10-device limit in ConfigMgr tech previews, I tore my hair out trying to figure out why this didn’t work, only to discover that I had collected about 20 devices in my ConfigMgr site server after performing a bunch of Autopilot tests.  After I cleaned out all of the garbage devices, most of which weren’t even clients but had been discovered from Active Directory, then everything started to work.)

I mentioned previously that there were some constraints.  Here they are:

• There’s no integration with the Enrollment Status Page yet – we’re still working on that.  So while the task sequence will run, it won’t be tracked and you can’t block the user from getting to the desktop.  That’s coming in the future.
• There can be some interesting behaviors based on the co-management configuration in ConfigMgr.  When the ConfigMgr client initially installs but hasn’t yet initialized, it will “own” all workloads – Intune may notice that and immediately stop sending apps and policies to the device.  Later, when the ConfigMgr client is initialized and receives policy from the site, those workloads may shift back to Intune.  Watch out for that flip-flopping.  (If you’re going to do everything via ConfigMgr, this doesn’t matter much as Intune would only need to push the ConfigMgr agent and then it’s done – at least for now, with no ESP integration.)
• This can be messy when you are doing Autopilot Hybrid Azure AD Join white glove deployments.  The reason: ConfigMgr needs either an Azure AD token or a computer cert in order to authenticate, and neither of those are available.  (You might think “sure, I can deploy a cert via Intune” but it will likely end up with the wrong computer name, which ConfigMgr will not use.)

Otherwise, have fun.