Why Azure Update Manager Doesn't Patch .NET or SQL Server on Your Windows Server VMs // XLT1

Defender for Cloud is flagging .NET, SQL Server, and PowerShell CVEs on your Windows Server VMs but Azure Update Manager says they're up to date? Here's the cause and the one-line fix.

TL;DR

Windows Server SKUs ship with the Windows Update service registered with the Automatic Updates agent — but not Microsoft Update, which is the channel that delivers .NET, SQL Server CU, SSMS, and PowerShell 7 updates. Until you opt in (via a one-line COM call), neither WUA nor Azure Update Manager can see those updates exist. The fix is safe, doesn’t install anything by itself, doesn’t reboot, and should be baked into every Windows Server VM build.

The issue

You’re doing a routine Defender for Cloud review. Your Windows Server 2022 VM has patchMode: AutomaticByPlatform. Azure Update Manager’s dashboard reports it as healthy. But Defender for Cloud is flagging vulnerability findings against:

.NET 8.0.x (CVE-2025-21176)
SQL Server 2022 (a cumulative update CVE)
SQL Server Management Studio (SSMS)
PowerShell 7.5.x

You log into the VM, open Settings → Windows Update, and it says “You’re up to date.” You run a manual scan via PowerShell. Still only Defender signatures pending. The findings in Defender for Cloud sit there for weeks. You start to wonder if Defender’s wrong, or if Azure Update Manager (AUM) is broken, or if there’s some maintenance configuration you forgot to attach.

None of those. What’s actually happening is that the Windows Update Agent (WUA) on your VM cannot see those updates exist, because the update source that ships them — Microsoft Update — is not registered with the agent.

How you’d notice it:

Defender for Cloud findings for .NET, SQL Server, SSMS, or PowerShell that won’t resolve no matter how many maintenance windows pass.
Azure Update Manager assessment shows the VM is current.
Manual WUA scans return only Defender signature updates.
The Settings UI on the VM says you’re up to date.

What’s actually going on under the hood:

WUA can register multiple update services with the Automatic Updates agent. The two that matter here:

Service	What it ships	Default on Windows Server?
Windows Update (`9482f4b4-e343-43b6-b170-9a65bc822c77`)	Windows OS, kernel, drivers, Defender signatures	Registered
Microsoft Update (`7971f918-a847-4430-9279-4a52d1efe18d`)	.NET runtime, SQL Server CUs, SSMS, ASP.NET Core, PowerShell 7 (sometimes), Visual Studio runtimes, OneDrive client	NOT registered

On Windows client SKUs (Windows 10/11), Microsoft Update is registered by default — the “Receive updates for other Microsoft products” toggle in Settings is usually flipped on. On Windows Server SKUs, it’s not. Microsoft’s stated rationale: server admins should explicitly choose their update sources rather than have SQL Server CUs surprise-installed on a fresh build.

The practical result: every fresh Windows Server VM in Azure starts life unable to see updates for any Microsoft product other than the OS itself. And because AUM is a layer on top of WUA — it consumes the same scan results — the gap is invisible until you correlate Defender’s findings with what WUA actually reports.

You can confirm the state in one command:

(New-Object -ComObject Microsoft.Update.ServiceManager).Services |
  Select-Object Name, ServiceID, IsRegisteredWithAU, IsDefaultAUService |
  Format-Table -AutoSize

If you see this — and on a fresh Windows Server VM you almost certainly will — you’ve found the gap:

Name              ServiceID                            IsRegisteredWithAU IsDefaultAUService
----              ---------                            ------------------ ------------------
Microsoft Update  7971f918-a847-4430-9279-4a52d1efe18d              False              False
Windows Update    9482f4b4-e343-43b6-b170-9a65bc822c77               True               True

Options considered

When you confirm this is the issue, several remediations look plausible. They’re not equivalent — most of them don’t actually solve the discovery problem.

Option A — Register Microsoft Update with WUA via the COM API

What it is: Call IUpdateServiceManager.AddService2 with the Microsoft Update service ID. One line of PowerShell. This is the programmatic equivalent of toggling “Receive updates for other Microsoft products” ON in the Settings GUI.
Pros: Safe, no install, no reboot. Works on every Windows Server SKU. Composable with any existing patch workflow (AUM-managed install, manual monthly windows, whatever). Bakeable into provisioning (Bicep CSE / Custom Script Extension).
Cons: Has to be applied per-VM. Not surfaced in any obvious Azure-side UI — feels like arcane WUA plumbing.
Right for: Every Windows Server VM, full stop. This is the systemic fix.

Option B — Manually download and install each missing patch from the Microsoft Update Catalog

What it is: Browse the Microsoft Update Catalog, download MSU/MSI installers for each flagged CVE, install on each VM.
Pros: Works without changing WUA configuration.
Cons: Tedious. Doesn’t fix the underlying gap — next month’s .NET or SQL CU will be invisible again. Doesn’t scale to a fleet.
Right for: A one-off if you’re not allowed to change WUA registration for policy reasons.

Option C — Change `patchMode` away from `AutomaticByPlatform`

What it is: Switch the VM’s Azure-side patch settings to Manual or AutomaticByOS.
Pros: None for this problem.
Cons: Doesn’t help. patchMode controls orchestration (who decides when to install), not discovery (what WUA can see). The Microsoft Update channel is still unregistered regardless.
Right for: Nothing related to this issue. Don’t do this.

Option D — Attach an Azure Update Manager maintenance configuration

What it is: Use AUM to schedule automated installs against the VM.
Pros: Useful if you want Azure to schedule patches for you instead of doing manual monthly windows.
Cons: Same as Option C — it changes who runs the install, not what WUA can see. If Microsoft Update isn’t registered, AUM has nothing new to install.
Right for: A separate, complementary decision after you’ve fixed the discovery gap. Not a fix for this problem.

Option E — Use Hotpatch instead

What it is: Enable enableHotpatching on supported Windows Server SKUs (Server 2022 Azure Edition, Server 2025) so OS security patches apply without reboots.
Pros: Real wins on OS-level patches and reboot frequency.
Cons: Different problem entirely. Hotpatch covers Windows OS security only — it doesn’t change anything about .NET, SQL CU, or other Microsoft Update territory. Also requires specific SKUs that most existing fleets aren’t on.
Right for: New VM builds on supported SKUs. Stacks on top of Option A; it doesn’t replace it.

Option F — Set the `EnableFeaturedSoftware` registry value

What it is: Set HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\EnableFeaturedSoftware = 1.
Pros: This is the client-SKU equivalent toggle.
Cons: Does not work on Windows Server. The registry value alone doesn’t register the Microsoft Update service with the Automatic Updates agent on Server SKUs. You’ll see the registry value flip but the WUA service registration won’t change — and your CVEs will still be invisible. A common dead-end.
Right for: Windows client SKUs only. Skip this on Server.

Why we chose Option A

A is the only option that actually solves the discovery problem at a systemic level, is safe to apply immediately (no install, no reboot), and is composable with whatever install workflow you already use. The COM call is part of the official WUA SDK; the API has been stable for years; the change is idempotent (re-running on an already-registered service is a no-op). The only real cost is that it has to be applied per VM — which is a one-liner via az vm run-command for existing VMs, and a Custom Script Extension for new ones.

The fix

1. Check current state

(New-Object -ComObject Microsoft.Update.ServiceManager).Services |
  Select-Object Name, ServiceID, IsRegisteredWithAU, IsDefaultAUService |
  Format-Table -AutoSize

If Microsoft Update shows IsRegisteredWithAU = False (or the row is missing entirely), the VM is opted out.

2. Register Microsoft Update

$mgr = New-Object -ComObject Microsoft.Update.ServiceManager
$mgr.AddService2('7971f918-a847-4430-9279-4a52d1efe18d', 7, '') | Out-Null

Parameter notes:

7971f918-a847-4430-9279-4a52d1efe18d — fixed ServiceID for Microsoft Update.
7 — bitmask flags: AddServiceFlag.AsDefaultAUService | AllowPendingRegistration | RegisterServiceWithAU (1 + 2 + 4).
'' — authorization cab. Empty for Microsoft Update; only used for third-party services.

This is safe to run during business hours. It does not download or install anything. It does not reboot. The next WUA scan will simply have a wider catalog to compare against.

3. Verify and re-scan

(New-Object -ComObject Microsoft.Update.ServiceManager).Services |
  Where-Object ServiceID -eq '7971f918-a847-4430-9279-4a52d1efe18d' |
  Format-List Name, IsRegisteredWithAU, IsDefaultAUService

$searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher()
$searcher.ServiceID       = '7971f918-a847-4430-9279-4a52d1efe18d'
$searcher.ServerSelection = 3   # ssOthers — requires ServiceID to be set
$result = $searcher.Search("IsInstalled=0 and Type='Software' and IsHidden=0")

"Found $($result.Updates.Count) pending updates from Microsoft Update"
$result.Updates | ForEach-Object {
  [pscustomobject]@{
    Title        = $_.Title
    KB           = ($_.KBArticleIDs -join ',')
    MsrcSeverity = $_.MsrcSeverity
    Size_MB      = [math]::Round($_.MaxDownloadSize / 1MB, 1)
  }
} | Format-Table -AutoSize -Wrap

You should see IsRegisteredWithAU = True and IsDefaultAUService = True. The second block scans Microsoft Update specifically and prints whatever was hidden from you before. On a VM that’s been running for a while you may see months of backlog — that’s visibility, not new exposure.

A common gotcha: after opt-in, the Windows Update entry will flip to IsRegisteredWithAU = False. This is correct, by design. Microsoft Update is a superset of Windows Update — same OS content plus the other Microsoft products — so AU only needs one registered source.

4. (Existing fleet) Apply remotely with no RDP

az vm run-command invoke -g <rg> -n <vm> \
  --command-id RunPowerShellScript \
  --scripts '(New-Object -ComObject Microsoft.Update.ServiceManager).AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"") | Out-Null'

Loop over your inventory:

az vm list -d \
  --query "[?powerState=='VM running' && storageProfile.osDisk.osType=='Windows'].{name:name, rg:resourceGroup}" \
  -o tsv |
while read -r name rg; do
  echo "== $rg / $name =="
  az vm run-command invoke -g "$rg" -n "$name" \
    --command-id RunPowerShellScript \
    --scripts '(New-Object -ComObject Microsoft.Update.ServiceManager).Services | Where-Object ServiceID -eq "7971f918-a847-4430-9279-4a52d1efe18d" | Select-Object Name, IsRegisteredWithAU | Format-List' \
    --query "value[0].message" -o tsv
done

5. (New builds) Bake into provisioning

Add a Custom Script Extension to your Windows Server VM Bicep module:

resource msUpdateOptIn 'Microsoft.Compute/virtualMachines/extensions@2023-09-01' = {
  parent: vm
  name: 'EnableMicrosoftUpdate'
  location: location
  properties: {
    publisher: 'Microsoft.Compute'
    type: 'CustomScriptExtension'
    typeHandlerVersion: '1.10'
    autoUpgradeMinorVersion: true
    settings: {
      commandToExecute: 'powershell -ExecutionPolicy Bypass -Command "(New-Object -ComObject Microsoft.Update.ServiceManager).AddService2(\'7971f918-a847-4430-9279-4a52d1efe18d\',7,\'\') | Out-Null"'
    }
  }
}

Idempotent — re-running on an already-registered service is a no-op, so the extension is safe to keep deployed across redeploys.

What this does NOT fix

OpenSSL CVEs. Windows doesn’t ship OpenSSL directly — it always arrives vendored inside a third-party tool (Git for Windows, the Self-hosted Integration Runtime, the On-prem Data Gateway, etc.). Those need their own update path.
Java library CVEs (log4j etc.). No Microsoft channel covers Java libraries — whichever app bundled the library has to ship a refreshed build.
Microsoft Edge. Has its own auto-update channel; check that the edgeupdate and edgeupdatem services are running.
Third-party software (Chrome, Firefox, vendor agents, etc.) — their own update mechanisms.

Future considerations — what Microsoft could do better

The fact that every fresh Azure Marketplace Windows Server image ships with this gap, and that every customer either knows this trick or carries a permanent invisible vulnerability surface, is bad posture-by-default in 2026. Three concrete improvements Microsoft could ship:

Default Microsoft Update to ON for Azure Marketplace Windows Server images. The original “server admins should choose their update sources” rationale predates managed cloud VMs by a decade. Azure VMs are by definition on the modern cloud-managed track; an admin who explicitly wants to opt back out can do so.
Have Azure Update Manager register Microsoft Update automatically when it’s enabled on a VM. AUM already does platform-level orchestration; it’s the natural place to ensure WUA’s discovery surface matches what AUM is supposed to manage.
Surface the opt-in state in Azure Update Manager’s assessment view. Right now you have to inspect WUA via PowerShell on each VM to know whether the discovery channel is even open. AUM should display “Microsoft Update: Not registered” as a configuration warning at the VM level. As-is, AUM is silently incomplete.

Until any of those happen, treat the opt-in as a mandatory build-runbook step on every new Windows Server VM. Add the CSE to your Bicep, add the verification check to your VM audit checklist, and circle back to your existing fleet with the az vm run-command loop above.

Why Azure Update Manager Doesn't Patch .NET or SQL Server on Your Windows Server VMs