Windows 2003 понизить роль контроллера домена

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

Пуск — Выполнить — dcpromo.exe, при запуске которой запускается мастер установки Active Directory

Картинка с сайта: www.itworkroom.com

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

Картинка с сайта: www.itworkroom.com

Что бы убрать функцию  глобального каталога, необходимо перейти в оснастку Active Directiry Sites and Services.

Картинка с сайта: www.itworkroom.com

Выбрать сервер, и войти в его свойства.

Картинка с сайта: www.itworkroom.com

Снять галку с Global Catalog. Об успешном отключении данной функции можно посмотреть в логах windows.

Картинка с сайта: www.itworkroom.com

Если мастер запущен уже после этой процедуры, предупреждения уже не будет. На данном этапе, мастеру установки Active Directory необходимо указать, является ли контролер домена последним в домене. Если поставить галку, на «сервер последний контроллер домена в данном домене» (This server is the last domain controller in the domain), то  контроллер домена становится изолированным сервером и все данные и настройки удаляются.

Картинка с сайта: www.itworkroom.com

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

Картинка с сайта: www.itworkroom.com

Завершающий шаг  запуска процесса понижения роли.

Картинка с сайта: www.itworkroom.com

Процесс удаления  Active Directory, понижение роли.

Картинка с сайта: www.itworkroom.com

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

Для того чтобы наделить статусом контроллера домена (Domain Controller, DC) сервер, функционирующий в среде Windows NT 4.0, или лишить его такого статуса, требуется полная переустановка сервера. Превратить сервер в DC можно лишь в процессе установки Windows. Подобное положение создает проблемы для администраторов, желающих изменить роль сервера таким образом, чтобы это не отражалось на функционировании других общих служб — ведь перспектива перенастройки системы «с чистого листа» вряд ли может показаться привлекательной. В среде Windows 2000 Server процесс повышения и понижения статуса сервера организован лучше, чем в среде Windows NT 4.0; администратор получает возможность превращать автономный сервер в контроллер домена с помощью утилиты Dcpromo. Понижение статуса сервера тоже легко выполняется с помощью Dcpromo, нужно только иметь возможность подключаться к функционирующему DC внутри данного домена.

Однако даже с учетом всех усовершенствований, внесенных в Windows 2000 Dcpromo (речь идет об изменениях, реализованных до выпуска пакета Service Pack 4, SP4), оставалась нерешенной одна проблема: для того, чтобы по всем правилам выполнить понижение статуса сервера с помощью утилиты Dcpromo, необходимо было иметь физическое соединение по сети с другим функционирующим DC. Нормальный ход процедуры понижения статуса мог быть нарушен и под воздействием других обстоятельств, например вследствие наличия в базе службы каталога дефектных объектов. Если же выполнить процедуру понижения статуса с соблюдением всех необходимых условий не представляется возможным, для удаления DC из инфраструктуры службы каталога опять-таки приходится полностью переустанавливать сервер и удалять все метаданные. Со времен Windows NT сохранилось еще одно ограничение, касающееся повышения статуса сервера: речь идет о требовании тиражировать все данные по сети. Возможность выполнить процедуру повышения статуса сервера с помощью сжатого файла или носителя, доставленного в удаленный офис, исключалась. В доменах, созданных до появления службы Active Directory (AD), такое тиражирование не вызывало затруднений, ведь на размеры баз данных SAM в этих версиях налагались серьезные ограничения. Но в системе AD объем одного только файла Directory Information Tree (DIT) может составлять более 10 Гбайт. В больших сетях, где реализована служба AD Windows 2000, процедура повышения статуса сервера глобального каталога (Global Catalog, GC), размещенного в одном из удаленных сегментов сети, может занять от 4 до 5 дней.

