Delivery Optimization says it is peering and your WAN link says otherwise: diagnosing DO before you blame the network

Somebody looks at the WAN graph on the second Tuesday of the month and asks the obvious question. We turned on Delivery Optimization. Why does the circuit still flatline every patch cycle?

The answer is almost never "Delivery Optimization is broken". It is usually that peering never happened, the client fell back to HTTP exactly as designed, and nothing anywhere told you. There is no error. There is no event. There is not even a red icon in Settings.

This post is the diagnostic path. Read the device before you touch policy, because most of the interesting evidence is volatile and the first thing everybody reaches for destroys it.

The problem: DO reports LAN mode and the WAN link disagrees

The shape of the complaint is always the same. Delivery Optimization is configured. Somebody can prove it, because the policy is deployed and the download mode reads back correctly. And the WAN egress on patch day is indistinguishable from the year before anyone configured it.

What makes this failure unusually annoying is that every surface you would normally interrogate is either silent or lying by omission.

Settings tells you nothing useful. The Activity Monitor page under Windows Update, Advanced Options, Delivery Optimization shows a breakdown by source for the current month. That is a real number, but it is one aggregate for the whole device, it has no per-file detail, and it cannot tell you why a source contributed nothing.

There is no Delivery Optimization log in Event Viewer. Not "there are no recent events" - there is no channel. I enumerated every event log and every registered provider on a Windows 11 25H2 device, build 26200.9168:

Read that carefully, because the distinction matters. Two ETW providers are registered. Zero event log channels exist. Providers emit trace events; channels are what Event Viewer and Get-WinEvent -LogName can actually read. Delivery Optimization has the former and not the latter, so there is nowhere in Event Viewer for those events to land.

This is the structural difference from BITS, which most of us learned to triage first. BITS writes an operational channel you can filter, sort and alert on. Delivery Optimization writes ETW traces into its own service-profile log folder and exposes them only through Get-DeliveryOptimizationLog. On the measured device that folder held 510 .etl files totalling 29.34 MB, named in two families - 502 domgmt.* and 8 dosvc.*. None of it is reachable from the Event Viewer console.

And the cmdlet reference is empty. This is the part that turns a solvable problem into folklore. The Microsoft Learn pages for the Delivery Optimization module cmdlets are published but unpopulated - the description field on Get-DeliveryOptimizationStatus and Get-DeliveryOptimizationPerfSnap both read as unfilled template placeholders. The parameter names are there, and the documented output types (DOSwarmStats, DOFilePeerInfo, DOPeerInfo, DOPerfSnap) are real, but there is no prose telling you what any field means.

The on-box help is no better. I checked:

Eighteen working cmdlets, module version 1.0.3.0, and no documentation on the box or on Learn for the two you most need. The field meanings are documented, just not where Get-Help or the cmdlet reference will take you - they live in the conceptual Monitor Delivery Optimization article. That single misplacement is why so much DO advice on the internet is invented.

There is a third reflex worth naming: switching download mode from LAN to Group because "Group is the recommended one". It might well be the right answer. But if you change it before you have measured, you will never know whether the original problem was the mode, the subnet, the file size floor, or a VPN adapter, and you have just committed a fleet-wide policy change on a hunch.

Why it happens: peering is a permission, not a switch

The mental model most people carry is that DO clients find each other. They do not. Microsoft's How Delivery Optimization works article states the principle plainly: the cloud service matches peers, and "Devices don't discover each other directly, except through local peer discovery on Windows 11".

So peering is a three-party negotiation, and any party can quietly decline.

Step one: the client registers, and what it registers decides everything

When a download starts, the client registers with the service and reports content identifiers such as the content URL, a randomly generated device GUID, the device's private IP address and subnet mask, a Group ID string if Group mode is configured and a Group ID is set, a profile bit mask covering platform and SKU and whether the device is a VM, and download attributes such as priority and transfer speeds.

Then the Discovery service points the client at a nearby Array service instance, and the Array service is the component that actually keeps the registry of which devices hold which content and returns the matched peer list. Matching is on three things: ContentID (only devices with the same content are candidates), GroupID (peers must be in the same group), and external IP and geo-location (used to collocate nearby devices).

Which is why a device can be perfectly healthy, on the right subnet, with the right policy, and still get an empty peer list: nobody else on that external IP was downloading that exact content at that time. Peering is a coincidence engine. It needs concurrency.

