ConfigMgr 2012 : Central Administration Site

I’m currently working out a suitable design for a System Center 2012 Configuration Manager deployment. One of the first things that you need to decide is your site hierarchy, specifically should you implement a Central Administration Site (CAS) with Primary Site(s) model or simply a Primary Site with Secondray Site(s) model. You may be one of the ‘lucky’ few where your design is simple and will always remain so!

Having looked into this, and event tested both in a lab I thought I’d share my opinion and experiences, one thing I should make clear at this point in time – there is no single reason for considering whether or not to use a Central Administration Site, in fact sometimes there are political or business reasons to adopt this model regardless of any technical requirements.

The environment i am deploying Configuration Manager into is geographically diverse, with many Internet (VPN) based users and remote sites. That said either of the models presented below will allow for successful management of all of these users.

Below is my representation of the facts/opinions I found during my decision making process….

 

Pro-CAS/Primary Site Deployments

A Central Administration Site offers immense scalability for your Configuration Manager deployment, I mean immense. A CAS can support 25 Primary Sites totalling a staggering 400,000 clients (as long as you are running SQL Enterprise Edition and have allocated the required hardware resources). Each Primary Site can support 250 Secondary Sites, each of which can support up to 5,000 clients (maybe more if you size hardware correctly).

By deploying a CAS you facilitate deployment of additional Primary Sites in the future. If there is an acquisition looming or that is possible where a Secondary Site would not be appropriate then this could be a deciding factor. Remember though, you cannot add a previously deployed standalone Primary Site to your CAS at a later date.

In a large environment it may be necessary to segregate Site Administration (note this alone is not a reason for a CAS due to Roles Based Administration), with a CAS you are still able to report on the entire hierarchy regardless of administrative delegation. All client data is replicated to the CAS. Site Administrators can be defined that only have permissions to connect to their designated Primary Site for management/administration.

 

Anti-CAS/Primary Site Deployments

Remember that no client can report to the CAS – therefore if you want to manage clients where you deploy your CAS you are either going to have to deploy an additional ConfigMgr Primary Site, point clients at that site to a Primary Site elsewhere or deploy a Secondary Site… sound messy?

By deploying a CAS you have additional server(s) and an additional database instance to manage.

 

Pro-Primary Site/Secondary Site Deployments

This model still offers scalability; a Primary Site supports up to 100,000 clients and 250 Secondary Sites each of which can support up to ~5000 clients. SQL express is a supported and suitable option at a Secondary Site, this reduces administrative overhead, cost and complexity.

Simplicity – System Center 2012 Configuration Manager is designed to help reduce site count over System Center Configuration Manager 2007; this model falls in-line with that ethos where possible (i.e. you have reviewed all of the pro’s and con’s!)

Streamlined management; there is a single connection point for Configuration Manager administration

Client data is replicated from Secondary Sites to Primary Site; centralised reporting.

Secondary SItes contain no configuration data, if you have a serious issue with the site you can simply uninstall it and redploy it  (as well as pushing ackages back to the DP) without losing client information/data.

 

Anti-Primary Site/Secondary Site Deployments

Not as scalable – i.e. 100,000 clients is the ceiling (for many is this an issue?!)  – you cannot join to a CAS at a later date nor can additional Primary Sites deployed into the same hierarchy.

Management console must be served out of the Primary Site, if this is remote you’ll have to use RDS/Citrix so there is some increased complexity and cost potentially.

Increased replication of packages from Primary Site to Secondary Site; packages must (OK, should) be created at the Primary Site and then replicated. If you create a package where the source is across a WAN connection you’ll find that the signature file generation and creation of that package takes a LONG TIME. This applies with OS Images/installers too, so if, for example, you perform a build and capture at the Secondary Site, you’ll need to copy the image back to the Primary, add the image then distribute the image back to the DP in the Secondary Site… messy!?!