. Контроллер домена Windows Server регистрит событие Directory Services 2095 при откате usN
Контроллер домена Windows Server регистрит событие Directory Services 2095 при откате usN

Контроллер домена Windows Server регистрит событие Directory Services 2095 при откате usN

В этой статье описывается, как обнаруживать и восстанавливать, если контроллер домена Windows Server неправильно откатился с помощью установки операционной системы на основе изображений.

Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 Исходный номер КБ: 875495

Эта статья предназначена только для агентов технической поддержки и ИТ-специалистов. Если вы ищете помощь с проблемой, обратитесь в microsoft Community.

Сводка

В этой статье описывается сбой репликации Active Directory, вызванный откатом номера последовательности обновления (USN). Откат USN возникает при неправильном восстановлении или вклеии старой версии базы данных Active Directory.

При откате usN изменения объектов и атрибутов, которые происходят на одном контроллере домена, не реплицируется в другие контроллеры домена в лесу. Поскольку партнеры репликации считают, что у них есть дополнивая копия базы данных Active Directory, средства мониторинга и устранения неполадок, такие как Repadmin.exe, не сообщают об ошибках репликации.

Контроллеры домена журнал Directory Services Event 2095 в журнале событий Службы каталогов при обнаружении отката usN. Текст сообщения события направляет администраторов в эту статью, чтобы узнать о вариантах восстановления.

Пример записи журнала Event 2095

В следующих темах обсуждаются вопросы обнаружения и восстановления отката usN в контроллере домена на Windows сервере.

Поддерживаемые методы для поддержки Active Directory для контроллеров доменов, которые работают Windows Server 2012 и более поздних версиях

Windows Server 2012 добавляет поддержку Hyper-Visor Generation ID (GenID). Это позволяет виртуальному гостю обнаруживать тома дисков, которые имеют новый ID, и реагировать на новый GenID. В Active Directory службы каталогов реагируют так, как будто контроллер домена был восстановлен из резервного копирования. Затем создается новый ID вызовов. С помощью нового ИД вызовов экземпляр базы данных может безопасно повторно вводить репликацию в лесу.

Это один из сценариев, который охватывается виртуализированным развертыванием контроллера домена и конфигурацией.

Поддерживаемые методы для поддержки Active Directory на контроллерах доменов, которые работают Windows Server 2003 или более поздних версиях Windows Server

В течение жизненного цикла контроллера домена может потребоваться восстановить или "откатить" содержимое базы данных Active Directory до известной точки времени. Или, возможно, вам придется откат элементов хост-системы контроллера домена, включая Active Directory, до известной хорошей точки.

Поддерживаются следующие методы, которые можно использовать для отката содержимого Active Directory:

Используйте утилиту резервного копирования и восстановления active Directory, которая использует API, предоставляемые Корпорацией Майкрософт и протестированную Корпорацией Майкрософт. Эти API неавторитарно или достоверно восстанавливают резервное копирование системного состояния. Восстановленная резервная копия должна исходить из одной и той же установки операционной системы и с того же физического или виртуального компьютера, который восстанавливается.

Используйте утилиту резервного копирования и восстановления active Directory, которая использует API службы копирования microsoft Volume Shadow Copy Service. Эти API восстанавливают и восстанавливают состояние системы контроллера домена. Служба копирования теней тома поддерживает создание однократных теневых копий одного или нескольких томов на компьютерах с Windows Server 2003, Windows Server 2008 или Windows Server 2008 R2. Одно точка в времени теневых копий также известны как моментальные снимки. Дополнительные сведения можно найти в службе "Том Теневая служба копирования" в Службе поддержки Майкрософт.

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

Типичное поведение, которое происходит при восстановлении резервного копирования системного состояния с данными active Directory.

Windows Контроллеры доменов сервера используют USNs вместе с ИД вызовов для отслеживания обновлений, которые должны быть реплицированы между партнерами репликации в лесу Active Directory.

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

Идентификатор призыва определяет версию или моментацию базы данных Active Directory, которая работает на заданном контроллере домена.

Когда Active Directory восстанавливается на контроллере домена с помощью API и методов, разработанных и протестированных Корпорацией Майкрософт, ID вызовов правильно сбрасывается на восстановленном контроллере домена. Контроллеры домена в лесу получают уведомление об сбросе вызовов. Поэтому они соответствующим образом корректируют свои высокие значения водяных знаков.

Программное обеспечение и методологии, которые вызывают откаты USN

