Forum Discussion
Delivery Optimization fails for 99% of the company
Hi,
I understand you are using ConfigMgr in combination with DO. Looks like your peer-to-peer over port 7680 TCP/UDP is working properly.
1) delta download should be enabled in ConfigMgr client settings; this is local port 8005. See ConfigMgr console > Administration > Client Settings > Default client Settings > Software Updates > 'Ports that clients use to receive delta content = 8005' (details: Https://docs.microsoft.com/en-us/mem/configmgr/sum/deploy-use/optimize-windows-10-update-delivery#bkmk_DO-1910)
2) There is also a parameter for DO to help it avoid to fall back too quickly to CDN: see https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization-reference#delay-background-download-from-http-in-secs. We set it to 1 hour.
3) You can also check DO logs on client which gives very clear and detailed info: Get-DeliveryOptimizationLog | select Message -Last 250 | Out-GridView
Hope this helps.
Johan
- Pardu1Oct 27, 2021Brass ContributorThank you so much for your suggestions.
All our PCs are comanaged, and our DO Ppolicy is deployed by Intune. But yes, Sccm configmanager is/could be still involved.
Not sure how much as is not clear to which workload depends DO, if any.
95% devices are in the pilot collection to set MDM as authority for WU.
Yes, delta downloads are disabled to the whole company. Doesn't makes sense to me, but it was set with such config when I arrived to the company. I also thought this could be the issue, so I enable it for a little group of 200 pcs located at the same office, and the same boundary. But unfortunately, after this OCT patch cycle, none of them appears in the Compliance Dashboard as BYTES>0
On DO logs I see a lot of FailureReason:Null, peer connection destroyed, socket connect error.
I see those errors even on Logs from a successful machine sharing 3.5Gb to the local network by DO. Makes sense to you?
I will recheck everything again. Thanks.- Pardu1Oct 27, 2021Brass ContributorRegarding the delay thresholds, we set it as recommended by MS, 60 sec
Recommended by official MS docs, by MEM help statements, and also directly from the fasttrack team of MS.
But who knows? I will try it.