We have recently updated the Configuration Manager Documentation Library regarding site boundary configurations. This change was made to clarify the use of supernets, which remain unsupported but have been a source of confusion resulting in support calls. The confusion comes when an Active Directory site is configured as a boundary and that Active Directory site contains one or more supernets.
Configuration Manager does not support supernets for site boundaries. This includes supernets defined directly in the Configuration Manager console as IP subnets, and supernets defined indirectly in the Configuration Manager console as Active Directory sites that contain supernets. Supernets can result in inconsistent behavior for Configuation Manager actions that use boundary configurations, such as site discovery and auto-site assignment for clients, and content location for when clients find distribution points to download packages.
Two common problems you might see when using supernets include the following:
Clients are unable to discover and to automatically assign to the correct site.
Clients fail to download packages because they are not given the expected distribution points .
It's easy to miss that supernets might be the underlying cause of these problems because of inconsistent behavior. Some clients that use supernets can behave as expected, while others do not. Configuration Manager 2007 was not designed to support supernets as boundaries, and while this configuration might work for some clients, it remains officially unsupported.
When clients exhibit unexpected behavior for boundary related tasks, validate that you have only supported boundary configurations in the Configuration Manager console and within the Active Directory sites configured as boundaries. For example, if you find that you've defined an Active Directory site as a boundary and this Active Directory site contains supernets, remove the Active Directory site boundary configuration and replace it with the exact subnets.
If this reconfiguration is not practical because of high administrative overheads, you might consider adding the relevant subnets to supplement the existing boundary configuration. This approach might eliminate the requirement to specify each subnet. We've heard that some customers have been successful with this configuration but it has not been tested by the product group and so it remains unsupported. For example, one possible consequence of this configuration might be that clients are given incorrect distribution points, such as a protected distribution point across a WAN when this was not your intended behavior.
The December documentation update clarifies the unsupported configuration of using supernets for boundary configuration in the following topics:
Many thanks to our colleagues in CSS - Clifton Hughes, Keith Thornley, Ryan Anderson - for bringing this to our attention, and to Brent Dunsire who helped us to clarify the use of supernets in the documentation and provide this additional information for customers.