Last Updated on February 6, 2024 by rudyooms

In one of my last blog posts, I was describing how I noticed that Autopilot Version 2 AKA APV2 is coming. This blog is the second one 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?

I will divide this blog into multiple parts:

1. Introduction
2. DevicePreparationDDF
3. PageEnabled
4. The New DevicePreparation Page
5. The New AutoPilotDevicePrephint
6. GenerateAutopilotV2AlertXML
7. Launch Agent
8. The whiteboard

1. Introduction

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

For the ones who didn’t want to read it :P. In the first blog post, I stumbled upon something called APV2 that was being 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 etc were getting installed, the old ESP was getting 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 that Procmon was touching some files on the disk. One of the many was the file called. DevicePreparation.DDF

As shown above, in the corresponding device description framework (DDF) folder in the system32 I noticed the DevicePreparation file in it. 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 was already working on APV2 for at minimum 9 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?

3. PageEnabled

I guess it’s time to play around with all of these settings. I installed my VM with the latest available canary build and I used the localmdm powershell module to deploy the PageEnabled Setting. From there on 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 the name already tells you what it does. As shown below, by the looks of it, it does try to find the PageEnabled setting in the devicepreparation reg node.

So, I guess we are on the right track? I guess 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 created the autopilotdeviceprephint value in the correct devicepreparation registry node. After creating the deviceprephint value and also after manually creating the DevicePreparation registry node and making sure the PageEnabled key was configured to 1, I entered my username and password. I started watching if something changed with the Enrollment Status Page. Within a second or 2, 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 we would expect 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 guess 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 showed up 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 had the idea that 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 would detect this key and use 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 made sure 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 just open that page first to determine if I need to spend time looking at some DLLs again.

7. Launch Agent

Let’s get back to the Autopilot enrollment to find out what is going to happen next 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 is happening after the MDMAgentinstalled is set to 1 we will notice that the IME tries to initialize the bootstrapper agent. To do so it tries to launch 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 a bit. This time the progress reporter kicked in and started showing me a different screen after it was done installing the Intune Management Extension (that is installed around 4%).

As shown above, it was now showing the fact 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 the installing management extension its how 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 has the knowledge to do so)