Step two: the metadata gate, and the silent downgrade

Before any peer transfer, the client fetches a Pieces Hash File. It contains SHA-256 hashes for each piece of the content, pieces are typically 1 MB, it is served from *.dl.delivery.mp.microsoft.com or *.windowsupdate.com, and its own authenticity is verified with a hash obtained over an SSL channel from the DO service.

Here is the sentence that explains a large share of real-world "DO is not peering" tickets:

Read that against a corporate proxy or TLS-inspection deployment. Block or mangle the metadata hosts and every download still succeeds, on time, from the CDN - with peering silently disabled per file. Your download mode still reads 1. Your policy is still correct. And your peer bytes are zero forever. This is the single most common way DO "works" and saves nothing.

The same article is blunt about the fallback in general: "CDN fallback always available - Peer-to-peer is an optimization layer." DO is a reliable HTTP downloader first. Peering is the optional part, and the design intent is that it fails soft.

Step three: the download mode decides the size of the room

Download mode is the coarsest control, and its values are documented in both the Delivery Optimization reference and Policy CSP - DeliveryOptimization.

Step four: five more constraints that disqualify peering without saying so

These are the ones that make a correctly configured fleet peer nothing. Every value below is from the DO reference.

1. Peer selection restriction. DORestrictPeerSelectionBy takes 0 (None), 1 (Subnet mask - restricts discovery to devices in the same subnet) or 2 (Local Peer Discovery via DNS-SD/mDNS). Microsoft states that selecting either 1 or 2 "prevents peer discovery across subnets". And separately: on Windows 11, "Default behavior for LAN (Download Mode 1) restricts peers to the local subnet." So a Windows 11 fleet in LAN mode is already subnet-scoped before you configure anything - which is a much smaller room than "same NAT" implies, and on a Wi-Fi estate with per-floor subnets or client isolation it can be a room of one.
2. Group identity. DOGroupIdSource takes 0 Not set, 1 AD Site, 2 Authenticated domain SID, 3 DHCP Option ID (the client queries DHCP Option ID 234 and uses the returned GUID), 4 DNS Suffix, 5 Entra tenant ID. When neither DOGroupId nor DOGroupIdSource is set, the group is determined using AD Site (1), then Authenticated domain SID (2), then Entra tenant ID (5), in that order. Critically: "The option configured in this policy only applies to Group (2) download mode. If Group (2) isn't configured as the Download Mode, this policy is ignored." A carefully designed GroupID scheme on a LAN-mode fleet is dead configuration.
3. VPN. DOAllowVPNPeerCaching defaults to not allowed: "By default, if a VPN connection is detected, peering isn't allowed, except when the 'Local Discovery' (DNS-SD) option is chosen." Detection is string matching - DO inspects the network adapter's Description and FriendlyName against a default keyword list of "VPN", "Secure" and "Virtual Private Network", and the docs give "MSFTVPN matches the VPN keyword" as the example. Any adapter whose name happens to contain the word "Secure" will be treated as a VPN.
4. Minimum file size. DOMinFileSizeToCache specifies the minimum content file size in MB eligible for peer caching, and "The default file size is 50 MB to participate in peering." Everything smaller is invisible to peering. Microsoft's own sizing guidance: above 30 devices drop it to 10 MB, above 100 devices go to 1 MB, because "Content peering has a limited number of slots available at any given time."
5. Machine resources. DOMinRAMAllowedToPeer default 4 GB, DOMinDiskSizeAllowedToPeer default 32 GB total disk capacity, and DOMinBatteryPercentageAllowedToUpload - "By default, devices won't upload while on battery." Note the asymmetry, which the docs state explicitly: "The device can download from peers while on battery regardless of this policy." A laptop fleet that is never docked will happily consume peer bytes and never contribute any.

Then there is eligibility. Not every payload is allowed to peer at all, regardless of policy. From the What is Delivery Optimization content table: Windows Update, UWP Store apps, Defender definition updates, Intune Win32 apps, Microsoft 365 apps and updates, Edge updates, Configuration Manager Express updates and Dynamic updates all support peer-to-peer. Windows 11 Win32 Store apps, the MDM Agent, Xbox Game Pass for PC, Windows Package Manager and the MSIX Installer are HTTP-downloader only - no peer-to-peer column tick at all. Microsoft 365 peering excludes the SAC Extended channel, and Teams peering only arrives at version 25122.1415.3698.6812.

