Find out what SYSVOL on DFSR is doing, part 2

This is a continuation of a previous post: https://blogs.technet.microsoft.com/389thoughts/2016/09/06/find-out-what-your-sysvol-on-dfsr-is-doing/

Since that blog and its script were published I have run it myself a couple of times on customer sites, and received reports from other people who tried it as well. The script had one problem where I neglected the possibility that a DC had zero conflicts. This can happen in extraordinary well managed and static environments, single-DC domains, or with very recently promoted DCs. Take your pick. See the updated script here: https://gallery.technet.microsoft.com/Summarize-conflict-and-f71684ad

The data showed some interesting patterns. What do you make of this one? This is the output of Get-SysvolDFSRConflictSummary | Out-Gridview, for a domain with seven DCs.

There are many more deletes than conflicts. This stands to reason: we are talking about SYSVOL, and normally all GPO updates happen on the PDC making it hard to create conflicts in the first place. The deletes happen like this: on the PDC a file is deleted, for instance by removing a GPO. On the PDC the file is just gone. But the other DCs in the domain see an incoming deletion and instead of deleting the file straight away, they move the file to the ConflictAndDeleted folder.

That's what you see here: the DC12 is the PDC of the domain, so has almost no incoming deletes. All other DCs take the incoming deletes and move them to ConflictAndDeleted. The other DC with markedly less deletes is DC14. This turns out to be a newly promoted DC, so it simply has seen less incoming deletes because it has not existed as long as the other DCs.

But today I also got a very different example:

More than 40,000 deletes for almost all DCs! About a 100 times more than the other sample. What's going on? Further investigation showed that all deleted files are policy templates. The GPOs are managed by Advanced Group Policy Management (AGPM), and all deletes that we checked corresponded to a check-in action by AGPM. So, AGPM does not play nice by selecting the PDC as it really should, but just picks a random DC in its own site.

To actually check on the activity in ConflictAndDeleted you can use the helper function called Get-SysvolPreservedFiles in the script. Dot-source or F8 the function, then run it targeting a specific DC:

[powershell]
Get-SysvolPreservedFiles -hostname dc23.earth.sol.local | Out-GridView
[/powershell]

That gets you the full list to play with: