Windows 11 Hotpatch: RebootLess Updates

Microsoft has recently introduced a mind-blowing feature called Hotpatch AKA Rebootless for Windows 11 Enterprise (version 24H2) and Windows 365 Enterprise. This feature allows quality updates to be applied without requiring a system restart, making it a game-changer for maintaining system availability while keeping devices secure.

Why Windows 11 Hotpatch is Useful

Traditionally, updates requiring a restart can wreak havoc on workflows and productivity, especially in environments where continuous uptime is critical. Enter Hotpatching—a game-changing solution that applies most updates seamlessly in the background, sparing end users from interruptions. While this dramatically reduces disruptions, periodic reboots are still required to maintain system stability. Typically, these are required only once every three months, cutting annual reboots from 12 to just 4—a whopping 66% reduction! This approach minimizes downtime, boosts productivity, keeps systems secure, and ensures compliance with minimal disruption.

Still, Hotpatching isn’t a one-size-fits-all solution. Its undeniable benefits must be balanced with regular system maintenance to prevent performance degradation and ensure long-term stability—don’t let convenience breed complacency.

In this blog, we’ll walk you through configuring Hotpatching using Intune, unravel the architecture that powers this feature, and dive deep into how components like Usoclient and MoUSOCoreWorker (Modern Update Stack Orchestrator Core Worker) handle policies and deploy updates on Windows devices.

By the end, you’ll understand the “how” and the “why” behind this innovative update strategy.

The WUFB-DS Hotpatch overview

Let me show you the Hotpatch overview before zooming in on every building block one by one.

We will first start with the easy part, which is configuring the Hotpatch policy in Intune.

Configuring the Hotpatch Policy in Intune

To enable Hotpatching, it’s essential to ensure that all requirements are met. Here’s what you need:

• A Microsoft Subscription: This includes Windows Enterprise E3 or E5 (e.g., Microsoft 365 A3/A5 or Microsoft 365 F3) or a Windows 365 Enterprise subscription.
• Targeted Devices: Devices must be running Windows 11 Enterprise (*LTSC) version 24H2 (Build 26100.2033 or later).
• Management Platform: Microsoft Intune is required 🙂 to deploy and manage the Hotpatch policy.

*LTSC: Please Note that Hotpatching only seems to kick in for the LTSC version (for now), as it seems there are no hotpatch-capable updates currently available for the regular Windows 11 Enterprise 24H2 release.

Once you’ve confirmed that all requirements are in place, you can proceed to configure the Hotpatching Update Policy in Intune. We can do so by creating a new Windows Quality Update Policy (preview)

After selecting the new preview policy, we need to define some additional settings.

1. Apply the latest cumulative quality updates for security: Enable this option to allow the system to fetch and apply the latest security updates.

2. When available, apply without restarting the device (‘hotpatch’): Toggle this option to enable Hotpatching, which applies the updates without requiring a reboot.

After creating and assigning this policy to your devices, you may notice that syncing the device in Intune doesn’t immediately reflect the changes. That’s because the actual policy download and application process is handled by background services on the device itself(Usoclient and MoUSOCoreWorker), who communicate with the WUfB-DS API rather than the standard Intune sync mechanism. Once the device communicates with the API, we will notice that Windows Update now mentions that it will enable hotpatching when available.

Installing the hotpatch-capable Update

With the policy configured, we can start checking the device for Windows updates. As shown below, after checking for updates, it mentions that the 2024-11 Windows 11 version 24h2 is HotPatch Capable and would start installing the update

After installing the update, we even got a nice green bar telling us that we are NOT REQUIRED to reboot the device!

It looks like pure magic! Except for the .net framework update, which still requires the device to reboot (sorry for the Dutch language)…but we can’t have it all, right?)

Let’s move on and dive into how this new Hotpatch Update policy arrives on our device.

Windows Client Scheduled Tasks and Background Services

The orchestration of retrieving the Hotpatching policy involves several moving parts on the Windows client.

Here’s a breakdown of the flow:

1. Scheduled Tasks

• Tasks like usoclient.exe start scan or other maintenance tasks trigger the Windows Update engine.

• These other Update Orchestration scheduled tasks ensure the system periodically checks for updates and applies policies when necessary.

2. Usoclient and MoUSOCoreWorker Interaction

• Usoclient: Acts as the entry point. When triggered, it initiates a scan for updates and policies. (StartScan). This triggers the MoUSOCoreworker to wake up.

• MoUSOCoreWorker: This is where the real magic happens. It:

  • Reads the store.db file (c:\programdata\usoprivate\updatestore\store.db) to determine the last scan time and policy

• Validates the cached policy (ScanCache)against the current time to decide whether to fetch a new policy.

• If the policy is outdated (or store.db is missing), it queries Windows Update Service API for the latest policy.

Detailed Component Workflow (Mermaid Flow Overview)