The binaries, so you know what you are actually looking at

Delivery Optimization is not one file, and the version numbers are a genuine diagnostic signal rather than trivia. Everything in this table was read off the measured 26200.9168 device.

Look at those version strings again. Three files in the same folder, three different schemes. dosvc.dll is on 10.0.26100.7309, dosettings.dll on 10.0.26100.8972 - and the OS is 10.0.26200.9168, so none of them match the build. But doclient.dll reads 1509.2607.1012.0, which is byte-for-byte the same version as wuaueng.dll on the same device. The download client is serviced on the Windows Update agent's release train, not the OS build's. Which means a DO client fix can arrive without a build change, and two devices reporting the same OS build can be running different DO clients.

How to verify: eight read-only commands, in order

Everything below is read-only. Nothing here restarts a service, clears a cache, or writes policy. Run it in an elevated PowerShell session - Get-DeliveryOptimizationLog explicitly requires administrator permissions when no path is given, and the status cmdlets are documented as being run from an elevated window.

The order matters. Each step either produces a root cause or eliminates a branch.

Three things to take from that block.

The provider suffix is the point. Every setting is paired with a ...Provider field, and Microsoft documents the behaviour: "Each policy is listed with the current set value and the provider of that policy", and "The provider is listed as 'Default Provider' if it's using the Delivery Optimization platform configured default." So DownloadModeProvider : MdmProvider is proof that LAN mode came from MDM, while WorkingDirectoryProvider : DefaultProvider is proof that nobody has moved the cache. This is how you settle the "is that setting actually applying?" argument without guessing.

The units cross-check works. Policy on this device sets DOMaxBackgroundDownloadBandwidth = 1000, and the policy is documented in kilobytes per second. Get-DOConfig reports DownBackLimitBps = 1024000. That is exactly 1000 x 1024, so the cmdlet is reporting the same setting in bytes per second. If those two numbers do not line up on your device, the policy you think you deployed is not the policy in force.

And two documented defaults do not match the device. The reference says DOMonthlyUploadDataCap defaults to 20 GB; Get-DOConfig reports UploadLimitMonthlyGB : 5120 attributed to DefaultProvider, and the policy is not set on this device. Similarly the monitor article says Get-DOPercentageMaxBackgroundBandwidth has a default of 45 and the foreground equivalent a default of 90, while the policy reference says both percentage policies default to 0 meaning dynamic adjustment. I am reporting the discrepancy rather than resolving it: trust the cmdlet for what the device is doing, and treat published defaults as a starting hypothesis.

The parent key for a Group Policy or local-policy DO deployment, as documented for every ADMX-backed setting in the Policy CSP:

On the measured device that key does not exist. Test-Path returns False. The device is MDM-managed, so the settings landed somewhere else entirely:

Three things in that key deserve a table of their own, because the naming is not obvious and the suffixes carry real information.

A naive reading of that block is "DO failed, zero percent peering". A correct reading is considerably more interesting, and it turns on one documented sentence about one field.

Microsoft describes Get-DeliveryOptimizationPerfSnapThisMonth as returning "data similar to data from Get-DeliveryOptimizationPerfSnap but limited to the current calendar month". Measured, it is not similar - it is a much smaller and much more useful schema, and it is the only place you get a clean month-to-date breakdown by source. Do not skip it because the docs make it sound redundant.

Here is the verdict on the measured device, and it is not the verdict a PercentPeerCaching check would have given you.

So: zero peering, all month, on a device with a correct LAN-mode policy. And roughly 62% of the month's HTTP bytes were served by a cache node rather than crossing the internet. The peering programme has failed. The WAN-egress programme is doing rather well. If you had reported PercentPeerCaching = 0 to a change board as "Delivery Optimization is not working", you would have been factually right and directionally wrong.

The cache node is worth a note because it explains itself. DOCacheHost and DOCacheHostSource are both not set on this device, and yet Get-DeliveryOptimizationStatus reported CacheHost values in the 173.46.83.20x range across several files. Microsoft documents two Connected Cache offerings: the Enterprise and Education product, where "Cache nodes are created in the Azure portal and are configured by applying the client policy using management tools such as Intune", and the ISP product, where nodes "are configured to deliver traffic to customers by manual CIDR or BGP routing". No client policy, cache hits anyway, is consistent with the second. Which means part of your bandwidth win may be arriving from your ISP without you configuring anything - and will silently vary by site and by carrier.

