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:
Software inventory
Hardware inventory
Software metering
Baselines and configuration items
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.
Note
If you are unable to use RAID there is an alternative within Windows Server 2012, called Storage Spaces. This feature is set to be supported in SQL Server 2014. Support for SQL Server 2014 will come with Configuration Manager 2012 R2.
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:
Volume C:\: This contains the OS setup with RAID 1)
Volume H:\: This contains the SQL Databases setup with RAID 1+0)
Volume D:\: This contains the SQL Database logs setup with RAID 1+0 )
Volume E:\: This contains the backups setup with RAID 5 )
Volume T:\: This contains SQL Database TempDB, which is setup with RAID 5)
Volume I:\: This contains the Configuration Manager files and is setup with RAID 1+0
Volume F:\: This contains the
Pagefile and the WSUS updates that is setup with RAID 1
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:
Use CAS on the top of the hierarchy because of the large amount of clients, less than 400,000 clients
Microsoft split up large geographical regions (Europe, Asia, and so on) as their own Primary sites
Use secondary sites within primary sites to control the flow of data
Multiple instances of each role within each site are used to have multiple instances available to the clients
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.
Central Administrator site is the role that sits on top of the hierarchy (It is not mandatory but if you need more than one primary site you need this role to manage the different subprimary sites).
The features it contains are as follows:
It can be installed along with the database server
It cannot have any clients directly assigned to it
It does processing of data from all the other primary sites in the hierarchy
It can manage all the clients in the hierarchy
It supports only Primary Sites as child sites
This site does not support all the different roles. For instance, it does support Endpoint Protection, Asset Intelligence, Reporting Services, Software Update point, Intune Connector, and System Health Validator point and some of these roles should be placed in top of the hierarchy.
This site supports the following:
It can support up to 25 child primary sites
When using SQL Datacenter or Enterprise it support up to 400,000 clients
When using SQL Standard it supports up to 50,000 clients
It is the most commonly-deployed site method and is a mandatory role when deploying Configuration Manager.
Now a primary site can have the following features:
It can be standalone or part of a hierarchy either with a CAS and other Primary site or a Primary with subsecondary sites
It is responsible for processing all data from its assigned clients
It uses database replication to communicate with its CAS
It can be installed with the database server
It can have clients assigned to it
The primary site has support for the following:
It can have up to 250 Secondary sites in its hierarchy
It can manage up to 100,000 clients
It can manage up to 10,000 Windows Embedded clients
When having a SQL Server collocated with the site server it can have up to 50,000 clients
A standalone primary site supports all the different roles. When a primary site is part of a bigger hierarchy, it no longer support having Asset Intelligence point, Endpoint Protection, or Synchronization point installed
It can have up to 10 Management points connected
Also, it can have up to 250 Distribution points connected
This can only be set up as a child site to another primary site and participates in file-based replication to communicate with its parent Primary Site. This is not a mandatory role and should only be considered if you want to control the transmission of client data up the hierarchy. However, secondary sites do not have all the functionality of a primary site and must be a child site of an existing primary site.
A secondary site has the following features:
It is installed with an SQL Express automatically if a SQL instance is not installed previously
Installs a Management point and Distribution point on the same server
Software Update point and State Migration point can also be installed
Sends data to its primary site using file-based replication
Also, it can support the following:
It can have only one Management point
It can have up to 250 Distribution points
It can manage up to 5,000 clients
It is important to note that Microsoft recommends that we try to avoid using secondary sites whenever possible, and just work with a regular primary site and use the different features which are included with the Distribution point. This will be covered in the next chapter.
A Management point has the following features:
Primary contact point for clients within a site is present. You can also install a Management with a connection to a Site Replica database to reduce CPU cycles on the Site database server.
Clients have to be connected to a Management point to communicate with a site.
It can support having up to 25,000 clients.
If you have a remote location (for instance, on a low bandwidth WAN) you should not configure a Management point at the remote location. This is because a Management point is not aware of the site, unlike a Distribution point, which you can place within a boundary. If you place a Management point at the remote location, clients from another part of the site might actually use that Management point and cause more traffic on the WAN link. In this case, it would be better suited to use a secondary site.
The Distribution point is responsible for delivering data to the clients, both for applications and OS deployment and also, it has the following features:
It allows streaming of applications using App-V
It allows PXE connections using unicast or multicast
It allows rate limiting and pull-based content deployment.
It supports up to 4,000 clients
It supports a combined total up to 10,000 applications and packages
Software Update point is integrated with Windows Server Update Services (WSUS) to deliver software updates to clients using Configuration Manager.
WSUS can be deployed on a regular Windows Server with either using a Windows Internal Database or using a regular Microsoft SQL Server. It supports the following features:
It supports up to 25,000 clients (when installed with the site server)
It supports up to 100,000 clients (when installed on another server that is not the site server)
Before Service Pack 1, you were restricted to having only one Software Update point in each site. Now with Service Pack 1, you can install multiple Software Update roles within a site.
The Fallback point allows clients to send status messages back to the site in case there is trouble with locating its Management point or for instance, trouble connecting to the site.
It is also useful if we want to use the client deployment report, which displays data received from the Fallback Status point. It is important to note that this role runs on regular HTTP and therefore it's not encrypted. This role supports up to 100,000 users and should be on a dedicated server.
These roles allow users to access a self-service portal for applications that are published to them. The portal itself is based solely upon Silverlight, both of these roles support up to 50,000 clients each.
The reporting role is attached to a SQL reporting instance to generate Configuration Manager Reports from the console.
This role copies over Configuration Manager Reports and applies security policies based upon the security settings in the site. It is important to note that only one reporting role can be attached to a SQL reporting instance.
There are other roles that can also be a part of the installation, which I'm not going to cover in detail in this chapter, but the following points might be worth looking into:
State Migration point
System Health Validator point
Intune point
Enrollment point
Enrollment Proxy point
Asset Intelligence synchronization point
More information about these roles can be found on Microsoft technet at
http://technet.microsoft.com/en-us/library/hh272770.aspx.
But there are some components that are important and are required for most of the roles in Configuration Manager. They are as follows:
Internet Information Services (IIS): This is a web server role, which is included in Windows Server. The majority of the roles in Configuration Manager require having this role installed, since it allows clients to communicate with the server using HTTP or HTTPS.
Background Intelligent Transfer Service (BITS): This is a component, which is included in most of the operating systems from Microsoft. It allows asynchronous, prioritized, and throttled transfer of files between machines using available network bandwidth. BITS is used by Configuration Manager to deliver content to the clients.
Remote Differencial Compression (RDC): This is an algorithm, which is used to analyze a situation where a file exists on two computers and that file is modified. Only the differing sectors need to be sent to the other computer. Site Servers and Distribution points use this to generate package signatures. So when we update a package it will only send over those sectors that have changed.