Mastering Windows Updates & Microsoft Updates – Part 1

Behind that simple “Check for updates” button lies a complex system of services, agents, stacks, and rules.

In this post, we’ll explore how to master Windows Updates successfully, why they sometimes fail, and what we can do in case something went wrong.

Further we will also see the difference between Windows and Microsoft Updates and their different settings we need to understand.

In Part 2 we will troubleshoot Azure virtual machines they will either stuck during updates or just looking like stuck and how to determine and solve it.

We will also take a look at the Extended Security Update (ESU) program and some troubleshooting about, further will see different methods to determine the installed SQL server version on Windows.

Checking for Updates Safely without triggering them by using SConfig

On Windows Server Core and some GUI editions, the built-in SConfig utility offers a command-line menu to manage common tasks like networking, domain membership, and Windows Update.

Unlike the “Check for updates” button in Settings, the SConfig utility lets you scan for available updates without triggering installation immediately.

This makes it a safe way for admins to see what patches are pending before deciding when and how to apply them.

The “Check for updates” button changed the way to now not just scanning but also downloading and installing automatically updates (for most update types) since Windows 10 and Windows Server 2016.

The SConfig utility still allows scanning without triggering the download and installation.

To open the SConfig utility we can use either the PowerShell or also the CMD. Just type

> SConfig

Select (6) to scan and search for updates.

Before downloading or installing them, we will be asked and can exit anytime without.

I will scan and search for all quality updates.

The Windows Update Agent (WUA) is now scanning for new updates. SConfig is just a VBScript menu wrapper that calls the same APIs the Windows Update Agent (WUA) uses.

The system executable in Window the Windows Update Agent (WUA) service is using under the hood, is the C:\Windows\System32\USOClient.exe which will finally scanning, downloading and installing updates plus restarting the system if needed.

It’s essentially a replacement for older tools like wuauclt.exe, which were used in previous versions of Windows.

Btw. in case of using WSUS, the scanning here will finally also trigger onboarding the computer to WSUS if not already shown up there under All Computers.

Below we can see that the Windows Update Agent (WUA) found three new available updates for the system.

Just pressing enter or (N) will cancel the process and going back to the main menu.

We can now exit the SConfig utility by entering (15).

The Microsoft Update Catalog: Your Official Source for Manual Windows Updates

Need a specific hotfix, driver, or patch that Windows Update doesn’t deliver?

The Microsoft Update Catalog is an official, searchable hub where IT pros and advanced users can find, download, and manage individual updates like MSU, CAB, or driver packages.

Whether you’re targeting offline systems, troubleshooting failed updates, or building precise deployments, the catalog puts granular control over your updates into your hands.

It’s especially useful for devices behind firewalls or in environment scenarios where automatic update channels don’t reach.

It supportWhen updates fail, Windows often leaves behind corruptions searching by KB number, product, classification, or hardware ID, perfect for finding exactly what you need.

And while it once required Internet Explorer and an ActiveX control, it’s now fully compatible with modern browsers and doesn’t require add-ons.

We can access the Microsoft Update Catalog through the following URL https://www.catalog.update.microsoft.com.

Download Updates from the Microsoft Update Catalog by using PowerShell

If we can’t use a browser download on the affected server but finally outbound HTTPS traffic to the Microsoft Update Catalog is allowed, we can also use the following PowerShell cmdlet to download a *.msu package from the Microsoft Update Catalog.

Start-BitsTransfer is a PowerShell cmdlet that uses BITS (Background Intelligent Transfer Service) to download or upload files.

It’s especially useful for large files because it can pause, resume, and handle network interruptions gracefully.

On newer Windows 10/11 and Server 2022 builds, Microsoft recommends Invoke-WebRequest or Invoke-RestMethod for simple downloads, but Start-BitsTransfer is still preferred for large, resilient transfers (like .msu updates).

# e.g. 2025-09 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5065428)
PS> $source = "https://catalog.s.download.windowsupdate.com/c/msdownload/update/software/secu/2025/09/windows10.0-kb5065428-x64_3c83399a5ec7b56767218da3a1823e6349ceafb1.msu"

PS> $Destination = "C:\Users\<username>\Downloads\windows10.0-kb5065428-x64_3c83399a5ec7b56767218da3a1823e6349ceafb1.msu"

