The central administration site, primary site, and the secondary site are all site systems. These themselves cannot be part of a cluster or any type of load balancing. What we can do though is make the database that stores our entire configuration, inventory, and other information highly available.

This can be done in a number of ways, for example, we can provide high availability using a traditional SQL cluster service. Both of these configurations allow us to make the database highly available.

Back to the site systems, if we are deploying our site system servers as virtual machines, then we can take advantage of replica in Hyper-V or similar technologies in VMware. This will make our site system server switch, should the workload need moving in the event of a failure. In this scenario, if you are deploying the site system server on the same server where SQL Server is deployed, then we might not need to worry about making the database highly available.

Any other service you deploy in Configuration Manager, such as the management point, distribution point, and fallback status point, to name a few, is known as a site system role. In some instances, we can create multiple instances of these roles to create tolerance but not in the sense of a cluster.

Some site system roles you can only deploy as one instance per hierarchy, for example, this is true of the Endpoint Protection Point where you can only deploy one instance of the role per hierarchy.

The management point is a good exception to this. While we cannot pick and choose which management point a client will communicate with in a primary site, we can deploy multiple management point servers to provide options to the client. If our hierarchy is running in an HTTPS configuration, then management points that are HTTPS enabled will be ordered above any HTTP management points by the client while it is selecting a management point to use.

The same can be said for the distribution point: we can deploy multiple instances of the distribution point to give the clients options when deciding which to use for downloading content. Software Update Points can be added to an NLB cluster, for example, which must be configured using PowerShell. However, they can also, with newer versions of Configuration Manager, have multiple instances in the same hierarchy without the need for an NLB cluster.

Depending on the requirements of the design and how important Configuration Manager is in terms of its role in the recovery of a data center is the driving factor for building fault tolerance at the site system role side of the picture.

It is best practice for any infrastructure service to keep multiple backups. Various reasons exist for this; however, I will not go into many details here. By using the default backup site server task in Configuration Manager, the first time a maintenance task runs, a snapshot is created. The next time the backup runs, another snapshot is taken and the previous snapshot is overwritten. As a result of how the backup maintenance task works, you only have the most recent backup and have no way of recovering an earlier snapshot.

Thankfully, you can use a batch file, AfterBackup.bat, which is automatically run following the completion of the maintenance task. You must manually create this file if you need it at <Install Directory>\Inboxes\Smsbkup.box. If this file exists, then it will be automatically executed.

The file is a regular batch script so you can perform any actions you wish here. You can verify the completion of the maintenance task, which includes the execution of AfterBackup.bat from the Component Status node in the Monitoring workspace. Look for the SMS_SITE_BACKUP component and you should see a status message with an ID of 5040.

While the backup maintenance task takes care of much of the site information and the database, it does not take care of everything. One example of this is that any custom reports that you create needs to be backed up manually.

The same is true for content files, which are part of applications and packages. The content library needs to be restored before you can redistribute any content to the distribution points. When the distribution manager starts to distribute content, it is copied from the site server to the distribution points. You must ensure that your backup solution includes both the content library and the package and application source locations for the site server.

Custom software updates that may have been published using System Center Update Publisher 2011 (SCUP) must also be backed up. These are also not included as part of the backup maintenance task. SCUP uses a database to store the repository so it is also important to make sure this database is included in your backup plans. It should be noted that the database file for SCUP is located in each user's profile.

Finally, the user state migration data is also not included. This is information that may be used during operating system deployment to back up and restore user state from one machine to another during either a refresh or a replace scenario. You must manually back up the folders that are specified in the Folder details section of the General tab in the State Migration Point properties.

Unlike the previous versions of Configuration Manager, you can no longer use the Recover a site option from the Start menu on the site server. You can only start the recovery wizard from the installation media. The wizard is available in the regular setup.

Once the setup has begun, you have the following two options that are available for the recovery of the failed site:

For the site database, the following options are available as part of the recovery:

With any design, it is vital to capture the key business requirements not just from the technical members of the project team, but also from people like Service Managers and the CIO who may be closer to the business than you are and can provide valuable insight into key decisions that may affect your design.

In our example, a number of requirements have been captured:

One of the big changes from Configuration Manager 2007 to Configuration Manager 2012 is the ability to deploy settings policies on a per collection basis rather than in Configuration Manager 2007 when they applied on a per site basis. With the information we have collected, this is going to come in very handy when we look at the final design.

The ability to also define security in a more granular way using role-based administration to give people access to perform set actions and then scoping their access down to Security Scopes will help with some of the defined requirements.

Not every design decision is black and white; sometimes we can have multiple options available to us for our design, and we need to make sure we pick the right option and justify that decision in our documentation.