Here’s how the scheduled tasks, Usoclient, and MoUSOCoreWorker to retrieve the updatepolicy to make Hotpatching a reality:

Detailed Explanation of the Mermaid Flow

Here’s a breakdown of the steps in the flowchart to help you understand how the Hotpatch feature operates in conjunction with Windows Update components:

1. Scheduled Task (Usoclient.exe start scan)

The process begins when a scheduled task or manual execution triggers usoclient.exe to start a scan (StartScan). This task ensures that the Windows Update process starts periodically or when requested.

• Purpose: To initiate a scan for updates, which includes fetching policies, determining the state of the system, and deciding on further actions.

2. MoUSOCoreWorker Execution

Once the Usoclient starts the scan, the MoUSOCoreWorker takes over. This component performs the heavy lifting, such as:

• Checking local policies and configurations.

• Deciding whether a new policy fetch or update is required based on the scan delay and the local cache.

• Communicating with external Microsoft Update services if necessary.

Key Responsibility: MoUSOCoreWorker determines whether the update process proceeds further by consulting the local store.db.

3. Database Logic

The MoUSOCoreWorker checks the store.db file (stored in C:\ProgramData) to understand the state of updates on the device:

• Check for the Last Scan Time:

• Determine Cached Policy Validity:

  • The worker examines ScanCache and ScanAttemptTime entries in store.db to verify if the cached policy is still valid.

Decision Point:

• If the cached policy is valid, the system proceeds to apply it directly.

• If the cached policy or store.db is invalid or missing, the system triggers a policy fetch.

4. Policy Fetch from devicelistenerprod

If the cached policy is outdated or missing, the MoUSOCoreWorker communicates with the Microsoft Update Service through the endpoint devicelistenerprod.(GraphSync)

The service responds with the latest UpdatePolicy JSON.

• What’s in the JSON: This file includes update-related settings, such as whether Hotpatching is enabled, required update packages, and scheduling rules.

A fun thing: If you have the token, you could also query the same API (or some others) with PowerShell.

5. Apply the Hotpatching Policy

The fetched Update Policy JSON is then parsed and applied to the device. Specifically:

1. Stored in store.db: The policy and metadata are cached locally for future reference.

2. Applied to the Windows Update Policy Manager: The policy is then applied to the system. We can spot the MoUSOCoreworker setting the AllowRebootless registry key in the Policymanager Key.

When this key is set, we will notice that if we check the configured update policies, we will now spot the corresponding hotpatching policy.

6. Update Database

After the policy is successfully applied, the following steps occur:

• Update the Last Scan Time: The ScanAttemptTime in store.db is updated to the current timestamp.

• Cache Metadata: Relevant details about the fetched policy are stored to ensure the system avoids redundant fetches in subsequent scans.

7. End Points

The process has two possible outcomes:

• No Action (Do Nothing): If the scan delay hasn’t been met or the cached policy is still valid, the system exits without making any network calls.

• Policy Applied Successfully: The new policy is applied, updates proceed as per the policy, and the device remains compliant.

The Hotpatching Policy Demo

Words are only words, so let’s take a look at a video in which I demonstrate how this policy is sent from the WUfB—DS API endpoint when the orchestrator scheduled task is launched.

The MoUsoCoreWorker logs

After looking at the flow and the explanation, you might wonder how I got all this information. It always starts with logs and Fiddler.

To understand how this flow worked, I opened the ETL files from the c:\programdata\usoshared\logs\system folder. After opening the existing ETL file with the WPA tool, it showed me the Orchestrator flow with the timestamps.

This flow is pretty important! Why? Because after opening the mousocoreworker.exe with the IDA tool, things become very easy to spot

The only thing I needed to do was examine the graphprovider::scan function to determine how and when the hotpatch UpdatePolicy was coming down to the device.

Key Takeaways

1. Policy Flow:

   • While the policy configuration is initiated in Intune, its enforcement relies on the Windows Update components (Usoclient and MoUSOCoreWorker) on the Windows client. Intune primarily manages policy assignment, while the actual application of the policy occurs through the client’s interaction with backend services, such as the Device Catalog (DCAT) and OneSettings endpoints. This separation allows for greater scalability and robustness as updates and policies are fetched and applied based on the client’s schedule, ensuring seamless integration with existing workflows.

2. Hotpatching Advantages:

   • Critical updates are applied without restarts, ensuring minimal downtime for enterprise environments.

   • Security posture is improved as systems stay updated with minimal user disruption.

   • Only for critical devices that you can’t afford to reboot

3. Importance of store.db:

   • The store.db cache is central to managing policy validity and reducing redundant network calls. It ensures that policies are only fetched when needed.

Conclusion

In conclusion, Hotpatching represents a significant leap forward in managing enterprise devices. With tools like Intune for policy management and the robust architecture provided by Windows Update components, organizations can maintain a seamless balance between security and productivity. Keep an eye on this feature as it evolves—it’s a game-changer!