PS> Start-BitsTransfer $Source $Destination

The URL we can pick from the Microsoft Update Catalog https://www.catalog.update.microsoft.com/.

Install KBs manually by first downloading it from the Microsoft Update Catalog

We can install KBs manually by using the WUSA utility (Windows Update Stand Alone)

Download the desired KB directly from https://www.catalog.update.microsoft.com.

> wusa.exe <path_to_KB5063877>.msu /quiet /norestart

/quiet: No UI
/norestart: Prevents auto-reboot

We can check if the KB was successfully installed by running.

PS> Get-HotFix -Id KB<number>

e.g.
PS> Get-HotFix -Id KB5062799

After a failed run, search C:\Windows\Logs\CBS\CBS.log for the same timestamp and error codes they appear to see which package/component failed inside the Latest Cumulative Update (LCU).

The file C:\Windows\Logs\CBS\CBS.log is one of the most important system logs on Windows when it comes to updates and servicing. It contains:

CBS (Component-Based Servicing) operations ==> Every action the Windows Servicing Stack (SSU) performs (installing, repairing, or removing components/updates).

Which updates were downloaded, staged, or applied. Success or failure messages for each package.

We can use the manual installer (wusa.exe) to pach an offline VM or image or by using 3rd party patch management solutions they doesn’t use WSUS or Windows Update as repository.

.msu packages are processed by wusa.exe, not the Windows Update client (wuauclt.exe or usoclient.exe).

usoclient.exe is part of the Update Session Orchestrator (USO), responsible for managing and orchestrating Windows updates. It handles the scanning, downloading, and installation of updates for the operating system and other Microsoft products. It replaced the older wuauclt.exe in newer Windows versions. 

The Get-WindowsUpdateLog command by the way reconstructs .etl logs from usoclient activity into a readable format.

Check for Pending Reboots

Sometimes Windows won’t finish installing updates or applying changes until the next restart, but how do you know for sure if a reboot is required?

There are several ways to test for pending reboots: by checking the RebootRequired registry key with PowerShell, querying package states with dism /Online /Get-Packages, or using ready-made tools like the Test-PendingReboot PowerShell cmdlet.

Below we will see each method we can use to quickly determine whether your system is waiting for a restart before updates or servicing operations can continue.

We can just query the following registry key by using Powershell plus also using the dism tool as shown below. Some of the updates will just shown a pending reboot by using one of them, so to finally be save run both, querying the registry and using the dism tool.

