Deploy SCCM images with something other than SCCM

I’ve stated many times that you could take an image from MDT and deploy it with anything, as there’s nothing MDT-specific captured in the image. But curiously, I’ve never heard any comments about the inverse of that, taking an SCCM image and deploying it with MDT or other tools like Tanium Provision. But someone asked the question, which made me try it out.

First, I needed to capture an image using SCCM. That’s not too hard using a “capture” task sequence:

The “Prepare OS” step runs Sysprep to generalize the OS, a necessary step. But what does the “Prepare Configuration Manager Client” step do? According to the documentation, it will remove the SCCM client from the OS (and if you deploy that image with SCCM later, it will get reinstalled anyway, so it might as well be removed) as long as you create a “capture” task sequence using the SCCM wizard (additional steps may be required if you created a custom task sequence or capture media). From a “use without SCCM” perspective, that’s a good sign — no obvious reason why the captured Windows WIM file can’t be used with other tools.

So the next step is to actually try it. I used Tanium Provision to deploy the WIM file, and everything appeared to work fine — at least until I signed in for the first time. You can see what happened in this edited video (compressing the long-running stuff to save time):

What does that show? Well, the OS is installed and running just fine, joined to Active Directory as expected. But when I tried to log in as a domain user (using my domain’s Administrator account because I’m lazy), the computer rebooted itself. And after that reboot, the computer name was changed and the domain trust was broken:

OK, so WTF? It’s a mystery. Looking for obvious things like Run, RunOnce, scheduled tasks, etc. came up with nothing. But something was triggering the device to behave like it was going through sysprep, and that was undoing what Tanium Provision had already done (e.g. naming the computer).

This one took some detailed registry comparison to figure out. Here’s what the HKLMSystemSetup key looks like on standard Windows media:

And here’s what it looks like in the SCCM-captured image:

See any obvious differences? There’s one that is pretty critical, SetupType. There’s no “official” documentation around any more (that I can find at least) that documents what this setting does, but there is an old TechNet thread that talks about it. It says that SetupType=0x1 means run the command (oobewindeploy.exe) and then reboot, where SetupType=0x2 means run the command and then show the logon screen. So, with the value set to 0x2, we’ve joined the system into AD (using an offline domain join that completes with the next reboot) and then we’re trying to sign in — while OOBE is still running. OOBE ends up doing its normal unattend.xml-driven stuff after that point, e.g. setting the computer name and breaking the domain join.

Alright, but why is that SetupType=0x2 set in the first place? It’s a trick used by SCCM and other tools to allow multiple reboots during the execution of the SetupComplete.cmd script. That’s how it handles the “reboot and continue” operations (e.g. anything a task sequence might throw at it). Tanium Provision (and MDT too) doesn’t need to do that, so it doesn’t mess with that registry key. So boom, bad things happen.

Fortunately, this isn’t hard to fix. You can modify the registry key in your image via these steps:

1. Mount the WIM image using DISM or PowerShell.
2. Load the WINDOWSSYSTEM32CONFIGSYSTEM registry hive using REGEDT32 (select the HKEY_LOCAL_MACHINE node, select Load Hive from the File menu).
3. Navigate to the Setup key (at whatever path you loaded the hive) and change the SetupType value from 2 to 1.
4. Unload the registry hive.
5. Unmount the WIM image, committing changes.

Or, since there are generally going to be opportunities to modify the registry key during the deployment process, this can be done on the fly too via PowerShell:

Set-ItemProperty -Path "HKLM:SystemSetup" -Name "SetupType" -Value 1

That’s what I did for Tanium Provision (mounting the registry while still in Windows PE and fixing the value there), so now it can handle the SCCM-captured image without any issues.