Cannot Reseal Windows 11 device while pre-provisioning

Iron Contributor

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)


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!







63 Replies
Sounds like a WUfB targetted at a device group and running windows 11 autopilot for pre-provisioned deployments... ow wait ... you are doing exactly that (except the wufb ring that I am note sure of :P.. but than again who isn't using wufb)

If so... feel free to read this blog of mine

Hi @Rudy_Ooms_MVP, Yes, I'm using WUfB but I do target user groups. I have 3 rings configured. Ring 3 is targeting all users and I excluded users from ring 1 and ring 2. The servicing channel is GAC. the only difference in rings is the deferral period.




The ESP is configured like below and targeting a device group:



I did have a look at the event logs and searched for CloudExperienceHostBroker like you mention in your blog.  You did some great troubleshooting there! There are also some other events that caught my attention but I still have to look at other logs just to satisfy my curiosity.


Guess I'll have to dig in a little deeper and see if I can solve this like you did in your blog, assuming WufB is the root cause. Event reasons like update/upgrade do make you wonder. Although I thought I was on the latest build before starting pre-provisioning. I'll doublecheck that too.


I re-enrolled the devices without pre-provisioning because that worked before, and after deleting the device record in MEM, I was able to reset the device and enroll again without pre-provisioning. So I'll have to make some config changes in my test tenant and see what works.


Thx again Rudy! I'll try to get back asap ;)




LoL..Everybody knows what opnieuw opstarten means right? ;) 


Event 1:

The process C:\Windows\system32\winlogon.exe (DESKTOP-HTHM3BU) has initiated the uitschakelen of computer DESKTOP-HTHM3BU on behalf of user NT AUTHORITY\SYSTEM for the following reason: Er is geen titel voor deze reden gevonden (=there is no title for this event)
Reason Code: 0x500ff
Shutdown Type: uitschakelen (=shutdown)


Event 2:

The process C:\Windows\system32\winlogon.exe (MINWINPC) has initiated the opnieuw opstarten of computer WIN-T70I1KVU8HQ on behalf of user NT AUTHORITY\SYSTEM for the following reason: Besturingssysteem: upgrade (gepland)
Reason Code: 0x80020003
Shutdown Type: opnieuw opstarten (=reboot)


Event 3:

The process C:\Windows\System32\CloudExperienceHostBroker.exe (WIN-T70I1KVU8HQ) has initiated the opnieuw opstarten of computer DESKTOP-HTHM3BU on behalf of user NT AUTHORITY\SYSTEM for the following reason: Besturingssysteem: nieuwe configuratie (niet gepland)
Reason Code: 0x20004
Shutdown Type: opnieuw opstarten (=reboot)


Event 4:
The server could not bind to the transport \Device\NetBT_Tcpip_{} because another computer on the network has the same name. The server could not start.

Hi.. I know what it means :p
Did you also searched in the DeviceManagement-Enterprise-Diagnostics provider for event 2800
as mentioned in the blog... so you know what caused that reboot.... because somehow it reboots (that's normal) but at that time it didn't finished the device phase successful.

Hi Rudy, First I looked at the Shell-core event log:


Shell-core event log: Filtered for Event 62407 . There are many events that have something to do with CloudExperienceHost. and the one you mention is also there:

CloudExperienceHost Web App Event 2. Name: 'CommercialOOBE_ESP_Subcategory_RebootRequiredBySubcategory_DeviceSetup.RebootCoalescing', Value: '{"message":"BootstrapStatus: Reboot required by subcategory DeviceSetup.RebootCoalescing.","errorCode":0}'.


Then I searched for 2800 in the devicemanagement-enterprise-diagnostics-provider-admin event log.
that gave me the following reboot trigger:

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


That was the only event I could find with a search for reboot. Google returned nada. But I did check out the CSP: and I'm trying to figure out the logics here.. :D


I'll update again when I know more ;)


Ahhh DMA Guard.... are you pushing some VB security stuff (wdac/mdac stuff?)

LoL, I was thinking the same thing and checked the MDE security baseline.


Who said troubleshooting is boring? :D 

As far as I know, there shouldn't be any other policies but I'll check those too.


@Oktay Sari 


Haha.. those 2 will/could trigger an unexpected reboot


Wondering what happens when you change that settings/remove that dmaguard setting



Yeahh, Thx @Rudy_Ooms_MVP, I'm gonna change the security baselines and try to pre-provision a device to see what happens. The SBs are targeting a device group, so that could be the issue here too. Not sure if I can manage to test today, but I'll let you know.  

Hi... cant wait to hear!! please let me now the outcome.. also wondering what happens when you remove that reboot uri as i did :p
Hi @Rudy_Ooms_MVP , sorry for the delay.. other obligations ;) I'm gonna test this later today and let you know what the outcome is.

