Question for which I'm having trouble finding an answer on Google or Technet...
Does granting the SYSTEM user permissions to DFS-shared files and folders have any effect on DFS replication? (And while we're at it, is there any good reason not to let SYSTEM have permissions to DFS-shared files?)
It comes up because I have a collection of DFS namespaces and folders that I'm not able to make someone else's problem, and while troubleshooting a problem where one DFS replica just wasn't replicating with another for no discernible reason, I observed that the SYSTEM account didn't have any permissions granted to any of the files or folders in the folder in question.
So I set SYSTEM to have full control and propagated it down, and our DFS health diagnostic reports went from showing a backlog of ~80 files to a backlog of ~100,000... and things started replicating, including a number of files that had been missing on one server or the other (so more than just the permissions changes started replicating).
Naturally, this made me curious as to whether or not DFS needs the SYSTEM account to have permissions to do its work, or if perhaps it was just any change to folder tree in question that prompted DFS to jump into action. If it matters, our DFS namespaces were set up under 2000/2003, and I have just recently finished upgrading all the servers to 2008 R2 or 2012 (with UAC enabled, blech), but have not yet gotten around to raising the DFS namespace functional levels to Server 2008.
(And bonus points if anyone has an official Microsoft article on NTFS file permissions and the SYSTEM account as it pertains to DFS or network files.)
This thread on technet says SYSTEM needs full control. Not a very official source however, and further testing proves that it is wrong.
DFS Replication Service
I took a look at the DFS services on my Server 2008R2 machine with Process Explorer. dfsrs.exe, the Distributed File System Replication service, runs as "NT Authority\SYSTEM". However, it has SeBackupPrivilege and SeRestorePrivilege:
From Microsoft Privilege Constants:
With those permissions, the DFS Replication Service can ignore any file permissions - it is given permission to read, write, and set permissions on any file it pleases.
Testing
I created a folder in one of my DFS shares with a few files in it, set my account as the owner, and removed all permissions except for my account.
DFS replicated it to all the other servers without issue, and all the replicas had the same permissions.
Thus DFS is not dependant on any file system permissions to replicate.
I suspect in your case simply making any changes to the files would have caused DFS to wake up and see that they needed replicating. No idea what would have caused that situation in the first place though.
According to this article from Microsoft http://support.microsoft.com/kb/120929 "The system account and the administrator account (Administrators group) have the same file privileges, but they have different functions."
This means that the System Account is the same as a local admin, and it exists for the purpose of running system services with the privileges of an Administrator without requiring a password. The replication process in DFS-R is performed with this account.
The system user has no special significance in the File System or in a DFS setup any different from a regular Admin. However it can become confusing because Windows Admins are not always operating with Administrative privileges depending on how the program or shell was called, whereas a system account would likely always operate with escalated/admin token. I would guess that your DFS setup was just being buggy, and modifying ACLs perhaps caused some syscalls to be made, or file handles to be opened/refreshed that shook the proverbial cobwebs off.