Blogs

Troubleshooting erroneous sharing violations in the DFS Replication health report

  • Comments 2
  • Likes

We recently received an email from a customer who was seeing sharing violations in the DFS Replication health report, even though the sharing violations were no longer being reported in the DFS Replication event log. He writes:

“I recently converted a small DFS (with NTFRS) environment to DFSR.  At one point, the 'primary' server got a number of 'sharing violations', event id 4304  source DFSR in the DFS Replication event log. I checked some files, they did appear to be in use, so I assumed after everyone went home they would free up, the files would be staged, and the event log warnings would stop.  And I was correct, late in the evening the warnings stopped and did not reoccur all night.  However, I've also been running Health checks periodically to check the initial replication status.  The first strange item is that the Health report lists those sharing violations as ID 4302; the event log shows only 4304, no 4302. The other inconsistency is that the Health report stills lists all (hundreds) of sharing violations, even though the event log warnings have long since stopped.  When will these errors leave the Health check?  Does it require manual intervention on my part? (I checked some of the files, and they're not currently in use).”

The reason this occurs is the lack of an “anti-event” that indicates the sharing violation is no longer occurring. Many events in DFS Replication do have anti-events to indicate that a previous condition has been resolved, but sharing violations do not. The health report, however, expects an anti-event and therefore keeps reporting sharing violations as it waits for the anti-event to occur. The reason DFS Replication cannot report the anti-event is as follows:

  • Files that cannot be installed during the current sync session (after retries) are abandoned and become part of the next sync.
  • The next sync does not maintain the state of files that were abandoned from being installed during the previous sync session.
  • Therefore, when sharing violations are resolved at the next sync and the files are replicated, the DFSR service does not know that the files were previously in sharing violation and does not send an anti-event. 

The DFSR MOM Management Pack reports a consolidation event that triggers an alert when frequent sharing violations occur, which is an indication that the issue has not been resolved over time. To work around the issue of having erroneous sharing violations reported in the diagnostic report, you can clear the DFS Replication event log to get rid of old sharing violation events.

 --Jill

 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment