Boundary groups, in ConfigMgr, allow us to associate our network locations with site system roles. We can, therefore, associate clients with the localised roles and we can add in DPs, SUPs (since ConfigMgr 1702), preferred MPs and state migration points in as site systems defined in our boundary groups. We can, also, use boundary groups for site assignment.
Boundary group management was changed with ConfigMgr 1610, and it is worth taking a look at the TechNet documentation that explains the set up in detail.
The basics are that your client is associated with its current boundary group, this could be one or more boundary groups, and it will use the site systems defined in the boundary group.
If no site systems are defined in the current boundary group, then a relationship can be created that links it with a neighbour boundary group. When creating that relationship, the amount of time before falling back to the neighbour can be specified for DP and SUP. roles.
Each ConfigMgr primary site has a default site boundary group, called Default-Site-Boundary-Group<sitecode>.
The default site boundary group will have the primary site server added to it when it is automatically generated.
It is worth noting that when creating a boundary group, there is an implied link to the default site boundary group for fallback for all your boundary groups. Think of it as a safety net for your boundary groups.
However, there are occasions whereby you won’t want your clients to fallback to the default boundary group. For example, you may have slow WAN links in certain locations, and have strategically placed distribution points locally to avoid traffic coming over the wire. To avoid this ever happening, you may enable the ‘Never Fallback’ checkbox, but be aware that this will stop all boundary groups from having that ability to fallback. This isn’t the end of the world though, since you can redirect the fast connected WAN’s to fall back to other boundary groups when creating your relationships and falling back to a neighbour.
As stated, Software Update Points can also be added into boundary groups and fallback relationships defined for this role.
Some careful consideration is needed here, you may be running a single SUP in your site which could be on a server sharing roles with a DP, e.g. your primary site server. If you have concerns around content on slow WANs, you are not going to add this server to your local boundary groups, just in case some content is missing from local DP and the clients start coming across that WAN again to grab the latest Windows 10 cumulative update, for example.
In this instance, you will need to allow fallback to the default boundary group to allow clients access to the metadata for software update compliance.
But what if you have been trigger happy, decided that nothing should ever fallback to the default boundary group for both DP and SUP.
Well, if you have only recently enabled the ‘Never fallback’ option in your default boundary group for SUPs, then devices that already have the client installed will have already fallen back to this boundary group picked up the SUP details and be using it quite merrily. However devices that come into the site post ‘Never fallback’ being enabled will struggle as they will never fallback and hence never be assigned the SUP.
We can check in our logs to see the lack of movement when running a Software Updates Scan cycle from the ConfigMgr control panel applet.
My windowsupdate.log file is reporting the WSUS server as NULL.
My WUAHandler.log is pretty much empty.
and the locationservices.log is showing nothing for ‘Calling back with the following WSUS locations.
A quick check of the group policy on the local device shows nothing configured for the ‘Specify intranet Microsoft update service location’.
So none of these bad boys are ever going to get patched in our SCCM environment. That single check box could potentially have some seriously knock on effects.
Be aware!
SCCMentor - Paul Winstanley 