Замена контроллера домена. Перенос контроллера домена на новый сервер

Источник

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

Практически каждый администратор, работающий с серверами на базе Windows, рано или поздно сталкивается с необходимостью замены полностью устаревшего основного контроллера домена, дальнейший апгрейд которого больше не имеет смысла, на новый и более соответствующий современным требованиям. Бывают ситуации и хуже – контроллер домена просто-напросто приходит в негодность из-за поломок на физическом уровне, а резервные копии и образы устарели, или потерялись
В принципе, описание процедуры замены одного контроллера домена на другой можно найти на разных форумах, но информация даётся отрывками и, как правило, применима только к конкретной ситуации, однако фактического решения не даёт. Кроме того, даже вдоволь начитавшись форумов, баз знаний и прочих ресурсов на английском языке – я смог грамотно провести процедуру замены контроллера домена без ошибок только с третьего или четвёртого раза.
Таким образом, я хочу привести поэтапную инструкцию замены контроллера домена вне зависимости от того работоспособен он или нет. Единственная разница заключается в том, что при «упавшем» контроллере эта статья поможет только если вы заранее позаботились и развернули резервный контроллер домена.

Предварительная подготовка

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

Проверка разрешений для папки SysVol

Следующая процедура рекомендуется для применения на Windows 2003, но для Windows 2008 она тоже пригодна:

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

a.     В окне проводника Windows щелкните папку %SystemRoot%\Windows\Sysvol правой кнопкой мыши и выберите команду Свойства.

b.     На вкладке Безопасность нажмите кнопку Дополнительно, снимите флажок Переносить наследуемые от родительского объекта разрешения на этот объект и нажмите кнопку ОК. Убедитесь, что для выбранной папки установлены указанные ниже права, доступа и нажмите кнопку ОК.

Администраторы: полный доступ.
Прошедшие проверку: чтение, чтение и выполнение, список содержимого папки.
Создатель-владелец: никакие права не установлены явно.
Операторы сервера: чтение, чтение и выполнение, список содержимого папки.
System: полный доступ.

c.     В окне проводника Windows щелкните папку %SystemRoot%\Windows\Sysvol\Sysvol правой кнопкой мыши и выберите команду Свойства.

d.     На вкладке Безопасность нажмите кнопку Дополнительно, снимите флажок Переносить наследуемые от родительского объекта разрешения на этот объект и два раза нажмите кнопку ОК.

e.     Щелкните правой кнопкой мыши папку %SystemRoot%\Winnt\Sysvol\Sysvol\имя_домена и выберите команду Свойства.

f.      На вкладке Безопасность нажмите кнопку Дополнительно, снимите флажок Переносить наследуемые от родительского объекта разрешения на этот объект и два раза нажмите кнопку ОК.

g.     Щелкните правой кнопкой мыши папку%SystemRoot%\Winnt\Sysvol\Sysvol\имя_домена\Policies и выберите команду Свойства.

h.     На вкладке Безопасность нажмите кнопку Дополнительно, снимите флажок Переносить наследуемые от родительского объекта разрешения на этот объект и нажмите кнопку ОК. Убедитесь, что для выбранной папки установлены указанные ниже права доступа, и нажмите кнопку ОК.

Администраторы: полный доступ.
Прошедшие проверку: чтение, чтение и выполнение, список содержимого папки.
Создатель-владелец: никакие права не установлены явно.
Владельцы-создатели групповой политики: чтение, чтение и выполнение, список содержимого папки, изменение, запись.
Операторы сервера: чтение, чтение и выполнение, список содержимого папки.
System: полный доступ.

i.      Для всех файлов и папок, расположенных в папке %SystemRoot%\Winnt\Sysvol\Sysvol\имя_домена\Policies, выполните следующие действия. Щелкните файл или папку правой кнопкой мыши и выберите пункт Свойства.

j.      На вкладке Безопасность нажмите кнопку Дополнительно, установите флажок Переносить наследуемые от родительского объекта разрешения на этот объект и два раза нажмите кнопку ОК.

                Запустите оснастку «Active Directory - пользователи и компьютеры». Для этого нажмите кнопку Пуск и выберите в меню Все программы пункт Администрирование.

                Запустите оснастку «Active Directory - пользователи и компьютеры», разверните узел с именем домена, щелкните правой кнопкой мыши узел Контроллеры домена и выберите пункт Свойства.

                На вкладке Групповая политика выберите объект Политика контроллеров домена по умолчанию и нажмите кнопку Изменить.

Примечание. Если на компьютере установлена консоль управления групповыми политиками, кнопка «Изменить» будет недоступна. В этом случае нажмите кнопкуОткрыть, чтобы запустить консоль управления групповыми политиками, разверните узлы имя_домена и Контроллеры домена, щелкните правой кнопкой мыши элементПолитика контроллеров домена по умолчанию и выберите пункт Изменить.

