Контроллеры домена не понижали изящное понижение при использовании мастера установки active directory для принудительного понижения

Установка и Настройка службы DNS-сервера

если контроллер домена, восстановленный из резервной копии, выполняется Windows сервере 2003, можно установить DNS-сервер без подключения контроллера домена к любой сети.

Установка и Настройка службы DNS-сервера

1. откройте мастер Windows компонентов. Чтобы открыть мастер, сделайте следующее:

   • Щелкните Пуск, нажмите Панель управления, а затем Установка и удаление программ.
   • щелкните добавить или удалить Windows компоненты.

2. В окне компоненты установите флажок Сетевые службы и нажмите кнопку сведения.

3. В области «Сетевые службы» установите флажок Служба доменных имен (DNS) , нажмите кнопку ОК, а затем нажмите кнопку Далее.

4. При появлении запроса в поле Copy files from (копирование файлов из) введите полный путь к файлам распространения и нажмите кнопку ОК.

   После установки выполните следующие действия, чтобы настроить DNS-сервер.

5. Нажмите кнопку Пуск, укажите пункт все программы, затем Администрирование и щелкните DNS.

6. Создайте зоны DNS для тех же доменных имен DNS, которые были размещены на DNS-серверах до критического сбоя. Дополнительные сведения см. в разделе Добавление зоны прямого просмотра ( https://go.microsoft.com/fwlink/?LinkId=74574 ).

7. Настройте данные DNS в том виде, в котором они существовали до критического сбоя. Пример:

   • Настройте зоны DNS, которые будут храниться в AD DS. Дополнительные сведения см. в разделе Изменение типа зоны ( https://go.microsoft.com/fwlink/?LinkId=74579 ).
   • Настройте зону DNS, которая является полномочным для записей ресурсов локатора контроллеров доменов (локатора контроллера домена), чтобы разрешить безопасное динамическое обновление. Дополнительные сведения см. в разделе разрешение только безопасных динамических обновлений ( https://go.microsoft.com/fwlink/?LinkId=74580 ).

8. Убедитесь, что родительская зона DNS содержит записи ресурсов делегирования (записи ресурсов сервера имен (NS) и узлов (A)) для дочерней зоны, размещенной на этом DNS-сервере. Дополнительные сведения см. в разделе Создание делегирования зоны ( https://go.microsoft.com/fwlink/?LinkId=74562 ).

9. После настройки DNS в командной строке введите следующую команду и нажмите клавишу ВВОД:

   net stop netlogon

10. Введите следующую команду и нажмите клавишу ВВОД.

    net start netlogon

    Примечание

    Команда Net Logon регистрирует записи ресурсов локатора контроллеров домена в DNS для этого контроллера домена. Если служба DNS-сервера устанавливается на сервере в дочернем домене, этот контроллер не сможет немедленно зарегистрировать свои записи. Это связано с тем, что в настоящее время он изолирован как часть процесса восстановления, а его основной DNS-сервер — корневой DNS-сервер леса. Настройте этот компьютер с тем же IP-адресом, который использовался до аварии, чтобы избежать сбоев поиска в службе контроллера домена.

Техническая поддержка Windows x64

Производитель оборудования предоставляет техническую поддержку и поддержку для Windows x64. Производитель оборудования предоставляет поддержку, поскольку Windows x64 была включена в ваше оборудование. Производитель оборудования мог настроить установку Windows x64 с уникальными компонентами. Уникальные компоненты могут включать определенные драйверы устройств или могут включать необязательные параметры для максимальной производительности оборудования. Корпорация Майкрософт предоставит необходимую помощь, если вам потребуется техническая помощь с Windows x64. Однако вам может потребоваться связаться с производителем напрямую. Ваш производитель лучше всего может поддерживать программное обеспечение, установленное производителем на оборудовании.

Резервное копирование данных состояния системы

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

Членство в группах Администраторы или Операторы резервного копирования, или эквивалентное, является минимальным требованием для резервного копирования файлов и папок.

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

Можно выполнять резервное копирование только данных о состоянии системы на локальном компьютере. Вы не можете создать резервную копию на удаленном компьютере.

Рекомендации по бэкапу контроллеров домена

Сервисы Active Directory разработаны с учетом избыточности, поэтому привычные правила и тактики бэкапа необходимо адаптировать соответствующим образом. В данном случае будет неправильно использовать ту же политику бэкапа, что уже работает для серверов SQL или Exchange. Ниже я приведу ряд рекомендаций, которые могут помочь при разработке вашей собственной политики для Active Directory:

Выясните, какие контроллеры домена в вашей среде выполняют роли FSMO (Flexible Single Master Operations). Совет: простая команда для проверки через командную строку: >netdom query fsmo

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

• Если на площадке несколько контроллеров домена, а вы хотите защитить отдельные объекты, то у вас нет необходимости в бэкапе всех контроллеров. Для восстановления отдельных объектов будет достаточно одной копии базы данных Active Directory (ntds.dit)
• Всегда есть возможность снизить риск случайного или намеренного удаления или изменения объектов AD. Можно порекомендовать делегирование административных полномочий, настройку ограничений доступа с повышенными правами и резервную площадку c задержкой репликации.
• Обычно рекомендуется выполнять бэкап контроллеров доменов поочередно и так, чтобы оно не пересекалось с репликацией DFS. Хотя современные решения (например, Veeam Backup & Replication v7 с пакетом обновления 3 и выше) знают, как решать эту проблему.
• Если вы используете виртуальную среду VMware, контроллер домена может быть недоступен по сети (например, он находится в зоне DMZ). В этой ситуации Veeam переключится на соединение через VMware VIX и сможет обработать этот контроллер.

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

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

Это самый простой способ, который гарантирует что вы не внесете непоправимых изменений в AD. В этом сценарии база ntds.dit, объекты GPO и содержимое папки SYSVOL будут автоматически реплицированы на новый DC с DC-ов, оставшихся онлайн.

Если размер базы ADDS небольшой и другой DC доступен по скоростному каналу, это намного быстрее, чем восстанавливать DC из бэкапа.

Восстановление леса в режиме изоляции

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

Особенно важно завершить работу всех владельцев ролей хозяина операций

Примечание

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

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

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

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

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

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

Контроллеры RODC могут продолжать работу, пока доступные для записи контроллеры домена находятся в автономном режиме. Ни один другой контроллер домена не будет напрямую реплицировать изменения с любого контроллера домена только для чтения (особенно без изменений контейнера схемы или конфигурации), так что они не будут иметь тот же риск, что и записываемые контроллеры домена во время восстановления. После восстановления и подключения всех доступных для записи контроллеров домена следует перестроить все контроллеры RODC.

Контроллеры RODC будут по-прежнему разрешать доступ к локальным ресурсам, кэшированным на соответствующих сайтах, в то время как операции восстановления будут выполняться параллельно. Локальные ресурсы, которые не кэшируются на RODC, будут иметь запросы на проверку подлинности, перенаправляемые на доступный для записи контроллер домена. Эти запросы завершатся ошибкой, так как доступные для записи контроллеры домена находятся в автономном режиме. Некоторые операции, такие как изменение пароля, также не будут работать до тех пор, пока не будет восстановлен доступный для записи контроллер домена.

Если вы используете архитектуру сети типа «звезда», вы можете сначала сосредоточиться на восстановлении доступных для записи контроллеров домена на центральных сайтах. Позже можно перестроить Контроллеры RODC на удаленных сайтах.

Восстановление Exchange Server

Почти все параметры конфигурации для серверов почтовых ящиков и клиентского доступа хранятся в Active Directory. Как и предыдущие версии Exchange, Exchange 2013 включает в себя параметр установки для восстановления потерянных серверов. Этот параметр, /m:RecoverServer, используется для восстановления и повторного создания потерянного сервера с помощью параметров и сведений о конфигурации, хранимой в Active Directory

Однако обратите внимание, что некоторые параметры не сохраняются, например локальный файл web.config и другие файлы конфигурации. Кроме того, не сохраняются пользовательские записи реестра

Для отслеживания и воссоздания таких изменений мы рекомендуем использовать надежный процесс управления изменениями.

Дополнительные сведения о восстановлении потерянного сервера Exchange 2013 см. в разделе Восстановление сервера Exchange. Дополнительные сведения о восстановлении потерянного сервера, являющегося участником группы обеспечения доступности баз данных, см. в разделе Восстановление рядового сервера группы обеспечения доступности баз данных.

Повторно подключите каждый восстановленный доступный для записи контроллер домена к общей сети

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

Примечание

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

После проверки подключите контроллеры домена к рабочей сети и выполните действия, чтобы проверить работоспособность репликации леса.

• Чтобы устранить разрешение имен, создайте записи делегирования DNS и настройте пересылку DNS и корневые ссылки по мере необходимости. Выполните команду repadmin/реплсум , чтобы проверить репликацию между контроллерами домена.
• Если восстановленные контроллеры домена не являются прямыми партнерами по репликации, восстановление репликации будет выполняться гораздо быстрее, создавая временные объекты соединения между ними.
• Чтобы проверить очистку метаданных, выполните команду repadmin \ /виевлист _ для списка всех контроллеров домена в лесу. Выполните команду _ nltest/дклист: * <> domain , чтобы получить список всех контроллеров домена в домене.
• Чтобы проверить работоспособность контроллера домена и DNS, запустите DCDiag/v, чтобы сообщить об ошибках на всех контроллерах домена в лесу.

Переносимость баз данных

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

Дополнительные сведения см. в статье Переносимость баз данных. Дополнительные сведения об использовании переносимости баз данных см. в статье Перемещение базы данных почтовых ящиков с помощью переносимости базы данных.

Очистка корня DFS

Если вы используете корень DFS а тем более если вы используете репликацию в DFS, то у вас после восстановления службы FRS может сохраниться событие 13508 в журнале, а DCDIAG в результатах может выдавать такую ошибку «Conflict Mangled Value». Это происходит из-за разных причин, но в основном из-за вручную удаленных объектов репликации.

Если ссылок в корне DFS не много, то самым быстрым способом будет пересоздать все ссылки, очистив дерево. При этом очистив дерево от ненужных объектов, а также очистив реестры всех контроллеров домена. Тогда при повторном создании корня DFS все объекты дерева и ветки реестра будут созданы заново.

Итак, что я удаляю в такой ситуации:

Сначала я запускаю оснастку «Distributed File System». У меня всего две корневых ссылки, в одной из них включена репликация.

Затем я удаляю целевые папки

Если вы удаляете последнюю целевую папку для корневой ссылки, то при этом удаляется и сама ссылка.

Удаляю оставшуюся корневую ссылку

Теперь удаляю корневые целевые папки, папку с текущего контроллера удаляю последней

Удаление последней целевой папки удаляю весь корень DFS.

Все, корень DFS удален, но в дереве все объекты остались, удаляем и их. Делаю это с помощью ADSIedit.

Первый объект, который я удаляю, это объектCN=DFS Volumes,CN=File Replication Service,CN=System,DC=test,DC=com. Удаляю его полностью со всем содержимым.

Второе место в котором я чищу ссылки это объект «CN=NTFRS Subscriptions» для каждого контроллера домена, который участвовал в репликации. В моем случае:

«CN=DFS Volumes\0ACNF:98627048-5ae0-492c-b929-911c72c54100,CN=NTFRS Subscriptions,CN=DC1,OU=Domain Controllers,DC=test,DC=com» — для контроллера DC1

«CN=DFS Volumes\0ACNF:2d3688fd-094c-4bdd-b017-8e2b29a51c5f,CN=NTFRS Subscriptions,CN=DC2,OU=Domain Controllers,DC=test,DC=com» — для контроллера DC2

Так как контроллер DC3 не учувствовал в репликации ссылок DFS, то у него и не создавались подобные объекты.

После очистки дерева необходимо почистить реестр каждого контроллера домена. Запускаю regedit и открываю ветку реестра «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets». В этой ветке должно быть несколько реплик, которые относятся к службе FRS. Нахожу реплики, которые относятся к DFS. У этих реплик значение параметра «Replica Set Type» будет равно «DFS»

Репликиудаляю в двух ветках реестра:

• «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets»
• «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets»

Все реплики удалены

Аналогично удаляю на всех контроллерах домена.

После создания корня DFS заново все выглядит вот так:

А в системных событиях появились записи о событиях 13553 и 13554 говорящие о успешном запуске репликации ссылок DFS.

Восстановление единого хранилища контактов

При использовании Lync 2013 в среде Exchange 2013 контактные данные пользователя Lync хранятся в специальной папке контактов в почтовом ящике пользователя. Это называется единым хранилищем контактов (UCS). При восстановлении почтового ящика, перенесенного в UCS, может быть затронут список контактов службы обмена мгновенными сообщениями для конечного пользователя. Если пользователь был перенесен после последней архивации, восстановление почтового ящика приведет к полной потере списка контактов пользователя. В менее значительных случаях изменения списка контактов, внесенные пользователем после последней архивации, будут утеряны. Для устранения риска возможной потери данных убедитесь, что пользователь перенесен на сервер мгновенных сообщений перед восстановлением почтового ящика.

Защита Active Directory

Защита «сайт-сайт»

Создайте контроллер домена на дополнительном сайте. При повышении роли сервера до роли контроллера домена укажите имя того домена, который используется на основном сайте. Чтобы настроить параметры объекта связывания сайтов, в который добавляются сайты, можно использовать оснастку Active Directory — сайты и службы. Настраивая параметры связи между сайтами, можно указать время и периодичность репликации между двумя или несколькими сайтами. Дополнительные сведения см. в статье Расписание репликации между сайтами.

Защита «сайт-Azure»

Сначала создайте контроллер домена в виртуальной сети Azure. При повышении роли сервера до роли контроллера домена укажите имя домена, которое используется на основном сайте.

Затем измените конфигурацию DNS-сервера для виртуальной сети так, чтобы использовался DNS-сервер в Azure.

Защита «Azure — Azure»

Сначала создайте контроллер домена в виртуальной сети Azure. При повышении роли сервера до роли контроллера домена укажите имя домена, которое используется на основном сайте.

Затем измените конфигурацию DNS-сервера для виртуальной сети так, чтобы использовался DNS-сервер в Azure.

Как временно стабилизировать дерево SYSVOL домена

1. Остановите FRS для всех контроллеров домена в домене и установите службу отключенной.

2. Вручную скопируйте полный набор политик в следующую папку на каждом контроллере домена:

   \Политики доменных имен \ SYSVOL SYSVOL \ \

   Как правило, для проверки подлинности требуются следующие две политики:

   • Политика контроллеров доменов по умолчанию{6AC1786C-016F-11D2-945F-00C04fB984F9}
   • Политика домена по умолчанию {31B2F340-016D-11D2-945F-00C04FB984F984F9}

   Примечание

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

3. Вручную скопируйте все необходимые скрипты в следующую папку:

   \Скрипты доменных имен \ SYSVOL SYSVOL \ DNS \

Предварительные условия и ограничения

BMR не поддерживается для компьютеров, работающих под управлением Windows Server 2003 или клиентских операционных систем.

Состояние системы и BMR одного и того же компьютера не могут находиться в разных группах защиты.

Сервер DPM не может защищать сам себя с помощью BMR.

Краткосрочная защита с записью на ленту (D2T) не поддерживается для BMR. Долгосрочное хранение на ленте (D2D2T) поддерживается.

Для BMR на защищаемом компьютере должна быть установлена система архивации данных Windows Server.

Для защиты BMR (в отличие от защиты состояния системы) DPM не предъявляет требований к дисковому пространству на защищаемом компьютере. Система архивации данных Windows Server (WSB) передает резервные копии непосредственно на сервер DPM

Обратите внимание, что это задание не отображается при просмотре представления заданий в DPM.

Если вы используете современное хранилище резервных копий и хотите увеличить размер реплики по умолчанию для BMR до более чем 30 ГБ, используйте следующий раздел реестра: HKLM\Software\Microsoft\Microsoft Data Protection Manager\Configuration ReplicaSizeInGBForSystemProtectionWithBMR (DWORD).

При использовании современного хранилища резервных копий резервные копии SystemState и BMR занимают больше места, чем при использовании традиционного хранилища, из-за клонирования ReFS. Каждая резервная копия SystemState или BMR является полной точкой восстановления

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

Примечание

Указанные ниже ограничения не распространяются на современное хранилище резервных копий (MBS). Указанные ниже ограничения действуют только при использовании традиционного хранилища после обновления DPM 2012 R2 до DPM 2016.

DPM резервирует для BMR 30 ГБ дискового пространства на томе реплики. Это значение можно изменить на странице «Выделение места на диске» в мастере изменения группы защиты либо с помощью командлетов PowerShell Get-DatasourceDiskAllocation и Set-DatasourceDiskAllocation

На томе точек восстановления механизм защиты посредством восстановления исходного состояния системы требует приблизительно 6 ГБ дискового пространства для хранения данных в течение пяти дней.
Обратите внимание, что размер тома реплики не может быть меньше 15 ГБ.
DPM не вычисляет размер источника данных BMR, а резервирует 30 ГБ для любого сервера. Администраторы должны изменить это значение в соответствии с ожидаемым размером резервных копий для восстановления исходного состояния системы в конкретных средах

Размер резервной копии BMR может быть примерно равен сумме использованного пространства на всех критических томах: критические тома = загрузочный том + системный том + том с данными состояния системы, например Active Directory.
Обработка резервного копирования состояния системы

Защита BMR требует меньше дискового пространства на томе точки восстановления. Однако ее задействование не приводит к высвобождению дополнительного пространства. Вы можете уменьшить размер тома вручную в мастере изменения групп защиты (на странице Изменение выделения места на диске) или с помощью командлетов Get-DatasourceDiskAllocation и Set-DatasourceDiskAllocation.
Защите BMR потребуется больше дискового пространства на томе реплики. Том будет увеличен автоматически. Для изменения используемого по умолчанию распределения дискового пространства можно использовать командлет Modify-DiskAllocation.

Защита состояния системы требует больше дискового пространства на томе точки восстановления.
DPM может попытаться автоматически увеличить том. В случае недостатка дискового пространства в пуле носителей будет выведено сообщение об ошибке.
Для защиты состояния системы потребуется дисковое пространство на защищенном компьютере, так как защита состояния системы сначала записывает реплику на локальный компьютер, после чего передает ее на сервер DPM.

Общие сведения и ресурсы для устранения неполадок Active Directory репликации

Сбой входящей или исходящей репликации приводит к тому, что Active Directory объекты, представляющие топологию репликации, расписание репликации, контроллеры домена, пользователей, компьютеры, пароли, группы безопасности, членство в группах и групповая политика, будут несогласованными между контроллерами домена. Несогласованность каталогов и репликация приводят к сбоям или несогласованным результатам, в зависимости от контроллера домена, к которому обращается операция, и может помешать приложению групповая политика и разрешения на управление доступом. Домен Active Directory службы (AD DS) зависят от сетевого подключения, разрешения имен, проверки подлинности и авторизации, базы данных каталога, топологии репликации и механизма репликации. Если основная причина проблемы репликации не очевидна, определение причины из множества возможных причин требует систематического исключения вероятных причин.

для средства на основе пользовательского интерфейса, помогающего отслеживать репликацию и диагностировать ошибки, скачайте и запустите средство Microsoft помощник по поддержке и восстановлениюили используйте средство Состояние репликации Active Directory , если требуется только анализировать состояние репликации.

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

Сведения о том, как работает репликация Active Directory, см. в следующих технических справочниках:

• Технический справочник по модели репликации Active Directory
• Технический справочник по топологии репликации Active Directory

Обнаружение отката 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.

• Подкайка реестра:
• Запись реестра: Dsa Not Writable
• Значение: 0x4

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

Заключение

Неужели бэкап контроллера домена — это так просто? Да и нет. Успешный бэкап — это хорошее начало, но далеко не все. В Veeam говорят: «Резервная копия ничего не стоит, если из нее нельзя восстановить данные».

Следующие статьи в этой серии будут посвящены различным сценариям восстановления Active Directory, включая восстановление контроллера домена, а также восстановление отдельных удаленных и измененных объектов с помощью собственных инструментов Microsoft и Veeam Explorer для Active Directory.

Также вас может заинтересовать:

• Статья Восстановление объектов Active Directory
• Подробная информация о Veeam Explorer для Microsoft Active Directory