Когда используются следующие среды, программы или подсистемы, администраторы могут обойти проверки и проверки, разработанные Корпорацией Майкрософт при восстановлении состояния системы контроллера домена:

Запуск контроллера домена Active Directory, файл базы данных Active Directory которого был восстановлен (скопирован) с помощью такой программы изображений, как Norton Ghost.

Запуск ранее сохраненного виртуального жесткого диска контроллера домена. Следующий сценарий может привести к откату USN:

  1. Продвижение контроллера домена в виртуальной среде размещения.
  2. Создайте снимок или альтернативную версию виртуальной среды размещения.
  3. Позвольте контроллеру домена продолжать репликацию входящие и исходящие репликации.
  4. Запустите созданный файл изображений контроллера домена в шаге 2.

Примеры виртуализированных сред размещения, которые вызывают этот сценарий, включают Microsoft Virtual PC 2004, Microsoft Virtual Server 2005 и EMC VMWARE. Другие виртуализированные среды размещения также могут вызывать этот сценарий.

Дополнительные сведения об условиях поддержки контроллеров домена в виртуальных средах хостинга см. в дополнительных сведениях о том, что следует учитывать при размещении контроллеров домена Active Directory в виртуальных средах размещения.

Запуск контроллера домена Active Directory, расположенного на томе, где дисковая подсистема загружается с помощью сохраненных ранее изображений операционной системы без необходимости восстановления состояния системы Active Directory.

Сценарий A. Запуск нескольких копий Active Directory, расположенных на дисковой подсистеме, которая хранит несколько версий тома

  1. Продвижение контроллера домена. Найдите файл Ntds.dit в подсистеме диска, которая может хранить несколько версий тома, в котором размещен файл Ntds.dit.
  2. Используйте дисковую подсистему для создания снимка тома, в котором размещен файл Ntds.dit для контроллера домена.
  3. Продолжайте, чтобы контроллер домена загружал Active Directory из тома, созданного на шаге 1.
  4. Запустите контроллер домена, сохраненный базой данных Active Directory в шаге 2.

Сценарий B. Запуск Active Directory с других дисков в разбитом зеркале

  1. Продвижение контроллера домена. Найдите файл Ntds.dit на зеркальном диске.
  2. Разломай зеркало.
  3. Продолжайте реплицировать входящие и исходящие репликации с помощью файла Ntds.dit на первом диске в зеркале.
  4. Запустите контроллер домена с помощью файла Ntds.dit на втором диске в зеркале.

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

Корпорация Майкрософт не поддерживает любой другой процесс, который делает снимок элементов системного состояния контроллера домена Active Directory и копирует элементы этого системного состояния на изображение операционной системы. Если администратор не вмешается, такие процессы вызывают откат USN. Это откат USN вызывает прямые и транзитные партнеры репликации неправильно восстановленного контроллера домена иметь несовместимые объекты в базах данных Active Directory.

Последствия отката USN

При откатах usN изменения объектов и атрибутов не реплицированы контроллерами домена назначения, которые ранее видели USN.

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

Откат USN может повлиять на репликацию любого объекта или атрибута в любом разделе. Наиболее часто наблюдаемый побочный эффект — это то, что учетные записи пользователей и учетные записи компьютеров, созданные на контроллере отката домена, не существуют на одном или более партнерах репликации. Или обновления паролей, которые появились на контроллере домена отката, не существуют в партнерах репликации.

На следующих действиях покажите последовательность событий, которые могут привести к откату USN. Откат USN происходит при откате состояния системы контроллера домена во времени с помощью неподдержки восстановления состояния системы.

Администратор продвигает три контроллера домена в домене. (В этом примере контроллеры домена — DC1, DC2 и DC2, а домен — Contoso.com.) DC1 и DC2 являются прямыми партнерами репликации. DC2 и DC3 также являются прямыми партнерами репликации. DC1 и DC3 не являются прямыми партнерами репликации, но получают возникающие обновления транзитно через DC2.

Администратор создает 10 учетных записей пользователей, соответствующих USNs от 1 до 10 на DC1. Все эти учетные записи реплицируется в DC2 и DC3.

На DC1 запечатлено изображение диска операционной системы. На этом изображении записаны объекты, соответствующие локальным USNs 1-10 на DC1.

В Active Directory внося следующие изменения:

  • Пароли для всех 10 учетных записей пользователей, созданных на шаге 2, сбрасываются на DC1. Эти пароли соответствуют USNs от 11 до 20. Все 10 обновленных паролей реплицируется в DC2 и DC3.
  • В DC1 создаются 10 новых учетных записей пользователей, соответствующих USNs от 21 до 30. Эти 10 учетных записей пользователей реплицируется в DC2 и DC3.
  • На DC1 создаются 10 новых учетных записей компьютера, соответствующих USNs 31-40. Эти 10 учетных записей компьютера реплицируется в DC2 и DC3.
  • В DC1 создаются 10 новых групп безопасности, соответствующих USNs от 41 до 50. Эти 10 групп безопасности реплицируется в DC2 и DC3.

DC1 испытывает сбой оборудования или сбой программного обеспечения. Администратор использует утилиту изображений на диске для копирования изображения операционной системы, созданного на шаге 3 на месте. ТЕПЕРЬ DC1 начинается с базы данных Active Directory, которая имеет знания о usNs от 1 до 10.

Так как изображение операционной системы было скопировано на место, а поддерживаемый метод восстановления системного состояния не использовался, DC1 продолжает использовать тот же ИД вызовов, который создал начальную копию базы данных и все изменения до USN 50. DC2 и DC3 также поддерживают один и тот же ИД вызовов для DC1, а также новый вектор USN 50 для DC1. (Современный вектор — это текущее состояние последних обновлений, происходящих на всех контроллерах домена для данного раздела каталога.)

Если администратор не вмешается, DC2 и DC3 не будут реплицировать изменения, соответствующие локальным USN 11-50, происходящим из DC1. Кроме того, в соответствии с ИД вызовов, который использует DC2, DC1 уже имеет знания об изменениях, которые соответствуют USN 11 до 50. Поэтому DC2 не отправляет эти изменения. Так как изменения в шаге 4 не существуют в DC1, запросы на логос сбой с ошибкой "отказано в доступе". Эта ошибка возникает либо из-за того, что пароли не совпадают, либо из-за того, что учетная запись не существует при случайной проверке подлинности новых учетных записей с помощью DC1.

Администраторы, отслеживавшие состояние репликации в лесу, отмечают следующие ситуации:

Средство командной строки сообщает, что двунастрочная репликация Active Directory между DC1 и DC2 и между DC2 и DC3 происходит Repadmin /showreps без ошибок. Эта ситуация затрудняет обнаружение непоследовательности репликации.

События репликации в журналах событий службы каталогов контроллеров доменов, которые работают Windows Server, не указывают на сбои репликации в журналах событий службы каталогов. Эта ситуация затрудняет обнаружение непоследовательности репликации.

Пользователи и компьютеры Active Directory или средство администрирования Active Directory (Ldp.exe) показывают различное количество объектов и метаданных объектов, когда разделы каталогов доменов на DC2 и DC3 сравниваются с разделами на DC1. Разница заключается в наборе изменений, которые карта usN изменяет от 11 до 50 на шаге 4.

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

Запросы на проверку подлинности пользователей для 10 учетных записей пользователей, созданных на шаге 2, иногда создают ошибку "отказано в доступе" или "неправильный пароль". Эта ошибка может возникнуть из-за несоответствия пароля между этими учетными записями пользователей на DC1 и учетными записями dc2 и DC3. Учетные записи пользователей, которые испытывают эту проблему, соответствуют учетным записям пользователей, созданным в шаге 4. Учетные записи пользователей и сброс пароля в шаге 4 не реплицируется на другие контроллеры домена в домене.

DC2 и DC3 начинают воспроизводить исходящие обновления, соответствующие номерам USN, которые больше 50 из DC1. Эта репликация обычно продолжается без административного вмешательства, так как ранее зарегистрированный порог переноса, USN 50, был превышен. (USN 50 — это вектор usN, записанный для DC1 на DC2 и DC3 до отключения и восстановления DC1.) Однако новые изменения, которые соответствовали USNs 11-50 в исходивом DC1 после неподтверченного восстановления, никогда не будут реплицироваться в DC2, DC3 или их транзитных партнеров репликации.

Хотя симптомы, упомянутые в шаге 6, представляют некоторые из последствий отката usN для учетных записей пользователей и компьютеров, откат USN может предотвратить репликацию любого типа объекта в любом разделе Active Directory. К этим типам объектов относятся следующие:

Топология и расписание репликации Active Directory

Наличие контроллеров домена в лесу и роли, которые эти контроллеры занимают

