Files that are replicated through FRS are deleted on downstream replicas in Windows
When you use the File Replication Service (FRS) in Windows, the replicated files in either the Sysvol or DFS replica sets are unexpectedly deleted on all replication partners after the existing files are replaced by newer versions. The deletions may not be noticed for minutes, hours, or days after the replacement because of replication backlogs and latency between FRS replica members.
Note "Replacement" in this context refers to a series of operations that are performed on the replicated files: a new file is created in the folder (for example, a temporary file) and is then renamed in order to replace an existing file. These file operations are typical of, but are not limited to, the Group Policy Management Console, the Advanced Group Policy Management (AGPM) MMC, and certain Windows PowerShell cmdlets (for example, Restore-GPO) of Windows Server 2012 and later).
Depending on the use of the deleted files by applications and services, an error may be reported when a file is missing from the replicated folder. For missing Group Policy files in the Sysvol replica set, administrators may find missing policy settings or discover that clients aren't processing expected policy settings sometime after the policy is changed. Other symptoms include the following:
- For a missing GPT.INI policy file, a client reports event ID 7017 in the Microsoft-Windows-GroupPolicy/Operational event log channel. The error states the following: The system calls to access specified file completed. <UNC path to the GPT.INI file in the Sysvol share>. The calls failed after X milliseconds." When you run a manual policy update by using gpupdate.exe, it may report "The processing of Group Policy failed. Windows tried to read the file <UNC path to GPT.INI file in the Sysvol share> from a domain controller and was not successful.
- DirectAccess (DA) policy settings aren't applied to clients as expected, and clients can't connect to DirectAccess servers.
There’s an issue in FRS that downstream servers encounter a sharing violation of the replaced file, and this causes the new file to be deleted. When the downstream server cannot process the FRS change because of the sharing violation, the FRS conflict resolution operation chooses to keep the older file, and then it replicates the deletion of the new file to all other replication partners.
There are currently no plans to fix this behavior. Instead, Microsoft advises that you transition Sysvol and DFS FRS replica sets to the Distributed File System Replication (DFSR) service.
For Sysvol, migration from FRS to DFSR has minimal requirements, and it takes advantage of the Dfsrmig.exe utility. For more information, see SYSVOL Replication Migration Guide: FRS to DFS replication.
For DFS FRS replica sets, you can manually transition to DFSR by using the methods in the DFS Operations Guide: Migrating from FRS to DFS Replication. You might also consider using the FRS2DFSR.EXE utility that's described at FRS to DFSR Migration Tool.
Article ID: 3099433 - Last Review: 11/10/2015 05:59:00 - Revision: 2.0
Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Standard, Windows Server 2012 Datacenter, Windows Server 2012 Standard, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard, Windows 7 Enterprise, Windows 7 Professional, Windows 8, Windows 8 Enterprise, Windows 8.1, Windows 8.1 Enterprise
- kbexpertiseadvanced kbsurveynew kbtshoot KB3099433