Usn rollback как вылечить

Что такое USN Rollback

Представьте себе, что в один не очень прекрасный день вы решили восстановить один из ваших контроллеров домена (КД) из резервной копии, которую вы по привычке сделали старым проверенным средством снятия образа диска, типа Acronis TrueImage. Или решили откатить ваш виртуализованный КД к старому снимку, сделанному средствами гипервизора (и всё это работало не под Windows Server 2012). Или же вам, как и мне однажды, не повезло: из-за сбоя RAID-контроллера, который управляет аппаратным зеркальным томом, содержащим систему КД, некоторое время тому назад из  этого зеркала вылетел один диск, а после перезапуска RAID-контроллер решил загрузить систему именно с этой, устаревшей половинки зеркала.

И вот, после перезагрузки вы обнаруживаете, что ваш контроллер домена — уже не совсем контроллер домена: он совершенно не желает авторизовывать пользователей и реплицировать изменения базы данных Active Directory (AD) с другими КД.  Если провести стандартную диагностику проблем AD с помощью утилит dcdiag, то мы увидим следующее (часть выдачи dcdiag для краткости опущена, важные для дальнейшего изложения признаки выделены жирным шрифтом):

C:UsersAdministrator.DOMAIN>dcdiag

…………………………………………………………………

Doing primary tests

Testing server: Default-First-Site-NameDC2
Starting test: Advertising
Warning: DsGetDcName returned information for \DC1.domain.loc, when
we were trying to reach DC2.
SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE.
         ……………………. DC2 failed test Advertising
…………………………………………………………………

Starting test: Replications
         [Replications Check,Replications Check] Inbound replication is
         disabled.
To correct, run «repadmin /options DC2 -DISABLE_INBOUND_REPL»
[Replications Check,DC2] Outbound replication is disabled.
To correct, run «repadmin /options DC2 -DISABLE_OUTBOUND_REPL»
  ……………………. DC2 failed test Replications
Starting test: RidManager
……………………. DC2 passed test RidManager
Starting test: Services
w32time Service is stopped on [DC2]
            NETLOGON Service is paused on [DC2]
         ……………………. DC2 failed test Services
— то есть, контроллер домена не объявляет себя контроллером домена, репликация базы данных AD отключена, а служба Netlogon («Сетевой вход в систему» в русской версии) находится в приостановленном состоянии. Если вы посмотрите в журнал событий Active Directory, то вы обнаружите в нём два характерных сообщения об ошибках:

с Event ID  2095

и с Event ID 2103

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

Если вы наблюдаете эти признаки, то это означает, что вы столкнулись с героем этой статьи — USN Rollback: возвращением текущего максимального последовательного номера изменений (USN) КД к старому, меньшему значению  (с помощью номеров последовательных изменений — USN — Active Directory отслеживает, какие именно изменения следует передавать при репликации между контроллерами домена, подробнее об этом ниже). Прочитать официальную информацию от Microsoft об этой проблеме можно в Technet Library (применительно к специфике виртуализованных контроллеров домена) или статье 885875 MS KB (на английском языке).

Хотя механизм возникновения данной проблемы изложен в указанных выше статьях, считаю необходимым для полноты изложения остановиться на нём и в этой статье (те, кому это не интересно или некогда это читать, могут перейти сразу к описанию процедуры восстановления в разделе Собственно рецепт). Потому что, чтобы понять, чем плохо возвращение текущего максимального универсального номера последовательных изменений к старому значению, нужно знать, как используются эти номера при обновлении копий базы данных Active Directory.

Active Directory спроектирована таким образом, чтобы при синхронизации (репликации) можно было передавать на целевой КД не всю базу данных, а только те изменения, которые не были ещё получены целевым КД. Для этого каждый измененный (в т.ч. вновь созанный) в базе данных AD объект или атрибут объекта маркируется в своих метаданных идентификатором КД (Invocation ID), на котором было первоначально произведено это изменение, и последовательным номером (USN) этого изменения на данном первоначальном КД (посмотреть метаданные для любого объекта и всех его атрибутов можно командой repadmin /showmeta ). При каждом изменении, первоначально произведенном на данном КД,  этот номер увеличивается.  Кроме того, каждый КД хранит у себя список максимальных номеров реплицированных изменений для каждого из известных ему КД-источников обновлений (идентифицируемых по Invocation ID) для каждого из разделов каталога — up-to-dateness vector (его можно посмотреть командой repadmin /showutdvec ). И при репликации КД запрашивает только те изменения, номер USN которых выше максимального номера уже полученного изменения.

Из этого описания видно, что если текущий максимальный номер USN по какой-то причине уменьшится, то изменения, промаркированные номерами USN в промежутке между новым текущим максимальным номером USN и запомненными на других КД максимальными номерами реплицированных изменений, никогда не будут реплицированы на эти другие КД, то есть, база данных AD окажется в рассогласованном состоянии — её содержимое на разных контроллерах доменов навсегда останется разным.

Поскольку все алгоритмы работы AD опираются на то, что содержимое баз данных на разных КД является (или достаточно быстро становится) одинаковым, то описанное выше положение дел является недопустимым. Чтобы его избежать, в механизм репликации AD был добавлен элемент контроля, проверяющий в момент первой репликации КД, что текущий максимальный номер USN на контроллере домена не меньше, чем максимальный номер реплицированных изменений, известных его партнерам по репликации. Если это условие не соблюдается, то AD блокирует входящую и исходящую репликацию, а также помечает (в реестре) свою копию базы данных как недоступную для записи по причине возвращения номера USN к меньшему значению — что как раз вызывает те самые симптомы, что описаны в начале статьи.

Обнаружение USN Rollback срабатывает, к сожалению, не всегда. Если контроллер домена после восстановления из образа долго не имеет связи с другими КД, и на нём за это время происходит много изменений, то после восстановления связи может оказаться, что на момент первой репликации после восстановления текущий максимальный номер USN окажется больше максимального номера реплицированных изменений, то условие отсутствия USN Rollback будет формально соблюдено, фактически имевший место откат назад номеров изменений обнаружен не будет и часть изменений так и останется не реплицированной. Такой вариант вполне реален при восстановлении КД после катастрофического отказа где-нибудь в филиале, где из-за того же отказа пострадала и связь. Так что, обнаружив приведенные в начале статьи симптомы, можно даже порадоваться — всё могло быть и хуже.

Как лечить USN Rollback

Лучшее лечение — это, как известно, профилактика. В применении к теме данной статьи это означает: делать резервные копии базы данных AD (она входит в раздел Состояние системы для КД) регулярно, и делать их программой, которая знает, как копировать и, главное — как восстанавливать базу данных AD. Простейшая из таких программ — это встроенная Windows Server Backup. Использование правильных программ исключает большинство возможных случаев возникновения USN Rollback, а если вдруг такая беда случилась (например, из-за сбоя RAID-контроллера, зеркалирующего системный диск) — без особых проблем восстановить базу данных AD.

Но вот что делать если беда уже случилась, а резервной копии базы данных AD нет? Рекомендации производителя — Microsoft — просты и незатейливы: понизить принудительно контроллер домена, удалить его метаданные из AD и повысить обратно. Процедуры эти просты и многократно описаны, здесь я на них останавливаться не буду. В большинстве случаев это можно проделать вполне безболезненно, и, собственно говоря, при наличии возможности именно так и стоит делать.

Интереснее другой вопрос — что делать, если принудительное понижение с последующим понижением — не вариант? Например, если на КД стоит какая-то программа, которая, с немалой степенью вероятности, не перенесёт такие манипуляции. Или USN Rollback возник на единственном контроллере вновь созданного домена, в котором уже были созданы учётные записи новых пользователей. Или вот,  например, был случай на русском форуме Technet, когда системный администратор умудрился загнать в состояние USN Rollback все контроллеры корневого домена леса — как сохранить лес? В таких случаях рекомендованный производителем способ решения проблемы не годится. Но выход, тем не менее, есть.Чтобы понять, как этот выход работает, следует рассмотреть две вещи: как при корректном восстановлении базы данных AD удаётся избежать USN Rollback, и какие именно изменения вносятся в конфигурацию КД при обнаружении этого состояния.

Для обеспечения корректности работы восстановленной базы данных программа восстановления делает одну простую вещь: она после завершения восстановления (а оно производится при загрузке в режиме службы восстановления каталогов) записывает в реестр новое значение для Invocation ID в параметр «HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSParametersNew Database GUID», заставляя AD при запуске во время следующей загрузки в нормальном режиме сменить Invocation ID — то есть заставляет выглядеть (с точки зрения механизма репликации базы данных AD) восстановленный контроллер домена как новый, совершенно другой КД, изменения на котором учитываются независимо от прежних, сделанных его до восстановления.

Что же касается реакции на USN Rollback то она включает в себя две вещи: во-первых, для подверженного ей КД отключается  (установкой флагов DISABLE_INBOUND_REPL и DISABLE_OUTBOUND_REPL в атрибуте Options объекта «NTDS Settings», связанного с объектом данного КД в разделе конфигурации) входящая и исходящая репликация, во-вторых в реестре этого КД в параметре «HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSParametersDSA not writeable» (типа REG_DWORD) фиксируется, что база данных AD не является допустимой по причине возникновения USN Rollback (значение параметра устанавливается равным 4). При обнаружении этого последнего параметра происходит запись в журнал события с кодом 2103, а служба Netlogon ставится в приостановленное состояние.

И в свете всего вышеизложенного становится понятно, что нужно делать, чтобы вывести контроллер домена из состояния USN Rollback:

Собственно рецепт.

Предупреждение. Приведенные ниже действия не опираются на официальные рекомендации Microsoft (хотя и проверены мной лично). Они могут привести к возникновению рассогласованных копий базы данных Active Directory на разных контроллерах доменов (см. ниже). Поэтому используйте их под свою ответственность и только в крайнем случае.

Предупреждение 2. Если на пострадавшем контроллере домена в БД AD были внесены какие-либо изменения после возникновения состояния USN Rollback, то эти изменения, скорее всего, никогда не будут реплицированы на другие контроллеры домена, даже после восстановления по указанной ниже процедуре (причины были рассмотрены в предыдущем разделе). Из-за этого произойдёт рассогласование копий БД. И впоследствии это может вылиться в странное поведение (например, несовпадающие пароли учётных записей) или даже в нарушение репликации (ошибка 8606). Если USN Rollback был обнаружен сразу же, и контроллер домена был вовремя заблокирован, то вероятность возникновения таких ошибок невелика. Но если это был, например, восстановленный из образа диска контроллер где-нибудь в филиале, то последствия могут быть весьма неприятными. Я надеюсь рассмотреть, как можно заранее вычислить такие изменения и сделать их доступным для репликации, в одной из следующих статей.

1. Заставить AD изменить Invocation ID. Хотя можно сделать это, напрямую записав соответствующий параметр в реестр, я считаю предпочтительным сделать это с помощью штатного Backup/Restore — это заодно устранит и возможные рассогласования копий папки SYSVOL на пострадавшем контроллере домена и других КД и позволит избедать возможных проблем с её репликацией (это другая тема, которую я тут не затрагиваю). Последовательность действий примерно следующая (я не расписываю подробно все шаги, поскольку они отражены во многих руководствах):

1а. Подготовительные действия. Установить, если ещё не установлен, компонент архивации и подготовить место, куда будет записана резервная копия (либо чистый локальный либо съёмный диск, либо пустую общую сетевую папку). Рекомендую также посмотреть (командой repadmin /showrepl ) зафиксировать текущий Invocation ID контроллера домена.

1б. Выполнить резервное копирование состояния системы (а лучше, если позволяет время и место на диске/папке — всего системного тома).

1в. Загрузиться в режиме восстановления службы каталогов и восстановить состояние системы. Рекомендую делать это от имени локальной учётной записи администратора режима восстановления службы каталогов (я наблюдал случаи, когда попытка восстановления состояния системы при регистрации под доменным администраторам приводила к необъяснимым сбоям).

1г. Загрузить контроллер домена в обычном режиме.

2. Разрешить входящую и исходящую репликацию для контроллера домена. Перед включением репликации в качестве меры предосторожности рекомендую проверить, что показываемое командой  repadmin /showrepl значение Invocation ID изменилось по сравнению со старым, зафиксированным на шаге 1а

Включение репликации производится командами

repadmin /options имя_КД -DISABLE_INBOUND_REPL

и

repadmin /options имя_КД -DISABLE_OUTBOUND_REPL

3. Удалить отметку о том, что база данных AD находится в недопустимом для записи состоянии по причине USN Rollback. Для этого надо запустить редактор реестра, выбрать ключ HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSParameters, найти в нём параметр «DSA not writeable» (его значение должно быть равно 4) и удалить этот параметр.

4. Запустить из приостановленного состояния (если она ещё не запустилась сама) службу Netlogon

После выполнения этих шагов я рекомендую (хотя это не обязательно) ещё раз перезагрузить контроллер домена и выполнить его диагностику с помощью команды dcdiag: после ликвидации USN Rollback могут проявиться и другие ошибки (см. например уже упоминавшийся случай на русском форуме Technet — там пришлось устранять и проблемы с SYSVOL, и не удалённые вовремя («застрявшие») из-за неработавшей репликации объекты).

Удачного вам восстановления. И больше так не делайте.