The Wonderful Story of APV2 Device Preparation

In one of my last blog posts, I described how I noticed that Autopilot Version 2, AKA APV2, was coming. This blog is the second in the Autopilot v2 series, and it will zoom into some more details. Shall I let you in on a secret? This blog post will show you one of the new Device Preparation Autopilot version 2 pages. Or did I spoil too much?

1. Introduction

Let’s start with a small summary of the first part of this series. I recommend you read it before continuing with this blog post.

Windows Autopilot Version 2 | APv2 mode | DevicePreparation

For those who didn’t want to read it :P. In the first blog post, I stumbled upon something called APV2 that was mentioned in the IME log.

The IME determines if it’s in Autopilot Version 2 mode by checking the AutopilotDevicePrephint value. The mention of APV2 and AutopilotDevicePrephint led me to believe that we will get an additional version of Autopilot called Autopilot Version 2. It’s pretty obvious that this new version of Autopilot is going to use something called DevicePreparation. These new Autopilot devicepreparation files can be found in the CloudExperienceHost folder.

C:\Windows\SystemApps\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy\webapps\inclusiveOobe\view

These new Autopilot files are available when you run the latest Windows Insider Preview Canary build.

I noticed that configuring the AutopilotDevicePrephint value impacted the Win32Apps and PowerShell scripts reporting in the Enrollment Status Page. Even when the apps were installed, the old ESP got stuck on identifying Apps.

I was expecting to get myself a new Autopilot page when configuring this key, but somehow that didn’t happen. So I decided to look a bit closer at the process.

2. DevicePreparationDDF

During the Autopilot enrollment process, I noticed Procmon touching some files on the disk. One of the many was the file called. DevicePreparation.DDF

As shown above, I noticed the DevicePreparation file in the corresponding device description framework (DDF) folder in system32. This file contains all the settings we need to configure the CSP.

How the F…., didn’t I notice this file earlier on when I was playing around with the Canary preview to get more details about the latest Declared Configuration improvements? The funny thing about this DDF file is that it isn’t something new because Microsoft already had their documentation in place for this CSP in February 2023

So, we can assume that Microsoft has already been working on APV2 for at least nine months (I assume a bit more). This CSP is used to configure the DevicePreparation CSP, which is used for Autopilot V2. You are free to draw your own conclusions now…

This devicepreparation CSP mentioned a couple of important things. One of them immediately caught my attention. This setting is called: PageEnabled.

As shown above, “this node determines whether to show the device preparation page during OOBE”. Okay… that’s funny, I guess we need to test it?

To do so, I first started playing around with PowerShell and trying to find out which settings are configured in the classname “MDM_DevicePreparation”

Bingo!!! The mdm_DevicePreparation class indeed showed me the same settings! Nice!

3. PageEnabled

I guess it’s time to play around with the discovered Device Preparation settings. I installed my VM with the latest available Canary build and used the local mum PowerShell module to deploy the PageEnabled Setting. From there, I watched Procmon go.

This PageEnabled CSP will configure/add a new setting to the provisioning\autopilotsettings\devicepreparation registry node. The funny thing is that when I wrote the first blog post of this series, the AutopilotDevicePrephint was also created in this registry key.

As always, I checked if I could find any mention of PageEnabled in the Windows.Management.service.dll. The first function in that file that contained the keyword PageEnabled was the: AutopilotGetSetting function.

I guess I don’t need to explain this function, as its name already tells you what it does. As shown below, it does try to find the PageEnabled setting in the device preparation reg node.

So, I guess we are on the right track? I think it’s time to enter my credentials and find out what will happen. Will it explode in my face, or am I going to be a lucky bastard?

4. The New DevicePreparation Pages

Before starting, I manually created the autopilotdeviceprephint value in the correct devicepreparation registry node. With that first key created, I also created the DevicePreparation registry node and ensured the PageEnabled key was configured to 1. Once those keys were created, I entered my username and password. I started watching if something changed with the Enrollment Status Page. Within a second or two, the device started setting up my device. Nothing new here…

A few seconds later, something magical happened! ….. Drums, please!!! The New Autopilot Device Preparation page showed up. This page was indeed showing me the same things I noticed when taking a look at the corresponding JS files in the cloudexperiencehost folder

At that point, it started the same steps as expected in the background, but it still showed the “installing management extension”. Weird.. but then again, I am doing this all on my own, trying to figure out what makes it tick.

I can cross 1 thing off my list: trying to enable APV2. From there on I waited and hoped to start seeing more new Autopilot pages (even while I didn’t find anything that could indicate there was more to find)

After waiting some time, I guess my dreams came true?

As shown above, a nice ice cream cone appeared, mentioning that it can’t continue setup because of a critical error. Of course, I could press skip device setup, but that wouldn’t be fun, right?

I opened the shell-core event log to find out what the actual error was

The event log is mentioning that the Agent installation is canceled, likely due to timeout. That’s weird? I thought this MDMagent was nothing more (maybe it is or a different version…. but… ) than the Intune Management Extension (IME). In the first blog post of this series, I mentioned the mdmagentinstalled registry key. This key will be created if the mdmagent is successfully installed.

