Here is a quick guide on setting up Delivery Optimization (DO) for a ConfigMgr environment.
Note: The setup is almost the same for non-ConfigMgr environments as well, most of the DO configuration is done via Group Policies.
Delivery Optimization Background
Delivery Optimization (DO) has been around since the very first versions of Windows 10, but it has not been until recently (ConfigMgr 1802) that you find some integration between DO and ConfigMgr. DO is used whenever Windows 10 updates any of it's built-in universal apps, or when a user installs an application from either the Microsoft Store, or the Microsoft Store for Business. DO is also used for Software Updates when they are setup to use Express installation files. Phil Wilcock has great post about the Express installation files scenario here: http://2pintsoftware.com/configmgr-express-updates-deep-dive
Delivery Optimization is a peer to peer technology, meaning as soon as one Windows 10 client in a location got the content, it can share the content with other clients. Now, there is a ton of different configuration options for Delivery Optimizations, controlling how the peering works, the cache size allowed, and the bandwidth control. The options vary with the Windows 10 version. In general, as of now, I recommend you to be at least on Windows 10 v1709, but from a core DO point of view, you probably want to be on Windows 10 v1803. Microsoft has all options listed here, and in what version of Windows 10 each option is available: http://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization
Like the BITS technology, Delivery Optimization also have the concept of foreground and background jobs. Foreground jobs in when a user starts a job, for example by installing an application from the Microsoft store. Background jobs are for example when Windows decides to update an application. In Windows 10 v1709 you can only set one bandwidth limit for both, but in Windows 10 v1803 you can configure bandwidth limits for background and foreground jobs independently.
Some nice features of DO is that is supports a distributed cache, meaning content is stored efficiently across multiple devices. It supports multitasking, as in support downloading from multiple sources, and it supports hybrid which means it can download from http and peer sources in parallel. Pretty cool.
Note: AFAIK, there are currently no third party solutions available that can do Delivery Optimization peering, meaning peering universal app downloads. You're stuck with the native options for now.
Scenario
The scenario for this guide is that we have a distributed environment running ConfigMgr Current Branch, in this setup there are two sites connected with a limited WAN link. Internet access is provided via the WAN link to the main office only.

Step-by-step guide
For the the scenario in this guide, we want to make sure that no clients in Chicago are reaching over the WAN link for finding peer clients for DO content. The default behavior of DO is that all clients with the same public IP can share content, but since all clients in our environment have the same public IP, we're using the group mode instead. Only allowing machines in Chicago share content with each other.
Setup the Group Mode
Configuring DO the use group mode is done via Group Policy, but there are two options to set the group ID, e.g. the identifier that we assign to each Chicago client. It can either be set ConfigMgr assuming you are on 1802 or later, and when you do that, you're simply saying that all clients belonging to the same boundary group, have the same ID.
Note: For the group mode to work, all clients in the group must use the same NAT IP.
1. Configure the ConfigMgr Client Settings to set the Group ID



2. Create a GPO that configures the DO settings. In this example the download to the Chicago clients where limited to 2560 KB/s (20 mbit)
GPO Settings for Windows 10 and Windows 11
- Absolut Max Cache Size (in GB): 30 (default value is 20)
- Allow uploads while the device is on battery while under set Battery level: 40 (By default, devices will not upload while on battery)
- Delay background download from http (in secs): 600 (10 min)
Note: If using the delay background settings for clients enrolled into Windows Autopilot, make sure to configure those assignments for foreground traffic. See Note #2 below. - Delay foreground download from http (in secs): 60 (10 min)
- Download Mode: Group (2)
- Group ID : (set to not configured when set by ConfigMgr, otherwise set a GUID for that location)
- Max Cache Age: 0 (0 means infinite, but real-world testing shows that DO still clears out the cache when needed with this setting. Default is 259200 = 3 days)
- Maximum Download Bandwidth (in KB/s): 2560 (2560 KB/s = 20 mbit/s)
- Minimum Peer Caching Content File Size (in MB): 1
- Minimum RAM (inclusive) allowed to use Peer Caching (in GB): 2
- Minimum Background QoS (in KB/s): 64 (lower to 20 if having slow Internet connections, 20 mbit/s or less)
Note #1: A neat trick is that you can set the "Select a method to restrict Peer Selection" group policy to subnet, making sure that only clients on the same subnet will peer content, even if they have the same NAT IP, or the same Group ID as everybody else. This subnet restriction works for both LAN and Group mode, and for the group mode, you need to set at least one Group ID for this to work. It can't be blank (Group ID is not required in LAN mode, only in Group mode).
Note #2: When configuring Win32 apps in Intune for Windows Autopilot, and having delay background download configured, make sure to set those application assignments to do foreground download (see below image).

Note #3: Again, If you don't set the group ID via ConfigMgr, set your group ID directly in this GPO. You can generate a GUID easily via PowerShell: [guid]::NewGuid()
Note #4: Prior to June 20, 2018, DO wouldn't cache files under 10 MB, even when you set it lower. It has been fixed now.
Note #5: Setting the background delay quite high (10 min) for Windows 10 v1803 or higher seems to improve the P2P ratio quite a bit (only background since you probably don't want users having to wait 10 minutes for foreground jobs, like when requesting an app from Microsoft store). But again, please see Note #2 for Windows Autopilot implications of settings this value.

Verification
To verify that DO works as expect you can use some of the the DO PowerShell cmdlets. Below you find some of the more useful DO cmdlets for Windows 10.
Windows 10 v1709
- Get-DeliveryOptimizationPerfSnap
- Get-DeliveryOptimizationStatus
Windows 10 v1803
- Get-DeliveryOptimizationLog
- Get-DeliveryOptimizationPerfSnap
- Get-DeliveryOptimizationPerfSnapThisMonth
- Get-DeliveryOptimizationStatus
Windows 10 v1903
- Delete-DeliveryOptimizationCache
- Get-DeliveryOptimizationLog
- Get-DeliveryOptimizationPerfSnap
- Get-DeliveryOptimizationPerfSnapThisMonth
- Get-DeliveryOptimizationStatus
- Get-DOConfig
- Get-DODownloadMode
- Get-DOPercentageMaxBackgroundBandwidth
- Get-DOPercentageMaxForegroundBandwidth
- Set-DeliveryOptimizationStatus
- Set-DODownloadMode
- Set-DOPercentageMaxBackgroundBandwidth
- Set-DOPercentageMaxForegroundBandwidth

Happy Deployment, / Johan
Hi Johan, Would you use ConfigMgr to set the GroupId and DownloadMode only to have it dynamic based on BoundaryGroup. And all additional tweaks via Group Policy, such as DelayBackground, CacheAge, etc.? Does GPO and Client Settings conflict/overwrite?
Hi Michael,
If ConfigMgr boundary groups matches your physical locations, then yes, they can be used. Otherwise I set them via script, GPO etc. I commonly set generic parameters via CSP or GPO, they do not conflict with ConfigMgr client settings.
/ Johan
Hello Johan,
In your Note#1 you said the group ID is mandatory is it also mandatory for LAN Mode ?
Thanks
Group ID is not required in LAN mode, only in Group mode. I've updated the post so that is more clear. / Johan