ConfigMgr – When not to use IP Address Ranges as Boundaries in Configuration Manager

This post from Jason Adams over on the ConfigMgr Team Blog makes fascinating reading. I had always assumed (incorrectly), that IP subnet based boundaries and IP address range based boundaries basically achieved the same thing (bit of course in slightly different ways as their names suggest), but there was’t any real performance “hit” difference between. However, I’m wrong and after reading this post now understand the implications of using the different types of boundaries and I’d recommend everyone using IP subnet/ ranges for boundaries takes a read of this article: “It is often surprising to me how what may seem like innocuous decisions on how to configure settings in Configuration Manager can lead to very different performance results. A case that has come up recently is the difference between using IP subnet based boundaries and IP address range based boundaries. While many users assume that the two boundary types are two varieties of the same thing, they were designed for very different applications and that difference can have a profound impact on the overall performance of your site. The IP address range boundary type was designed to remedy a simple problem. When VPN clients interacted with older versions of Systems Management Server, the precursor of Configuration Manager, the VPN clients did not present a subnet that could be rendered via either Active Directory site or IP subnet boundaries. To remedy this situation, the concept of an IP address range boundary was created specifically to handle VPN clients. The design intent, however, was to continue to use Active Directory site or IP subnet boundaries for non-VPN clients. If you prospect through the Internet, you can find the original guidance on the use of ranged boundaries in the Systems Management Server 2003 documentation. In fact, in the original implementation, ranged boundaries could not be used for site assignment – only for distribution point and management point location requests. Over time, customers have adopted ranged boundaries for uses other than VPN clients. This was not the intent, but should be fine for a small scale implementation of Configuration Manager. However, in recent years, blogs and other commenters have appeared recommending the replacement of all boundary types with ranged boundaries. While it is true that ranged boundaries represent a more granular approach to defining sets of clients, they are often not necessary and in all cases ranged boundaries have a larger performance impact on your site server than the use of other boundary types. As an example, I have heard customers indicate that the lack of persistence of the subnet mask makes them nervous about using IP subnet boundaries. This is often fed by the misperception that the subnet mask is required along with the network ID to identify the subnet a client belongs to. It is true that the subnet mask is essential when configuring a subnet on routers or other networking devices. It is also important to have the subnet mask to calculate the network ID from an IP address. However, once the subnet ID is derived using the subnet mask, it is no longer required by Configuration Manager. The subnet ID is an intrinsic attribute of the system in the Configuration Manager database. This is an important consideration for performance. When Configuration Manager runs a database query to determine if a client exists within a boundary, the type of query required to match the client depends on the boundary type in use. The different boundary types require different queries. In the case of an Active Directory site boundary or an IP subnet boundary, the query attempts to match the exact value of the subnet or the site against a specific attribute of the system. This is a relatively inexpensive SQL query. On the other hand, when the boundary is an IP address range with a range of values, the query requires a complex join against a temporary table composed of all values above the minimum and below the maximum. This last query (for ranged boundaries) is an extremely expensive SQL statement that must be checked for each ranged boundary in the database. Thus, with more ranged boundaries and larger ranges for those boundaries, the query places more pressure on SQL Server. In addition, in System Center 2012 Configuration Manager SP1, we added new functionality that assesses all clients on a regular basis to determine if any client assignments have changed based on new boundaries. This means that boundaries are assessed regularly. The more IP address range boundaries that are used, the more additional pressure is put on the SQL instance. The IP address range boundary fills a gap in the client assignment story for Configuration Manager. For clients on edge networks that lack either an Active Directory site or a subnet, ranged boundaries are an excellent way to extend management capabilities. However, it is important to remember that ranged boundaries are designed for a specific purpose and should only be used in scenarios that cannot be addressed through Active Directory site or IP subnet boundaries. When designing your boundary strategy, we recommend boundaries that are based on Active Directory sites. Where those are not possible, use IP subnet boundaries. If neither of these options are available, then leverage IP range boundaries. –Jason Adams This posting is provided “AS IS” with no warranties and confers no rights.” Original post: http://blogs.technet.com/b/configmgrteam/archive/2013/03/01/when-not-to-use-ip-address-ranges-as-boundaries-in-configuration-manager.aspx