После переноса серверов служб развертывания Windows (WDS) с Server 2003 на Server 2012 R2 необходимо навести порядок в обновленном хозяйстве. Вероятно, самый важный шаг, который скорее всего выполнялся при развертывании роли WDS — настройка WDS для работы при размещении на одном сервере с ролью сервера DHCP. Если роли WDS и Windows Server DHCP Server размещены совместно, то проверив свойства сервера WDS, следует проверить настройки следующих параметров:
- Do not listen on port 67 («Не прослушивать порт 67»);
- Configure DHCP option 60 to PXEClient («Настроить тег 60 DHCP-параметра для значения PXEClient»).
Если включен режим, задаваемый вторым параметром, сервер DHCP настраивается автоматически. Обращаться к консоли DHCP при этом не обязательно.
Если используется сервер DHCP, отличный от предоставляемого Microsoft, проверьте настройку параметра Do not listen on port 67. Вам потребуется средство администрирования DHCP-сервера для настройки параметра 60.
Если предполагается использовать WDS с диспетчером виртуальных машин или диспетчером конфигураций, то необходимо правильно выполнить настройку через соответствующие консоли VMM или диспетчера конфигураций. Достоинство этих двух продуктов состоит в преодолении сложностей, связанных с настройкой WDS.
Кроме того, следует убедиться, что все нужные образы, присутствовавшие на WDS-серверах Server 2003, имеются в наличии на серверах Server 2012 R2. Непростительно выполнить миграцию, а потом обнаружить, что при выводе старых серверов из эксплуатации было удалено несколько важных образов.
Последним шагом должна быть проверка развертываний, это позволит убедиться в правильности функционирования всех компонентов. Если вы можете успешно развернуть операционные системы с использованием WDS в Server 2012 R2, значит миграция с Server 2003 прошла успешно.
Переходить ли в новый лес?
Один из важных вопросов, возникающих при переходе от Server 2003 к Server 2012 R2, следующий: обновить существующую среду Active Directory или лучше перейти к новой среде Active Directory? Как в случае со многими важными вопросами в сфере информационных технологий, ответ на него начинается со слов «в зависимости от обстоятельств».
Преимущество перехода на новый лес заключается в том, что появляется возможность вернуться назад и изменить решения, принятые в компании при первом развертывании Active Directory. Если вы все еще пользуетесь Server 2003, то ваша компания явно не относится к числу оперативно внедряющих новые информационные технологии. Многие организации располагают лесом со структурой, сформированной еще при первом внедрении Active Directory, когда впервые было выполнено развертывание Windows 2000 или устанавливалась операционная система Windows Server 2003.
Решения, принятые при этом развертывании, скорее всего, на тот момент были обоснованными. Другой вопрос, насколько обоснованы они сейчас. Это как с клавиатурой QWERTY, сконструированной с целью повысить скорость ввода по сравнению со старыми пишущими машинками. Возможно, вам по-прежнему приходится работать со структурой леса, которая представлялась рациональной десять лет назад, но не отражает сегодняшнего положения дел в вашей компании. Поэтому переход на новый лес позволяет создать условия, отвечающие современным потребностям. Кроме того, появляется возможность «убрать мусор», в том числе устаревшие учетные записи и объекты, накопившиеся за время существования Active Directory.
Недостаток миграции по сравнению с обновлением состоит в необходимости тщательного планирования. Это проблематично, потому что осталось всего пара месяцев до завершения расширенного срока поддержки Windows Server 2003. Если вы еще не приступили к планированию, то теперь это все равно что начинать изучать «Руководство по использованию парашюта» после того, как двигатели самолета отказали.
Рационализация доменов
Переход с Windows Server 2003 на Windows Server 2012 R2 дает возможность заново оценить структуру Active Directory вашей компании. В частности, у вас появляется возможность оптимизировать число доменов.
Число необходимых доменов зависит от нескольких факторов. Рекомендации, какие из этих факторов следует считать наиболее весомыми, подчас сомнительны. Но какими бы ни были рекомендации в прошлом, справедливо отметить, что советы, которые давали во время выпуска Windows Server 2003, отличаются от советов относительно количества доменов, необходимых пользователям новых версий операционной системы Windows Server.
Рекомендуемый верхний предел числа учетных записей пользователей в доменах с текущими версиями операционной системы Windows Server — 100 000 пользователей. Предельное значение зависит от пропускной способности самого медленного канала связи между любыми двумя контроллерами домена. На самом нижнем уровне, если имеется канал связи на 28,8 Кбит/с и только 1% его полосы пропускания отводится для трафика репликации, современный домен все же способен обслуживать 10 000 пользователей. Если доступны 10% этого медленного канала связи, то число пользователей увеличивается до 40 000. Сегодня большинство компаний располагает гораздо более быстродействующими каналами связи между сайтами, чем 28,8 Кбит/с. А число служащих в компаниях, кроме самых крупных, обычно меньше 10 тысяч. Поэтому для подавляющего большинства организаций вполне достаточно одного домена.
Большинство компаний имеют два или несколько доменов, так как их доменная структура определяется не только максимальным числом пользователей и требованиями репликации. Политические факторы часто преобладают над техническими, и ни один из них не оказывает такого влияния на системных администраторов, как список лиц, имеющих административные привилегии в различных подразделениях компании.
Специалисты, хорошо знакомые с последними версиями операционной системы Windows Server, знают, что при правильной настройке делегирования можно достичь такого же уровня разделения административных ролей, который обычно приводится в качестве аргумента в пользу организации нескольких отдельных доменов. Старый довод о необходимости нескольких доменов для отдельных политик паролей также неактуален благодаря возможности (резко возросшей в Windows Server 2012 R2) создавать отдельные политики паролей на основе членства в группах. Конечно, для этого потребуется выполнить некоторую работу, поэтому многие компании имеют отдельные домены по той простой причине, что их администраторы не понимают разделения привилегий в достаточной степени, чтобы правильно реализовать их в одном домене.
Возможно, в Windows Server vNext нас ожидают улучшения, но они не помогут обладателям Windows Server 2003, так как срок эксплуатации Windows Server 2003 истечет задолго до выхода первоначальной версии Windows Server vNext. Дополнительные сведения об ограничении числа учетных записей можно найти в статье на сайте TechNet: https://technet.microsoft.com/en-us/library/cc732201%28v=ws.10%29.aspx
Перенос учетной записи между лесами
Если вы задумали переход от существующего леса Windows Server 2003 к новому лесу с операционной системой Windows Server 2012 R2, то одной из проблем, с которой вы неизбежно столкнетесь, будет миграция учетных записей. Миграция учетных записей представляет собой процесс перемещения учетных записей пользователей, групп и компьютеров из домена Active Directory одного леса в другой лес. Компания Microsoft предоставляет для этого специальный бесплатный инструмент, именуемый Active Directory Migration Tool (ADMT).
С помощью ADMT можно переносить учетные записи, одновременно сохраняя журнал идентификаторов безопасности и пароли. В ходе работы ADMT создает клон учетной записи. Это означает, что в процессе миграции учетная запись не удаляется из исходного леса. Для использования ADMT требуется некоторая подготовка и, очевидно, лес назначения тоже должен быть подготовлен, прежде чем вы сможете приступить к перемещению учетных записей. Компания Microsoft опубликовала превосходное руководство, где на 256 страницах описано, как перенести учетные записи из одного леса в другой. Руководство по ADMT можно загрузить с сайта компании по адресу: http://www.microsoft.com/en-au/download/details.aspx?id=19188. Обязательно изучите его, прежде чем приступать к миграции. Получить инструмент ADMT (текущая версия 3.2) можно через службу Microsoft Connect по адресу: https://connect.microsoft.com/site1164/program8540.