The social media DMs, e-mails, and blog comments around Autopilot v2 have raised a bunch of questions, interesting points, speculation, opinions, etc. I figured it would be useful to summarize those with even more questions, interesting points, speculation, and opinions of my own.

This will be a long one, so find a comfortable spot, grab a drink,

Is Autopilot v2 (Windows Autopilot device preparation) a preview feature?

No, this one went straight to general availability. Presumably there was a private preview before this happened. As was pointed out in some blogs (e.g. this one from 2023), the bits for this were added into Windows 11 well before the release, but weren’t finalized (well, as final as any release can be, especially with the known issues and additional features that are still being worked on) until the end of March when they were included in KB5035942 for Windows 11 22H2/23H2, as well as being included in Windows 11 24H2 (26100, the Windows Insider release preview version).

The interesting part of this one: It seems unlikely that any OEMs will update the devices that are shipping with Windows 11 23H2 to include the KB5035942 or later. Generally, they update the bits for GA (e.g. November-ish) and for “critical security fixes” which are rare. So if you plan to use devices directly from OEMs, make sure that they either ship a custom image that has the needed fixes, or wait for 24H2 to ship.

How will the known issues be addressed?

The known issue list includes issues that are service side, meaning they can be updated at any time (usually monthly, but bugs that are affecting customers could be updated faster than that), and client-side, which gets much more interesting. Client-side fixes generally get checked into Windows and meander their way into Insider builds; only after those Insider builds have been “validated” externally can that fix be backported into a cumulative update. That process usually takes weeks to months (depending on severity), and then you also run into the challenge I mentioned above: how do you get OEMs to ship those new bits? While it’s possible for there to be a “critical update” that gets installed as part of OOBE, those are generally pretty rare. So you’re back to custom images. The “race against time” would be to address client-side issues in time for OEMs to finalize their fall 24H2 images (typically November-ish). (There was an “Autopilot Update” feature that enabled updating just the Autopilot bits, talked about at various public events in years back, but that’s no longer used.)

When talking about validation in Insider builds, that’s always interesting: What enterprise customers ever use Insider bits to test anything, especially Autopilot provisioning processes? But the “checkbox” of shipping it through an Insider build still exists.

Can I use Co-Management Authority to run an SCCM task sequence with APv2?

If you aren’t familiar with this setup, you can check out this post. The basic idea is that if you create a “Co-management Authority” (a.k.a. “Co-management settings”) item and assign it to a group of devices, e.g. the same one you are using with APv2, it will push down the CCMSETUP.MSI, that will install the SCCM client, and then the SCCM client will run a task sequence.

Since I didn’t see anything in the docs about this, I tried it out. It does appear to still go through the process as CCMSETUP.MSI installed the CCMSETUP service and it tried to install the SCCM client. But that failed because my CMG is unhappy. Even with that failure, the AP device provisioning process finished successfully. So it appears that this at least partially works: the SCCM client will be deployed and the task sequence will run, but it might not be tracked by the APv2 ESP.

I fixed my CMG issue (expired cert) and then tried again, but it failed again, this time with a CCM_E_NO_CLIENT_PKI_CERT error. I would have expected it to authenticate with the user’s AAD token, but that’s not working. I’m guessing that’s something I will have to put that on the list of things to troubleshoot later, quite possibly an issue on my side unrelated to APv2.

Update 2024/06/07 8:07pm: I spoke too soon, I tried it again and it worked just fine. But again it didn’t appear to be tracked.

Can I bypass the EULA page?

At this point, no, with APv2 the user will always see the EULA page. That makes sense, because there’s no Autopilot registration and the user-targeted Autopilot device preparation profile won’t be received until after the user signs into AAD.

The question is whether this will be possible in the future via the tenant binding feature that was mentioned in the original APv2 announcement. It might be — if it’s known that the device is org owned, the org can implicitly accept the EULA on behalf of the user. But that whole conversation might involve lawyers, so who knows if that will be possible.

Can I bypass the “personal vs. work/school question”?

Yes, just use Windows 11 Enterprise instead of Windows 11 Pro, since Enterprise doesn’t ask that question. Of course OEMs don’t ship devices with Windows 11 Enterprise preinstalled, so you’d have to pay them to preload a custom Windows 11 Enterprise image.

But if you’re using Windows 11 Pro, the answer here is the same as the previous question: Not now, maybe in the future with the tenant binding feature that isn’t yet available.

