Назад | Перейти на главную страницу

Ошибка контроллера домена после удаления устаревшего сервера SBS из локальной сети

Я переношу Windows SBS 2008 к Windows 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 на исходном сервере, указывая на себя. Но это еще не помогло, и поиск результатов в Google не дает никаких решений. Я все еще нахожу одну запись для исходного сервера на целевом сервере @ >Active Directory Users and Computers >[domain] >Domain Controllers.

Есть идеи, как решить эти 2 проблемы?

РЕДАКТИРОВАТЬ:

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 на [новый сервер] было довольно ухабистой поездкой, потому что ничто не работало так, как описано в практических рекомендациях, которые мы пытались использовать. Но, в конце концов, вывод запроса 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
аналогичная ситуация (двойные записи для [oldserver] и [newserver] для _udp<& другие записи в диспетчере DNS - нужно ли мне удалить версии, указывающие на старый сервер 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>

практически я могу прочитать упомянутый файл, когда захожу (как администратор домена)

Я бы начал с nltest /dsregdns на новом контроллере домена и удалите все записи DNS для старого контроллера домена из диспетчера DNS.

Если старый контроллер домена находится в AD Sites and Services, его также следует удалить оттуда.

Могут быть другие проблемы. Если ты бежишь nltest /dsgetdc:<domain name> на новом контроллере домена должен отображаться TIMESERV и net share на новом DC должны отображаться SYSVOL и NETLOGON.

AD - это среда с несколькими мастерами, способная определять, какой DC активен, а какой мертв. В общем, вы должны удалить все эти записи DNS в конце, но это не должно помешать вам использовать новый DC, если старый DC просто вне сети. Мне это кажется какой-то проблемой репликации. если вы перейдете к \\ newserver, вы увидите все общие ресурсы (NETLOGON и SYSVOL)? Также стоит старый сервер 2008 или 2008 R2. Если это обычный 2008, он может использовать FRS вместо DFSR, что может вызвать проблемы с новыми версиями контроллеров домена (2012 и более поздних версий). Войдите в старый DC, откройте средство просмотра событий и посмотрите, сможете ли вы найти какие-либо ошибки, указывающие на FRS (например, ошибки JOURNAL_WRAP).

Поскольку мы пробовали разные вещи, я не могу связать решение с конкретным действием.

Я почти уверен, что это было связано с методом репликации FRS и DFSR на исходном сервере (SBS 2008). Я отмечаю ответ @expx, говоря, что сейчас это решение, хотя это было не совсем то же самое

Я думаю, что репликация может наконец пойти по правильному пути после того, как мы остановили FRS и запустили DFSR на исходном сервере. Я не могу объяснить подробные шаги, но не последовательность, поскольку это был метод проб и ошибок. Спасибо всем за вклад, который побудил нас в конце концов покончить с этим (по крайней мере, так это выглядит сейчас)