So to be sure I wasn’t going crazy, I opened that specific registry node and checked if the mdmagentinstalled was set to 1. Uh okay as shown below, the whole key was missing

That’s weird, right? In a normal situation (not a rudy enrolled autopilot device), when the SLDM Provider hint, AKA AutopilotDevicePrephint, is configured, the Intune Management extension detects this key and uses it to determine if the device is in APV2.

From there on it will install the IME and would ask the devicepreparationprovidercommon.dll to configure the (MDM) provider ready hint value.

It would set that mdmagentinstalled to 1. I opened the IME log to find out what was happening.

That’s even weirder! Somehow, the IME isn’t detecting if the device is in Autopilot v2 anymore. What happened?

5. The New AutoPilotDevicePrephint

I decided to open IDA again and start checking the devicepreparation IME DLL and opening the SetSldmProviderExecutingProvisioningHint function.

As shown above, it’s trying to find the AutopilotDevicePrephint value inside the AutopilotSettings registry node.

Uhhh… Uhhh.. So let me get this right, somewhere between I published the first blog post about APV2 and this one, Microsoft moved it? Because as shown below, that key was first deployed in the Devicepreparation subnode?

Well okay, fine, I guess we now need to create that AutopilotDevicePrepHint in the root of the Autopilotsettings instead.

Before we continue and start looking at what will happen when we try again if we create that value in the proper place, I still need to tell you a small side story.

While trying to find more information about the whole process, I also noticed that the OMADMClient also tries to detect if the device is in Autopilot version 2 mode by looking at the DevicePrephint key

6. GenerateAutopilotV2AlertXml

While enrolling my device with APV2 for the 1000^th time, I noticed that the OMADmclient was also trying to detect if that autopilotdeviceprephint was created

So, I decided to also take a look at the OMADMClient (again…) and started searching for that same key when it initializes a session

Enrolling my device for the 1000 and 1 time, I also ensured I had the SyncML tool opened and running. As shown below, it was indeed sending out a 1224, check-in alert to the service

APV2 as in Autopilot V2… Looking up the getautopilotdeviceprephint led me to the OMADMCLIENT functionGenerateAutopilotv2AlertXML

If we take a closer look at that alert template we will notice that it indeed contains the same XML we noticed in the SyncML tool

Funny side story, right?

Okay, that XML was nice to spot, true… but while looking at it, I again spotted the FeatureManagement / Known Issue rollback(KIR) stuff

Before the OMADmClient tries to find that APV2 key, it first tries to determine if the feature is enabled or disabled. Again nothing new… Do you remember the blog in which I was telling you why MMPC wasn’t anything new and was already out there in 2020?

WinDC | MMP-C | SecuredCore | ConfigLock | WCOS | EPM (call4cloud.nl)

Looking at old DLL files is like having a nice beer while enjoying the sunset but I guess it’s not for everyone. So, if you want to know how to keep up to date with what Microsoft is cooking without spending time on code, you could take a look at this GitHub page.

mach2/features/rs_prerelease/amd64/25314_25324_diff.patch at master · riverar/mach2 · GitHub

This GitHub page mentions every feature you can enable with the Vive tool and in which Windows release this feature was introduced. First, I needed to find myself the ID that corresponds with the feature. As shown below we need to find 41603559

I worked my way through all the diff.patches and finally stumbled upon the 25314_25324 build

AutopilotDevicePreparation was added and by the looks of it, around the same date, the DevicePreparation docs went live.

So, every time a new insider build comes out, I open that page first to determine whether I need to look at some DLLs again.

7. Launch Agent

Let’s return to the Autopilot enrollment to find out what will happen when we configure the proper Autopilot registry values.

This time the device didn’t stop and didn’t throw an error at me (at least not on the devicepreparation page). Now it’s stuck at 100% without anything other than installing management extension.

If we take a closer look at what happens after the MDMAgentinstalled is set to 1, we will notice that the IME tries to initialize the bootstrapper agent by launching the agent function.

Somehow, the initialization of this agent is getting a time out after 300000ms

Luckily, after a couple of weeks of releasing this blog, things changed slightly. This time, the progress reporter kicked in and started showing me a different screen after installing the Intune Management Extension (which is installed at around 4%).

As shown above, it now showed that it was “installing required apps and policies for your organization.”

That’s a big improvement from what it looked like before! It’s a shame that there is still work that needs to be done because the ProgressReporterHeartbeatHandler is still having issues connecting to its host.

So, instead of hanging on to the installing management extension, it’s now stuck on installing the required apps and policies.

8. The whiteboard

As always, the personal whiteboard in which I tried to find the proper path and how stuff works.

Conclusion

Even when this is just a glimpse of what is coming in Autopilot Version 2, hopefully, you all like the new Device Preparation Pages I just showed you. As always, there is more to it than meets the eye, so I still have a lot of stuff I need to look into to give you the whole story. So prepare yourself for some amazing stuff 🙂 (when the insider preview and the IME have the knowledge to do so)