С появлением утилиты Dcpromo для системы Windows Server 2003 реализованный еще в Windows 2000 Server процесс повышения статуса сервера стал более эффективным. Теперь администратор может форсировать понижение статуса вне зависимости от того, имеется ли связь с доменом, и от состояния объектов данного DC. Версия Dcpromo, содержащаяся в пакете Windows 2000 SP4, тоже позволяет выполнять форсированное понижение статуса. Но есть основания полагать, что самая популярная функция утилиты Dcpromo системы Windows 2003 — это возможность создавать DC с помощью данных, сохраненных на внешнем носителе. Такой вариант создания DC — это, в сущности, управляемое восстановление резервной копии файла с данными о состоянии системы от другого DC Windows 2003. Такой носитель с резервными копиями позволяет создавать контроллеры доменов в удаленных узлах гораздо быстрее, чем в среде Windows 2000. Создавая DC на базе носителей данных с помощью Dcpromo Windows 2003, можно за несколько минут выполнить процедуру повышения статуса GC, на которую в среде Windows 2000 уходило от 4 до 5 дней. Время выполнения будет зависеть от «возраста» используемой резервной копии файла с данными о состоянии системы. Эти новые функции позволят не только сэкономить часы, которые пришлось бы потратить на полную перенастройку серверов, но и задействовать новые методы развертывания и восстановления данных после сбоя.

Применение Dcpromo с использованием внешних носителей

Реализованные в утилите Dcpromo Windows 2003 новые средства повышения статуса серверов с использованием носителей могут значительно расширить возможности администраторов в том, что касается восстановления работы сети после отказов DC, особенно в удаленных филиалах, где для создания нового DC могут потребоваться часы или даже дни работы, в зависимости от ширины полосы пропускания глобальной сети и размера соответствующего файла данных службы каталога. Кроме того, с помощью этих средств технические специалисты могут значительно сократить время развертывания служб AD в удаленных филиалах, а также сократить объем трафика, проходящего по каналам глобальных сетей при создании нового DC. Этот процесс можно использовать для формирования лишь копий контроллеров домена или серверов GC, и на обеих системах должны быть при этом установлены одни и те же исправления для операционной системы. Перед тем как приступить к формированию нового DC с помощью внешнего носителя, необходимо убедиться, что выполнен ряд условий. В частности, время, прошедшее с момента записи в резервный файл данных о состоянии системы, не должно превышать 60 дней. Дело в том, что 60 дней — это стандартный срок существования так называемых «меток на удаление». Срок существования меток на удаление — это период, в течение которого объекты сохраняются в каталоге, пока DC окончательно не удалит их оттуда. Если DC создается на базе резервного файла, существующего на протяжении более длительного времени, чем срок существования меток на удаление, то в базу данных каталога вновь будут введены все объекты, удаленные из него ранее.

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

В момент выполнения резервной копии состояние исходного DC должно быть безупречным. С помощью средств netdiag.exe и dcdiag.exe нужно убедиться, что журнал событий исходного DC не имеет записей и что данные DNS прописаны корректно. Тиражирование данных должно проходить гладко; в этом можно убедиться с помощью команды repadmin.exe /showrep1 /all. Необходимо удостовериться, что тиражирование файлов службой File Replication Service (FRS) выполняется без проблем; для этого следует провести испытания с использованием фиктивных файлов. Важно проследить, чтобы DC реагировал на запросы по протоколу Lightweight Directory Access Protocol (LDAP) и с помощью вызовов удаленных процедур. Общие ресурсы Netlogon и Sysvol DC должны быть доступны. Наконец, нужно убедиться в том, что файл DIT не слишком фрагментирован.

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

Основные этапы