Can I suppress the Security/Private settings page?

This one strikes me as odd, because I expect this to be a very common organization ask — they want to control the settings, not have the end user do it. (Sure, most end users will just click “Next” three times to get the screen to go away, but orgs may not like the defaults.) There’s no technical reason why this wouldn’t be possible, since this occurs after the user signs into AAD and the whole APv2 process is completed. But I see no way to make this happen today. You could certainly push out a configuration profile that changes these settings, but what happens if those settings are applied before OOBE completes? Will OOBE overwrite them? No idea, something to try at a later time.

Can I control the update installation process?

If you saw my previous post, I mentioned that there was a new OOBE page that installed “feature and quality updates” at the end of OOBE, and then rebooted the computer. It turns out that only showed up with Windows 11 24H2 build 26100 (the Insider release preview/RTM release), not with previous releases.

Weirdly, that is no longer showing up for me today. I don’t know if that means it was turned off, or if it thinks my machine (which I keep rolling back to a non-patched checkpoint) is already patched. Either way, I can’t see it anymore.

I would expect Windows Update for Business and/or Autopatch settings to be able to configure that (e.g. to prevent feature updates from downloading and installing), although I don’t see any new documented settings in the 24H2 ADMX files or in the MDM CSP documentation. So we may have to wait to find out what’s going to happen here.

Do the APv2 percentages mean anything?

People have noticed the new APv2 status page (I’ll still call it the ESP page, even though nothing in the APv2 docs refers to it that way) counts up: 0, 1, 2, 3, 4, 5, 6, 100. So what’s going on with that? The best I can tell, the initial low numbers are meaningful:

• 0: Intune Management Extension (IME) MSI is being downloaded.
• 1: IME is being installed
• 2: IME is initializing and figuring out what apps are needed.
• 3+: Apps are being installed

It’s funny to see the progress, as it goes from 6 to 100 on my tests. Best I can tell, it’s just adding one for each Win32 app it installs; when all those apps are done, it jumps to 100. Gotta love Microsoft progress displays.

Update 2024/06/07 8:08pm: In a more recent attempt, one of my apps hung during installation. In that case, the percentage continued to climb until a timeout occurred. So I didn’t quite get the logic right. Now I’m thinking it’s just showing a percentage of the total available time (e.g. since I specified an hour in the profile, it’s showing a percentage of that hour that has elapsed).

What happened to user ESP with APv2?

Best I can tell, it no longer exists. Generally I would say good riddance, but that’s more from my experiences around HAADJ where it would time out because the signed-in AD user didn’t have an AAD user token available because device registration hadn’t completed before they signed in. But since APv2 is AAD-only, that doesn’t apply here. So my guess is that it just wasn’t used enough for tracking apps or user-targeted policies.

Of course there’s always some possibility that it’s just a work-in-progress and will come back at some point, but since there’s no references in the docs that I can find, I’m guessing that won’t happen.

Can I specify a device naming template with APv2?

No one was ever happy about the naming options available in APv1, because no two customers have the same requirements around computer naming. But there were some options to let you build a name using constant text, serial numbers, and random numbers. That’s not present in the APv2 profile:

Will it come back again? That seems a little awkward, since the computer name is usually set earlier in the process. I’ve seen cases where OOBE asks for the name too, well before the user puts in any credentials. (I’m guessing that happens on Windows 11 Pro but not Windows 11 Enterprise; I never see it on my Enterprise VM.) But it always could be reintroduced somehow, maybe with tenant binding?

Until then, you should be able to use an MDM policy to rename the computer using the ComputerName setting in the Accounts CSP, which doesn’t appear to be available in the Intune settings catalog (so it would take a custom OMA-URI). But that’s probably going to cause the computer to reboot if that’s received during OOBE. At least with AAD-joined devices, the name doesn’t really matter that much — yes, Intune and AAD both pick up the value (eventually), but it’s just another attribute of the device, unlike with AD where the object needs to be renamed in the directory. Given that and this reboot behavior, the easiest way is probably to just run a PowerShell script and rename it yourself, and accept the fact that the “real” name will occur with the next reboot (which won’t take too long due to updates being needed).

Can I still use group tags with APv2?

This one caused me to chuckle. Short answer: no. But why would you really need to? You create an Autopilot device preparation policy that targets users; it is linked to an AAD device group that the device will be put into when it is deployed, so you just need to target everything to that device group. There’s no more need for group tags, dynamic groups, or anything like that.

