First published on TechNet on Oct 25, 2018
At Ignite 2018, we announced
Windows Autopilot for existing devices
, a new feature designed to migrate devices from Windows 7 (or any other version of Windows, i.e. 8.1 or 10), Active Directory-joined and ConfigMgr-managed, to Windows 10, Azure Active Directory-joined and Intune-managed (with co-management with ConfigMgr if you so desire) leveraging the Windows Autopilot user-driven deployment process to drive the Windows 10 configuration process.
Boot to Windows PE (no data migration steps, we assume OneDrive for Business already has the data in the cloud).
Format and partition the drive (so this is clearly a wipe-and-load process, not an in-place upgrade – all data, apps, settings, etc. are cleaned from the drive).
Apply the new Windows 10 OS image.
Inject drivers into the applied Windows 10 installation.
Copies an Autopilot configuration file into the proper location in the Windows folder structure (this enables an Autopilot user-driven experience without harvesting and uploading the hardware hash in advance).
Boot into Windows 10.
Install the ConfigMgr client.
Sysprep the Windows 10 OS.
Reboot into Windows 10 OOBE.
This takes quite a while – about 20 minutes to get into Windows 10 the first time, then another 20 minutes to generalize (sysprep) and re-specialize the device. And that’s before the time it takes for the Autopilot configuration (Azure AD join, Intune enrollment, pushing policies and apps, etc.).
So how can we make that faster? Simple: Only boot into Windows 10 once, and don’t sysprep it. (The OS image being applied initially, straight from the Windows 10 media, has already been sysprepped and captured. What’s the downside? Well, you can’t customize the Windows 10 OS, but I would argue you don’t really want to do that anyway; the goal is to treat these existing devices just like new devices, which would probably be configured via Intune exclusively, or Intune + ConfigMgr in a co-management configuration.
So let’s look at what that task sequence can look like:
Apart from the removed steps from above (6, 7, 8), there are two other changes:
A new step to remove the unattend.xml that the “Apply Operating System” step automatically creates (this gets in the way of Autopilot).
A PowerShell script (“Copy adjusted JSON”) to copy an edited AutopilotConfigurationFile.json into the right location (more on that later).
The net change: 20 minutes or so removed from the process. You can find an exported version of my task sequence attached to this blog.
Now here’s a little more detail on that “Copy adjusted JSON” task sequence step. The official docs have you create an AutopilotConfigurationFile.json, with a step that copies the file without any changes to the correct location. In my PowerShell version of that step, I make one edit before writing the file to the correct location, inserting the existing computer name so that the “new” Windows 10 OS ends up with the exact same name as the “old” Windows 7 installation. Here’s the script in its entirety:
# Read the current config
$config = Get-Content .\AutoPilotConfigurationFile.json | ConvertFrom-Json
# Get the computer name
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
$computerName = $tsenv.Value("_SMSTSMachineName")
# Add the computer name
$config | Add-Member "CloudAssignedDeviceName" $computerName
To use the script, save it as AdjustJSON.ps1 and put it in the same folder as the AutopilotConfigurationFile.json that you created following the official documentation. (And make sure you have PowerShell and .NET included in your Windows PE boot images.)