Ah, good old DFSR, with it’s highly complex management algorithm that is at times, a Law Unto Itself. What do you mean that file is newer? I’m going to overwrite it with THIS one!
DFSR is also full of false truths and true lies. Event ID’s that don’t tell you what’s wrong. Logs that make out that everything is broken when it isn’t… Weeks of over written data that no one knew was happening… But sadly if you don’t have hardware replication, you probably use this. Don’t get me wrong, when it works properly, it’s great, but there’s sometimes quite a management overhead, plus a lot of time and experience involved when it needs to get fixed.
This link has an amazing script that was similar to part of my checks in a previous role, whereby I had a few scripts running as part of Daily Checks for the team, that reported on DFSR, Exchange and AD. It emailed pretty pictures and everything (you know how people love pretty pictures!) So as my first post towards Checks and DFSR management – the following link is fantastic.
I will say though, as part of any infrastructure related checks or notifications, it’s what works for you and your team. I had a great Project Manager once who said that if you get the process right, then everything works. If the process fails and a person followed the process, then the process needs changing. Which stands to reason – you need the process that people need to follow, that takes into consideration everything that needs to happen and there’s no point having a barrage of alerts sent to email, if the person involved doesn’t read them, understand them and put down somewhere he’s done all of the above.
Kibble Network 