Advanced Delivery Optimization Diagnostics: Steps 4 to 8, the Log Pipeline and the Binary Versions

The problem: the first three commands came back clean

The ordinary diagnosis ends at step three. You read the effective configuration and the provider that set it, you confirmed where the policy physically lives, and you read the per-file byte accounting. Download mode is a peering mode, no constraint is obviously disqualifying the device, and the byte accounting still shows every file arriving over HTTP with NumPeers : 0.

That is the case this post is for. There is no error to search for, because Delivery Optimization does not raise one. The remaining answers are in places that are not configuration: the device aggregates, the network path, the hardware floor, the trace pipeline, and the version of the client binary itself.

Why it happens: two things that are not in the configuration

Two facts explain most of what the first three steps cannot. The first is that Delivery Optimization is not one component on one release schedule. The second is that it has no event log, so there is nothing to go back and read.

Advanced: the binaries, so you know what you are actually looking at

Skip this unless two devices on the same Windows build are behaving differently. It explains why that can happen.

Delivery Optimization is not one file, and the version numbers are a genuine diagnostic signal rather than trivia. The versions below were read off the measured 26200.9168 device. File sizes are deliberately not listed: they change with almost every monthly update, so a byte count printed here would only invite you to compare it with your own device and conclude something is wrong when nothing is.

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.

A second device confirms it. The same four files were read on a different Windows 11 25H2 machine, on build 26200.9457 rather than 26200.9168. If all of Delivery Optimization shipped with the OS build, every version would have moved together. They did not:

Three files, one OS, three different release cadences. The service DLL did not move at all between those two builds, while the download engine moved twice.

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.

How to verify: steps 4 to 8

These continue the numbering from the first post. They are all read-only: nothing here restarts a service, clears a cache or writes policy. Run them in an elevated PowerShell session.

Step 4 tells you whether the device saved bandwidth at all. Steps 5 and 6 eliminate the network and the hardware. Step 7 is the trace pipeline, which is the only place with per-download detail. Step 8 tells you where the cache actually is.

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 fix: what each advanced finding changes

As in the first post, the goal is to name one constraint and change one thing. These are the findings that only the advanced steps can produce.

Proof it worked: what to capture

The advanced steps are worth running only if you write down what they returned. Capture these four, before and after whatever you change:

• The month-to-date split from Get-DeliveryOptimizationPerfSnapThisMonth: DownloadHttpBytes, DownloadCacheHostBytes, DownloadLanBytes. These separate "we saved WAN bandwidth" from "peering worked", which are different questions.
• NumberOfPeers from Get-DeliveryOptimizationPerfSnap. Zero after a change means the peer list is still empty, whatever the configuration says.
• The doclient.dll version on every device you are comparing, so a difference in behaviour can be attributed or ruled out.
• The date and time of the test download, because the aggregates are month-to-date and reset.

References

Companion post: Delivery Optimization says it is peering and your WAN link says otherwise — the plain-English primer, why peering is a permission rather than a switch, and diagnostic steps 1 to 3.

• Monitor Delivery Optimization — the only place the cmdlet output fields are documented, including the statement that BytesFromHTTP includes BytesFromCacheServer.
• Troubleshoot Delivery Optimization — the two-device test, the NumberOfPeers check and the port 7680 procedure.
• Delivery Optimization reference — every setting with its MDM name, units and default, including the RAM and disk floors.
• Configure Delivery Optimization for Windows — the full port table including Teredo on 3544, and peer group design by topology.
• How Delivery Optimization works — cloud-coordinated peer matching, the pieces-hash metadata file and the documented fall back to Simple mode.