Прежде всего потребуется с помощью программы NTBackup создать резервную копию данных о состоянии системы исправного DC (и, возможно, сервера GC), как показано на экране 1. Для этого нужно запустить утилиту NTBackup и после появления первого экрана щелкнуть на режиме Advanced Mode. На следующем экране необходимо перейти на закладку Backup и установить флажок System State. Лучше всего присвоить резервному файлу такое имя, в которое входило бы имя исходного сервера, а также дата резервного копирования, чтобы впоследствии можно было понять, во-первых, является ли данный сервер сервером GC, и, во-вторых, каков номер версии операционной системы. После ввода пути нужно щелкнуть на кнопке Start Backup. На следующем экране можно указать дополнительные параметры. Флажок Automatically back up system protected files with the system state («Автоматически копировать защищенные системные файлы, содержащие данные о состоянии системы») следует удалить, поскольку при использовании внешних носителей Dcpromo обходится без этих файлов. По завершении резервирования нужно обязательно просмотреть отчет: необходимо убедиться, что все важнейшие файлы скопированы. В случае сбоя следует снять все блокировки, мешающие копированию тех или иных файлов, и повторить процедуру. Если при этом функционирует служба NT File Replication System — NTFRS, весьма вероятно появление ошибки DO_NOT_REMOVE_NtFrs_PreInstall_Directory. На нее можно не обращать внимания. NTFRS использует данный каталог, однако создавать его копию не нужно.

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

Далее потребуется программа NTBackup, с помощью которой выполняется процедура восстановления файлов с использованием созданного резервного файла. Следует запустить утилиту NTBackup. Когда появится первый экран, нужно щелкнуть на кнопке Advanced Mode, затем перейти на закладку Restore and Manage Media. В меню Tools требуется выбрать элемент Catalog a backup file и в появившемся списке отыскать нужный резервный файл. Раскрыв каталог файлов, необходимо выставить флажок system state. Затем, руководствуясь экране 2, следует настроить NTBackup для восстановления файлов в другом месте. Я выбрал место на том же логическом накопителе, где хранится файл DIT. На экране 3 показаны компоненты, которые будут восстановлены в этой папке.

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

Далее следует запустить программу Dcpromo в режиме advanced mode с помощью команды dcpromo /adv. На экране выбора Domain Controller Type требуется указать переключатель Additional domain controller for an existing domain. На следующем экране (см. экран 4) в разделе Copy domain information нужно выбрать пункт From these restored backup files и указать папку с файлами копии для восстановления (она может располагаться, к примеру, по адресу F:system-state-backup estore).

На следующем экране можно превратить формируемый DC в сервер GC. Но такая возможность предоставляется лишь в том случае, если резервный файл был получен на сервере GC в том же домене. Но даже если упомянутый файл был создан именно на таком сервере, превращать новый DC в GC совсем не обязательно. Программа запросит доменную учетную запись, предоставляющую право создавать DC в данном домене. Затем она потребует указать пути расположения создаваемых журналов регистрации транзакций, базы данных каталога и общего ресурса Sysvol. Наконец, нужно будет ввести пароль для выполнения операции восстановления каталога — на случай, если в дальнейшем возникнет необходимость загрузить систему в режиме Directory Services Restore Mode для обслуживания каталога или для его восстановления.

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

Восстановление после сбоя

Тем, кто занимается составлением плана восстановления данных после аварийного сбоя, будет приятно узнать, что благодаря способности утилиты Dcpromo Windows 2003 создавать новые DC с помощью носителя данных, в этом деле открываются новые возможности. Надо сказать, что администраторы редко выполняют резервное копирование содержимого всех DC сети, поскольку данные, хранящиеся на всех DC одного домена, во многом совпадают. До того как на свет появилась Windows 2003, для восстановления вышедшего из строя DC, как правило, нужно было произвести установку сервера «с чистого листа» и затем, используя сеть, вновь придать ему статус DC (а возможно, и сервера GC). Процесс повышения статуса мог растягиваться на долгие часы, а то и дни — особенно в тех случаях, когда речь шла о повышении статуса DC до GC, сопряженном с дополнительным тиражированием предназначенных только для чтения контекстов именования, которые в больших сетях могут быть весьма объемными. На отдаленных сетевых узлах в эти дни могли отмечаться снижение скорости выполнения запросов по протоколу LDAP и, возможно, недоступность сервера DDNS. Не будем забывать и о том, что для завершения процесса повышения статуса пришлось перемещать огромные объемы данных по каналам глобальной сети. С помощью средств повышения статуса сервера, реализованных в утилите Dcpromo, можно с легкостью преодолеть такие препятствия, как испорченные файлы DIT или вышедшие из строя аппаратные компоненты, и времени на это уйдет во много раз меньше, чем того потребовала бы среда Windows 2000. Нужно просто восстановить сервер и вновь повысить его статус до прежнего состояния — DC или GC — с помощью резервной копии файла с данными о состоянии системы.