Hi @Rudy_Ooms_MVP,

Frustrating thing happened. I had to delete and start over with the test device and then got myself a nice “Something went wrong” error. No organization found/No profile found.


Not sure if I want to laugh or try and see if this device survives a (very hard and high) drop test. It is almost the exact same behavior you've  blogged about . The difference is that I can delete the device all I want, do a new AP hash import/registration, wipe/re-install.. It will not enroll.


Tried again and it's not enrolling with pre-provisioning and also not with a normal AP enrollment. It seems I'm left with a device that is not capable of enrolling with AP. At least not with Windows 11.


I'm going to re-install this same device with Window 10 and see if that works, but I'm going to leave it for a couple of days and focus on other things so I can shake this off a bit. 


I'll post an update here once I've tested this thing again. For now, Thx for stepping in!




Mmmm... sounds like a coincidence ...Because last week I was also looking at some logs from someone who was experiencing the same kind of behavior (suddenly) as if the device didn't recognize the autopilot profile..... wondering what happens with window 10


If you have some experience with Fiddler.. try to determine what happens at that point (just as I did in that blog, which got me that hardwaremismatch error)


Just experienced the exact same thing again... on the device I am always using


Rudy Ooms | MVP :netherlands: on Twitter: "This is kind off funny… Same test device i am always usin...

Same thing here, or maybe that’s me :)

@Rudy_Ooms_MVP , @Bruce S So now I have 2 devices to test with. 1 device that is just not able to download a profile what so ever (Windows 11) and another device, that will download a profile but the reseal option is not shown. That is how this threat started. Here's one final update:


The device that could not reseal: 

First I tried to set the DMA and credential guard settings in the MDE security baseline to Not Configured on at a time and re-enrolled using pre-provisioning. That did not work. the Reseal option was still not showing. I ended up at the login screen like before. Strange enough though, when I reset the device from Intune, it would end up in the user  flow like it would, after resealing. 


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:


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


I'm somewhat disappointed that pre-provisioning is not working out of the box with Windows 11 and hope this will be fixed sometime soon.


Then for the device that can't find/load a profile:

@Rudy_Ooms_MVP I did a fiddler trace and that one gave me a nice 807 - ZtdDeviceIsNotRegistered

The error description: The device being deleted or configured does not exist in the service.



@Michael Niehaus has a nice table on his blog explaining what might be the cause:  This would typically only happen if Intune and the Windows Autopilot deployment service are out of sync (e.g. you removed a device from Microsoft Store for Business, and then tried to remove it via Intune before Intune had noticed it disappeared).


Off-course I checked the store, made sure all is in-sync, waited a long long time, deleted every trace I could find for this device, re-installed windows 10, and still no luck here. It really seems like this device is no longer able to pre-provision.


So I'm trying to enroll the device without pre-provisioning and then I see a nice "How would you like to set up?" question.. LoL @Rudy_Ooms_MVP I ended up at your blog again. 


Up until now, I uploaded the hash using PowerShell -online from the OOBE. so I decided to give it one last try and upload the CSV manually. Still no luck... I did manage to collect the logs from the device again and will try to dive in again, but for today, I'm feeling beet-up by Autopilot :D  

@Oktay Sari 


thats some nice troubleshooting… glad to hear you have 1 working device even when its not working out of the box :)…. 

wondering if its possible for you to run these scripts on that device rhat refuses to download the profile?. Nice error btw you seen woth fiddler

wget -outfile Intune.xml
wget -outfile IntuneODCStandAlone.ps1
powerShell -ExecutionPolicy Bypass -File .\IntuneODCStandAlone.ps1
love to see them :)

Thx for diving in @Rudy_Ooms_MVP, Much appreciated! I'll send you a DM with the info ;)

opened a case with Microsoft. Hope to hear something and if I do, I'll give another update ;)
I am hoping the same thing.... and especially what could be causing this...

@Rudy_Ooms_MVP Here's a quick update on the device that does not download the AP profile:


  • I deleted the AP device from tenant A (where it will not download AP profile)
  • I did NOT reset the device
  • I imported the same device in tenant B
  • assigned a new AP profile to the device in tenant B
  • checked Azure AD device record in in tenant B
  • tried enrolling the device in tenant B and what do you think? It works!
The device enrolled in tenant B without any issues and is able to download the assigned AP profile. For now, it looks like it's an issue with a single device in one tenant. When enrolling with another tenant, everything works just fine and the device can download the AP profile.
Still working with MS on this one so I'll give an update when there's something to share.