Add Boundary Group Selection to SUP Creation Process
It has become a semi-regular occurrence in the various communities that someone has created a new environment or rebuilt their SUPs and suddenly none of their clients updates are managed by ConfigMgr and they're getting updates direct from Microsoft.
Often the root cause is that they did not add the new SUP to any boundary groups. It's an additional step that users just need to kinda of magically know ahead of time to do. Which is to say people aren't going to know and find out the hard way.
Let's solve this somehow. For me, making boundary group selection part of the SUP configuration makes sense. I'd suggest defaulting to the default boundary group in that scenario.
On this date in the foul year of our lord 2021 yet another poor unfortunate soul was forced to endure hours (days!) of agony trying to figure out why their brand new environment just didn't work.
We have wrestle with how to keep our DMZ servers patched. We have set up MP/DP/SUP site server in the DMZ for this but run into several challenges. There seems to be no way to prevent intranet clients and internet-based clients from trying to use the SUP that is in the DMZ. If we use boundaries we have issues because the DMZ subnets are 192.168.1.x and 192.168.2.x, which are very common default subnets on home Wifi routers. The "failover" from an unreachable SUP doesn't seem to happen properly or very quickly so update deployments across the whole environment get drastically slowed down. We should be able to assign a specific SUPto a group of clients by Collection or a registry setting or something.
I'm going to start documenting each time this happens here. Because ... why not. On this date some poor soul lost ~4 best hours of their life because the SUP wizard doesn't make it clear to the user that their SUP is useless unless they add it to a Boundary Group.
It occurred to me just now that while SUPs are the one I've seen most frequently (probably because nuke-n-pave is a popular option) this should probably apply to all boundary aware site roles. If clients will only use a newly created role based on boundary information then make that part of the configuration process so that admins do not neglect it.