You use Distributed File System Replication (DFSR) to publish content to branch offices.
All the changes to the replicated content occur on one server or on a subset of the servers that are members of the replicated folders. None of the other servers have any updates created on them.
In this scenario, you notice intermittent and unexplained spikes in the backlog. The number of spikes is approximately equal to the number of objects in the replicated folder.
The issue occurs because of the way the DFS Replication server determines stale membership of its replication partners. If a DFS Replication server does not receive an update from one of its replication partners in more than 60 days, the server determines that the partner is stale. The DFS Replication server then updates all records that are related to the stale partner. This operation generates a backlog on the DFS Replication server when it is processing tombstones that must be sent to all replication partners. Additionally, the stale partner must send out a notification that it is still active. If this scenario happens on multiple DFS Replication servers at the same time, you find very large increases in replication backlogs.
A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.
If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.
Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft website:
Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.
To apply this hotfix, your computer must be running Windows Server 2008 R2 or Windows Server 2008 Service Pack 2 (SP2) . Additionally, you must install the Distributed File System (DFS) Replication role service on the computer.
To use the hotfix in this package, you do not have to make any changes to the registry.
You may have to restart the computer after you apply this hotfix.
Hotfix replacement information
This hotfix does not replace a previously released hotfix.
The English (United States) version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.
Windows Server 2008 file information notes
Important Windows Vista hotfixes and Windows Server 2008 hotfixes are included in the same packages. However, only "Windows Vista" is listed on the Hotfix Request page. To request the hotfix package that applies to one or both operating systems, select the hotfix that is listed under "Windows Vista" on the page. Always refer to the "Applies To" section in articles to determine the actual operating system that each hotfix applies to.
The files that apply to a specific product, SR_Level (RTM, SPn), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table.
6.0.600 2. 23xxx
Windows Server 2008
The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the "Additional file information for Windows Server 2008" section. MUM files and MANIFEST files, and the associated security catalog (.cat) files, are extremely important to maintain the state of the updated components. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.
For all supported x86-based versions of Windows Server 2008
For all supported x64-based versions of Windows Server 2008
Windows Server 2008 R2 file information notes
Important Windows 7 hotfixes and Windows Server 2008 R2 hotfixes are included in the same packages. However, hotfixes on the Hotfix Request page are listed under both operating systems. To request the hotfix package that applies to one or both operating systems, select the hotfix that is listed under "Windows 7/Windows Server 2008 R2" on the page. Always refer to the "Applies To" section in articles to determine the actual operating system that each hotfix applies to.
The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the "Additional file information for Windows Server 2008 R2" section. MUM and MANIFEST files, and the associated security catalog (.cat) files, are extremely important to maintain the state of the updated components. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.
For all supported x64-based versions of Windows Server 2008 R2
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:
824684 Description of the standard terminology that is used to describe Microsoft software updates
After the hotfix is installed on all Windows Server 2008 R2-based DFSR members, the same issue may occur if one of the following conditions is true:
The member loses its DFSR database completely, and then receives a new database GUID when the database is rebuilt.
Note You may be more aware of the condition when you use the StopReplicationOnAutoRecovery registry setting that is described in the following Microsoft Knowledge Base article:
2663685 Changes that are not replicated to a downstream server are lost on the upstream server after an automatic recovery process occurs in a DFS Replication environment in Windows Server 2008 R2
The member is up and running, but it cannot contact any downstream partner with its Heartbeat updates, for example because of completely closed replication schedules.
Additional file information
Additional file information for Windows Server 2008
Additional files for all supported x86-based versions of Windows Server 2008
Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Standard, Windows Server 2008 Datacenter, Windows Server 2008 Datacenter without Hyper-V, Windows Server 2008 Enterprise, Windows Server 2008 Enterprise without Hyper-V, Windows Server 2008 Standard, Windows Server 2008 Standard without Hyper-V