ConfigMgr, Delivery Optimization and Multiple Boundary Groups

As a general rule of thumb, keeping your boundary groups configuration stupid simple is a good idea. That being said, I was today years old when I learned how multiple boundary groups, with different peer download settings, affect Delivery Optimization settings as well as Peer Cache downloads.

TL;DR

Configure your clients to be a member of exactly 1 boundary group and all is good. No need to worry.

Delivery Optimization in ConfigMgr

For the full story on Delivery Optimization in ConfigMgr, read this post https://deploymentresearch.com/setup-delivery-optimization-do-for-configmgr-current-branch/ , but to summarize it: ConfigMgr can configure the DO download mode, set the Group ID, and set the Cache Server to use for all machines having a ConfigMgr client installed.

ConfigMgr uses Client Settings to enable DO setting all together, and the details are coming from the boundary group. For a client to set the DO group ID to the ID of the boundary group, you need to enable peer downloads for the boundary group. This is the same setting you would use to allow Peer Cache Client Settings to be deployed, but also affects Delivery Optimization.

Multiple Boundary Groups

The interesting learning from today is following: If a client is a member of one boundary group that allow peer download, and at the same time, is a member of a boundary group that does not allow it. The result is no DO settings being applied, and the clients reverts to DO download mode 1, and no DO Group ID being set. No entirely ideal for most environments.

Note: Again, the same behavior also affects Peer Cache. If a client is a member of another boundary group, where peer downloads are disabled, it will never download from a peer cache source. Doesn't matter if its first boundary group has it enabled. No means no.