However, that’s not to say that there aren’t challenges that you may need to overcome. For example, if you had a single Autopilot profile and then used group tags to create multiple groups that targeted different apps and/or settings to devices based on that group tag, you’re going to have issues. Sure, you could create multiple Autopilot device preparation policies (APv2) that target different user groups, each with its own targeted apps and policies linked to the device groups specified in each policy, but that basically means you can only choose based on the user, not based on the device.

What happens if I reset or reimage a device and the new user has a different targeted APv2 profile?

An interesting question. Let’s assume you went through the process as UserA, which caused the device to be put into DeviceGroupA and that has AppA targeted to it. Now, you reset the device and give it to UserB, who has a different APv2 profile that is linked to DeviceGroupB and AppB. Is the device now in both DeviceGroupA and DeviceGroupB, so it gets both apps?

Someone try that out and let me know 🙂

What’s the story with DFCI and APv2?

If you aren’t familiar with DFCI, it’s a firmware management feature that works with only Surface devices. (Other OEMs could have implemented it, but as far as I know, none ever did.) For “security reasons” (i.e. you don’t want someone to be able to brick all of your devices through a simple command that sets a BIOS password on them), this only works with devices that were registered via the OEM or partner; it doesn’t work with devices that the customer registers themselves. (The customer themselves isn’t even trustworthy enough.)

So what happens in APv2 when you aren’t doing hardware hash device registration any more? A good question, and as far as I know it hasn’t been addressed by Microsoft yet. My stab-in-the-dark guess is that DFCI will remain an APv1 feature and won’t be brought forward to APv2.

Will APv2 replace APv1?

My initial thought was that of course APv2 will replace APv1, but the APv2 FAQ explicitly stated that there will still be investments in v1:

Does this mean that Windows Autopilot isn’t being invested in any longer?

Not at all! We’re continuing to work on Windows Autopilot in parallel with developing Windows Autopilot device preparation. The first release of Windows Autopilot device preparation doesn’t have all the scenarios of Windows Autopilot, specifically pre-provisioning and self-deploying modes, so we’ll continue to invest in those areas. Additionally, in the future, we plan to add any high value features from Windows Autopilot device preparation to Windows Autopilot to improve the experience for all customers.

But the previous FAQ item right before that makes me question that some:

Do existing Windows Autopilot profiles need to be migrated to Windows Autopilot device preparation?

There’s no need to migrate from existing Windows Autopilot profiles to Windows Autopilot device preparation policies. We expect both solutions to exist in parallel for a while as we work to improve the experience and add more functionality.

Is that a slip of the tongue? How long is “for a while”? My guess is that eventually APv2 does replace APv1, but we’re probably talking years.

Related to this, if you are Microsoft and you expect to phase out APv1 at some point, you would likely have little incentive to backport changes from APv2 to APv1, unless you are addressing strong customer feedback — there’s a lot of risk in replacing what’s already in use, compared to adding a new scenario alongside an existing one. Maybe it will happen, maybe not. (I have a small wager riding on this one.)

How do I deal with blank or duplicate serial numbers and corporate device IDs?

Some background information first: When you enroll a device via APv2, it initially enrolls as a personal device; it flips to a corporate device after the enrollment. So if you don’t have personal device enrollments enabled for Windows devices, you aren’t going to get very far.

The (possibly?) short-term solution to this is to use corporate device identifiers. With those, you can upload the device details (manufacturer, model, and serial number) so that Intune recognizes at enrollment time that the device is a corporate device. Ironic, going from a device registration model (APv1, hardware hashes) to a different device registration model (APv2, corporate device identifiers).

I say “possibly” a short-term solution because this seems to go against the flow of APv2. Perhaps some scenarios would work fine with tenant binding (e.g. any user-driven scenario), but maybe self-deploying and pre-provisioning won’t? We’ll have to wait and see for that one.

If APv2 doesn’t track policies, will kiosks work?

This is another interesting scenario: If you have a kiosk device that doesn’t have any apps, e.g. you’re just using Edge and configuring it to run full-screen to display a particular web page, there are a set of policies that need to be delivered to the device before a user signs on. If Autopilot v2 doesn’t track policies, how does it know when it is safe for the user to sign in?

Typically, this is combined with self-deploying mode, so in the short term this is just a hypothetical scenario. If you are using self-deploying mode, you’ll just continue with APv1 for now. Presumably this will be addressed with a future self-deploying implementation.

What about Windows Hello for Business policies and APv2?

This is similar to the previous question, but also requires a little more context. There are two ways you can configure Windows Hello for Business policies:

• At the tenant level. If you do this, the settings are provided in the initial enrollment payload so that they take effect even if the user were to immediately log into the device (e.g. no Autopilot at all). So there’s never any issue here, those enrollment-level settings will always be there before the user signs in.
• Via a device-targeted configuration profile. You could create a configuration profile that configures WHfB for a certain group and target a device with those. This will typically work because there’s nearly always a long enough delay to ensure that the policy is applied before the user is (automatically) signed in.
• Via a user-targeted configuration profile. Uh oh, this one is likely going to be an issue: Since there is no user ESP, the odds of the policy begin applied in a very small window between when the user signs in and when the shell checks to see if it needs to do WHfB enrollment for the user is, not surprisingly, also very small.

So I guess don’t use user-targeted WHfB policies?

What happened to the Autopilot diagnostics feature (Ctrl-Shift-D) in APv2?

If you aren’t familiar with the Autopilot diagnostics page, it was designed as a way to see more detailed information about an Autopilot deployment than what you could see in ESP natively. It’s a level of detail that the end user doesn’t care about, but IT admins who want to know more about what is going on, or even more importantly, what failed, you want as much detail as possible. So, this Ctrl-Shift-D feature was added. But I’m not sure it really lived up to its potential — I still find that the Get-AutopilotDiagnostics script (and the Get-AutopilotDiagnosticsCommunity forked version) is more useful. (Since I wrote that script, I am biased though.)

With APv2, that Ctrl-Shift-D function no longer exists. Will something like it come back in the future? Hard to say for sure, but my guess is no, you’ll need to do remote troubleshooting using the Autopilot device preparation deployment monitoring report. (Better hope the failures are post-enrollment.)

And what about the Get-AutopilotDiagnosticsCommunity script? I’ve been looking into that some. It certainly does not work with APv2 today, but it may be possible to make some changes to it to get it to work. There are enough changes in the Autopilot v2 ESP process that is making that challenging. But I haven’t given up yet.

Will Hybrid AADJ ever be supported in APv2?

It’s pretty safe to say “absolutely, positively no chance in hell.” The FAQ explicitly states that (well, not using those words), and there’s pretty much a 0% chance that ever changes. So, you’re going to have to stick with APv1 for that.

Why is there a limit of tracked apps 10 apps in APv2?

Again from the FAQ: “…to increase stability and achieve a higher success rate. Looking at our telemetry, almost 90% of all Autopilot deployments are deployed with 10 or less fewer apps.” So if you’re in that 10%, you’re doing it wrong 🙂

I assume you could work around that by using dependency chains, since the chained apps won’t count against the limit of apps that you can specify in the APv2 profile.

Can we control the order of app installation in APv2?

You can at least now mix MSIs, Office/M365 Apps, Win32 apps, and store apps together, as per the FAQ, so there’s no more “thou shall not use MSIs” directive. But there’s still no control over the order of app installation, at least not without using dependency chains as you could with APv1.

Can I use tenant lock with APv2?

Tenant lock with APv1 was a combination of two things: A policy that says to “Hide account change options” combined with another setting that “Require network in OOBE.” These were a bit tricky to use though: “Hide account change options” is in the Autopilot v1 profile, but only applies when you have a network connection to receive that profile, and “Require network in OOBE’ can only be pushed out as an MDM policy after the device enrolls in OOBE. Chicken-and-egg problem.

So effectively, this setup was primarily useful in pre-provisioning scenarios where the IT technician ensures that both of those policies are applied before the device gets to the end user. (Technically, you could have the OEM configure the “network required” one by setting a UEFI variable, but I doubt many people bother with that.)

So how would this work with APv2? Well, the “network required’ piece may still apply — while Pro requires a network connection, I don’t believe Enterprise does. And the “hide change” option is still post-enrollment. So you’re either needing a new pre-provisioning scenario, or a feature that is linked with tenant binding.

We don’t yet know how tenant binding will work, or what capabilities it will have, or whether it is considered a security feature (can’t be bypassed) or a convenience feature (e.g. flip a registry key or UEFI variable), so we’ll have to stay tuned on that one.

Is there a way to get the device enrollments report to not display times in GMT?

Hah, I didn’t even notice this one. I’m guessing the answer is no.