Перед системным администратором порой стоит задача установить или обновить приложения на множестве ПК. И часто проблема состоит не в выборе средства доставки и автоматической установки — их есть множество на любой вкус, от встроенных в Windows OS (Active Directory) до полноценных Configuration Management систем, таких как MS SCCM, Enteo NetInstall, LanDesk Management Suite, HP Application Deployment Manager, IBM Tivoli Provisioning Manager, ManageEngine Desktop Central и много других…
Зачастую проблема состоит в том, что инсталляции приложений, которые предоставляет производитель, не всегда приспособлены для установки в автоматическом (unattended) режиме. В сети можно найти рекомендации, как подготовить к автоматической установке конкретное приложение. Иногда описанные рекомендации работают для определенной версии ПО, но для последующих версий — нет, или рекомендации сопряжены с приличными затратами времени по реинжинирингу инсталляции и создании msi пакета, используя WiX Installer или другие freeware тулы. В такой ситуации системному администратору приходится неоднократно повторять «танцы с бубном», пытаясь заставить непослушные приложения беспроблемно устанавливаться в unattended режиме.
К сожалению, в сети практически не встречается описание общих подходов и рекомендаций для подготовки приложения к автоматической инсталляции.
Эта статья ставит целью как раз восполнить этот пробел и описать best practices для подготовки unattended инсталляций, используемые в проектах «Инфопульса».
В подготовке приложений к автоматической установке стоит учитывать следующие особенности, связанные с тем, что приложение устанавливается не человеком, а специальным продуктом или функцией OS, работающими(ей) в автоматическом режиме.
- Приложение устанавливается под учетной записью, отличной от пользовательской учетной записи, под которой приложение будет запускаться. Например, если приложение не может работать без файла, который должен быть установлен %USERPROFILE%, то этот файл будет отсутствовать для пользователя, запускающего приложение, так как приложение было установлено под другой учетной записью (часто под local system account), для которой %USERPROFILE% ссылается на другую директорию.
- Приложение устанавливается под учетной записью, имеющей отличные права доступа, чем пользовательский аккаунт, под которым приложение будет запускаться. Например, если пользователь — член Users группы и не локальный администратор на своём ПК (что все чаще и чаще применяется в компаниях), то попытка приложения записать какие-то данные в per-machine ресурсы (HKEY_LOCAL_MACHINE, %ProgramFiles%, %SystemRoot%) будет неудачной на Windows XP, что приведет к ошибке в работе приложения. Для Windows 7 ситуация куда интереснее, там попытки процесса (запушенного в стандартном, не privileged режиме) записать данные в per-machine ресурсы будут перенаправлены в Virtual Store, что не всегда положительно сказывается на корректной работе некоторых приложений. Можно конечно отменить такое перенаправление, но тогда мы приходим к ситуации, которая описана для Win XP.
- Рабочий стол и окна приложений для учетной записи, под которой происходит unattended инсталляция, недоступны для пользователя. Поэтому если при запуске инсталляции в unattended режиме появляется сообщение об ошибке в виде модального окна, требующего реакции пользователя, — то реакции от пользователя не будет, так как пользователь на своем рабочем столе не видит это окно. Это обычно заканчивается тем, что пользователь вечером выключает свой ПК (или системный администратор снимает процесс), процесс инсталляции прекращается не завершившись и на следующий день Service Desk имеет «головную боль» от пользователя (или пользователей!), жалующихся на неработающее приложение.
Из описанных выше особенностей вытекают требования и рекомендации к подготовке инсталляций к автоматическому развертыванию.
- Если приложение требует обязательно наличие per-user ресурсов (HKEY_CURRENT_USER ключей, файлов в % USERPROFILE%) и не может без этих ресурсов работать, то unattended инсталляция должна обеспечивать установку таких ресурсов для каждого пользователя, запускающего приложение, в том числе и для вновь созданных пользователей.
Для терминальных серверов есть свои подходы и тулы для решения этой задачи. Для рабочих станций вам поможет либо Active Setup, либо использование Self-Healing и Advertised shortcuts для msi инсталляций. Но в этом случае msi инсталляция должна соответствовать требованиям Microsoft и, соответственно, не иметь ошибок в msi таблицах, что случается достаточно редко: ну кто из разработчиков инсталляций серьезно относится к каким-то там требованиям Microsoft, многие об этих требованиях даже не догадываются.
Чтобы Self-Healing и Repair работал нормально, нужно проверить msi файл на наличие ошибок (это можно сделать, используя Orca или InstEd! тулы) и исправить ошибки в msi базе. Но подавляющее большинство администраторов идет по другому пути — пытается отменить создание advertised shortcuts для msi инсталляций (например, через DISABLEADVTSHORTCUTS property), естественно, теряя при этом возможность автоматической установки/обновления per-user ресурсов для пользовательского аккаунта. - Если приложение записывает данные в per-machine ресурсы в процессе своей работы, а пользователи не имеют привилегий локального администратора, необходимо обеспечить точечную установку прав на запись на изменяемые приложением per-machine ресурсы для пользователей при работе на Win XP. Для Windows 7 нужно проверить, как работает приложение при включенном UAC и в режиме перенаправления записи per-machine файлов и реестра в Virtual Store. Точечную установку прав на запись на изменяемые приложением per-machine ресурсы желательно включить в сам пакет (или скрипт, cmd файл) unattended инсталляции. Для целей точечной установки прав записи на определенные ресурсы подходят тулы subinacl, setacl, secedit. Последний предпочтительнее, так как встроен во все версии Windows OS, но более сложен в использовании, так как требуется умение писать inf файлы для него.
- Важно убедиться, что exe инсталляция не выдает сообщений об ошибках в виде окон, требующих взаимодействия с пользователем, если включена опция вывода сообщений в log файл и опция установки в unattended/silent режиме. Обычно сообщения об ошибках возникают либо при отсутствии необходимых ресурсов, либо при невозможности обновить устанавливаемые файлы. Поэтому чтобы убедиться, что все сообщения об ошибках сохраняются в log файле и не появляются в виде окон, необходимо специально сымитировать ошибку для unattended инсталляции, например, переместив/переименовав/удалив файл, продукт или ключ в реестре которого требуются для успешной инсталляции программы. Для msi инсталляций следует использовать /qn опцию командной строки или LIMITUI property для подавления всех окон пользовательского интерфейса.
- Стоит отменить принудительный restart OS, который может инициировать exe процесс инсталляции. Во-первых потому, что этот процесс может быть не последним в списке приложений, устанавливаемых автоматически. А во-вторых, в это время с системой может работать пользователь, для которого неожиданный restart системы может стать неприятным сюрпризом. Для msi инсталляции это достигается путем установки REBOOT property в значение ReallySuppress.
- Если приложение требует дополнительной настройки после инсталляции, то такая настройка должна быть включена в unattended инсталляцию. Можно, конечно, устанавливать ненастроенное приложение, а потом отсылать пользователям инструкцию как его настроить, но тем самым вы значительно повышаете риск иметь криво настроенное приложение у пользователей. Ну а криво настроенное приложение, конечно, усложняет работу службы поддержки, и чем больше пользователей, тем сложнее жизнь у helpdesk-а…
- Важно убедиться, чтобы unattended инсталляция поддерживала также unattended режим деинсталляции и восстановления (Repair). Многие производители ПО, предоставляющие exe инсталляцию, поддерживающую опции командной строки для unattended/silent установки, забывают про unattended/silent деинсталляцию, что может создавать определенные проблемы, особенно если количество ПК, на которых нужно удалить софт насчитывает сотни или тысячи.
Очень важен процесс тестирования unattended инсталляций, так как от этого зависит качество и стабильность автоматического обновления ПО. И чем больше количество ПК, тем более вероятны «сюрпризы». Поэтому для предупреждения ошибок, стоит по возможности тестировать unattended инсталляцию, придерживаясь следующего сценария:
- Подготовили install.cmd и uninstall.cmd файлы для unattended установки
- Подготовили систему (или виртуальную машину), максимально близкую по конфигурации к корпоративной OS, на которой работают пользователи
- Копируем файлы инсталляции вместе с install.cmd и uninstall.cmd в локальный каталог
- Запускаем install.cmd под local system учётной записью, например, через Psexec.exe -i -s <executable>
- Ждем завершения процесса
- Анализируем log файл
- Создаем нового пользователя, члена Users группы
- Заходим в систему под этим пользователем, запускаем приложение
- Если в инсталляции предусмотрели автоматическую конфигурацию приложения, проверяем, чтобы приложение было правильно сконфигурировано.
- Выполняем тестирование работы приложения (основные функции), меняя конфигурацию приложения в доступных пользователю пределах.
- Закрываем приложение, открываем опять и проверяем, чтобы приложение было запущено с сохраненной конфигурацией.
- Делаем logoff для пользователя, заходим как администратор
- Запускаем uninstall.cmd под local system account
- Ждем завершения процесса
- Анализируем log файл (Если log файл не генерируется для деинсталляции, это для нас неприятный момент, означающий, что мы не сможем анализировать ошибки, возникшие при unattended деинсталляции)
- Заходим под пользователем, проверяем, чтобы приложение было деинсталлировано, все линки (.lnk файлы) на приложение удалены из Start menu, quick launch, desktop
- Смотрим отсутствие файлов приложения в %ProgramFiles%
Стоит заметить, что обоснованность усилий и времени, которые вы тратите на подготовку и тестирование unattended инсталляции зависит от количества ПК, на которых вы планируете установить приложение и от сложности самого приложения.
Если количество ПК небольшое или приложение сложное и требует много времени на подготовку, то разумным является все-таки ручное обновление ПО на каждом ПК.
Но если количество ПК превышает 300–400, и количество ПО, которое нужно регулярно обновлять, тоже не маленькое, то есть смысл в выполнении этих рекомендаций, так как ручная установка займет больше времени, чем подготовка и тестирование unattended инсталляции с последующей автоматической установкой.
