This blog will be about my first encounter with APv2. Yeah!! APv2 As in Autopilot version 2. Did I get your attention??? I am going to assume I do. I will guide you through my first peak at the files that are responsible for Autopilot V2 and how I stumbled upon them, just by being me and nothing else. This first post will be the first one in the Autopilot Version 2 series!
1. Introduction
Everyone that is expecting me to spoil all kinds of Autopilot NDA stuff here… nope, not going to do that :). Also, I will not show you pictures from the Autopilot session during the WP Ninjas summit. If you wanted to hear that information firsthand, you needed to be there in person π
So let’s continue and let me describe what I am going to talk about. After my response, I gave on Twitter (MS: check time and date π) about something called APV2, I felt the urge to still write it all down.
So here we go! On 10-11-2023, I was scrolling down the IME (Intune Management Extension) log with the CMtrace tool to find a culprit with a Win32 app that failed to install.
Nothing fancy and the root cause was detected and resolved within a couple of minutes but!!!! While I was looking at the IME log something funny and amazing caught my attention.
When I was looking at the IME log, I suddenly noticed the APv2: Checking device is in APv2 mode. Even when it doesn’t pronounce the whole word, at that time I pronounced it as Autopilot V2 Mode instantly.
I have learned one thing these couple of years, my first thought is always the one I need to follow. So I guess I need to make a new Autopilot Tree with its moving components in the future.
Besides the APv2 Keyword, Microsoft made it very easy for me to find out more about how the IME detects if the device is in Autopilot v2 mode. The IME is trying to detect if a certain registry key is configured: DevicePrepHintValue. With this switch, I guess it’s pretty obvious that Autopilot v2 is not going to replace Autopilot V1; otherwise, we wouldn’t need a switch to determine the version, right?
Let me show you some simple magic that got me going.
As shown above, I used the free version of the text crawler and just did a quick search for the keyword: DevicePrepHintValue in all of the files in the Intune Management Extension Folder. The funny thing about Textcrawler is, that you could even search in DLL files, isn’t that just wonderful?
That search quickly showed me all of the files in which the keyword (DevicePrepHintValue) was configured. It guided me to the DevicePreparationProviderCommon.dll
When looking up that file, I noticed that that file was pretty new on my device… Just a couple of weeks old
At first, I thought it was nothing new and nothing fancy because we already have a Device Preparation phase during Autopilot, right?
To be sure I opened the Windows.Management.Service.dll on my own device with the IDA tool and also a device that has the latest Insider Preview Canary build installed.
As shown above, this is my own device (Windows 22621.2428)… only 6 mentions with DevicePreparation in it. Let’s do the same for the Insider preview (25951.1000)
Wow… 1054 mentions of devicepreparation, that’s a lot more than I was even expecting. 6 or 1054… that’s a big difference. Now I am interested! Before continuing let’s do a quickie and just take a glimpse at my drawing board.
2. My drawing board
You may be wondering why I always dropping some mspaints flows in my blogs lately. Let me tell you how I work a bit.
If I “discover” aka stumble into something funny, I always take screenshots of them and place them in MsPaint. It’s just acting like a whiteboard for me. Every time I find out something more I just place it where it needs to be and connect the dots to it until it starts making sense. (at least for me)
3. Autopilot Device Preparation
When you take a closer look at my own whiteboard, you will notice that I am mentioning a couple of important system files. Those files could tell you a lot if you spend enough time looking at them.
First, let’s sum up some of the Intune Management Extension files that have arrived with the IME that contain the word APv2.
Let’s start with the first 2, I mentioned in the introduction (devicepreparation and bootstrapperagentcore). Those 2 files pointed me to something called “Device Preparation.”
The devicepreparationprovidercommon.dll holds the function to detect if the device is in Autopilot V2 Mode so the IME knows if the device is in APv2. It does so by checking out if a specific registry key exists.
The IME tries to find the AutopilotDevicePrepHint registry key inside the Software\Microsoft\Provisioning\AutopilotSettings key.
Of course, I tried to manually create that registry key and set it to 1 before enrolling my device into Autopilot.
Guess what the IME log showed me? The device is in APv2 Mode
With this key AutopilotDevicePrepHint set, the IME thinks our device has the payload to get the device into Autopilot v2 mode. After the first few steps and registering our device into mobile management, the device was stuck on identifying the apps.
When we switch back to the registry key that we created, we will notice that just after the IME got installed and checked the AutopilotDevicePrepHint , it will create some additional registry key to specify if the mdmagent got installed
When we manipulate the Autopilot enrollment by setting that specific AutopilotSettings registry key, it is stuck on identifying and deploying the Win32apps (all msi apps/office, etc seem to be getting installed pretty fine) but somehow all the “blocking/tracked” apps we configured in the Autopilot profile didn’t seem to be getting installed (and also missing in the tracked apps in the setup registry key)
A small resume before we continue: Autopilot V2, does something with Win32apps as it seems. Let’s find out more!
4. Win32App and Script Plugin
As shown in the picture in the previous part, we also have some existing IME files in which Apv2 is being mentioned. The 2 most important ones are the Win32App and the Scriptplugin. You may take one guess, what those 2 DLLs are responsible for! I guess something with delivering Win32Apps and Scripts?
When we start with the Win32App plugin, we will indeed notice that this file is also trying to find out if the device is in Apv2 mode… Mmm so with Autopilot v, something is going to change with the delivery of win32apps. (Sounds like a future blog)
But I am not done yet, because the script plugin also mentioning APv2
With this addition, I guess it’s pretty obvious that when you are using Autopilot v2, “something” is going to change with how we can deploy win32apps and PowerShell scripts? I am not done yet with my first look at what is going to change with Autopilot v2! Let’s take a look at the UWP app: CloudExperienceHost which is used for Autopilot
5.CloudExperienceHost
If you have read my blogs about autopilot and my attempts from back in the day to disable the possibility to create a local account, you could have noticed that the Autopilot UWP web app and its files are stored inside this folder:
C:\Windows\SystemApps\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy\webapps\inclusiveOobe\view
Inside this folder, we have an additional Autopilot folder and if we compare that folder with the same folder on a not insider preview build we will spot something
My Insider preview VM now has an additional file called: Autopilotdevicepreparation-main. So is this telling us that the devicepreparation is going to be something different than the Autopilot ESP page we have now? It certainly looks like it.
If we go back a few folders to the javascript folder, we will also notice 2 new files here. (inclusiveoobe\js\autopilot).
DevicePreparation again! Even when looking at the size of the javascript file and what’s inside, it almost looks like a completely new additional page!
Does this mean that we will get a new Autopilot web page when enrolling our device with Autopilot V2? I guess we will find out in the second blog of the Autopilot Version 2 series.
Conclusion
I can’t wait to see more, or play around with Autopilot V2 when it hits the “streets”. With the Autopilot DevicePreparation files being in the insider preview build, it looks like it’s coming!
For now, I can only assume that Autopilot V2 is going to be a separate version and will run next to the “old” version. When looking at the DLL it touches, it looks like there is some stuff going to change about how Scripts and Win32Apps are being deployed.
Interesting. Yes, hopefully they’ll add the ability to have apps designated to only install during Autopilot even though the target is “all Windows hashes”. The work-arounds for this today are not even circus worthy π
Great writeup as always π
Have you seen this? https://learn.microsoft.com/en-us/windows/client-management/mdm/devicepreparation-csp
Interesting article. Thanks very much for sharing. It’s good to read an article which shows depth of investigation but presented so clearly.