Our design is no different, we have multiple options and considerations we need to look at to make the right decision. The following table lays out some of the options available to us when we look at addressing some of the challenges that we are facing:

Directly addressing the stated requirements

Now that we have looked at some of the challenges we are facing, we need to make decisions on each of the requirements. This will start forming the basis of the design that we will prepare.

First of all, we need to decide on the top of the hierarchy. With the information we have been provided, a central administration site will be the best fit. This addresses the requirement that the site should be centrally managed from one location. We could also have provided a standalone primary site, which would have achieved the same result; however, this restricts our hierarchy in terms of what we place at sites lower down the hierarchy. This is because if we place a secondary site in New York, which would be the preferred technical solution, this means we cannot expand late. Remember that we might suddenly have to manage two more offices with 10,000 clients at each location. At this point, we don't need to pay much attention to the ability to segregate management of systems to regional departments, as no matter how we design the site, this functionality will be available.

Next is the ability to control traffic between London and New York. First of all, we need to deploy a single primary site as part of our hierarchy, which is also in London; this will be connected to our central administration site. This primary site will service the 20,000 clients that are located in London and combine down two existing sites, the old central site and child primary site. We cannot assign clients to the central administration site so we need a primary site in the hierarchy.

For New York, we will also place a primary site. This configuration has been chosen for the following reasons:

• Site-to-site configurations can address the bandwidth control requirements to transfer content from London
• Settings are managed centrally so we only need to deploy a single primary site, which is joined to the hierarchy
• As the link is slow, we do not want the 4,500 clients in New York sending their inventory and policy requests over the network to London
• Any future growth can be handled by implementing a primary site today rather than a secondary site or site system roles

Finally, in Chicago we deploy a secondary site that is hanging off the New York primary site. We do this because although the links between Chicago and New York are fast, this site has 1,000 clients. Additionally, from an administrative point of view, it makes logical sense to create the secondary site off the other site in North America, rather than creating it from the primary site in London.

The following diagram shows how the core of our hierarchy will look with this configuration:

Tip

Don't just let technology dictate your decisions we have just made a decision based on both technology and logical thinking. This is as important as making decisions for technical reasons.

High availability of the database or fault tolerance is not stated in the requirements but it is good practice to include a plan on how you would include this functionality, unless it has been explicitly excluded from the scope of the project. For our customer, they have not stated either way if this is or is not a requirement. For this reason, we will make some recommendations on high availability and fault tolerance.

Licensing is also a stated requirement, in that, if required, we should reduce it where possible. While we usually cannot do much in this area, System Center 2012 is one area where this can be addressed by looking at the SQL Server licensing.

You are allowed to deploy the SQL Server Standard edition with any System Center 2012 component provided it is the only SQL instance and no other databases are served out of the same server. For this the SQL Server Standard license cost will be included in the System Center 2012 license.

With this information, we need to now look at our usage of SQL Server and how the edition we select impacts our hierarchy. When we are deploying a hierarchy, the edition of SQL Server we deploy on the central administration site is the one that will determine how many clients our hierarchy can support.

When we deploy SQL Server Enterprise or Datacenter edition, the hierarchy can support a combined total of 400,000 devices. The Standard edition limits us to 50,000 clients; in this scenario, although SQL supports an in-place edition upgrade from standard to enterprise, Configuration Manager does not support this due to the way in which the database is partitioned. A primary site or secondary site in a hierarchy is not affected by the edition of SQL Server that is used for that site. However, a primary site with a SQL Server installed locally is limited to 50,000 clients; the limit with a remote SQL Server instance is 100,000 clients.

While infrastructure design documents are technical documents and in many cases very technical, they are often looked over by decision makers in both IT and finance. It is important that the top of your document includes a statement of what problem this design fixes and what business benefits it brings to the table.

Including this information at the top, from experience, gives the nontechnical readers of the document all the information they need to either sign off the design and provide the financial backing for the project or ask you to provide more information.

For our example customer, we have the following great benefits to add into the documentation, including the fact that we are answering all of the stated requirements:

When you write the business benefits in a document, remember who will read it. Try and put the financial benefits before and process or technical benefits as these will satisfy the reader of the document without them having to read much.

Now that we have decided on our design, we need to make sure our design is documented. Every design document is different based on the requirements but a few headings are listed, which will give some direction on the layout of the document:

This will give you a good high-level design document with all the information that people need, including the decisions you have made to reach the design that you are setting out in the document. Consultancy companies as well often deliver detailed design documents, which include much more information and more detailed diagrams.

Now that we have prepared our design documentation, we need to prepare our diagrams so people can see how our solution is put together at a graphical level. Diagrams can take many forms and be drawn up in many ways. The following diagrams are included with our design: