Microsoft System Center Configuration Manager: Deploy a scalable solution by ensuring high availability and disaster recovery using Configuration Manager with this book and ebook.

When planning for High Availability you need to look at every aspect of your infrastructure; spanning from the underlying hardware to the software running on top of the different servers that serve the clients.

Some general points that can be highlighted when setting up a design and that need to be taken into account are as follows:

All these questions need to be taken into account and looked over, and taken into the planning phase. We always need to look over a design and think is there any single point of failure with this design? Because, it does not matter if we set up a massive and redundant SQL cluster in every way and we put the cluster on the same network switch. Because, then we know that if that particular switch goes down, the cluster goes down.

Coming back to Configuration Manager let us take a look at a simple site design for Configuration Manager and how it might look:

With a simple design shown in the previous diagram we have the general feature set for Configuration Manager available to our clients. All our Configuration Manager Clients will contact the Management point for policies, advertisements and reporting of data, and so on. The Management point in return will populate the site database with information received from the clients.

When the clients need to download a source file from an advertised deployment or for an operating system deployment it will contact the Distribution point within the site. For this site the data is stored in a single database server, which is collocated with the Primary Site Server. This design also includes a Software Update Point role as well as Endpoint Protection Role for the management of endpoint protection and patch management.

Let us look into problems with this type of design. For instance, let us see what would happen if the Management point server in the site stops functioning:

Let us see what would happen if we had two Management points in the site we just saw.

The clients would try to contact its first Management point; if it is offline it would look at its list of available Management points and try to contact the other one. This way we would have maintained site functionality for the clients. This gives us a Highly Available Management point solution for the clients, but this is only one of the components that need to be taken into account.

If the database stops working or suffers from a faulty hard drive at the server site, it would reflect outcomes that appear in the upcoming sections. As I mentioned earlier, clients will cache data locally until the site server is restored, but historical data will be lost. For instance, software metering information can be used for reporting licensing usage.

These were just a few examples of what might go wrong with this design. It is important to stay ahead when planning. There are also other components besides the ones we just covered in my example that need to be taken into account and they will be covered later in the book.

Other components

Configuration Manager is highly dependent on other components such as DNS and Active Directory, and also Active Directory Certificate Services and DHCP. Are there any High Availability options for them? I will cover this topic more in detail in a later chapter.

But many of these roles are not a part of the design phase for a Configuration Manager solution, and in most cases are already set-up redundant. Further on in the upcoming chapters we will discuss how we can deploy each role and back-end services like Microsoft SQL Server using High Availability and load-balancing features, SQL Server. It is important to note that there are no services in Configuration Manager that happen in real time and that no clients require continuous communication with any of the site roles.

Configuration Manager always works on a predefined schedule for each operation; therefore you must expect some latency even if you set up High Availability for your sites.

Before we continue, we will take a look at how Microsoft IT deployed Configuration Manager for the environment, just to give a clearer image on how a large enterprise Configuration Manager deployment might look for a business. The following diagram gives its overview design:

Microsoft IT deployed Configuration Manager 2012 for more than 250,000 systems and more than 150,000 users worldwide. Using this design and much of the logic that they use when deploying should be used in other scenarios as well as when planning.

The entire project can be found at the following site:

http://www.microsoft.com/en-us/download/confirmation.aspx?id=29433

A point to note here is that there are only six physical servers in the entire design. They are used on the site server roles, which have SQL Server installed (In this case, there is one each in the different Primary Sites and the CAS server).

Note

At the time Microsoft IT implemented Configuration Manager, Windows Server 2012 was not available and therefore, they chose not to virtualize the database servers in this design because of the hardware requirements for CPU.

All of the servers which have Microsoft SQL Server installed are set up with different forms of RAID in order to gain redundancy and performance. This is needed because all the clients report back a large amount of data to the site, depending on what features are enabled in the client policy.

For instance, some examples of what the clients might report back to the site and the database are as follows:

And depending on the information and the schedule this might result in a large amount of data.

But let us delve into the different forms of RAID and how it can give us better performance and redundancy for our database server. The whole purpose of RAID is to group together physical disks into a group and then form virtual disks on top to gain performance and redundancy. Now, there are different levels of RAID that we can setup

