We have received a number of requests for more information in response to the following two blog posts:

• Known Issue: Supernets in Active Directory sites used as site boundaries
• Some ConfigMgr 2007 clients never install packages, report status of “Waiting on content”

The statement that "Configuration Manager does not support supernets for site boundaries" remains true, because Microsoft didn’t intentionally design or test Configuration manager for supernet scenarios.  After doing some testing in my lab, however, I can more clearly explain when the use of supernets should and should not cause issues with respect to site assignments and Client Push and with clients locating package source on DPs.

The key to understanding both scenarios is to consider the data available and from which perspective it is gathered.  It is also important to note that Active Directory (AD) has logic to verify whether a client's IP address lands within a specific subnet, regardless of the mask listed for the subnet in AD, while SCCM only performs this type of calculation for IP ranges.  For example, AD can tell that a client with IP 192.168.121.100/24 does fall under the IP subnet 192.168.120.0/23 while SCCM will compare the client's real IP subnet, 192.168.121.0, with 192.168.120.0 and come to a different conclusion.  Only when an IP range is used in SCCM, where the numbers are converted to 32-bit decimal values, is SCCM able to verify that the client IP above really does land in the 192.168.120.0/23 subnet.  Below are a couple of specific examples to help with this understanding.

Site Assignment/Client Push

AD System Discovery (ADSysDis) queries DNS for the IP address of each client discovered in AD.  As neither DNS nor AD itself contains the client's IP subnet or subnet mask, ADSysDis calls a Directory Services API with the client's IP address to get the AD Site and closest matching IP Subnet within that site in which the IP address falls.  The resulting information is written into a Discovery Data Record (DDR) file to be processed by Discovery Data Manager (DDM) later.

If Client Push is enabled, DDM evaluates the data in the DDR file and compares the AD Site and IP Subnet information contained with the configured SCCM site boundaries.  If the AD Site containing the supernet is also in the site boundaries, the client is considered to be Assigned = Yes and things work normally.  If the supernet listed in AD is directly listed as a site boundary, the same is true.  If, however, the client's real (non-supernet) subnet is listed as a site boundary, the client is not considered to be assigned and no Client Configuration Record (CCR) file will be created for Client Push to act on.

For example, using this intended client:

Name:  WK01-110-51W - IP:  192.168.110.100 - Mask:  255.255.255.0 - IP Subnet:  192.168.110.0

and this sample AD Site:

Name:  AD-Site-1 - containing IP Subnet:  192.168.0.0/16

When AD System discovery runs, using the configuration above, it finds WK01-110-51W as a computer in AD, looks up the client's IP (192.168.110.100) address in DNS and ensures that it can ping the machine before creating a DDR.  If so, we query AD for the AD Site in which the client falls and find the closest matching IP subnet within the AD Site that covers the client IP, as obtained from DNS.  In this example, that IP Subnet would be 192.168.0.0.

When DDM processes this DDR file from this example, it will only have the IP Subnet of 192.168.0.0 for this client.  If the site boundaries contain the AD Site or the 192.168.0.0 subnet itself, the client is in the boundaries and a CCR will be generated.  The same is true if an IP Range of 192.168.0.0 - 192.168.255.255 is listed as a boundary.  If the site boundary contains only the client's real IP Subnet of 192.168.110.0, the client is not found to be in the boundaries and no CCR is created.

Package Source Location

When clients attempt to locate package source for a specific package, they post a request their current MP containing the package ID, package version, the client's assigned site code, the client's IP address and calculated IP subnet.  The MP executes three stored procedures to get a list of child secondary sites below the assigned site and to get site codes where the provided AD Site and/or IP address are assigned.  From there, two more stored procedures are run to get lists of protected and unprotected DPs which are hosting the proper version of the specified package.  This list is returned to the client so that further logic can be applied on the client to choose the best possible source.  If the details provided by the client initially do not match the data in the database, an empty list will be returned to the client and 'No matching DPs available' is reported.

For example, Using these two clients:

Name:  WK01-120-51W - IP:  192.168.120.101 - Mask:  255.255.255.0 - IP Subnet:  192.168.120.0/24

Name:  WK02-120-51W - IP:  192.168.121.100 - Mask:  255.255.255.0 - IP Subnet:  192.168.121.0/24

this sample AD Site:

Name:   AD-Site-120 - containing IP Subnet:  192.168.120.0/23

and the DP hosting package source protected with the AD Site name, both clients are able to locate and execute the package program.  This is true because the clients know their AD Site, from AD itself, and provide this information to the MP when they request version x of package y.

If the DP is protected with 192.168.120.0 then WK01 works but WK02 reports that it cannot locate a local copy of the package source.  This happens regardless of whether 192.168.120.0/24 or 192.168.120.0/23 was added to the site boundaries because SCCM only uses the mask to calculate the IP subnet in the wizard and does not actually store it.

If the DP is protected with 192.168.121.0 then WK02 works and WK01 fails, as expected.  Changing the subnet mask of both clients to 255.255.254.0 results in each calculating their IP subnet to be 192.168.120.0, so protecting the DP with either 192.168.120.0 or the AD site name allows both to work.  Protecting the DP with an IP Range of 192.168.120.0 - 192.168.121.255 also works as the clients' IP addresses both fall within this range.

Conclusion

As noted at the beginning of this writing, SCCM does not support supernets.  The examples above are intended to provide an understanding as to when use of supernets should and should not cause issues with site assignment/Client Push and package source location lookup.  Hopefully this information assists in site design around and troubleshooting of such issues.

Note: This information was originally contributed by Keith Thornley, Senior Support Escalation Engineer, on the Configuration Manager Support Team blog:

http://blogs.technet.com/configurationmgr/archive/2010/03/22/clarification-on-issues-resulting-from-the-use-of-supernets-in-configmgr-2007.aspx