Создание файлов .msi

posted in SoftWare, Windows |

Как подготовить старые приложения к работе с Windows Installer с помощью WinINSTALL LE

Любой инструмент, облегчающий инсталляцию – а еще важнее, удаление программ – приносит ощутимую пользу. Поэтому мне нравится принцип универсальности, заложенный в файлах Windows Installer (.msi-файлах). Но готовые к работе с Windows 2000, приведенные к типу .msi приложения встречаются редко, поэтому каждый, кто хочет широко использовать файлы.msi, должен научиться создавать их. Это позволяет делать поставляемый вместе с Windows 2000 Server инструмент WinINSTALL Limited Edition (LE) фирмы VERITAS Software, обеспечивающий преобразование в .msi-формат. Однако процесс создания безупречного .msi-файла требует времени и усилий.

Когда-то для установки приложения было достаточно скопировать на жесткий диск пару файлов, возможно, указав при этом другой каталог. Но большинство современных прикладных программ состоит из множества файлов, в том числе отдельной программы специально для установки приложения. Как правило, программы установки выполняют несколько функций. Во-первых, они создают один или два каталога программы для хранения программных файлов и данных. Во-вторых, они размещают динамические библиотеки (DLL) на жестком диске машины, но не всегда в каталогах нового приложения; часто DLL размещаются в каталоге \winnt или \winnt\system32 (несмотря на возможность конфликтов прикладных DLL, сохраненных в этих каталогах, с библиотеками DLL операционной системы и других приложений). В-третьих, большинство приложений ассоциированы с определенными расширениями файлов и должны сохранить ряд параметров конфигурации, поэтому программа установки заносит расширение файла и параметры конфигурации в реестр. Наконец, инсталляторы приложений обычно помещают отдельный пункт в меню Start, Programs. Из этого перечня операций видно, почему программы установки так велики – им необходимо выполнять множество задач.

Администратору неудобно переносить программу установки и сопутствующие файлы на настольный ПК каждого пользователя и лично контролировать процедуру установки, ему нужен централизованный способ установки прикладных программ без вмешательства пользователя. Такой функциональностью располагает Active Directory (AD), но пользоваться файлами установки нелегко; для AD предпочтительны приложения в формате .msi. Но большинство поставщиков пока не выпускает свои продукты в .msi-формате. Поэтому, чтобы использовать AD для развертывания приложений, необходимо преобразовать большинство из них в формат .msi. WinINSTALL LE бесплатно поставляется в составе Windows 2000 Server (в папке \valueadd\3rdparty\mgmt\winstle на компакт-диске с Windows 2000), и многие администраторы отдадут предпочтение именно этому решению.

СТРОИМ ПАКЕТ .MSI

Для создания .msi-файлов в WinINSTALL LE используется метод моментального снимка, проверенный временем способ описания и инкапсуляции приложений. Чтобы сгенерировать .msi-файл для прикладной программы, следует приступать к работе на <чистом>, ранее не эксплуатировавшемся настольном ПК, который я называю прототипом – я всегда пользуюсь утилитой Symantec Ghost или службами Microsoft Remote Installation Services (RIS), чтобы очистить диск прототипа и начать с чистого листа.

Прежде чем инсталлировать приложение, следует запустить программу discoz.exe пакета WinINSTALL LE, которая составляет список файлов, каталогов и элементов реестра на прототипе – другими словами, discoz.exe генерирует моментальный снимок исходного состояния системы. Затем на прототипе устанавливается новое приложение и проводится его настройка в соответствии с требованиями пользователя. Для фиксирования любых изменений реестра компьютер следует перезагрузить – иногда эта операция необязательна, но она никогда не вредит. Затем программа discoz.exe запускается вновь. Она генерирует постинсталляционный моментальный снимок, отмечая все новые файлы, изменения в реестре и программные ярлыки. Discoz.exe собирает всю информацию об изменениях в указанном пользователем месте и строит соответствующий .msi-файл. В .msi-файле содержится информация об изменениях каталогов, файлов и реестра, а также набор инструкций для Windows Installer.

Я опускаю подробности работы Windows Installer, ограничившись двумя рекомендациями. Во-первых, при подготовке WinINSTALL к созданию предварительного моментального снимка программа спрашивает, следует ли выполнить расширенную проверку реестра (Enhanced Registry Scan). Проверка всегда полезна, этот флажок следует отметить. Во-вторых, система подсказки WinINSTALL предлагает не держать discoz.exe на прототипе. Лучше установить discoz.exe на другом ПК и выделить в общее пользование каталог программы в каталоге \Program Files второго компьютера. Следует подсоединиться к этому общему каталогу и запустить discoz.exe из него.

ИНСТАЛЛЯЦИЯ ПАКЕТА

Теперь пришло время взглянуть на каталог .msi-файла, в котором отражены файлы и структура устанавливаемого приложения. Работая над данной статьей, я создал .msi-файл для Lotus Organizer 6. Данный пакет содержал каталог с именем Lotus, и применение .msi-файла заставляет Windows Installer создать и заполнить файлами каталог с этим именем. В моем пакете есть также каталог с именем \winnt, из чего я заключил, что фирма Lotus создала Organizer с нарушением правил установки. Из каталога .msi-файла можно узнать и точный объем пространства, занимаемого приложением на жестком диске – в .msi-файле нет сжатых файлов, которые уменьшают размер установленного приложения.