Дополнительные сведения о консоли управления групповыми политиками см. на веб-узле Майкрософт по адресу:

http://www.microsoft.com/windowsserver2003/gpmc/default.mspx

                Последовательно раскройте следующие папки:

Конфигурация компьютера
Конфигурация Windows
Параметры безопасности
Локальные политики

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

                «Local Service»;

                «Network service»;

«Прошедшие проверку»;
«Все»;
«Администраторы».

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

                Нажмите кнопку Пуск, выберите пункт Выполнить, введите команду gpupdate и нажмите кнопку ОК.

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

Администраторы: полный доступ.
Прошедшие проверку: полный доступ.
Все: чтение.

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

1. Щелкните правой кнопкой мыши значок Мое сетевое окружение и выберите команду Свойства.
2. В меню Дополнительно выберите пункт Дополнительные параметры.
3. Убедитесь, что внутренний сетевой адаптер указан первым в списке Подключения. В противном случае передвиньте его в начало списка, используя кнопки со стрелками.

Проверка работоспособности и корректности работы контроллера домена

Для проверки корректности работы контроллера домена необходимо использовать утилиту dcdiag (для Windows 2003 она находится на установочном диске, для Windows 2008/R2 – она устанавливается вместе с системой):

Dcdiag /v /c /fix

Dcdiag /v /test:dcpromo /dnsdomain:my_domain /replicadc /fix

Dcdiag /v /test:dns /dnsall /fix

Nslookup

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

ntdsutil /metadata cleanup

Результатом работы этой команды будет удаление «мертвых душ» бывших или не получившихся контроллеров домена из Active Directory.

Подготовка леса и домена к появлению нового контроллера домена

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

Эти не хитрые операции проводятся с помощью утилиты adprep, которая находится на установочном диске ОС в каталоге Support. Эту утилиту обязательно надо брать с диска самой последней версии ОС из тех, на которых будут базироваться в дальнейшем  контроллеры домена!

Если дело касается Windows 2003 R2, то программу adprep необходимо брать со второго диска, а не с первого!

Операции подготовки необходимо выполнять в такой последовательности:

1.            Adprep /forestprep

2.            Adprep /domainprep

3.            Adprep /domainprep /gpprep

Подготовка серверов к повышению/понижению роли

Сама процедура создания резервного контроллера домена элементарна – мы просто запускаем на любом сервере сети мастер dcpromo. При помощи мастера dcpromo создаём контроллер домена в существующем домене. В результате проделанных манипуляций мы получаем развернутую службу каталогов AD на нашем дополнительном сервере (я буду называть его pserver, а основной контроллер - dcserver).
Дальше, если dcpromo сам не предложил – запускаем установку DNS сервера. Никаких настроек изменять не надо, зону создавать также не надо – она хранится в AD, и все записи автоматически реплицируются на резервный контроллер. Внимание – основная зона в DNS появится только после репликации, для ускорения которой сервер можно перезагрузить. В настройках TCP/IP сетевой карты резервного контроллера домена адресом первичного DNS сервера должен быть указан ip-адрес основного контроллер домена.
Теперь можно легко проверить работоспособность резервного контроллера домена pserver. Мы можем создать пользователя домена как на основном так и на резервном контроллере домена. Сразу после создания он появляется на дублирующем сервере, но примерно в течение минуты (пока происходит репликация) – он показан как отключенный, после чего начинает отображаться одинаково на обоих контроллерах.
На первый взгляд все действия по созданию исправной схемы взаимодействия нескольких контроллеров домена выполнены, и теперь, в случае выхода из строя «основного» контроллера домена, «резервные» контроллеры будут автоматически выполнять его функции. Однако, хотя разница между «основным» и «резервным» контроллерами домена чисто номинальная, «основной» контроллер домена имеет ряд особенностей (роли FSMO), о которых не стоит забывать. Таким образом, вышеприведенных операций для нормального функционирования службы каталогов при отказе «основного» контроллера домена не достаточно, и действия, которые надо произвести для грамотной передачи/захвата роли основного контроллера домена будут описаны ниже.

Немного теории

Нужно знать, что контроллеры домена Active Directory исполняют несколько видов ролей. Эти роли называются FSMO (Flexible single-master operations):
- Schema Master (Хозяин схемы) – роль отвечает за возможность изменения схемы – например разворачивания Exchange server или ISA server. Если владелец роли будет недоступен – схему существующего домена вы изменить не сможете;
- Domain Naming Master (Хозяин операции именования доменов) – роль необходима в том случае, если в вашем доменном лесу есть несколько доменов или поддоменов. Без неё не получится создавать и удалять домены в едином доменном лесу;
- Relative ID Master (Хозяин относительных идентификаторов) – отвечает за создание уникального ID для каждого объекта AD;
- Primary Domain Controller Emulator (Эмулятор основного контроллера домена) – именно он отвечает за работу с учётными записями пользователей и политику безопасности. Отсутствие связи с ним позволяет входить на рабочие станции со старым паролем, который нельзя сменить, если контроллер домена «упал»;
- Infrastructure Master (Хозяин Инфраструктуры) – роль отвечает за передачу информации об объектах AD прочим контроллерам домена в рамках всего леса.
Об этих ролях достаточно подробно написано во многих базах знаний, но основную роль практически всегда забывают – это роль Global Catalog (Глобального Каталога). По факту этот каталог просто запускает LDAP сервис на порту 3268, но именно его недоступность не позволит доменным пользователям входить в систему. Что примечательно – роль глобального каталога могут иметь все контроллеры домена одновременно.

Фактически можно сделать вывод – если у вас примитивный домен на 30-50 машин, без расширенной инфраструктуры, не включающий в себя поддомены - то отсутствие доступа к владельцу/владельцам первых двух ролей вы можете не заметить. Кроме того, мне несколько раз попадались организации, работающие больше года вообще без контроллера домена, но в доменной инфраструктуре. То есть все права были розданы давно, при работающем контроллере домена, и не нуждались в изменении, пароли пользователи себе не меняли и спокойно работали.

Определение текущих владельцев ролей fsmo

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

dsquery server –forest –hasfsmo schema
dsquery server –forest –hasfsmo name
dsquery server –forest –hasfsmo rid
dsquery server –forest –hasfsmo pdc
dsquery server –forest –hasfsmo infr
dsquery server –forest -isgc 

Каждая из команд выводит нам информацию о том, кто является владельцем запрашиваемой роли (рис.1).

Добровольная передача ролей fsmo при помощи консолей Active Directory

Вся информация, необходимая для передачи роли основного контроллера домена у нас есть. Приступаем: для начала нужно убедиться в том, что наша учётная запись входит в группы «Администраторы домена», «Администраторы схемы» и «Администраторы предприятия», а затем приступить к традиционному методу передачи ролей fsmo – управлением доменом через консоли Active Directory. 

Для передачи роли “хозяина именования домена” выполняем следующие шаги:

- открываем «Active Directory Домены и Доверие» на том контроллере домена, с которого мы хотим передать роль. Если мы работаем с AD на том контроллере домена, которому мы хотим передать роль, то следующий пункт пропускаем;

- щёлкаем правой кнопкой мыши на значке Active Directory — домены и доверие и выбираем команду Подключение к контроллеру домена. Выбираем тот контроллер домена, которому хотим передать роль;

- щелкаем правой кнопкой мыши компонент Active Directory — домены и доверие и выбираем команду Хозяева операций;

- в диалоговом окне Изменение хозяина операций нажимаем кнопку Изменить (рис. 2).

- после утвердительного ответа на всплывающий запрос получаем успешно переданную роль.

Аналогичным образом, при помощи консоли «Active Directory — пользователи и компьютеры» можно передать роли «хозяин RID», «основной контроллер домена» и «хозяин инфраструктуры».

Для передачи роли «хозяина схемы» необходимо предварительно зарегистрировать в системе библиотеку управления схемой Active Directory:

regsvr32 schmmgmt.dll

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

После того как все роли переданы остаётся разобраться с оставшейся опцией – хранителем глобального каталога. Заходим в Active Directory: «Сайты и Службы», сайт по умолчанию, сервера, находим контроллер домена, ставший основным, и в свойствах его NTDS settings ставим галочку напротив global catalog. (рис. 3)

Итог – мы поменяли хозяев ролей для нашего домена. Кому нужно окончательно избавиться от старого контроллера домена – понижаем его до рядового сервера. Однако простота проделанных действий окупается тем, что их выполнение в ряде ситуаций невозможно, или оканчивается ошибкой. В этих случаях нам поможет ntdsutil.exe.

Добровольная передача ролей fsmo при помощи консолей ntdsutil.exe

На случай, если передача ролей fsmo при помощи консолей AD не удалась, Microsoft создал очень удобную утилиту – ntdsutil.exe – программа обслуживания каталога Active Directory. Этот инструмент позволяет выполнять чрезвычайно полезные действия – вплоть до восстановления всей базы данных AD из резервной копии, которую эта утилита сама создала во время последнего изменения в AD. Со всеми её возможностями можно ознакомиться в базе знаний Microsoft (Код статьи: 255504). В данном случае мы говорим о том, что утилита ntdsutil.exe позволяет как передавать роли, так и «отбирать» их.

