TL;DR is an SCCM IP address range boundary of 0.0.0.0-255.255.255.255 going to cause major performance issues?
We're beginning to roll out SCCM (currently 1702) for use as a Windows patching solution. We've got a complex network of many AD domains and IP subnets and the only viable boundary solution I see for us is IP address ranges (since SCCM doesn't understand supernets) but I see boundaries as becoming tedious to manage as new subnets come online.
Currently we only have one Primary Site Server that all clients report to. I've done a lot of reading up on how SQL intensive IP boundary calculations can be and I'm trying to understand what the best option would be. Bigger ranges? or more, smaller ranges?
Right now I've got IP address range boundaries for our commonly used private IP prefixes and just made IP ranges for the entire /8 ranges to encompass all of the /24 subnets with that prefix.
Example: A boundary of 192.0.0.0-192.255.255.255 to encompass multiple 192.168.x.x subnets.
If I redesign the boundaries to just one boundary of 0.0.0.0-255.255.255.255 is that going to cause performance issues? And what about if I add a second site server where I want certain subnets to report to that site server so then I'd have something like:
0.0.0.0-191.168.9.255 > Boundary Group 1/Site A
192.168.10.0-192.168.50.255 > Boundary Group 2/Site B
192.168.60.0-255.255.255 > Boundary Group 1/Site A
At the high end we're looking at about 10,000 clients so I don't know if the articles about these SQL performance issues are for much larger installations or if the whole problem is over-hyped.
Best Answer
You should consult a professional. With 10k clients, I'm guessing you have several physical sites, and this would be key in designing SCCM boundaries. Half of the purpose here is to ensure clients are talking to a local management server. The other half is not literally losing your mind when it comes to management.
I see no mention of physical sites mentioned, and it may be a considerable amount of work to align IP subnets with physical locations.
I also see problems with your example IP ranges. You should start by only including your Private IP space, whether it is 10.0.0.0/8, 192.168.0.0/16 and/or 172.16.0.0/12.
Every org is different, but if your Active Directory sites are in "good" shape, this might be a better option for configuring SCCM Boundaries.