SCCM 2012 Hierarchy Demystified

With the introduction to System Center Configuration Manager 2012 Microsoft introduced changes in the Hierarchy from 2007. It can be a very tedious task to dig through all the TechNet articles to try and figure out how you should architect your SCCM 2012 deployment. A lot of the information out there leads you right back to version 2007 with assumptions that you will figure out what still applies and what doesn’t. I tried to summarize some of the most important changes so you can get some clarity on how to architect your environment.
Previous SCCM 2007 Hierarchy
CENTRAL SITE: Is the top of the hierarchy with all SQL data rolling up to this point. Could operate the same as a Primary and can administer any site below it in the hierarchy and can send data down to those sites as well.
PRIMARY SITE: Clients are assigned directly to the Primary, has access to a Microsoft SQL Server Database, Can administer or be administered via the Configuration Manager Console, It can be a child of other Primary Sites and can have Primary Child Sites of its own
SECONDARY SITE: A Secondary Site does not have access to a Microsoft SQL Database, Secondary Sites are a Child Site of a Primary Site and can only be administered via a Primary Site, Secondary Sites cannot have Child Sites of their own, and Clients can be  assigned to the Site once it has originally registered with the Primary.
SITE SYSTEMS: Any System that holds a SCCM Role.
New SCCM 2012 Hierarchy
CENTRAL ADMINISTRATIVE SITE (CAS): Sits on top of the SCCM 2012 Hierarchy, Cannot directly manage clients, Used when multiple primaries are needed like having over 100k clients, can manage all SCCM 2012 Site Servers from one console. (See more on How the CAS server works below)
PRIMARY SITE: Works the same functions as 2007 except No ability to tier primary site servers – they are only peers in a hierarchy with a CAS, No need deploy a primary site server to support different settings, policy, and administrative control, No need to tier for content routing, language neutral support you may install multiple languages per primary site, Client settings are now applied at the collection level and not at the primary site, Administration is logically segmented through role-based settings and scopes and not by using a separate primary sites
SECONDARY SITE: Now have SQL Express to replicate, control the upward flowing traffic, clients can be assigned a local management point (Note: All clients still have to register with a Primary first before they are assigned the Secondary MP, can be used as local SUP. Still has to be managed from primary.
SITE SYSTEMS: Systems that hold a SCCM role
What Do I Need?
So with all the basic hierarchy info explained above the question remains on what are the common deployment scenarios used with SCCM 2012. Do we use a CAS or not use a CAS? What are the circumstances where you would deploy multiple Primary servers calling for the need for a CAS? When do we deploy a Secondary Site Server VS using just DP/MP roles to a site system?
Every SCCM deployment architecture needs to be considered based on the customers environment with these in mind.

• Clients – The total number of clients to be managed and amount of clients per location.
• Security – Segmented Networks like PCI and DMZ environments
• Political – Need for Segregating Administration geographically
• Infrastructure – Forest, Domains, Sites, Firewalls, Workgroups, Internet Clients, Bandwidth

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

With this in mind I will give you a few scenarios that have the need for different Architecture.
Single Active Directory Forest
The most common scenario used to deploy SCCM 2012 is the deployment of a single Primary Server with DP/MP strategically place throughout the locations. Since Each Primary site supports up to 250 secondary sites, up to 250 DP/PXE and up to 100k clients machines attached, this can support most companies looking to deploy SCCM 2012. Always consider using Distribution Points VS Secondary Sites and use multiple MPs for redundancy for communication for the clients. You also can throttle data from the each individual DP itself. Keep in mind Each primary can have only 10 MPs so if you have a need for more without expanding to Multiple Primaries you could then use Secondary’s Site servers for additional MPs but this adds SQL replication traffic and more points of failure to troubleshoot if there are issues. I have seen much improvement in using secondary sites where there is limited bandwidth and you need to control the client traffic. By placing a secondary site with MP, SUP and DP roles on a site creates very little WAN traffic coming from that clients at that location. One more note on secondary sites is that the only way to guarantee traffic flow to a MP you want your clients to connect to is to have a secondary site or another Primary site with a CAS server. Just having MP roles spread out across the organization does not guarantee that clients local to those MP will connect to those MPs unless you use a Primary or Secondary site at the location. One thing to note is MP traffic is very small, if there is not a need to localize the SUP than I wouldn’t use a secondary site. With the new bits functionality, site boundary assignments with logical DP assignments I have yet to use secondary sites even in global deployments but I am aware of a company that used over a hundred of them because they had small satellite links with big latency issues and it worked great.
Segmented secure Networks with single point to manage (Multi-forest, Large DMZs, PCI)
Here is a situation that is very common scenario. Many companies out there have this kind of Infrastructure in place especially if you are dealing with industry where compliance is regulated. These systems are highly secure and usually segmented from the corporate environment by firewalls, and separate Active Directory forest. The straight forward approach is to just have separate SCCM 2012 Hierarchies for each segmented environment but this will add a lot of extra administrative tasks like manually duplicating all your configurations in each hierarchy. Another approach would be to manage these systems via SSL Certificate but this requires a PKI infrastructure and limits some functionality like OS deployments. This is a good choice for managing systems in a DMZ and you can use a reverse proxy or open 443 internal to get this to work. SCCM 2012 no longer has Native mode so it can manage internal clients via port 80 and Internet clients via 443 at the same time.
If you are going to want to manage multiple segmented environments from a one console than you will need to have Kerberos authentication ability across the environments with a list of open ports across firewalls. Best practice for this would be to have a transitive forest trust for multi-forest and to limit opening ports just between Site Server to Site Server. In this scenario you would need to have a CAS server because the site server would need to be a primary so clients can register without having to open the firewall to all clients. With this you can manage all the systems in the secure network.
Another method you can use if a Trust is available and you want to limit the ports open would be to install a secondary site server. This would still require ports to be open from Site Server to Site Server limiting the cheese grater effect on the firewall. With this approach you will still need to open a port for clients to initially register with the primary server (port 80/443) but this can be customized for clients to use whatever port you want. After the clients register with the Primary you could then close the port and the client can use the secondary site as a local MP for all client management at that point. Even though the Proxy Management role is not an option the secondary site server still acts like a proxy management server. Some features will still be unavailable because they require direct communication from the Console to the client like Remote Access functions, Wake on LAN, and third part tools like Right Click Tools. They still need ports to be open to work, but this way allows very secure networks with the ability to limit opening a bunch of port and the best part is you will not need a CAS server nor PKI unless you use Port 443 then you still need PKI.
If the trust is not an option but you can open firewall ports for clients to communicate with the Primary site server than you could manage the segmented systems as a workgroup but you would need to have a way for the clients to locate the MP so special install commands would be used and DNS would need to be configured for the clients to find the Primary Site. There are a list of ports that would need to be open but some of them can be changed to using custom ports.
The Central Administrative Server (CAS)
There is a lot of blogging going on about whether you should install a CAS in your SCCM Hierarchy or not. Most opinions are to not use a CAS unless:

• You are installing multiple Primaries
• Have over 100k Clients

Keep In mind the CAS server has to be a pretty beefy machine.  Microsoft recommends 16 cores, 64 GB of ram and 1.5 TB disk space for all the files. The reasoning behind this is because the CAS function is to replicate all data from every primary and also functions as a reporting server. This is how Microsoft could move from the Parent Child Primary hierarchy where data replicated from the bottom up. Now it replicates horizontally via the CAS. So you can say in a way it’s like an SQL proxy taking data from one SCCM SQL instance and duplicating it on another. The CAS also enables the administration of hierarchy-wide configurations for client agents, discovery, and other operations. When a CAS exist use this site for all administration and reporting for the hierarchy. You can Join a primary to a CAS if you discover later that you have a need for multiple primaries. This does not mean you can deploy multiple Hierarchies and then join them later with a CAS. You can only join one existing Primary to a CAS, then after that you deploy your other Primary servers.
With all this said I can go on and on about the specs on all the feature and functions of SCCM 2012 but I just wanted give you an idea on which direction you should go more than the specific configuration. I hope this gave you a good overview so you can have some clarity about how to get this going in your environment.