Windows - Configuration - Restrict Bandwidth for Windows Updates

What the Windows Update bandwidth cap Worklet does

This Automox Worklet™ caps Windows Update download bandwidth on Windows endpoints by writing two Delivery Optimization policy values to the registry. The Worklet sets a maximum background download rate and a maximum foreground download rate in kilobits per second (Kbps), then verifies both values on every subsequent evaluation.

The two policy values live under HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization. The Worklet writes DOMaxBackgroundDownloadBandwidth for transfers that happen while the endpoint is idle or running other work, and DOMaxForegroundDownloadBandwidth for transfers initiated by an active user session. Both are stored as DWORD values; the scripts convert the Kbps input to the internal unit before writing (multiply by 0.128). Setting either input variable to 0 hands the decision back to Windows for dynamic adjustment.

Default values in the shipped Worklet are 1000 Kbps (1 Mbps) for background and 500 Kbps (0.5 Mbps) for foreground. Both are policy variables in the Worklet body. Set them to the values your network team has approved before deployment. The remediation script prints the applied Kbps values to the Automox activity log on each successful run.

These two registry values are the modern Delivery Optimization replacement for the legacy PercentageMaxForegroundBandwidth and PercentageMaxBackgroundBandwidth percentage-based controls. Prefer the absolute Kbps form. It produces predictable behavior on the mixed link speeds a fleet of laptops actually sees in the field.

Why cap Windows Update bandwidth at the endpoint

Uncapped Windows Update traffic competes with business-critical applications on constrained network links. Feature updates can run several gigabytes, and Delivery Optimization transfers aggressively on any connection Windows treats as fast. On branch-office circuits, VPN connections, or shared WAN links, that behavior affects application performance during active update cycles. The two registry values this Worklet enforces are the documented Microsoft policy surface for capping those transfers. Both directions are bounded on every endpoint the policy targets.

The bandwidth caps under HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization can be set through Group Policy on domain-joined endpoints, but that path does not reach Entra-joined or Intune-managed endpoints that are offline, or endpoints where a previous configuration left only partial values. This Worklet enforces the bandwidth baseline against every endpoint under Automox management, regardless of how the registry key was previously written, so a missing or mismatched DWORD is corrected on the next evaluation cycle.

How Windows Update bandwidth enforcement works

1. Evaluation phase: The Worklet runs Test-Path against HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization and checks for each value with Get-ItemProperty. If the path is missing or either value is absent, the endpoint exits 1 immediately. Otherwise, the script reads both DWORDs with Get-ItemPropertyValue and compares them against the converted target. A mismatch exits 1 and flags the endpoint for remediation; a match exits 0 as compliant.

2. Remediation phase: The Worklet creates the registry path with New-Item when it does not exist, then writes DOMaxBackgroundDownloadBandwidth and DOMaxForegroundDownloadBandwidth using New-ItemProperty -PropertyType DWord (or Set-ItemProperty when the path already exists). The Worklet prints the applied Kbps values to the activity log via Write-Output and exits 0 on success. A catch block exits 1 with a failure message when the registry write fails.

Windows Update bandwidth policy requirements

• Windows 10 version 2004 or later, or Windows 11 (Delivery Optimization Kbps policies are honored on Pro, Enterprise, Education, and Server SKUs)

• PowerShell 4.0 or later (the Automox agent context already meets this on every supported Windows build)

• Local administrator rights to write under HKLM (the Automox agent runs as SYSTEM, which satisfies this without elevation prompts)

• Set the desired background Kbps cap and foreground Kbps cap as policy variables in the Worklet body before scheduling; the defaults are 1000 Kbps background and 500 Kbps foreground

• If your environment already configures Delivery Optimization through Group Policy or Intune, retire the conflicting policy first; the last writer on the registry path wins

• A value of 0 in either variable yields Windows-managed dynamic bandwidth on that channel, which is useful when you only want to cap one direction

Expected state after the bandwidth cap is applied

After remediation, every targeted endpoint reports both DOMaxBackgroundDownloadBandwidth and DOMaxForegroundDownloadBandwidth present under HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization with the Kbps values your policy specified. Subsequent Automox runs report the endpoint compliant without re-writing the registry, because the evaluation phase finds the values already correct.

Validate from an elevated PowerShell prompt with Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization' | Select-Object DOMaxBackgroundDownloadBandwidth, DOMaxForegroundDownloadBandwidth. Live behavior is visible in Get-DeliveryOptimizationStatus and Get-DeliveryOptimizationPerfSnap, which expose the negotiated download rate during an active feature or cumulative update. For audit evidence, export the registry key with reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization and store the output with the Automox policy run identifier.

The cap persists across reboots and feature updates as long as the Automox policy remains active. If the registry path is deleted or another configuration channel overwrites the values, the next evaluation detects the missing or mismatched DWORDs against the configured Kbps targets and triggers remediation, which rewrites the values with Set-ItemProperty.