Автоматизируем установку программного обеспечения в сети

Андрей Бирюков

Установка программного обеспечения – неотъемлемая часть работы системного администратора. Есть несколько способов автоматизировать этот процесс.

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

Групповая политика как основа автоматизации

Для начала нам необходимо определиться со средством, с помощью которого будет осуществляться автоматическое развертывание пакетов. В сети на основе Windows можно использовать несколько различных средств, например, Microsoft Systems Management Server (SMS) или Microsoft Operations Management (MOM). Однако это достаточно мощные и, следовательно, дорогостоящие программные продукты, требующие специальной подготовки, и использование которых оправдано лишь в сетях крупных компаний, где количество компьютеров исчисляется сотнями и тысячами. Поэтому об этих продуктах компании Microsoft речь сегодня вести не будем. Но если у нас есть Active Directory, то нам доступно такое мощное средство управления программным обеспечением, как Group Policy.

В Group Policy за установку приложений отвечает компонента Software Installation and Maintenance, которая есть как в разделе «Computer Configuration → Software Settings», так и в «User Configuration → Software settings» (см. рис. 1).

Рисунок 1. Групповая политика домена

Различие между компонентами в этих двух разделах следующее. В Computer Configuration вы можете только назначать (Assign) приложение, то есть оно станет доступным без каких-либо действий со стороны пользователя после следующей загрузки системы. В User Configuration приложения можно как назначать, так и публиковать (Publish), при этом после публикации оно становится доступным из окна «Add/Remove» для пользователей, к которым применяется данный объект Group Policy. Назначенные приложения становятся доступны после входа пользователя в систему.

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

Для установки приложения с помощью Group Policy необходимо выполнить следующие действия. Открыть раздел Computer Configuration или User Configuration (в зависимости от поставленной задачи). Затем выбрать «Software Installation → Action → New → Package…». Тут сразу следует оговориться, что при развертывании с помощью групповой политики используемый дистрибутив должен представлять из себя msi или msp файл. О том, что делать в случае, если наш дистрибутив не является msi/msp-файлом, мы поговорим далее. В появившемся окне необходимо указать файл пакета (msi или msp). Обратите внимание на то, что необходимо указать не локальный, а сетевой путь к данному файлу, так как в противном случае пакет будет недоступен другим пользователям. Далее выбираем в зависимости от вида установки Assigned или Published. И все, точка распространения программного обеспечения готова.

Создаем установочный пакет вручную

Итак, с подготовкой средства для развертывания ПО мы разобрались. Теперь вернемся к тому, с чего начали, а именно – с создания пакета для автоматической установки приложения. В случае, если дистрибутив устанавливаемой программы уже содержит msi-файл, то можно считать, что у нас уже есть установочный пакет и необходимо только прописать его в Group Policy, как это описано выше. Но рассмотрим ситуацию, когда есть только установочный файл, например, setup.exe, при запуске которого задается много разных вопросов, требуется указать ряд настроек. В документации по Windows в такой ситуации предлагают использоть ZAPфайлы. Это специальный текстовый файл, который указывает на программу установки для данного приложения и может при необходимости запускать сценарии автоматизированной установки. Однако такой вариант установки имеет целый ряд ограничений (например, назначать приложения пользователям или компьютерам или устанавливать приложения автоматически при первом вызове) и поэтому используется для устаревших приложений, установочные файлы которых нельзя перепаковывать.

Делаем снимки системы

Другой вариант – это создание установочных пакетов с помощью средств третьих производителей. Здесь сразу следует оговориться, что создание установочных пакетов самостоятельно – занятие достаточно рискованное, так как по собственному опыту могу сказать, что не бывает абсолютно идентичных пользовательских машин, и поэтому то, что на одной системе устанавливается без проблем, на другой может вызвать ошибку, зависание и даже повреждение операционной системы. Поэтому прежде чем приступать к развертыванию свежесозданного пакета на всех машинах домена, надо сначала тщательно протестировать, устанавливая приложение на нескольких машинах домена, как правило, этими «испытуемыми» становятся компьютеры сотрудников ИТ-отдела, так как они наиболее подготовлены к различным «сюрпризам».

Но если вас вышесказанное не испугало, то можно приступать к созданию установочного пакета. В справочнике по Windows 2003 [1] для создания msi-пакетов рекомендуется использовать WinInstalLE 2003 [2].

Для начала подготовим сборочную машину, которая имеет типовую для вашей сети конфигурацию.

Прежде чем начать установку приложения, необходимо сделать снимок (snapshot) системы.

