Site to Site Replication Component Inboxes Overview


The flow of events or components will work as shown below:-


Created minijob to send compressed copy of package CEN0000D to site PRI.  Transfer root = \\STEVERACCEN\SMS_CPSC$\CEN0000D.PCK.    
Package CEN0000D is new or has changed, replicating to all applicable sites.   
Sent package changes to site PRI for package CEN0000D

We have started our site to site communications demo using distribution manager content – but it could just as easily have been collection replication, site control file replication, status message replication, state message replication, etc.

The minijob is placed in which is the component that handles replication.  The contents of is show below:

There are 5 folders here.

This is where all data that is incoming from a parent or child site is placed.  Replication manager has the job of figuring out what kind of data it is, which component should handle it and where it should be placed – and then the content is copied there for final processing (more on this once we get over to the server side.  This folder is not part of our example on CEN (but will be on PRI) so we will skip for now.

This is the location where all data is placed by various ‘sending’ components that is destined for another site.  Data is categorized as to priority and placed in the appropriate subfolder under Outbound – either low, normal or high priority.

Data moves from outbound to process where everything is checked and made ready for transfer.  Typically you won’t see files in the process folder unless there is a problem.  The processing was so quick I wasn’t able to catch it to show here.

This folder contains data that is ready to be sent.  Once data arrives here the next steps are to schedule it for sending and to send.  If you look in the ready folder on a reasonably active site you will typically see folders with data inside that are destined for another site in the hierarchy.  The highlighted area below shows that the contents of this folder are destined for site PRI.

If we look inside the folder we see another .RPL file. The filename has changed from the one we found in the incoming folder – does that mean the contents of the file have changed?

Nope, same file – except now it has been processed, validated and is ready for sending.

The history folder maintains a history of all transactions that have flowed through replication manager – either incoming from other sites or outbound to other sites.  If we look in the history folder we see a .TRS file- known as a transaction file – which records movement through the replication manager inbox.  In some scenarios information will fail to replicate due to invalid values in this file.  In earlier versions – such as SMS 2.0 – this fact wasn’t logged in replmgr.log but is now.

All of the activity just described is recorded in just a few lines from the replmgr.log

Scanning low priority outbound replication directory.     
Did not find any additional replication files.    Minijob created.  Priority 2, transfer root (\\STEVERACCEN\SMS_CEN\inboxes\\ready\2_gg1xd8.PRI).

As we leave the note that content will remain here until notification is received that sending has completed.  This is important to ensure pointers to content are not removed until sending is finished.

The next step is to schedule the jobs for sending. We will go through the folders in the order of processing

Note:  Scheduler is a single threaded component.  That means that when it starts it has to work it’s way through the entire processing loop before it starts again.  On a very busy site it is common to see that one full loop of logging is not captured in a single log file.

The to send folder is the staging area showing what content is to be sent to the destination.

Following our filename our job of interest is 0000004F.I16.  Reviewing the contents of this file we see the same identifier and more pointers back to our source.

Requests is a folder that we see as part of processing in the log entries above but it’s hard to catch data in this folder since requests is a quick stop along the way to outboxes\lan.

The outbox folders – in this case LAN since we are using the LAN sender – is where our send requests are placed to flag sender to wake up and begin sending the content defined in the tosend folder. Note that the .CPB and .DAT files are always present in this folder.

If we look at our appropriate SRQ file – 20027CEN.SRQ as found earlier in the .job file content – we see this file pulls everything together so the sending process can begin.  We will watch the sending process take place next.

Before leaving the folder we should stop a the UID folder.

In this folder we will have two files – a .REQ and a .JOB.  These are files used to track the progress of various items as they are sent through the scheduler.  These files are critical to the operation of scheduler and should never be deleted.  If they are you can recreate them as blank text files.  If you have one file but not the other just take the filename of the one you have, increment it by a hundred or so and create the missing file with that new filename.  If neither file are present you can recreate both – use a filename for both that would likely be above the value you might expect there.  I like to use a filename of 00100000 since it would take a really long time for a site to send that many jobs so the filename is likely safe and leaves plenty of room to grow.

Note:  At this point all sending is complete from CEN to PRI – now PRI has to process that sent data forward.

Notice also that we are sending to SMS_Site – that is a share name that translates to the inboxes\\receive folder on PRI.

All sending, regardless of content, is sent directly to the SMS_Site folder on the destination site servers.  The content is sorted further from there.

How is it sorted further?  If we look at the despoolr.log on PRI we will see our .SNI file being processed.  Before we jump into the details of the log – a log reading tip.  Many components in SCCM are multi-threaded meaning they can work on multiple things at once.  This is potentially confusing as the entries in the log may get mixed between various lines of processing.  One way to keep things straight is the thread ID that is recorded in the log.  If we look at despoolr.log we see this very thing.

If replmgr is used to handle the file type all it does is look at the content and forward it on – something similar to the below log snip.

Moved incoming replication file to C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\\INCOMING\CEN_24.SDM    
Moved incoming replication file to C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\\CEN_2.CAR   
Moved incoming replication file to C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\\INCOMING\CEN_11.CID


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