Если мы хотим передать роль от существующего «основного» контроллера домена к «резервному» – мы заходим в систему на «основной» контроллер и начинаем передавать роли (команда transfer).

Если у нас по каким-то причинам отсутствует основной контролер домена, или мы не можем войти под административной учетной записью – мы входим в систему на резервный контроллер домена и начинаем «отбирать» роли (команда seize).

Итак первый случай – основной контроллер домена существует и функционирует нормально. Тогда мы заходим на основной контроллер домена и набираем следующие команды:

ntdsutil.exe

roles

connections

connect to server имя_сервера (того кому хотим отдать роль)

q 

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

Полный список команд доступен после запроса fsmo maintenance стандартным знаком ? . Пришла пора передавать роли. Я сходу, не задумываясь, решил передавать роли в том порядке, в каком они указаны в инструкции к ntdsutil и пришёл к тому, что не смог передать роль хозяина инфраструктуры. Мне, в ответ на запрос о передаче роли, возвращалась ошибка: «невозможно связаться с текущим владельцем роли fsmo». Я долго искал информацию в сети и обнаружил, что большинство людей дошедших до этапа передачи ролей сталкиваются с этой ошибкой. Часть из них пытается отобрать эту роль принудительно (не выходит), часть оставляет всё как есть – и благополучно живёт без этой роли.

Я же путём проб и ошибок выяснил, что при передаче ролей в данном порядке гарантируется корректное завершение всех шагов:

- хозяин идентификаторов;

- хозяин схемы; 

- хозяин именования;

- хозяин инфраструктуры;

- контроллер домена;

После успешного подключения к серверу мы получаем приглашение к управлению ролями (fsmo maintenance), и можем начать передавать роли:

- transfer domain naming master

- transfer infrastructure master 

- transfer rid master

- transfer schema master 

- transfer pdc master

После выполнения каждой команды должен выходить запрос о том – действительно ли мы хотим передать указанную роль указанному серверу. Результат удачного выполнения команды показан на (рис.4).

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

Принудительное присваивание ролей fsmo при помощи ntdsutil.exe

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

seize naming master
seize infrastructure master
seize rid master
seize schema master
seize pdc

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

Работа над ошибками

Самое главное, о чём не следует забывать – новый основной контроллер домена сам себе настройки TCP/IP не исправит: ему адресом первичного DNS сервера теперь желательно (а если старый контроллер домена + DNS сервер будут отсутствовать, то обязательно) указать 127.0.0.1 .
При этом если у вас в сети есть DHCP сервер, то нужно заставить его выдавать адресом первичного DNS сервера ip вашего нового сервера, если DHCP нет – пройтись по всем машинам и прописать им этот первичный DNS вручную. Как вариант, можно назначить новому контроллеру домена тот же ip что был у старого.

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

Самым распространённым предупреждением, после передачи ролей fsmo, является сообщение о том, что «msdtc не может корректно обработать произошедшее повышение/понижение роли контроллера домена».
Исправляется просто: в меню «Администрирование» находим «Службы компонентов». Там раскрываем «Службы компонентов», «Компьютеры», открываем свойства раздела "Мой компьютер", ищем там "MS DTC" и жмем там "Настройки безопасности". Там разрешаем "Доступ к сети DTC" и давим ОК. Служба будет перезапущена и предупреждение исчезнет.

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

Разобраться в проблемах функционирования домена можно при помощи утилиты dcdiag (рис. 5):

Установить эту утилиту можно с оригинального диска Windows 2003 из папки /support/tools. Утилита позволяет проверить работоспособность всех служб контроллера домена, каждый её этап должен оканчиваться словами successfully passed. Если у вас выходит failed (чаще всего это тесты connection или systemlog) то ошибку можно попробовать вылечить в автоматическом режиме:

dcdiag /v /fix 

Как правило, все ошибки, связанные с DNS должны пропасть. Если нет – пользуемся утилитой проверки состояния всех сетевых служб:

netdiag

И её полезным инструментом устранения ошибок:

netdiag /v /fix 

Если и после этого остаются ошибки связанные с DNS – проще всего удалить из него все зоны и создать вручную. Это довольно просто – главное создать основную зону по имени домена, хранящуюся в Active Directory и реплицируемую на все контроллеры домена в сети.
Более подробную информацию об ошибках DNS даст ещё одна команда:

dcdiag /test:dns 

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

(Источник: http://zocomp.ru/index.php?option=com_content&view=article&id=53:-fsmo-&catid=34:articles&Itemid=55)
Оригинальная статья дополнена мной для исключения проблем, с которыми столкнулся я лично, когда переносил контроллер домена с Windows Server 2003 на Windows Server 2008R2.