Семейства Windows

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

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

Контроллер домена для ОС Unix

В данном случае серверная организация для ОС Linux/Unix в полной степени совместима с предъявляемыми стандартами Весь необходимый и сопутствующий функционал обеспечивает программный комплекс Samba (найти его можно на сайте по адресу www.samba.org, а также OpenLDAP (соответственно www.openldap.org). Как всем хорошо известно, основополагающим преимуществом поред знаменитой Windows заключается в том, что она распространяется бесплатно, а, соответственно, организации нет необходимости тратить достаточно большие средства для того, чтобы установить контроллер домена, предположим, под windows Server 2003. Лицензию на данный программный продукт по закону необходимо покупать. При этом настройка домена в локальной сети особых проблем не составляет.

Изменение домена для сайта организации

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

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

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

Основным элементом эффективной корпоративной сети является контроллер домена Active Directory, управляющий многими службами и дающий многие преимущества.

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

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

“Домен — базовая единица ИТ-инфраструктуры на базе ОС семейства Windows, логическое и физическое объединение серверов, компьютеров, оборудования и учетных записей пользователей.”

Контроллер домена (КД) - отдельный сервер с ОС Windows Server, на котором запущены службы Active Directory, делающие возможной работу большого количества ПО, требующего КД для администрирования. Примерами такого ПО является почтовый сервер Exchange, облачный пакет Office 365 и другие программные среды корпоративного уровня от компании Microsoft.

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

• Развертывание терминального сервера . позволяет значительно сэкономить ресурсы и усилия, заменяя постоянное обновление офисных ПК единоразовой инвестицией в размещение “тонких клиентов” для подключения к мощному облачному серверу.
• Повышенная безопасность . КД позволяет задавать политики создания паролей и заставлять пользователей применять более сложные пароли чем дата своего рождения, qwerty или 12345.
• Централизованный контроль прав доступа . Вместо ручного обновления паролей на каждом компьютере отдельно, администратор КД может централизованно сменить все пароли за одну операцию с одного компьютера.
• Централизованное управление групповыми политиками . Средства Active Directory позволяют создать групповые политики и задать права доступа к файлам, папкам и другим сетевым ресурсам для определенных групп пользователей. Это в разы упрощает настройку учетных записей новых пользователей или изменение параметров существующих профилей.
• Сквозной вход . Active Directory поддерживает сквозной вход, когда при вводе своего логина и пароля для домена, пользователь автоматически подключается ко всем остальным службам типа почты и Office 365.
• Создание шаблонов настройки компьютеров . Настройка каждого отдельного компьютера при добавлении его в корпоративную сеть может быть автоматизирована с помощью шаблонов. Например, с помощью специальных правил могут быть централизованно отключены CD-приводы или USB-порты, закрыты определенные сетевые порты и так далее. Таким образом, вместо ручной настройки новой рабочей станции, администратор просто включает ее в определенную группу, и все правила для этой группы применятся автоматически.

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

Когда внедрять контроллер домена Active Directory в корпоративную сеть?

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

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

• Ошибочные настройки DNS-сервера , что приводит к ошибкам локации ресурсов в корпоративной сети и в сети Интернет
• Некорректно настроенные группы безопасности , приводящие к ошибкам прав доступа пользователей к сетевым ресурсам
• Некорректные версии ОС . Каждая версия Active Directory поддерживает определенные версии десктопных ОС Windows для тонких клиентов
• Отсутствие или неправильная настройка автоматического копирования данных на резервный контроллер домена.

Так уж получилось в нашей организации, что инфраструктуру надо было делать быстро, а на покупку лицензий требовалось время. Поэтому было решено использовать образы Windows Server 2012R2 Evaluation, а после тестового периода уже лицензировать. Тогда еще никто не знал, что нельзя просто так взять, прописать лицензию Standard в релизе Evaluation, и на выходе получить лицензионный Standard, иначе, думаю, сначала бы все таки купили лицензии. Но делать нечего, что имеем, с тем и работаем. Итак.

Задача: после покупки лицензий Microsoft на Windows server 2012R2 Standard необходимо активировать их на наших серверах. Приступаем.

При выполнении задачи была обнаружена проблема. Так как изначально мы устанавливали Windows server 2012R2 Standard Evaluation, то при попытке прописать ключ для Standard - сервер говорит, что ему этот ключ не подходит. Начали поиск решения проблемы перевода сервера из версии Evaluation в Standard. Ответ был найден на сайте microsoft в статье TechNet .

Частично статья помогла решить проблему. Мы смогли поменять версию на трех физических серверах и активировать их нашими лицензиями. Но, к сожалению, не все так просто складывалось с контроллерами домена. В вышеуказанной статье прямым текстом говорится, что контроллеры домена НЕВОЗМОЖНО перевести из выпуска Evaluation в Standard. Нам же это необходимо сделать в самые кратчайшие сроки, т.к. количество возможных /rearm у PDC закончилось, а дней до окончания ознакомительной версии осталось меньше 3 дней.

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

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

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

1. Создаем новую виртуальную машину с параметрами соответствующими текущему PDC. Желательно создать на физическом сервере, на котором нет других контроллеров домена, но это если у вас несколько гипервизоров, как в моем случае, если нет, то это не принципиально, вопрос только в отказоустойчивости. Ну а если вы работаете не с гипервизорами, а с реальными серверами, то отказоустойчивость PDC и BDC вещь и так само собой разумеющаяся.

2. Устанавливаем Windows Server 2012R2. Выбираем выпуск Standard с графическим интерфейсом. Настраиваем TCP/IP и переименовываем сервер в соответствии со стандартном наименований в IT инфраструктуре.

3. После установки в диспетчере серверов включаем серверу новые роли. Нас интересует AD, DNS и прочие роли и компоненты, используемые на текущих домен-контроллерах.

4. Повышаем сервер до контроллера домена. Проходит репликация между основным контроллером домена и новым.

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

ntdsutil
roles
connections
connect to server <имя сервера PDC>
q

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

transfer naming master - передача роли хозяина доменных имен.
transfer infrastructure master - передача роли хозяина инфраструктуры;
transfer rid master - передача роли хозяина RID;
transfer schema master - передача роли хозяина схемы;
transfer pdc - передача роли эмулятора PDC

Для завершения работы Ntdsutil вводим команду q.

6. После передачи хозяина схемы смотрим системный журнал и dcdiag на предмет ошибок. Их быть не должно. Если есть, исправляем. (я столкнулся с ошибкой dns, где сервер жаловался на неправильно указанные сервера пересылки. В этот же день я узнал, что в серверах пересылки DNS не должен быть указан сервер на котором установлен DNS (как правило указывают сервера DNS провайдера и Yandex(Google), что в общем-то логично, это по сути порождает петлю в DNS.

7. Если ошибки исправлены, или их нет. Приступаем к сменам IP-адресов. Назначаем старому PDC любой свободный IP-адрес в сети, а новому PDC назначаем адрес старого.

8. Снова проверяем на ошибки. Проводим тесты. Выключаем старый PDC и BDC. Проверяем возможность авторизации в домене. Затем оставляем включенным только BDC, проверяем принимает ли он на себя роль контроллера домена в случае недоступности PDC.

9. Если все тесты проходят удачно. Можно уничтожать старый PDC и приниматься за смену версии BDC.

10. В нашем случае cтарый PDC все еще нельзя было выкинуть на помойку так как на нем функционировала роль пространства имен DFS, а мы не знали, как ее реплицировать на новый сервер.

11. Все оказалось очень просто. Входим в графическую оснастку «Управление DFS». В «Пространстве имен» добавляем существующие пространства имен, затем каждому пространству имен добавляем сервер пространства имен и в общем-то все. Корень dfs автоматически вместе с ссылками на сетевые ресурсы появляется на c:\ и все работает. На всякий случай проверяем работу выключением старого PDC. Сначала сетевые ресурсы будут недоступны (DFS нужно 300 секунд для репликации). По истечении 5 минут сетевые ресурсы снова должны стать доступны.

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

P.S.: Все вышеописанные действия проводились после внимательного изучения книги Windows server 2012R2 - Полное руководство. В частности глав посвященных конкретно AD, DNS и DFS, а так же контроллерам домена. Без понимания и планирования к данным действиям лучше не приступать, т.к. можно потерять рабочую инфраструктуру.

Надеюсь, для кого-то эта статья окажется полезной и нужной. Спасибо за внимание!

Будучи хорошо знакомым с малым бизнесом изнутри, меня всегда интересовали следующие вопросы. Объясните, почему сотрудник должен пользоваться на рабочем компьютере тем браузером, который нравится сисадмину? Или взять любое другое программное обеспечение, например, тот же архиватор, почтовый клиент, клиент мгновенных сообщений… Это я плавно намекаю на стандартизацию, причем не по признакам личной симпатии сисадмина, а по признакам достаточности функционала, стоимости обслуживания и поддержки этих программных продуктов. Давайте начнем считать ИТ точной наукой, а не ремеслом, когда каждый делает так, как у него получается. Опять-таки, с этим в малом бизнесе тоже очень много проблем. Представьте, что компания в нелегкое кризисное время меняет нескольких таких администраторов, что в такой ситуации делать бедным пользователям? Постоянно переучиваться?

Давайте посмотрим с другой стороны. Любой руководитель должен понимать, что у него сейчас происходит в компании (в том числе и в ИТ). Это необходимо для отслеживания текущей ситуации, для оперативного реагирования на возникновение разного рода проблем. Но это понимание является более важным для стратегического планирования. Ведь, имея крепкий и надежный фундамент, мы можем строить дом на 3 этажа или на 5, делать крышу разной формы, делать балконы или зимний сад. Точно также и в ИТ, имеем надежную основу – можем в дальнейшем использовать более сложные продукты и технологии для решения бизнес-задач.

В первой статье и пойдет речь о таком фундаменте – службах Active Directory . Именно они призваны стать крепким фундаментом ИТ-инфраструктуры компании любого размера и любого направления деятельности. Что это такое? Вот давайте об этом и поговорим…

А разговор начнем с простых понятий – домена и служб Active Directory.

Домен – это основная административная единица в сетевой инфраструктуре предприятия, в которую входят все сетевые объекты, такие как пользователи, компьютеры, принтеры, общие ресурсы и многое другое. Совокупность таких доменов называется лесом.

Службы Active Directory (службы активного каталога ) представляют собой распределённую базу данных, которая содержит все объекты домена. Доменная среда Active Directory является единой точкой аутентификации и авторизации пользователей и приложений в масштабах предприятия. Именно с организации домена и развёртывания служб Active Directory начинается построение ИТ-инфраструктуры предприятия.

База данных Active Directory хранится на выделенных серверах – контроллерах домена. Службы Active Directory являются ролью серверных операционных систем Microsoft Windows Server. Службы Active Directory имеют широкие возможности масштабирования. В лесу Active Directory может быть создано более 2-х миллиардов объектов, что позволяет внедрять службу каталогов в компаниях с сотнями тысяч компьютеров и пользователей. Иерархическая структура доменов позволяет гибко масштабировать ИТ-инфраструктуру на все филиалы и региональные подразделения компаний. Для каждого филиала или подразделения компании может быть создан отдельный домен, со своими политиками, своими пользователями и группами. Для каждого дочернего домена могут быть делегированы административные полномочия местным системным администраторам. При этом всё равно дочерние домены подчиняются родительским.

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

Для обеспечения отказоустойчивости служб Active Directory необходимо развернуть два или более контроллера домена в каждом домене. Между контроллерами домена обеспечивается автоматическая репликация всех изменений. В случае выхода из строя одного из контроллеров домена работоспособность сети не нарушается, ведь оставшиеся продолжают работать. Дополнительный уровень отказоустойчивости обеспечивает размещение серверов DNS на контроллерах домена в Active Directory, что позволяет в каждом домене получить несколько серверов DNS, обслуживающих основную зону домена. И в случае отказа одного из DNS серверов, продолжат работать остальные. О роли и значимости DNS серверов в ИТ-инфраструктуре мы еще поговорим в одной из статей цикла.

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

1. Единая точка аутентификации

В рабочей группе на каждом компьютере или сервере придётся вручную добавлять полный список пользователей, которым требуется сетевой доступ. Если вдруг один из сотрудников захочет сменить свой пароль, то его нужно будет поменять на всех компьютерах и серверах. Хорошо, если сеть состоит из 10 компьютеров, но если их больше? При использовании домена Active Directory все учётные записи пользователей хранятся в одной базе данных, и все компьютеры обращаются к ней за авторизацией. Все пользователи домена включаются в соответствующие группы, например, «Бухгалтерия», «Финансовый отдел». Достаточно один раз задать разрешения для тех или иных групп, и все пользователи получат соответствующий доступ к документам и приложениям. Если в компанию приходит новый сотрудник, для него создаётся учётная запись, которая включается в соответствующую группу, – сотрудник получает доступ ко всем ресурсам сети, к которым ему должен быть разрешён доступ. Если сотрудник увольняется, то достаточно заблокировать – и он сразу потеряет доступ ко всем ресурсам (компьютерам, документам, приложениям).

2. Единая точка управления политиками

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

3. Повышенный уровень информационной безопасности

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

4. Интеграция с корпоративными приложениями и оборудованием

Большим преимуществом служб Active Directory является соответствие стандарту LDAP, который поддерживается другими системами, например, почтовыми серверами (Exchange Server), прокси-серверами (ISA Server, TMG). Причем это не обязательно только продукты Microsoft. Преимущество такой интеграции заключается в том, что пользователю не требуется помнить большое количество логинов и паролей для доступа к тому или иному приложению, во всех приложениях пользователь имеет одни и те же учётные данные – его аутентификация происходит в едином каталоге Active Directory. Windows Server для интеграции с Active Directory предоставляет протокол RADIUS, который поддерживается большим количеством сетевого оборудования. Таким образом, можно, например, обеспечить аутентификацию доменных пользователей при подключении по VPN извне, использование Wi-Fi точек доступа в компании.

5. Единое хранилище конфигурации приложений

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

Подводя итоги, хочется еще раз акцентировать внимание на том, что службы Active Directory являются сердцем ИТ-инфраструктуры предприятия. В случае отказа вся сеть, все сервера, работа всех пользователей будут парализованы. Никто не сможет войти в компьютер, получить доступ к своим документам и приложениям. Поэтому служба каталогов должна быть тщательно спроектирована и развёрнута, с учётом всех возможных нюансов, например, пропускной способности каналов между филиалами или офисами компании (от этого напрямую зависит скорость входа пользователей в систему, а также обмен данными между контроллерами домена).

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 минут на выяснение причины появления ряда предупреждений - я разобрался с синхронизацией времени, архивацией глобального каталога и прочими вещами, до которых раньше не доходили руки. Теперь всё работает как часы - самое главное не забудьте завести резервный контроллер домена, если вы хотите удалить старый контроллер домена из сети.