AutoPilot for existing devices: Move from Windows 7 to modern Co-managed Windows 10 in a jiffy using ConfigMgr


Lately I have been preparing our own shift from old school device provisioning with PXE and ConfigMgr, to the modern alternative with Windows AutoPilot. The preparation is two folded, where the mindset of the IT pros working with the technologies needs a shift, but obviously also the technologies and features involved.

We’ve been hitting F12 and preparing devices within IT for many years and while it’s easy to persuade IT pros into using new and exciting technologies, the businesses we serve also needs maturing. We are not quite there yet, but we are getting closer, and the first step is obviously to embrace the technology and start using it.

We don’t have any devices running Windows 7 in our environment (phew), but this is an approach that can be used with previous versions of Windows 10 as well. For example when moving from 1803 to 1809.

AutoPilot Deployment Profile

The first step in achieving this goal, is to export and convert the relevant Windows AutoPilot deployment profile. This obviously assumes that you have one created already. For the newbie, deployment profiles are found and created in the Microsoft 365 Device Management Portal at in the Device enrollment -> Windows enrollment blade. See below illustration:

For your convenience and for your inspiration, in this example I’m using a User Driven and Azure AD joined profile looking like this:

As mentioned, we need to export and convert the profile into a JSON format. This is done through Powershell:

The output will be similar to this. Note that I have 2 profiles, why the Powershell output will display 2 profiles as well. The one we need here, is the one called Default AutoPilot Profile.

Copy all of that into Notepad.

OBS: Notice my red arrow. This line cannot break into two, which a direct copy/paste from above will do due to the lacking width in the Powershell area.

Save the content as AutoPilotConfigurationFile.json with ANSI encoding and create an old school package in SCCM containing this as the source files. No program is needed here. (This is very basic SCCM and not covered here with respect to the total length of the post)

Don’t mind the .ps1 file in there. I’ll elaborate later.

Task Sequence

With above in place and the package containing the .json created, we can move on to the task sequence used. Create a new task sequence and select “Deploy Windows AutoPilot for existing devices“.

Note #1: This is based on Configuration Manager Current Branch 1810 and the minimum requirement is SCCM 1806 as well as Windows 10 v1809.

Note #2: If you run SCCM 1806, you will have to create the steps manually from a blank Task Sequence. This option is first introduced natively in 1810.

Give the task sequence a suitable name and select a boot image. Note that the boot image used must be based on Windows 10 v1803 or later which equals to minimum 17134.

Select your image package containing Windows 10 1809. This can be a custom captured .wim, but I suggest you use the default install.wim from your Windows 10 1809 media. The whole idea here is, that build and capture is considered obsolete and new devices are obviously not shipped with your custom image.

And point to the package you created earlier containing the new .json file.

The net result is below task sequence.

Now, per Michael Niehaus post on Speeding up Windows Autopilot for existing devices, this can be done a tad differently speeding up the process even further. Read his post for details.

Taking Michael’s changes into account, this can give you a result similar to below.

Michael also covers a way to keep the device name. This is the Powershell script which is also stored in the same location as the .JSON file.

OneDrive Known Folder Move

Where and why does OneDrive come into play? Due to this being a clean install of Windows, you will want to make sure your users documents and files are available POST installation of Windows 10. OneDrive Known Folder Move to the rescue.

This is my Windows 7 device with my files on the desktop, documents and pictures folders synced with OneDrive. With this in place, I’m confident to move on with the upgrade to Windows 10 through the Windows AutoPilot experience knowing that my files are stored in OneDrive and will return once the installation is complete.

The upgrade experience

Running the task sequence from the Software Center will boot the device into Windows PE.

Eventually ending up in the AutoPilot OOBE

And when signing in with an account allowed to join devices into Azure AD and enroll devices into Intune MDM, you will get past all the steps in the Enrollment Status Page:

Final touch in Intune

A final but important touch in Microsoft Intune, is to make sure the newly provisioned device is kept as an AutoPilot device moving forward. This can be done either by manually adding the device to the AutoPilot service or by automatically converting the device.

Needless to say, we don’t like to do stuff manually, so taking a closer look on the deployment profile, you will have the option to Convert all targeted devices to AutoPilot.

In this example, I’m assigning the profile to a group consisting of ALL AutoPilot devices and another group of devices, which is not yet considered AutoPilot devices (devices equal to those deployed with this method).

Doing this, the profile, which is considered the default profile in this environment, is assigned to all devices that are imported into the AutoPilot service with whatever means AND devices which are not yet AutoPilot devices.

Devices deployed using this method will eventually be members of both groups, where the group consisting of ALL AutoPilot devices (Intune_AutoPilot_All_Devices) will be the group generally used for assignments throughout the AutoPilot configuration.

Note #1: The group containing all AutoPilot devices is made with this dynamic membership rule: (device.devicePhysicalIDs -any _ -contains “[ZTDId]”)

Note #2: The only logically way of grouping the devices not yet AutoPilot devices I could come up with, was grouping based on the device name. My deployment profile dictates that the devices are named with a specific prefix. This is used in a group with a dynamic membership rule.

Company Portal and Co-management

Another great addition is to assign the company portal as required to all your AutoPilot devices. In this example, the Company Portal will install once the device has been converted to AutoPilot.

To add some extra deliciousness to the whole process, we can install the SCCM client onto the device in order to reach Co-management. I have covered that in a previous post here:

In this example, the SCCM client is made available in the Company Portal (the keen eye will also notice my files on the desktop are still there POST clean install):

More of importance

All of this goodness will not work, if you block enrollment of personally owned Windows devices. That be if you have this setting set to Block. So that is something to consider.

The details are, that the device while being enrolled as company owned, is not considered an AutoPilot devices until it has been converted or imported manually. Thanks to Oliver Kieselbach for making me aware.

Enjoy 🙂

6 thoughts on “AutoPilot for existing devices: Move from Windows 7 to modern Co-managed Windows 10 in a jiffy using ConfigMgr”

  1. Another great tutorial post Martin, I’m so glad I found you on Twitter 🙂
    My company (30k users and devices and a full ConfigMgr 1810 setup) is also interested to going to Autopilot with Intune management but I think we will have a more challenging journey as we require an en-GB base WIM which I currently create in a Build and Capture sequence using a custom script to add the GB client pack and all additional LIP’s before deploying it using another custom deployment TS. As all base media from Microsoft in our VLSC is en-US, installing en-GB and ripping out en-US in an Intune/Autopilot sequence as well as all our other company specific stuff will be interesting!

    • Andy, thank you so much for taking your time to provide feedback. Much appreciated 🙂 An another note, it’s perfectly doable to add language packs using MS store for Business and Intune

  2. The device you are deploying like this, does it have to be known in Intune?
    If I’m not mistaken, the device has to be member of 1 of the 2 groups(Intune_ConvertToAutopilot or Intune_AutoPilot_All_Devices) to be able to receive the correct autopilot profile.

    • Once the device enrolls into the AutoPilot experience, the device joins Azure AD. This is where it’s picked up by the new device name and targeted with the deployment profile which converts the device into an AutoPilot device. no need to import the hardware hash here 🙂

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.