Microsoft Configuration Manager 2007 как инструмент миграции в Active Directory

--> Дата: Окт 8, 2008 55

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

В 2000 г. компания Microsoft (www.microsoft.com) впервые представила службу каталогов Active Directory (AD) в составе Windows 2000. Весной 2008 г. вышла уже третья версия этой службы, входящая теперь в состав Windows Server 2008. И хотя с момента выхода первой версии прошло уже достаточно много времени, вопросы, связанные с миграцией в службу AD, вновь встают перед разными компаниями с не меньшей остротой. Многие компании расширяются, консолидируют ИТ-ресурсы, приобретают новые подразделения с уже сложившейся ИТ-инфраструктурой, принимают новые стандарты ведения ИТ.

В течение последних трех лет вырабатывались и сейчас успешно применяются решения для оптимизации процессов миграции. Раньше одним из таких инструментов был Microsoft Systems Management Server 2003 (SMS 2003), а теперь его новая версия — Microsoft System Center Configuration Manager 2007 (ConfigMgr*), о котором и пойдет речь в этой статье.

Причины, почему для выполнения такого рода проектов выбирается ConfigMgr, достаточно просты:

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

В данной статье вопросы внедрения AD и использования ConfigMgr очень тесно переплетены, потому что именно так происходит в реальности. Решения на базе ConfigMgr позволяют собрать необходимые данные о существующей инфраструктуре, оптимизировать процесс перехода к единой службе каталогов AD, снизить операционные издержки и минимизировать различные риски при внедрении AD. В рамках такого проекта команде, выполняющей миграцию, требуется только некоторый базовый функционал ConfigMgr (рис. 1).

Понятия и термины

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

Инвентаризация аппаратного обеспечения — автоматический сбор данных о характеристиках аппаратного обеспечения клиентов ConfigMgr (объем оперативной памяти, подключенные периферийные устройства и т. п.).

Инвентаризация программного обеспечения — автоматический сбор данных о файлах на дисках компьютеров-клиентов сайта ConfigMgr.

Мониторинг использования ПО позволяет собирать данные об использовании ПО в организации: какие программы, когда запускались и в течение какого времени использовались на компьютерах-клиентах.

Распространение ПО служит для автоматизации процесса запуска программ на клиентах сайта ConfigMgr.

Система установки обновлений ConfigMgr обеспечивает доставку клиентам ConfigMgr новейших обновлений ПО Microsoft и других производителей, обновление которого поддерживается ConfigMgr.

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

Условия проекта

Типичный профиль компаний, которые применяют описанный подход, таков: обычно это территориально распределенная компания, с выделенным головным подразделением в крупном промышленном городе (центр страны/области) и большим количеством дочерних филиалов (от 50 до 2000). Примерное количество сотрудников в организации колеблется от 5 тыс. до 25 тыс. человек.

Филиалы часто делятся на два типа — средний и нижний уровни. На среднем уровне (город/область) присутствует ИТ-персонал, и филиал обладает некоторой автономностью в решении вопросов, касающихся ИТ-инфраструктуры. Количество ПК — примерно 100–1500. Нижний уровень (район города, поселок) полностью зависит от среднего уровня, не имеет выделенного штата ИТ-персонала, а количество ПК колеблется от 1 до 30.

Обычно на верхнем и среднем уровне уже есть сложившаяся ИТ-инфраструктура с самыми разными решениями для организации совместной работы. Это могут быть Novell, домены SAMBA, рабочие группы, домены NT 4.0, самые разные вариации доменов Windows 2000 и Windows 2003.

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

В общем, любой более или менее крупный банк на территории России дает представление о том, о какой структурной организации идет речь.

Перед руководством ИТ-подразделений при миграции в единую службу каталогов Active Directory стоят следующие цели:

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

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

В этом масштабном и трудоемком проекте можно выделить следующие основные фазы (рис. 2):

сбор данных об информационных системах головного подразделения и всех филиалов;
проектирование новой информационной системы;
развертывание ядра новой информационной системы в головной организации и пробных филиалах;
миграция ресурсов из старых систем в головной организации и пробных филиалах;
тиражирование решения на оставшиеся филиалы.

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

Сбор данных

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

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

Мы затронем здесь только некоторые основные проблемы, возникающие на этапе сбора данных и касающиеся парка ПК.

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

Отсутствие точных данных о версиях ОС, используемых на ПК. В зависимости от версии ОС механизмы и процедуры миграции могут очень сильно различаться.

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

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

