As we already know, a Configuration Manager hierarchy starts with either a central administration site and a primary site in a hierarchy or just a single standalone primary site. Unlike in Configuration Manager 2012 RTM, in Configuration Manager 2012 SP1 you cannot add a central administration site later; you can do this in the R2 version. It should be noted though that you cannot remove a central administration site later on with any version of Configuration Manager 2012. This means you no longer have to make any large assumptions about the size of your hierarchy years down the line.
It is important to mention at this point that the central administration site is not a direct replacement for the old central site in the previous versions. The way the hierarchy works is different from the previous versions, so it would be difficult to compare the two. In Configuration Manager 2012, the central administration site is used as a central location for both administration and reporting. While some site system roles can be deployed to the central administration site, you cannot assign clients to the central administration site.
In the previous versions of Configuration Manager, we used a central site to address many issues, such as:
Splitting the management of servers and client machines
Segregating permissions between sites
Applying different client settings to servers and client machines
Internal political reasons
Configuration Manager 2012 has gone a long way in answering many of these points, meaning that we can now deploy a single-flat hierarchy, which is both easy to manage and gives us the flexibility to delegate the management of different environments or devices to our support teams as well as properly define permissions for the whole hierarchy rather than at a single-site level.
Tip
If you are coming away from a Configuration Manager 2007 environment, think about the reasons you may have had to deploy multiple sites in Configuration Manager 2012. Those reasons have probably gone.
Now, the golden rule for a central administration site is that if you are managing more than one primary site, then you require a central administration site to manage them both centrally. For this reason, most of you will not require a central administration site. This is because a standalone primary site can support up to 100,000 clients.
It should also be noted that the design should be as simple as the requirements allow and that a central administration does not provide high availability, which is a common misconception.
To give you an idea in terms of supported numbers of clients, when you are supporting Windows Server, Windows Client, and Windows Embedded operating systems as well as Linux and UNIX clients, then a standalone primary site will support up to 100,000 clients.
Devices that are managed by Windows Intune or the Exchange Server Connector will support up to 50,000 clients and finally, mobile devices enrolled by Configuration Manager, mobile device legacy clients, such as WinCE 5.0, WinCE 6.0, WinCE 7.0, and Windows Mobile 6.0 and Mac OS X clients can support 25,000 clients.
While it is important that you do not over specify the site, it is also important that the site is designed fit for this purpose. Try to move away from the design rules that were used in the previous versions of Configuration Manager; while those designs will still be valid, it may not be the correct way to do it anymore.
In the largest hierarchies, it is not uncommon to see multiple primary sites. We have just seen how, technically, you don't need to deploy multiple primary site servers if you are not managing over 100,000 clients. Designing Configuration Manager in the most technically sound way every time will end up causing you potentially more problems than you would like.
Tip
Always take into account the business requirements of your organization and make sure you understand the strategy your business is taking; this may mean that you have to break the best technical design.
Some common reasons for not deploying a technically sound solution would be as follows:
Legal reasons
Internal political reasons
Regulatory reasons
From experience, it is not uncommon to have to put in multiple primary sites when one would have done the job. While it is always great to design a solution that does the job without spending lots of money, always remember that functionality and flexibility should come first; however, for legal and regulatory reasons, this may not be possible. If this is the case, make sure this is highlighted in the design.
If you know your company is flexible in the way they work, for example, offices that appear and disappear quickly, often with large numbers of employees and equipment that need to be managed, then make sure the hierarchy you design can accommodate this solution and is flexible enough to support those requirements. This example is a fairly common one in the construction industry where project offices pop up and pop down at a moment's notice.
In this scenario, the most technically sound design would mean you having to admit that your hierarchy cannot support these clients properly without some re-design; this is not a situation you want to be in.
For a long time, secondary sites in Configuration Manager have been seen as a bit of a dark art. You shouldn't think of them like that. With the release of Configuration Manager 2012, it is not uncommon that you can just replace your existing secondary sites with distribution points.
The reason for this is that in Configuration Manager 2007, a secondary site would commonly be used because of the sender, which provided throttling, scheduling, and compression of the traffic, if required. However, these capabilities have been added to the distribution point in Configuration Manager 2012.
Secondary sites do still have their place though. In Configuration Manager 2012, secondary sites take part in replication just like the central administration site and the primary site. Portions of the database are not replicated down to the secondary site from the primary site; the replication that is used makes this a highly efficient process. By default, a secondary site installation will automatically deploy SQL Server Express unless you specify an installation of the SQL Server you have already deployed.
The replication that is used in Configuration Manager 2012 is not the native SQL Replication that we are used to. Instead the replication is taking advantage of the SQL Server Broker Service. The broker is a native SQL functionality, which supports messaging and queuing. This is known as the Data Replication Service (DRS).
When you are looking at your network topology and deciding if you should place a secondary site at that location, ask yourself the following questions:
Does this location have more than 500 clients and less than 5,000 clients?
Do I need to compress the traffic going to the site?
Do I need to control the flow of traffic flowing up the hierarchy?
Do I need a local management point?
Do I need a local Software Update Point?
If you can look at a specific location and answer any of those questions as yes, then you will probably need to deploy a secondary site. Let's dig into the preceding questions a little more; this should give us some pointers to help make our decision.
The number of clients you intend to support is a really important factor. The main reason is that the secondary site supports communication from up to 5,000 clients. If you have more than 5,000 clients at one location, then regardless of network connectivity, you will potentially want to look at putting a primary site here anyway rather than using a secondary site.
Another question for client count is to ask yourself if you want 500 clients getting policy over the network to a remote location? The content can be addressed with distribution points; what we are attempting to address in this scenario are too many clients communicating with a management point over the WAN.
Tip
Information on the estimation of client network traffic can be found in a very useful TechNet article at http://bit.ly/1sZTHfY.
Do you have enough physical network bandwidth to support this amount of traffic? This is the question we are asking here. This will determine if we need to compress or control the flow of traffic that is heading up the hierarchy.
Regardless of the number of clients communicating, we do not want to saturate the network with the management traffic.
Unlike the distribution point, we cannot control which management point the clients report to at a primary site, when we have multiple management points. For this reason, the only way we can control this is by using a secondary site. The same would go for the Software Update Point; this is another service of the hierarchy like the management point. We are unable to control which Software Update Point the client will use at any given time.
After applying the rules set out in the preceding section, we might still be unsure about whether or not we will need a secondary site. One of the great things about Configuration Manager is the simplicity and ease with which we can deploy and modify the hierarchy from within the console.