Delivery Optimization fails for 99% of the company

[Pardu1]

DO policy (Lan mode 1) deployed on 75k devices, all of them comanaged.
Compliance dashboard show 75k devices clearly contacting with peers on the same subnet, but only 1% is achieving >0 bytes savings..
DO inbound rules are opening 7680 UDP & TCP by default on windows firewall.
Our proxy show allowed connections to mandatory Cloud URLs for DO, and its allowing http range bytes.
Same results uninstalling our antivirus.
1% working DO peers doesn't share location.
Intune only devices are also failing.
AADJoin devices are also failing.

Recently we used our DPs as Connected Cache Server. Those DPs really seems to be acting as a hostpeer, and clearly are saving data for us, but is not enough. We need also W10 peering.

To recap...
PCs are getting updates from CDN, then chaching that content and offering themselfs as peers to WU Servers.
Then new PCs contact WU, WU point them to those HostPeers, then new PCs connect with them, but 99% there's no transfer, so after a timeout those PCs are pointing again to CDN causing tons of traffic.

If such location has a Connected cache available, that connection to the CacheServer seems to be working.
Why our cache servers are achiving the transfers, but not our regular W10 boxes?
Which piece of the puzzle I'm missing?

I'm completely desesperate, with feature upgrade paused as we cannot afford such payloads without destroying the networks.
Mayday! Any idea, any clue?

[#2]

@Pardu1 

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#bk...)

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#dela.... 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

[#3]

Thank 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.

[#4]

Regarding 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.

[#5]

@Pardu1 

For other Admins stucked on the same situation....
Check if your global domain GPOs are set to IGNORE your local/default/built-in firewall rules.
Keep in mind DO firewall rules are created and active by default for any W10 edition.