This blog will discuss the famous reboots you could encounter when using Autopilot. I will also show you what happens 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!
To better understand 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 notice that we are enrolling 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 ensured we knew 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.
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, we noticed the same error 0x20004 code again in the system event log. Sorry for the dutch words… but I guess you know what “Opnieuw Opstarten” means.
Now that we have examined the IME and system logs, let’s examine some other event logs. When you encounter CloudExperienceHost errors, the Shell-Core event log is always the place to start digging!
As shown above, this event log tells 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 unsure what could be triggering it. Let’s start troubleshooting!
So, I decided to perform another Autopilot enrollment to hopefully spot something more useful. This time, I decided 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?
I was like huh? This issue should have been fixed some time ago (15-11-2021)
I guess it doesn’t count for Windows 11 somehow? But looking back at the picture and taking a look 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 (oofhours.com)
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 RebootRequiredURIs
I decided to check out the WUfB deployment rings because it mentioned the Update URI. As shown below…
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
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!
As shown above, I decided to remove “All devices” from the assignment and added “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!
Please Note: When using AutoPatch, there is a “slight” change that could cause the same issue. As shown below, the “BusinessReadyUpdatesOnly” is configured for all.
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?
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.
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!
Of course, my first idea to fix it didn’t work. Let me explain what I tried to do. I wrote a PowerShell script and uploaded it to Intune so I could be sure it would be pushed to the device when enrolling it 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!
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!!!!!
Being too late is one, but when testing this script, I also noticed that the idea of creating a scheduled task to bypass the “NT servicetrusted installer” permission issue is great, but it won’t work during OOBE. 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)
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!
https://call4cloud.nl/wp-content/uploads/2022/04/remove2.zip
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 also ensure 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)
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 had 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! After the apps were installed successfully, we were prompted by the good old “sealing” screen!
As mentioned before, when using Windows Autopatch, you could also stumble upon this issue. So did Adam Gross
He used and rewrote my initial script but improved it greatly by obtaining additional privileges to delete those reg keys!
SeTakeOwnershipPrivilege
SeRestorePrivilege
Go get it while it’s hot!!! (could also be used to remove additional rebootrequireduri’s)
Toolbox/Remove-AutopilotRebootKeys.ps1 at master · AdamGrossTX/Toolbox · GitHub
Damn…!!!! I guess the 2022-08 Update (KB5016629) must be one of the best updates that were delivered since the KB5007253 (the one that fixed the Intel TPM attestation issues!)
Why? ??? Let me show you why!
2. it fixes the required missing frameworks for your Microsoft Store apps after your device goes through a remote Wipe!
Microsoft Store Apps not working after performing a Wipe (call4cloud.nl)
3. Last but not least, it fixes the issue I showed you in this blog when pre-provisioning a device! After installing the required KB5016629 update, it looks like you can pre-provision your device without being afraid of a broken Autopilot device!
It’s always good to have a good understanding of what could be causing a reboot during Autopilot! When Autopilot triggers the reboot, it normally just reboots and continues to the Account ESP stage.
Many 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 (call4cloud.nl)
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 wait until the latest insider preview fix arrives in the regular Windows 11 build?
Troubleshooting error 2147749902 (WBEM_E_INVALID_NAMESPACE) isn’t always straightforward. What started as a simple Intune error turned…
This blog will focus on a new Intune Core Feature called Windows Device Inventory (Resource…
This blog will show you the inner workings of the Device Inventory Agent
This blog is a follow-up to the Windows Enrollment Attestation series. I’ll dive into why…
Deploying Windows devices using Autopilot can be challenging, especially when devices are shipped from a…
This time, we’re diving back into Device Health Attestation (DHA). With Windows 24H2, there’s a…
When subscription activation gets stuck, it could be due to conflicting tenant accounts. This blog…
In this post, I’ll show you how to streamline the Out-of-Box Experience (OOBE) setup process…
