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, for the overhaul, 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 your 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 between 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, then after 10 minutes it will fall back to my Manchester office. Once it falls back, it will then use the time for fallback, 10 mins, 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 then 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 then 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. I have worked with customers where the use of ‘Never Fallback’ to the default boundary group has been beneficial, 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 from this is that you should have a SUP added to your default boundary groups at a minimum. If you are not defining SUPs in your standard boundary groups, then clients have to fallback to the default boundary group to gain knowledge of an available SUP in the environment. Without the SUP defined, then it is possible for new clients, introduced into the environment, never 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 then left to associate MPs into their relevant boundary groups.
If clients reside in a boundary group with no assigned Management Points, then 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, then it will use the list of all MP’s in the environment to communicate with. Once registered, then the new behavior kicked in.
Cloud Preference Allowed (CB 1810)
In ConfigMgr 1810, the latest version of ConfigMgr released, the feature to ‘Prefer cloud distribution points over distribution points’ was introduced. This meant that you could effectively point your remote branch offices out to a cloud distribution point if they had 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. With this site role added, this allows 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.
For the full low down on boundary groups within ConfigMgr, and to keep up with the latest changes as they hit the product, then I always recommend that you read boundary group section of the Microsoft TechNet documentation.
