我们最近在另一个站点向我们的网络添加了第二个 DC。DC 似乎在通过网络进行通信时没有任何困难，并且 AD 对象（用户、计算机等）正在正确同步。但是，组策略却不是。检查C:\Windows\SYSVOL\domain新 DC 上的文件夹显示它是空的，而在旧 DC 上它包含Policies和scripts文件夹以及相关内容。
但是，dcdiag没有显示任何明显的提示表明哪里出了问题（见下面的输出），并且 DFSR 似乎认为它正在正确复制，根据输出dfsradmin backlog。dfsrdiag replicationstate显示没有活动连接，但我不确定这是否正常；dfsradmin membership list显示两个 DC。
有人有什么想法吗？我几乎束手无策了；如果不是因为这样做会涉及许多权限问题，我甚至会尝试手动复制策略。
dcdiag输出：
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
答案1
我知道这是一个老问题，但是在将新的 Windows 2016 VM 升级为新的 DC 后，我遇到了同样的问题。谷歌引导我到这里。
以下是我学到的知识，希望能够帮助其他人：
如果您的任何 DC 正在使用 VSS 进行备份，VSS 会暂停 DFSR。这是正常的。记录的事件可能会导致 DCDIAG 发出投诉。
您可能会看到一些类似“清除 DFS 事件日志并再次运行 DCDIAG”的提示。确实，如果您清除了日志，DCDIAG 不会抱怨 DFSR，但这当然是作弊。
最后，您需要验证 DFS 复制是否确实正在进行。
执行此操作的官方方法是使用 DFS 管理工具（系统管理器 | 工具 | DFS 管理）
在 DSF 管理中：
- 在左侧操作按钮中，单击创建诊断报告
- 选择传播测试，按照向导继续操作以开始测试
- 几个小时后（您的间隔可能会有所不同；我的间隔是 1.6 小时，用于三个 DC），返回 DFS 管理并再次单击创建诊断报告
- 选择传播报告，并生成报告。
该报告将在您的默认浏览器中打开并指示传播是否有效以及花费了多长时间。
答案2
最终，我通过降级新 DC、将其作为简单成员保留几天，然后重新提升它（以便执行其他测试）解决了此问题。重新提升它会导致新控制器正确复制之前丢失的文件，从而使测试变得有些多余。
但是，我应该指出，我之前确实尝试过降级并重新升级新的 DC，但无济于事。可能是因为长时间没有进行 DFS 复制导致某种形式的超时；鉴于缺乏清晰的数据，这是我对如何解决此问题的最佳猜测。