Материалы о рабочей средеНастройка служб развертывания Windows

Уэс Миллер (Wes Miller)

Содержание

Замена того, что есть
Рассмотрение стека
Программа сетевой загрузки
Поставщик PXE WDS
Демон TFTP
Хранилище данных конфигурации загрузки
Windows PE
Транспортный сервер
Пользовательская многоадресность
Заключение

В течение трех месяцев я занимался изучением служб развертывания Windows (WDS) — их истоков, последующим образом и дальнейшим подробным рассмотрением некоторых сложных вопросов, таких как WDSUtil и многоадресность. В последнем выпуске этой серии я рассмотрю настройку WDS в соответствие с потребностями вашей организации. Большинство инструментов Microsoft разработаны с определенными возможностями настройки. Но при возникновении необходимости настройки на практике, вы начинаете выяснять, соответствуют ли инструменты вашим потребностям, или, еще чаще, что для работы в ваших ситуациях необходима определенная ручная настройка.

Замена имеющегося

В последнее время читатели часто спрашивают: «Я использую икс (существующая технология развертывания) — подойдут ли WDS службы для меня и совместимы ли они с икс?» После прекращения использования автоматизированных служб развертывания (ADS) особый интерес представляет вопрос «Как выполнить быстрое развертывание большого объема или подготовку серверов — могут ли службы WDS сделать это автоматически?»

Хотя службы WDS не задумывались как полноценная замена ADS, и фактически в них отсутствует несколько ключевых компонентов, с помощью небольшой работы WDS могут заменить ADS. Аналогично, если какие-либо функции WDS не работают ожидаемым образом, вы обнаружите, что множество компонентов этих служб можно заменить — с различной степенью сложности и объемом проектирования. Рассмотрим развертывание с помощью WDS, а также компоненты, настройка которых может быть необходима, и как эта настройка выполняется.

Рассмотрение стека

На Рис. 1 показаны компоненты процесса развертывания WDS. Все эти действия могут быть в определенной степени настроены. Я отметил все шаги разными цветами, чтобы показать, что, по-моему мнению, представляет сложность (как правило, связанную с наличием навыков разработки), заключающуюся в замене или настройке. Чем темнее синий цвет, тем труднее будет настройка этого этапа.

Рис. 1 Сложность настройки WDS

Действительная сложность настройки каждого этапа, конечно же, зависит от навыков вашей команды (разработки или проектирования) и вашего понимания WDS, формата образов Windows (WIM), Active Directory и иных технологий, интеграция которых необходима, например, SQL или ADSI. Давайте рассмотрим все эти этапы; подумаем о способах их настройки и используемых методах.

Программа сетевой загрузки

Маловероятно, что потребуется создание пользовательской программы сетевой загрузки для замены программ, входящих в состав WDS, но это возможно. В состав служб WDS входят программы сетевой загрузки для использования с системами без мониторов (как правило, серверами) или системами с необходимостью нажатия клавиши F12 или без такой необходимости и т.д. Эти программы сетевой нагрузки могут быть подготовлены для Active Directory с помощью WDSUtil, или можно заменить Startrom.com программой сетевой загрузки, которую необходимо использовать во всех неподготовленных системах (например, если во всех системах отсутствуют мониторы или запрос на нажатие клавиши F12 никогда не должен появляться).

К сожалению, доступно немного документации по созданию собственной программы сетевой загрузки (некоторые сведения доступны на веб-узле msdn.microsoft.com/library/bb870970.aspx). Программа сетевой нагрузки — это небольшое 16-разрядное приложение с определенными ограничениями, для которого необходимы определенные навыки программирования. Как правило, рекомендуется использовать существующие программы сетевой загрузки, входящие в состав WDS, если не требуется соблюдение специальных требований и существует группа разработки с соответствующими навыками.

Поставщик PXE WDS

Обычно относительно служб удаленной установки мы получали отзывы пользователей о необходимости использования другого хранилища данных, чем Active Directory для данных клиентской системы — чаще всего SQL Server. При использовании WDS в проект включена подключаемая инфраструктура для поставщиков среды удаленной загрузки (PXE). Это означает, что при разработке для данных PXE можно использовать другое резервное хранилище, отличное от Active Directory.

Службы WDS имеют собственного поставщика, использующего Active Directory; теперь System Center Configuration Manager (SCCM) подключается к WDS, а также самостоятельно реализует поставщика. Документация по созданию собственных поставщиков существует в ограниченном количестве, и не так уж много готовых образцов кода (хотя в Windows SDK содержится определения документация и ряд примеров), поэтому это довольно трудная задача. Если отсутствуют специальные требования относительно этого аспекта процесса загрузки, я снова рекомендую не пытаться создавать пользовательский поставщик PXE.

Демон TFTP

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

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

Необходимо только помнить, что вы углубляетесь в технически неподдерживаемую область, когда это касается Microsoft, и что это может привести к возникновению трудно диагностируемых проблем. Более того, улучшенный демон TFTP в WDS позволяет пожертвовать производительностью. В идеале рекомендуется использовать существующий демон TFTP WDS и таймауты PXE, предварительную подготовку и/или границы сети для определения клиентов, загружающихся с сервера PXE, вместо того, чтобы пытаться приспособить существующий сервер.

Хранилище данных конфигурации загрузки

Службы RIS не позволяли указывать на уровне загрузки, что именно должно загружаться — всегда требовалось использовать модуль OS (для выбора программы установки, Windows PE (среда предустановки Windows) или что-либо еще). Службы WDS, поскольку они используют для сетевой загрузки загрузчика целиком, также поддерживает настройку хранилища данных конфигурации загрузки, предоставляемого клиентам. Данные конфигурации загрузки по умолчанию для каждой архитектуры содержатся по адресу RemoteInstall\Boot\<arch>\Default.bcd, где <arch> — это определенная архитектура загружаемой системы.

Данные конфигурации загрузки можно настроить для каждого клиента, после чего клиент будет использовать их для загрузки. Например, можно установить одну запись BCD для запуска установки, другую для запуска среды восстановления, а третью для проверки памяти — или же можно использовать полностью автоматическую запись загрузки по умолчанию и ручную (или пользовательский процесс установки) в качестве выбираемого пользователем варианта. (Дополнительные сведения см. в статье «How to Modify the BCD Store Using Bcdedit» (Изменение хранилища BCD с помощью Bcdedit) на веб-узле go.microsoft.com/fwlink/?LinkId=115267.)

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

Помимо использования BCD для указания используемых образов, также можно указать образ путем настройки объекта учетной записи компьютера (MAO) для компьютера в Active Directory. В службе RIS каждый элемент сохраняется в определенном атрибуте MAO (файл Startrom и Unattend (SIF) для использования). В WDS они хранятся как пары имени/значения в разделе netBootMirrorDataFile. Например, образ загрузки и файл Unattend для использования определенным компьютером хранятся в данном разделе. Записи имеют форму списка пар имен-значений, разделенного точками с запятыми. Записи для изменения образа загрузки и файла Unattend — это записи BootImage и UnattendFilePath соответственно.

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

• Поиск всех данных для отдельных компьютеров или пользователей. Например, эти данные могут быть введены пользователем, получены от сервера SQL Server или из текстового файла.
• Копирование и установка образа установки на клиентских системах. Эта задача может быть выполнена непосредственно с помощью установки, используя ImageX для установки образа с сетевого ресурса, или используя многоадресность (просто скопируйте образ и установите его с помощью ImageX).
• Предоставление файла Unattend (такого как Unattend.xml или sysprep.inf в зависимости от развертываемой версии Windows) для выполнения установки.
• Автоматизация всех необходимых действий по переносу после установки (или в случае Windows Server 2008 всех действий по применению ролей).

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

Я был поклонником Microsoft SQL Server в течение долгого времени (начиная с выпуска SQL Server 6.5), поэтому моим инстинктивным желанием является создание подобной структуры с помощью SQL. Конечно, для этого необходимо добавить в вашу сборку Windows PE функции SQL. Более того, можно написать собственный графический пользовательский интерфейс — приложение HTML (HTA) или скомпилированный исполняемый файл — или использовать сервер сценариев Windows (WSH) для выполнения минималистской установки только с помощью командной строки. Для использования HTA и WSH они также должны быть добавлены к Windows PE.