PS> (Get-Item 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired' -ErrorAction SilentlyContinue) -ne $null

and using the dism tool
PS> dism /Online /Get-Packages | findstr /i pending

also show the affected package
 dism /Online /Get-Packages /Format:Table | findstr /i pending

PS> dism /Online /Get-Packages | findstr /i pending

# also show which package requires a reboot
dism /Online /Get-Packages /Format:Table | findstr /i pending

As mentioned we can also use a PowerShell cmdlet to check for pending reboot and shown here in detail plus how to install the module offline in case the computer doesn’t have outbound internet access.

Here we can also determine detailed information about the reason for the pending reboot.

We can also check if there is pending.xml file in C:\Windows\WinSxS\. More about in Part 2.

The pending.xml file in C:\Windows\WinSxS\ is a temporary file that contains information about pending Windows updates or operations. 

It is created and used by the Windows servicing stack to manage updates, but if it becomes corrupted or stuck, it can cause update errors. To resolve issues, you may need to use an elevated Command Prompt to rename or delete pending.xml to clear stuck update operations, often in conjunction with other steps like clearing the Software Distribution folder.

> dir C:\Windows\WinSxS\pending.xml

# if it exists and Windows update process is really stuck
> rename C:\Windows\WinSxS\pending.xml pending.old

Checking installed Updates

Running updates is one thing, knowing they actually applied is another. Whether you’re troubleshooting a failed patch or just double-checking system health, Windows gives you several ways to confirm update status: from the Settings app and Event Viewer to PowerShell commands and the WindowsUpdate log files.

Below we will look at the most reliable methods to verify if updates were really installed and completed without issues.

Not all Updates appear under Settings – Update & Security – Windows Update – View update history

Some updates we will just find under Control Panel -> Programs -> Programs and Features -> Installed Updates, the reason for is due to how Windows categorizes and packages updates internally.

OS updates in general will be shown up under Settings – Update & Security – Windows Update – View update history whereas product updates like e.g. pure .Net Framework updates will just shown in the Control Panel.

Also for example SQL Server updates will just shown up in the Control Panel whereas security updates for Microsoft OLE DB Driver for SQL server will shown up under Settings – Update & Security – Windows Update – View update history because they will belong directly to the OS itself.

Windows has two main separate tracking systems for update history:

• Control Panel (legacy) → Programs and Features → Installed Updates ==> Reads from CBS (Component-Based Servicing) store

• Settings → Windows Update → View update history ==> Shows WU client logs (Windows Update Agent history)

By using the manual Installer (.msu Files)

Security updates provided as .msu files and installed by the manual installer (wusa.exe) also just shown up in the control panel and not in the new Settings UI.

PS> wusa.exe windows10.0-kb5062557-x64-1809_tw74754-86339.msu /quiet /norestart

WUSA utility (Windows Update Stand Alone)
/quiet: No UI
/norestart: Prevents auto-reboot

# Uninstall update
PS> wusa /uninstall [KB number] /kb:[number]

# Show detailed output
wusa [update.msu] /verbose

The install is logged in:

• C:\Windows\Logs\CBS\CBS.log
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\

Result: The update is fully installed, and appears in Get-HotFix and Control Panel but It is not registered in the Windows Update Agent’s event history and therefore does not appear in Settings → Windows Update → View update history.

Check installed Updates by using PowerShell

The PowerShell cmdlet Get-HotFix provides a quick way to list updates, service packs, and hotfixes installed on a Windows system.

It shows details like the KB number, installation date, and description, making it a handy first step when you need to verify if a specific patch is present or troubleshoot update history from the command line.

PS> Get-HotFix | Sort InstalledOn -Descending | Format-Table -AutoSize

or what is intalled on a specific date
Get-HotFix | Where-Object { $_.InstalledOn -ge (Get-Date "2025-07-17") } | Sort InstalledOn

or with the following command, sometimes returns more data than Get-HotFix, but still focuses on OS KB updates.
Get-CimInstance Win32_QuickFixEngineering | Where-Object { $_.InstalledOn -ge (Get-Date "2025-07-17") } | Sort InstalledOn

Check if specific Windows Security Update was successfully installed

We can also use Get-HotFix to check if a specific update were successfully installed by running the following command.

PS> Get-HotFix | Where-Object {$_.Description -eq "Security Update"} | Sort-Object InstalledOn -Descending

Or searching for a specific update

PS> Get-HotFix -Id KB5062557

If the update appears here, it was installed successfully.

If there is a discrepancy when under Settings – Windows Update – View update history the update appears as failed to install and under Get-Hotfix it is shown up, the failure message in Settings usually reflects an earlier attempt.

Get-HotFix reflects the current state and if it’s listed there, the update is now installed successfully.

Checking installed Updates by using the Event Viewer

Windows logs every update installation attempt in Event Viewer, giving you a detailed timeline of what was installed, when, and whether it succeeded or failed.

By browsing the Setup and WindowsUpdateClient logs, you can confirm successful updates, spot errors, and dig into the details that the Settings app doesn’t always reveal.

We can filter here for Event ID 1,2,4.

Event ID 1 Update installation started
Event ID 2 Update installation completed successfully
Event ID 4 Reboot initiated or required

Windows Server 2012 Update Logfiles vs. Windows Server 2016 and newer

Windows Server 2012

On Windows Server 2012 and earlier, update activity was still logged in plain text files under C:\Windows\WindowsUpdate.log as shown below.

These logs provide a straightforward, line-by-line record of update checks, downloads, installations, and errors.

Unlike newer systems that rely on Event Viewer and ETL tracing, Server 2012 makes it easy to open the file directly in Notepad for quick troubleshooting.

C:\Windows\WindowsUpdate.log

Windows Server 2016 (Windows 10) and newer

On Windows Server 2016 (and Windows 10) and newer we first need to run the following Windows PowerShell cmdlet to generate this logfile.

PS> Get-WindowsUpdateLog

This cmdlet will merge and convert Windows Update trace files (.etl files) stored under C:\Windows\Logs\WindowsUpdate into a single readable WindowsUpdate.log

Windows Update no longer directly produces a WindowsUpdate.log file. Instead, it produces .etl files that aren’t immediately readable as written.

Source: https://learn.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=windowsserver2022-ps&viewFallbackFrom=win10-ps&preserve-view=tru

In case you will run into the following error, we first need to copy the missing SymSrv.dll to the mentioned path.

Copy-Item : Cannot find path ‘C:\Program Files\Windows Defender\SymSrv.dll‘ because it does not exist

Copy SymSrv.dll either from the same machine and following path C:\Windows\WinSxS\ or from another Windows Server 2016 where Defender wasn’t removed.

The PowerShell module WindowsUpdateLog.psm1, which implements the Get-WindowsUpdateLog cmdlet, contains this line: $SYMSRV_DLL_PATH = “$env:ProgramFiles\Windows Defender\SymSrv.dll”

It then tries to copy that DLL to a working directory: Copy-Item -Path $SYMSRV_DLL_PATH -Destination $WORKDIR -Force -ErrorAction Stop

So if Windows Defender is uninstalled, this path and file no longer exist, and the cmdlet throws an error.

Get-WindowsUpdateLog doesn’t read a live text log. It merges ETL traces from Windows Update (WPP/ETW) and then resolves event IDs/opcodes into human-readable text using debug symbols. For that symbol resolution it loads SymSrv.dll (the Symbol Server client).

Windows Update (WPP/ETW)
ETW (Event Tracing for Windows): A high-performance event logging system built into Windows.
WPP (Windows software trace PreProcessor): A Microsoft framework used by developers to instrument code for ETW.

Windows Update (WPP/ETW) refers to the event tracing providers that Windows Update uses.

On many builds Microsoft ships a copy of SymSrv.dll under
C:\Program Files\Windows Defender\ and the cmdlet’s script expects to copy it from there into its working folder. If Microsoft Defender has been removed, that path doesn’t exist, so the cmdlet throws this error message.

Without SymSrv.dll and access to symbols, the cmdlet can’t translate the trace data into readable lines, so it fails early at the copy step when the Defender-hosted DLL isn’t present.

Why Microsoft did this
This appears to be a design oversight. SymSrv.dll is part of the Debugging Tools for Windows, but Microsoft chose to bundle a copy with Windows Defender and hardcoded its path into the update log generation script. This creates an unnecessary dependency on Defender even when it’s not needed for the system’s security.

Troubleshoot Windows Update Errors

When updates fail, Windows often leaves behind corruption in system files or the update cache. Two of the most effective repair tools are sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth, which scan and repair system files as well as the servicing stack. (About how to update the service stack (SSU) directly to resolve issues related to you will find below).

If problems persist, clearing the Windows Update cache folders (SoftwareDistribution and Catroot2) resets the update sandbox, forcing Windows to rebuild its update state from scratch.

When Windows Update downloads, stages, and prepares updates, it doesn’t touch system files directly.
Instead, it uses a couple of dedicated working folders as a temporary workspace, that’s what’s referred to as the aka update sandbox.

C:\Windows\SoftwareDistribution ==> Stores downloaded update payloads (the .cab / .msu files). Contains the update history database (DataStore.edb). Holds temporary files during the install process.

C:\Windows\System32\catroot2 ==> Stores cryptographic signatures and catalog (.cat) files used to verify update packages. Critical for ensuring integrity before updates are applied.

Together, these steps plus manual update of the the Servicing Stack Update (SSU) directly and shown below, form a reliable toolkit for troubleshooting most update-related errors.

!! Note !!
When you rename/delete SoftwareDistribution, the DataStore.edb is removed as well as mentioned. Nevertheless it does not remove the update history shown in “View update history” in Settings as mentioned in diverse articles on the web. That history is stored elsewhere (in the Windows Registry and system logs).

Windows Update will simply rebuild a fresh DataStore.edb going forward.

This database is using an Extensible Storage Engine (ESE) database (aka Jet Blue or .edb file). The same engine used by things like Active Directory and Windows Search.

In case of curiosity, we can use the SEDatabaseView (NirSoft, free) utility to open and see the content of this database.

!! Note !!
Editing this DB directly is a bad idea → it can corrupt Windows Update.

Repair servicing (CBS) & component store

Before repairing by using the /RestoreHealth flag, we can also first check the health by using the following flags

# Performs a more thorough scan of the component store to detect corruption. Slower than /CheckHealth  below (can take several minutes).
DISM /Online /Cleanup-Image /ScanHealth


# Performs a quick check to see if there’s any corruption in the Windows component store and whether it is repairable. Very fast (usually takes a few seconds).
DISM /Online /Cleanup-Image /CheckHealth

To scan and repair the Windows image (i.e., the files that make up your running Windows installation) we can run the command by using the /RestoreHealth flag. May require a reboot, but won’t restart by itself.

The sfc /scannow command scans all protected system files, if corruption is found, it attempts to repair by pulling clean copies from the component store. If files are in use and can’t be repaired while Windows is running, it marks them for replacement at the next reboot.

DISM /Online  /Cleanup-Image /RestoreHealth
sfc /scannow

Check CBS.log under C:\Windows\Logs\CBS\CBS.log for issues.

Clear WU working folders (resets the “update sandbox”)

net stop wuauserv
net stop bits
net stop cryptsvc
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start cryptsvc
net start bits
net start wuauserv

Then try the installation of failed updates again from Settings or by using the usoclient directly:

# Installs updates that have already been downloaded.
> usoclient StartInstall

Modern versions of Windows use the Update Session Orchestrator (USO) service to handle Windows Update tasks in the background.

The usoclient.exe tool lets you interact with this service from the command line. One of its useful switches is StartInstall, which forces the installation of already downloaded updates.

While it’s mainly designed for internal system calls, admins sometimes use it for testing or scripting to kick off pending update installations without waiting for Windows to do it automatically.

Common usoclient.exe commands. Run from an elevated Command Prompt (Admin):

# Forces Windows to check for new updates.
> usoclient StartScan

# Starts downloading available updates.
> usoclient StartDownload

# Scans, downloads, and installs updates, then waits for completion (often used in scripts).
> usoclient ScanInstallWait

# Re-reads update settings (like Group Policy changes) without requiring a reboot.
> usoclient RefreshSettings

# Resumes an update installation after a reboot
> usoclient ResumeUpdate

# Kicks off an update scan with UI prompts (deprecated in newer builds).
> usoclient StartInteractiveScan

Note: On Windows 10 build 1903+ and Windows 11, Microsoft has locked down most UsoClient switches, they often do nothing or are intended only for system calls. The recommended replacement for scripted control is the Windows Update PowerShell module (PSWindowsUpdate).

Windows Update Agent (wuauserv) Service stuck at Stopping

If this keeps happening, it often points to servicing stack corruption or a broken pending update. In that case, manually installing the latest SSU (Servicing Stack Update) can help.

Starting in February 2021, the cumulative update includes the latest servicing stack updates, providing a single combined cumulative update payload for Windows Update, Windows Server Update Services (WSUS), and the Microsoft Update Catalog. 

Source: https://learn.microsoft.com/en-us/windows/deployment/update/servicing-stack-updates

You will still find single SSU (Servicing Stack Update) using the Microsoft Update Catalog for Windows 10, Windows Server 2012, Windows Server 2016 and Windows Server 2019.

There is currently no separate standalone Servicing Stack Update (SSU) for Windows Server 2022 or Windows Server 2025 available from Microsoft.

If the SSU is only partially broken (e.g. Windows Update is stuck, but WUSA or DISM still functions), then try to manual install the latest cumulative update (LCU) by running wusa.exe Windows10.0-KB<LCU-ID>.msu /quiet /norestart.

Run the following command (just works by using the CMD) to determine the PID of the stuck Windows Update Service (wuauserv).

> sc queryex wuauserv

To finally terminate the stuck process we can run the taskkill command below by specifying the PID of the stuck service.

> taskkill /PID <pid number stuck service> /F
> taskkill /PID 9132 /F

Download the latest SSU (Servicing Stack Update) from the Microsoft Update Catalog and install it by using the WUSA utility (Windows Update Stand Alone)

In my case here a Windows Server 2016 is affected and therefore I will first search for the latest SSU KB number for W2K16 by doing a web search for.

KB5062799 — Servicing Stack Update for Windows Server 2016 for x64-based Systems, released on July 8, 2025

We can access the Microsoft Update Catalog through the following URL https://www.catalog.update.microsoft.com.

Run the WUSA utility (Windows Update Stand Alone) to update the SSU. Afterwards first reboot the machine to see if the Windows Update Agent now can be stopped, started and restarted.

PS> wusa.exe .\windows10.0-kb5062799-x64_4be9f25384d92da06806aee618883cf4f3b09048.msu /quiet /norestart
PS> Get-HotFix -Id KB5062799

Updating the SSU (Servicing Stack Update) on Windows typically does not force a reboot.
SSUs update the Windows Update infrastructure itself, not core OS components.

To be safe also afterwards first clear the WU working folders (resets the “sandbox”) before trying to update the machine.

net stop bits
net stop cryptsvc
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start wuauserv
net start bits
net start cryptsvc
net start msiserver

To check which Servicing Stack Updates (SSUs) are already installed on the system, we can also run the following PowerShell cmdlet.

Get-HotFix | Where-Object { $_.Description -like "*Servicing Stack*" -or $_.HotFixID -match "KB\d+" } | Sort-Object InstalledOn -Descending | Select-Object HotFixID, Description, InstalledOn

Newer builds (Win 11 / Server 2022+), some cumulative updates already include the SSU. In those cases, the SSU may not appear as a separate entry but is still integrated, Microsoft moved toward “LCU + SSU combined packages”. So depending on OS version, you might see:
Separate SSUs (older model, e.g., W2K16, W2K19 early builds).
Only LCUs (with SSU bundled inside) on newer versions.

Windows Update vs. Microsoft Update 

At the February 2005 RSA Conference, Microsoft announced the first beta of Microsoft Update, an optional replacement for Windows Update that provides security patches, service packs and other updates for both Windows and other Microsoft software.

The initial release in June 2005 provided support for Microsoft Office 2003, Exchange 2003, and SQL Server 2000, running on Windows 2000, XP, and Server 2003. Over time, the list has expanded to include other Microsoft products.

Office Update is a free online service that allows users to detect and install updates for certain Microsoft Office products. The original update service supported Office 2000, Office XP, Office 2003 and Office 2007.

On 1 August 2009, Microsoft decommissioned the Office Update service, merging it with Microsoft Update. 

Microsoft Update supported all versions of Microsoft Office up to Office 2007 and later; however, it does not support Office 2000.

Source: https://en.wikipedia.org/wiki/Windows_Update

Enable Microsoft Update 

By default when “Receive updates for other Microsoft products when you update Windows” is set to Off, like shown below, no default value is set in the registry for registered update services like Windows Update or Microsoft Update, so just Windows Update will be used to update the OS.

!! Note !!
This option/setting finally just kick in when using Microsoft’s public endpoints for Updates like update.microsoft.com and not for other update sources like WSUS server. Also when using Azure Update Manager like shown in my following post, it finally depends on the update source which is configured on the machines, for Azure virtual machines we can also use Azure Update Manager by using an on-prem WSUS server as update source.

For WSUS server or 3rd-party update systems, this setting/option will have no impact and the update categories which will finally be find and applied by the machines, are purely defined on the WSUS server or 3rd-party update systems.

When pressing the toggle button to enable “Receive updates for other Microsoft products when you update Windows”, the registry key for Microsoft Update will be set as default service for registered update services and also updates for other Microsoft products like SQL Server and Office will be downloaded and installed.

On a server where SQL server 2019 is installed, after enabling “Receive updates for other Microsoft products when you update Windows”, the local Windows Update Agent (WUA) on the OS will now also download and install SQL server updates.

As already mentioned just when using Microsoft’s public endpoints for Updates like update.microsoft.com.

Enable Microsoft Updates by using PowerShell

In case the toggle button “Receive updates for other Microsoft products when you update Windows” is greyed out, we can also enable Microsoft Updates by using PowerShell.

# Enable Microsoft Update service
$ServiceManager = New-Object -ComObject Microsoft.Update.ServiceManager
$ServiceManager.AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"")