One honest inconsistency in that output, flagged rather than explained: Get-DeliveryOptimizationPerfSnap reports FilesUploaded : 1 and TotalBytesUploaded : 13851984, roughly 13.2 MB, while the month-to-date view reports UploadLanBytes : 0 and UploadInternetBytes : 0. The simplest reading is that the upload predates the current calendar month, since only the second cmdlet is month-scoped. Either way it tells you something valuable: this device has successfully uploaded to a peer at some point, so the peer protocol path is not structurally broken. It just is not being used now.

That is a complete chain of custody: DoSvc is Running with StartMode Auto, its PID owns a listening socket on TCP 7680, and both auto-created inbound firewall rules are Enabled with Action Allow. Microsoft documents exactly this behaviour - "Port 7680 is automatically registered and opened by the Delivery Optimization service" - and adds the consequence: "If you block port 7680, peer-to-peer functionality is disabled. However, devices can still download content using HTTP over port 80 or HTTPS over port 443." That is the silent-failure mechanism in one sentence.

To test reachability between two devices rather than just locally, the documented check is Test-NetConnection -ComputerName 192.168.9.17 -Port 7680 from one to the other. Microsoft still describes the Telnet equivalent and notes that a blinking cursor means success, but Test-NetConnection needs no feature install. The full documented port set is worth having: 7680/TCP for peer content, 3544/UDP for Teredo NAT traversal - required when using download mode 2 or 3 - 443/TCP for the DO cloud service, 80/TCP for metadata and CDN payload, and 67 and 68 UDP for DHCP-based groups or cache server discovery.

RAM passes with 30.67 GB against a 4 GB floor. Disk passes with 951.6 GB against a 32 GB floor. No connected adapter matches a VPN keyword. So on this device the resource gates and VPN suppression are all eliminated by measurement, and the remaining candidates are the subnet restriction, content eligibility, and simple lack of a concurrent peer.

Note the shape of that reasoning. Every one of these steps is worth running precisely because it can clear a suspect. A diagnostic that can only ever confirm is not a diagnostic.

There is no channel, so the tooling is cmdlet-based. In escalation order:

• Get-DeliveryOptimizationLog reads all logs from the DoSvc log directory when no -Path is given, which requires administrator permissions. Entries come back as objects on the pipeline, so Get-DeliveryOptimizationLog | Set-Content out.txt is the documented way to dump them.
• Get-DeliveryOptimizationLogAnalysis is the one worth reaching for first, because it computes the answers rather than making you grep for them. With no options it returns the total number of files, the number of foreground files, the minimum file size for it to be cached, the number of eligible files larger than that minimum, the number of files that found peers, the number of peering files that got at least one byte from peers, overall efficiency, and efficiency in the peered files. Those middle three fields are the entire investigation in one row. With -ListConnections you also get destination IP, peer type, status code, bytes sent, bytes received and file ID per connection.
• Enable-DeliveryOptimizationVerboseLogs and its Disable- counterpart exist for the case where the default traces are not enough. Turn verbose logging back off when you are done.
• The Delivery Optimization Troubleshooter is a Microsoft diagnostic that verifies device configuration, checks P2P efficiency and settings, and validates Connected Cache connectivity. Useful switches: -HealthCheck, -P2P, -MCC, -GenerateSupportBundle [-ReproduceIssue] and -AsObjects for scripting. It was not present on the measured device, so it is a download rather than something in-box.

You need this for two reasons: the disk-size prerequisite is documented as applying to the working directory rather than the OS volume when DOModifyCacheDrive is configured, and any cache-clearing step has to target the right place.

Do not guess and do not hard-code. Read it from the device. Get-DOConfig -Verbose reports WorkingDirectory, which on the measured device came back as C:\WINDOWS\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\Cache with WorkingDirectoryProvider : DefaultProvider, confirming nothing has moved it. Microsoft publishes the same location as the default in the workflow article, expressed from %SYSTEMDRIVE%. The DeliveryOptimization parent folder on the device holds three siblings - Cache, Logs and State - with the cache itself organised as GUID-named subdirectories and State holding dosvcState.dat plus a keyValueLKG.dat that lines up with the documented KeyValue bootstrap service, described as providing "endpoints for all other services and device configs".

