更新 1

Question

我有两台服务器，一台旧的 AD 服务器（服务器 A）和一台全新的服务器（服务器 B）。我正在尝试从旧服务器迁移到新服务器，因此我按照以下步骤设置了第二台服务器指示并将第二台服务器添加为同一域内的域控制器。

因此，服务器领域一切都很顺利，两台服务器都在旧域上，并配置为域控制器。现在我想关闭服务器 A（最终将退役，但我想暂时将其保留为备份）。所以我禁用了AD 复制在服务器 B 上并调整 DNS 设置，使服务器 B 不再指向服务器 A：

然后我关闭了服务器 A。突然（在服务器 B 上）我无法通过“Active Directory 用户和计算机”或“Active Directory 管理中心”访问 AD 的配置。我得到了以下各种推导：

无法找到命名信息，因为：RPC 服务器不可用

无法连接到任何域。请刷新或在连接可用时重试。

无法联系以下域控制器：127.0.0.1。指定的域不存在或无法联系。

因此，它似乎可以正常工作（我可以使用域凭据登录，使用 AD 的第三方应用程序似乎可以工作），但我无法访问任何东西。我是不是漏掉了什么，我不明白为什么服务器 B 不直接将自己检测为新的 AD 服务器。我以为不再有神奇的“主要” AD 服务器。互联网上大多数人建议降级旧 AD 服务器，但在这种情况下我宁愿不这样做。是否有可能在不降级旧服务器的情况下完成 AD 迁移？

更新 1

按照@KatherineVillyard 的建议更新 FSMO 角色后，我遇到了大多数相同的错误，但在“Active Directory 管理中心”中，我遇到了一个有趣的新错误，当您选择“更改域控制器”时，我得到了：

在运行 Active Directory Web 服务 (ADWS) 的 DEV 域中找不到可用的服务器。

这很有趣，因为我检查过，我确定该服务正在我的新机器上运行。我想知道问题是否DNS 相关。我已经尝试重新调整网络设置并重新启动服务器。很多时候，遇到这类问题时，我似乎只是把东西扔到墙上，看看什么东西会粘住 :(

更新 2

我尝试了很多方法，但似乎只需禁用服务器 A 上的 NetLogin 服务即可关闭服务器 A，从而重现该问题。一旦服务器 A 上的该服务停止响应，您将无法再通过任一服务器上的任何管理单元控件访问该域（抛出类似类型的错误）。

当您在服务器 B 上运行以下命令时，我还注意到一些有趣的事情：

nltest /DSGetDC:MYDOMAINHERE

您将获得以下内容（假设两台服务器上都在运行 netlogin）：

DC：\\(服务器 A)
地址：\\(服务器 A IP 地址)
Dom Guid：XXXX
Dom 名称：(MYDOMAINHERE)
森林名称：(MYDOMAINHERE)
Dc 站点名称：Default-First-Site-Name
我们的站点名称：Default-First-Site-Name...

我在新服务器（B）上注意到的另一件事是，如果你运行（“dcdiag /test：advertising”），你会收到以下消息（旧服务器（A）上没有问题）：

测试服务器：Default-First-Site-Name\(服务器 B)
开始测试：广告
警告：当我们尝试访问（服务器 B）时，DsGetDcName 返回了 \\(服务器 A).(MYDOMAINHERE) 的信息。
服务器未响应或被认为不适合。
.........................（服务器 B）测试失败 广告

我觉得这确实是新服务器（B）上的某种 DNS 配置问题，但我已删除了服务器 B 中对服务器 A 的所有引用DNS 管理器并重新启动服务器。整个过程有点像黑匣子，“DSGetDC”从哪里获取这些信息？“(DNS) 服务器”，应该是服务器 B，而不应该引用服务器 A，显然我这里遗漏了一些东西 :(

Answer 1

不存在“神奇的主 AD 服务器”，但存在是 FSMO 角色。根据您提供的信息，我相当确定服务器 A 拥有一个或所有 FSMO 角色。

您可能希望重新启动服务器 A，将所有 FSMO 角色平稳地转移到服务器 B，然后将其关闭。 本文告诉您如何使用 PowerShell 执行此操作。如果出现链接失效，以下是主要要点：

查找当前的主人：

Get-ADForest example.com| ft DomainNamingMaster, SchemaMaster
Get-ADDomain example.com | ft InfrastructureMaster, PDCEmulator, RIDMaster

加载 Active Directory powershell 模块：

Import-Module ActiveDirectory

您可以根据名称或角色编号移动角色。

Move-ADDirectoryServerOperationMasterRole "Server B" –OperationMasterRole 0,1,2,3,4

或者

Move-ADDirectoryServerOperationMasterRole "Server B" –OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster

如果失败，请在末尾添加 -force，例如

Move-ADDirectoryServerOperationMasterRole “dc2” –OperationMasterRole 0,1,2,3,4 -force

你也可以使用 GUI如果你更喜欢。

Answer 2

我放弃 ：（

我把它交给同事去弄清楚，我们最终发现问题与“DFSR SYSVOL 复制”有关。我们降级并重新升级了新服务器 (B)，以尝试清除任何无效配置。然后我们按照问题的解决方案进行操作，详情请见关注帖子事实证明，运行场景 1 和 2 中的步骤后，新服务器 (B) 上的注册表项“SysvolReady”被设置为零。

（以防链接失效）

要解决此问题，请按所述顺序执行以下所有步骤，并在以域管理员身份运行时使用提升的 CMD 提示符：

场景 1：

1. 通过在 PDCE 上运行来确定哪个安全组策略正在将此设置应用于 DC：

   GPRESULT.EXE /H secpol.htm

2. 在 Web 浏览器中打开 secpol.htm，然后单击“显示全部”。搜索条目“管理审核和安全日志”。它将列出应用此设置的组策略。

3. 使用 GPMC.MSC，编辑该组策略以包括“管理员”组。

4. 允许 AD 和 SYSVOL 复制在所有 DC 上聚合。在 PDCE 上运行：

   GPUPDATE /FORCE

5. 注销 PDCE 并重新登录，以便使用用户权限分配更新您的安全令牌。

6. 跑步：

   DFSRMIG.EXE/创建全局对象

7. 允许 AD 和 SYSVOL 复制在所有 DC 上聚合。在 PDCE 上运行：

   DFSRDIAG.EXE 波拉德

   DFSRMIG.EXE/获取迁移状态

8. 验证部分或全部 DC 是否已达到“准备就绪”状态并准备好重定向。此时，您可以正常进行迁移。请参阅迁移最佳实践下方的更多信息部分。

场景 2：

1. 通过在 PDCE 上运行来确定哪个安全组策略正在将此设置应用于 DC：

   GPRESULT.EXE /H secpol.htm

2. 在 Web 浏览器中打开 secpol.htm，然后单击“显示全部”。搜索条目“管理审核和安全日志”。它将列出应用此设置的组策略。

3. 使用 GPMC.MSC，编辑该组策略以包括“管理员”组。

4. 允许 AD 和 SYSVOL 复制在所有 DC 上聚合。在受影响的 DC 上运行：

   GPUPDATE /FORCE

5. 重新启动该 DC 上的 DFSR 服务。

6. 验证 DC 现在共享 SYSVOL 和 NETLOGON，并复制 SYSVOL 入站。

“warrenw 注释 5/3/2013”

1. 手动共享 sysvol - 编辑此注册表值 - 键 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\parameters
   值 SysvolReady = 1

   运行 net share 以确保 sysvol 已共享。

2. 打开策略并将用户或组添加到“管理审核和安全日志”用户权限。

3. 运行 gpupdate force。

我们认为复制和 netlogin 状态注册表项失败是问题的关键，但我们尝试了许多其他较小的事情，这些也可能是解决问题的一个因素。不过，希望这篇文章将来能对某些人有所帮助。