Introduction

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 https://devicemanagement.microsoft.com 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:

Install-Module AzureAD
Install-Module WindowsAutopilotIntune

Connect-AutopilotIntune -user intuneadmin@intunetenantname.com

Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON

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: https://www.imab.dk/deploy-the-sccm-client-using-microsoft-intune-and-the-cloud-management-gateway-no-pki-certificates/

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 🙂