With 2012 release of System Center Configuration Manager, planning and designing a hierarchy became a bit more difficult.
Not because of the limitations, but because of the huge mix of different possibilities you have.
For instance with the introduction of CAS role (Which sits on the top of the hierarchy and is used for management purposes of many primary sites) you have even more options of how to manage your infrastructure.
In addition, with SP1 you have even more options, for instance you can now have more than one SUP for a primary site. (Which you could not have before SP1) and that the CAS SUP now doesn’t need to sync directly with Windows Update as well) so this post is what factors you need to think of in terms of planning and how to manage the devices. In addition, for many which have multiple domains, trusted and untrusted, and in different forests and depending on how you want the flow of traffic to go it takes a lot of planning!
This post is meant as a guideline and might not always present the best options but just to show some possible examples of how you deploy Configuration Manager 2012 SP1.
Now first I am going to define how the hierarchy in Configuration Manager looks like.
In the first picture we have a stand-alone site (Primary Site) in the secondary picture we have a Primary site with two secondary sites.
In addition, in the last picture we have the CAS with three primary sites and with their secondary sites.
Source: http://i.technet.microsoft.com/dynimg/IC638818.gif
First I’m going to specify the limits of each hierarchy role:
CAS: (Does not process client data, and does not support clients assignments.
400.000 clients (If you use SQL Enterprise) 50,000 if you use standard.
25 Child Primary Sites
Roles:
Asset Intelligence synchronization point (Can only be one in the hierarchy)
Endpoint Protection point (Can only be one in the hierarchy)
Reporting services point
Software update point
System Health Validator point
Windows Intune connector
Primary Site:
250 secondary sites
100,000 clients (50,000 clients if the SQL is installed on the same computer as the site server)
10,000 WES clients
50,000 Mac
Roles:
Application Catalog web service point
Application Catalog website point
Asset Intelligence synchronization point (not if it’s a child primary site)
Distribution point
Fallback status point
Management point
Endpoint Protection point (not if it’s a child primary site)
Enrollment point
Enrollment proxy point
Out of band service point
Reporting services point
Software update point
State migration point
System Health Validator point
Windows Intune connector (not if it’s a child primary site)
Secondary Site: (Must be linked to a primary site, MP and DP are installed automatically, installs SQL Express if nothing else is available)
5,000 clients.
Distribution point
Management point
Software update point
State migration point
Software Update Point:
25,000 clients (That is installed on the same server as the site server 100,000 else)
After SP1 (Supports multiple SUP per Site)
Distribution Point:
4,000 clients
250 DP per Primary Site
250 DP per secondary site
10,000 packages and applications
Management Point:
25,000 clients
10,000 Mac computers
10 MP per primary site
Now there are some roles that cannot be deployed in a untrusted domain:
These are out of band service point and the Application Catalog web service point.
But always think simplicity, so if it is possible avoid the CAS role where it seems logical.
(1 domain) ( 1 location ) 1 Primary Site
Depending on how many clients you have in your infrastructure, but with one location and one domain this is only and easiest way to go ahead, for high-availability purposes you should have 2 of each system role and a clustered SQL server for the site server.
( 1 domain ) ( 2 locations) 1 Primary Site 1 Secondary Site (Slow link)
Lets for the purpose of this post say that you have 1 location where you have most of your infrastructure, you have one remote site with 200 clients which has a limited connection to the primary site, one secondary site on the remote location would be the best approach. Clients there would talk directly to the management point and the distribution point of the secondary site.
(1 domain) ( 2 locations) 1 Primary Site and 1 Distribution Point (Fast link for secondary site)
In this case we have also a remote location but we have a fast wan link so we don’t need a secondary site which has the agents and the applications and packages. Therefore, we have a distribution point at the remote location and clients communicate with a MP in the central location.
(1 domain) (2 locations) ( one small branch office )
I would recommend using branch cache on a distribution point and for the clients, when the first client requests content from the DP it will download it and cache it for other clients on the same subnet. This requires a DP installed with Branch cache.
NOTE: Remember that for a remote domain installation to work properly you would need to install the management point with an account that has access to the Configuration Manager database. You configure this during the installation of the Management Point.
( 2 domains untrusted forest ) ( 1 locations) 1 Primary Site in Primary (1 Management Point 1 Distribution Point)
Now we cannot install a primary or secondary site in a untrusted domain, we can only install user facing system roles in a untrusted domain. So therefore, we install a management point and a distribution point in the untrusted domain.
And we can also publish the site in AD for the untrusted domain as well.
( 2 domains trusted forest ) ( 1 location )
This depends on the number of clients but again a solution with a distribution point and a management point in the other domain could be a solution. In case there are too many clients, you would need to expand the hierarchy with a CAS and a primary site in each forest.
(Multiple domains untrusted) (Multiple domains)
Primary site or depending on how many clients. Use Primary Site in one domain (Pref the largest one) and deploy a distribution point and a management point in the other domains.
Here I will also link to some example hierarchy scenarios from Microsoft
http://technet.microsoft.com/en-us/library/gg712989.aspx
Identify requirements to plan for a hierarchy
http://technet.microsoft.com/en-us/library/gg712310.aspx
I would also recommend that you read Microsoft’s own hierarchy for their internal Configuration Manager solution
http://blogs.msdn.com/b/shitanshu/archive/2011/10/16/configuration-manager-2012-deployment-real-world-experience-part-1.aspx