Official Microsoft blog on IP Address Ranges as ConfigMgr boundaries met with instant rebuttal

On March 1st, 2013 Microsoft posted some guidance on Using IP Address Ranges as Boundaries in Configuration Manager. A day later, the community, and actual ConfigMgr customers started to question the validity of the post and whether or not Microsoft might actually use their own product.

It was met with comments like…

“This goes against the prevailing wisdom of this (community), including my own.”

“It is Microsoft’s own terminology that created the initial confusion around the importance of the subnet mask. That statement has never been clarified to my satisfaction.”

“The paragraph about subnet masks makes me think this person works in a Utopian environment. In the real world the mask doesn’t always match the subnet ID. I’m not saying that’s good practice but that’s the way it is.”

Your thoughts?  As a customer community, we’ve always questioned the differences between the Microsoft way of doing things and the real-world way of doing things.  Microsoft tends to develop products to work a specific way, however they don’t always work the way they were intended in the real world.  Could this be another case of that?  I can’t tell you the number of times I’ve heard from Microsoft “it’s not supposed to work that way”, followed by the customer saying, “maybe not, but it does, and we need it to.”

Read through the March 1st post and let me know your thoughts: When not to use IP Address Ranges as Boundaries in Configuration Manager


Written by , Posted .


  1. The only time I have seen an issue in ConfigMgr or SMS with a subnet or an AD site being used as a boundary is when they have been entered incorrectly. In every case, the issue has been that the wrong IP subnet ID was used. Some people try to cheat and enter to cover a range of separate subnets from to You can’t do this yet I see it done over and over again. I have seen some very smart people make this mistake and insist you can do this. The subnet IDs have to be entered individually:,,,… to

    ConfigMgr has no real knowledge of the subnet mask. Dig through the DB and find where it stores or references the mask, particularly with site assignment. I have yet to find anything. The IPv4 client on the individual systems calculates the subnet ID based on the IP address that is assigned using the mask. This is what the ConfigMgr client and the site systems look at. If a client has an address of / his subnet ID is calculated to be Another client has / his subnet ID is calculated to be

    A blog post last year by one of the MVPs goes into great detail of why IP Subnet IDs won’t work, but the examples in the post would never be encountered in the real world, especially when it comes to supernetting. I have the utmost respect for this person and their knowledge of ConfigMgr, but I have to disagree with their post on this subject In the example they listed, there is a workstation with / and another with / The subnet ID in both case would in fact be, but the reality is that you would never encounter that on a single private network. If you do have a configuration like that, you have much larger problems than ConfigMgr boundaries as you have introduced a conflict with two networks. Routing tables rely on subnet IDs for the destination networks, so how would another router know where to route a packet for a system that had the address versus on with an address when they both had the same subnet ID? It wouldn’t, that is why the example that is sited is not valid and I have seen sited elsewhere in discussions about ConfigMgr boundaries, yet it could not exist in a real world scenario.

    The same is true for subnetting. For example you have two networks one with the subnet ID of / and another with the subnet ID of / Their subnet IDs would be and What I have seen time and time again in ConfigMgr setups is where in a situation like that, both networks fell under the same site and DP, so the admin would enter as a single boundary (or in AD Sites and Services – Subnets) thinking it would cover both subnets, but it actually only covers the lower end of the range.

    What adds to the confusion is that people still think in the terms of Class A, B and C when it comes to addressing, but most private networks use CIDR. Only the high level public address schemes use the class based subnetting.

    The bottom line is that if you have 10 or 10,000 subnet IDs in your network, you have to enter them all, either in ConfigMgr or AD Sites and Services. There is no cheating or consolidating. Enter them all and it will work.

    • Pat Man

      So, to the devil with IP subnet boundaries – where AD sites don’t cover it, just use IP ranges instead and live with the SQL overhead. As Jason Sandys said, IP subnets really are evil …

    • Jay Connor

      Our setup was IP range for IPv4, Subnets for IPv6 (900 inputted)

      We had issues with our Temp DB getting smashed running the query

      We removed the IP range and this did not improve the situation.

      We then removed the 900 IPv6 Subnets and used AD sites instead. Improved the situation immediately, the server is zooming along.

      We still not sure now if there is a limit of IP subnets that causes it to slow down to a halt. Unfortunately we weren’t able to test inputting all our IPv4 subnets (thousands).

      We were seeing a constant IOPS level of 2500, peaking at 7000, now we
      see a max of about 100 IOPS.

  2. One of the main reasons I avoid using Active Directory site boundaries is because of OSD. If you’re deploying operating systems, and you want to apply Software Updates prior to joining the computer to the domain, you absolutely must use site boundaries other than Active Directory sites. This is particularly important for running build & capture task sequences, but can also apply to deployment task sequences as well.

  3. the_prof

    We’ve had constant frustration with boundaries, and the resultant performance of the database. We were not in a position to rely on AD in any way and so had to use ranges for quite a number of systems, which as documented, takes a severe toll on the database. Converting to subnets, as a few people have said, doesn’t always work the way you would expect and doesn’t necessarily improve performance either.

    It makes me question the architecture of the product when something so relatively simple should affect a products performance so drastically. I understand what CM must do in the background to effectively ‘validate’ clients, but it is a symptom of a flawed design.

    It strikes me that there are much simpler methods one could use to effectively decide where to get ones data (i.e. choose a DP), and SCCM makes this process arduous, relatively speaking. Architecturally, some of the reasons behind the relative complexity of the product are understandable, but becoming less and less valid (as we get better networks and more ubiquitous access).

Leave a Comment

You must be logged in to post a comment.