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 firstname.lastname@example.org 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.
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.
18 thoughts on “AutoPilot for existing devices: Move from Windows 7 to modern Co-managed Windows 10 in a jiffy using ConfigMgr”
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
Just to make sure: I can use the above procedure on any device, without importing the hash value in autopilot?
Yes – that’s why the deployment profile also converts the device into an AutoPilot device 🙂
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 🙂
Hi, have you had any success using this process for Hybrid AD Joined deployment profile? Even if I only have one profile configured and it’s a Hybrid AD profile; it only does an AAD join. The same profile and configuration policies work fine if I import the device HWID using the CSV import process. I can only think it’s something to do with the dynamic group membership.
Hi! No, I haven’t had any success with a hybrid join and I don’t know if it will work. It’s on my to-do to ask the product group here and get a confirmation 🙂
My image deployment and AAD join using Autopilot json works fine. But I have following observations, any help is appreciated :
Scenario : Wipe & Load (Initiate above TS from within Windows 7 or 10 or deploying using PXE)
1) Auto Deletion of Json file:
The process of automatic deletion of AutoPilotConfigurationFile.json file from c:\Windows\Provisioning\AutoPilot folder post logon is inconsistent. In some instance file is deleted automatically while in some instance file is left over.
2) Powershell script to retain existing computer name:
The process of Powershell script updating the Json file with existing computer name works. No issues.
The issue is :
If the hardware is never deployed and enrolled using AutoPilot Json process, the computer name written by PowerShell script into Json file will work. i.e. it will get the existing computer name.
If the hardware is already deployed and enrolled once and you decide to reimage, either PXE or within windows it will not use the existing computer name even though powershell script updates the JSon file. It will use the computer naming format stated in AutoPilot profile set in Azure / Intune.
Hi Martin, thank your for this great guide. One question regarding your last paragraph:
“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.”
In our case we block personally owned devices. Our OnPrem devices are synced to aad.
Would it still be possible if the put the synced onprem devices into the Intune_ConvertToAutopilot AAD Group? Or are there other dependencies why we need this setting?
Else we have to create the .csv, upload the devices into autopilot and add them to the autopilot profile form the json file?
I have the same query. Have you found the answer and can you please share?
I just replied to Marc. Apologies for the very late reply here.
I’m afraid not. If you block personally owned Windows devices, you cannot use this method to move into AutoPilot. This is because the device isn’t really an AutoPilot device when just copying down the .json.
On the other hand, if you convert the devices into AutoPilot and they get registered with the AutoPilot service, they are no longer considered personal devices.
If people are still following your guides, which is pretty awesome 🙂 Then you might update your Powershell script in line 4 from Connect-AutopilotIntune -user email@example.com to Connect-MSGraph 🙂 otherwise it will fail because its not used anymore as you know i guess 🙂
But really nice guide, great job! 🙂
Does this work on devices that are connected via VPN?
so my question is, we only have Azure AD Registered devices, I have tried MDM enrollment on few devices. They enroll into Intune but they also get added to the All Autpilot Devices group- automatically because it assigns the ZTDId to the device. Once the device is added to All autopilot devices group automatically, it tries to install all the applications that are assigned to all Autopilot Group. We are trying to avoid getting applications installed on the devices that are Converted to Autopilot with the deployment profile. Is there any automated way to stop getting these devices added automatically to All Autopilot Devices group after they have converted to autopilot?