DFSR Diagnostics Report shows sharing violations events in Windows Server even though the files have already been replicated
This article provides a workaround for an issue where DFSR Diagnostics Report shows sharing violations events even though the files have already been replicated.
Applies to: Windows Server 2012 R2
Original KB number: 973836
When you run the Distributed File System Replication (DFSR) Diagnostics Report (DFSR Health Report) on a Microsoft Windows Server 2008-based computer or on a Windows Server 2003-based computer, the report contains many entries for the sharing violations events. However, when you check the files on the replication partner, you find that the files have already been replicated.
This issue occurs in the current implementation of DFSR because no anti-events are triggered when the files are replicated. Therefore, the reporting state of the files remains as sharing violated.
To determine the real state of the file, use the
DFSRDIAG BACKLOG command to check for sharing violations. The command output provides a list of the first 100 files that are not replicated.
There two kinds of DFSR events for sharing violations: Event ID 4302 and Event ID 4304. The DFSR Diagnostics combines both kinds of events, and reports them only as Event ID 4302.
The following information explains more about these two kinds of events.
Event ID 4302: A local sharing violation occurs when the service can't receive an updated file because the local file is being used. This occurs on the receive side of the file change. The file is already replicated. However, it can't be moved from the installing directory to the final destination.
Event ID 4304: The service can't stage a file for replication because of a sharing violation. This occurs on the "send" side of the file change. DFSR wants to stage or copy the file for replication. However, an exclusive lock prevents this.