Cannot Reseal Windows 11 device while pre-provisioning

[Oktay Sari]

Before I reinvent the wheel, I thought I’ll post the issue here. I have a AP profile configured as below.

Deployment mode                               User-Driven

Join to Azure AD as                              Azure AD joined

Language (Region)                               Dutch (Netherlands)

Automatically configure keyboard   Yes ( In know.. please read on)

Microsoft Software License Terms        Hide

Privacy settings                                     Hide

Hide change account options               Hide

User account type                                 Standard

Allow pre-provisioned deployment  Yes

Apply device name template                Yes

Enter a name                                         XXXX-%SERIAL%

I know I’ve set the auto keyboard to yes, but here me out. As far as I understood the previously known issue is fixed in Windows 11. Windows Autopilot for pre-provisioned deployment | Microsoft Docs

In Windows 10, version 2004 and later, if the Autopilot deployment profile Language/Region setting is not set to User Select, then OOBE will progress past the language/region/keyboard selection screens. This causes the pre-provisioning technician to arrive at the Azure AD login page, which is too late to enter pre-provisioning. This issue is fixed in Windows 11.

For the pre-provisioning part:

On Windows 10 21H2 (10.0.19044.1645) I can pre-provision the device successfully. The technician flow completes and I have a green screen giving me the option to reseal. After reboot, the normal user flow follows, and the device is ready to go before you know. AAD joined and MDM enrolled with user affinity.

However, on Windows 11 (10.0.22000.675) the technician flow starts OK. I’m presented with the AP profile that is selected, and I can continue pre-provisioning. But it never shows me the green screen and I’m not able to reseal the device. It also does not show any errors what so ever during pre-provisioning. The device simply reboots and ends up at the login screen. The user flow does not seem to start and from the login screen, I’m also not able to sign-in with any account.

At this stage, I checked the device in the AP portal. The interesting thing is, that the device seems to be AAD joined and MDM enrolled. And as expected, there is no primary user yet in Intune.

So I looked up the device in Azure AD and confirmed it is AAD joined. Although I don’t believe the info presented. I also looked up the device in MEM/Intune and collected the diagnostics logs from the device.

Still in the process of diving into the logfiles but here are some of my findings:

intunemanagementextension.log shows some interesting things:

• GetAADJoinInfo - Failed to get Azure AD Join information using NetGetAadJoinInformation
• ![LOG[AAD User check using device check in app is failed, now fallback to the Graph audience. ex = Intune Management Extension Error.Exception: Microsoft.Management.Services.IntuneWindowsAgent.AgentCommon.TokenAquireException: Attempt to get token, but failed.

The User Device Registration event log is playing tricks on me. Here are some of the events from the log

• The get jAccount S-1-12-1-xxx-xxx was added to group Administrators.oin response operation callback was successful.
• The post join tasks for the AAD Authentication Package completed successfully.
• The registration status has been successfully flushed to disk.
  • Join type: 11 (DEVICE_AUTO_DDID)
• The complete join response operation was successful.
• The task \Microsoft\Windows\Workplace Join\Device-Sync was successfully enabled.
• The initialization of the join request was successful. Inputs:
  •  JoinRequest: 8 (DEVICE_UNJOIN)
•             Domain:xxx.onmicrosoft.com

If I had to guess, I’d say the device is AAD joined and MDM enrolled at first, but for some reason, it unjoins the device in AAD which explains the fact that I cannot sign-in with a AAD User account. The device however remains MDM enrolled.

What is going on here?

I will test the same setup with auto configure keyboards set to No and see what happens. But the fact that I can get to the pre-provisioning screen, see the selected AP profile and reseal the device with W10 tells me (or at least it looks like) this should work. 

Anyone else having the same experience with Windows 11?

Hope this makes some sense. Thx in advance!

Oktay

[#2]

@Oktay Sari 

I had the exact same issue.

Deployments work fine with Windows 10.

With Windows 11 I didn't get the Reseal option.

At the end I removed all assignments which I had from "All devices" to a dynamic group with all autopilot devices. So I still manage to apply the security baselines and Windows update ring profile to a device group, just not "All devices".

I also did this with applications and scripts, but I guess that is not needed. Just the options which can cause a reboot. I guess all the policies related to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\SyncML\RebootRequiredURIs

Please can you try to do the same to see if you can reproduce this?

I also read another blog that someone tested the Pre Provisioning issue on the latest Windows 11 preview build and it seems the issue has been solved in that build.

See chapter 7 of this blog:

Windows 11, WUfB and the Autopilot pre-provisoning issue (call4cloud.nl)

Hope this helps

[#3]

Hi @RonaldBe21, the blog you're mentioning is @Rudy_Ooms_MVP blog. We've been in contact about this strange behavior and in one of my earlier replies I gave an update on the Windows 11 device that did not give the reseal option:

The device that could not reseal: 

I ended up with removing every policy assignment I had except for the update rings targeting users and still no reseal option. Then I deleted the following registry key:

HKLM:\SOFTWARE\Microsoft\Provisioning\SyncML\RebootRequiredURIs\ManagePreviewBuild

started pre-provisioning again, and yes! A nice reseal button!

I didn't have this issue (not resealing) with Windows 10. Later on, I tested with a couple of default policy sets like security baselines, Bitlocker, firewall, MDE, etc. All targeting device groups. I deploy update rings to user groups. But even then, the behavior was the same. No issues with Windows 10 pre-provisioning, while Windows 11 won't give the option to reseal. I'm testing a bit more, and will then contact support with all info I have. But deleting the above reg key, helped.

I'm seeing stranger thing too, In some cases, the device would reboot and not give the reseal option, then end up at the logon screen the first boot. But strange enough, after a second boot, the  user flow seems to start, like I did reseal the device. And again, all on Windows 11.

[#4]

@Oktay Sari 

We are experiencing the same issue as described above.
The configuration that is giving errors is as following:

Windows 11 (build: 10.0.22000.795)
Autopilot pre-provisioning

When we apply the security baseline, we are getting the exact same reboot issue. Device is Intune manged and AAD joined after the reboot, only it is just showing the local login screen. A second reboot after the device gets the unexpected reboot never works.

In the IME log first we see the reboot trigger caused bij the CloudExperienceHostBroker.exe:

[datasensor] skipping boot event before first enrollment, bootid = 3-8-2022 08:44:00, CoreBootTimeInMilliseconds = 9290, GPTimeInMilliseconds = 0, TotalBootTimeInMilliseconds = 9290, UpdateTimeInMilliseconds = 0, EventDataXml = <BootReason><EventData xmlns="http://schemas.microsoft.com/win/2004/08/events/event" SystemPowerOffTime="2022-08-03T08:43:42.3470465Z">
  <Data Name="param1">C:\Windows\System32\CloudExperienceHostBroker.exe (PP5CD20337HS)</Data>
  <Data Name="param2">PP5CD20337HS</Data>
  <Data Name="param3">Besturingssysteem: nieuwe configuratie (niet gepland)</Data>
  <Data Name="param4">0x20004</Data>
  <Data Name="param5">opnieuw opstarten</Data>
  <Data Name="param6"></Data>
  <Data Name="param7">NT AUTHORITY\SYSTEM</Data>
</EventData>
<CustomData>
  <FullPath>C:\Windows\System32\CloudExperienceHostBroker.exe</FullPath>
</CustomData></BootReason>, BootReason = 1074, BootDiskMediaType = 4

In the shell-core-operational eventlog I subfrequently seeing the reboot required from DeviceSetup.RebootCoalescing.

CloudExperienceHost Web App Event 2. Name: ‘CommercialOOBE_BootstrapStatusCategory_RebootCoalescing_Initiated’, Value: ‘{"message":"BootstrapStatus: Non-parallelizable batch of 1 subcategories requires a reboot.","errorCode":0}’.

And last but not least in the DeviceManagement-Enterprise-Diagnostics eventlog we are seeing the DmaGuard URI is the cause of the reboot that has been triggered.

The following URI has triggered a reboot: (./Device/Vendor/MSFT/Policy/Config/DmaGuard/DeviceEnumerationPolicy).

Also, the deletion of the HKLM:\SOFTWARE\Microsoft\Provisioning\SyncML\RebootRequiredURIs\ManagePreviewBuild regkey doesn't always work (sometimes is does).

Next thing I''m going to try if it all works with the Windows 11 Insider preview build, just like @Rudy_Ooms_MVP is mentioning in his blog.

Anyone knows if there is already any news from Microsoft about this particular problem?

[#5]

As the /DeviceEnumerationPolicy is one of the rebootrequired uris that's the one that will trigger the reboot.. that's for sure.. so what happens when you "remove" that one from the HKLM:\SOFTWARE\Microsoft\Provisioning\SyncML\RebootRequiredURIs\

[#6]

Did some testing on the following OS versions:

Windows 11 (build: 10.0.22000.795)
Windows 11 (build: 10.0.22000.832)

All the devices (2 different types from HP, 7 in total), went to the pre-provisioning fase successfully when I delete the ./Device/Vendor/MSFT/Policy/Config/DmaGuard/DeviceEnumerationPolicy key.

I don't have to delete the ManagedPreviewBuild key...

On 1 device I installed the Windows 11 Insider Preview Build 22621, that one didn't came through the pre-provisioning fase, I failed on another part, didn't got time to troubleshoot this.

So, it looks I have a workaround to delete the "DeviceEnumerationPolicy" regkey before pre-provisioning, and I could remove it from the WIM file before I roll out the OS via MDT.

But I'm wondering if Microsoft is already aware of the conflicts between the RebootRequired regkeys and using Security Baselines with Pre-Provisioning.

[#7]

“They “ are aware as those keys are definied in the reboot required section :).

Using security baselines is great, but in my humble opinion split them up with your own policies… so you know what you are configuring on thise devices…

Enabling virtual based securitu with the sec baselines is almost 99% an issue with prepro..

But it also depends on the windows build as the wufb managebuild i mentioned was fixed and with win11 it was introduced again :)

[#8]

Hello all,

last week I have opened a premier case at Microsoft. They engineer who is helping me could directly tell me that this is a know bug in Windows 11. He is also aware about a possible fix in the latest Windows 11 insider build and is trying to get a possible ETA for the fix so we will know when the issue is going te be resolved. As soon as I have a confirmation about the ETA, I will post it here.

[#9]

Hi,
Could you share the information about which bug exactly? to be sure we are talking about the same issue :)

[#10]

The bug is related to Windows 11 en Pre-provisioning and that the reseal button will not appear.

[#11]

Thanks for the info Ronald, hoping Microsoft will provide a ETA for releasing the fix asap.

[#12]

We're affected too.
Is it really a general bug in Win 11? Or has it to do with config policies/baselines?

[#13]

For me it is a security baseline conflict with Autopilot pre-provisioning, DMA-Guard specifically.

[#14]

The cause of this issue is not very clear te me. At one customer I had this issue and changed all the assignments (including security baselines and update ring policy) from "all devices" to a device group instead. But this didn't work when I tested at another customer. 

One test I did there is to remove all the configuration profiles en security baselines, including the update ring policy. So nothing was applied to the device but still I did not get the reseal button. 

On other forums I also see that people are having different results. Maybe this could be when testing with different update levels of Windows, I am not sure.

So the only thing I can be sure of is that Microsoft told me it is a know bug and they are working on it. I can not get with 100% certainty a configuration which will always work. Microsoft also told me that they cannot provide me with a workarround, because they just don't have one. 

They also told me that removing the mentioned register key(s) also do not work (always) as expected so that is also not a good workarround.

I guess we can only wait to make sure that the issue is resolved by Microsoft. I will not advice to use Pre-Provisioning with Windows 11 for now, because I cannot find a working (workarround) solution which I am sure it will keep working and not have to worry that it stops working with different conditions.

I also tested with a colleague and we did have just good results with the latest insider build of Windows 11. Not something to use in a production environment for our customers, but at least we have good fate that Microsoft will be able to help us soon.

As mentioned before, as soon as I get a confirmed ETA for the fix from Microsoft, I will let you all know. 

[#15]

Most of the times you could resolve this issue by changing the assignment to users instead of devices.. just the same as with WUFB targetted at devices... it caused a reboot back in the win 11 days that would give you a nice login screen with no ability to login ;)...

The same goes for device config profiles that could trigger such weird behavior..,.

[#16]

Having the same issue with Windows 11 (Currently using latest Windows 11 release 21h2.9) Windows 10 on same device gets to reseal screen. I have tried all options mentioned except for key delete. ./Device/Vendor/MSFT/Policy/Config/DmaGuard/DeviceEnumerationPolicy . I will test that shortly. I do have an open ticket with MS Support, still waiting on them to offer some suggestion. Really dont want to have to go back to deploying Windows 10.

[#17]

And when assinging that config to users instead of devices?

[#18]

I have not tried that as this is testing on production environment. Changing wufb to "all Users" is probably not a good idea. I will test it on my test lab when I have a chance - was hoping that Microsoft would provide a "fix" before I got to that

[#19]

Hehe i am not saying “all users” just a test group with your test user in it :)… if you know what is causing it, the informstion you could share with ms is better

[#20]

Msft has to solve the issue. Not we as Customers. 🫤

[#21]

Nope we dont, but it helps to give them as much information as possible…