Different Update Categories Microsoft provide

Microsoft generally categorizes updates into a few distinct types, each with a different purpose, release cycle, and impact.

• Security (Quality) Updates
  • Purpose: Fix security vulnerabilities and sometimes include stability/reliability improvements.
  • Frequency: Released on Patch Tuesday (second Tuesday of each month), or as out-of-band patches for critical zero-day exploits.
  • Key traits:
    • Cumulative (includes fixes from all previous security updates for that OS build).
    • No new features – strictly security and quality fixes.

• Cumulative Updates (CU)
  • Purpose: General category for monthly rollups that can include:
    • Security fixes
    • Bug fixes
    • Reliability improvements
  • Frequency: Usually monthly (Patch Tuesday), plus optional “Preview” releases late in the month.
  • Key traits
    • Include all prior fixes for that branch/build.
    • Can be Security-only or Security + Quality.

• Servicing Stack Updates (SSU)
  • Purpose: Update the Windows Update servicing stack (the code that installs Windows updates) to make future updates install correctly.
  • Frequency: Released as needed, sometimes bundled with CUs.
  • Key traits:
    • Required before certain CUs can be applied.
    • Small in size.

• Feature Updates
  • Purpose: Introduce new Windows features, UI changes, and large OS revisions (e.g., Windows 10 21H2 → 22H2).
  • Frequency: Once or twice a year (Windows 10/11) or at major milestones (Server editions).
  • Key traits:
    • Essentially an in-place OS upgrade.
    • Much larger download (~3–5 GB).
    • Can change the OS build number significantly.