The point of reading WorkingDirectory rather than memorising a path is that DOModifyCacheDrive exists and is sometimes used. A script with a literal path is wrong on exactly the devices where the answer matters. And when you do need to clear the cache, the supported route is Delete-DeliveryOptimizationCache, which takes -FileID for a single file, -IncludePinnedFiles to include pinned content, and -Force to skip prompts - not a manual delete.

The event log catalogue, and why it is nearly empty

The brief for a post like this normally includes an Event ID table. For Delivery Optimization the honest version of that table is mostly a census of what is not there, and the contrast is instructive. Windows Update, which is the caller for most DO traffic, does log to a channel.

The fix: change one constraint, and know which one

By this point the diagnosis should name a single constraint. Fix that one. Resist the urge to deploy five settings at once, because with no event channel and only aggregate counters you will have no way to attribute the improvement.

Map your finding to the change:

Things not to do

Do not use Set-DODownloadMode as the fix. It exists, it accepts CdnOnly, Lan and Internet, and it requires elevation. But Microsoft is explicit: changes made with the Set-DO* cmdlets "may be overridden by Group Policy or MDM policy on the next policy refresh". These are diagnostic and temporary-adjustment tools. Use them to prove a hypothesis on one device in ten seconds; never as the remediation.

Do not configure download mode 100. Deprecated in Windows 11, and Microsoft warns it "can cause some content to fail to download". If you want no peering, use 0. If the device has no internet access, use 99.

Do not clear the cache to "reset" DO. A device with a populated cache is an upload source for the rest of the fleet - the measured device had UploadCount : 36, thirty-six files currently eligible to serve peers. Delete-DeliveryOptimizationCache throws that away and removes the byte-level evidence with it. If the goal is disk space, DOMaxCacheSize, DOAbsoluteMaxCacheSize and DOMaxCacheAge are the settings that do it without destroying the fleet's seed capacity.

Do not raise the bandwidth cap as a first response to a saturated link. That is the opposite lever. On the measured device the caps are doing exactly what they were asked to: DOMaxBackgroundDownloadBandwidth = 1000 KB/s, reported by Get-DOConfig as DownBackLimitBps = 1024000, with a business-hours range of 08:00 to 17:00 at 25% both in and out of hours. A saturated WAN link with those caps in force is not a DO throttling problem - it is a lot of devices each staying politely inside a 1 MB/s ceiling.

Proof it worked: the four numbers that have to move

Because there is no event to watch, verification is a before-and-after measurement. Take the baseline before you change anything - the whole of step 1 to step 6 above, saved to a file - then re-measure after a real patch cycle rather than after a policy refresh. Peering needs concurrency, so nothing will change until two devices actually want the same payload at the same time.

The four numbers, in order of how convincing they are:

1. NumberOfPeers from Get-DeliveryOptimizationPerfSnap. Microsoft's own troubleshooting procedure makes this the pass/fail: download the same app on two devices on the same network, wait 10 to 15 minutes between them, confirm download mode is 1 or 2 on both, then check that NumberOfPeers on the second device "should be nonzero". Zero here and the cloud service is not matching you, so nothing downstream can work.
2. BytesFromLanPeers on individual files from Get-DeliveryOptimizationStatus. Peers being offered is not peers delivering. This is the field that proves bytes actually crossed the LAN, and it distinguishes a matching success from a transfer success.
3. DownloadLanBytes from Get-DeliveryOptimizationPerfSnapThisMonth. The fleet-level number to report upward, because it is month-scoped and needs no interpretation. Pair it with DownloadHttpBytes and DownloadCacheHostBytes so the audience can see all three sources at once.
4. ConnectionEstablished from Get-DeliveryOptimizationStatus -PeerInfo. The forensic one. Per-peer, real time, with IP, PeerType, BytesSent, BytesReceived and 20-second rolling upload and download rates. If peers are offered but every ConnectionEstablished is False, you have a reachability problem on 7680 between the peers, not a matching problem - and that is a completely different fix.

What does success actually look like? A real, measured example from a sibling capture on this estate: PercentPeerCaching : 33.68 on a 2.79 GB Microsoft 365 payload. One third of a nearly three-gigabyte download sourced from peers on one device. That is what a working peer group produces on eligible content, and it is a useful sanity anchor - if your best file after a fix is still at 0.4%, the constraint you changed was not the binding one.

