Peer cache vs BranchCache vs Delivery Optimization in Configuration Manager

Branch offices without a distribution point don't have to pull every package across the WAN. Configuration Manager offers four ways to keep content local: client peer cache, Windows BranchCache, Delivery Optimization and Microsoft Connected Cache on a distribution point. They overlap less than their names suggest. In this post I'll explain what each one serves, how a client chooses where to download from, how to set them up, and how to prove which source a client actually used.

How it works#

Two points catch people out. Peer cache doesn't depend on BranchCache; they work side by side. And Connected Cache on a distribution point doesn't serve content from Configuration Manager deployments, such as software updates from your software update point. That content comes from distribution points, peer cache and BranchCache.

How a client picks a source#

For each download, the client sends a content location request to its management point. The reply lists the distribution points in its current boundary group and every online peer cache source in that group that has the content, plus distribution points from neighbor and default site boundary groups after their fallback times. The management point never offers peer cache sources from a neighbor group. Boundary group options on the Options tab adjust the order: Allow peer downloads in this boundary group, During peer downloads, only use peers within the same subnet, Prefer distribution points over peers within the same subnet and Prefer cloud based sources over on-premise sources. If your groups aren't solid yet, start with boundaries and boundary groups explained.

Step-by-step#

1. Enable peer cache sources#

1. Pick a few wired, always-on desktops per location with spare disk space, and put them in a collection.
2. Create a custom device client setting: Client Cache Settings › Enable as peer cache source = Yes. Keep the default ports (8004 for the initial broadcast, 8003 for downloads) unless they clash; Configuration Manager opens them in Windows Firewall, but third-party firewalls need rules. Size the client cache for your largest content, such as OS upgrade packages.
3. Deploy the setting to the collection. Sources report their cached content to the management point with state messages, and the management point checks that a source is online over the client notification channel (TCP 10123).
4. Optional: in Hierarchy Settings › General, enable Configure client peer cache sources to divide content into parts, so several sources download different parts from a remote distribution point and then share them. This only applies to background downloads such as required deployments.

2. Enable BranchCache#

In a client setting, set Client Cache Settings › Configure BranchCache and Enable BranchCache to Yes, and set the maximum BranchCache cache size. BranchCache is always enabled on deployments, so clients use it whenever the distribution point supports it.

3. Configure Delivery Optimization and Connected Cache#

1. In client settings, Delivery Optimization › Use Configuration Manager Boundary Groups for Delivery Optimization Group ID = Yes, so DO peers only within a boundary group. Keep Allow peer downloads in this boundary group selected.
2. For Connected Cache, open the distribution point's properties and, on the General tab, select Enable this distribution point to be used as Microsoft Connected Cache server, confirm the licenses and choose the drive and size (100 GB by default). Don't preinstall IIS Application Request Routing; setup installs and configures it.
3. In client settings, enable Delivery Optimization › Enable devices managed by Configuration Manager to use Microsoft Connected Cache servers for content download. Clients must be in the same boundary group as the Connected Cache distribution point; neighbor and default groups aren't used.

Verify#

• Configuration Manager content: on the client, LocationServices.log records the content location reply, and ContentTransferManager.log and DataTransferService.log show the URL used. A peer cache download points at a peer's host name instead of a distribution point. For divided downloads, read ContentTransferManager.log on the sources and MP_Location.log on the management point.
• Across the site: the Client Data Sources dashboard shows how much content came from distribution points, peers and BranchCache. The reports Peer cache source content rejection, by condition and details show why sources refused requests.
• BranchCache and Delivery Optimization, on the client:

Get-BCStatus | Select-Object BranchCacheIsEnabled, BranchCacheServiceStatus
Get-DeliveryOptimizationStatus |
    Select-Object FileId, BytesFromPeers, BytesFromCacheServer, BytesFromHttp, PercentPeerCaching

Good looks like this: branch clients download Configuration Manager content from a peer or the local distribution point before any fallback time, and Delivery Optimization jobs show non-zero BytesFromPeers or BytesFromCacheServer.

Tips and gotchas#

• Peer sources refuse work when they're on battery saver, CPU load is above 80%, the disk queue length is above 10, or they have no free connections. The client then tries the next source.
• Offline sources slow everyone down: by default a client can fail if the first 25 peer cache sources it tries are offline. Keep source lists small and healthy.
• Not supported: Windows on Arm64 devices as peer cache sources or clients, and peer cache sources that aren't domain-joined.
• Task sequences: a Software Center task sequence that reboots into Windows PE needs a network access account to download from peer cache sources.
• Persist content you want peers to serve with the Persist content in the client cache option. Clients otherwise remove the oldest content first.
• Still failing? See content not reaching distribution points and the application deployment error codes quick reference.

References#

• Peer cache for Configuration Manager clients (Microsoft Learn)
• Microsoft Connected Cache with Configuration Manager (Microsoft Learn)