RAID 1 is a solution based on two disks where data is mirrored on both disks (so in case of a disk failure the service will continue to run on the other disk) when you replace the faulty disk the RAID controller will rebuild the data on the new disk until both disks have the same content again. This type of RAID will in theory give us 2x the read performance since the data is available on both disk, but this is very dependent on having an adequate RAID controller.

RAID 5 is a solution based on minimum three disks and it uses parity bits on each disk. Here data is split up in different chunks where two of the disks contains the data and the third disk contains the summary of the data on the other disks (known as a parity bit) For instance, if disk one contains the data bit, 1, and disk two contains the data bit, 1, then the parity disk would contain the data, 2. Since, it will always contain the sum of the different data from the other disks. If disk 1 should fail, it would take the parity and extract the data on disk 2, which will add up to 2 - 1 = 1. So it knows that the bits that are missing on the faulty disk is 1. Depending on the data the parity might be on different disks, so we do not use a dedicated disk for parity.

RAID 1+0 (or 10) is a combination of RAID levels 1 and 0 which does mirroring and splitting the data. All disks are members of two groups, where one group does the mirroring and the other group is for splitting the data. This can, in theory, give us 4x read and 2x write performance gain and redundancy in case of a disk failure and depending on the disks that fails, it can allow for two disks to fail.

When Microsoft IT set up the CAS SQL Server, they used different levels of RAID depending on the purpose of the volume.

So let us take a better look on Microsoft setup and the layout of their database server. To explain in detail how Microsoft set up their database servers, have a look at the following volumes:

Some factors that are worth taking note are that they split the database setup so that they place the transaction logs on one volume, TempDB on one, and the regular databases on another one. With this type of setup you get better performance on the database service because of the way the different components and SQL work.

The TempDB database is responsible for storing all the temporary tables, temporary stored procedures, and internal objects created by the database engine. So any procedure in Configuration Manager that you use to create a temporary table will be stored in the TempDB.

The transaction logs store all the data transactions and database modifications. After these transactions are stored they are truncated to the database. These logs files will grow in size until a full backup has been done. This requires a lot of write activity and by placing them on a RAID 1+0 solution, we will have adequate performance.

It is also a best practice to store the swap file on a disk other than the regular OS disk. This will also boost our performance, since the swap file does not need to share IO with the regular system services. The other SQL Server on the primary sites are set up in an equal way as the CAS SQL to ensure that performance is not an issue for the large amounts of data.

It is important to note that you do not need to split up your database servers like this unless you require the extra performance and redundancy. But this type of deployment is according to best practice and should be used when possible, since Configuration Manager relies heavily on its database server.

We can also see in the design that Microsoft IT decided to use Secondary Sites in some of their regions. This is mostly because of the geographical gap between different countries. With Secondary Sites you can control the flow of data going back and forth between the sites.

Since secondary sites install a Management point and a Distribution point automatically, clients have what they need to get policy updates and content. As we can see from the site design, Microsoft uses a simple design for their solution. To sum up, following bullet points show how they deploy their service:

Now, let's take a look into the different roles within Configuration Manager and see what kind of features they give and what they support. This will give you a better understanding on how you should scale and where you should use the different roles and components.

In a moment, you will see how the different roles and clients communicate with each other. This information will be useful when setting up or planning firewall rules between servers and clients, and roles that can be load balanced.

Network communication flow is described in the following table:

Some important factors regarding port usage within Configuration Manager are as follows:

Before we continue on how to deploy High Availability, it is import to note some of the changes that have been done to the Service Pack 1 release. Some of the new features are large hierarchy changes that can affect the site design. It has the following features:

In this chapter, we have gone through the different components and roles within Configuration Manager, what their functions are, and how they scale. We looked into different components which need to be taken into account when planning for High Availability such as networking, hardware, and other critical infrastructure components such as AD, DNS, and DHCP.

We also took a closer look at how Microsoft IT has deployed their Configuration Manager solution to get a better overview on how a site design with High Availability might look like.

In the next chapter, we will start by going through how we can set up the different roles and features to become highly available.