How long does SCCM/ConfigMgr site to site replication take?

I received a question today asking me, “How long does site to site replication take?” I figured this is a good question because simply it doesn’t have one answer. Depending on type of replication, it could have as many as three or more answers. Replications can be distinguished with a priority of High, Medium, or Low. Replication will continue to scan until one of the three conditions are met:

  • No more files exist
  • Elapsed time is longer than two polling intervals (polling interval is 5 minutes)
  • There has been no activity for 5 seconds


Site to Site replication is always to High priority. While other replications will be configured via creation and the default is medium.

So, the general answer would be, “Anywhere up to 15 minutes for replication to start. Depending on current replication status and the amount of data being replicated it could take longer”.

Some of variables that will also take into effect with site to site replication are:

Sender Pulse Mode – SMS 2003 SP1 and later versions and Configuration Manager 2007 support pulse mode. This mode allows you to specify the size of the data blocks that are sent, and also to specify a time delay between sending each data block. Pulse mode can be configured in the properties of an address on the Rate Limits tab. Pulse mode is useful when you have a very low network bandwidth available between sites.

Site Addresses and Address Data Transfer Rates – To control network load, you can schedule when SMS 2003 and Configuration Manager 2007 can use an address and the amount of network bandwidth that can be used when it sends to that address. Also, to provide increased throughput or to act as a backup if some addresses are unavailable, you can define multiple addresses to each destination site. If you define more than one address to a site, you can specify a priority for each address use for sending to that site. The results pane of the Configuration Manager console lists multiple addresses to a single destination site in priority order.

By default, the data transfer rate that SMS2003 and Configuration Manager 2007 sites will use to send data to an address (another site) is unlimited at all times. This means that when a site is transmitting data to another site, it could potentially consume 100% of the available bandwidth during the data transfer. However, you can limit how much connection bandwidth is used at different times of the day by setting maximum data transfer rate for the address. Setting limits on data transfer rates prevents SMS 2003 and Configuration Manager 2007 sites from consuming all the available bandwidth for the connection between the current site and the destination site. When you configure a maximum transfer rate for an address, the originating site will calculate the available bandwidth, and then apply the maximum transfer rate during the transmission process. For example, if the maximum transfer rate for an address is set to 50%, SMS/Configuration Manager will achieve 50% bandwidth utilization by sending a block of data to the destination site, and then pausing for the same amount of time it took to send the data before sending another block of data. Repeating this process for each block of data sent to the address will effectively provide 50% bandwidth utilization during the transfer.

Note that when you enable a limit to the maximum transfer rate for a given site, you are limited to one concurrent sending. This limitation takes precedence over the configured per site maximum concurrent sending’s that is configured on the applicable sender.

The default configuration on the Standard Sender for the maximum concurrent sending’s is three. This means that we can have three concurrent sending’s to any remote site that we have an address for. When we enable a Rate Limit on a remote site address, we decrease to 1/3 or 33% the maximum possible data transfer rate. This occurs because we reduce the number of concurrent sending’s from the default of three to only one. We cut the maximum transfer to only 1/6 or 16.67% of the default maximum transfer rate if we further configure a limit of 50% of connection bandwidth. Be careful when configuring these limits to avoid inadvertently creating conditions that result in replication data being generated faster than it can be replicated between sites. In this scenario, a backlog of non replicated data can build up on the site.

Fan Out Package Software Distribution Package Replication – In Configuration Manager 2007, refer to this functionality as “send from nearest site”. It enables a mode of forwarding the compressed copy of a package to sites that are more than one tier below the central site.

Historically, the central site was solely responsible for creating requests to send the compressed copy of the package to child sites.  You might wonder how this is handled in a site that is more than two levels deep: For example, if you have a site hierarchy where Site A is the central site, Site B is a child site of Site A, and Site C is a child site of Site B, how does the file get from Site A to Site C?

The answer is in the magic of Scheduler.  If multiple active send requests referenced the same source file, then the operation was optimized somewhat.  In the scenario where the compressed copy of the package has to be sent to both Sites B and Site C, send requests are broken into master and slave send requests. The file itself is sent once in the master send request, and then slave requests take care of forwarding the file further to child sites. Through this method, the file itself will only travel once across a given site-to-site link.

Scheduler looks to see if it has multiple send requests to non-directly addressed sites that have the same package that needs to be routed through the same address. If it finds them it combines them into master/slave send requests. The instruction file gets replaced with a “routing instruction” and this is sent only once to the sub-site. At the sub-site the routing instruction creates a routing package and a RTR (routing request). Scheduler will change the RTR to multiple send requests that all reference the same routing package (RPG) file. When Scheduler on the sub site begins to process the new requests this process could repeat itself yet again.

However, this method only optimizes site-to-site replication for send requests that are created at approximately the same time.  This works great if a package is created on a central site and immediately distributed to distribution points on all child sites. It does not work if each site is added independently or one at a time.  In these scenarios, multiple active send requests would not be present at a given time, so we are essentially back to a “master-only” replication model – the file is sent across each site-to-site link to the child site.

Here’s a flow chart of SCCM/ConfigMgr Replication.


This data was extracted from an existing document written by System Center Configuration Manager Support Team Blog. This document goes into greater detail of all types of replication within SCCM/ConfigMgr. Also discusses how security across sites work and tools to use to manage security keys.

Leave a Reply


We use cookies to ensure the best possible experience on our website. Detailed information on the use of cookies on this site is provided in our Privacy and Cookie Policy. Further instruction on how to disable our cookies can be found there.