;)
There are many questions to ask yourself or your customer if you are trying to outline the overall System Center 2012 Configuration Manager Infrastructure. When at all possible you should use a Single Primary Site.
In the Beginning, the first question as it relates to infrastructure design that must be asked is whether they have or expect to have over 50,000 Clients if using SQL Server Standard, or 100,000 if using SQL Server Enterprise.
Technical Rules to follow
- A Primary site can only suppport 50,000 Clients when you co-locate SQL on the same server, and it can only support 100,000 Clients* if SQL is on a separate server. If you will go over the count for your configuration, then you would want to use a CAS. Simply put, if you will have more than 100,000 Clients you will need a CAS and Multiple Primary Sites) *The version of SQL “Standard” or “Enterprise” does not increase or decrease client load like the CAS does.
- A Primary Site or all Primary Sites combined cannot have more clients combined than what the CAS can support. A CAS can support 50,000 Total if it is using SQL Standard, and it can support up to 400,000 total if using SQL Enterprise.
- You will have more than 250 Secondary Sites (A Single Primary site can only have a maximum of 250 Secondary Sites.)
- You want more than 250 distribution points. A single primary site can only support 250 distribution points. So you can add secondary sites below a primary to add additional distribution points, up to a maximum of 5,000 per primary and its secondary sites.
Note: Upgrading a SQL Standard to SQL Enterprise later on the CAS or a Primary will not change the limit, for example, if I upgrade a SQL Server Standard version to SQL Enterprise does not reset the 50,000 client support to now support 100,000 Clients because you upgraded the site to SQL Server Enterprise.
Arguments for having more than one Primary Site
There are other reasons to have more than one primary site, but technically the only reasons for having more than one Primary Site technically are above. The below reasons should be addressed as to if they apply to your design or not. It is also important to note that the Configuration manager Site is not a security boundary in that Permissions can apply across all sites and not just one, as was the case in older versions of Configuration Manager
Splitting the Load across two Primary Sites
This idea suggest that you will have a Central Administration Site (CAS), and two Primaries with the thought of splitting the clients across multiple primary sites, with the idea that if you lost one Primary, you could still support half of your environment until the other Primary is recovered. The Pros and Cons of this are as follows:
Pros
- If you lose the CAS or One Primary, then at least one Primary is still functional, as are its Secondary Sites until the CAS or other Primary is brought back online. (The determining factor on if this is truly a Pro is “How long will it take me to get the CAS or Other Primary site back online?”) as well as what the SLA calls for as it applies to Configuration manager within the organization.
- Removes the Single Point of Failure scenario from the design, as clients assigned to other primaries would still be able to report in and be managed. (Please note that is also a Con as shown below in #2.)
Cons
- You now need more at least 2 more servers: a CAS and another Primary Site
- You now have three servers at a minimum that could have outages. This adds multiple single points of failure
- Increased Licensing costs
- Increased hardware costs.
- Increased SQL Replication
- Change latency across the Infrastructure as well as Locking due to replication latency.
Redundancy and High Availability
The data from Primary Sites and the CAS replicates amongst appropriate sites in the hierarchy. The CAS also provides centralized Administration and reporting. It is also important to note that automatic Client Re-assignment does not occur when a Primary Site fails.
The result of a Primary Site failure is that the Primary Site and its Secondary sites communication are now broken, and the Secondary Sites cannot be re-parented. This coupled with the fact that the Client cannot be easily re-assigned in the time it would take to recover the failed Primary Site means there is really not a valid reason to do this unless the time it will take you to recover the Primary site, is greater than the time it would take to reassign and reinstall all of the Secondary sites the failed primary had, and that is usually not the case. So when given this argument the end outcome is usually that this is not a good reason at all.
The rare case that I have seen where this was valid was when the scenario of Natural Disaster or War Type precautions for redundancy are being considered where the other location won’t be coming back online for quite some time, and in that scenario, it could be a valid design… I myself have had two such customers that did it for just this reason.
Geographic
In some cases companies across different countries require that each continent or country can share data, but that they also must be able to still support their country or continents clients must still be manageable. In this case, which is a business case for continuity; it would be feasible to have more than one Primary Site. Making the choice to use another Primary site in this case should be based on connectivity and client count because just using a Secondary site or remote Distribution point should be good enough for Geographic separation.
Political
There are many political reasons used as arguments in adding more Primary Sites, I will write on a few political reasons, though I am sure I have not seen them all. Political reasons are what they are, and sometimes corporations and their IT Departments must reside by specific Governance or other Security factors when building out your SCCM 2012 infrastructure.
Political Argument 1: Separate IT Departments
In some companies the IT departments may be separated out and have different roles throughout the company. Despite what they might think, the Configuration Manager 2012 is fully capable of assigning and isolating privilege within a single primary Site. Great strides were made in Configuration manager 2012 to ensure this argument is invalid. This should not be a reason for adding another Primary Site.
Political Argument 2: Governance and Compliance
With the advent of IT Governance and things such as HIPPA and Sarbanes Oxley, and other Compliance measures to ensure Security there is no True way to “not share” data amongst the Primary sites and the Central Administration site, so isolation of Data cannot be accomplished by adding Primary Sites as that data will be replicated to the CAS, and for this reason multiple Primary sites is not a valid solution. If the Governance and Compliance is truly setup this way, then there will likely be separate forest, separate IT Teams and so forth, which would mean also that a completely separate Configuration Manager 2012 hierarchy would need to exist in order to remain in compliance.
Political Argument 3: Separation of Content
In some cases the content (packages and applications) must remain within that country only. In order to do this, you would need a primary site that could ‘own’ the content. The other alternative would be to have a remote DP in that country but the problem herein lies that the content would be coming from a Primary site in a different country so would not be a viable option. The solution would be to have a Primary in that country that must own the content and a Distribution point pointing its own primary site in said country, this would allow Role Based administration to be used to secure the content and prevent it from leaving that Primary site and distribution point. In this case, a separate primary site is valid.
Political Argument 4: That’s just the way we do things!
In this case, which is sometimes true, and then you really have no choice other than to point out the reasons why and why not and rest your case.
