Last year, I wrote Part 1 of my article on Windows Autopatch, but life got away from me a.k.a. running Workplace Ninjas US and I never got back to this. Today, we will finish part two.

In this article, we will cover a few things:

• How Windows Autopatch Functions
  • Windows Update for Business Overview
  • Windows Autopatch Overview
• Windows Autopatch Under the Hood
• Autopatch APIs
• Windows Autopatch Log Review

Let’s get started as we have some fun things to cover, which should be a blast for everyone.

How Windows Autopatch Functions

Let’s first talk about Windows Update for Business works. I covered this in detail a few years ago here. We’ll quickly summarize it.

Windows Update for Business Overview

Windows Update for Business (WUfB) is simply shifting patching from your on-prem servers to public Windows Update servers. The service is free and available on Win10/11 Pro, Education, and Enterprise versions.

You can deploy WUfB through either GPO or Windows CSPs (e.g. Intune or 3rd party MDMs). These settings control how and when devices are updated.

The Windows Update Deployment Service delivers approval, scheduling, and safeguarding of updates for managed devices. The deployment service APIs that approve and schedule specific updates for deployment. They are powered by the Graph APIs and SDKs.

Now, we understand the basics of that, let’s discuss what makes Autopatch so different and then investigate what is under the hood.

Windows Autopatch Service Overview

We already know Windows Autopatch is a cloud service that automates Windows, Microsoft 365 Apps for enterprise, Microsoft Edge, and Microsoft Teams updates. Microsoft has told us that for awhile.

One of the ways that Windows Autopatch builds on top of WUfB is with the Autopatch Group Service (which is actually a function app) as seen in this diagram below. That is part of the device registration micro service that runs inside of Windows Autopatch.

Conceptually, things have changed a little bit, some think for the better some don’t, but I digress. They used to magically create all these groups. Now, you set the dynamic assignment group like you see here:

You can decide if you want to assign Entra groups to the rings or not, but that is your call.

From there, you tell it what types of patches to cover from:

Next, you tell it how to handle drivers, target versions of Feature Updates and Edge Rings:

From here, you can tweak things like:

• Deferrals and Deadlines for Quality, Feature, and Driver Updates
• Deferrals and Deadlines for Microsoft Office Updates
• Ring Install/Restart Options and Notification Options

Now, we will move onto the more technical info around Windows Autopatch.

Windows Autopatch Under the Hood

Now, we move onto the entire registration process, which is what makes the magic happen as opposed to just pushing random keys into the registry like WUfB.

1. Device is added to an Entra group in scope of Autopatch
2. A function called Windows Autopatch Discover Devices will trigger hourly searching for new devices. The Entra Device ID is then used to query attributes in Intune and Entra for registration. It grabs these attributes:
   1. AzureADDeviceID
   1. OperatingSystem
   1. DisplayName (Device name)
   1. AccountEnabled
   1. RegistrationDateTime
   1. ApproximateLastSignInDateTime

• Another function is called to check for device pre-requisites (basically making sure it meets its requirements to register, and will check for):
  • Intune-managed (checks if the Entra Device ID has an Intune Device ID also)?
  • Checked in within the last 28 days?
  • Windows device?
  • Corporate-owned Windows device?
  • Valid Windows SKU?
  • Meets OS requirements?
  • Validates workloads if it is co-managed.

• Next, it will calculate what ring to put it in provided you’re using dynamic distribution.
• If the Windows Autopatch Client Broker is deployed (more on this later), it will perform some post-device registration actions
• Registration finishes (check the full diagram below)

Let’s check out some of the stuff in the registry, which correlate to much of this.

Now, with Windows Autopatch we see a very different set of keys in “Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate”

Let’s talk a bit more about a few of these keys.

The SusClientId is used by Windows Autopatch to unique identify a device and associate that hostname to the unique ID. This isn’t new and was used back in the WSUS days.

The SusClientIdValidation is a hash that validates the Client ID is valid. It’s interesting they use another old WSUS key “UpdateDesiredVisibility” so that it isn’t treated like a WSUS-style reported device and like a cloud-registered device.

Overall, it’s interesting how we’re seeing so many WSUS internals still in Autopatch.

We also have keys here: “Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate”

There’s a ton of keys in here as you can see:

Let’s hit on a few of the ones that are interesting.

This key makes the scans work in the background as it’s a managed service:

Expression Evaluators are also very cool. These show for various update types, the DLLs it calls to make sure an update is valid:

One of the most interesting aspects is the USOClient.exe ((Update Session Orchestrator Client), which basically powers most of Windows Update, which you can read about here.

What’s very cool about the registry is it shows the EXACT command along with its parameters to invoke some of the functions:

So, you can use this command to update Edge:

UsoClient.exe  EdgeUpdate /ua /installsource scheduler-uo-express

I will be trying to capture all of the parameters but for now this is my current list: (These are from this great article here)

• StartScan
• StartDownload
• StartInstall
• RefreshSettings
• StartInteractiveScan
• RestartDevice
• ScanInstallWait
• ResumeUpdate

In addition I found:

• CrossDeviceUpdate
• DevHomeUpdate
• EdgeUpdate
• StartStoreBizCritUpdates
• StartLXPBizCritUpdates
• /update SCHEDULEDTASK triggeringUI=AprilForkExpressLane skipMoratorium=true displayLevel=none (for Office Updates)
• OutlookUpdate
• TFLUpdate
• ReportPolicies
• StartMaintenanceWork
• StartWork
• StartOobeAppsScan
• StartOobeAppsScanAfterUpdate
• /SendHeartbeat

The update handlers are also very cool. These show you the DLLs that the service passes you to perform updates.

You’ll notice it even shows you the URI to the schema .e.g.: http://schemas.microsoft.com/msus/2016/01/UpdateHandlers/OSInstaller

The location  “Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\PolicyState” is very important as it shows you where all of the settings that came down from the Autopatch service are located:

Another idea that is poorly documented is this area: “Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\UpdatePlatform\UX\Configurations”

These are additional settings will come down from the Autopatch backend telling it how to handle patching around the UX components.

One other aspect that I want to touch on is the Windows Autopatch Client Broker | Microsoft Learn. This is something you deploy from Tenant Admin > Windows Autopatch > Management and will by default go to all devices, but you can change that:

I think it’s a good idea in general to deploy it as it helps speed up troubleshooting. The two main things it buys you is:

• Helps with the readiness check by telling you if the device is ready to be managed by Autopatch, and proactively detect and address device issues.
• Empowers automated log collection for support issues otherwise you have to manually collect logs.

Windows Autopatch APIs

The last part I want to cover are the Autopatch API commands that are available, because they’re sometimes useful.

You can leverage the API pretty nicely to enroll devices in Autopatch for Feature Updates, Quality Updates, or Driver and Firmware Updates.

Enroll in feature updates like this (you can use either feature or driver as the category):

Endpoint: https://graph.microsoft.com/beta/admin/windows/updates/updatableAssets/enrollAssets

Body:

{

  "updateCategory": "driver",

  "assets": [

    {

      "@odata.type": "#microsoft.graph.windowsUpdates.azureADDevice",

      "id": "01234567-89ab-cdef-0123-456789abcdef"

    },

    {

      "@odata.type": "#microsoft.graph.windowsUpdates.azureADDevice",

      "id": "01234567-89ab-cdef-0123-456789abcde0"

    },

    {

      "@odata.type": "#microsoft.graph.windowsUpdates.azureADDevice",

      "id": "01234567-89ab-cdef-0123-456789abcde1"

    }

  ]

}

Not to belabor it too much further, we have a number of different things we can do with the API. Microsoft docs are decent on it, so let me just summarize the options:

With Feature Updates, we can:

• Run Queries to Identify Devices
• Enroll Devices
• List the Catalog Entries for Feature Updates
• Create Deployments
• Edit Deployments
• Add Members to a Deployment Audience
• Pause a Deployment
• Delete a Deployment
• Unenroll Devices

With Quality Updates, we can:

• Run Queries to Identify Devices
• List the Catalog Entries for Expedited Updates
• Create Deployments
• Add Members to a Deployment Audience
• Delete a Deployment
• Validate the Readiness of Devices for Expedited Updates

For Driver and Firmware Updates, we can:

• Run Queries to Identify Devices
• Enroll Devices
• Create a Deployment Audience and Add Members to a Deployment Audience
• Create an Update Policy
• Review Applicable Driver Content
• Approve Driver Content for Deployment
• Revoke Driver Approval
• Unenroll Devices

If you have any issues with any of the commands reach out, and I’m happy to chip in!

Windows Autopatch Log Review

Sometimes it’s fun or necessary to capture logs, so I thought we could explore that for a moment.

In PowerShell, you run this command to grab the ETL logs pretty easily:

The super neat thing about this command is it converts the ETL files found in C:\Windows\Logs\WindowsUpdate\ into a .LOG file you can read fairly easily.

You will find a ton of useful info in there:

If you get bored, you can also grab Microsoft PerfView to look at the ETL files, which can be really useful when you need to capture verbose logging.

You can also grab the USO logs from: C:\ProgramData\USOShared\Logs

It’s pretty neat what PerfView will show you overall:

If we zoom in, you can see the amazing details we get about USO:

This is the sort of info that when we have issues, Microsoft Support will look at. Overall, it’s nice to see the data, how its constructed, and how the USO does its job.