Как создать резервный контроллер домена. Добавление дополнительного контроллера домена в существующий домен AD. Установка роли ADDS
UPD: Создал видеоканал на youtube куда постепенно выкладываю обучающие видео по всем областям ИТ, в которых хорошо разбираюсь, подписывайтесь: http://www.youtube.com/user/itsemaev
UPD2: Микрософт традиционно меняет привычный синаксис в командной строке, поэтому роли в кажлый версии Windows Server могут звучать по-разному. Они вообще теперь не fsmo называются а operation masters. Так вот, для корректных команд в консоли после fsmo maintenance напишите просто? и он вам покажет доступные команды.
У меня в апрельский журнал "Системный администратор" взяли статью на тему "Безболезненная замена устаревшего или отказавшего контроллера домена на базе Windows Server"
И даже сто долларов заплатили и дали пакет с мозгами)) Я теперь Онотоле.
Безболезненная замена устаревшего или отказавшего контроллера домена на базе Windows Server.
(кому вдруг надо - картинки пришлю)
Если ваш контроллер домена вышел из строя или полностью устарел и требует замены - не спешите планировать провести ближайшие выходные за созданием нового домена на новом сервере и кропотливым переносом в него пользовательских машин. Грамотное управление резервным контроллером домена поможет быстро и безболезненно заменить предыдущий сервер.
Практически каждый администратор, работающий с серверами на базе Windows, рано или поздно сталкивается с необходимостью замены полностью устаревшего основного контроллера домена, дальнейший апгрейд которого больше не имеет смысла, на новый и более соответствующий современным требованиям. Бывают ситуации и хуже - контроллер домена просто-напросто приходит в негодность из-за поломок на физическом уровне, а резервные копии и образы устарели, или потерялись
В принципе, описание процедуры замены одного контроллера домена на другой можно найти на разных форумах, но информация даётся отрывками и, как правило, применима только к конкретной ситуации, однако фактического решения не даёт. Кроме того, даже вдоволь начитавшись форумов , баз знаний и прочих ресурсов на английском языке - я смог грамотно провести процедуру замены контроллера домена без ошибок только с третьего или четвёртого раза.
Таким образом, я хочу привести поэтапную инструкцию замены контроллера домена вне зависимости от того работоспособен он или нет. Единственная разница заключается в том, что при «упавшем» контроллере эта статья поможет только если вы заранее позаботились и развернули резервный контроллер домена.
Подготовка серверов к повышению/понижению роли
Сама процедура создания резервного контроллера домена элементарна - мы просто запускаем на любом сервере сети мастер 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 -hasfsmo schema
dsquery server - hasfsmo name
dsquery server - hasfsmo rid
dsquery server - hasfsmo pdc
dsquery server - hasfsmo infr
dsquery server -forest -isgc
Каждая из команд выводит нам информацию о том, кто является владельцем запрашиваемой роли (рис.1). В нашем случае владелец всех ролей - основной контроллер домена dcserver.
Добровольная передача ролей fsmo при помощи консолей Active Directory.
Вся информация, необходимая для передачи роли основного контроллера домена у нас есть. Приступаем: для начала нужно убедиться в том, что наша учётная запись входит в группы «Администраторы домена», «Администраторы схемы» и «Администраторы предприятия», а затем приступить к традиционному методу передачи ролей fsmo - управлением доменом через консоли Active Directory.
Для передачи роли “хозяина именования домена” выполняем следующие шаги:
- открываем «Active Directory Домены и Доверие» на том контроллере домена, с которого мы хотим передать роль. Если мы работаем с AD на том контроллере домена, которому мы хотим передать роль, то следующий пункт пропускаем;
- щёлкаем правой кнопкой мыши на значке Active Directory — домены и доверие и выбираем команду Подключение к контроллеру домена. Выбираем тот контроллер домена, которому хотим передать роль;
- щелкаем правой кнопкой мыши компонент Active Directory — домены и доверие и выбираем команду Хозяева операций;
- в диалоговом окне Изменение хозяина операций нажимаем кнопку Изменить (рис. 2).
- после утвердительного ответа на всплывающий запрос получаем успешно переданную роль.
Аналогичным образом, при помощи консоли «Active Directory — пользователи и компьютеры» можно передать роли «хозяин RID», «основной контроллер домена» и «хозяин инфраструктуры».
Для передачи роли «хозяина схемы» необходимо предварительно зарегистрировать в системе библиотеку управления схемой 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 domain 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 сервер не видит контроллер домена.
Разобраться в проблемах функционирования домена можно при помощи утилиты (рис. 5):
Установить эту утилиту можно с оригинального диска Windows 2003 из папки /support/tools. Утилита позволяет проверить работоспособность всех служб контроллера домена, каждый её этап должен оканчиваться словами successfully passed. Если у вас выходит failed (чаще всего это тесты connection или systemlog) то ошибку можно попробовать вылечить в автоматическом режиме:
dcdiag /v /fix
Как правило, все ошибки, связанные с DNS должны пропасть. Если нет - пользуемся утилитой проверки состояния всех сетевых служб:
И её полезным инструментом устранения ошибок:
netdiag /v /fix
Если и после этого остаются ошибки связанные с DNS - проще всего удалить из него все зоны и создать вручную. Это довольно просто - главное создать основную зону по имени домена, хранящуюся в Active Directory и реплицируемую на все контроллеры домена в сети.
Более подробную информацию об ошибках DNS даст ещё одна команда:
dcdiag /test:dns
По окончанию проделанных работ у меня ушло ещё где-то 30 минут на выяснение причины появления ряда предупреждений - я разобрался с синхронизацией времени, архивацией глобального каталога и прочими вещами, до которых раньше не доходили руки. Теперь всё работает как часы - самое главное не забудьте завести резервный контроллер домена, если вы хотите удалить старый контроллер домена из сети.
Следует установить и настроить второй, дополнительный контроллер домена. Это необходимо для того, чтобы в случае потери связи или выхода из строя первого контроллера домена, добавочный контроллер домена смог обрабатывать запросы пользователей. Тогда работа в сети будет безостановочной, в случае проблем одного из контроллеров, второй будет выполнять все те же функции.
Установка и настройка второго контроллера домена.
1. На первом контроллере домена открываем сетевые настройки первого сервера. Для этого в поле поиска набираем ncpa.cpl. Далее выбираем нужный сетевой интерфейс, правый клик - "Свойства - IP версии 4(TCP/IPv4). - Свойства". В поле альтернативный интерфейс, вписываем IP-адрес добавочного контроллера домена (в данном случае 192.168.100.6).
2. Затем переходим на второй сервер и задаём имя будущему серверу: "Этот компьютер - Свойства - Изменить параметры - Изменить". В поле "Имя компьютера" задаём имя серверу, далее "ОК". Потребуется перезагрузка компьютера, соглашаемся.
3. После перезагрузки переходим к настройке сетевого интерфейса. Для этого в поле поиск пишем ncpa.cpl. Выбираем нужный интерфейс, правый клик - "Свойства - IP версии 4(TCP/IPv4). - Свойства". В открывшемся окне заполняем поля:
- IP-адрес : IP-адрес сервера (например, 192.168.100.6)
- Маска подсети : например, 255.255.255.0 (маска 24 бит)
- Основной шлюз : например, 192.168.100.1
- Предпочитаемый DNS-сервер : IP-адрес первого сервера (например, 192.168.100.5)
- Альтернативный DNS-сервер : IP-адрес второго сервера (например, 192.168.100.6)
Затем нажимаем "ОК".
4. Добавляем в домен новый сервер. Для этого выбираем "Этот компьютер - Свойства - Изменить параметры - Изменить". Ставим чекбокс "Является членом домена" и вписываем имя домена. Затем "ОК".
5. В диалоге "Изменение имени компьютера или домена" вводим имя пользователя домена с административными правами (пользователь должен иметь возможность добавлять компьютеры в домен), далее "ОК".
6. При успешной операции появится надпись "Добро пожаловать в домен...". Нажимаем "ОК".
7. После перезагрузки компьютера в окне "Просмотр основных сведений о вашем компьютере" можно проверить напротив "Полное имя", что компьютер вошел в состав домена.
8. На этом подготовительный этап закончен, пора устанавливать необходимые роли на сервер. Для этого открываем "Диспетчер серверов" - "Добавить роли и компоненты". Необходимо установить DNS-сервер, Доменные службы Active Directory, DHCP-сервер.
9. Читаем информацию в окне "Перед началом работы", нажимаем "Далее". В следующем окне "Выбор типа установки" оставляем чекбокс "Установка ролей или компонентов" по умолчанию, снова "Далее". Выбираем наш сервер из пула серверов, затем "Далее".
10. В окне "Выбор ролей сервера" выбираем DNS-сервер, Доменные службы Active Directory, DHCP-сервер. При добавлении роли будет появляться предупреждение, например "Добавить компоненты, необходимые для DHCP-сервер". Нажимаем "Добавить компоненты". После выбора нужных ролей нажимаем "Далее".
11. В новом окне "Выбор компонентов" игнорируем "Выберите один или несколько компонентов для установки на этом сервере", нажимаем Далее. В следующем окне "DHCP-сервер" читаем на что обратить внимание при установке DHCP-сервера, затем "Далее". В новом окне "Подтверждение установки" проверяем выбранные роли, нажимаем "Установить".
12. Появится окно с ходом установки выбранных компонентов. Данное окно можно закрыть, оно на процесс установки уже не влияет.
13. После того, как установятся выбранные компоненты, в "Диспетчер серверов" нажимаем значок предупреждения в виде восклицательного знака, выбираем "Повысить роль этого сервера до уровня контроллера домена".
14. Появится "Мастер настройки доменных служб Active Directory". В окне "Конфигурация развертывания" оставляем по умолчанию чекбокс "Добавить контроллер домена в существующий домен", проверяем название домена в поле "Домен". Напротив поля (текущий пользователь) нажимаем кнопку "Изменить".
15. Вводим логин и пароль пользователя в домене с административными правами. Нажимаем "ОК". Затем "Далее".
16. В окне "Параметры контроллера домена" вводим парль для режима восстановления служб каталогов (DSRM), снова "Далее".
17. В окне "Параметры DNS" игнорируем предупреждение о том, что делегирование для этого DNS-сервера невозможно создать, поскольку полномочная родительская зона не найдена", просто жмем "Далее".
18. В окне "Дополнительные параметры" источник репликации оставляем "Любой контроллер домена", снова "Далее".
19. Расположение базы данных AD DS, файлов журналов и папки SYSVOL оставляем по умолчанию, нажимаем "Далее".
20. Просматриваем параметры, настроенные в "Мастер настройки доменных служб Active Directory", затем "Далее".
21. В окне "Проверка предварительных требований" проверяем, что появился зеленый чекбокс. Таким образом все проверки готовности к установке выполнены успешно. Нажимаем "Установить".
22. В следующем окне читаем, что "Этот сервер успешно настроен как контроллер домена". Читаем предупреждения, нажимаем "Закрыть".
23. Пришло время проверить работоспособность Доменных служб Active Directory и DNS-сервера. Для этого открываем "Диспетчер серверов".
24. Выбираем "Средства" - "Пользователи и компьютеры Active Directory".
25. Открываем наш домен и раскрываем подразделение "Domain Controllers". В окне напротив проверяем наличие второго сервера как контроллера домена.
27. Проверяем наличие IP-адреса второго сервера в зоне прямого и в зоне обратного просмотра.
28. Затем выбираем "Active Directory - сайты и службы".
29. Раскрываем дерево "Active Directory - сайты". Проверяем наличие второго контроллера домена напротив "Servers".
30. Пришло время настроить DHCP-сервер. Для этого на втором сервере выбираем в "Диспетчер серверов" - "Средства" - "DHCP".
31. Выбираем добавочный сервер, правой клавишей мыши - "Добавить или удалить привязки".
32. Проверяем настройку сетевого интерфейса, через который будут обслуживать DHCP-клиенты на втором сервере.
33. Объединяем два DHCP-сервера. Конфигурация высокой доступности, режим балансировка высокой нагрузки. Распределяем нагрузку на сервера 50x50. Для настройки на первом сервере, где установлен и настроен DHCP-сервер, выбираем "Диспетчер серверов" - "Средства" - "DHCP".
34. Правый клик на созданную в DHCP-сервере область, далее "Настройка отработки отказа...".
35. Появится мастер "Настройка отработки отказа", затем "Далее".
36. Указываем сервер-партнер для отработки отказа. Для этого в поле "Сервер партнер" с помощью кнопки "Добавить сервер" добавляем второй (дополнительный) сервер, на котором развернута роль DHCP-сервер. Затем нажимаем "Далее".
37. В поле "Общий секрет" вписываем пароль. Остальные настройки можно оставить по умолчанию, в том числе процент распределения нагрузки Локальный сервер - Сервер партнер - 50% на 50%. Снова "Далее".
38. Проверяем параметры настройки отработки отказа между первым сервером и дополнительным сервером. Нажимаем "Готово".
39. Смотрим в ходе настройки отработки отказа, чтобы все было "Успешно" и закрываем мастер.
40. Открываем второй сервер. "Диспетчер серверов" - "Средства" - "Авторизовать".
41. Проверяем "Пул адресов". Будет произведена синхронизация DHCP-серверов.
На этом процесс установки и настройки Active Directory, DHCP, DNS закончен. Посмотреть, что и как делать, можно здесь:
Как вы знаете, службы Active Directory Domain Services (AD DS) устанавливаются на сервере, который называется контроллер домена (DC). В активный каталог домена AD можно добавить десятки дополнительных контроллеров для балансировки нагрузки, отказоустойчивости, уменьшения нагрузки на WAN каналы и т.д. Все контроллеры домена должны содержать одинаковую базу учетных записей пользователей, учетных записей компьютеров, групп и других объектов LDAP каталога.
Для корректной работы всем контроллерам домена необходимо синхронизироваться и копировать информацию между собой. Когда вы добавляете новый контроллер домена в существующий домен, контроллеры домена должны автоматически синхронизировать данные между собой. Если новый контроллер домена и существующий DC находятся в одном сайте, они могут легко реплицировать данные между собой. Если новый DC находится на удаленном сайте, то автоматическая репликация не так эффективна. Поскольку репликация будет идти через медленные (WAN каналы), которые как правило стоят дорого и скорость передачи данных по ним не велика.
В этой статье мы покажем, как добавить дополнительный контроллер домена в существующий домен Active Directory ().
Добавление дополнительного контроллера домена в существующий домен AD
Прежде всего, нам нужно установить роль Active Directory Domain Services на сервере, который будет новым DC.
Установка роли ADDS
Прежде всего, откройте консоль Server Manager. Когда откроется Server Manager, нажмите «Add roles and features», чтобы открыть консоль установки ролей сервера.
Пропустите страницу «Before you Begin». Выберите «Role-based or featured-based installation» нажмите кнопку «Next». На странице «Server Selection» снова нажмите кнопку «Next».
Выберите роль Active Directory Domain Services . В открывшемся окне нажмите кнопку «Add Features», чтобы добавить необходимые инструменты управления Active Directory Management Tools.
Когда процесс установки будет завершен, перезагрузите сервер, войдите в систему под администратором и выполните следующие действия.
Настройка дополнительного контроллера домена
Теперь в мастере установки ролей нажмите ссылку «Promote this server to a domain controller ».
Выберите «Add a domain controller to an existing domain», ниже укажите имя вашего домена AD. Если вы авторизованы под обычным пользователем, вы можете изменить учетные данные на администратора домена. Нажмите кнопку «Select», откроется новое окно, выберите имя вашего домена и нажмите «Ok», затем «Next».
На странице Domain Controller Options, можно выбрать, что нужно установить роль DNS-сервера на вашем DC. Также выберите роль Global Catalog. Введите пароль администратора для режима DSRM и подтвердите его, затем нажмите кнопку «Next».
На странице Additional options укажите сервер, с которым вы хотите выполнить первоначальную репликацию базы Active Directory (с указанного сервера будет скопирована схема и все объекты каталога AD). Вы можете сделать снимок (snapshot) текущего состояния Active Directory на одном из контроллеров домена и применить его на новой машине. После этого база AD этого сервера будет представлять собой точную копию имеющегося контроллера домена. Подробнее о функции Install From Media (IFM) – установки нового DC с носителя в одной из следующих статей ():
На страницах «Paths and Review options» нам ничего не придется настраивать, пропустите их, нажав кнопку «Next». На странице «Prerequisite», если вы видите какую-либо ошибку, проверьте и выполните все указанные требования, затем нажмите кнопку «Install».
Настройка репликации между новым и имеющимся контроллером домена
Мы почти закончили, теперь проверим и запустим репликацию между первичным DC (DC01..сайт). При копировании информации между этими двумя контроллерами домена данные базы Active Directory будут скопированы из DC01..сайт. После завершения процесса все данные корневого контроллера домена появятся на новом контроллере домена.
В «Server Manager» выберите вкладку «Tools» затем пункт «Active directory sites and services».
В левой панели разверните вкладку Sites -> Default-First-Site-Name -> Servers. Оба новых DC находятся в одном сайте AD (это подразумевает, что они находятся в одной подсети, либо сетях, соединенных высокоскоростным каналом связи). Затем выберите имя текущего сервера, на котором вы сейчас работаете, затем нажмите «NTDS Settings». В моем случае DC01 является корневым контроллером домена, в данный момент консоль запущена на DC02, который будет дополнительным контроллером домена.
Щелкните правой кнопкой мыши по элементу с именем «automatically generated». Нажмите «Replicate now». Появится предупреждение о запуске репликации между корневым контроллером домена и новым контроллером домена.
Сделайте то же самое для DC01. Разверните вкладку DC01 и нажмите «NTDS Settings». Щелкните правой кнопкой мыши на «automatically generated», затем нажмите «Replicate now». Оба сервера реплицируются друг с другом, и все содержимое DC01 будет скопировано в DC02.
Задача состоит в передаче ролей c основного контроллера домена Windows Server 2008 с Active Directory (AD) на резервный контроллер домена Windows Server 2012. Резервный контроллер домена (DCSERVER) должен стать основным, а тот, который сейчас основной (WIN-SRV-ST) должен стать резервным и в перспективе демонтироваться. Все действия выполняются на резервном сервере DCSERVER. Оба сервера работоспособны и «видят» друг друга.
Перед началом передачи ролей необходимо проверить, какой из серверов является хозяином ролей. Для этого вызываем командную строку Win+R >> cmd и вводим команду:
netdom query fsmo – запрос на определение хозяина ролей FSMO
По результату выполнения команды видно, что хозяин всех ролей контроллер домена, который у нас называется Win-srv-st, он сейчас основной.
Краткая справка:
FSMO (англ. Flexible single-master operations - «операции с одним исполнителем») - типы выполняемых контроллерами домена AD операций, требующие обязательной уникальности сервера, выполняющего данные операции (wiki). Это значит, что данные роли могут быть только на одном контроллере домена.
Хозяин схемы (Schema Master) – отвечает за возможность изменения существующей схемы AD (например добавление Exchange и тп.)
Хозяин именования доменов (Domain Naming Master) – добавляет/убавляет домены (если их несколько в одном лесу).
PDC (Primary Domain Controller Emulator) — эмулятор основного контроллера домена. Отвечает за смену паролей их репликацию, изменение групповой политики, синхронизацию время и совместимость с ранними версиями Windows.
Диспетчер пула RID (Relative ID Master) – создает ID для каждого объекта AD.
Хозяин инфраструктуры (Infrastructure Master) – передает информацию об объектах AD между другими контроллерами домена (например, когда пользователи из одного домена попали в соседний).
Есть еще одна очень важная роль – Global Catalog (GC) – хотя она не является FSMO т.к. её держателем могут быть несколько DC одновременно, без неё невозможно нормальное функционирование домена и его служб. GC хранит у себя копии всех объектов AD и частичные реплики других доменов леса. Он позволяет находить пользователям и приложениям объекты в любом домене существующего леса, отвечает за проверку подлинности имени пользователя, предоставляет сведения о членстве пользователя в универсальных группах, может общаться с другим доменным лесом.
Учетная запись должна как минимум входить в группы:
— администраторы домена;
— администраторы предприятия;
— администраторы схемы.
Передача ролей хозяина операций RID , PDC и Инфраструктуры.
Нажимаем правой кнопкой мыши на имя домена в каталоге и выбираем пункт – Хозяева операций…
В открывшемся окне видим, что хозяином во всех трех вкладках RID, PDC и Инфраструктура является Win-Srv-St.SCRB.local. Ниже написано: Чтоб передать роль хозяина операций следующему компьютеру, нажмите кнопку «Изменить». Убеждаемся что в самой нижней строчке имя сервера, которому мы хотим передать роль хозяина и жмем изменить. Делаем это же на всех трех вкладках.
В появившемся вопросе подтверждения жмем Да.
Роль хозяина успешно передана. ОК. Хозяином операций стал DCSERVER.SCRB.local.
Делаем то же самое на оставшихся двух вкладках PDC и Инфраструктура.
Передача роли «Хозяин именования доменов».
Выбираем в AD DS нашего сервера пункт Active Directory – домены и доверие.
Правой кнопкой мыши жмем по названию и выбираем, как и ранее, строчку Хозяин операций…
Проверяем имена серверов, нажимаем изменить.
Хозяином операций стал DCSERVER.
Передача роли «Хозяин схемы».
Первоначально зарегистрируем в системе библиотеку управления схемой AD с помощью команды regsvr32 schmmgmt.dll
Нажимаем WIN+R >> cmd
Вводим команду и получаем ошибку: Модуль «schmmgmt.dll загружен, но не удалось выполнить вызов DLLRegisterServer, код ошибки: 0x80040201.
Ошибка, потому что командную строку нужно запускать от имени администратора. Сделать это можно, например из меню Пуск. Выбираем командную строку и нажимаем запуск от имени администратора.
Еще раз вводим команду regsvr32 schmmgmt.dll. Теперь всё прошло как нужно.
Нажимаем WIN+R, пишем mmc
В открывшейся консоли выбираем Файл >> Добавить или удалить оснастку… (или жмем CTRL+M)
Среди доступных оснасток выбираем Схема Active Directory, нажимаем добавить. ОК.
В корне консоли выбираем добавленную оснастку, нажимаем на неё правой кнопкой мыши и выбираем строчку «Хозяин операций…»
Текущим хозяином схемы значится Win-Srv-St.SCRB.local. В нижней строчке тоже его имя.
При нажатии кнопки «Сменить» появляется сообщение: Текущий контроллер домена Active Directory является хозяином операций. Чтоб передать роль хозяина другому DC, нужно нацелить на этот DC схему Active Directory.
Возвращаемся к оснастке и выбираем ПКМ Сменить контроллер домена Active Directory.
В открывшемся окне выбираем нужный сервер. В нашем случае DCSERVER.SCRB.local. ОК.
Консоль выдаст сообщение: Оснастка схемы Active Directory не подключена к хозяину операций схемы. Выполнение изменений невозможно. Изменения схемы могут быть сделаны только в схеме владельца FSMO.
При этом в названии оснастки появился нужный нам сервер.
Снова жмем на неё правой кнопкой мыши и переходим к хозяину операций. Проверяем названия серверов, жмем кнопку «Сменить».
Роль хозяина операций успешно передана. ОК.
Для того, чтоб убедиться в передаче ролей, введем еще раз в командной строке netdom query fsmo
Хозяином ролей теперь является DCSERVER.SCRB.local.
Глобальный каталог.
Чтоб уточнить, где расположен GC нужно пройти по пути: AD – Сайты и службы >> Sites >>Default-First-Site-Name >> Servers >> DCSERVER
В появившейся службе NTDS Settings жмем ПКМ и выбираем – Свойства.
Если стоит галочка напротив надписи Глобальный каталог, то значит что он на этом сервере. А вообще, в нашем случае GC расположен на обоих DC.
Настройка DNS .
В настройке DNS нового основного DC пишем вот что:
В первой строчке IP адрес бывшего основного DC (Win-Srv-St), который теперь стал резервным 192.168.1.130.
Во второй строчке 127.0.0.1 т.е. самого себя (можно и свой IP написать, чтоб по конкретнее).
В том контроллере домена который у нас стал резервным записано так:
В первой строчке IP основного DC.
Во второй строчке свой IP. Все работает.
DHCP у нас в сети не работает по причине местных обстоятельств, по этому перенастраивать его не нужно. Зато нужно пройти 200 ПК и вручную прописать новый DNS. По этой причине решено пока что не демонтировать старый контроллер домена. За полгода планомерных обходов DNS у пользователей поменяются.
Microsoft Active Directory является стандартом в инфраструктуре, где требуется аутентификация пользователей и централизованное управление. Почти невозможно представить себе, как системные администраторы справлялись бы со своей работой без этой технологии. Однако использование Active Directory не только приносит большую пользу, но и налагает большую ответственность, требуя значительного времени и понимания процессов работы. Поэтому я предлагаю вашему вниманию несколько cтатей, которые расскажут, как успешно выполнять бэкап и восстановление Active Directory с помощью решений Veeam. В частности, я поясню, как Veeam помогает делать копии контроллеров домена (DC) или отдельных объектов AD и при необходимости восстановить их.
А начну я с того, что в сегодняшнем посте расскажу о возможностях бэкапа физических и виртуальных контроллеров домена, предоставляемых Veeam, и о том, что необходимо помнить во время бэкапа. За подробностями - под кат.
Сервисы Active Directory разработаны с учетом избыточности, поэтому привычные правила и тактики бэкапа необходимо адаптировать соответствующим образом. В данном случае будет неправильно использовать ту же политику бэкапа, что уже работает для серверов SQL или Exchange. Вот несколько рекомендаций, которые могут помочь при разработке политики бэкапа для Active Directory:
- Выясните, какие контроллеры домена в вашей среде выполняют роли FSMO (Flexible Single Master Operations).
Полезно: простая команда для проверки через командную строку: >netdom query fsmo
Выполняя полное восстановление домена, лучше начать с контроллера домена с наибольшим числом ролей FSMO - обычно это сервер с ролью эмулятора основного контроллера домена (PDC). В противном случае после восстановления вам придется переназначать соответствующие роли вручную (при помощи команды ntdsutil seize). - Если вы хотите защитить отдельные объекты, то у вас нет необходимости в бэкапе всех контроллеров, имеющихся на продакшен-площадке. Для восстановления отдельных объектов будет достаточно одной копии базы данных Active Directory (файл ntds.dit).
- Всегда есть возможность снизить риск случайного или намеренного удаления или изменения объектов AD. Можно порекомендовать делегирование административных полномочий, ограничение доступа с повышенными правами, а также репликацию на резервную площадку с предустановленной задержкой.
- Обычно рекомендуется выполнять бэкап контроллеров доменов поочередно и так, чтобы оно не пересекалось с репликацией DFS. Хотя современные решения знают, как решать эту проблему.
- Если вы используете виртуальную среду VMware, контроллер домена может быть недоступен по сети (например, он находится в зоне DMZ). В этой ситуации Veeam переключится на соединение через VMware VIX и сможет обработать этот контроллер.
Если у вас виртуальный DC
Так как сервисы Active Directory потребляют малую часть ресурсов системы, то контроллеры домена обычно становятся первыми кандидатами для виртуализации. Чтобы защитить виртуализованный контроллер с помощью Veeam, нужно установить и настроить Veeam Backup & Replication.Важно!
Решение работает с ВМ контроллера домена на Windows Server 2003 SP1 и выше, минимальный поддерживаемый функциональный уровень леса - Windows 2003. Учетной записи нужно предоставить права администратора Active Directory –- можно работать под учетной записью администратора предприятия или домена.
Процесс установки и настройки Veeam Backup & Replication уже неоднократно освещался – например, в видео, подготовленном системным инженером Veeam, поэтому обойдемся без подробностей. Предположим, что все настроено и готово к работе. Теперь нужно создать задание бэкапа контроллера домена. Процесс настройки довольно прост:
Резервную копию можно дополнительно сохранить в облако с помощью поставщика услуг Veeam Cloud Connect (VCC). Также ее можно перенести в другой репозиторий резервных копий, используя задания архивирования резервных копий или функционал архивирования на магнитную ленту. Самое главное, что теперь резервная копия хранится в надежном месте, и из нее в любой момент можно восстановить нужные данные.
Если у вас физический DC
Честно говоря, я надеюсь, что вы идете в ногу со временем, и в вашей компании контроллеры домена давно виртуализованы. Если это не так, то надеюсь, что вы их регулярно обновляете и они работают на относительно современных версиях ОС Windows Server -Windows Server 2008 (R2) и выше. (О нюансах работы с более старыми системами будет отдельная статья).Итак, у вас есть один или несколько физических контроллеров домена, работающих под Windows Server 2008 R2 и выше, и вы хотите их защитить. В этом случае вам потребуется Veeam Endpoint Backup - решение, предназначенное специально для защиты данных физических компьютеров и серверов. Veeam Endpoint Backup копирует нужные данные с физической машины и сохраняет их в файл резервной копии. В случае аварии вы сможете восстановить данные «на голое железо» или выполнить восстановление на уровне логического диска. Кроме того, вы сможете восстанавливать отдельные объекты с помощью Veeam Explorer для Microsoft Active Directory.
Делаем следующее:
Вот и все: бэкап выполнен, контроллер домена под защитой. Перейдите в репозиторий и найдите нужную резервную копию или цепочки резервных копий.
Если вы настроили репозиторий Veeam Backup & Replication в качестве целевого хранилища для резервных копий, то вновь созданные резервные копии будут отображаться в панели инфраструктуры Backups > Disk, пункт Endpoint Backups.
