Don’t Be a Menace to Autopilot While configuring Your WUfB in the Hood

This blog will be about the famous reboots you could encounter when using Autopilot. In this blog, I am going to show you what would happen when you target a WUfB to a device group and try to enroll a Windows 11 device with Autopilot for pre-provisioned deployments.

Of course, I will also show you how to fix it on your own until Microsoft comes up with a solution!

I will divide this blog into multiple parts

  1. The Issue
  2. Troubleshooting
  3. The Fix
  4. How to NOT Implement the Fix
  5. How to Implement the Fix Option 1
  6. How to Implement the Fix Option 2
  7. Windows 11 Insider Previews
  8. Conclusion

1. The Issue

To get a better understanding of what is happening I decided to record it.

Please Note: I ordered an Elgato HD60 S to make sure the next recording would be a little bit better

When taking a good look at what’s happening in the youtube video you will have noticed that we are enrolling a Windows 11 with Autopilot for pre-provisioned deployments. After the ESP device phase finished installing the required apps Windows suddenly rebooted! Which normally shouldn’t be an issue if it continues the ESP!.

While the ESP was busy installing the apps, I made sure we were aware of the time frame. After the unexpected reboot, I logged in with my local admin account which was created during Autopilot to check out the System event logs and the Intune Management Extension log first.

Graphical user interface, text, application

Description automatically generated

As shown above (picture is clickable), when looking at the system event log first, you will notice the CloudExperienceHostBroker.exe triggered the reboot (0x20004). It’s always about the CloudExperienceHost I guess!

We could also open the Intune Management Extension log to find out if this error is also logged inside the IME log. As shown below, again the same error 0x20004 code we also noticed in the system event log. Sorry for the dutch words… but I guess you know what “Opnieuw Opstarten” means.

Text, letter

Description automatically generated

Now we have taken a look at the IME and system log, let’s check out some other event logs. When you are stumbling upon these kinds of CloudExperienceHost errors, the Shell-Core event log is always the place to start digging!


Description automatically generated with medium confidence

As shown above, this event log is telling us that the CommercialOOBE_ESP requires a reboot by the subcategory DeviceSetup.RebootCoalescing, ErrorCode 0.

Okay, so we now know that the CloudExperienceHost is responsible for the “reboot” but we are still not sure what could be triggering it. Let’s start some troubleshooting!

2. Troubleshooting

So I decided to perform another Autopilot enrollment to hopefully spot something more useful. This time I decide to monitor the DeviceManagement-Enterprise-Diagnostics provider for event 2800.

As shown below even while the device was still busy installing the apps the URI ./device/vendor/MSFT/Policy/Config/Update/ManagePreviewBuilds already triggered a reboot?

Graphical user interface, text, application

Description automatically generated

But looking at the Timestamp, the device was still busy installing apps… and it didn’t reboot at that point… Almost if it “scheduled” the necessary reboot after it would finish the device phase

That’s kinda weird, so I decided to take another look at the DeviceManagement event log

Again the same RebootRequired and RebootCoalescing notification we got earlier. Coalescing….that’s a nice word? I am dutch, so I needed to translate it

To blend or come together: Okay… good to know that it was a combined reboot but I am also pretty sure I have read that specific word, somewhere else! After some searching, I stumbled upon this sentence.

“There will be a coalesced reboot at the end of the device setup phase of ESP, and the computer will have its new name after that reboot before they sign-in”

