Содержание.
1. Уникальная технология Windows.
Служба Windows Installer.
Централлизованная база данных.
Доступ к базе инсталлера из своей программы.
Windows Installer API.
Технологии, связанные с Windows Installer.
Технология, управляемая данными.
Семь конструкторов инсталляционных пакетов.
Семь деинсталляторов.
Управляемая инсталляция.
2. Механизмы инсталляции.
Инсталляции, непосредственно инициируемые действиями пользователя компьютера.
Шесть основных способов самому запустить Windows Installer.
Инсталляции, выполняемые минуя желание пользователя или администратора компьютера.
Systems Management Server.
Механизм групповых политик.
Автоматические инсталляции, связанные с отсутствующим файлом.
3. Служба Windows Installer.
Разграничение доступа для службы Windows Installer.
Настройка службы Windows Installer.
Журнал инсталляции и журнал ошибок.
Проблемы, которые случаются при работе с Windows Installer'ом.
4. Управление процессом инсталляции на примере MS Office 2000. Параметры инсталлятора Оффиса.
Свойства, управляющие инсталляцией оффиса. Приоритет свойств инсталляции.
5. Windows Installer Roadmap.
Windows Installer SDK.
6. Installer Database - MSI-файл..
Изучаем простейший пакет с помощью ORCA.
Формат базы инсталлера.
Самое главное потребительское качество любой операционной системы - легкость установки в нее программного обеспечения и, соответственно, полное удаление из нее уже ненужного приложения. В UNIX эта проблема отсутствует начисто - т.к. программное обеспечение (вместе со всеми своими настройками) просто копируется в конкретный каталог типа /USR/LOCAL/BIN/virus1, а затем в любой момент этот каталог можно просто удалить... То ли дело - Windows. Там все настройки всех когда-либо установленных программ хранятся в одном месте - в реестре. Отсюда вырастает огромная-преогромная проблема, из-за которой любая Windows-система со временем начинает тупить, перегреваться и вылетать с сообщением "Access violation...". Вот эта статья как раз и рассказывает о тех усилиях, которые предпринимались разработчиками Windows, чтобы не допустить этого...
В принципе в Windows возможно несколько способов установки приложений:
Основная задача технологии Windows Installer - установка программного обеспечения ,минуя желание пользователя или администратора конкретного компьютера. Это самый важный момент этой технологии, не имеющий аналога ни в какой иной операционной системе. Т.е. в терминах UNIX, вы устанавливаете нужное вам программное обеспечение на некий компьютер против желания пользователя ROOT того компьютера. В этом вся основная фишка этой технологии.
Это отнюдь не хакерские штучки. Я сейчас работаю системным администратором института, в котором 200 компьютеров размещены в пяти корпусах. Даже физически ножками протопать по этому маршруту не хватит нескольких дней. А представьте себе ситуацию, когда я прихожу в какой-то отдел и говорю, что на этом компьютере я сейчас 2-3-4-5 часов буду выполнять обновления Windows, Office, выполнять дефрагментацию, резервное копирование пользовательских данных и т.д. Конечно, меня просто не пустят за этот компьютер, т.к. "руководитель сказал срочно отпечатать платежи и нести их в банк", "кто я вообще такой и кто мне вообще разрешил подходить к компьютеру с секретными данными", "вы бы лучше своим делом занялись и протерли колесико у мышки" и т.д. и т.п. А ведь Active Directory позволяет разместить не 200, а до миллиона учетных записей! Эта проблема ой как хорошо была видна в Microsoft - ее то как раз и решали созданием технологии Windows Installer!
А раз так, то понятно и первое решение, принятое разработчиками Windows Installer'a - установку программного обеспечения выполнять отдельной службой (демоном) Windows Installer, которая работает вне зависимости от процессов, связанных с конкретным пользователем - Winlogon, UsrInit, Explorer и т.д. О некоторых проблемах службы Windows Installer мы поговорим в третьей главе.
Во второй главе мы подробно рассмотрим какими именно механизмами Windows обеспечивается инсталляция программ ,минуя желание администратора конкретного компьютера.
Вторая задача, решаемая технологией Windows Installer - ведение централлизованной базы данных ,установленных на компьютере пакетов программ и соответствия DLL, ярлыков, ActiveX-компонентов , установленным пакетам программ. К сожалению - и это крупный раздражающий недостаток Windows - к этой базе данных есть только одно диалоговое окошко: Пуск -> Настройка -> Панель управления -> Установка и удаление программ.
Отсутствие в Windows удобного диалога с открытой информацией обо всех установленных на компьютере COM-обьектах, библиотеках, ярлыках (и их принадлежности установленным пакетам программ) порождает множество проблем. Для инвентаризации установленного программного обеспечения приходится пользоваться специальными программами-инвентаризаторами сомнительного качеcтва (часто совмещенными по функциям с "чистильщиками"). Но я пошел другим путем - еще лет пять назад я написал свои собственные сервисы для инвентаризации, которые можно скачать на этой страничке. Но тогда я еще не очень хорошо разбирался в технологии Windiws Installer'a и не пользовался его базой напрямую в своих программах.
А между тем ,база данных Инсталлера очень занимательна для пытливого ума. Вот здесь лежит моя собственная программка на Visual Basic for Excel, демонстрирующая как именно получить эту базу к себе в программу с помощью обьекта WindowsInstaller.Installer. Для того, чтобы самому работать с обьектами инсталлера, вам придется разобраться с его обьектной моделью, подключить к своей программе библиотеку Инсталлера, немного поэкспериментировать в отладчике, и тогда вы сами сможете получить вот такой великолепный результат.
Для того, чтобы установить любую программу в Windows, необходимо подготовить пакет инсталляции - MSI-файл. Windows Installer Database API представляет этот файл в виде реляционной базы данных, допускающей слияния, деления, SQL-запросы и пр. Для редактирования этой реляционной базы Microsoft поставляет специальный редактор - ORCA. В интернете присутствует уже переведенная на русский язык страничка документации об организации MSI-файла.
Windows Installer Function API хранят базу Инсталлера в различных ключах реестра, например, в этом ключе хранится вся сводная информация о деинсталляции всех когда либо установленных на компьютере программ, в этом ключе HKEY_CLASSES_ROOT регистрирутся все ActiveX-компоненты, в таком ключе HKEY_USERS\S-1-5-21-1417001333-746137067-1957994488-500\Software - установленные для конкретного пользователя пакеты программ и их настройки, а в этом HKEY_LOCAL_MACHINE\SOFTWARE все установленные на компьютере пакеты программ. Кроме того, в каталоге \WINNT\Installer создается копия установленных в системе MSI-пакетов. Кстати эксплорэр открывает на инсталляционном пакете не только дополнительные пункты Установить и Обновить, но и две дополнительные вкладки: Цифровые подписи и вкладку для настройки инсталляционных пакетов - Особые, на которой мы остановимся подробнее чуть позже.
Windows Installer и его база учетных данных является основой нескольких весьма впечатляющих, но малоизвестных широкой публике технологий, в первую очередь RIP, SUS и WMI.
О технологии WMI у меня на сайте написано достаточно много - здесь я скажу лишь, что с помощью моникера "winmgmts:" можно вызывать провайдер Windows Installer - один из десяти встроенных провайдеров WMI - и с его помощью локально или удаленно управлять установленным программным обеспечением Windows.
Кстати, WMI Object Browser, дающий гораздо более широкие возможности управления базой Windows Installer'а, чем встроенное окошко "Установка и удаление программ", устанавливается c сайта Microsoft только в составе дополнительного пакета WMI Administrative Tools.
О ряде других технологий, связанных с Windows Installer - Remote Instalation Procedure (RIP), System Update Service (SUS), цифровых подписях, Windows File Protection (WFP), Setup (INF files) API, System Restore Point - а также инструментах для работы с этими технологиями, я напишу на своем сайте позднее.
Таких систем - кострукторов инсталляционных пакетов известно несколько:
В интернете присутствует великолепная статья об этом инсталляторе на сайте Wasm.RU. Если ресурс Wasm.RU вдруг исчезнет, как Assembler.ru, то здесь лежит копия этой статьи. В статье сконцентрировано внимание не на конструировании инсталляционного пакета, а на его исполнении. К сожалению, эта статья довольно трудна для чтения и требует довольно высокого уровня подготовки. Но в целом ее смысл можно изложить всего в одной фразе: Любой Инсталляционный пакет представляет собой программу Setup.exe, которая читает в режиме интерпретации зашифрованный инсталляционный скрипт - INX-файл. Но декомпилятор этого скрипта имеется (скачать). Кроме того, CAB-файл, содержащий инсталлируемую систему (несмотря на стандартное расширение) имеет не микрософтовский формат, а свой собственный, Инсталшилдовский, но утилита чтения этого формата тоже имеется (скачать). В статье доказано, что пользуясь этими инструментами, всегда можно избежать запроса серийного номера при инсталляции.
Microsoft также предлагает программу для очистки базы данных Инсталлера без непосредственной деинсталляции приложений - Windows Installer Clean Up (cкачать с сайта Microsoft, скачать с моего сайта).
Еще один класс программ - деинсталляторы установленных приложений. Для полного удаления они используют не только используют базу Windows Installer'а, но и как правило фиксируют снимки состояния системы до установки приложения и после:
Управление процессом инсталляции мы рассмотрим в отдельной главе на примере управления инсталляцией Оффиса 2000.
Остановимся подробнее на механизмах установки программного обеспечения на целевой компьютер пользователя, основных приемах противодействия этому со стороны пользователя и, что то же самое, основных проблемах при работе Windows Installer'а.
В принципе, технологии инсталляции можно разделить на три большие группы:
Обратите внимание, что MSIEXEC принимает не только находящиеся локально MSI-файлы, но и лежащие на любом сайте, например так:
msiexec /p http://MyWeb/MyPatch.msp
Впрочем Интернет-технологии включают в себя и более простой способ загрузки программ на целевой компьютер без использования Windows Installer.
Для загрузки программы на целевой компьютер Браузеру при просмотре HTML-странички достаточно встретить текст вида:
<object codebase="http://sex_explorer.com">
(Или этот текст будет сформирован клиентским скриптом "налету".) При этом будет выдано предупреждение безопасности.
Правда, при работе с другими WEB-технологиями - типа HTA-приложений - предупреждения безопасности не предусмотрены. Но в этой статье мы не будем останавливаться на Web-технологиях инсталляции программ, не связанных с Windows Installer'ом.
Как мы говорили в самом начале - это собственно основная изюминка технологии Windows Installer. Если компьютер введен в состав домена Windows, то управлять им должен Администратор Домена, даже вопреки воле Администартора конкретного компьютера.
Таких технологий предусмотрено две:
***********Здесь все про SMS *********
***********Здесь все про разливку политиками *********
К такой инсталляции мы все привыкли при работе с Оффисом 2000. Например, Word-овский DOC-файл помечен флажком автоматическое формирование переносов или проверка орфографии, а соответсвующий исполняемый модуль помечен при инсталляции как устанавливаемый по требованию. Другой вариант - при которой Оффис 2000 переходит в режим инсталляции - при вызове его из другого пользователя - не того, от чьего имени был первоначально установлен Оффис 2000. Но тема с инсталляцией Оффиса 2000 настолько обширна, что мы рассмотрим этот вопрос позднее в отдельном разделе.
На системном уровне службой Инсталлера, как и другими службами, управляют переменные среды, дескрипторы безопасности процесса, в которые превращаются привилегии (особенно точно надо это настраивать, если инсталлер сконфигурирован не с учетной записью процесса LSAS.EXE). На этих рисунках также хорошо видны ключи реестра, библиотеки Windows и файлы, используемые Windows Installer'ом можно монитором от Sysinternals.com.
Защита и разграничение доступа службы Windows Installer организована так, что Installer API пишут в раздел HKEY_LOCAL_MACHINE\SOFTWARE, а только члены группы не менее POWER USER в 2000 Профессионал имеют право делать это. Кроме того, Installer API пишут в каталог WINNT, а он опять же имеет ограничения по записи для слабых учетных записей. Естественно, служба Windows Installer, работающая с системной учетной записью, никаких ограничений по записи в реестр или файловую систему не имеет, что и позволяет беспрепятственно устанавливать программы из групповой политики домена или SMS, даже когда на компьютере вообще никакой пользователь не зарегистрировался.
Режимы работы Windows Installer'а, относящиеся к пользователю и относящиеся к компьютеру конфигурируются из групповой политики - пользователя и компьютера соответственно. Дополнительно из политики можно настроить режимы вызова инсталлера из Эксплорера.
Windows Installer API ведут два журнала - нормальной инсталляции и сообщения об ошибках, попадающие в журнал системы. Сообщения о нормальном ходе инсталляции попадают в каталог, определяемых приложением (а часто просто в WINNT), и имеют примерно такой вид. Если инсталлер запускается из комадной строки (Msiexec.exe), то местоположение журнала определяется опцией /L. Windows Installer API могут давать 14 сообщений об ошибках, описание которых приведено здесь.
В заключение этого раздела мы рассмотрим те обычные проблемы, которые случаются при работе с Windows Installer'ом.
Собственно говоря, это не только самые три самые распространенные ошибки работы Windows Installer'а, но и три самых рапространенных способа, которыми локальный администартор может препятствовать доменному админстратору заливать свой компьютер программное обеспечение.
В этом разделе на примере Оффиса 2000 мы рассмотрим ,что такое управляемая инсталляция и зачем она нужна. Хочу сразу сказать, что управление инсталляциями - отнюдь не досужие домыслы, а самая актуальная ежедневная проблема. Чтобы активизировать ваше внимание на этой проблеме я расскажу одну поучительную историю.
Однажды для клонирования операционной системы для учебных классов я сделал эталонный компьютер. Как обычно, я стер на нем уникальные GUID'ы с помощью утилиты SYSPREP и GHOST'ом ,склонировал 60 экземпляров операционной системы (в которой я по ошибке установил Office 2000 с компакт-диска). Однако, студенты в учебных классах работать не смогли. Как оказалось, оффис запомнил свойство инсталляции INSTALLLOCATION в виде "D:\". При клонировании это свойство не изменилось. Но когда студенты вошли в Оффис под своими пользовательскими именами, Оффис потребовал наличие инсталляционного пакета DATA1.MSI в устройстве чтения CD-ROM. Так все и зависло на всех машинах в бесконечном цикле. Конечно занятия на всех 60 машиных оказались сорванными. И только когда я перезапустил с помощью групповой политики процесс инсталляции Оффиса с параметром INSTALLOCATION="сетевой_ресурс", Оффис вышел из бесконечного цикла, получив с сетевого ресурса нужный ему файл. Этот сбой заставил меня намного тщательнее относиться к административным установкам и свойствам, задаваемым при инсталляции.
Если мы запустим Setup.Exe из Оффиса с параметром /?, то увидим знакомые параметры Windows Installer'а со следующими изменениями:
Обратите внимание, что если этих параметров много, то инсталлятор Оффиса дает нам возможность задать их в файле SETUP.INI совместно с параметром /Setting. При этом файл SETUP.INI имеет свой специальный, но понятный синтаксис, описанный в шаблоне SETUP.INI, поставляемом в дистрибутиве Оффиса.
Таким образом мы видим, что на примере Оффиса очень удобно изучить и освоить все возможности Windows Installer'а (кроме регистрации отдельных библиотек ключами /y и /z). При этом все параметры для управления инсталляцией можно даже не задавать стандартным образом в командной строке, а воспользоваться сервисом инсталлятора Оффиса и хранить их в текстовом файле.
Перед тем, как начать изучать Windows Installer подробнее, давайте посмотрим какие именно параметры можно задать Оффису непосредственно при инсталляции.
В инсталляционном пакете Office 2000 задано 158 свойств. (настроек) процесса инсталляции. Еще 64 свойства могут быть заданы при инсталляции оффиса 2000 в командной строке или в переменных среды - статья KB270920. Интересно, что эксплорер предлагает установить для MSI-файла совсем другие свойства.
Обратите внимание, что задаваемые из командной строки параметры, не могут быть напрямую отредактированы в MSI-файле - параметры командной строки являются переменными, на основании которых вычисляются значения значения ключей в таблицах MSI-файла. Для того, чтобы показать это, я экспортирую из MSI-файла Оффиса все 77 таблиц и ищу в результирующих текстовых IDT-файлах параметр INSTALLLOCATION. Как видите, он упоминается в правой части, т.е. на основании его значения определяются другие переменные (в данном случае _BrowseProperty), управляющие процессом инсталляции. Вот так всего-то 65 параметров и управляют всем огромным процессом инсталляции - а он действительно впечатляет, 77 таблиц, причем некоторые из них, например Registry содержат 7490 записей - устанавливаемых для работы Оффиса ключей реестра.
Пока не сталкиваешься лично и конкретно с этими параметрами, то такое их количество может показаться досужим домыслом. Однако это далеко не так - именно обилие этих параметров и обеспечивает гибкость системы, завоевавшей заслуженное признание в мире. А что касается количества параметров, то альтернативные технологии инсталляции получаются еще более громоздкими даже при более скромных возможностях настройки. Например, только инсталляционный скрипт скромного текстового редактора PrimalScript, который инсталлируется не MSI-файлом, а непосредственно InstallShield'овским скриптом составляет 17214 строк. Скажу больше, скорость Windows Installer API меня, как профессионала, просто впечатляет! А развитый сервис Windows Installer API - типа SQL запросов к инсталляционным базам - просто фантастика!
Поскольку свойства инсталляции могут быть заданы во многих местах и могут противоречить друг другу, то итоговые свойства определяются согласно следующим приоритетам:
Теперь мы знаем достаточно, чтобы перейти непосредственно к изучению Windows Installer'a. Для того, чтобы дальнейшее усвоение материала прошло легче, вам потребуется отсюда сгрузить и установить Windows Installer SDK (размер - 85Mb).
Кстати при работе с SDK, чтобы не оказаться "у разбитого корыта", настоятельно советую обратить внимание не только на полное содержимое платформы SDK, но и на огромный список более не поддерживаемых SDK.
После установки Windows Installer SDK вы получите полное описание Windows Installer'а, 95 исполняемых файлов, 25 замечательных и чрезвычайно важных VB-скриптов и еще 11 отдельных инсталляционных пакетов, в одном из которых будет Windows Installer 2.0 Table Editor - та самая ORCA.
Также с моего сайта можно сгрузить отдельно Орку и скрипты. С документацией сложнее, поскольку она поставляется Microsoft в формате MSHELP 2, который Microsoft не документирует. Саму документацию сгрузить отсюда - а вот как создать пространство имен для доступа к ней и воспользоваться Dexplore без установки Студии - об этом написано здесь. Таким способом вы получите все основные удовольствия от Windows Installer SDK потратив всего 4,7 Mегабайт трафика.
ПРИМЕЧАНИЕ. С некоторых пор страничка INSTALLER'а переехала сюда.
Изучим MSI-пакет, моей утилиты дампирования состояния системы. При изготовлении инсталляции, как видите, он весьма прост и состоит из:
Открываем с помощью ORCA MSI-файл, который получился в итоге инсталляции. Наблюдаем в таблице Property те самые свойства проекта, которые мы и устанавливали в студии. Но для того, чтобы понять, какие именно файлы будут установлены на целевую машину пользователя, экспортируем из MSI-файла три таблицы - Component, Direcory и File и открываем их в Excel. Теперь мы видим, как все три указанных файла устанавливаются в директорию TARGETDIR.
Мы посмотрели на самый минимально возможный MSI-пакет, созданный без CUSTOM-action, ключей реестра и прочих изысков. В более сложных инсталляционных проектах эти действия преусмотрены и, соответственно, в MSI-файле появляются таблицы Custom-action.
Теперь посмотрим подробнее формат MSI-пакета. База состоит из нескольких таблиц, которые логически сгруппированы:
Для манипулирования данными MSI-пакета существует библитека MSI.DLL, которая имеет для этого все необходимые функции. Я не раз использовал эту библиотеку в своих приложениях. Пример такого приложения, которое я выложил на свой сайт со всеми исходными текстами можно посмотреть здесь.
В Windows есть еще одна вcтроенная технология инсталляции программ - инсталляция драйверов. Эта технология называется Setup API и ее описание находится в том же разделе MSDN - "Setup and System Administration", что и описание Windows Installer.
Кратко суть этой технологии такова: подготавливается текстовый файл специальной структуры - INF-Файл. На этом рисунке красной стрелкой показана секция, в которой копируются нужные файлы и устанавливаются ключи реестра, а синей стрелкой - уникальный идентификатор hw_id, которым идентифицируются Plug&Play устройства - в данном случае видеокарта моего компьютера. А на этом рисунке хорошо видны Plug&Play идентификаторы для флоппи-дисковода, CD-ROM'а, сетевой карты и жесткого диска моего компьютера. С этим инталляционным файлом возможны два режима работы:
| <Назад> <На главную> <В раздел ASP> <В раздел NET> <В раздел SQL> <В раздел Разное> <Написать автору> < Поблагодарить> |
