☰

从本地网络删除旧版 SBS 服务器后域控制器出现错误

tag-icon • tag-icon active-directory windows-server-2016 windows-sbs-2008
从本地网络删除旧版 SBS 服务器后域控制器出现错误

我正在将 a 迁移Windows SBS 2008到 aWindows Server 2016并且认为我已经到了最后一英里，关闭了源 SBS 服务器。

不过，我的域名似乎仍然依赖于旧版 SBS。当我从网络中移除旧服务器时（通过关闭它或拔掉网线），我遇到了 2 个问题：

启动时出错“仪表板”在目标服务器上

Windows Server Essentials:
    Networking domain controller server ist not accessible, some operations in Dashboard may not succeed. 
    Please check your network and make sure you can access the domain controller server.

启动时出错“Active Directory 用户和计算机”在目标服务器上

Active Directory Domain Services:
    Naming information can not be located because the specified domain  
    either does not exist or could not be contacted.

实际上，一旦源服务器与本地网络断开连接，就无法看到任何域用户帐户。也许后台运行的其他程序也会受到影响，但我并不知道。

到目前为止，我已经删除了DNS Manager源服务器上指向自身的一些条目。但这并没有起到什么作用，谷歌搜索也没有真正找到任何解决方案。我仍然在目标服务器 @ 中找到源服务器的一个条目>Active Directory Users and Computers >[domain] >Domain Controllers。

知道如何解决这两个问题吗？

编辑：

C:\Users\admin>netdom query fsmo   
Schema master           [newserver].[mydomain].local   
Domain naming master    [newserver].[mydomain].local   
PDC                     [newserver].[mydomain].local
RID pool manager        [newserver].[mydomain].local
Infrastructure master   [newserver].[mydomain].local   
The command completed successfully.

将 fsmo 角色移至 [newserver] 的过程相当坎坷，因为没有任何东西像我们尝试使用的操作指南中所述的那样工作。但最终，netdom 查询输出就像上面发布的那样（据我所知应该是这样的）

编辑2： 我得到了查看目标服务器条目的提示DNS Manager，并实际上得到了一些对源服务器的引用

  • >Forward-Lookupzones >myDomain>_msdcs有一个名称服务器（NS）条目仍然引用SBS - 我想我在这里更改了IP地址，所以它指向新的服务器，对吗？
  • >Forward-Lookupzones>[myDomain] >/sites >/Default-First-Site-Name >/_tcp有 2 个条目（一个用于旧服务器，一个用于新服务器）_gc，_kerbereos&_ldap
  • >Forward-Lookupzones>[myDomain] >/_tcp有 2 个条目（一个用于旧服务器，一个用于新服务器），分别为_gc、_kerbereos和_ldap_kpasswd
  • 类似情况（DNS 管理器中 [oldserver] 和 [newserver] 的双重条目_udp<和其他条目 - 我是否应该删除指向旧 SBS 服务器的版本？

编辑3：

我可以平2 个服务器相互连接ping [hostname].local（返回IPv6地址，其中ping (hostname)返回 IPv4 地址），但不是通过ping [domain].[hostname].local。如果我理解正确的话，这是同类问题的另一个指标。这是否指向解决方案？

编辑4：@expx

使用等效的德语术语搜索系统日志，服务器实际上返回了 3 个条目（其中 2 个只是确认，而不是错误）

Protokollname: System
Quelle: Microsoft-Windows-GroupPolicy
Datum: 06.07.2018 11:12:48
Ereignis-ID: 1058
Aufgabenkategorie:Keine
Level: Error
keywords:
User: SYSTEM
Computer: [oldserver].[domain].local
Description:

Error while processing the Group policy. The attempt to read the file "\so6.local\SysVol\so6.local\Policies{3474E153-5F07-4EC3-B816-9C0405CCF68F}\gpt.ini" from a Domaincontroller was not successful.
Group policiy settings can't be applied until this event is resolved. This could be a temporay problem which could have at least one of the following causes:
a) name resolution/network connection with the current Domaincontroller
b) Waiting period of the File Replication Service
c) the DFS-Clilent has been deactivated

Event-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-GroupPolicy" Guid="{aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}" />
<EventID>1058</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>1</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2018-07-06T09:12:48.941Z" />
<EventRecordID>1643448</EventRecordID>
<Correlation ActivityID="{C8828C15-D9E9-4FC6-8DE1-927F01129AB1}" />
<Execution ProcessID="520" ThreadID="1260" />
<Channel>System</Channel>
<Computer>SO6SERVER.so6.local</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="SupportInfo1">4</Data>
<Data Name="SupportInfo2">840</Data>
<Data Name="ProcessingMode">1</Data>
<Data Name="ProcessingTimeInMilliseconds">3027</Data>
<Data Name="ErrorCode">53</Data>
<Data Name="ErrorDescription">Der Netzwerkpfad wurde nicht gefunden. </Data>
<Data Name="DCName">\SO6SERVER.so6.local</Data>
<Data Name="GPOCNName">cn={3474E153-5F07-4EC3-B816-9C0405CCF68F},cn=policies,cn=system,DC=so6,DC=local</Data>
<Data Name="FilePath">\so6.local\SysVol\so6.local\Policies{3474E153-5F07-4EC3-B816-9C0405CCF68F}\gpt.ini</Data>
</EventData>
</Event>

实际上，当我访问时我可以读取提到的文件（作为域管理员）

答案1

AD 是多主环境，能够确定哪个 DC 处于活动状态，哪个 DC 处于死机状态。通常，您最终应该删除所有这些 DNS 记录，但如果旧 DC 只是脱离网络，这不应阻止您使用新 DC。在我看来，这似乎是某种复制问题。如果您导航到 \\newserver，您是否看到所有共享（NETLOGON 和 SYSVOL）？此外，旧服务器是 2008 还是 2008 R2。如果是普通的 2008，它可能使用 FRS 而不是 DFSR，这可能会导致新版本的 DC（2012 及更高版本）出现问题。登录到旧 DC，打开事件查看器，看看是否可以找到任何指向 FRS 的错误（例如 JOURNAL_WRAP 错误）。

答案2

我将从nltest /dsregdns新的 DC 开始，并从 DNS 管理器中删除旧 DC 的所有 DNS 记录。

如果旧的 DC 位于 AD 站点和服务中，也应该从那里将其删除。

可能是其他问题。如果您nltest /dsgetdc:<domain name>在新的 DC 上运行，它应该显示 TIMESERV，而net share在新的 DC 上应该显示 SYSVOL 和 NETLOGON。

答案3

由于我们尝试了不同的方法，因此我无法真正将解决方案归结于某个特定的操作。

我非常确定这与源服务器 (SBS 2008) 上的 FRS 与 DFSR 复制方法有关。我现在将 @expx 的答案标记为解决方案，尽管它并不是完全相同的东西

我认为在我们停止 FRS 并在源服务器上启动 DFSR 后，复制可能最终会走上正确的道路。我无法真正解释详细的步骤，但不能解释顺序，因为这是一个反复试验的过程。感谢大家的意见，这让我们最终解决了这个问题（至少目前看起来是这样）

相关内容