Сложность создания собственного процесса установки полностью зависит от ваших навыков и воображения. Я видел довольно изящные системы, определенные только с помощью SQL и WSH или HTA — что довольно простые навыки. Однако очень важно помнить упоминавшиеся в предыдущих статьях ограничения:

• В Windows PE отсутствует подсистема Windows on Windows (WOW), поэтому ее необходимо скомпилировать для каждой поддерживаемой архитектуры.
• Нельзя использовать Visual Basic 6.0 при необходимости развертывания через x64 или IA64 Windows PE.
• Можно использовать Visual Studio 2005 или 2008 для создания приложений, но необходимо создать неуправляемое приложение Visual C++, поскольку Windows PE не поддерживает никакие версии Microsoft .NET Framework.
• Отсутствие .NET Framework также не позволяет использовать Windows PowerShell для автоматизации.

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

Аналогично, для определенных сценариев может потребоваться пользовательское секционирование — может выполняться развертывание Windows Vista с BitLocker или могут создаваться системы Windows XP, а данные профилей сохраняться на втором томе, или возможно выполняется развертывание системы Windows Server и необходимо создать отдельный том на этом же диске для ведения журнала. Для всего этого необходима автоматизация DiskPart, что, как в предыдущих версиях, может быть выполнено путем передачи сценария (в любом формате) программе DiskPart, содержащей команды, которые необходимо выполнить, и которая потом должна быть закрыта.

Создание собственного процесса установки — занятие не для слабых духом, поскольку, по сути, оно заключается в перестройке исполняемого файла (или по крайней мере в зеркальном отображении его функций), поэтому для этого требуется определенная разработка и проектирования. Но все сводится к объему функций, которые должны быть включены по умолчанию, а также к форме создаваемого процесса (HTA или WSH или скомпилированный язык программирования).

Транспортный сервер

Если большинство стандартных функций WDS не используются (например, Active Directory), или создается полностью собственное решение, транспортный сервер может соответствовать вашим потребностям и не создавать нежелательных ограничений. В таблице на Рис. 2 (который взят из статьи «Using Transport Server» (Использование транспортного сервера) по адресу go.microsoft.com/fwlink/?LinkID=115298) описано то, что включено в роль транспортного сервера WDS.

Рис. 2 Сервер развертывания и транспортный сервер

Когда я говорю, что транспортный сервер сложен в развертывании, сложна не сама роль; ее развертывание, конечно же, выполняется очень просто (см. Рис. 3). Эта реализация пользовательской установки с использованием транспортного сервера, для который необходимо выполнение определенной работы. Использование роли транспортного сервера эффективно устраняет большую часть простоты использования WDS как роли.

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

Пользовательская многоадресность

Независимо от того, используется ли роль транспортного сервера, но особенно если она используется, при выполнении многосистемного развертывания рекомендуется использовать многоадресность. ADS имеет мощную функцию многоадресности, которую можно дублировать с помощью WDS с многоадресностью. Службы WDS имеют собственную функцию многоадресности, но при создании собственного пользовательского решения можно использовать многоадресность с помощью WDSMCast, что упоминалась в статье за предыдущий месяц (см. Рис. 4). Помните, что необходимо передать файл(-ы) образа для развертывания, который затем должен быть установлен. Как правило, это означает необходимость достаточного пространства на жестком диске для сохранения и установки образа.

Рис. 4 Запуск WDSMCast (щелкните изображение, чтобы увеличить его)

Заключение

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

Уэс Миллер (Wes Miller) — старший технический руководитель продуктов в CoreTrace (CoreTrace.com) в Остине, штат Техас. Ранее Уэс работал в компании Winternals Software, а также в корпорации Майкрософт в должности руководителя программы. Связаться с Уэсом Миллером можно по адресу technet@getwired.com.