Site to site data replication flow in SMS 2003 and ConfigMgr 2007 explained

Site to site data replication flow in SMS 2003 and ConfigMgr 2007 explained

  • Comments 3
  • Likes

GrayAndYellowGearsHi everyone, Terry McKinney here.  Below is a quick-reference document that illustrates the MOST COMMON site to site data replication flow path in SMS 2003 and ConfigMgr 2007. There are exceptions to this flow path of course so see the document referenced below for specifics on these exceptions and for greater detail on site to site replication.

New deep-dive document: Component details and data flow for site-to-site replication in SMS 2003 and Configuration Manager 2007

=====

image

NOTE: Question marks (???) in the text below indicate random character generation by SMSExcec thread processing.

SMSExec thread component on source site initiates replication request

SMSExecutive thread component that is requesting data replication places the data to be replicated in replmgr.box\outbound\low OR replmgr.box\outbound\normal OR replmgr.box\outbound\ high folder. Low (3), normal (2), and high (1) specify replication priority requested by the SMSExec thread that requests replication.

Replmgr:

Replication Manager (ReplMgr) scans the three folders listed above for incoming data. Replmgr prepares the job source files by combining data files destined for replication to a given site in the \replmgr.box\process\<destinationsitecode>_<priority> folder (i.e., XYZ_2). If there are no pending replication requests to a given site that have the same replication priority, Replmgr implements steps A and B listed below. It there are pending replication requests to that site that have the same replication priority that are already scheduled for replication, data for new request(s) is held in the Replmgr.box\process\<destinationsitecode>_<priority> folder. Data for the new request(s) will remain in the Replmgr.box\process\<destinationsitecode>_<priority> folder until the pending same-priority request completes data replication OR the new replication request(s) reaches 6 hours in age. At this time, Replmgr will implement steps A and B listed below. If a replication job of the same priority and destination site is still pending, ReplMgr implements steps A and B below to create an additional same-priority replication request for that site.

A. Data to be replicated is moved to \replmgr.box\ready\<priority>_??????.<destinationsitecode> (i.e., 2_SKEJFS.XYZ).  This folder is referenced in log files as the "transfer root".

B. ReplMgr then creates a .JOB file in the \Schedule.box folder.

Scheduler:

At the top of the Scheduler process loop (except on service startup) Scheduler activates any pending jobs by completing the following steps:

A. Compresses all files in the transfer root (i.e., \replmgr.box\ready\2_SKEJFS.XYZ) into a single package file and writes this file to \schedule.box\tosend\<job id>.P??.

B. Creates a destination site despooler instruction file in \schedule.box\tosend\<job id>.I?? to be transmitted immediately after the package file created in step A is transmitted.

C. Creates a send request in the \schedule.box\requests folder (<priority>_???<originatingsite>.SRQ) (i.e., 2_5ZKABC.SRQ).

D. Determines if the package and instruction file needs to be routed through an intermediate child site. If so, a routing instruction file is created (RT??????.INS) for the send request.

E. Schedules the send request by moving it into an appropriate sender outbox. Each installed sender type creates its own folder under schedule.box\outboxes. The most common sender outbox is schedule.box\outboxes\LAN.

Sender:

1. Sender transmits the package file and then the instruction file to the remote site by completing the following steps:

A. Renames the send request (<priority>_???<originatingsite>.SRQ) to (<priority>_???<originatingsite>.SRS (changes the filename extension to .SRS)

B. Transmits the package (\schedule.box\tosend\<jobid>.P??) file to the remote site Despoolr.box\receive folder (the SMS_SITE share) and renames it to <sendrequestid>.PCK

C. Transmits the accompanying instruction file (\schedule.box\tosend\<job id>.I??) to the same location and renames it to <sendrequestid>.INS

D. Flags the <priority>_???<originatingsite>.SRS file with a "sending complete" flag.

E. Creates a \schedule.box\<sendrequestid>.DWS (done with sending) file.

Replication component processing at the destination site Despoolr.box\receive folder)

Despoolr:

The Despooler process first checks the signature on the replicated files. If signed correctly, despoolr decompresses the instruction file and implements the instructions contained within that file – to decompress the package into the \replmgr.box\incoming folder in this case.

ReplMgr:

Replication Manager analyzes incoming files and replicates the objects to appropriate inbox folders. The appropriate inbox folder is specified by the component on the source site server that began the replication process. Inbound replication jobs that use transactions must bear a transaction ID that is greater than the existing number for that object type that is contained in the sitecode.trs present on the destination site. If this condition is met, the transaction is considered valid and the inbound replication objects are passed to the destination component/inbox. If this condition is not met, the transaction is considered invalid and the replication objects are discarded by Replication Manager.

Post - replication cleanup on originating site:

Scheduler:

A. Updates the corresponding job status to "complete" when it finds the \<sendrequestid>.DWS during its

processing cycle.

B. Performs cleanup - deletes the related package and instruction files in the \schedule.box\tosend folder

C. Deletes the transfer root folder (i.e., replmgr\ready\2_SKEJFS.XYZ)

D. Marks the send request for deletion

ReplMgr:

After the transfer root has been deleted, pending replication requests with the same priority and destination site that are less than 6 hours in age can be created. Note that if there are existing jobs of the same priority and with the same destination site that are older than 6 hours, ReplMgr will request scheduling an additional replication job of the same priority for replication to that site.

Scheduler:

A. Deletes completed send requests when it finds the associated <job_id>.dws file for that job during its processing cycle.

B. Deletes the completed job files (minimum cycle: once per hour, maximum cycle: once per process loop).

Terry McKinney | System Center Support Escalation Engineer

App-V Team blog: http://blogs.technet.com/appv/
AVIcode Team blog: http://blogs.technet.com/b/avicode
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
OOB Support Team blog: http://blogs.technet.com/oob/
Opalis Team blog: http://blogs.technet.com/opalis
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/
SCMDM Support Team blog: http://blogs.technet.com/mdm/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

clip_image001 clip_image002

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Great post!  We finally have a reference that describes the "under the hood" site to site replication process.

  • Excellent....Very Infomational and helpful..Thank you..

  • Thank you for this informative post detailing the how behind the what.