The Realm of the Verbal Processor

To CAS or Not to CAS

WHY Series #1

I figured I’d start the WHY Series with a question that will have an impact on your Configuration Manager design…do you need a Central Administration Site or not? To CAS or not to CAS…that is the question.

First let’s address a key difference between Configuration Manager 2012 and 2007. A Central Administration Site (SCCM 2012) is NOT the same as a Central Primary site (SCCM 2007). A CAS cannot have clients assigned to it. It cannot have all SCCM site roles. It is for administration and reporting ONLY. A CAS can only have primary sites as child sites…no secondaries attached to a CAS. It isn’t just a new name…it is fundamentally different. With that said…why would you or would you not need a CAS?

When you get right down to it, the question of whether or not you need a CAS boils down to a different question…”will I need more than one primary site?”. If the answer to that question is no…then you’ve also answered the CAS question…no you don’t need a CAS. You only need a CAS if you have more than one primary site. So…with that being the REAL question to ask…let’s look at reasons why you would need multiple primaries.

Scalability

The primary reason why you would need multiple primaries is scalability. There are certain requirements from a technical limitation standpoint that force the need for a second primary. Per the documentation these include:

• More than 100,000 clients. If you are currently or expecting to grow beyond 100,000 clients, congratulations, you get a CAS because the published client count limitation for a single primary site is 100,000.
• More than 10,000 Windows Embedded clients with File Based Write Filters (with proper exclusions implemented). (3000 if the listed exclusions are not implemented)
• More than 50,000 MAC clients.
• More than 250 Secondary sites
• More than 250 Distribution Points (although note that each Secondary site can have 250 DPs as well. With that in mind the aggregate total of DPs…those directly attached to the primary and all of the DPs attached to all of the secondary sites is a maximum of 5000 DPs)

Just in Case

Let’s go ahead and deal with an argument that came up with the RTM of SCCM 2012…the “just in case” scenario. This came about because at RTM, you had to install a CAS first in the hierarchy…you couldn’t attach a primary to a CAS after the fact. So, some companies chose to install a CAS “just in case” they would ever need one. This often came up when talking about a merger…that you would want a CAS in order to pull the other company into the hierarchy. Well…what if the other company had better hardware? What if your company was going to be the “child” company after the merger? Well…now you get rid of your CAS anyway…and you had unnecessary complexity in your hierarchy for nothing. Really, the “just in case” argument was always a weak/bad argument.

With the release of SP1 for SCCM 2012, it is now possible to join an existing primary to a CAS…the CAS no longer has to be the first thing installed in the hierarchy. Since it now IS possible to join an existing primary site to a CAS…the “just in case” scenario is completely blown away.

Conclusion:

Unless you meet (or are approaching) one of the scalability limitations, assume that you do NOT need a CAS. Keep your design simple. Always always always start with a simple design…then add complexity to meet either business or technical requirements. But ONLY add complexity to address one of those requirements. In general assume that you do NOT need a CAS unless specific requirements (business or technical) make it necessary.

Until next time…keep asking the right questions.

April 22, 2013 - Posted by Jarvis | ConfigMgr 2012, WHY Series | design, hierarchy, scalability, SCCM