none
Windows Seerver 2008 Kerberos RRS feed

  • Вопрос

  • Использую несколько серверов Windows Server 2008 SP2 под управлением VMware ESXi 5.1. Два сервера являются контроллерами домена. На всех серверах раз в день генерируются такие предупреждения:

    Код события 4

    Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера msk-nbk-office$. Использовалось конечное имя cifs/HQ-NBK-MNWORK-3.usem.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (USEM.LOCAL) отличен от домена клиента (USEM.LOCAL), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

    Код события 29

    Центр распространения ключей (KDC) не может найти подходящий сертификат для использования при регистрации смарт-карт или KDC-сертификат не может быть проверен. Регистрация смарт-карт не может работать правильно, если данная проблема не разрешена. Для исправления неполадки либо проверьте существующий сертификат KDC при помощи certutil.exe, либо запросите новый KDC-сертификат.

    Помогите пожалуйста решить данную проблему!

    22 февраля 2013 г. 2:43

Ответы

  • Если коротко: HQ-DC у Вас - источник содержимого SYSVOL (refernce DC), а на HQ-SDC это содержимое еще только нужно реплицировать (когда Вы его поднимали, этого по какой-то причине не произошло, а Вы это не проконтролировали).

    Т.е. на HQ-DC восстановление, если его производить, должно быть полномочным (установите Burflags в значение D4), на HQ-SDC - неполномочным (установите Burflags в значение D2). Подробности - по приведенной мной ссылке (там, если нужно, можно получить и русский перевод), либо http://support.microsoft.com/kb/290762

    На всякий случай, перед этими действиями скопируйте куда-нибудь содержимое SYSVOL каждого из DC.


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

    • Помечено в качестве ответа kirilee 4 марта 2013 г. 2:14
    25 февраля 2013 г. 20:50

