Data Replication in Configuration Manager 2012

Lots has been made about the new way in which Configuration Manager replicates it’s data. It is much more efficient at replicating data between sites, one main reason for this is that we now use native functionality within SQL Server to perform this replication.

New Wave Replication

It’s a common misconception about what type of replication is used with Configuration Manager. We do not use the SQL replication engine for site replication. This can be used for MP replica (see this post) but not for the site data. Instead we use SQL functionality called the SQL Server Service Broker (or SSB), here is a short explanation from the TechNet documentation:-

SQL Server Service Broker provides native support for messaging and queuing applications in the SQL Server Database Engine. This makes it easier for developers to create sophisticated applications that use the Database Engine components to communicate between disparate databases. Developers can use Service Broker to easily build distributed and reliable applications.

Data that is replicated in Configuration Manager is split down into two categories, these are global data and site data (more on these shortly). We still use traditional file replication for content data, this is treated the same as before. What is good about using the service broker for our replication is that we now have the ability to lock objects, this supports single user editing, you may have seen this in action with a task sequence for instance, if someone already has it open you will be prompted to open it in read-only mode.

Global Data

In a nutshell global data is anything that is generated by the administrator. Here are some examples of global data:-

  • Collection rules and count
  • Package metadata
  • Program metadata
  • Deployments
  • Configuration item metadata
  • Software updates metadata
  • Task sequence metadata
  • Site control file
  • System resource list
  • Site security objects
  • Alerts

As you can see, quite an exhaustive list. One question I get quite a bit is why collection rules and counts are global data when they may be specific to a site, it’s a very good question and one which I will answer in a later section.

This new method of replication ensures all site servers know how the hierarchy is configured. From a recovery perspective this also aids recovery as the central administration site or the primary site can be used as a reference without a backup. Global data is replicated between every one and seven minutes to provide an accurate view of the site. If you have been looking for the site control file, you will no longer find this in the file system but instead in the database, serialized as XML. This is great because it means we no longer have to wait for file replication for site configuration but rather it’s done in seconds (ish) through database replication. The use of global data replication also means that clients at secondary sites can quickly determine if a new policy is available without traversing the hierarchy.

Site Data

As you might expect, site data is anything which is generated by the system, for this reason it is specific to the site it comes from. Site data is also only replicated up the hierarchy and not across the hierarchy, this means that if you have three sites (S01, S02 and S03) that data from S01 will not be available on S02 and S03, data from S02 will not be on S01 and S03, you get the idea (you can see this in the diagram below, if the coloured lines are data from that specific site). The way the data is replicated means we still get centralised management, a lot of applications with replication do not support this. Since hierarchy data can be very large, we are reducing the size of storage needed across the hierarchy because site data is not needed at every site. This enables centralised management and reporting at the central administration site.


To make sure data is available as quickly as possible, replication schedules are between one and seven minutes (depending on the data), this is the same as global data. Phew, here are some examples of site data:-

  • Collection member results
  • Alert messages
  • Inventory
  • Asset Intelligence CAL track data
  • Status messages
  • Software distribution status detail
  • Client health data
  • Component summarisers
  • Wake on LAN data

Where is the data located?

It shouldn’t come as much of a surprise to anyone that global data is found at both the central administration site and also every primary site. Secondary sites also get a copy of the same data however they only get a subset of this information, this information includes:-

  • Links to full policy at the primary site
  • Management point lookup information
  • Generic distribution point lookup information
  • Distribution point preference information

Site data on the other hand is on the central administration site and the originating primary site, as the above diagram shows. This enables some kind of data protection between each site as you know inventory from S01 will not appear on S02 and S03.

Managing Down Level Primary Sites

One of the great improvement in Configuration Manager 2012 is the ability to centrally manage the site in an effective manner regardless of your security roles and scopes. One thing to note is that if an administrator is logged onto a single primary site and creates a deployment to a collection, that administrator will only see the collection members listed as a member of the site they are administering from, but their deployment will be hierarchy wide. That is why the collection member count is a part of global data.

That same administrator may view the scope of their deployment; say to 200 clients, while they can only see the 100 clients as members of the collection, since those clients are assigned to the primary site the administrator is connected to through the administration console.


Tags: , , , , , ,

About Martyn

Martyn is one of the Senior Cloud Architects and DevOps Team Leader at one of the worlds leading Cloud Transformation Specialists Inframon. Martyn is responsible for the architecture of some of the largest Azure deployments in EMEA and is a advisor to a many businesses on their strategies. Martyn is a regular speaker at Microsoft events and community events on Azure and DevOps, giving his insight to a growing number of audiences.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: