Microsoft

System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

Peer Caching Boundary Groups

ConfigMgr Team, your best practice document regarding the set up of boundary groups actually breaks peer caching.

https://docs.microsoft.com/en-us/sccm/core/servers/deploy/configure/define-site-boundaries-and-boundary-groups

To quote: "it is a best practice to create a separate set of boundary groups to use only for site assignment."

This is good advise, and I use this also for Management Points and Software Update Points so that if I add or remove a site system, I only have to modify 1-2 boundary groups instead of 150.

Since Peer Caching is now based on Boundary Groups, if you have implemented this best practice, then effectively every client in a site that has Peer Caching enabled is within the same boundary group, and therefore any client at any site across the world can search for and download content from any client at any site across the world. (We are experiencing this right now, as a matter of fact.)

In order to better control where clients can and cannot use Peer Caching, I would suggest that a setting be added to the boundary groups that the clients can read that would tell them whether or not they can use Peer Caching when inside this boundary. Since the client setting controls who can be a SuperPeer and who cannot, this setting will be good to ensure that the clients stay within their actual physical boundaries and only select SuperPeers within that boundary.

As a bonus, if you designate a Distribution Point to a boundary that is enabled for Peer Caching, then that will be the first DP that the clients reach out to if there is no content available on a SuperPeer within the boundary.

46 votes
Vote
Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
John Williamson shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

2 comments

Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
Submitting...
An error occurred while saving the comment
  • Trevor Jones commented  ·   ·  Flag as inappropriate

    We have this same issue. Even if a boundary is a member of a site-system boundary group where the option 'Allow peer downloads in this boundary group' is checked, if it is also member of a site assignment group where the option is not checked, it will prefer the 'not checked' over the 'checked' and will not peer. You can see the following in the LocationServices.log on an affected client:

    Client is in boundary group marked to not Allow peer downloads. Setting WindowsDO GPO to default values. Mode = LAN. GroupID = empty

    So essentially peering is everywhere or nowhere if you use site assignment groups.

  • Sam Monroe commented  ·   ·  Flag as inappropriate

    Couldn't you just disable "Allow peer downloads in this boundary group" in your site assignment group and keep it checked in your content group? Also, I never have a Site system server under the References tab on my Site Assignment group. Am I missing something?

Feedback and Knowledge Base