ConfigMgr Boundary Groups Update

In ConfigMgr, boundaries define locations where our devices reside. We can define boundaries based on IP subnets, IP ranges, Active Directory sites and IPv6 prefixes. We also have boundary groups, a set of logical locations that group together these boundaries. The boundary groups can then be used to find site assignment for the clients or to dictate which site roles are available to them and from which site system server.

Intranet-based clients will check against their location to evaluate which boundary group they are a member of. Internet-based clients, however, do not use boundary information.  Instead, they will use any site system from their assigned site—if that site system is configured to allow connections from Internet based-devices.

Microsoft has made some considerable changes to the way boundary groups operate within ConfigMgr Current Branch, including some recent changes in ConfigMgr 1810. These changes radically alter the way that we approach planning and designing a ConfigMgr hierarchy, and in the way that we can control some of the major roles with the environment. Let’s look at some of these changes in more detail.

Boundary Group Caching (CB1511)

Boundary group changes started in the initial release of Current Branch, 1511. This was the introduction of boundary group caching where clients cache the name of their current boundary group. This meant that the management point (MP) no longer needed to look up a client’s boundary or boundary group for client’s content requests. Jason Sandys wrote a fantastic in-depth article about this feature change, and it’s well worth reading.

Simplified Infrastructure with Better Fallbacks (CB 1610)

A radical overhaul of boundary groups, however, occurred in the ConfigMgr 1610 release. The objective was to assist with simplifying content infrastructure and to give more control over client fallback to site systems for content from distribution points. The update to 1610 automatically converted existing boundary groups into the new format.  

This update introduced a new concept, the default site boundary group. If clients did not reside in a boundary group, then they would fall back to the default group and use the site systems associated with it. The changes also introduced the ability to control fallback to other boundary groups within the ConfigMgr environment and, by assigning a weighting to the relationship between the groups, define which location the clients to go to.

So how does the relationship feature work? Let’s assume I have three boundary groups in my environment. I create fallback relationships among the three groups based on the number of minutes I am happy to wait before my client falls back to the other groups to grab content.

Suppose I have a London office. Then, in my boundary group Relationship tab I create a fallback relationship from the London office to my Manchester and Seattle offices. I can control when devices start to fall back. If my London-based client fails to find the content from any available distribution point in the London boundary group, after 10 minutes it will fall back to my Manchester office. Once it falls back, it will then use the time for fallback, 10 minutes, as the amount of time to get the content from the Manchester office. If the client then fails to find a distribution point resource with content in the Manchester office, a fallback to the Seattle office will occur after 30 minutes. After 120 minutes of attempting to get the content from any of our related boundary groups, the client will fall back to the default boundary group to get the required content.

You can stop clients from falling back to boundary groups that you do not wish them to use via the "Never Fallback" checkbox. Use this wisely, though. For some customers I have worked with, the use of Never Fallback to the default boundary group has been beneficial--for example, to avoid large amounts of data being dragged across very slow network links. However, ideally, you should be using the default boundary group as a fallback source for content. The clients need to get content from somewhere.

SUPs Join the Party (CB 1702/1706)

Further modifications were introduced in ConfigMgr 1702 and 1706. The ability to add Software Update Points (SUPs) into boundary groups and allow for fallback was added. This feature enabled admins to control client’s access to specific SUPS in their environment.

One requirement is that you have a SUP added to your default boundary groups at a minimum. If you are not defining SUPs in your standard boundary groups, clients have to fallback to the default boundary group to gain knowledge of an available SUP in the environment. Without the SUP defined, it is possible for new clients, introduced into the environment, never to pick up the SUP and therefore never apply any updates. I wrote a blog post about the impact of this at my SCCMentor site.

MP Traffic Taming (CB 1802)

Hot on the tail of DP and SUP boundary group awareness, ConfigMgr 1802 introduced the taming of MP traffic. Microsoft did this by allowing admins to assign MPs into the boundary group and contain their associated traffic to locations. The ugrade to 1802 moved all the existing intranet-based Management Points into the default boundary group, and admins were left to associate MPs into their relevant boundary groups.

If clients reside in a boundary group with no assigned Management Points, they are presented with a list of all Management Points in the environment. This ensures that clients will continue to communicate with at least one MP in the environment and receive policy. The fallback option also has zero impact on how a client install obtains its management point. If the /MP switch is not defined as an install parameter, it will use the list of all MPs in the environment to communicate with. Once registered, the new behavior kicks in.

Cloud Preference Allowed (CB 1810)

In ConfigMgr 1810, the latest version of ConfigMgr, the feature "Prefer cloud distribution points over distribution points" was introduced. This means you can effectively point your remote branch offices to a cloud distribution point if they have a faster internet link, for example.

What’s Next for Our Boundary Groups?

The ConfigMgr Technical Preview stream is the best yardstick we have for potential new features.  This means there’s a good chance (fingers crossed) that the 1902 release will take onboard a new feature added to TP1902: the ability to add the Cloud Management Gateway to boundary groups. This site role would allow CMG client communication to occur based on the group relationships, and hence traffic can be redirected away from expensive or slow WAN links to faster, less expensive routes.

Some software vendors offer solutions to radically shrink (or, in some cases, eliminate) the complexity of boundary groups along with a DP infrastructure. If this sound interesting to you, you might want to catch an upcoming webinar from Adaptiva to see if its solution would be useful in your environment: Product Webinar: Rethinking ConfigMgr Speed, Security, and Simplicity.

For the full lowdown on boundary groups within ConfigMgr, and to keep up with the latest changes as they hit the product, I recommend that you read the boundary group section of the Microsoft TechNet documentation.

Paul Winstanley is a Microsoft MVP and ConfigMgr certified consultant. Based out of London, Paul has 20 years of IT experience. He has spent a decade specializing in deploying ConfigMgr and advising clients how to use it effectively. He relentlessly contributes to the ConfigMgr and Intune community. Follow him on LinkedIn and Twitter, and check out his blog at SCCMentor.