For scale context, Microsoft's own internal deployment used Group mode restricted to devices in the same Active Directory domain with content cached for 24 hours, and reports that "More than 76 percent of content came from peer devices versus the Internet". Treat 76% as the ceiling of what a well-tuned Group-mode estate achieves, not as a target for month one.

Here is the honest before-and-after frame for the device in this post, so you can see what an unfinished investigation looks like written down:

Two closing cautions on measurement itself.

First, connection counts are instantaneous. LanConnectionCount, HttpConnectionCount, CacheHostConnections, CdnConnections and their siblings were all zero on the measured device precisely because nothing was downloading at that moment. Sampling them on an idle machine produces a confident, meaningless zero. Capture during a download or do not capture them at all.

Second, the same cmdlet can disagree with itself across scopes, and that is not a bug you need to chase. Get-DOConfig reported MaxUploadRatePct : 50 from DefaultProvider while Get-DeliveryOptimizationPerfSnap reported UploadRatePct : 100. One is a configured ceiling; the other is a currently applied rate. Record both, label them clearly, and do not average them into a single "upload rate" field on a dashboard.

References

• Monitor Delivery Optimization - the only place the cmdlet output fields are actually documented: the full Get-DeliveryOptimizationStatus and Get-DeliveryOptimizationPerfSnap field tables, the -PeerInfo fields, the Get-DOConfig -Verbose field list with the provider-attribution behaviour, and the Get-DeliveryOptimizationLogAnalysis output list.
• How Delivery Optimization works - cloud-coordinated peer matching, the client registration payload, ContentID/GroupID/external IP matching, Discovery and Array services, the Pieces Hash File and the documented fall back to Simple mode, the per-download-mode peer group scope table, port requirements, NAT traversal, and the default cache location and limits.
• Delivery Optimization reference - every setting with its MDM name, units and default: download modes 0 to 100, DOGroupIdSource values 0 to 5, DORestrictPeerSelectionBy, the Windows 10 versus Windows 11 peer-selection difference, DOMinFileSizeToCache, DOMinRAMAllowedToPeer, DOMinDiskSizeAllowedToPeer, DOAllowVPNPeerCaching, DOVpnKeywords and the delay policies.
• Troubleshoot Delivery Optimization - the "if you don't see any bytes from peers" decision tree, the two-device test with the 10 to 15 minute gap, the NumberOfPeers check, the same-public-IP test, the port 7680 Test-NetConnection procedure, and the four restrictive settings to audit.
• Configure Delivery Optimization for Windows - firewall hostnames, the full port table including Teredo on 3544, peer group design by topology, the file-size guidance by fleet size, the delay-policy starting values, and the non-additive cache-server fallback warning.
• Policy CSP - DeliveryOptimization - OMA-URIs, formats, allowed ranges, and the Group Policy mapping for every setting, including the SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization registry key name and DeliveryOptimization.admx.
• What is Delivery Optimization? - the content-type eligibility table showing which payloads support peer-to-peer at all, the minimum Windows versions, the client-default statement about NAT, and the Microsoft-internal 76 percent figure.
• Microsoft Connected Cache overview - the two offerings, and the distinction between the Enterprise and Education product configured by client policy and the ISP product routed by CIDR or BGP.
• Get-DeliveryOptimizationStatus (cmdlet reference) - the -AsObject, -PeerInfo and -SelectPeerCount parameters (default 5) and the output types DOSwarmStats, DOFilePeerInfo and DOPeerInfo. The description fields on this page are unpopulated, which is why the conceptual monitor article above is the real reference.
• Get-DeliveryOptimizationPerfSnap (cmdlet reference) - output type DOPerfSnap. Also an unpopulated stub at the time of writing.
• Test-NetConnection - the documented alternative to Telnet for the peer-to-peer port 7680 reachability test.
• Delivery Optimization Troubleshooter - the Microsoft diagnostic with -HealthCheck, -P2P, -MCC, -GenerateSupportBundle and -AsObjects.

Every command output shown in this post was captured read-only from a live Windows 11 Enterprise 25H2 device, build 26200.9168, on 23 August 2026. Nothing in the diagnostic path writes to the device, restarts a service, or clears a cache. Validate against your own estate before acting on any of it.