В WininstalLE это можно сделать с помощью средства Discover (раздел «File → Run Discover»). Данная утилита произведет сканирование системы (при этом для файлов можно выбрать какой диск сканировать, а также указать исключения в каких каталогах и каких ветках реестра не надо сканировать). Далее будет сделан снимок системы в состоянии «Before», то есть до установки системы. Авторы программы рекомендуют, чтобы перед запуском Discover на сборочной машине не было установлено никаких дополнительных приложений, то есть только операционная система, но по-моему, лучше, чтобы на сборочной машине была именно типовая конфигурация c типовыми приложениями, используемыми в вашей сети.

После того как снимок будет создан, надо запустить процесс установки нашего приложения. После того как приложение успешно установится и все необходимые изменения и настройки будут внесены, необходимо вновь запустить Discover, но в режиме «Perform the ‘After’ snapshot now». После этого снова запустится сканирование, по завершении которого будет произведено сравнение изменений системы до и после установки, и в результате создан msi-файл, фактически являющийся установочным пакетом.

При необходимости можно произвести редактирование установочного пакета. После запуска WinInstalLE для редактирования msi-пакета нужно, выбрав опцию «Windows Installer Package» и нажав правую кнопку мыши, указать Packages Directory, затем в появившемся списке выбрать уже созданный пакет (см. рис. 2).

Рисунок 2. Настройки установочного пакета в WinInstalLE

В разделе «Files» можно добавить какие-то дополнительные файлы, которые необходимо создать в процессе установки. Пути ко всем этим файлам необходимо указать в разделе «Files». Также можно прописать удаление либо перенос каких-либо файлов, для случаев если, например, требуется заменить устаревшие версии некоторых из них более новыми.

Для приложений, использующих промышленные СУБД, есть возможность прописать в системе источник данных ODBC. Также можно добавить ярлыки установленной программы на «Рабочий стол». Если приложение требует внесения изменений, то в соответствующем разделе свойств пакета WinInstalLE можно указать нужную ветвь реестра. Аналогично, если необходимо запустить какие-либо сервисы, создать или внести изменения в ini-файлы. Естественно, при внесении каких-либо изменений в файл пакета вручную необходимо точно знать, к каким последствиям они могут привести.

Когда все изменения сделаны, в разделе «Actions» можно воспользоваться опцией Compress, которая позволяет сжать msi-файл. Также в этом разделе можно создать hash для файлов пакета.

После того как все действия по настройке установочного пакета произведены, для того, чтобы создать msi-файл, достаточно просто сохранить изменения. В результате получаем каталог, в котором находится msi-файл и также группа служебных файлов, которые требуются для установки. Для развертывания необходимо в Group Policy указать путь к msi-файлу.

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

Для создания пакетов посредством мониторинга изменений воспользуемся другой программой.

Отслеживаем изменения на лету

Программа FLEXnet AdminStudio Professional Edition 7.0 позволяет автоматизировать данный процесс. Данный программный продукт является коммерческим, испытательную версию можно получить по адресу [3], предварительно зарегистрировавшись, правда, следует отметить, что дистрибутив довольно большой, около 370 Мб, так как программа включает в себя массу различных функций.

Сборочную машину мы готовим аналогичным образом, то есть разворачиваем типовую конфигурацию.

Итак, после запуска Admin Studio мы попадаем на Start Page (см. рис. 3).

Рисунок 3. Главное меню FLEXnet

Из всего многообразия предлагаемых функциональных возможностей программы нас прежде всего интересует раздел «Package setup». В этом разделе нам предлагается сначала указать выполняемый файл дистрибутива приложения (как правило setup.exe), а затем – путь к файлу, содержащему новый установочный пакет. После этого необходимо нажать кнопку «Repackage», которая становится активной после указания требуемых путей. Следует также отметить, что мы можем использовать два метода мониторинга изменений в системе – это Installation Monitoring и Snapshot. По умолчанию предлагается использовать Installation Monitoring, нас это вполне устраивает. После нажатия «Repackage» нам предлагается указать номер версии, URL производителя и другие описания устанавливаемого приложения. Советую здесь вносить осмысленную информацию, так как потом эти описания будут выводиться в свойствах уже установленного приложения. Затем указываем путь, где будут храниться файлы, создаваемые в процессе установки приложения. После этого запускается установочный файл, и начинается процесс установки нашего приложения. При этом в процессе установки можно указывать необходимые настройки, путь для установки, править ярлыки для того, чтобы приложение было доступно пользователям на рабочем столе и т. д. После окончания установки появится окно с активной кнопкой «Process». Окончательно проверив, что наше приложение корректно установилось и запускается, можно нажать эту кнопку. Admin Studio произведет анализ изменений и затем запустит Repackager (см. рис. 4).

Рисунок 4. Свойства готового пакета