Все ответы

  • Покажите вывод следующих команд

    setspn -L HQ-NBK-MNWORK-3

    nslookup HQ-NBK-MNWORK-3

    nslookup msk-nbk-office


    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 6:46
  • Microsoft Windows [Version 6.1.7601]
    (c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.

    C:\Users\kschemelev>setspn -L HQ-NBK-MNWORK-3
    Зарегистрирован ServicePrincipalNames для CN=HQ-NBK-MNWORK-3,OU=PC,DC=usem,DC=lo
    cal:
            RestrictedKrbHost/HQ-NBK-MNWORK-3
            HOST/HQ-NBK-MNWORK-3
            RestrictedKrbHost/HQ-NBK-MNWORK-3.usem.local
            HOST/HQ-NBK-MNWORK-3.usem.local

    C:\Users\kschemelev>

    Microsoft Windows [Version 6.1.7601]
    (c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.

    C:\Users\kschemelev>nslookup HQ-NBK-MNWORK-3
    ╤хЁтхЁ:  hq-dc.usem.local
    Address:  192.168.0.1

    ╚ь :     HQ-NBK-MNWORK-3.usem.local
    Address:  192.168.0.102


    C:\Users\kschemelev>nslookup msk-nbk-office
    ╤хЁтхЁ:  hq-dc.usem.local
    Address:  192.168.0.1

    ╚ь :     msk-nbk-office.usem.local
    Address:  192.168.0.102


    C:\Users\kschemelev>

    22 февраля 2013 г. 6:54
  • дежурный вопрос - со снапшотов КД не восстанавливались? про msk-nbk-office$ даже спрашивать пока не буду - не соответствуют хеши паролей на хосте и в базе AD: тикет для него зашифрован не тем паролем - он его не может расшифровать... смущает SPN, который использовался: покажите вывод команд setspn -L domain\msk-nbk-office и setspn -L domain\HQ-NBK-MNWORK-3 (в качестве domain укажите свой)
    22 февраля 2013 г. 7:03
    Отвечающий
  • У вас HQ-NBK-MNWORK-3 и msk-nbk-office разрешаются в один адрес (192.168.0.102). Для чего это?

    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 7:03
  • дежурный вопрос - со снапшотов КД не восстанавливались? про msk-nbk-office$ даже спрашивать пока не буду - не соответствуют хеши паролей на хосте и в базе AD: тикет для него зашифрован не тем паролем - он его не может расшифровать... смущает SPN, который использовался: покажите вывод команд setspn -L domain\msk-nbk-office и setspn -L domain\HQ-NBK-MNWORK-3 (в качестве domain укажите свой)

    КД со снэпшотов восстанавливал как-то пару раз, но давно! Компьютер msk-nbk-office вписал в домен пару дней назад.

    Вот то что просили:

    Microsoft Windows [Version 6.1.7601]
    (c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.

    C:\Users\kschemelev>setspn -L usem\msk-nbk-office
    Зарегистрирован ServicePrincipalNames для CN=MSK-NBK-OFFICE,OU=PC,DC=usem,DC=loc
    al:
            TERMSRV/MSK-NBK-OFFICE
            TERMSRV/msk-nbk-office.usem.local
            RestrictedKrbHost/MSK-NBK-OFFICE
            HOST/MSK-NBK-OFFICE
            RestrictedKrbHost/MSK-NBK-OFFICE.usem.local
            HOST/MSK-NBK-OFFICE.usem.local

    C:\Users\kschemelev>setspn -L usem\HQ-NBK-MNWORK-3
    Зарегистрирован ServicePrincipalNames для CN=HQ-NBK-MNWORK-3,OU=PC,DC=usem,DC=lo
    cal:
            RestrictedKrbHost/HQ-NBK-MNWORK-3
            HOST/HQ-NBK-MNWORK-3
            RestrictedKrbHost/HQ-NBK-MNWORK-3.usem.local
            HOST/HQ-NBK-MNWORK-3.usem.local

    C:\Users\kschemelev>

    22 февраля 2013 г. 7:11
  • У вас HQ-NBK-MNWORK-3 и msk-nbk-office разрешаются в один адрес (192.168.0.102). Для чего это?

    Microsoft Certified Do Nothing Expert

    Нет я полагаю, что это не совсем нормально!Давайте расскажу всю ситуацию:

    У нас много мобильных сотрудников, которые уезжают надолго с ноутбуками из офиса. В офисе два КД с двумя ДНС серверами и поднят ДХЦП. Я так понимю,  что по прибытию в офис им выдается уже другой адрес отличный от первоначального сопоставления с ДНС серверами. Вот и получают ся такие наложения, но как это исправить я не знаю!

    22 февраля 2013 г. 7:15
  • КД со снэпшотов восстанавливал как-то пару раз, но давно!
    Дальше можно не смотреть. Выбирайте любого из них с наиболее актуальными данными (на глаз), убивайте второго и вводите в строй новый. Без шуток - я серьёзно. Не дожидаясь перитонита.
    22 февраля 2013 г. 7:15
    Отвечающий
  •  Компьютер msk-nbk-office вписал в домен пару дней назад.
    Покажите вывод ipconfig /all c компьютера HQ-NBK-MNWORK-3.

    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 7:15
  • Если вы про КД, то HQ-SDC это тот домен который я полнял в качестве вторичного и он не имеет ролей FSMO. HQ-DC - это тот домен, который я работает и за счет него сейчас все пользователи авторизуются! НО именно его я и восстанавливал из бэкапа. Как быть? Если я вас правильно понял, то вы мне предлагаете грохнуть HQ-DC? А можно без этого обойтись?
    22 февраля 2013 г. 7:20
  • По конкретно вашему вопросу - смотрите актуальность записей в DNS. Поскольку с SPN у вас проблем не видно с двумя хостами - наиболее вероятно, что клиент по нужному имени приходит не к тому хосту (что возможно, поскольку в DNS у вас задублированы записи - скорее всего одна из них неактуальна, её нужно удалить и разобраться почему терминалка самостоятельно не смогла зарегистрироваться в DNS). В остальном - планируйте вывод одного из КД и повторный ввод.
    22 февраля 2013 г. 7:21
    Отвечающий
  • У нас много мобильных сотрудников, которые уезжают надолго с ноутбуками из офиса. В офисе два КД с двумя ДНС серверами и поднят ДХЦП. Я так понимю,  что по прибытию в офис им выдается уже другой адрес отличный от первоначального сопоставления с ДНС серверами. Вот и получаются такие наложения, но как это исправить я не знаю!
    Проверить на DHCP настройки динамической регистрации записей в DNS - раз, настроить Scavenging на DNS - два. В принципе уже шаг 1 способен решить многие проблемы.
    22 февраля 2013 г. 7:24
    Отвечающий
  • Т е нужно понизить роль КД HQ-DC до рядового сервера и снова его сделать КД? Я просто не могу понять как в моем случае избавиться от дублирования записей в ДНС?
    22 февраля 2013 г. 7:25
  • Если вы про КД, то HQ-SDC это тот домен который я полнял в качестве вторичного и он не имеет ролей FSMO. HQ-DC - это тот домен, который я работает и за счет него сейчас все пользователи авторизуются! НО именно его я и восстанавливал из бэкапа. Как быть? Если я вас правильно понял, то вы мне предлагаете грохнуть HQ-DC? А можно без этого обойтись?
    Правильно ли я понимаю, что у вас два домена, в каждом из которых один домен-контроллер? или у вас один домен с двумя контроллерами? Если это последний вариант, то обойтись нельзя. Ни в коем случае не восстанавливать со снапшотов или образов...
    22 февраля 2013 г. 7:26
    Отвечающий
  • У меня один домен с двумя контроллерами! Может мне просто грохнуть записи всех машинок в ДНС? А потом они автоматически создадуться!

    И еще - как тогда бэкапить и восстанавливать КД?

    22 февраля 2013 г. 7:38
  • Т.е. нужно понизить роль КД HQ-DC до рядового сервера и снова его сделать КД?
    Да, после этого забыть про снапшоты и бэкапить хотя бы встроенными средствами ОС в закрытую шару.
    Это не из-за проблем DNS, это превентивная мера от потенциально более широкого факапа. Про "USN Rollback" почитайте на досуге - объяснять долго, но если вы хотя бы раз обеспечили контроллеру возврат в прошлое - намного дешевле его сейчас переподнять пока у вас ещё нет бОльших проблем.
    22 февраля 2013 г. 7:41
    Отвечающий
  • Может мне просто грохнуть записи всех машинок в ДНС? А потом они автоматически создадутся!
    Можно и так, но без фанатизма только. Scavenging у вас настроен в DNS? и на сервере и в зонах?
    22 февраля 2013 г. 7:42
    Отвечающий
  • Scavenging у вас настроен в DNS? и на сервере и в зонах?
    А что это такое можно подробнее и как это посмотреть?
    22 февраля 2013 г. 7:47
  • Scavenging у вас настроен в DNS? и на сервере и в зонах?

    А что это такое можно подробнее и как это посмотреть?

    http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 8:02
  • КД со снэпшотов восстанавливал как-то пару раз, но давно!
    Дальше можно не смотреть. Выбирайте любого из них с наиболее актуальными данными (на глаз), убивайте второго и вводите в строй новый. Без шуток - я серьёзно. Не дожидаясь перитонита.

    Может, сначала выдачу dcdiag посмотрим?

    PS Если действительно репликация не идет из-за USN Rollback, то это - уже достаточная причина для того, чтобы в DNS (на другом КД) оставались неверные записи. Решение проблемы с репликацией (путем переподнятия КД) вполне может решить и проблему с DNS.


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


    • Изменено M.V.V. _ 22 февраля 2013 г. 8:11
    22 февраля 2013 г. 8:06
  • Может, сначала выдачу dcdiag посмотрим?
    Безусловно посмотрим в соседней теме.
    Вы готовы дать своему клиенту гарантию отсутствия проблем в будущем после снапшот-рекавери? Я когда провожу AD Review и в истории есть такие операции - не готов, слишком много подводных камней может вылезти. Поэтому позиция вполне себе однозначная и жёсткая - купировать сейчас.
    22 февраля 2013 г. 8:10
    Отвечающий
  • Scavenging у вас настроен в DNS? и на сервере и в зонах?

    А что это такое можно подробнее и как это посмотреть?


    http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

    Microsoft Certified Do Nothing Expert

    Я понял, а нужно ли ее включать или нет! У меня она выключена! И если нужно включать, то у меня же два ДНС и два КД , ее нужно включать на обоих?
    22 февраля 2013 г. 8:10
  • КД со снэпшотов восстанавливал как-то пару раз, но давно!
    Дальше можно не смотреть. Выбирайте любого из них с наиболее актуальными данными (на глаз), убивайте второго и вводите в строй новый. Без шуток - я серьёзно. Не дожидаясь перитонита.


    Может, сначала выдачу dcdiag посмотрим?

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

    А с какими ключаит будем смотреть? Что dcdiad завести?
    22 февраля 2013 г. 8:11
  • По поводу ошибки 4. Картина такова.

    Некий клиент хочет обратиться к некой сетевой папке \\HQ-NBK-MNWORK-3.usem.local\ShareName

    Клиент обращается к контроллеру домена и просит так называемый service ticket для аутентификации на HQ-NBK-MNWORK-3

    Контроллер домена определяет что служба HOST/HQ-NBK-MNWORK-3 работает от имени учетной записи CN=HQ-NBK-MNWORK-3,OU=PC,DC=usem,DC=local, формирует запрошенный service ticket и шифрует его при помощи хеша пароля учетной записи HQ-NBK-MNWORK-3$

    Клиент формирует DNS-запрос и ваш DNS-сервер разрешает имя HQ-NBK-MNWORK-3.usem.local в 192.168.0.102

    Клиент обращается к компьютеру с адресом 192.168.0.102, но попадает на msk-nbk-office, а не на HQ-NBK-MNWORK-3, как ожидалось.

    msk-nbk-office пытается расшифровать Service Ticket хешем своего пароля, но терпит фиаско, В этот момент и генерируется ошибка 4.

    У вас проблема в том, что есть две машины с одинаковыми IP. Тут и scavenging не поможет. Но настроить его все равно полезно, ссылка выше.

    Если адреса на всех пользовательских машинах получаются через DHCP, включите настройку Conflict Detection Attempts на сервере DHCP.

    Если же юзеры используют статические адреса, то могу только посочувствовать.


    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 8:11
  • Без ключей.


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

    22 февраля 2013 г. 8:12
  • PS Если действительно репликация не идет из-за USN Rollback, то это - уже достаточная причина для того, чтобы в DNS (на другом КД) оставались неверные записи

    C:\Users\kschemelev>nslookup HQ-NBK-MNWORK-3
    ╤хЁтхЁ:  hq-dc.usem.local
    Address:  192.168.0.1

    ╚ь :     HQ-NBK-MNWORK-3.usem.local
    Address:  192.168.0.102


    C:\Users\kschemelev>nslookup msk-nbk-office
    ╤хЁтхЁ:  hq-dc.usem.local
    Address:  192.168.0.1

    ╚ь :     msk-nbk-office.usem.local
    Address:  192.168.0.102

    Обе хостовые записи существуют на одном сервере DNS (192,168,0,1). При чем тут репликация DNS?


    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 8:15
  • И если нужно включать, то у меня же два ДНС и два КД , ее нужно включать на обоих?
    На одном - достаточно. Best practice вендора - минимум на двух: на случай если единственный сборщик мусора будет выведен или перестанет работать.
    22 февраля 2013 г. 8:17
    Отвечающий
  • Может, сначала выдачу dcdiag посмотрим?
    Безусловно посмотрим в соседней теме.
    Вы готовы дать своему клиенту гарантию отсутствия проблем в будущем после снапшот-рекавери? Я когда провожу AD Review и в истории есть такие операции - не готов, слишком много подводных камней может вылезти. Поэтому позиция вполне себе однозначная и жёсткая - купировать сейчас.

    Гарантию дает только страховой полис, а я ее дать не могу, но если со времени восстановления ничего страшного не случилось, то и за те несколько часов, которые требуются для диагностики, скорее всего, ничего не случится. Особенно если клиент не будет ничего менять за это время в AD.

    Времена Win2K без SP давно прошли, и получить недетектированный USN Rollback сейчас очень трудно (а в конфигурации с 2 КД, постоянно работающими в одном сетевом сегменте - практически невозможно), а детектированный всего лишь блокирует репликацию и работу сервера в качестве КД. Кстати, dcdiag поможет обнаружить, какой именно из КД надо будет понижать/повышать, потому что заблокирован, скорее всего, только один, даже если из снимка восстанавливались оба.


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



    • Изменено M.V.V. _ 22 февраля 2013 г. 8:24
    22 февраля 2013 г. 8:17
  • Клиент обращается к компьютеру с адресом 192.168.0.102, но попадает на msk-nbk-office, а не на HQ-NBK-MNWORK-3, как ожидалось.
    У вас проблема в том, что есть две машины с одинаковыми IP
    Дмитрий, выше автор всё уже конкретизировал - машина одна. Записи - две.
    22 февраля 2013 г. 8:18
    Отвечающий
  • Клиент обращается к компьютеру с адресом 192.168.0.102, но попадает на msk-nbk-office, а не на HQ-NBK-MNWORK-3, как ожидалось.
    У вас проблема в том, что есть две машины с одинаковыми IP

    Дмитрий, выше автор всё уже конкретизировал - машина одна. Записи - две.
    Эээ, выше - это где? В этом топике ничего подобного не было.

    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 8:23
  • Эээ, выше - это где? В этом топике ничего подобного не было.
    "У нас много мобильных сотрудников, которые уезжают надолго с ноутбуками из офиса. В офисе два КД с двумя ДНС серверами и поднят ДХЦП. Я так понимаю, что по прибытию в офис им выдается уже другой адрес отличный от первоначального сопоставления с ДНС серверами. Вот и получаются такие наложения"
    22 февраля 2013 г. 8:25
    Отвечающий
  • dcdiag не запускается так простоMicrosoft Windows [Version 6.1.7601]
    (c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.

    C:\Users\kschemelev>dcdiag

    Диагностика сервера каталогов

    Выполнение начальной настройки:
       Выполняется попытка поиска основного сервера...
       ***Ошибка: hq-nbk-cio не является сервером каталогов.  Следует указать
       /s:<Сервер  каталогов> или /n:<Контекст именования>, либо ничего не
       указывать, если  используется локальный компьютер.
       ОШИБКА. Не удалось найти основной сервер.

    C:\Users\kschemelev>

    22 февраля 2013 г. 8:27
  • ***Ошибка: hq-nbk-cio не является сервером каталогов
    На контроллерах.
    22 февраля 2013 г. 8:29
    Отвечающий
  • Best practice вендора - минимум на двух: на случай если единственный сборщик мусора будет выведен или перестанет работать.

    Т е. я его включаю на обоих ДНС и смотрю, что будет?

    22 февраля 2013 г. 8:29
  • Т е. я его включаю на обоих ДНС и смотрю, что будет?
    Сразу смотреть будет нечего - записи устареют, потом раз в неделю будет запускаться сборщик мусора который их удалит и т.д. Вопрос в другом - как ваш DHCP регистрирует записи в DNS и под какой учётной записью?
    22 февраля 2013 г. 8:31
    Отвечающий
  • включите настройку Conflict Detection Attempts

    Нужно ли ее на самом деле включать и где в ДХЦП она включается?
    22 февраля 2013 г. 8:34
  • Эээ, выше - это где? В этом топике ничего подобного не было.

    "У нас много мобильных сотрудников, которые уезжают надолго с ноутбуками из офиса. В офисе два КД с двумя ДНС серверами и поднят ДХЦП. Я так понимаю, что по прибытию в офис им выдается уже другой адрес отличный от первоначального сопоставления с ДНС серверами. Вот и получаются такие наложения"

    Это только предположение. Причем я не особо понял, что имел в виду автор. Если речь идет о том, что для одной и той же машины существует две разные ДНС-записи (старая и новая), то это не подтверждается выводом nslookup. В выводе только одна запись что для HQ-NBK-MNWORK-3, что для msk-nbk-office.

    Если есть две записи test1 A 169.12.13.14 и test1 A 169.12.13.15, то nslookup test1 выдал бы два результата.


    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 8:39
  • Вот данные dc diag с HQ-DC

    Microsoft Windows [Версия 6.0.6002]
    (C) Корпорация Майкрософт, 2006. Все права защищены.

    C:\Users\kschemelev>dcdiag

    Диагностика сервера каталогов

    Выполнение начальной настройки:
       Выполняется попытка поиска основного сервера...
       Основной сервер = hq-dc
       * Идентифицирован лес AD.
       Сбор начальных данных завершен.

    Выполнение обязательных начальных проверок

       Сервер проверки: Default-First-Site\HQ-DC
          Запуск проверки: Connectivity
             ......................... HQ-DC - пройдена проверка Connectivity

    Выполнение основных проверок

       Сервер проверки: Default-First-Site\HQ-DC
          Запуск проверки: Advertising
             ......................... HQ-DC - пройдена проверка Advertising
          Запуск проверки: FrsEvent
             ......................... HQ-DC - пройдена проверка FrsEvent
          Запуск проверки: DFSREvent
             ......................... HQ-DC - пройдена проверка DFSREvent
          Запуск проверки: SysVolCheck
             ......................... HQ-DC - пройдена проверка SysVolCheck
          Запуск проверки: KccEvent
             ......................... HQ-DC - пройдена проверка KccEvent
          Запуск проверки: KnowsOfRoleHolders
             ......................... HQ-DC - пройдена проверка KnowsOfRoleHolders
          Запуск проверки: MachineAccount
             ......................... HQ-DC - пройдена проверка MachineAccount
          Запуск проверки: NCSecDesc
             Ошибка - NT AUTHORITY\КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ не имеет
                Replicating Directory Changes In Filtered Set
             прав доступа для контекста именования:
             DC=ForestDnsZones,DC=usem,DC=local
             Ошибка - NT AUTHORITY\КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ не имеет
                Replicating Directory Changes In Filtered Set
             прав доступа для контекста именования:
             DC=DomainDnsZones,DC=usem,DC=local
             ......................... HQ-DC - не пройдена проверка NCSecDesc
          Запуск проверки: NetLogons
             [HQ-DC] В учетных данных пользователя отсутствует разрешение на
             выполнение данной операции.
             Учетная запись, используемая для этой проверки, должна иметь права на
             вход в сеть
             для домена данного компьютера.
             ......................... HQ-DC - не пройдена проверка NetLogons
          Запуск проверки: ObjectsReplicated
             ......................... HQ-DC - пройдена проверка ObjectsReplicated
          Запуск проверки: Replications
             [Проверка репликации,HQ-DC] Сбой функции DsReplicaGetInfo(PENDING_OPS,
             NULL), ошибка 0x2105 "Доступ к репликации отвергнут."
             ......................... HQ-DC - не пройдена проверка Replications
          Запуск проверки: RidManager
             ......................... HQ-DC - пройдена проверка RidManager
          Запуск проверки: Services
                Не удалось открыть службу NTDS в HQ-DC, ошибка 0x5
                "Отказано в доступе."
             ......................... HQ-DC - не пройдена проверка Services
          Запуск проверки: SystemLog
             ......................... HQ-DC - пройдена проверка SystemLog
          Запуск проверки: VerifyReferences
             ......................... HQ-DC - пройдена проверка VerifyReferences


       Выполнение проверок разделов на: ForestDnsZones
          Запуск проверки: CheckSDRefDom
             ......................... ForestDnsZones - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... ForestDnsZones - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: DomainDnsZones
          Запуск проверки: CheckSDRefDom
             ......................... DomainDnsZones - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... DomainDnsZones - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: Schema
          Запуск проверки: CheckSDRefDom
             ......................... Schema - пройдена проверка CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... Schema - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: Configuration
          Запуск проверки: CheckSDRefDom
             ......................... Configuration - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... Configuration - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: usem
          Запуск проверки: CheckSDRefDom
             ......................... usem - пройдена проверка CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... usem - пройдена проверка CrossRefValidation

       Выполнение проверок предприятия на: usem.local
          Запуск проверки: LocatorCheck
             ......................... usem.local - пройдена проверка LocatorCheck
          Запуск проверки: Intersite
             ......................... usem.local - пройдена проверка Intersite

    C:\Users\kschemelev>

    И с HQ-SDC

    Microsoft Windows [Версия 6.0.6002]
    (C) Корпорация Майкрософт, 2006. Все права защищены.

    C:\Users\kschemelev>dcdiag

    Диагностика сервера каталогов

    Выполнение начальной настройки:
       Выполняется попытка поиска основного сервера...
       Основной сервер = hq-sdc
       * Идентифицирован лес AD.
       Сбор начальных данных завершен.

    Выполнение обязательных начальных проверок

       Сервер проверки: Default-First-Site\HQ-SDC
          Запуск проверки: Connectivity
             ......................... HQ-SDC - пройдена проверка Connectivity

    Выполнение основных проверок

       Сервер проверки: Default-First-Site\HQ-SDC
          Запуск проверки: Advertising
             Внимание: DsGetDcName вернул сведения для \\hq-dc.usem.local при
             попытке получения доступа к HQ-SDC.
             СЕРВЕР НЕ ОТВЕЧАЕТ или НЕ СЧИТАЕТСЯ ПРИЕМЛЕМЫМ.
             ......................... HQ-SDC - не пройдена проверка Advertising
          Запуск проверки: FrsEvent
             За последние 24 часа после предоставления SYSVOL в общий доступ
             зафиксированы предупреждения или сообщения  об ошибках.  Сбои при
             репликации SYSVOL могут стать причиной проблем групповой политики.
             ......................... HQ-SDC - пройдена проверка FrsEvent
          Запуск проверки: DFSREvent
             ......................... HQ-SDC - пройдена проверка DFSREvent
          Запуск проверки: SysVolCheck
             ......................... HQ-SDC - пройдена проверка SysVolCheck
          Запуск проверки: KccEvent
             ......................... HQ-SDC - пройдена проверка KccEvent
          Запуск проверки: KnowsOfRoleHolders
             ......................... HQ-SDC - пройдена проверка
             KnowsOfRoleHolders
          Запуск проверки: MachineAccount
             ......................... HQ-SDC - пройдена проверка MachineAccount
          Запуск проверки: NCSecDesc
             Ошибка - NT AUTHORITY\КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ не имеет
                Replicating Directory Changes In Filtered Set
             прав доступа для контекста именования:
             DC=ForestDnsZones,DC=usem,DC=local
             Ошибка - NT AUTHORITY\КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ не имеет
                Replicating Directory Changes In Filtered Set
             прав доступа для контекста именования:
             DC=DomainDnsZones,DC=usem,DC=local
             ......................... HQ-SDC - не пройдена проверка NCSecDesc
          Запуск проверки: NetLogons
             Не удается подключиться к общему ресурсу NETLOGON. (\\HQ-SDC\netlogon)
             [HQ-SDC] Сбой операции net use или LsaPolicy с ошибкой 67,
             Не найдено сетевое имя..
             ......................... HQ-SDC - не пройдена проверка NetLogons
          Запуск проверки: ObjectsReplicated
             ......................... HQ-SDC - пройдена проверка ObjectsReplicated
          Запуск проверки: Replications
             [Проверка репликации,HQ-SDC] Сбой функции
             DsReplicaGetInfo(PENDING_OPS, NULL), ошибка 0x2105
             "Доступ к репликации отвергнут."
             ......................... HQ-SDC - не пройдена проверка Replications
          Запуск проверки: RidManager
             ......................... HQ-SDC - пройдена проверка RidManager
          Запуск проверки: Services
                Не удалось открыть службу NTDS в HQ-SDC, ошибка 0x5
                "Отказано в доступе."
             ......................... HQ-SDC - не пройдена проверка Services
          Запуск проверки: SystemLog
             ......................... HQ-SDC - пройдена проверка SystemLog
          Запуск проверки: VerifyReferences
             ......................... HQ-SDC - пройдена проверка VerifyReferences


       Выполнение проверок разделов на: ForestDnsZones
          Запуск проверки: CheckSDRefDom
             ......................... ForestDnsZones - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... ForestDnsZones - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: DomainDnsZones
          Запуск проверки: CheckSDRefDom
             ......................... DomainDnsZones - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... DomainDnsZones - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: Schema
          Запуск проверки: CheckSDRefDom
             ......................... Schema - пройдена проверка CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... Schema - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: Configuration
          Запуск проверки: CheckSDRefDom
             ......................... Configuration - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... Configuration - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: usem
          Запуск проверки: CheckSDRefDom
             ......................... usem - пройдена проверка CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... usem - пройдена проверка CrossRefValidation

       Выполнение проверок предприятия на: usem.local
          Запуск проверки: LocatorCheck
             ......................... usem.local - пройдена проверка LocatorCheck
          Запуск проверки: Intersite
             ......................... usem.local - пройдена проверка Intersite

    C:\Users\kschemelev>

    22 февраля 2013 г. 8:40
  • включите настройку Conflict Detection Attempts

    Нужно ли ее на самом деле включать и где в ДХЦП она включается?

    http://technet.microsoft.com/en-us/library/cc737924%28v=ws.10%29.aspx

    Хуже точно не будет. Только не ставьте ее значение больше 2, это не рекомендуется.


    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 8:41
  • Т е. я его включаю на обоих ДНС и смотрю, что будет?

    Сразу смотреть будет нечего - записи устареют, потом раз в неделю будет запускаться сборщик мусора который их удалит и т.д. Вопрос в другом - как ваш DHCP регистрирует записи в DNS и под какой учётной записью?

    У меня тогда еще один вопрос должна ли стоять галочка в свойствах днс сервера на закладке дополнительно "Дополнительнвй службы BIND"?

    Просто у меня она не стоит.

    22 февраля 2013 г. 8:44
  • должна ли стоять галочка в свойствах днс сервера на закладке дополнительно "Дополнительнвй службы BIND"?
    Просто у меня она не стоит.
    нет
    22 февраля 2013 г. 8:45
    Отвечающий
  • Вот данные dc diag с HQ-DC

    Мдаа, тут уже не до невинных проблем с DHCP

    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 8:46
  • Вот данные dc diag с HQ-DC

    Мдаа, тут уже не до невинных проблем с DHCP

    Microsoft Certified Do Nothing Expert

    Что делать то нужно?
    22 февраля 2013 г. 9:07
  • Что делать то нужно?

    Выполнять понижение HQ-SDC, который вы восстанавливали из бекапа до рядового сервера. при этом у вас остается бодрый живой HQ-DC, поднимете ему рядышком под боком еще один контроллер для обеспечения минимальной отказоустойчивости сервисов- выше Кирилл вам советовал это. И все будет как раньше.
    22 февраля 2013 г. 9:17
    Отвечающий
  • Что делать то нужно?

    Вообще рекомендация уже дана. Избавляйтесь от одного из контроллеров и поднимайте его заново. Есть подозрение на USN Rollback. Но лучше подождите пока остальные коллеги вернутся в эту или соседнюю вашу тему, нужно определить какой из контроллеров оставлять. Я пока воздержусь от инструкций, у меня маловато опыта в восстановлении репликации.

    Пока что начните читать статью http://support.microsoft.com/kb/216498/ru


    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 9:18
  • Не вижу результатов некоторых тестов из-за нехватки прав доступа. Повторите, пожалуйста, запуск dcdiag из командной строки в режиме администратора.

    PS Предварительный вывод: USN Rollback обнаружен и работа в качестве КД вместе с репликацией AD заблокированы на HQ-SDC. Понижать/повышать, скорее всего, нужно будет его. Но хотелось бы увидеть результаты всех тестов.


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

    22 февраля 2013 г. 9:19
  • Что делать то нужно?
    Лечить. В вашем случае ампутировать придётся HQ-SDC, убеждаться что следов его не осталось и уже после - отращивать заново.
    22 февраля 2013 г. 9:19
    Отвечающий
  • Выполнять понижение HQ-SDC, который вы восстанавливали из бекапа до рядового сервера... выше Кирилл вам советовал это
    Дим, я уже в сторонке покуривая наблюдаю :)
    22 февраля 2013 г. 9:20
    Отвечающий
  • Что делать то нужно?

    Написано здесь: http://support.microsoft.com/kb/875495

    Насчет проблем с DNS - высока вероятность, что после решения основной проблемы они уйдут сами (отсутствие репликации между двумя серверами DNS - вполне достаточная причина для их возникновения), так что пока можно ими не заморачиваться.


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


    • Изменено M.V.V. _ 22 февраля 2013 г. 9:24
    22 февраля 2013 г. 9:23
  • По поводу контроллеров там ситуация была такая

    Существовал DC u-server2 который был FSMO и который умер вторичным КД был HQ-DC. Выключил U-Server2 т к во время репликации у меня переставали работать оба КД. Восстановил из бэкапа HQ-DC, предварительно вообще отключив u-server2. Я перенес на HQ-DC все роли FSMO вручную и удалил u-server2 и все записи о нем из ДНС. Затем вторичным КД поднял HQ-SDC и настроил репликации. А после вы уже все знаете. Начались вышеобсуждаемые проблем с работой в случае отключения HQ-DC.

    22 февраля 2013 г. 9:28
  • Забыл добавить, что HQ-SDC я поднимал на ЧИСТОЙ машине. Зачем убирать именно его я не понимаю!
    22 февраля 2013 г. 9:39
  • Вот диагностика с HQ-DC с правами админа

    Microsoft Windows [Версия 6.0.6002]
    (C) Корпорация Майкрософт, 2006. Все права защищены.

    C:\Windows\system32>dcdiag

    Диагностика сервера каталогов

    Выполнение начальной настройки:
       Выполняется попытка поиска основного сервера...
       Основной сервер = hq-dc
       * Идентифицирован лес AD.
       Сбор начальных данных завершен.

    Выполнение обязательных начальных проверок

       Сервер проверки: Default-First-Site\HQ-DC
          Запуск проверки: Connectivity
             ......................... HQ-DC - пройдена проверка Connectivity

    Выполнение основных проверок

       Сервер проверки: Default-First-Site\HQ-DC
          Запуск проверки: Advertising
             ......................... HQ-DC - пройдена проверка Advertising
          Запуск проверки: FrsEvent
             ......................... HQ-DC - пройдена проверка FrsEvent
          Запуск проверки: DFSREvent
             ......................... HQ-DC - пройдена проверка DFSREvent
          Запуск проверки: SysVolCheck
             ......................... HQ-DC - пройдена проверка SysVolCheck
          Запуск проверки: KccEvent
             ......................... HQ-DC - пройдена проверка KccEvent
          Запуск проверки: KnowsOfRoleHolders
             ......................... HQ-DC - пройдена проверка KnowsOfRoleHolders
          Запуск проверки: MachineAccount
             ......................... HQ-DC - пройдена проверка MachineAccount
          Запуск проверки: NCSecDesc
             Ошибка - NT AUTHORITY\КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ не имеет
                Replicating Directory Changes In Filtered Set
             прав доступа для контекста именования:
             DC=ForestDnsZones,DC=usem,DC=local
             Ошибка - NT AUTHORITY\КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ не имеет
                Replicating Directory Changes In Filtered Set
             прав доступа для контекста именования:
             DC=DomainDnsZones,DC=usem,DC=local
             ......................... HQ-DC - не пройдена проверка NCSecDesc
          Запуск проверки: NetLogons
             ......................... HQ-DC - пройдена проверка NetLogons
          Запуск проверки: ObjectsReplicated
             ......................... HQ-DC - пройдена проверка ObjectsReplicated
          Запуск проверки: Replications
             ......................... HQ-DC - пройдена проверка Replications
          Запуск проверки: RidManager
             ......................... HQ-DC - пройдена проверка RidManager
          Запуск проверки: Services
             ......................... HQ-DC - пройдена проверка Services
          Запуск проверки: SystemLog
             ......................... HQ-DC - пройдена проверка SystemLog
          Запуск проверки: VerifyReferences
             ......................... HQ-DC - пройдена проверка VerifyReferences


       Выполнение проверок разделов на: ForestDnsZones
          Запуск проверки: CheckSDRefDom
             ......................... ForestDnsZones - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... ForestDnsZones - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: DomainDnsZones
          Запуск проверки: CheckSDRefDom
             ......................... DomainDnsZones - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... DomainDnsZones - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: Schema
          Запуск проверки: CheckSDRefDom
             ......................... Schema - пройдена проверка CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... Schema - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: Configuration
          Запуск проверки: CheckSDRefDom
             ......................... Configuration - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... Configuration - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: usem
          Запуск проверки: CheckSDRefDom
             ......................... usem - пройдена проверка CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... usem - пройдена проверка CrossRefValidation

       Выполнение проверок предприятия на: usem.local
          Запуск проверки: LocatorCheck
             ......................... usem.local - пройдена проверка LocatorCheck
          Запуск проверки: Intersite
             ......................... usem.local - пройдена проверка Intersite

    C:\Windows\system32>

    22 февраля 2013 г. 9:42
  • Забыл добавить, что HQ-SDC я поднимал на ЧИСТОЙ машине. Зачем убирать именно его я не понимаю!
    Он у вас неработоспособен на данный момент в полной мере. Первый - да, второй - нет. Вкупе с обстоятельствами, которые мы выяснили - его дешевле переделать сейчас с нуля, чтобы гарантировать нормальную работу.
    22 февраля 2013 г. 9:44
    Отвечающий
  • Забыл добавить, что HQ-SDC я поднимал на ЧИСТОЙ машине. Зачем убирать именно его я не понимаю!

    Результат dcdiag с него покажите - разберемся.

    PS USN Rollback случается не только при восстановлении из образа, но и, например, при некоторых сбоях RAID-контроллера, к которому подключен диск, содержащий ОС.


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



    • Изменено M.V.V. _ 22 февраля 2013 г. 9:47
    22 февраля 2013 г. 9:44
  • А вот с HQ-SDC

    Microsoft Windows [Версия 6.0.6002]
    (C) Корпорация Майкрософт, 2006. Все права защищены.

    C:\Windows\system32>dcdiag

    Диагностика сервера каталогов

    Выполнение начальной настройки:
       Выполняется попытка поиска основного сервера...
       Основной сервер = hq-sdc
       * Идентифицирован лес AD.
       Сбор начальных данных завершен.

    Выполнение обязательных начальных проверок

       Сервер проверки: Default-First-Site\HQ-SDC
          Запуск проверки: Connectivity
             ......................... HQ-SDC - пройдена проверка Connectivity

    Выполнение основных проверок

       Сервер проверки: Default-First-Site\HQ-SDC
          Запуск проверки: Advertising
             Внимание: DsGetDcName вернул сведения для \\hq-dc.usem.local при
             попытке получения доступа к HQ-SDC.
             СЕРВЕР НЕ ОТВЕЧАЕТ или НЕ СЧИТАЕТСЯ ПРИЕМЛЕМЫМ.
             ......................... HQ-SDC - не пройдена проверка Advertising
          Запуск проверки: FrsEvent
             За последние 24 часа после предоставления SYSVOL в общий доступ
             зафиксированы предупреждения или сообщения  об ошибках.  Сбои при
             репликации SYSVOL могут стать причиной проблем групповой политики.
             ......................... HQ-SDC - пройдена проверка FrsEvent
          Запуск проверки: DFSREvent
             ......................... HQ-SDC - пройдена проверка DFSREvent
          Запуск проверки: SysVolCheck
             ......................... HQ-SDC - пройдена проверка SysVolCheck
          Запуск проверки: KccEvent
             ......................... HQ-SDC - пройдена проверка KccEvent
          Запуск проверки: KnowsOfRoleHolders
             ......................... HQ-SDC - пройдена проверка
             KnowsOfRoleHolders
          Запуск проверки: MachineAccount
             ......................... HQ-SDC - пройдена проверка MachineAccount
          Запуск проверки: NCSecDesc
             Ошибка - NT AUTHORITY\КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ не имеет
                Replicating Directory Changes In Filtered Set
             прав доступа для контекста именования:
             DC=ForestDnsZones,DC=usem,DC=local
             Ошибка - NT AUTHORITY\КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ не имеет
                Replicating Directory Changes In Filtered Set
             прав доступа для контекста именования:
             DC=DomainDnsZones,DC=usem,DC=local
             ......................... HQ-SDC - не пройдена проверка NCSecDesc
          Запуск проверки: NetLogons
             Не удается подключиться к общему ресурсу NETLOGON. (\\HQ-SDC\netlogon)
             [HQ-SDC] Сбой операции net use или LsaPolicy с ошибкой 67,
             Не найдено сетевое имя..
             ......................... HQ-SDC - не пройдена проверка NetLogons
          Запуск проверки: ObjectsReplicated
             ......................... HQ-SDC - пройдена проверка ObjectsReplicated
          Запуск проверки: Replications
             ......................... HQ-SDC - пройдена проверка Replications
          Запуск проверки: RidManager
             ......................... HQ-SDC - пройдена проверка RidManager
          Запуск проверки: Services
             ......................... HQ-SDC - пройдена проверка Services
          Запуск проверки: SystemLog
             ......................... HQ-SDC - пройдена проверка SystemLog
          Запуск проверки: VerifyReferences
             ......................... HQ-SDC - пройдена проверка VerifyReferences


       Выполнение проверок разделов на: ForestDnsZones
          Запуск проверки: CheckSDRefDom
             ......................... ForestDnsZones - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... ForestDnsZones - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: DomainDnsZones
          Запуск проверки: CheckSDRefDom
             ......................... DomainDnsZones - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... DomainDnsZones - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: Schema
          Запуск проверки: CheckSDRefDom
             ......................... Schema - пройдена проверка CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... Schema - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: Configuration
          Запуск проверки: CheckSDRefDom
             ......................... Configuration - пройдена проверка
             CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... Configuration - пройдена проверка
             CrossRefValidation

       Выполнение проверок разделов на: usem
          Запуск проверки: CheckSDRefDom
             ......................... usem - пройдена проверка CheckSDRefDom
          Запуск проверки: CrossRefValidation
             ......................... usem - пройдена проверка CrossRefValidation

       Выполнение проверок предприятия на: usem.local
          Запуск проверки: LocatorCheck
             ......................... usem.local - пройдена проверка LocatorCheck
          Запуск проверки: Intersite
             ......................... usem.local - пройдена проверка Intersite

    C:\Windows\system32>

    22 февраля 2013 г. 9:45
  • Репликацию между КД проверяю так:

    CHCP 1251
    repadmin /replsum  hq-dc  >> #replsum.txt
    repadmin /replsum  hq-sdc  >> #replsum.txt

    Вот результат:

    Время запуска сводки по репликации: 2013-02-22 15:47:13



    Начат сбор данных для сводки по репликации, подождите:

      ....





    Исходный DSA        наиб. дельта     сбоев/всего %%   ошибка

     HQ-SDC                    01m:00s    0 /   5    0  





    Конечный DSA        наиб. дельта      сбои/всего %%   ошибка

     HQ-DC                     01m:00s    0 /   5    0  





    Время запуска сводки по репликации: 2013-02-22 15:47:13



    Начат сбор данных для сводки по репликации, подождите:

      ....





    Исходный DSA        наиб. дельта     сбоев/всего %%   ошибка

     HQ-DC                     11m:19s    0 /   5    0  





    Конечный DSA        наиб. дельта      сбои/всего %%   ошибка

     HQ-SDC                    11m:19s    0 /   5    0  




    22 февраля 2013 г. 9:49
  • Так, никаких следов USN Rollback не наблюдается. Судя по тому, как Вы описывали восстановления с образа, чаша сия, может быть, Вас минула и понижать/повышать КД не придется.

    Сейчас у Вас проблема со службой репликации файлов, которая препятствует HD-SDC работать в качстве КД.

    Чтобы понять, в чем проблема, перезапустите на каждом КД службу репликации файлов (Ntfrs) и посмотрите в журнале событий, какие после этого появляются предупреждения и ошибки.

    Чтобы понять, в чем проблема, перезапустите на каждом КД службу репликации файлов (Ntfrs) и посмотрите в журнале событий, какие после этого появляются предупреждения и ошибки.

    Подозреваю, что на HD-SDC есть событие 13514, и, скорее всего - 13508 (это означает, что SYSVOL еще ни разу не был полностью реплицирован с рабочего КД, а потому данный сервер в качестве КД работать не может).

    На HD-DC должна быть ошибка. Наиболее вероятно - с кодом 13561 (состояние JRNL_WRAP_ERROR), но может быть что-то еще.

    PS Если проблема в этом, то проблемы с Kerberos/DNS с ней не связаны, с ними надо будет разбираться дальше.


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



    • Изменено M.V.V. _ 22 февраля 2013 г. 10:03
    22 февраля 2013 г. 9:55
  • Так, никаких следов USN Rollback не наблюдается.
    Операция вывода-ввода делается в течение часа максимум со всеми приготовлениями - тем более из текущего раскоряченного состояния. Смысл рисковать?
    22 февраля 2013 г. 10:06
    Отвечающий
  • Так, никаких следов USN Rollback не наблюдается.

    Операция вывода-ввода делается в течение часа максимум со всеми приготовлениями - тем более из текущего раскоряченного состояния. Смысл рисковать?

    Помнится, кто-то когда-то сказал мне: "Никогда никого не спешите понижать" :)

    Автор поправился, что он делал восстановление HD-DC еще в тот момент, когда HD-SDC не существовало.

    Конечно всегда есть подозрение, что автор что-то не договаривает или что-то забыл (Все лгут!).

    /troll mode off :)


    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 10:21
  • Это не тот случай, здесь имеет смысл сэкономить телодвижения, а не заниматься спортом с бригадой реаниматологов.

    Тогда была несколько другая ситуация, насколько я припоминаю.

    Каждый для себя, конечно, решает- можно за час все сделать и вымыть руки, а можно никуда не торопиться, и расковыривать дальше, набивая пару сотен постов. Вопрос времени и желания, имхо.

    22 февраля 2013 г. 10:32
    Отвечающий
  • Чем рисковать?

    USN Rollback сейчас не детектируется (нет ни одного признака - ни запрета репликации, ни приостановленной службы NetLogon). А если верить автору вопроса, рассогласования в AD между HD-DC и HD-SDC возникнуть не могло: в момент поднятия HD-SDC единственная копия AD была на HD-DC, а после этого никакой КД из образа не восстанавливался.


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

    22 февраля 2013 г. 10:34
  • в момент поднятия HD-SDC единственная копия AD была на HD-DC, а после этого никакой КД из образа не восстанавливался
    вы уверены? :) "все лгут" (c)
    Ну или как минимум - имеют право забыть или не учесть. Задача хорошего технического консультанта - постараться предотвратить.
    "Никогда никого не спешите понижать" - Дмитрий, превосходно, 5 баллов за память :) но в данном случае действительно риск от предлагаемой операции минимален, зато гарантирует отсутствие лишних сюрпризов.
    22 февраля 2013 г. 10:46
    Отвечающий
  • Может быть моя позиция неэтична по отношению к тредстартеру, но я хочу подсмотреть через плечо новые методики диагностики, а metadata cleanup уже неинтересно.

    Microsoft Certified Do Nothing Expert

    22 февраля 2013 г. 10:52
  • Может быть моя позиция неэтична по отношению к тредстартеру, но я хочу подсмотреть через плечо новые методики диагностики, а metadata cleanup уже неинтересно
    Если условно забыть про USN Rollback, то текущая ситуация разрешается в несколько минут. Вопрос сводится к тривиальному траблшутингу FRS/DFS-R и поднятию SysVol'а, после чего ситуация нормализуется. Но если вспомнить обратно, то я бы затратил лишние полчаса на переподнятие.
    22 февраля 2013 г. 10:56
    Отвечающий
  • Так, никаких следов USN Rollback не наблюдается. Судя по тому, как Вы описывали восстановления с образа, чаша сия, может быть, Вас минула и понижать/повышать КД не придется.

    Сейчас у Вас проблема со службой репликации файлов, которая препятствует HD-SDC работать в качстве КД.

    Чтобы понять, в чем проблема, перезапустите на каждом КД службу репликации файлов (Ntfrs) и посмотрите в журнале событий, какие после этого появляются предупреждения и ошибки.

    Чтобы понять, в чем проблема, перезапустите на каждом КД службу репликации файлов (Ntfrs) и посмотрите в журнале событий, какие после этого появляются предупреждения и ошибки.

    Подозреваю, что на HD-SDC есть событие 13514, и, скорее всего - 13508 (это означает, что SYSVOL еще ни разу не был полностью реплицирован с рабочего КД, а потому данный сервер в качестве КД работать не может).

    На HD-DC должна быть ошибка. Наиболее вероятно - с кодом 13561 (состояние JRNL_WRAP_ERROR), но может быть что-то еще.

    PS Если проблема в этом, то проблемы с Kerberos/DNS с ней не связаны, с ними надо будет разбираться дальше.


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



    Вы правы! Есть ошибка 13508.

    Есть еще ошибка ДНС 4013 и 4515. А в журнале АД 2886. Это на HQ-SDC ЧИСТЫЙ КД).

    На HQ-DC те же ошибки + 2887

    24 февраля 2013 г. 11:27
  • Может быть моя позиция неэтична по отношению к тредстартеру, но я хочу подсмотреть через плечо новые методики диагностики, а metadata cleanup уже неинтересно

    Если условно забыть про USN Rollback, то текущая ситуация разрешается в несколько минут. Вопрос сводится к тривиальному траблшутингу FRS/DFS-R и поднятию SysVol'а, после чего ситуация нормализуется. Но если вспомнить обратно, то я бы затратил лишние полчаса на переподнятие.
    Если это проблема нескольких минут, то предлагаю по возможности помочь мне удаленно!
    24 февраля 2013 г. 11:28
  • По восстановлению репликации FRS общее руководство есть в MS KB Оно применимо и к Wn2K8 (с поправкой, что все  программы нужно запускать в режиме администратора, либо отключить UAC), если используется репликация FRS (уровень работы домена - Win2K, Win2K3 либо после более высокие, но поcле перехода на них миграция на DFSR не производилась). У Вас, судя по всему, как раз используется FRS


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

    24 февраля 2013 г. 12:19
  • По восстановлению репликации FRS общее руководство есть в MS KB Оно применимо и к Wn2K8 (с поправкой, что все  программы нужно запускать в режиме администратора, либо отключить UAC), если используется репликация FRS (уровень работы домена - Win2K, Win2K3 либо после более высокие, но поcле перехода на них миграция на DFSR не производилась). У Вас, судя по всему, как раз используется FRS


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

    Из  статьи не понятно какие конкрnетно нужно выполнять действия для решения моей проблемы?
    25 февраля 2013 г. 5:24
  • Из статьи не понятно какие конкретно нужно выполнять действия для решения моей проблемы?
    может всё-же предпринять немного усилий? Ключевые слова в статье - D2 и D4. Здесь точно такие же люди как и вы - у всех своя работа есть и личные дела. Удалённо - возможно, но по срокам сложно сказать - квота альтруизма пока исчерпана, вероятно - ближе к выходным что-нибудь выйдет.
    25 февраля 2013 г. 6:09
    Отвечающий
  • Можно и в выходные! Но если есть возможность, то на неделе, если кто сможет помогите разобраться!
    25 февраля 2013 г. 7:03
  • В вашем случае есть всего два контроллера, поэтому достаточно выполнить лишь Nonautoritative Restore of an FRS-Replicated SYSVOL Folder

    Nonauthoritave проще чем Authoritative, в нем меньше шагов. Прочитайте теорию в статье, которую дал коллега M.V.V._, в ней подробно описываются все шаги авторитетного восстановления с пояснениями. Не ленитесь ). Если будут конкретные вопросы - задавайте.



    Microsoft Certified Do Nothing Expert

    25 февраля 2013 г. 9:32
  • Это нужно выполнять на обоих КД? Будет ли от этого гарантированный результат в случае с моей проблемой?
    25 февраля 2013 г. 9:58
  • Вы все же не прочитали статью (

    Nonauthoritative Restore выполняется на проблемном контроллере. В вашем случае на HQ-SDC.

    Гарантий никто не дает.  99.(9)% что хуже не станет (если вы все же прочитаете статью, разберетесь в теории и не наделаете глупостей)


    Microsoft Certified Do Nothing Expert

    • Изменено Dmitry Zobnin 25 февраля 2013 г. 10:11
    25 февраля 2013 г. 10:10
  • В вашем случае есть всего два контроллера, поэтому достаточно выполнить лишь Nonautoritative Restore of an FRS-Replicated SYSVOL Folder

    Nonauthoritave проще чем Authoritative, в нем меньше шагов. Прочитайте теорию в статье, которую дал коллега M.V.V._, в ней подробно описываются все шаги авторитетного восстановления с пояснениями. Не ленитесь ). Если будут конкретные вопросы - задавайте.



    Microsoft Certified Do Nothing Expert


    Не факт. Я все еще не уверен, что FRS на HQ-DC работоспособна (слов про то, что после растарта ntfrs в журнале службы репликации не появляется ошибок, я не видел), поэтому может сначала потребоваться выполнить полномочное (authoritattive) восстановление  на нем, а уж потом - неполномочное на HQ-SDC

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


    • Изменено M.V.V. _ 25 февраля 2013 г. 11:31
    25 февраля 2013 г. 11:29
  • Я еще раз говорю! HQ-DC восстанавливал, а HQ-SDC поднимал на чистой машине и добавлял когтроллером в домен! Какую команду для кого делать и что нужно делать с FRS?

    25 февраля 2013 г. 14:35
  • Если коротко: HQ-DC у Вас - источник содержимого SYSVOL (refernce DC), а на HQ-SDC это содержимое еще только нужно реплицировать (когда Вы его поднимали, этого по какой-то причине не произошло, а Вы это не проконтролировали).

    Т.е. на HQ-DC восстановление, если его производить, должно быть полномочным (установите Burflags в значение D4), на HQ-SDC - неполномочным (установите Burflags в значение D2). Подробности - по приведенной мной ссылке (там, если нужно, можно получить и русский перевод), либо http://support.microsoft.com/kb/290762

    На всякий случай, перед этими действиями скопируйте куда-нибудь содержимое SYSVOL каждого из DC.


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

    • Помечено в качестве ответа kirilee 4 марта 2013 г. 2:14
    25 февраля 2013 г. 20:50
  • К стати по поводу репликаций - вот результаты команды repadmin /showreps с HQ-DC

    Microsoft Windows [Версия 6.0.6002]
    (C) Корпорация Майкрософт, 2006. Все права защищены.

    C:\Windows\system32>repadmin /showreps
    Default-First-Site\HQ-DC
    Параметры DSA: IS_GC
    Параметры узла: (none)
    DSA - GUID объекта: a59a8fe9-9e0e-4f3a-abfa-a0821cfdbfff
    DSA - код вызова: 6d5a8632-b053-4ee3-935c-114739a932d1

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

    DC=usem,DC=local
        Default-First-Site\HQ-SDC через  RPC
            DSA - GUID объекта: 8fb06763-f99b-48c9-bd06-8058d979de95
            Последняя попытка @ 2013-02-26 12:48:44 успешна.

    CN=Configuration,DC=usem,DC=local
        Default-First-Site\HQ-SDC через  RPC
            DSA - GUID объекта: 8fb06763-f99b-48c9-bd06-8058d979de95
            Последняя попытка @ 2013-02-26 12:48:44 успешна.

    CN=Schema,CN=Configuration,DC=usem,DC=local
        Default-First-Site\HQ-SDC через  RPC
            DSA - GUID объекта: 8fb06763-f99b-48c9-bd06-8058d979de95
            Последняя попытка @ 2013-02-26 12:48:44 успешна.

    DC=DomainDnsZones,DC=usem,DC=local
        Default-First-Site\HQ-SDC через  RPC
            DSA - GUID объекта: 8fb06763-f99b-48c9-bd06-8058d979de95
            Последняя попытка @ 2013-02-26 12:48:44 успешна.

    DC=ForestDnsZones,DC=usem,DC=local
        Default-First-Site\HQ-SDC через  RPC
            DSA - GUID объекта: 8fb06763-f99b-48c9-bd06-8058d979de95
            Последняя попытка @ 2013-02-26 12:48:44 успешна.

    C:\Windows\system32>

    Вроде реплики ходя.

    26 февраля 2013 г. 6:50
  • А вот с Hq-SDC

    Microsoft Windows [Версия 6.0.6002]
    (C) Корпорация Майкрософт, 2006. Все права защищены.

    C:\Windows\system32>repadmin /showreps
    Default-First-Site\HQ-SDC
    Параметры DSA: IS_GC
    Параметры узла: (none)
    DSA - GUID объекта: 8fb06763-f99b-48c9-bd06-8058d979de95
    DSA - код вызова: ff16c2f5-2f8b-4700-8d83-5703685bc4de

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

    DC=usem,DC=local
        Default-First-Site\HQ-DC через  RPC
            DSA - GUID объекта: a59a8fe9-9e0e-4f3a-abfa-a0821cfdbfff
            Последняя попытка @ 2013-02-26 12:50:06 успешна.

    CN=Configuration,DC=usem,DC=local
        Default-First-Site\HQ-DC через  RPC
            DSA - GUID объекта: a59a8fe9-9e0e-4f3a-abfa-a0821cfdbfff
            Последняя попытка @ 2013-02-26 12:43:24 успешна.

    CN=Schema,CN=Configuration,DC=usem,DC=local
        Default-First-Site\HQ-DC через  RPC
            DSA - GUID объекта: a59a8fe9-9e0e-4f3a-abfa-a0821cfdbfff
            Последняя попытка @ 2013-02-26 12:43:24 успешна.

    DC=DomainDnsZones,DC=usem,DC=local
        Default-First-Site\HQ-DC через  RPC
            DSA - GUID объекта: a59a8fe9-9e0e-4f3a-abfa-a0821cfdbfff
            Последняя попытка @ 2013-02-26 12:50:01 успешна.

    DC=ForestDnsZones,DC=usem,DC=local
        Default-First-Site\HQ-DC через  RPC
            DSA - GUID объекта: a59a8fe9-9e0e-4f3a-abfa-a0821cfdbfff
            Последняя попытка @ 2013-02-26 12:43:24 успешна.

    C:\Windows\system32>

    26 февраля 2013 г. 6:51
  • Вроде везде успешно! Не понятно откуда тогда ошибки и нужно ли выполнять восстановление SYSVOL то что рекомендуется выше? http://support.microsoft.com/kb/290762

    26 февраля 2013 г. 6:53
  • Вроде везде успешно! Не понятно откуда тогда ошибки и нужно ли выполнять восстановление SYSVOL то что рекомендуется выше? http://support.microsoft.com/kb/290762


    Репликация AD (которая, как показывает выдача repadmin, у вас успешна) и репликация SYSVOL (которая у вас не работает) - это две разные вещи. Читайте документацию.

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

    26 февраля 2013 г. 9:16
  • Спасибо буду смотреть!
    26 февраля 2013 г. 9:23
  • Коллеги!

    Рекомедации не помогли! Папка SYSVOL на HQ-SDC не реплицировалась!

    Почитал еще статьи. Там написана, что возможно проблемы с ДНС. На HQ-SDC есть событие 4515

    Зона usem.local ранее была загружена из раздела каталога DomainDnsZones.usem.local, но новая копия зоны найдена в разделе каталога ForestDnsZones.usem.local. DNS-сервер не будет использовать новую копию зоны. Необходимо разрешить данный конфликт как можно скорее.

    Если данная зона перемещена администратором из одного раздела каталога в другой, то это может быть безопасное переходное состояние. В этом случае в дополнительных действиях нет необходимости. Удаление первоначальной копии зоны должно скоро распространиться и на данный сервер.

    Если существует две копии зоны в двух различных разделах каталога, но это не является переходным эффектом операции перемещения зоны, то одна из копий должна быть удалена как можно скорее для устранения конфликта.

    Обращайтесь ко встроенной справке по вопросам изменения области репликации раздела каталога приложений, содержащего DNS-зоны, и за более подробными сведениями о сохранении DNS-зон в разделах каталога приложений.

    Зашел в настройки ДНС в мою зону usem.local и увидел, что репликация стоит для всех ДНС серверов в этом домене. А должно стоять для всех ДНС серверов в этом лесу если я не ошибаюсь! Пытаюсь менять режим и получаю ошибку!

    28 февраля 2013 г. 9:13
  • Обратил внимание, что есть какая-то зона _msdsc.usem.local в ее свойствах стоит днс сервера в этом лесу. Меняю кгалочке на ДНС сервера в этом домене. Изменяется. Но в зоне usem.local при смене зоны, та же ошибка. На основном HQ-DC итеация та же. Не могу повысить зону.

    Может это и является решением моей проблемы и реплики заработают.

    28 февраля 2013 г. 9:17
  • Замечательно - ещё и "morphed dns zone" (понятие собственное - ибо явление аналогичное morphed folders в FRS) получили метаниями... смысл сюда изливать, если вы не следуете прямым указаниям - получается флейм и пустая трата времени специалистов... вот вам статья и вот - только не уверен, что в итоге вы не положите свои остатки... и сильно вряд ли что FRS/DFS у вас не поднимается из-за DNS - в любом случае это можно проверить nslookup'ом: правильно ли резолвятся имена контроллеров друг у друга...
    28 февраля 2013 г. 9:43
    Отвечающий
  • nslokup показывает все верно!

    Я выполнил Ваше предписание. но ничего не получилось! Простите, что занимаю Ваше драгоценное время, но я просто по человечески просил помочь! Думаю , чтоы Вы тоже были в таких ситуациях и также просили помощи у спецов!

    28 февраля 2013 г. 9:47
  • Я так понимаю, что это стало последствием правки реестра либо команды Repadmin /syncall /aed
    28 февраля 2013 г. 9:49
  • В статье разбирается 2000 сервер! Может есть толковая пошаговая инструкция?
    28 февраля 2013 г. 9:50
  • Вот с HQ-DC

    Microsoft Windows [Версия 6.0.6002]
    (C) Корпорация Майкрософт, 2006. Все права защищены.

    C:\Users\kschemelev>nslookp
    "nslookp" не является внутренней или внешней
    командой, исполняемой программой или пакетным файлом.

    C:\Users\kschemelev>nslookup
    Default Server:  hq-sdc.usem.local
    Address:  192.168.0.3

    > hq-sdc
    Server:  hq-sdc.usem.local
    Address:  192.168.0.3

    Name:    hq-sdc.usem.local
    Address:  192.168.0.3

    >

    28 февраля 2013 г. 10:05
  • Вот с HQ-SDC

    Microsoft Windows [Версия 6.0.6002]
    (C) Корпорация Майкрософт, 2006. Все права защищены.

    C:\Users\kschemelev>nslookup
    Default Server:  hq-dc.usem.local
    Address:  192.168.0.1

    > hq-dc
    Server:  hq-dc.usem.local
    Address:  192.168.0.1

    Name:    hq-dc.usem.local
    Address:  192.168.0.1

    >

    28 февраля 2013 г. 10:07
  • Статья http://support.microsoft.com/kb/290762 на самом деле помогла! Просто нужно было немного подождать! Ошибка исчезла и SYSVOL появился! Спасибо!

    НО остаются ошибки АД 2886 и ДНС 4515 и 4013.

    Как можно их решить! Я так понимаю именно из-за этих ошибок в случае отключения HQ-DC при вводе команды nslookup получаю ошибку, что команда отрабатывает ДНС hQ-DC а не HQ-SDC.

    Как мне это исправить?

    1 марта 2013 г. 2:13
  • 2886 можно игнорировать - она нге влияет на работоспособность.

    4013, если она возникает только в момент загрузки, тоже можно игнорировать. Если в процессе работы - нужно разбираться, с чем она связана.

    4515 следует устранять. Для этого нужно

    а) убедиться, что серверы DNS на обоих КД загружают зоны из одного и того же раздела AD, если нет - перенастроить на HQ-SDC, откуда он загружает зону - через настройки области репликации для соотвествующей зоны на этом КД (можно в таком случае просто на время выполнения п. б удалить роль сервера DNS с HD-SDC)

    б) удалить ненужные копии зон из другого раздела. См. http://technet.microsoft.com/en-us/library/cc735755(v=WS.10).aspx и http://support.microsoft.com/kb/867464


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

    • Предложено в качестве ответа MikAndr 13 апреля 2015 г. 10:07
    4 марта 2013 г. 9:18