This was an interesting example of how tangled some problems are. They look straightforward when you first look at them, but as you unwrap the layers it becomes more and more complex.
Problems adding a W2k3 DC to an existing W2K FT root
Such and such a company “.. is trying to add the W2K3 DC’s to the existing fault tolerant dfs root but gets the access denied errors with both dfsutil and UI. If he blows away the existing dfs structure and then recreates it on one of the 2003 dc's it is fine.”
After adding some debug code to DFS – we could see that there was a problem in a call to the registry. The problem was that we call RegConnectRegistry, and when we call this we connect via Remote Registry services.
There is a registry key called SecurePipeServers which contains the winreg subkey, and this controls remote access to the registry
The effected machine was lacking proper permissions to these keys:
“Local Service” permissions to:
But – the Local Service and other well-known security principals do not show up in UI when we tried to add them. Why was this? Due to a little known behavior in Windows Server 2003:
After you run the dcpromo.exe command on a Microsoft Windows Server 2003 computer to promote the server to a domain controller, the Local Service and other well-known security principals that are introduced with Windows Server 2003 do not appear.
You cannot resolve the well-known security principals when you try to add the well-known accounts by using NTFS file system permissions on a file or a folder. Additionally, you cannot resolve the well-known security principals when you use the ADSI Edit tool, the Group Policy Object Editor snap-in (Gpedit.msc), or Registry Editor. See http://support.microsoft.com/?kbid=827016 for more info.
Once we added the value directly (or made the ROOT Domain PDC a 2k3 DC) then the DFS problems went away.
How would you have come to this conclusion without adding debug code to the DFS component? Regmon.exe from comes to mind but I am curious how you would have done it.