none
После выключения серваков на новогодние праздники,один DC перестал видет другой.Нет репликации

    Вопрос

  • Решил как то весь офис переехать на новое место.Под ноый год,а потом дней пять все было выключено.А когда включили,то посыпались такие логи.

    Подскажите куда копать?Днс у каждого DC свои.У 192.168.2.6 стоит первым он же,пробовал  поставить 127.0.0.1,но разницы нету

    проблемны DC перезагружал уже

    есть вариант сделать принудительно репликацию,но этим я буду заниматься сегодня вечером.

    с основного как,мне очень странно
    DC=rxt,DC=ru
        Default-First-Site-Name\ADREPLICA01 через  RPC
            DSA - GUID объекта: 16eaad1d-f56c-4f7b-a218-7f150931ba93
            Последняя попытка @ 2018-01-12 10:56:04 успешна.

    CN=Configuration,DC=rxt,DC=ru
        Default-First-Site-Name\ADREPLICA01 через  RPC
            DSA - GUID объекта: 16eaad1d-f56c-4f7b-a218-7f150931ba93
            Последняя попытка @ 2018-01-12 10:56:04 успешна.

    CN=Schema,CN=Configuration,DC=rxt,DC=ru
        Default-First-Site-Name\ADREPLICA01 через  RPC
            DSA - GUID объекта: 16eaad1d-f56c-4f7b-a218-7f150931ba93
            Последняя попытка @ 2018-01-12 10:56:04 успешна.

    DC=DomainDnsZones,DC=rxt,DC=ru
        Default-First-Site-Name\ADREPLICA01 через  RPC
            DSA - GUID объекта: 16eaad1d-f56c-4f7b-a218-7f150931ba93
            Последняя попытка @ 2018-01-12 10:56:04 успешна.

    DC=ForestDnsZones,DC=rxt,DC=ru
        Default-First-Site-Name\ADREPLICA01 через  RPC
            DSA - GUID объекта: 16eaad1d-f56c-4f7b-a218-7f150931ba93
            Последняя попытка @ 2018-01-12 10:56:04 успешна.

    с второго

    Repadmin: выполнение команды /showrepl контроллере домена localhost с полным доступом
    Default-First-Site-Name\ADREPLICA01
    Параметры DSA: IS_GC
    Параметры сайта: (none)
    DSA - GUID объекта: 16eaad1d-f56c-4f7b-a218-7f150931ba93
    DSA - код вызова: bf86d998-afcc-4341-b482-1178c5197d00

    ==== ВХОДЯЩИЕ СОСЕДИ   ======================================

    DC=rxt,DC=ru
        Default-First-Site-Name\AD через  RPC
            DSA - GUID объекта: 9ebdc9fb-8753-4f57-ae2f-61ac5f6c8b41
            Последняя попытка @ 2018-01-12 10:48:26 завершена с ошибкой, результат -2146893022 (0x80090322):
                Главное конечное имя неверно.
            169 последовательных ошибок.
            Последний успех @ 2017-12-31 00:03:59.

    CN=Configuration,DC=rxt,DC=ru
        Default-First-Site-Name\AD через  RPC
            DSA - GUID объекта: 9ebdc9fb-8753-4f57-ae2f-61ac5f6c8b41
            Последняя попытка @ 2018-01-12 10:48:26 завершена с ошибкой, результат -2146893022 (0x80090322):
                Главное конечное имя неверно.
            165 последовательных ошибок.
            Последний успех @ 2017-12-30 23:59:04.

    CN=Schema,CN=Configuration,DC=rxt,DC=ru
        Default-First-Site-Name\AD через  RPC
            DSA - GUID объекта: 9ebdc9fb-8753-4f57-ae2f-61ac5f6c8b41
            Последняя попытка @ 2018-01-12 10:48:26 завершена с ошибкой, результат -2146893022 (0x80090322):
                Главное конечное имя неверно.
            165 последовательных ошибок.
            Последний успех @ 2017-12-30 23:59:04.

    DC=DomainDnsZones,DC=rxt,DC=ru
        Default-First-Site-Name\AD через  RPC
            DSA - GUID объекта: 9ebdc9fb-8753-4f57-ae2f-61ac5f6c8b41
            Последняя попытка @ 2018-01-12 10:48:26 завершена с ошибкой, результат 1256 (0x4e8):
                Удаленная система недоступна. За информацией о разрешении проблем в сети, обратитесь к справочной системе Wi
    ndows.
            165 последовательных ошибок.
            Последний успех @ 2017-12-30 23:59:04.

    DC=ForestDnsZones,DC=rxt,DC=ru
        Default-First-Site-Name\AD через  RPC
            DSA - GUID объекта: 9ebdc9fb-8753-4f57-ae2f-61ac5f6c8b41
            Последняя попытка @ 2018-01-12 10:48:26 завершена с ошибкой, результат 1256 (0x4e8):
                Удаленная система недоступна. За информацией о разрешении проблем в сети, обратитесь к справочной системе Wi
    ndows.
            165 последовательных ошибок.
            Последний успех @ 2017-12-30 23:59:04.

    Источник: Default-First-Site-Name\AD
    ******* 169 ПОСЛЕДОВАТЕЛЬНЫХ ОШИБОК с 2017-12-31 00:03:59
    Последняя ошибка: -2146893022 (0x80090322):

    в логах у проблемного dc

    Служба репликации DFS обнаружила ошибку в подключении к партнеру AD для группы репликации Domain System Volume.
     
    DNS-адрес партнера: AD.rxt.ru
     
    Доступные дополнительные сведения:
    WINS-адрес партнера: AD
    IP-адрес партнера: 192.168.2.6
     
    Служба периодически будет пытаться установить подключение.
     
    Дополнительные сведения:
    Ошибка: 1825 (Ошибка в пакете безопасности.)
    Идентификатор подключения: 33A1A3A9-F415-44A1-9778-27E96E16555B
    Идентификатор группы репликации: 534FCCFC-8104-41D0-9C6C-C9D692B97F08

    также там где хозяин операция  написано ошибка

    У основного  DC там он же,то есть все ок.


    • Изменено Otherkot 12 января 2018 г. 8:14
    12 января 2018 г. 8:08

Ответы

  • у меня все так и есть,но никто ничего не менял.Думаю причина в том,что их разлучили не 5 дней(в моем случае) но как грамотно их опять подружить мне не понятно

    у меня тоже во время НГ два ДЦ были разлучены на 10 дней из-за перенастройки VPN между ними. Просто вручную в оснастке "Сайты и Службы" запустил репликацию - всё заработало:

    12 января 2018 г. 8:49
  • Коллеги, по моему мнению, копать именно в сторону DNS смысла в данном случае нет. Сообщение об ошибке, которое в кривом переводе на русский звучит"Главное конечное имя неверно" (на самом деле, правильный перевод - "Имя целевого участника [безопасности] неверно") может иметь две причины.

    Первая возможная причина - имя целевого сервера (оно в случае репликации - это CNAME с именем, равным DSA GUID, в поддомене _msdsc)разрешается через DNS в IP другого сервера. Конечно, проверить этот факт стоит (командой nslookup 9ebdc9fb-8753-4f57-ae2f-61ac5f6c8b41._msdcs.rxt.ru). Но в описанной ситуации вряд ли произошло это - нет предпосылок.

    Скорее, тут проявляется вторая возможная причина ошибки - несоответствие долговременного ключа (на основе пароля УЗ сервера AD.rxt.ru), которым зашифрован билет службы для обращения к AD.rxt.ru (выданный на ADREPLICA01.rxt.ru)  ключу, который имеет у себя сам сервер AD.rxt.ru. Как это проверить, а с немалой вероятностью - и решить эту проблему, я написал в предыдущем сообщении.

      

    Слава России!



    13 января 2018 г. 8:52
  • Всем спасибо,тему можно закрывать.после включения реплики(вчера отключал на полдня) они друг друга увидели.Теперь все стадии проходят со статусом успешно.Возможно помог ответ:принудительно отреплицировать эти 2  DC
    13 января 2018 г. 12:07

Все ответы

  • по поводу настройки днс процитирую сам себя :)

    хорошим тоном считается назначать DNS вперехлест. то есть на первом кд ставите адрес DNS второго сервера и добавка "на себя", а на втором наоборот - первый и "на себя"

    (это для начала)
    • Изменено RAMzez_ 12 января 2018 г. 8:29
    12 января 2018 г. 8:28
  • по поводу настройки днс процитирую сам себя :)

    хорошим тоном считается назначать DNS вперехлест. то есть на первом кд ставите адрес DNS второго сервера и добавка "на себя", а на втором наоборот - первый и "на себя"

    (это для начала)

    Этот "хороший тон" был до 2003 года, когда в Windows Server 2003 поменяли процесс репликации и решили проблему "островов" (собственно, из-за чего перехлёст и требовался).

    Otherkot покажите ipconfig /all со всех контроллеров домена.
    WINS сервер Вам в сети вообще зачем? Им кто-то пользуется?
    Так же банально пропингуйте каждый контроллер домена.

    12 января 2018 г. 8:44
  • у меня все так и есть,но никто ничего не менял.Думаю причина в том,что их разлучили не 5 дней(в моем случае) но как грамотно их опять подружить мне не понятно
    12 января 2018 г. 8:44
  • у меня все так и есть,но никто ничего не менял.Думаю причина в том,что их разлучили не 5 дней(в моем случае) но как грамотно их опять подружить мне не понятно

    у меня тоже во время НГ два ДЦ были разлучены на 10 дней из-за перенастройки VPN между ними. Просто вручную в оснастке "Сайты и Службы" запустил репликацию - всё заработало:

    12 января 2018 г. 8:49
  • Попробуйте ping контроллеров (с одного на другой и обратно)

    Проверьте время на обоих контроллерах, возможно у них разница во времени

    Проверьте службу RPC 

    Контроллеры в одной подсети? 
    12 января 2018 г. 8:50
  • Попробуйте запустить реплику из cmd под учеткой админа

    repadmin /replicate DC1 DC2 "dc=domain,dc=com" 

    12 января 2018 г. 8:56
  • одна под сеть 192.168.2.0/24

    одно время

    причем ADreplica при команде

    w32tm /query /status

    пишет,что все ок и время синхронизации с основным AD

    12 января 2018 г. 10:00
  • Через nslookup оба контроллера определяются? 

    И про ping вы не уточнили. 

    Проверьте еще правила брандмауэра и статус служб относящихся к работе доменных служб.

    покажите вывод команды repadmin /replicate Имя_резервного_DC имя_основного"dc=domain,dc=com" 

    покажите вывод DCDIAG на проблемном контролере 

    12 января 2018 г. 10:16
  • Похоже, второй КД не имеет в своей копии базы AD правильный пароль первого КД и не в состоянии его среплицировать.

    Для решения проблемы можно заставить систему на втором КД  получить билет Kerberos на первом KD командами (из командной строки в режиме администратора):

    net stop kdc

    klist -li 3e7 purge

    После этого произведите репликацию (через AD Sites & Services, например) и проверьте факт её прохождения с помощью repadmin /showrepl

    Если репликация восстановилась, то для контроля опять запустите KDC (net start KDC), сбросьте кэш билетов системы (klist -li 3e7 purge) и повторите попытку репликации. Если попытка будет удачной - проблема решена.

    Репликация может и не восстановиться - например, если её реально не было не 5 дней, а существенно больше (3-6 месяцев, зависит от того, в какой версии ОС изначально был создан домен). Тогда вы увидите проблему в выдаче repadmin и вам придётся решать уже её.


    Слава России!



    • Изменено M.V.V. _ 12 января 2018 г. 13:54
    12 января 2018 г. 13:52
  • Этот "хороший тон" был до 2003 года, когда в Windows Server 2003 поменяли процесс репликации и решили проблему "островов" (собственно, из-за чего перехлёст и требовался).

    проблему то может и решили, вот только делать это приходится и в 2012r2 во избежание, как показывает практика ;)
    12 января 2018 г. 17:30
  • Этот "хороший тон" был до 2003 года, когда в Windows Server 2003 поменяли процесс репликации и решили проблему "островов" (собственно, из-за чего перехлёст и требовался).

    проблему то может и решили, вот только делать это приходится и в 2012r2 во избежание, как показывает практика ;)
    во избежании чего?
    12 января 2018 г. 17:53
  • проблему то может и решили, вот только делать это приходится и в 2012r2 во избежание, как показывает практика ;)

    во избежании чего?
    вот это прочтите до конца - поймете ;)
    12 января 2018 г. 18:15
  • И что? У ТС стоял только петлевой адрес. Если он пропишет не вперехлест - будет работать также без сбоев.

    Я не говорю, что вперехлест это не правильно. Это лишь рудимент. Вот будет у вас больше 2-3 контроллеров домена, что и как вы будете перехлестывать?! А так поставил себя на первое место - и работает, и не паришься кого вторым сделать.

    12 января 2018 г. 19:39
  • Коллеги, по моему мнению, копать именно в сторону DNS смысла в данном случае нет. Сообщение об ошибке, которое в кривом переводе на русский звучит"Главное конечное имя неверно" (на самом деле, правильный перевод - "Имя целевого участника [безопасности] неверно") может иметь две причины.

    Первая возможная причина - имя целевого сервера (оно в случае репликации - это CNAME с именем, равным DSA GUID, в поддомене _msdsc)разрешается через DNS в IP другого сервера. Конечно, проверить этот факт стоит (командой nslookup 9ebdc9fb-8753-4f57-ae2f-61ac5f6c8b41._msdcs.rxt.ru). Но в описанной ситуации вряд ли произошло это - нет предпосылок.

    Скорее, тут проявляется вторая возможная причина ошибки - несоответствие долговременного ключа (на основе пароля УЗ сервера AD.rxt.ru), которым зашифрован билет службы для обращения к AD.rxt.ru (выданный на ADREPLICA01.rxt.ru)  ключу, который имеет у себя сам сервер AD.rxt.ru. Как это проверить, а с немалой вероятностью - и решить эту проблему, я написал в предыдущем сообщении.

      

    Слава России!



    13 января 2018 г. 8:52
  • Всем спасибо,тему можно закрывать.после включения реплики(вчера отключал на полдня) они друг друга увидели.Теперь все стадии проходят со статусом успешно.Возможно помог ответ:принудительно отреплицировать эти 2  DC
    13 января 2018 г. 12:07
  • Всем спасибо,тему можно закрывать.после включения реплики(вчера отключал на полдня) они друг друга увидели.Теперь все стадии проходят со статусом успешно.Возможно помог ответ:принудительно отреплицировать эти 2  DC
    Так Вы отметьте правильный по Вашему мнению ответ и закройте тему =)) 
    16 января 2018 г. 7:33