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
- The Issue
- The Fix
- How to NOT Implement the Fix
- How to Implement the Fix Option 1
- How to Implement the Fix Option 2
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 deployment. After the ESP device phase finished installing the required apps Windows suddenly rebooted!
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.
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.
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!
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!
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?
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 (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 RebootRequiredURI
I decided to check out the WUfB deployment rings because it was mentioning 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 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!
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:SOFTWAREMicrosoftProvisioningSyncMLRebootRequiredURIs
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!
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 serviceTrusted 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 the idea to create a scheduled task to bypass the “NT servicetrusted 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)
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)
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:sourcesinstall.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 system32config folder by running this command
reg load HKLMOFFLINE C:MountnewWindowsSystem32ConfigSoftware
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 hklmoffline
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!
Having a good understanding of what could be causing a reboot during Autopilot is always good! In my opinion, 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!