• Optional Updates
  • Purpose: Non-security fixes (drivers, preview builds, optional patches).
  • Frequency: Anytime, often released near the end of a month as “C” or “D” releases.
  • Key traits:
    • Optional via Windows Update (“Download and install”).
    • Useful for early testing of next month’s fixes.

• Out-of-Band (OOB) Updates
  • Purpose: Emergency fixes for critical vulnerabilities or bugs that can’t wait for Patch Tuesday.
  • Frequency: Ad-hoc.
  • Key traits:
    • Released outside the normal update cycle.
    • Typically security-related, but can also be to fix major service outages.

• Definition Updates
  • Purpose: Update malware signatures for Microsoft Defender Antivirus and other security products.
  • Frequency: Multiple times a day.
  • Key traits:
    • Small in size.
    • Keeps protection up to date.

• Driver & Firmware Updates
  • Purpose: Provide hardware-specific improvements from OEMs (via Windows Update).
  • Frequency: As hardware vendors release them.
  • Key traits:
    • Optional unless marked critical.
    • Can affect stability/performance.

What is the Servicing Stack Update (SSU)?

A Servicing Stack Update (SSU) is basically Microsoft’s way of patching the plumbing that Windows uses to install other updates, and it’s a bit more than just a single service.

It includes multiple core servicing components that have to work together whenever you install, uninstall, or verify updates.

Windows Update Agent (WUA – wuauserv)

The Windows Update Agent (WUA) is basically the brain and API layer of the Windows updating system, it’s what actually knows how to talk to Microsoft’s update servers (or WSUS), decide what applies to your machine, and hand those updates off to the servicing stack for installation.

• Role: The main Windows Update service.
• What SSU touches:
  • Improves how it talks to Windows Update servers and WSUS.
  • Fixes bugs in update metadata parsing and applicability checks.
  • Adjusts logic for update ordering and dependencies.
• Why it matters: If wuauserv miscalculates prerequisites or can’t parse metadata correctly, later CUs can fail with cryptic errors.

Component-Based Servicing (CBS)

The Component-Based Servicing (CBS) system is the core engine that actually installs, removes, and maintains Windows components and updates.

If WUA (Windows Update Agent) is the dispatcher, then the CBS is the mechanic doing the actual work.

• Role: The CBS engine (TrustedInstaller service + cbs.dll) is responsible for:
  • Staging updates into the WinSxS store.
  • Managing installation order for individual OS components.
  • Handling rollbacks if updates fail.
• What SSU touches:
  • Fixes in the CBS transaction manager (so updates don’t get stuck in “pending”).
  • Improvements to component versioning logic.
  • Patching the manifest and catalog parsing code.
• Why it matters: Every CU is just a bundle of CBS packages; if CBS is broken, nothing installs, even manually.

Deployment Image Servicing and Management (DISM)

• Role: DISM is the tool and API for managing Windows images (online or offline).
• What SSU touches:
  • Updates DISM binaries and libraries to support new update types.
  • Improves repair commands (/RestoreHealth, /ScanHealth) so they work with new component store formats.
• Why it matters: A newer CU might require DISM to understand new payload formats, or /RestoreHealth might fail.

Catroot and Catroot2 in SSU context

• Location:
  • C:\Windows\System32\Catroot
  • C:\Windows\System32\Catroot2
• Purpose:
  These folders store cryptographic catalog files (.cat) that Windows uses to:
  • Verify the digital signatures of update packages.
  • Maintain a database of trusted catalog hashes for system files and updates.
  • Record which update components have been validated.
• Difference between Catroot & Catroot2:
  • Catroot: More static, system-level catalogs (often for base OS components).
  • Catroot2: Dynamic, regenerated by Windows Update when validating new updates.
• SSU Role:
  • Updates the cryptographic services (CryptSvc) and catalog handling libraries used by CBS/WUA.
  • Adds support for new signing algorithms (e.g., SHA-2).
  • Ensures catalogs for new updates are stored/validated correctly.
  • Sometimes introduces fixes so Catroot2 can rebuild cleanly if corruption occurs (avoiding the “0x800B0109 / signature verification failed” errors).
• When corrupted:
  • Update installs fail with signature errors.
  • Fix often involves stopping CryptSvc, renaming Catroot2, and letting it rebuild.

More about Servicing stack updates you will also find here https://learn.microsoft.com/en-us/windows/deployment/update/servicing-stack-updates.

WinSxS store

The WinSxS store (short for Windows Side-by-Side) living under C:\Windows\WinSxS is a folder in Windows operating systems that stores multiple versions of system files, libraries, and components.

Side-by-Side Storage: It allows multiple versions of the same DLL or system file to exist simultaneously. When an application needs a specific version, Windows can direct it to the correct file within the WinSxS store without affecting other applications.

Component Store: It acts as a central repository for all Windows components. When you install updates or new features, the required files are placed in WinSxS. This allows Windows to install, uninstall, and repair components without needing the original installation media.

Servicing: Required for Windows Update, DISM, and other servicing operations.

The WinSxS folder often appears very large because of the way the operating system links to files. Windows uses a technique called hard linking, where a single file on the disk can have multiple “pointers” to it.

• The files you see in the C:\Windows\System32 directory are often hard links that point back to the actual files stored in the WinSxS folder.
• When you look at the properties of the C:\Windows\WinSxS folder, the size shown includes the size of the hard-linked files. It’s not a true measure of the disk space consumed, as a file isn’t duplicated for each link.

Windows includes tools like the Deployment Image Servicing and Management (DISM) command-line tool to help manage and clean up the WinSxS store by removing old, unused versions of files.

In Part 2 we will troubleshoot Azure virtual machines they will either stuck during updates or just looking like stuck and how to determine and solve it.

We will also take a look at the Extended Security Update (ESU) program and some troubleshooting about, further will see different methods to determine the installed SQL server version on Windows.

Links

Windows deployment documentation
https://learn.microsoft.com/en-us/windows/deployment/

Deploy Windows client updates using Windows Server Update Services (WSUS)
https://learn.microsoft.com/en-us/windows/deployment/update/waas-manage-updates-wsus

Manage device restarts after updates
https://learn.microsoft.com/en-us/windows/deployment/update/waas-restart

Manage additional Windows Update settings
https://learn.microsoft.com/en-us/windows/deployment/update/waas-wu-settings

Windows Update: FAQ
https://support.microsoft.com/en-us/windows/windows-update-faq-8a903416-6f45-0718-f5c7-375e92dddeb2

Understanding Component-Based Servicing
https://techcommunity.microsoft.com/blog/askperf/understanding-component-based-servicing/373012

Lifecycle FAQ – Extended Security Updates
https://learn.microsoft.com/en-us/lifecycle/faq/extended-security-updates