The official blog of the Microsoft System Center Configuration Manager Product Group
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:
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:
More information on the Configuration Manager Support Team blog: Clarification on issues resulting from the use of supernets in ConfigMgr 2007
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.
-- The Configuration Manager Writing Team
This posting is provided "AS IS" with no warranties and confers no rights.
This seems a little backward, in that using supernets in AD site definitions is fairly commonplace in fairly complex networks. However, I have a question...
Could an "IP Address Range" site boundary be used in place of a supernet that is defined with AD site boundary?
e.g. AD Site London:-
London,172.28.4.0/22 <= a supernet
London's physical subnets:-
So, could the boundary be defined as an "IP Address Range" site boundary?:-
172.28.4.1 - 172.28.7.254
We updated this post to replace the reference to the Configuration Manager Support Team blog post "Some ConfigMgr 2007 clients never install packages, report status of "Waiting on content" " with the updated blog post "Clarification on issues resulting from the use of supernets in ConfigMgr 2007".
Can you clarify what the definition of a "supernet" is?
Do you mean that you cannot define two IP ranges, one with a shorter subnet mask and one with a longer subnet mast that overlap? (Like 10.1.3.0/24 and 10.1.2.0/23, which will cover both 10.1.2.0/24 and 10.1.3.0/24)
Or do you mean that you can only use IP ranges that are split along class A/B/C boundaries? (So 10.1.2.0/24 is valid but 10.1.2.0/23 is not valid)
Does this also apply to SCCM 2007 R2?
The information in this blog is applicable for all service pack and R versions of Configuration Manager 2007.
This has made our lives more difficult . I have multiple supernets and majority of clients are failing download . When will microsoft release a hotfix for this .. I believe you just need to update the stored procedures in the database to do that.
Can any body answer Pat's query...??/'