Как уже отмечалось выше, утилита Dcpromo Windows 2003 (или Windows 2000 с пакетом SP4) позволяет форсировать понижение статуса сервера даже в тех случаях, когда установить связь с доменом невозможно. Представим себе такую картину. Предположим, что на одном из DC входящие изменения не тиражировались в течение более чем 60 дней (т. е. стандартного срока существования меток на удаление). Синхронизировать такие DC по сети нежелательно, так как это влечет за собой реплицирование ранее удаленных объектов (объектов, удаленных на тех DC, которые функционировали корректно). В итоге в сети могут появиться так называемые неисчезающие объекты (lingering objects). Их называют также призраками (ghosts — в разделах «только для чтения») или зомби (zombies — в разделах, допускающих запись данных), ибо они как бы возвращаются «из царства мертвых». При попадании неисчезающих объектов в предназначенные только для чтения контексты именования могут возникать ситуации, когда задача обнаружения и удаления этих объектов становится трудноразрешимой. Само их существование может привести к остановке процесса репликации, поэтому нужно с особой тщательностью следить за тем, чтобы они не попадали в сеть. Команда Dcpromo /forceremove позволяет вновь сделать бывший DC автономным сервером, несмотря на невозможность взаимодействия с другими DC. Впоследствии благодаря реализованным в Dcpromo средствам повышения статуса сервера с помощью носителя информации можно быстро вернуть этому серверу актуальный статус DC. Нужно иметь в виду, что после выполнения процедуры форсированного понижения статуса или иной «нештатной» процедуры удаления DC придется очистить каталог от метаданных, а возможно, и удалить записи DNS. Этот процесс подробно описан в статье «HOW TO: Remove Data in Active Directory After an Unsuccessful Domain Controller Demotion» (http://support.microsoft.com/?kbid=216498).

Необходимо тщательно продумать вопрос о том, где размещать роли мастеров операций Flexible Single-Master Operation (FSMO), которые может выполнять и восстанавливаемый DC. Если по какой-либо причине возникнет необходимость понизить статус сервера, возможно, придется захватить одну из ролей FSMO, с тем чтобы лес или домен мог функционировать должным образом.

Резервное копирование по расписанию

Чтобы ускорить процесс восстановления контроллеров доменов, следует ежедневно осуществлять резервное копирование данных о состоянии системы по меньшей мере для одного сервера GC в каждом сайте AD, который содержит контроллер домена, для всех доменов. Для управления и назначения из одного центра расписания для большого числа сеансов резервного копирования DC можно использовать простые сценарии. Сценарии базируются на утилите командной строки schtasks.exe, которая в системах Windows 2003 и Windows XP размещается в каталоге %windir%system32. Подобно программе at.exe в Windows NT, утилита schtasks.exe позволяет дистанционно управлять расписанием задач. Однако schtasks.exe гораздо мощнее, чем at.exe. Если попытаться назначить расписание для резервирования систем, расположенных в доверенных доменах, и при этом для планировщика заданий задействовать учетную запись пользователя из доверенного домена, schtasks.exe не будет функционировать с данной учетной записью. Чтобы избежать такой ситуации, нужно запускать планировщик с системы, расположенной в том же домене, что и целевые системы, и использовать учетные записи служб из того же домена. Еще одно соображение: утилиту schtasks.exe нельзя использовать для создания расписания локальных операций резервного копирования в контексте учетной записи, отличной от учетной записи локально зарегистрировавшегося пользователя. Следовательно, для того чтобы программно управлять резервным копированием данных о состоянии системы, необходимо запустить SSBU-Control.bat на неиспользуемом сервере (например, на автономном сервере — члене домена). Этот сценарий содержится в листинге 1.

SSBU-Control.bat — это процесс, управляющий всем процессом развертывания и верификации резервных копий и планирования сеансов резервирования. Его задача состоит в том, чтобы проверять наличие расписаний заданий по «резервированию данных о состоянии системы» на любом количестве DC. Если расписания заданий нет, SSBU-Control.bat автоматически создает новое задание и регистрирует это событие в файле. Кроме того, сценарий предусматривает создание на целевом DC необходимой структуры папок и копирует на этот DC несколько файлов, необходимых для настройки сеанса резервного копирования. Далее сценарий проверяет, существует ли файл резервной копии данных о состоянии системы на каждом DC, и регистрирует детали — включая дату модификации файла — в главном файле для просмотра или для передачи регистрационных сведений по электронной почте. Допустим, на DC существует целевой каталог J:system-state-backupjob. В этом случае при выполнении сеанса резервного копирования по расписанию будет автоматически создан резервный файл J:system-state-backup.

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

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

• Следует скопировать и оптимизировать файл SSBU-Control.bat. Обязательно отредактируйте указанные в начале файла переменные с учетом особенностей конкретной сети. Я рекомендую не сохранять резервные копии на том же накопителе, где хранится база данных службы каталога. Тогда в случае отказа накопителя с DIT у вас останется резервный файл для восстановления.
• Необходимо создать командный файл ssbu.bat. Он представлен в дистинге 2 и включает в себя набор команд. SSBU-Control.bat автоматически скопирует этот командный файл на DC и запустит его на данном DC для выполнения резервного копирования локально. Переменная BKDrive в верхней части обязательно должна соответствовать буквенному обозначению целевого накопителя. Кроме того, нужно иметь в виду, что в данном файле резервирование назначено на 2 часа утра. Если этот срок не подходит, можно ввести в файл более удобное время.
• Следует создать служебную учетную запись в локальном домене с правами резервирования данных о состоянии системы и доступа к общему ресурсу, где будут храниться резервные копии. Командный файл ssbu.bat требует доступа к разделяемому ресурсу J$ на DC. Для модификации общего ресурса можно использовать переменные, указанные в начале файла ssbu.bat.
• На исходном сервере (т. е. на сервере, который планируется использовать для управления сеансами резервирования данных о состоянии системы) нужно создать папку C:scriptsssbu. Эта папка будет исходным каталогом.
• В исходном каталоге необходимо создать файл dclist.txt со списком DC, содержимое которых нужно резервировать. Каждая строка файла должна содержать имя только одного сервера. Можно использовать либо имена Fully Qualified Domain Names (FQDNs), либо имена NetBIOS; при этом предполагается, что в сети корректно выполняется разрешение и тех и других имен.
• Следует создать резервный файл с именем system-state-backup.bks. Для этого нужно запустить NTBackup и на первом экране нажать кнопку Advanced Mode. На следующем экране требуется перейти на закладку Backup и поставить флажок System State. В меню Job следует выбрать элемент Save Selection As и сохранить файл system-state-backup.bks в исходном каталоге. Этот файл известит программу NTBackup о том, что, собственно, нужно резервировать.
• Необходимо убедиться, что schtasks.exe находится либо в исходном каталоге, либо в пути поиска. Я пользовался программой schtasks.exe версии 5.1.2600.0 в SSBU-Control.bat. Эта версия функционирует в средах Windows 2003, Windows XP и Windows 2000.
• ?На управляющем сервере, где выполняется программа SSBU-Control.bat, нужно создать расписание сеанса резервного копирования, который будет осуществляться раз в сутки. Этот автоматизированный сценарий позволит спокойнее спать по ночам: вы будете знать, что расписание для сеансов резервного копирования создано и должным образом соблюдается. Если для какого-либо DC расписание не назначено, сценарий исправит ошибку и внесет регистрационную информацию в файл. Файл SSBU_JOB_STATUS.txt показывает состояние сеансов резервирования на всех DC, а в файле SSBU-Log.txt перечисляются все DC и копии файлов данных о состоянии систем. Таким образом, администратор может проверять, содержат ли резервные файлы все последние изменения и соответствуют ли они заданным размерам. Задача сводится к тому, чтобы ежедневно просматривать эти файлы.

С тех пор как на рынке появилась Windows NT, процедура повышения статуса DC претерпела существенные изменения. Средства форсированного понижения и повышения статуса серверов с помощью носителей данных открывают новые возможности управления развертыванием DC и GC, а также их восстановлением после сбоев. Эти новые функции в сочетании с возможностью развертывания и обслуживания сеансов копирования данных о состоянии системы из центрального узла сети с использованием программ NTBackup и schtasks.exe должны значительно упростить работу администратора.

Джесс Сутела — старший консультант в службе Managed Services в HP. Занимается проектированием и консультациями по вопросам сетевой инфраструктуры Windows. С ним можно связаться по адресу: jesse.sutela@hp.com

Принудительное понижение роли контроллеров домена с помощью мастера установки Active Directory в Windows Server 2003 или Windows 2000 Server выполняется неправильно

Проблема

Причина

Решение

Временное решение

Статус

Дополнительная информация

Мастер установки Active Directory предназначен для повышения роли компьютеров под управлением Windows 2000 и Windows Server 2003 до контроллеров домена в Active Directory. К числу выполняемых мастером операций относятся установка новых служб, изменение типа запуска существующих служб и применение действующих в Active Directory параметров безопасности и проверки подлинности.

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

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

• на момент понижения роли последнего контроллера в домене нет доступных контроллеров в родительском домене следующего уровня;
• работа мастера установки Active Directory не завершается из-за проблем с разрешением имен, проверкой подлинности, модулем репликации или зависимости объекта Active Directory даже после тщательного устранения неполадок;
• контроллер домена не реплицировал входящие изменения Active Directory как минимум для одного контекста именования в течение времени действия захоронения (по умолчанию — 60 дней);

  Внимание! Восстанавливать такой контроллер домена следует только в том случае, если нет других возможностей восстановления домена.

• нет времени на тщательный разбор и удаление неполадок, поскольку контроллер домена необходимо немедленно ввести в эксплуатацию.

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

Принудительное понижение роли контроллера домена приводит к потере локально хранимых в Active Directory на контроллере домена изменений, включая добавление, изменение и удаление пользователей, компьютеров, групп, доверительных отношений, групповой политики и конфигурации Active Directory, которые не были реплицированы до запуска команды dcpromo /forceremoval. Кроме того, удаляются изменения всех атрибутов таких объектов (например паролей для пользователей, компьютеров, доверительных отношений и членства в группах).

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

Выполнение принудительного понижения роли контроллера домена под управлением Windows 2000 (запуск команды dcpromo /forceremoval) приводит к регистрации события с кодом 29234 в журнале системных событий.

Тип события: Предупреждение
Источник события: lsasrv
Категория события: Отсутствует
Код события: 29234
Дата: ДД/ММ/ГГГГ
Время: ЧЧ:ММ:СС
Пользователь: Н/Д
Компьютер: computername Описание: Роль этого сервера была принудительно понижена. Он больше не является контроллером домена.

Выполнение принудительного понижения роли контроллера домена под управлением Windows Server 2003 приводит к регистрации события с кодом 29239 в журнале системных событий.

Тип события: Предупреждение
Источник события: lsasrv
Категория события: Отсутствует
Код события: 29239
Дата: ДД/ММ/ГГГГ
Время: ЧЧ:ММ:СС
Пользователь: Н/Д
Компьютер: computername Описание: Роль этого сервера была принудительно понижена. Он больше не является контроллером домена.

Выполнение команды dcpromo /forceremoval не приводит к удалению метаданных пониженного в роли контроллера домена на оставшихся контроллерах домена. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

216498  Удаление данных из Active Directory после неудачного понижения роли контроллера домена

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

1. Удалите из домена учетную запись компьютера.
2. Удалите оставшиеся DNS-записи, включая записи A, CNAME и SRV.
3. Удалите оставшиеся объекты члена FRS (FRS и DFS). Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

   296183  Обзор объектов Active Directory, используемых службой FRS (эта ссылка может указывать на содержимое полностью или частично на английском языке)

4. Если пониженный в роли компьютер являлся членом групп безопасности, удалите его из состава этих групп.
5. Удалите все ссылки DFS на пониженный в роли сервер, например связи и корневые реплики.
6. Если пониженный в роли контроллер домена обладал одной из ролей хозяина операций (FSMO), ее должен захватить оставшийся контроллер домена. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

   255504  Использование программы Ntdsutil.exe для присвоения и передачи контроллеру домена роли FSMO

7. Если понижаемый в роли контроллер домена является сервером DNS или сервером глобального каталога, для соблюдения параметров балансировки нагрузки, отказоустойчивости и конфигурации в лесу необходимо создать новый сервер такого же типа.
8. Выполнение в программе NTDSUTIL команды remove selected server приводит к удалению объекта NTDSDSA (родительский объект для входящих подключений к принудительно пониженному в роли контроллеру домена), однако родительский объект сервера в оснастке «Active Directory — сайты и службы» сохраняется. Если контроллер домена не будет введен в состав леса под тем же именем, удалите объект сервера с помощью оснастки «Active Directory — сайты и службы».

сурс

Проблема:
В некоторых случаях правильно понизить роль контроллера домена под управлением Windows 2000 или Windows Server 2003 с помощью мастера установки Active Directory (Dcpromo.exe) не удается
Причина:
Такое поведение наблюдается в случае сбоя определенной зависимости или операции, например подключения к сети, разрешения имен, проверки подлинности, репликации службы каталогов Active Directory или определения месторасположения критически важного объекта в Active Directory.
Решение:
Внимание! Предварительно убедитесь в наличии пароля для загрузки компьютера в режиме восстановления службы каталогов. В противном случае после понижения его роли войти в систему не удастся. Пароль для загрузки компьютера в режиме восстановления службы каталогов можно сбросить с помощью средства Setpwd.exe из папки Winnt\System32. В Windows Server 2003 функции средства Setpwd.exe интегрированы в команду Set DSRM Password (средство NTDSUTIL). Подробнее.
Из командной строки выполняем:

Соглашаемся со всем…
Примечание 1: На контроллере домена под управлением Windows 2000 с пакетом обновления 2 (SP2) или более высокой версии предварительно установите исправление Q332199 или пакет обновления 4 (SP4). В пакетах обновления, начиная с 2 (SP2), реализована поддержка принудительного понижения роли контроллеров домена.
Примечание 2: Пакет обновления Windows Server 2003 SP1 улучшает процесс dcpromo /forceremoval. При выполнении команды dcpromo /forceremoval осуществляется проверка, имеет ли контроллер домена роль хозяина операций, является сервером службы доменных имен (DNS) или сервером глобальных каталогов. Для каждой из этих ролей администратор получает всплывающее уведомление с указаниями по выполнению соответствующих действий.
Оригинал статьи