ConfigMgr 2012 should keep the minimalists happy – the architecture is designed for a much flatter hierarchy, and in fact a Single Site ConfigMgr 2012 hierarchy will be a reality for most organizations with less than 100,000 clients to manage. The first important change in SCCM 2012 architecture is the Central Administration Site (CAS), which is in some ways similar to an SCCM 2007 Central Site, but no clients can be managed directly from the CAS.
The key role of the CAS is to coordinate replication of data throughout a hierarchy, so it is not required if you are going to manage your entire environment with a single Primary Site. However, once a Site has been created as a ‘stand-alone’ Site, it cannot be attached to a CAS at a later stage, so if you do need multiple Primary Sites you will need to start with a CAS (in any multi-Site hierarchy, the CAS must always be installed first and the Primary Sites joined to it when they are installed). A CAS also enables a failed Primary Site to be recovered even without a backup. It is also worth noting that only Primary Sites can attach to a CAS, and only Secondary Sites can be attached to these Primary Sites, so effectively your hierarchy will not exceedthree tiers.
Even the role of the Secondary Site is somewhat challenged in ConfigMgr 2012. One of the main reasons for deploying Secondary Sites in ConfigMgr 2007 was to be able to manage network bandwidth for the distribution of content (packages, updates and OS images). In ConfigMgr 2012, distribution of content to remote Distribution Points can be scheduled and throttled in the same manner as site-to-site traffic, so unless you are concerned about the amount of traffic going back to the Primary Site (inventory, status, software usage etc.) you can do without Secondary sites.
It’s worth noting that Secondary Sites require a SQL database in ConfigMgr 2012, however the Secondary Site installation will install SQL Express if a supported version of SQL Server is not
installed locally.
In ConfigMgr 2012, boundaries are used to identify network locations and are available to all Sites in the hierarchy. Boundaries are then grouped together in Boundary Groups, which can be optionally associated with a particular Site for client Site assignment. For example, each of the VLANs in a particular location, like a branch office or a retail store, would be added as individual Boundaries, and these Boundaries would then be added to a Boundary Group that identifies that location. The Boundary Group can then be associated with the Primary Site that should manage that location.