SCCM Replication Process

SCCM 2012 Replication Process

Configuration Manager 2012 Replication Process

The Replication of data between sites in SCCM is happening due to the Data Replication Service (DRS).It is a new feature added in configuration Manager 2012 found along with the legacy File based replication. This replication model is also called as SQL based replication, as multiple SQL features are used.

In SCCM Architecture as illustrated in the following figure. The CAS has two primary sites which in turn lead to two secondary sites. The flow of data types between these sites is explained subsequently (page2). If the replication looks good, the Alert status is displayed as OK as follows:

Figure 1: SCCM Site Hierarchy

SCCM2007 – File Based Replication uses Server Message Block (SMB) protocol and accomplished by using a sender and file replication route that together define how and when a network connection to a parent or child site can be established. This replication transfers file from site to site.

SCCM2012 – SQL Based Replication along with File Based Replication. This Replication uses SQL Service Broker (SSB) along with change tracking and BCP functions.

Components involved in SQL based replication

The most important components in SQL based replication are as follows:

· SQL service Broker - It is the SQL mechanism to deliver messages end to end.

· Replication group - Similar SQL tables are grouped together and a replication group is formed. There are 12 replications group in SCCM which are listed in the following table:

Replication Group 

• Replication Configuration 
• Site Control Data 
• Configuration Data 
• Registration Data 
• Language Neutral 
• Asset Intelligence Knowledge Base 
• EndpointProtection_ThreatMetaData 
• Alerts 
• Group Relationships 
• Upgrade Assessment 
• MDM_Global 
• CFD_Global 

· Replication Configuration Monitoring (RCM)- RCM is the component that is responsible for sending information regarding any changes to tables in the replication group to the receiving site.

· Replication Pattern - Replication Pattern is nothing but the type of data that is defined during the replication. The details are explained as follows:

The data that is part of the replication is grouped into few types:

· Global Data – The data that is transferred and needed across the hierarchy and the Data that is created by administrator comes under Global category. This information is shared between central site and all primaries. The list of Global Data is as follows:

• Task Sequence Metadata
• Deployments
• Configuration Items Metadata
• Security Roles
• Security Scopes
• Alert

· Site Data – The Data that is sent to particular primary, for example, the data sent by the client is shared only to the particular primary and it is not required for other primary sites. The list of Site Data is as follows:

• Hardware Inventory
• Software Inventory
• Software Metering
• Software Distribution 
• Status Message
• Wake on LAN
• Data related to client health and history 

· Global Proxy – This is the data that is transferred between the secondary site and respective primary site.

How Replication Works, when New Primary Sites are installed?

Once the primary site is installed, the newly installed site will initiate a synchronization with the sender site (central site) to gather the huge subsequent data. This task leads to the movement of all identical data set from sender site to receiving site. This movement of data is called replication.

Initially the primary site that is newly installed will send an INIT request to the CAS, to pull information of desired replication group. Further the INIT request that is sent uses the Bulk Copy Program (BCP) application to extract all of the data from the tables that make up the replication group being initialized. 

At the same time a row count of the number of exported rows is also taken and stored in a .row count file. RCM in sending site begins sending any changes to tables in the replication group to the receiving site. The BCP files are replicated to the receiving site through the legacy content sender. Once the data is received, the RCM in receiving site will check for the row count and change tracking table to ensure the change is updated.

The data movement during the initialization is captured as a flow diagram:

Figure 2: Initialization Data Movement

Once the site moves to active mode, it will be ready for production and starts doing the standard DRS replication across all sites.

Example:

When a Collection is created in Central site:

The provider will write to the corresponding tables for the package (V_collection_Getc) in the primary site.These tables are enabled for the feature ‘SQL Change tracking’. So when the new data gets inserted into the V_Collection_G table only the primary key column information is stored in the Change tracking tables. The changes will later update to all Primary sites’ corresponding tables and updated with latest information.

Logs to verify:

RCMctrl.log
Sender.log

Some simple SQL queries used to verify the replication status

To find replication status: 

execspdiagdrs

To find the replication data: 

select * from vReplicationData where Replicationpattern = 'site'


To find the articleName

selectArticleName from ArticleData where ReplicationID = (select ID from

vReplicationData where ReplicationGroup =

'Alerts')