OOBECompleteTimestamp: The Hidden Reason Behind WUfB Hotpatch Delays

If you’ve read my previous post about Windows 11 Hotpatch, you’ll remember how this feature promises rebootless updates and streamlined patch management. But during that deep dive, one question lingered: why wasn’t the Windows 11 Hotpatch policy applied right after enrollment? The answer lies with an important registry key inside the Windows Update process: the OOBE Complete Timestamp. This blog unpacks what this registry key does, why it’s so critical for Windows Update for Business (WUfB) policies, and how it can create delays or failures.

Bonus tip: We’ll explore how this key might also help requirement scripts determine whether the Out-of-Box Experience (OOBE) is truly complete.

Introduction: From Enrollment to Updates: The Hidden Puzzle Piece

So, there you are, setting up a new Windows device. The Windows Autopilot enrollment finishes, and everything seems fine… until you realize some updates aren’t kicking in as expected. Windows Hotpatch? Delayed. Rebootless updates? Nowhere to be seen. If this sounds familiar, the answer might lie in a little-known registry key called OOBECompleteTimestamp.

This blog explores what this key does, why it’s critical for policies like the Hotpatch setting, and how its absence and even its presence (with delays) can complicate your WUfB policies. We’ll also cover Microsoft’s fixes to ensure updates flow smoothly during and after enrollment. Let’s dive in.

The Discovery: What is OOBE Complete Timestamp?

During the Out-Of-Box Experience (OOBE) and when the user signs in for the first time, the system processes configurations, applies policies, and prepares the device for life in the real world. Once this process is done, winlogon.exe writes a registry key named OOBECompleteTimestamp.

 This key serves as the device’s marker that OOBE has officially ended.

Here’s where you can find it: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE\OOBECompleteTimestamp

It looks like this:

• Name: OOBECompleteTimestamp

• Type: Binary

• Value: A timestamp marking the exact moment OOBE wrapped up.

Let’s discuss some fun facts about this key. Fun fact number one: With that OOBECompleteTimeStamp key missing, the AllowRebootlessUpdates policy won’t kick in. We will spot the same when taking a look at the UpdateStore Database. The last run was blocked by OOBE (BlockedByOObe)

Fun fact number two: Even with this key set, Windows Update for Business (WUfB) policies like re-bootless updates or hot patching might not apply immediately.

Let’s first zoom in on how that “delay  exactly works.”

OOBE Completion and First Use Time: When is a Device Ready?

Windows doesn’t just mark the end of the OOBE phase with the OOBECompleteTimestamp, and it also uses this key to calculate when a device is officially “ready.” This readiness is determined by a process called First Use Time, which depends entirely on OOBE completion.

Here’s what happens under the hood:

1. OOBE Check:
   The system verifies if OOBE has completed using the OOBEComplete function. If not, the “first use time” defaults to an invalid state, preventing updates or policies from applying.

2. System Setup Manager:
   If OOBE is complete, the system retrieves the timestamp via the GetOutOfBoxExperienceCompleteTime method from SystemSetupManager.

3. Conversion:
   The retrieved timestamp is converted from Windows file time to Unix epoch time, making it usable for updates and policies.

4. Error Handling:
   If errors occur or the OOBE timestamp is invalid, the system halts further calculations, potentially delaying updates or compliance policies.

The Delayed Readiness Dilemma: When Hotpatching Hits Pause

Even when the OOBECompleteTimestamp is correctly set, the system doesn’t jump to action. Instead, it takes a sweet time to request or apply policies like Hotpatch / AllowRebootlessUpdates.

This delay isn’t a bug; it’s a feature. It’s designed to ensure the system is fully prepared before Windows updates and policies start rolling out.

But here’s the rub: this deliberate delay often leaves IT administrators scratching their heads, wondering why their freshly enrolled devices seem stuck in limbo, missing Windows updates or policies they expected to be applied instantly.

Now, when the OOBECompleteTimestamp is missing or invalid, things really take a turn for the worse.

The Problem: Missing the OOBE Complete Timestamp

Without this critical marker, the system can’t calculate “First Use Time”, and that’s where the trouble begins. No timestamp, No Update, No Policies? Devices are left hanging in an unready state, leaving admins scrambling to figure out what went wrong.

