Many of us have been testing the new Windows Autopilot Device Preparation Policies (or Apv2, whichever you want to call it). Don’t worry, this is not another blog on how to configure APv2. There are tons of those already out there. I’ve been testing this over the last week and my testing has been mostly positive. I think this is a great step forward. This is a welcomed addition to autopilot, but we lose several things that APv1 had:
- The new ESP will only install apps targeted to devices
- Self-Deploying and Pre-Provisioning
- No Hybrid (I don’t think anyone is complaining about this one)
- More OOBE prompts (this is annoying, but a minor loss in my opinion)
- No device naming template
Overall, for the majority of user-driven autopilot devices, Device Preparation Policies will become my preferred method (once OEMs start shipping with updated Windows builds). The ESP is much cleaner, seems to progress quicker, and the reporting is great. I also love the ability to specify scripts that can be ran during the ESP. However, the lack of a device naming template is frustrating. Users can provide their own device name during the OOBE or skip and end up with the default DESKTOP-XXXXXX name. This happens before the user signs in with their work account, so the user can choose whatever they want:
I wrote a few blogs a while back regarding renaming hybrid autopilot devices and how to initiate a reboot at the completion of the ESP (for APv1). I wanted to revisit this and come up with a solution to use a device name template for APv2. Microsoft says there are enhancements coming that will allow us to rename devices natively during provisioning. Until then, however, we are stuck with the tools we have available.
Renaming a device is a very simple process. We can accomplish this with PowerShell using rename-computer. The challenge is that the PC name doesn’t take full effect until after a reboot. So, determining how we can force or prompt for a reboot is something else that needs to be considered. Or, you can just rename and wait until the user reboots anyway. I prefer to automate as much of this as possible. It usually only takes a few minutes for Entra to pick up the new PC name after the device is rebooted, so I prefer to try enforcing a reboot after the device is renamed. If you simply want to rename and want to wait until the user performs a reboot on their own (or for Windows updates to perform the reboot), you can grab the rename script here, add it as a platform script, target your device preparation group, make it a required script during the device preparation ESP, and you’re good to go.
In my previously referenced blogs, I used a Win32 app to accomplish these tasks. However, with the new APv2 ESP, we now have the ability to use platform scripts and require that they’re executed during the ESP. This is a more attractive solution because these run once and won’t re-run unless they’re changed. We also don’t need to worry about detection rules. With all of that being said, you can certainly use a Win32 app if you prefer.
I have not dug entirely into the new ESP to determine all of the similarities and differences on the backend, but the new ESP still runs as the defaultuser0 account. During the ESP, the device is joined to Entra, Enrolled into Intune, added to your specified device group in the device preparation profile, and runs apps/scripts that are specified as required in the device prep profile. When that completes, and you click continue, the defaultuser0 account is disabled and signed out, and then the identity used to initiate the device Autoipilot prep profile is signed into the device and runs through the first sign-in experience. So, the new ESP is entirely focused on Intune apps/scripts/policies targeted to the device.
Renaming during the ESP and enforcing a reboot after
Now, on to using a device naming template. I’ve mimicked the most common device naming template used in APv1 for this, which is Prefix-%SERIAL%.
I currently have two scripts that I use, but they can be combined into one if you’d prefer. The first script simply renames the device. In testing I have this set to SMB-%SERIAL%. This can be combined with the second script, or added as its own platform script. The serial length is determined and shortened if necessary. The second script does the following:
- Creates a scheduled task to reboot the computer on event 4725. This event is logged after the ESP when the defaultuser0 account is disabled.
- The task XML files and action scripts are downloaded from github, and the tasks are created on the workstation. These can be edited without updating the Intune script. One performs the reboot, the other notifies the user there will be a forced reboot in 20 seconds (more on this below).
- When the task runs, it disables the scheduled tasks so it won’t run again if event 4725 occurs in the future. You can also uncomment the lines to unregister these if you prefer.
All the scripts are available here. If you want to use this as-is, edit the rename script to use the prefix you want, and upload it as a platform script. Then download the IntunePlatformScript-RebootPostESP.ps1, upload it as a platform script, target the device prep group, and add it as a required script to the Device Prep profile.
If you don’t know where those areas are:
And:
In my testing, the best trigger to initiate a reboot is using one of the events for the default user account being disabled or logged off. In APv1, this would trigger immediately at that moment in the ESP. However, with APv2, the typical first sign-in experience happens, and scheduled task actions seem to be delayed until the first sign experience is complete. So, you’re stuck waiting for these screens to complete:
As it stands now, through my testing, in most cases the reboot happened before the user even saw their desktop (which is what we want). However, sometimes the user will get to their desktop, and then the reboot will occur anywhere from 2-20 seconds later. It seems this depends on the resources on the computer and when it comes to launching the actions from the tasks.
Because there is sometimes a delay, I also wanted to use some form of notification for the end user since there is a slight delay. After making a script to use a toast notification, I realized that DND in the notification area is on by default for Windows 11. So, typical toast notifications don’t display for the users. I messed with trying to enable notifications for the user, but couldn’t find anything after an hour, so I switched to a different method.
Since toast notifications don’t work, we can use a com object notification window instead. In the event you hit a delay, your users will at least see a notification before they’re rebooted.
If you don’t want to notify the user, feel free to remove the notification components of the platform script. In most cases, the user experience will be like the animation below. This is obviously sped up:
If you require WHfB registration at first logon:
If you require WHfB in your environment, the forced reboot can be annoying if you hit a slight delay in the reboot like I mentioned above, because it may happen while the user is trying to register for WHfB. In that case, we can use event ID 300 from the User Device Registration log, which is logged once the passport key is uploaded to Entra.
We can see that the reboot is timed better here, so if you use WHfB, this method is probably better. If you require or make Windows Hello optional after the ESP, use this script. The reboot will be times a few seconds after the user registers their WHfB method, similar to the animation below:
