windows/servercore:ltsc2025: in-container Windows Update activity bloats sandbox.vhdx

Describe the bug
The image mcr.microsoft.com/windows/servercore:ltsc2025 ships with the registry policy HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\AUOptions = 3 baked into the image. Per Microsoft documentation this value means "Auto download and notify for install" (reference). As a result, containers based on this image (and on derived images such as mcr.microsoft.com/dotnet/framework/aspnet:*-ltsc2025) actively run Windows Update internally: they scan and download cumulative updates from Microsoft's update servers.

Because the writable layer (sandbox.vhdx) is dynamic and monotonically growing, the disk space consumed by these in-container updates is never reclaimed and accumulates on the host. In our environment one container's sandbox.vhdx grew from ~250 MB (fresh) to ~9 GB after one Patch Tuesday cycle, exhausting the host disk. In my infrastructure about 40 containers affected across multiple hosts, ~200 GB of waste.

To Reproduce

1. Verify the policy is present in the unmodified image:
   docker run --rm mcr.microsoft.com/windows/servercore:ltsc2025 powershell -Command "Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU'"
   Output:

AUOptions    : 3
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\
               Policies\Microsoft\Windows\WindowsUpdate\AU
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\
               Policies\Microsoft\Windows\WindowsUpdate
PSChildName  : AU
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

2. Build any minimal image FROM mcr.microsoft.com/windows/servercore:ltsc2025 that does not modify Windows Update related settings.
3. Run a container with internet access across a Patch Tuesday with a relevant update available.
4. Inside the container, check the WU log: Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 30
   Sample log from inside an unmodified container running on windows/servercore:ltsc2025:

 TimeCreated            Id  Msg
 4/19/2026 11:57:18 PM  26  Windows Update successfully found 2 updates.
 4/18/2026 3:57:04 AM   26  Windows Update successfully found 2 updates.
 4/17/2026 11:07:29 AM  41  An update was downloaded.
 4/17/2026 10:59:03 AM  41  An update was downloaded.
 4/17/2026 5:56:56 AM   26  Windows Update successfully found 2 updates.
 4/16/2026 7:56:48 AM   26  Windows Update successfully found 2 updates.
 4/14/2026 11:56:33 AM  26  Windows Update successfully found 1 updates.
 4/13/2026 1:56:24 PM   26  Windows Update successfully found 1 updates.
 ... (daily scans going back further) ...

5. On the host, observe {docker-data-root}\windowsfilter\{container-id}\sandbox.vhdx grow by several GB.

The Event 41 entries on 2026-04-17 are actual update payloads pulled into the container. April 2026 Patch Tuesday delivered KB5082063 and KB5082417 (.NET Framework 4.8.1 servicing). The host disk usage spike that triggered our investigation matches these timestamps.

Expected behavior
Per Microsoft's documented servicing model for containers (rebuild and pull a new base image monthly), containers based on this image should not be silently downloading updates from Microsoft's update servers and consuming gigabytes in the writable layer that the consumer of the image did not opt into and is not made aware of.

Configuration:

• Edition: Microsoft Windows Server 2025 Standard 10.0.26100 N/A Build 26100
• Base Image being used: mcr.microsoft.com/windows/servercore:ltsc2025, digest sha256:83374b6927f7945bb0933d03f158f84b03182017e2694fa23aedd24ea51434e4
• Container engine: Docker CE
• Container Engine version:

Client:
 Version:           29.3.0
 API version:       1.54
 Go version:        go1.25.7
 Git commit:        5927d80
 Built:             Thu Mar  5 14:28:30 2026
 OS/Arch:           windows/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.3.0
  API version:      1.54 (minimum version 1.40)
  Go version:       go1.25.7
  Git commit:       83bca512
  Built:            Thu Mar  5 14:25:24 2026
  OS/Arch:          windows/amd64
  Experimental:     false

• Container isolation: process
• Affected images also include: mcr.microsoft.com/dotnet/framework/aspnet:4.8.1-windowsservercore-ltsc2025

Additional context
System log inside the container shows wuauserv started and stopped cyclically (~once per hour) over many days (Event 7036), consistent with UsoSvc (Update Orchestrator) waking it on the schedule implied by AUOptions=3.

Start by reproducing the registry policy with the shown docker run PowerShell command, then inspect Windows Update Operational events and sandbox.vhdx growth during a Patch Tuesday cycle. Compare the servercore:ltsc2025 behavior with Microsoft's documented container servicing model. Done means the image no longer causes unintentional in-container update downloads and the writable layer does not accumulate those payloads.