Windows 10

Do not clone an Azure AD-joined or MDM-enrolled Windows 10 OS

The Windows guidance goes back many years: Before you can duplicate or clone a Windows installation (whether physically duplicating the disk drive or using some sort of VM-based snapshot or differencing disk technique), it is absolutely essential that the system be generalized using Sysprep.exe.  That’s also called out in KB 314828:

When you deploy a duplicated or imaged Windows installation, it is required that the System Preparation (Sysprep) tool is used before the capture of the image…We do not provide support for computers that are set up by using SID-duplicating tools other than the System Preparation tool.

And in the Windows docs:

You must reseal, or generalize, a Windows image before you capture and deploy the image. For example, when you use the Sysprep tool to generalize an image, Sysprep removes all system-specific information and resets the computer…If you transfer a Windows image to a different computer, you must run the Sysprep command together with the /generalize option, even if the other computer has the same hardware configuration. The Sysprep /generalize command removes unique information from your Windows installation so that you can reuse that image on a different computer.

When you run Sysprep to generalize a computer, every Windows component gets the opportunity to remove stuff from the system:  Registry keys, certificates, files, folders, etc. – anything that the component knows will cause issues if that installation were every cloned.  But that doesn’t mean every component actually does that.  Case in point:  If you take a Windows 10 installation and join it to Azure AD or enroll it in Intune, the OS will receive multiple certificates tied to the specific device; additional enrollment and device ID information will be written to a variety of places in the registry; policy information and settings will be applied as well.  And *none of that* will be removed by the sysprep /generalize process.

So what does that mean?  Simple:

  • Never clone a device that is joined to Azure AD or enrolled into an MDM service such as Intune.

If you don’t follow this advice, all of the devices using that image will look the same.  Intune won’t be able to tell them apart when they all provide the same device ID and certificates.  And you’ll end up with a mess.  Avoid later headaches – don’t try it.

If you are going to create an image, follow a consistent, repeatable process (e.g. using MDT or ConfigMgr OSD), using a VM, running an automated task sequence that can complete the whole process.  Do not join it to Azure AD or Active Directory; do not get it into a co-managed state (since that would be enrolled in Intune).  Keep it in a workgroup, do your customizations, and run sysprep /generalize at the end of the process.

Or better yet, don’t do imaging at all and use Windows Autopilot…

Categories: Windows 10

5 replies »

  1. Thanks for the article. An interesting scenario happened to us where our site techs accidentally built some devices intended for AAD/Intune management through on-premise ConfigMgr OSD. This removed the vendor recovery partition.
    To reapply the original vendor image we booted a brand new “out the box” device of the same model into WinPE and ran the following command on it:
    DISM.exe /capture-ffu /ImageFile=D:\xxxx.ffu /CaptureDrive:\\.\PhysicalDrive0 /name:xxxxDisk
    We then applied this original image on the incorrectly built device by running:
    DISM /apply-ffu /ImageFile=D:\xxxx.ffu /ApplyDrive:\\.\PhysicalDrive0
    We actually had to reapply this image to 6 devices that were incorrectly built. The 6 devices then went through the standard OOBE organisation join into AAD and Intune. There are 6 objects in Intune that received the correct policy/configuration etc but the kicker was that they all ended up with the same computer name. With pure modern management I don’t think there is an issue here but can you let us know your opinion of this scenario we ended up in?

    Like

    • If they were captured with the same Intune certs, they’ll end up acting as one device from an Intune perspective. That’s pretty bad overall. (The AAD device gets fixed up by the subsequent OOBE execution, but it doesn’t re-enroll, so all the devices would have the same Intune device ID.)

      Like

      • No, the captured image was from a fresh out the box vendor image. It was just strange that the 6 devices that had that fresh image applied to them ended up with the same computer name in Intune – but six individual computer objects in Intune.

        Like

      • example1:
        Name: DESKTOP-K5UJRJH
        Management name: Jack.HO4_Windows_5/12/2020_10:51 AM
        Intune Device ID: 2218d1ae-88b2-4892-a591-9044f32a4f2c
        Azure AD Device ID: 8cd0747a-a1a3-4243-a853-06fd015e148b
        example2:
        Name: DESKTOP-K5UJRJH
        Management name: Avanthika.Kalaichelvan_Windows_5/10/2020_11:46 PM
        Intune Device ID: 0d3dc5ce-4e63-4082-bf61-e1b050d0d2af
        Azure AD Device ID: e4dce710-919e-4b20-a961-0daa2dea3830

        Like

Leave a Reply to Michael Niehaus Cancel reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s