Данный список можно продолжать до бесконечности, но суть проблем понятна.

Для снижения и устранения такого рода рисков применяется следующий подход. Все объекты компании делятся на две неравные группы — несколько пробных подразделений и все остальные офисы. Чаще всего в число пробных подразделений попадают головной офис компании и несколько объектов, характеризуемых как простой, средний и сложный филиал.

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

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

Задачи, которые желательно решить на данном этапе, прямо вытекают из списка приведенных выше проблем. Это сбор инвентарных данных об аппаратном обеспечении и об используемом ПО; составление подробных отчетов об используемых подсетях TCP/IP и распределение ПК по этим подсетям; получение списка локальных администраторов (этот перечень можно продолжить). Для этого применяются следующие средства:

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

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

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

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

Проектирование

В рамках данного этапа происходит проработка архитектуры системы, настроек всех служб — AD, DNS, DHCP, а также разработка и отладка процедур и процессов миграции ресурсов в новую систему.

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

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

А вот с процедурами миграции все гораздо сложнее. Здесь мы сделаем упор на миграцию ПК, поскольку миграция пользователей и групп выходит за рамки данной статьи.

Как отмечалось выше, в крупных организациях часто используются жесткие политики безопасности, ограничивающие или запрещающие доступ к ПК по сети. Как это влияет на миграцию? Основной инструмент миграции — это Active Directory Migration Tool (ADMT), клиент-серверное приложение, которое в ходе миграции устанавливает на компьютер свой агент. Процесс установки выполняется по сети и требует соблюдения ряда условий. Но политики безопасности зачастую полностью блокируют работу этого агента. Добавьте к этому, что ПК может находиться в неуправляемой среде (пример — домен NT 4.0 или рабочая группа), и получится замкнутый круг. Мы хотим управлять ПК, но для этого его нужно перенести в AD. А чтобы перенести его в AD, нам необходимо им управлять. Чтобы разорвать этот порочный круг, нужно либо провести миграцию в ручном режиме (но что если ПК, на которых нужно провести миграцию, находятся на островах в Баренцевом море?), либо добавить в процедуру миграции средство управления ПК, такое, как ConfigMgr.

На этапе проектирования вырабатывается ряд требований, которым должен соответствовать ПК для успешной миграции в новую службу каталогов AD. Это может быть версия ОС, версия пакета обновлений, запущенные службы, наличие необходимых сетевых ресурсов или что-то еще. Для приведения ПК в соответствие с перечисленными требованиями существует набор специально разработанных командных файлов. С помощью ConfigMgr гарантируется доставка и выполнение этих командных файлов на ПК в сети организации. Через механизмы отчетов, встроенные в ConfigMgr, можно контролировать процесс готовности ПК к миграции. Общая последовательность действий приведена на рис. 3.

Такой подход дает очень мощный инструмент подготовки и проведения миграции как в неуправляемых средах (домены NT 4.0 или рабочие группы), так и в доменах AD с их механизмом групповых политик.

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

Развертывание ядра системы в пробных филиалах

Вне зависимости от того, какое именно решение было разработано на этапе проектирования, его апробация первоначально проходит на небольшой группе объектов и пользователей. Под «развертыванием ядра системы» могут скрываться самые разные действия: как установка нового леса Active Directory, так и доведение существующих информационных систем до уровня, принятого при проектировании. Это может быть и обновление леса Active Directory до более новой версии или переименование доменов AD.

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

Миграция ресурсов в пробных филиалах

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

ConfigMgr в данном случае используется для решения следующих задач:

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

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

На практике регулярно случается, что при миграции выясняется какая-то инфраструктурная особенность данного филиала: неверно сконфигурированные DNS-серверы на части компьютеров при условии статической адресации, разрешения на уровне файловой системы NTFS и т. д. Эти настройки мешают успешному проведению миграции. В такой ситуации разрабатываются командные файлы и скрипты, вносящие необходимые изменения, и эти скрипты выполняются на ПК с помощью ConfigMgr.

Тиражирование решения

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

К проблемам, описанным в разделе «Миграция ресурсов в пробных филиалах», на этом этапе стоит добавить следующие:

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

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

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

Вместо заключения

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

Что касается оборудования, то при выполнении задач миграции требования к оборудованию для работы ConfigMgr минимальны. Можно использовать старые ПК или виртуальные машины.

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

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

* Правильной аббревиатурой для System Center Configuration Manager 2007 с точки зрения Microsoft будет именно ConfigMgr, а не SCCM.