We recently added a second DC to our network at a different site. The DCs do not appear to have any difficulty communicating via the network, and AD objects (users, computers etc) are synchronising correctly. However, group policies are not. Examining the C:\Windows\SYSVOL\domain
folder on the new DC shows that it is empty, whereas on the old DC it contains the Policies
and scripts
folders with associated contents.
However, dcdiag
does not show any obvious hints as to what is wrong (see output below), and DFSR seems to believe that it is replicating correctly, as per the output of dfsradmin backlog
. dfsrdiag replicationstate
shows no active connections, but I'm not sure whether or not this is normal; dfsradmin membership list
shows both DCs.
Does anyone have any ideas? I'm pretty much at my wit's end; I'd even try manually copying the policies over were it not for the fact that there are many permissions issues involved in doing so.
dcdiag
output:C:\Windows\system32>dcdiag
Directory Server Diagnosis
Performing initial setup:
Trying to find home server...
Home Server = HACTAR
* Identified AD Forest.
Done gathering initial info.
Doing initial required tests
Testing server: Saturn\HACTAR
Starting test: Connectivity
......................... HACTAR passed test Connectivity
Doing primary tests
Testing server: Saturn\HACTAR
Starting test: Advertising
......................... HACTAR passed test Advertising
Starting test: FrsEvent
......................... HACTAR passed test FrsEvent
Starting test: DFSREvent
There are warning or error events within the last 24 hours after the
SYSVOL has been shared. Failing SYSVOL replication problems may cause
Group Policy problems.
......................... HACTAR failed test DFSREvent
Starting test: SysVolCheck
......................... HACTAR passed test SysVolCheck
Starting test: KccEvent
......................... HACTAR passed test KccEvent
Starting test: KnowsOfRoleHolders
......................... HACTAR passed test KnowsOfRoleHolders
Starting test: MachineAccount
......................... HACTAR passed test MachineAccount
Starting test: NCSecDesc
......................... HACTAR passed test NCSecDesc
Starting test: NetLogons
Unable to connect to the NETLOGON share! (\\HACTAR\netlogon)
[HACTAR] An net use or LsaPolicy operation failed with error 67,
The network name cannot be found..
......................... HACTAR failed test NetLogons
Starting test: ObjectsReplicated
......................... HACTAR passed test ObjectsReplicated
Starting test: Replications
......................... HACTAR passed test Replications
Starting test: RidManager
......................... HACTAR passed test RidManager
Starting test: Services
......................... HACTAR passed test Services
Starting test: SystemLog
An error event occurred. EventID: 0x00000422
Time Generated: 10/10/2014 14:39:05
Event String:
The processing of Group Policy failed. Windows attempted to read the
file \\bistromath.domains.h2g2.local\sysvol\bistromath.domains.h2g2.local\Polic
ies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini from a domain controller and
was not successful. Group Policy settings may not be applied until this event is
resolved. This issue may be transient and could be caused by one or more of the
following:
[snip: many identical log entries]
......................... HACTAR failed test SystemLog
Starting test: VerifyReferences
......................... HACTAR passed test VerifyReferences
Running partition tests on : ForestDnsZones
Starting test: CheckSDRefDom
......................... ForestDnsZones passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... ForestDnsZones passed test
CrossRefValidation
Running partition tests on : DomainDnsZones
Starting test: CheckSDRefDom
......................... DomainDnsZones passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... DomainDnsZones passed test
CrossRefValidation
Running partition tests on : Schema
Starting test: CheckSDRefDom
......................... Schema passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... Schema passed test CrossRefValidation
Running partition tests on : Configuration
Starting test: CheckSDRefDom
......................... Configuration passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... Configuration passed test CrossRefValidation
Running partition tests on : bistromath
Starting test: CheckSDRefDom
......................... bistromath passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... bistromath passed test CrossRefValidation
Running enterprise tests on : bistromath.domains.h2g2.local
Starting test: LocatorCheck
......................... bistromath.domains.h2g2.local passed test
LocatorCheck
Starting test: Intersite
......................... bistromath.domains.h2g2.local passed test
Intersite
dfsrdiag backlog
:C:\Windows\system32>dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:queeg /rmem:hactar
No Backlog - member <hactar> is in sync with partner <queeg>
dfsrdiag replicationstate
:C:\Windows\system32>dfsrdiag replicationstate
Summary
Active inbound connections: 0
Updates received: 0
Active outbound connections: 0
Updates sent out: 0
dfsradmin membership list
:C:\Windows\system32>dfsradmin membership list /rgname:"Domain System Volume"
MemName RfName LocalPath StagingPath StagingSize
HACTAR SYSVOL Share C:\Windows\SYSVOL\domain C:\Windows\SYSVOL\staging areas\bistromath.domains.h2g2.local 4096
QUEEG SYSVOL Share C:\Windows\SYSVOL\domain C:\Windows\SYSVOL\staging areas\bistromath.domains.h2g2.local 4096
I know this is an old question, but I encountered this same issue after promoting a new Windows 2016 VM to be a new DC. Google led me here.
Here's what I learned, in the hope it helps others:
If any of your DC are being backed up using VSS, VSS pauses DFSR. This is normal. The event(s) that are logged may cause DCDIAG to complain.
You may see some hits around that say something like "Clear the DFS event log and run DCDIAG again". It is true that DCDIAG does not complain about DFSR if you have cleared the log, but this is cheating, of course.
Ultimately, you need to verify that DFS replication is in fact ongoing.
The official way to do this is in the DFS Management tool (System Manager | Tools | DFS Management)
In DSF Management:
The report will open in your default browser and indicates if the propagation worked and how long it took.
Ultimately, I resolved this issue by demoting the new DC, leaving it as a simple member for several days, then re-promoting it (in order to perform additional tests). Re-promoting it caused the new controller to replicate the previously missing files properly, rendering the tests somewhat redundant.
However, I should note that I did try demoting and re-promoting the new DC earlier, to no avail. It may be that the long period in which it wasn't doing DFS replication caused some form of timeout; given the lack of clear data that's my best guess as to how this got sorted.
User contributions licensed under CC BY-SA 3.0