Эти роли включают распределение глобальных каталогов, относительный идентификатор (RID) и главные роли операций. (Главные роли операций также называются гибкими одиночными мастер-операциями или FSMO.)

Наличие разделов домена и приложений в лесу

Существование групп безопасности и их текущих членов

Регистрация записей DNS в зонах DNS, интегрированных в Active Directory

Размер дыры USN может представлять сотни, тысячи или даже десятки тысяч изменений пользователей, компьютеров, траста, паролей и групп безопасности. (Отверстие USN определяется разницей между самым высоким номером USN, который существовал при восстановлении резервного копирования состояния системы, и количеством происходящих изменений, созданных на откате контроллера домена до его отключения.)

Обнаружение отката USN на контроллере домена Windows Server

Так как откат usN трудно обнаружить, Windows Сервер 2003 SP1 или более поздний контроллер домена версии регистрировать событие 2095, когда контроллер домена источника отправляет ранее признанный номер USN контроллеру домена назначения без соответствующего изменения в коде вызовов.

Чтобы предотвратить возможность создания уникальных обновлений Active Directory на неправильно восстановленном контроллере домена, служба Net Logon приостановлена. Когда служба Net Logon приостановлена, учетные записи пользователей и компьютеров не могут изменить пароль на контроллере домена, который не будет воспроизводить такие изменения исходящие. Кроме того, средства администрирования Active Directory будут благоприятствуть здоровому контроллеру домена при обновлении объектов в Active Directory.

На контроллере домена записывают сообщения событий, похожие на следующие, если верны следующие условия:

  • Контроллер домена источника отправляет ранее признанный номер USN контроллеру домена назначения.
  • Соответствующие изменения в ID-вызове не изменяются.

Эти события могут быть запечатлены в журнале событий службы каталогов. Однако они могут быть перезаписаны до наблюдения администратора.

Вы можете подозревать, что откат USN произошел. Однако в журнале событий службы каталогов не видятся соотносимые события. В этом сценарии проверьте запись реестра Dsa Not Writable. В этой записи приводится судебно-медицинская экспертиза о том, что произошло откат usN.

  • Подкайка реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
  • Запись реестра: Dsa Not Writable
  • Значение: 0x4

Удаление или вручную изменение значения записи записи реестра Dsa Not Writable ставит контроллер отката домена в постоянно неподдержку. Поэтому такие изменения не поддерживаются. В частности, изменение значения удаляет поведение карантина, добавленное кодом обнаружения отката usN. Разделы Active Directory на контроллере отката домена будут постоянно несовместимы с прямыми и транзитными партнерами репликации в том же лесу Active Directory.

Восстановление после отката USN

Существует три подхода к восстановлению после отката usN.

Удаление контроллера домена из домена. Для этого выполните следующие действия:

Удалите Active Directory из контроллера домена, чтобы заставить его быть автономным сервером. Дополнительные сведения см. в примере Контроллеры домена, которые не изящно понижали при использовании мастера установки Active Directory для принудительного понижения.

Отключим пониженный сервер.

На здоровом контроллере домена очистите метаданные пониженного контроллера домена. Дополнительные сведения см. в дополнительных сведениях о метаданных сервера контроллера домена Active Directory.

Если неправильно восстановленный контроллер домена принимает главные роли операций, передай эти роли здоровому контроллеру домена. Дополнительные сведения см. в рублях Transfer or seize FSMO roles in Active Directory Domain Services.

Перезапустите пониженный сервер.

Если требуется, установите Active Directory на автономный сервер снова.

Если контроллер домена ранее был глобальным каталогом, настройте контроллер домена на глобальный каталог. Дополнительные сведения см. в книге Как создать или переместить глобальный каталог.

Если контроллер домена ранее принимал главные роли операций, переведи главные роли операций обратно в контроллер домена. Дополнительные сведения см. в рублях Transfer or seize FSMO roles in Active Directory Domain Services.

Восстановление системного состояния хорошей резервной копии.

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

Восстановление состояния системы без резервного копирования состояния системы.

Снимок можно использовать в качестве источника резервного копирования. Или вы можете настроить базу данных, чтобы дать себе новый код вызовов, используя процедуру в разделе Восстановление предыдущей версии виртуального контроллера домена VHD без резервного копирования данных системного состояния в разделе Running Domain Controllersв Hyper-V .

📎📎📎📎📎📎📎📎📎📎