Not long after we started adding Windows Server 2012R2 servers earlier this year we noticed a problem with Windows Update. Our Server Group policy settings were set to automatically download updates, but we would have to manually install these updates to plan for downtime. In a 24-hour operation like a jail, we can’t necessarily schedule a time to boot users off of vital servers for restarts.

What I started to see was that on some of our servers the updates were not making it from our Windows Server Update Services server to the clients (ironically, our new WSUS server was one of these that wouldn’t get updates). In fact, these servers had never updated. After investigating I determined that the servers that were affected had one thing in common; they were never updated before they had a WSUS policy applied to them.

Digging for information I found a blog that highlights the issue. When you install a new Server, or a new Desktop OS for that matter, Windows runs through the Out-Of-Box-Experience, or OOBE. You’re familiar with this even if you never knew what it was called; it’s the part of the installation where Windows asks what you want your user and computer name to be, where you choose how you will handle updates, and where you choose your time zone.

Server 2012 has a short OOBE with a hidden step; run Windows Update. The OOBE will not end until Windows connects to Windows Update. And according to the above blog this issue also affects Windows 8.1.

You will know you have this issue if you navigate to C:/Windows/WindowsUpdate.log, the Windows Update log, and you find the following:
Windows OOBE is still in progress. AU deferring detection
WARNING: BeginDetection failed, hr:0x8024a008
All AU searches complete.
# WARNING: Failed to find updates with error code 8024a008
AU setting next detection timeout to 2014-10-22 12:44:24
OOBE is in progress, so cannot perform Accelerated Install

So how do you fix this? The blog quoted above shows a PowerShell module that can be downloaded and used to access Windows Update (As an aside, how is there not an official Microsoft PowerShell built-in module for Windows Update?). This works well for updating the machine but it still doesn’t solve the actual problem; it doesn’t manage to force an end to the OOBE. And while updating is definitely a good thing, I also want to return the system to its full functionality so that I don’t have to remember that these are the three machines that need to be update in some  special way.

After a few months of searching I finally found the answer, accidentally, as it were. I was examining the registry values for Windows Update in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Updatewhen I came across this:

IsOOBEInProgress : 1
PSPath           : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Win
dowsUpdate\Auto Update

I few tests later and I determined that this registry d-word value, when set to 1, means that the Out Of Box Experience is currently running. When set to 0, Windows Update thinks that the OOBE is completed. Sure enough, this change fixed all of the issues we had with server updates.

So to make this change yourself, open a PowerShell prompt as an administrator (Right-click and select “Run As Administrator”) and type the following command:

set-itemproperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\' -Name IsOOBEInProgress -Value 0

After a restart, you should be able to run Windows Update without any problems.