0

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.

Evan
  • 19
  • 2
  • 5

2 Answers2

1

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.

blaughw
  • 2,267
  • 1
  • 11
  • 17
  • It is true, I could look at just the private IP ranges. That would cut down on the range size. We have multiple AD domains and that's not really an option in our situation. We do have multiple physical locations but our backbone is such that locality is not as much of an issue. We're looking at SCCM scale based on capacity. Every primary site you add has the SQL Standard licence fee associated with it so we'd rather grow to multiple sites as capacity demands or just add multiple distribution points to the single primary site and use boundaries to distribute the clients across them. – Evan May 10 '17 at 22:24
0

In my opinion, IP Range boundary is not bad because:

  1. We don't need to create IP ranges manually, instead Active Directory Network Discovery will create all those for us based on IP Subnet.
  2. It's not boundary which is used for MP,DP,SMP or SUP (new feature) but boundary groups. All site systems are associated with boundary groups, not boundaries.

So if you have many physical locations, just create some boundary groups (add corresponding boundaries as memberships) associate with corresponding site system servers, I think this should be working in many scenarios.

Bifeng Dong - MSFT
  • 286
  • 1
  • 4