Boundaries how subnets and ip ranges are actually used internally by ConfigMgr 2012

Saud Saud Al-Mishari has taken a different stance on the topic and instead produced something extremely worthwhile. Instead of providing a rebuttal one way or the other, he has put together a nice piece on how subnets and ranges are actually used internally by ConfigMgr 2012 and then talks about what he sees customers doing


Subnets in a ConfigMgr are a client-side (or more accurately a network host) view of networking. We’ll comeback to that in a second; however, that is one of the major reasons supernets don’t exist in ConfigMgr (let alone being supported). Supernets are a network construct for a way of grouping like subnets to make their management and routing more simple. A supernet is like saying all of Japan is supernet A, composed of Tokyo office subnets 1, 2 & 3. We might want to serve that location through a single ConfigMgr server or site.

That said, let’s go back to client-side. A client only knows about its IP address and subnet mask. It doesn’t know anything else. It uses that to determine if an IP address is local or remote (something that needs to be routed by a gateway/router). It is the ConfigMgr client on that network host (Windows device) that determines its IP subnet by applying its subnet mask against its IP address.

Now – you might think that’s simple and too basic; but it is the ConfigMgr client that drives this entire subnet process. It’s a client sends content location request, along with SUP and MP list within 2012. When a client does a location request to the MP for content (e.g. packages) it does so by supplying its subnet to the MP. You can see this by turning on trace logging and looking at Location Services log files or the MP log files (if you have a few clients) – or even firing up NetMon and doing a network trace. The MP passes the subnet by calling a SQL query with that information to determine if the content/site system is available on that subnet or a remote one (Jason discusses this more in his blog, This is a fairly straight forward comparison of the supplied subnet against a list of subnets. Obviously…as you get more and more subnets this gets more computationally expensive – but it still string lookup against a list of strings, not the end of the world in SQL complexity.

IP Ranges

IP ranges are conceptually simple. They aren’t even really supernets, there just a range of addresses. The determination of if a client falls into a range, unlike a subnet, is done by the ConfigMgr server infrastructure. Specifically it is done by SQL Server. Again, in the location request you’ll see an IP address sent up by the client. The MP passes that to the SQL Server, and the SQL Server does the determination of where that IP address falls into. Again, Jason discusses this further and discusses why this is a more complex operation than a simple lookup of a subnet we talked about above. Since the individual query is expensive, adding lots of them burns up more SQL Server resources.

Real world

Some customers I have worked with have subdivided a subnet into two different IP ranges to support different sites serving different departments or client types. For example, PCs can only talk to Global End User team’s server (not my North America team’s server) or Retail Banking cannot talk to Treasury servers (if they contained the same packages). That’s an example of something bad, and something I’d strongly advise my customers against when working with them. Valid ways of using might include (I say might include because the below is not exhaustive):

You might use IP Ranges when you have been provided with supernets by your networking team (in my Tokyo example, I might group those three subnets into a single IP Range).
You might use them when your AD sites have been consolidated heavily and DC have been consolidated. This helps you maintain granularity needed for ConfigMgr.
You might use them you have a tremendous amount of subnets in your environment (you network team is using subnet masks like or .192 to create very small ranges)
You might also need them when dealing with the VPN client scenario (naturally 🙂
The key is – don’t just start throwing IP Ranges just because they work. Have a think about it. Know the trade-off when using something more complex internally within the product and costs you more database perf resources but easier to administer. It’s a trade off…


Keeping boundaries consistant with network changes

If you are using Active Directory for your site boundaries, you can monitor the Windows
System event log for specific event IDs based on the version of Windows Server:

▶ For Windows Server 2003 and Windows Server 2008 domain controllers (DCs), look
for Event ID 5807, Type: Warning, Source: NETLOGON on each DC.
▶ On Windows 2000 domain controllers, the Event ID will be 5778.

This event indicates that one or more computers have connected to the domain control-
ler from an IP address that is not part of a defined Active Directory site. For informa-
tion on troubleshooting and remediating this issue, see

Planning Boundaries 2012

AD site and IP subnet boundaries suffer from the same major shortcoming: They do not
work correctly with the Classless Inter-Domain Routing (CIDR) method commonly used
in networking today. CIDR uses variable length subnet masks (VLSM) to provide more
flexible addressing than the older class A, B, and C IP subnets. Both AD site and IP subnet
boundaries assume the use of a specific subnet mask based on the legacy “class” assign-
ment of the specified subnet. Here is an example of the problems you can run into using
these types of boundaries.

An AD site used as a boundary contains the IP subnet of–
or 192.168.14/23. ConfigMgr calculates the subnet ID as If you now have
a client with an IP address of with a subnet mask of, or, the calculated subnet ID is Although the client’s IP
address is clearly within the range specified in AD, the subnet ID comparison does not
match and the client is not assigned during discovery.

In addition, clients unable to retrieve site information from your AD, such as workgroup
clients or clients in domains that do not have a trust relationship with your site server’s
domain, cannot use AD sites as boundaries. For these reasons, IP ranges or IPv6 prefixes
are usually the best choice for defining boundaries.