This isn’t just a rare edge case. Newly enrolled devices sometimes lack the OOBECompleteTimestamp immediately after enrollment. Why? Because if the OOBE process gets interrupted or doesn’t complete properly, winlogon.exe won’t create the key at all.

And without this key:

• Windows Updates sit idle, waiting indefinitely for the green light that never comes.

• Policies like Hotpatching and other WUfB features stay on hold, and they are refusing to apply.

• IT admins are left chasing ghosts, trying to debug devices that won’t cooperate.

Whether it’s the deliberate delay after the key is set or the chaos caused by its absence, the OOBECompleteTimestamp can be a silent saboteur in your update strategy. Knowing how to spot these issues and fix them is the key to keeping your devices up to date without the drama.

How to Verify the OOBECompleteTimestamp

Before discussing fixes, let’s confirm if the issue is with this key. A quick PowerShell command will tell you if the OOBECompleteTimestamp is missing or set incorrectly.

Here’s the script to check the timestamp and translate it into a readable format:

# Define the registry path and value name
$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE\OOBECompleteTimestamp"
$valueName = "OOBECompleteTimestamp"

try {
    # Retrieve the binary data
    $binaryData = Get-ItemPropertyValue -Path $registryPath -Name $valueName

    if (-not $binaryData) {
        Throw "Value '$valueName' does not exist at '$registryPath'."
    }

    # Output raw binary for debugging
    Write-Output "Raw Binary Data: $($binaryData -join ' ')"
    Write-Output "Binary data length: $($binaryData.Length)"

    # Parse binary data as a structured datetime
    if ($binaryData.Length -ge 12) {
        $year   = [BitConverter]::ToInt16($binaryData, 0)  # First 2 bytes: Year
        $month  = [BitConverter]::ToInt16($binaryData, 2)  # Next 2 bytes: Month
        $day    = [BitConverter]::ToInt16($binaryData, 4)  # Next 2 bytes: Day
        $hour   = [BitConverter]::ToInt16($binaryData, 6)  # Next 2 bytes: Hour
        $minute = [BitConverter]::ToInt16($binaryData, 8)  # Next 2 bytes: Minute
        $second = [BitConverter]::ToInt16($binaryData, 10) # Next 2 bytes: Second

        # Validate and create a datetime object
        $decodedDate = Get-Date -Year $year -Month $month -Day $day -Hour $hour -Minute $minute -Second $second
        Write-Output "Decoded Date (Structured): $decodedDate"
    } else {
        Throw "Binary data is too short to decode as a structured datetime."
    }
}
catch {
    Write-Error "Error: $($_.Exception.Message)"
}

 Run this script, and you’ll either see the exact time OOBE is completed or confirmation that the key doesn’t exist. So, people who want to determine if the OOBE is complete can just check if this key is there! Easy does it!

The Fix: Enabling Updates Before the First Sign-In

If the OOBECompleteTimestamp is missing or you’re running into update delays, Microsoft has introduced a policy fix to address this. You can configure Allow updates to install before initial user sign-in to bypass the reliance on OOBECompleteTimestamp. This ensures updates are processed regardless of the OOBE state.

$RegKeyPath = “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Orchestrator”

$regValueName = “ScanBeforeInitialLogonAllowed”

$regValueData = 1

New-Item -Path $RegKeyPath -Force -ErrorAction SilentlyContinue | Out-Null

New-ItemProperty -Path $RegKeyPath -Name $regValueName -Value $regValueData -PropertyType DWORD -Force | Out-Null

For reference, check out Microsoft’s official guidance here.

Why Does This Fix Matter?

By enabling updates before sign-in, you’re essentially cutting out the dependency on OOBECompleteTimestamp. This is especially useful for:

• Newly enrolled devices: Ensures updates happen without delays, even if the key isn’t created in time.

• Enterprise environments: Keeps devices compliant with update policies right out of the box.

• Hotpatch workflows: Prevents rebootless updates from stalling due to missing markers.

Wrapping Up: OOBE, Policies, and the Waiting Game

The OOBECompleteTimestamp might seem like a minor detail, but it’s the linchpin that tells Windows it’s time to roll out updates and apply policies. Without it, or with delays in processing, it’s like hitting the brakes on Hotpatching, and other WUfB features.

You can sidestep these delays and keep your devices running smoothly by staying ahead of this potential bottleneck, verifying the timestamp, and implementing the fix. Next time updates stall or policies fail to apply, you’ll know exactly where to dig.