Получив .msi-версию прикладной программы, можно инсталлировать приложение одним из трех способов. Во-первых, просто дважды щелкнуть на msi-файле. Во-вторых, использовать команду Msiexec /i, чтобы неявно загрузить файл из командной строки. Например, команда, показанная на Экране 1, инсталлирует пакет pilotdesk.msi из каталога \pilotdesk в каталоге приложений на server1 (как и большинство параметров команд в Windows, ключ /i нечувствителен к регистру.) В-третьих, можно воспользоваться политиками Group Policy, чтобы создать политику развертывания программного обеспечения (это тема для отдельной статьи).

После ряда экспериментов я убедился, что Windows Installer нельзя вызвать двойным щелчком на .msi-файле или командой Msiexec /i из командной строки: эти методы не позволили инсталлировать Organizer, когда я зарегистрировался в качестве пользователя без административных полномочий. Но когда я задействовал групповую политику Group Policy для нового .msi-файла, чтобы назначить Organizer тому же пользователю, а затем зарегистрировался от имени этого пользователя, и выбрал пункты меню Start, Programs, Organizer, то Organizer был установлен без проблем.

Почему же мне не удалось инсталлировать .msi-файл Organizer двойным щелчком мыши или по команде Msiexec? Во-первых, программа Setup приложения Organizer размещает некоторые файлы в каталогах \winnt и \winnt\system32, а по умолчанию пользователи без специальных полномочий могут только просматривать файлы в этих каталогах. Во-вторых, программа Setup приложения Organizer производит запись в два раздела реестра: HKEY_LOCAL_MACHINE\SOFTWARE и HKEY_CURRENT_USER\Software. Для каждой учетной записи пользователя имеется собственный раздел HKEY_CURRENT_USER\Software, в который пользователи могут беспрепятственно вносить изменения. Но только владелец учетной записи System и члены локальной группы Administrators могут производить запись в раздел HKEY_LOCAL_MACHINE.

Тогда почему же удалось успешно провести инсталляцию с помощью Group Policy? Потому что операционной системе не было известно, что Msiexec выполнялась по запросу от имени моей учетной записи. Windows 2000 исходила из того, что Msiexec была запущена с учетной записью System, которая имеет право выполнять запись в каталоги \winnt и \winnt\system32. Windows Installer организован в виде службы отчасти потому, что Windows Installer может работать с учетной записью пользователя, отличной от записи пользователя, зарегистрировавшегося на рабочей станции в данный момент. Windows Installer может работать даже в случаях, когда на компьютере не зарегистрирован никто, например, в случае с такими службами, как Microsoft IIS.

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

Автоматический вызов некоторых других приложений, для которых мною были созданы .msi-файлы, происходил по другой причине: им соответствовали элементы в менее известном разделе HKEY_CURRENT_USER\Software\Microsoft\ Windows\CurrentVersion\Run (элементы некоторых программ могут размещаться и в файле параметров конфигурирования win.ini, хотя я не встречал их уже несколько лет). Из всего сказанного можно сделать вывод, что нужно быть готовым несколько раз перестраивать .msi-файл, не забывая каждый раз проверять его.

ИСПОЛЬЗОВАНИЕ ПОДРУЧНЫХ СРЕДСТВ

Мне часто задают вопрос, зачем нужно предоставлять учетные записи уровня Administrator пользователям, разрешая им устанавливать программы на своих машинах. Теперь ответ на этот вопрос очевиден: подобно Lotus Organizer, многие программы установки приложений производят запись в каталоги и разделы реестра, недоступные пользователям, не имеющим административных прав. Но приложениям нет необходимости размещать DLL в системных каталогах или записывать элементы в раздел реестра HKEY_LOCAL_MACHINE.

Если необходимо использовать приложение, которое инсталлирует DLL в системном каталоге, можно попробовать два приема. Во-первых, следует попытаться переместить все файлы, записанные приложением в каталоги \winnt и \winnt\system32, в каталог приложения. После того, как я проделал эту операцию, Organizer продолжал работать. Во-вторых, можно переименовать раздел приложения в разделе HKEY_LOCAL_MACHINE\SOFTWARE (если программа установки переименовала какие-нибудь разделы) и посмотреть, будет ли приложение работать по-прежнему. Organizer не работал. Другой вариант – добавить локальную группу Authenticated Users в группу пользователей, имеющих право вносить изменения в HKEY_LOCAL_MACHINE\SOFTWARE, хотя при этом несколько понизится уровень безопасности системы. Но самое лучшее решение – известить поставщиков ПО, что вы не купите следующую версию программы, если она не будет выполнена в соответствии со спецификациями Windows 2000.

Марк Минаси
16.10.2001

Марк Минаси – редактор Windows NT Magazine, имеет сертификат MCSE; является автором книги “Mastering Windows NT Server 4.0″ (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com.