Здесь мы можем увидеть все изменения, которые были сделаны в системе в процессе установки. Меню аналогично тому, что есть в WinInstalLE, но с той лишь разницей, что все эти изменения были сделаны автоматически в результате мониторинга процесса установки. Если что-либо из предложенных изменений нас не устраивает, например, не надо создавать какие-то файлы, то здесь это можно подправить. Когда все необходимые изменения внесены, для окончательного создания установочного пакета надо нажать «Build» и затем сохранить изменения. В результате выполнения всех вышеперечисленных действий мы получаем готовый к развертыванию msi-пакет. Согласитесь, такой способ создания установочных пакетов намного эффективнее и быстрее предыдущего.

Дополнительные возможности

Следует особо упомянуть о дополнительных возможностях, которые имеются в FLEXnet Admin Studio. На стартовой странице Start Page есть возможность для пересборки уже готового установочного пакета Customize Package (например, для случаев, когда необходимо внести некоторые изменения не пересобирая при этом все заново). Также эта опция полезна, если требуется создать msi-файл для изменения исходного дистрибутива.

Следующей дополнительной возможностью является наличие такого средства, как resolve Conflicts, которое позволяет разрешать конфликты, которые могут возникнуть при установке нового приложения. Для того чтобы воспользоваться данной возможностью, необходимо выбрать на стартовой странице раздел «Resolve Conflicts», далее указать msi-файл и выбрать тип операции «ConflictSolver Operation». Стандартным средством является «Detect conflicts for this package». После нажатия «Perform» в открывшемся окне нужно нажать «Validation» для запуска процесса проверки содержимого пакета на наличие ошибок. Скорее всего, список сообщений не будет пуст, хотя это не означает, что все плохо. Сообщения могут информировать о дублировании некоторых файлов (например, установочные файлы могут дублироваться в каталоге LastKnowGood в системных папках Windows), аналогично могут дублироваться некоторые записи в реестре. Разрешить обнаруженные конфликты можно попробовать с помощью опции «Best Practices». Также в программе есть возможность определять возможные конфликты с уже установленными приложениями (раздел «Detect Conflicts»), правда, количество известных Admin Studio приложений, к сожалению, оставляет желать лучшего. Подробный отчет об обнаруженных в пакете конфликтах можно просмотреть, сохранить и распечатать в разделе Reports, причем отчет можно составить как для всего пакета, так и отдельно для файлов или реестра.

Еще есть возможность тестирования пакета с помощью опции Ensure Package Conflicts. Также можно подготовить пакет к распространению в разделе Prepare package for distribution. В этом разделе можно, к примеру, разместить готовый msi-пакет на FTP-сервере, в сетевой папке, а также подготовить развертывание с помощью уже упоминавшегося в начале статьи продукта Microsoft SMS.

Автоматизация управления лицензиями

На следующую дополнительную возможность программы FLEXnet AdminStudio хотелось бы обратить особое внимание, так как эта компонента представляет нам возможность контроля за лицензированием устанавливаемого программного обеспечения. «Выбрав Prepare Application for license Management», мы попадаем в окно управления лицензиями. Для начала нам необходимо указать msi-пакет и в открывшемся списке файлов выделить те файлы, которые отвечают за лицензирование приложения, как правило, это exeфайлы. В разделе «Set Limits» устанавливаем ограничения на количество лицензий, дату окончания действия, а также реакцию на случай достижения лимита лицензий. Раздел «define Access» позволяет задать ограничения на доступ к лицензиям для определенных узлов или пользователей. Наконец, в разделе «Configure Connection» нужно указать файл лицензий сервера FLEXnet. При первом запуске эту лицензию необходимо запросить по адресу, который также указан в данном окне. Завершающим этапом в настройке управления лицензированием является раздел «Finalize Package», в котором необходимо прописать папку, где будут создаваться новые пакеты. Когда все эти действия выполнены, нажимаем «Build Package». Если все настройки были заданы верно, то мы получим установочный пакет, лицензионные установки которого можно контролировать. Для получения отчета по использованию приложения нужно нажать «Creating application Usage reports with FLEXnet Manager». Таким образом, можно решить еще одну задачу системного администрирования – контроль за количеством установленных копий данного программного продукта.

Вернемся к Group Policy

Итак, мы рассмотрели несколько способов создания собственных установочных пакетов для нашего приложения. По моему мнению, FLEXnet Admin Studio является наиболее удобным и функциональным средством разработки своих msi-пакетов. Пакеты, созданные с помощью обеих программ, без проблем развертываются в группе, к которой применена данная политика. В случае, если приложение по каким-то причинам не установилось на компьютере, то причину сбоя следует искать прежде всего в журнале событий Event Viewer, в Application Log. Не забудьте, что размещать установочный пакет нужно в каталоге, к которому есть общий доступ пользователей из сети и, как уже упоминалось в начале статьи, в настройках Software Installation необходимо указать именно сетевой путь, а не локальный.

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

Использованные источники:

1. Windows Server 2003. Справочник администратора.

2. http://www.wininstall.com – сайт программы WinInstalLE.

3. http://www.macrovision.com – сайт программы FLEXnet Admin Studio.