Of course…. Michael Niehaus Renaming Autopilot-deployed Hybrid Azure AD Join devices – Out of Office Hours (

Okay, when NOT using Autopilot for pre-provisioning deployments, I am fine with it but this time I am not. I guess this reboot isn’t because of the computer name change but more about the Update/ManagePreviewBuilds RebootRequiredURI

I decided to check out the WUfB deployment rings because it was mentioning the Update URI. As shown below…

Graphical user interface

Description automatically generated with medium confidence

Description automatically generated with low confidence

At first sight, it looks like there is nothing wrong with it as it is using the servicing channel: Retail Channel, and NOT the pre-release build:

I was expecting the Windows Insider setting to be configured like this!

Luckily it wasn’t! But then again, when enrolling Windows 10 with Autopilot the unexpected reboot didn’t occur! That’s odd! Maybe a combination? I know at first hand that device targeted Win32 Apps also could trigger a suppressed reboot at the end of the device setup because of a possible soft reboot return code it could receive.

So to be 100% sure it wasn’t the Win32Apps or the MS 365 Apps I decided to remove them all from the required apps during ESP and also removed all of the assignments so only the Company Portal Online (USER targeted) was left

Graphical user interface, text, application, chat or text message, email

Description automatically generated

After trying to reenroll the Windows 11 device again with Autopilot and still experiencing the same reboot we can be pretty sure the Win32 apps are NOT triggering it 😊 I guess we need to start taking another look at the WUfB ring!

Just like the Online version of the Company Portal we are using, I decided to do the same for the WUfB ring. Target at users not at devices!

Graphical user interface, text, application

Description automatically generated

As shown above, I decided to remove the “All devices” from the assignment and added the “All Users” instead.

Please Note: This WUfB example above, is definitely not the way to configure WUfB! But as it was my own demo/test tenant, all users were fine with me

After another Autopilot enrollment, I was amazed to see Autopilot ending up at its “sealing” screen instead of rebooting and ending up with a local login prompt. That’s weird! So changing the WUfB assignment to users will fix the Windows 11 reboot issue!

3. Fixing it manually?

After changing the assignment we are now 100% sure the unexpected reboot is happening because of the Update/ManagePreviewBuilds RebootRequiredURIs!

Luckily I stumbled upon the needed registry key a while ago while I was writing a blog about the remediation error -201628112?

A picture containing table

Description automatically generated

So I decided to open the registry to check out this key: HKLM:\SOFTWARE\Microsoft\Provisioning\SyncML\RebootRequiredURIs

My first and maybe a very stupid idea was to just remove the ManagePreviewBuild URI from this section.

Graphical user interface, application

Description automatically generated

Trying to delete the registry key just gave me some permissions denied errors. Even the system didn’t have permission to change it! So using psexec wasn’t going to work. The only thing left was changing the ownership, because the “TrustedInstaller” was the only one with enough permissions to remove that registry value.

After removing this registry key manually I reenrolled my Windows 11 device again with Autopilot for pre-provisioned deployments.

AND YES, YES, YES!!! My stupid idea worked! The device didn’t reboot and ended up with a nice Seal screen!

Learning when to say “no” to an idea | by Denise Law | Product and  Engineering at The Economist | Medium

4. How to NOT Implement the Fix

My first idea to fix it, of course, didn’t work. Let me explain what I tried to do. I wrote a PowerShell script and uploaded it to Intune so I can be sure it will be pushed to the device when enrolling the device with Autopilot.

This PowerShell script will create a scheduled task that is going to run as the “NT service\Trusted Installer”. This scheduled task will launch a PowerShell session and will execute the encoded command.

This encoded command is nothing more than just a removal of that specific registry key!

Okay, okay… it was my first idea!!!!... while trying to fix it this way I noticed that running the PowerShell script from Intune gave me some issues, let me explain them!

Issue 1:

I noticed that after I started the Autopilot pre-provisioning, getting that PowerShell script from Intune and automatically executing it was just a little bit too late!. At that point, Windows was already aware of the Requiredreboot URI!!!!!

Issue 2:

Being too late is one but when testing this script I also noticed the idea to create a scheduled task to bypass the “NT service\trusted installer” permission issue is great but it won’t work during OOBE. Because trying to start the scheduled task with Powershell or with schtasks, puts the task in a queued status!.

It will only be executed when manually right-clicking the task in the GUI and pressing “Run”. Please Note: I need to dig into this.. as I don’t understand yet why it doesn’t execute in the OOBE)

5. How to Implement the Fix Option 1

After testing out my first idea, I first changed the PowerShell script a little bit because the idea to run a scheduled task in the OOBE screen wasn’t going to work!

As shown above I decided to take another road to try to fix it. I am making sure I am downloading the Set-ACL.exe from my own website to the programdata folder. With this tool, it’s very easy to change the owner of that registry key. After changing the Owner, I am also making sure the administrators group will have full access to that same key.

After the ownership and permissions are changed, it will delete that specific RebootRequired key if it exists. After deleting the registry key it will restore the ownership.

Please Note: You will NEED to run this script BEFORE starting the pre-provisioning by using Shift-F10(if you are NOT blocking SHIFT+F10)

6. How to Implement the Fix Option 2

Running the PowerShell script to fix it manually, each time a device needs to be provisioned could be easily forgotten. To make sure I wasn’t going to forget to apply this fix each time I decided to alter my install.wim file a little bit.

Some time ago I already wrote a blog about how you could add an additional KB update to your Windows installation medium by using DISM

Why not do the exact same thing? This time we aren’t going to add a KB update to the installation medium but we are making sure that the registry key doesn’t even exist when installing a new device with my Windows 11 installation USB stick!

I plugged in my USB Stick with the Windows 11 installation files on it and made sure I created a temporary folder (mountnew) on my hard drive.

Let’s mount the Install.wim file from the USB Stick (D:) by running this command

Dism /Mount-Wim /WimFile:D:\sources\install.wim /index:6 /MountDir:C:\Mountnew

After we mounted the install.wim file to our temporary folder we could also “load” the registry that’s inside the system32\config folder by running this command

reg load HKLM\OFFLINE C:\Mountnew\Windows\System32\Config\Software

When the Software part is loaded you could open the registry and open the OFFLINE key as shown below

After we have opened the RebootRequiredURI’s registry key, we took over the ownership and deleted that key!

When you are done deleting that key you need to make sure you UNLOAD the OFFLINE registry by running this command

Reg unload hklm\offline

When we have UNLOADED the registry, let’s unmount the image with DISM to make sure our changes are committed and saved!

DISM /unmount-image /mountdir:c:\mountnew /commit

After my image was unmounted I reinstalled the device again! After the apps were installed successfully it prompted us with the good old “sealing” screen!

7. Windows 11 Insider Previews

After doing some more tests I was interested if this weird Windows 11 Autopilot Issue would be fixed in an insider preview build. So I decided to start with an older Windows 11 Insider Preview build: 22526.1

I downloaded all older Windows 11 Insider Previews. I guess I love the UUP dump as I couldn’t find these older builds on the official Insider Preview ISO download site

windows 11 – Browse known builds – UUP dump

After installing the device again with this older build, I ended up with the same results (local admin at the Windows login screen) So I decided to download another build. This time I used the Windows 11 Insider preview 22h2 22567.1 build

As shown above, this time not a local admin problem at the Windows login screen but a “Something Went Wrong ” ice cream corn screen. I clicked the retry button multiple times but… nothing happened. I guess Microsoft almost fixed it in this release.. let’s try the Windows 11 Insider preview 22h2 22581.1 build

As shown above…. again the damn Ice Cream Corn! But after pressing “Try Again” a couple of times … it got me to the reseal screen!!!

After the 22581.1 build, I decided to skip the rest and just download the latest Windows 11 insider preview 22598.1 build with my Windows insider account

After creating my new Windows 11 installation medium I reinstalled the device and started the Autopilot for pre-provisioned deployments again. After Autopilot was done installing the apps, it rebooted again BUT this time it continued the Autopilot ESP instead of showing us the something went wrong error or the local admin login screen!!!!!


Having a good understanding of what could be causing a reboot during Autopilot is always good! When the reboot is triggered by Autopilot itself, normally it just reboots and will continue to the Account ESP stage.

A lot of people are complaining about a reboot during Autopilot…. but not me! Why? As it will solve the necessary Bitlocker DHA reboot to be compliant before the user logs in. I am explaining that part in another blog

Requiring Online Microsoft Store Apps and the Autopilot ESP (

Looking back to the Windows 11 bug, when not using the insider preview we don’t need that key to be there! A simple fix (for now) is just to delete that key… or just wait until the fix from the latest insider preview arrives in the regular Windows 11 build?

It Does Not Exist Data GIF - It Does Not Exist Data Star Trek - Discover &  Share GIFs

5 thoughts on “Don’t Be a Menace to Autopilot While configuring Your WUfB in the Hood

  1. We tried for a long time to get that implicit ManagePreviewBuilds setting removed but couldn’t get it done. It’s there for a very fringe scenario, i.e. an Insider build that wants to leave the Insider rings and join the “normal” ring, but that’s maybe 0.01% of machines out there. And there’s no logic to see “am I already out of the Insider rings” before telling the OS “leave Insider” and no logic in the OS to say “if I’m already not in Insider, it’s silly to reboot.” Hence the mess you see.

    The other possible workaround is to just not use the rings setting, manually setting the “other” WUfB settings via custom OMA-URI policies.

    1. Always nice to have michiel niehaus responding on a blog about autopilot… and especially when its my blog :)… an honor :).

      Doesnt sound like a difficult thing to remove but then again i am not working at ms :p… its a shame we should need to turn back to using the csp instead of the wufb rings to solve it… luckily with the latest insider previews the esp is still alive after the reboot… (even when it doesn need to reboot)

  2. Once again I find your blog detailing the exact same issue we’re having right now. I am in the process of testing Windows 11 and I run into the same issue where the computer reboots half way through self deploying mode, and ends up being unusable.
    But even after having tried both your options to fix this, it still doesn’t work. I have verified that the registry key doesn’t exist (and your script also confirms that when I run it). For now, I am out of suggestions, and keep crawling the internet for anything useful, but I think I might as well wait for the 22H2 release and hope that it’s fixed there.


    1. Oh, and another thing I tried after reading Michael Niehaus’ post, was to exclude WUfB from these computers. But that didn’t help either…

    2. Hi. Did you also searched for that same event log as I did for the managepreviewbuild? It should mention which uri has triggered the reboot
      Do you happen to have the security baselines configured? As these also could trigger a reboot due to the virtualization-based security

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  26  =  33