Обеспечение совместимости приложений с Windows 7 в виртуализованной среде

Вот-вот увидит свет система Microsoft Application Virtualization (App-V) 4.6, которая, как заявлено, полностью поддерживает Windows 7. Многие клиенты, планирующие развертывание Windows 7, включают App-V в перечень компонентов для преобразования настольных столов. (Развертывание операционной системы часто сопряжено с пересмотром как состава используемых приложений, так и инфраструктуры в рамках проекта по переходу на «современный рабочий стол» или «рабочий стол следующего поколения».)

При попытке скоррелировать расходы на App-V и Windows 7 у ИТ-профессионалов неизбежно возникают вопросы:

• Я слышал, что App-V призвана обеспечить совместимость приложений. Подразумевает ли это, что она поможет мне обеспечить совместимость моих приложений с Windows 7?
• Придется ли мне повторно виртуализировать пакеты App-V, которые я уже развернул на уже существующих рабочих столах с Windows XP?
• Что делать с несовместимыми приложениями, когда я приступлю к развертыванию App-V?

Сейчас мы обсудим каждый из этих вопросов.

Правда ли, что App-V — решение, обеспечивающее совместимость приложений

Microsoft App-V — это в первую очередь решение для управления и развертывания приложений, которое способно принести существенную выгоду предприятию за счет сокращения затрат на создание пакетов приложений, повышения устойчивости системы и предоставления современным мобильным сотрудникам доступа к имеющемуся программному обеспечению. Но усилиями маркетологов термин «совместимость приложений» был сильно перегружен и со временем стал восприниматься неверно: пользователи ожидали получить от App-V решение своих проблем с совместимостью приложений и операционной системы. По большей части это невозможно. (Исключения сегодня существуют главным образом по историческим причинам и никак не могут считаться показательными, но в этой статье мы на этом останавливаться не будем.)

Замешательство клиентов вынудило скорректировать маркетинговый «месседж» — отныне предпочитают не упоминать термин «совместимость приложений», а сразу говорят об основных преимуществах, а именно: уменьшается число конфликтов между приложениями (обратите внимание, как старательно обходится слово «совместимость») и, в результате, значительно сокращается объем регрессионного тестирования.

Официальная позиция команды совместимости приложений и ОС такова:

Как говорилось ранее, App-V — не универсальное решение для обеспечения совместимости приложений и ОС; однако если оболочка совместимости позволяет приложению работать на данной версии Windows стандартным (невиртуализованным) образом, то в большинстве случаев, и для большинства оболочек, оно будет работать в App-V при виртуализации помещенного в оболочку приложения. Таким образом, как правило, App-V обеспечит работу приложений с оболочками (shims), предоставляемыми в составе средств App Compat при условии, что приложение в оболочке способно работать на невиртуализованной версии ОС.

Теперь совершенно ясно, что App-V не предназначена для обеспечения совместимости приложений с ОС. (Мы обсудим взаимодействие оболочек с App-V чуть позже.) Давайте познакомимся с другими аспектами влияния виртуализации приложений на совместимость с операционной системой.

Обеспечивает ли App-V совместимость пакетов

Когда мы говорим о совместимости приложений, разумно отделить совместимость отдельных пакетов от совместимости совместной их работы. В сущности рекомендованный процесс тестирования совместимости приложений (в моей статье в номере за июнь 2009 г. Планирование проекта совместимости приложений) отделяет тестирование установки от тестирования выполнения приложений. А начнем мы с официальной рекомендации команды разработчиков:

Очень часто возможно выполнить виртуализацию на одной ОС, а работать виртуализованное приложение будет на другой ОС; однако здесь поведение зависит как от приложения, так и от операционной системы и нельзя гарантировать, что это будет работать во всех комбинациях приложений и операционных систем, потому что App-V не универсальное решение совместимости с операционной системой. В случае неполадок пользователь обязан выполнить виртуализацию в той же операционной системе, в которой работает клиент App-V.

Звучит не сильно ободряюще — официальная позиция понятна: все зависит от конкретной ситуации. Но оценивая риск, не забудьте сравнить три основных используемых в настоящее время технологии установки ПО:

Setup.exe  выполняет произвольный код, который чреват теми же возможными неполадками во время выполнения, что и произвольный код самого приложения. В такой ситуации требуется тщательное тестирование.

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

Microsoft App-V вообще не выполняет никакого кода, а просто копирует большой бинарный объект данных, представляющий собой виртуальную файловую систему, после чего отчитывается: «Виртуальная файловая система установлена». Поэтому основной вопрос не в том, установилось ли приложение (в конце концов, большого умения при копировании бинарного объекта не требуется), а в совместимости приложения в процессе работы. Таким образом следует ожидать, что в этом случае тестирование установки будет самым коротким. Красота!

Никто официально не утверждает, что все пакеты будут работать, но получается, что основная причина разъяснения состоит в том, что многие пользователи путают неполадки при установке и при работе приложения. Вообще говоря, приобретя Microsoft App-V, можно надеяться на значительное снижение затрат на тестирование установки приложений.

Как устранять неполадки с совместимостью во время работы приложения, если оно установлено средствами Microsoft App-V

Помните это гипнотическое заклинание о поддержке: «App-V будет поддерживать работу приложений с оболочками, предоставленными в составе средств App Compat». Как на самом деле реализовать это? Совместимы ли они вообще?

Ответ, к счастью, положительный. В сущности, у вас несколько вариантов выполнения задачи.

Краткое руководство по оболочкам совместимости для начинающих

Для тех, кто незнаком с оболочками: оболочка (shim) —это одно из немногих слов из четырех букв, использующихся Майкрософт, которое не является сокращением. Это метафора, основанная на английском слове shim, которое используется инженерами для прокладки из дерева или металла необходимой для совмещения двух предметов. В данном случае такими предметами является приложение и Windows, а оболочка — это дополнительный код, который обеспечивает их совместную работу (см. рис. 1 и 2).

Рис. 1 До применения оболочки приложение взаимодействует с Windows напрямую.

Увеличить

Рис. 2 При установке оболочки приложение взаимодействует с Windows опосредствовано, внедренный код оболочки может изменять данные, отправляемые в Windows и/или принимаемые из Windows.

Работа оболочки основана на перехвате API-вызовов. В Windows API-интерфейс реализован как набор DLL-библиотек. Каждое разработанное для работы в среде Windows приложение импортирует эти библиотеки и поддерживает в памяти таблицу адресов всех содержащихся в библиотеках функций. Поскольку связь с функциональными возможностями Windows осуществляется через таблицу, логично заменить эти адреса на адреса DLL-библиотек оболочки. Приложение вообще «не в курсе», что вызов перенаправляется в DLL оболочки, а не самой Windows, и Windows не замечает, что вызов исходит из источника, отличного от приложения (потому что DLL оболочка — всего лишь еще одна DLL-библиотека в процессе приложения).

Например, очень популярна оболочка, подменяющая версию. Ее реализуют путем перехвата нескольких API-функций, служащих для определения, на какой версии Windows работает приложение. Обычно эту информацию предоставляет сама Windows, и она соответствует действительности. Однако при наличии оболочки вызовы API-функций перехватываются. Вызов не передается в Windows, а предложению сообщается другая версия Windows (например, Windows XP вместо Windows 7). Если приложение запрограммировано на работу только на Windows XP, таким образом удается обмануть и «убедить» приложение, что оно работает на «правильной» ОС. (Очень часто именно это решает проблему несовместимости приложения!)

Оболочки позволяют делать массу нестандартных вещей, вот несколько примеров. Пример.

• Оболочка ForceAdminAccess заставляет приложение считать, что текущий пользователь является членом группы «Администраторы», даже если это неправда. (Много приложений отказываются нормально работать, если пользователь не локальный администратор, хотя можно прибегать и к другим уловкам, таким как виртуализация реестра и файлов контроля учетных записей, для устранении проблемы, которые изначально стали причиной проверки.) Реализация довольно проста: оболочка перехватывает функцию IsUserAnAdmin библиотеки shell32.dll. Код перехваченной функции (у которой, в отличие от оригинальной функции, замечательные показатели производительности) просто возвращает True.
• Оболочка WrpMitigation обманывает установщики приложений, «убеждая» их, что те могут выполнять запись в файлы, защищенные механизмом WRP (Windows Resource Protection). При попытке записи в защищенный файл оболочка сначала создает новый временный файл, помечает его к удалению сразу же после закрытия описателя, а затем возвращает описатель временного файла в качестве описателя реального защищенного файла. Приложение устанавливает настоящую версию kernel32.dll или shell32.dll (или любого другого файла, который его разработчик посчитал нужным добавить в установочный пакет) во временный файл, а после уничтожения временного файла в файловой системе остается исправленная новая версия защищенного файла. Таким образом WRP сможет гарантировать, что на компьютере не появится древняя копия файла shell32.dll из Windows 95, но при этом установщик не потерпит неудачу из-за отказа в доступе.
• Оболочка CorrectFilePaths может переадресовать файлы в другое место. Так, если есть приложение, пытающее выполнять запись в папку c:\myprogramdir (которая не исправлена автоматически средствами виртуализации реестра и файлов контроля учетных записей), можно переадресовать файлы, которые изменяются во время выполнения в профили пользователей. Это позволяет вам обеспечить работу обычного пользователя, не ослабляя списки управления доступом (ACL) — ведь люди, ответственные за безопасность очень не любят такое ослабление.
• Существуют сотни универсальных оболочек, призванных решить проблему совместимости приложений, и подчас они позволяют экономить значительные средства. В частности, очень часто используют оболочки в следующих ситуациях.
• Компания, поставщик программы, прекратила свое существование, и нет никакой возможности получить обновленную версию ПО. Если нет возможности получить другое приложение от другого поставщика или собрать новую версию самостоятельно, оболочка поможет отложить решение проблемы на какое-то время.
• Приложение не настолько критичное, чтобы тратиться на обновленные версии (которые обычно требуют затрат на поддержку), но пользователи довольны и нет никаких проблем, что они используют неподдерживаемую версию.
• Приложение разработано собственными силами компании, но вы не хотите ждать, когда команда разработчиков выпустить полностью обновленную версию. Вместо этого, можно предпочесть временное решение, а при выходе новой версии получить от команды разработчиков постоянное решение. Такой подход позволяет не останавливать всю деятельность по разработке приложения, посвящая все время и ресурсы на устранения неполадок с совместимостью. Можно использовать временное решение проблемы и подождать пока группа разработчиков выпустит релиз с новыми функциями, который уже находится в разработке.

Использование оболочек в рамках инициативы по решению проблем совместимости приложений может сэкономить значительные средства и сильно ускорить развертывание Windows 7.

Варианты управления оболочками на предприятии

В моей статье об управлении оболочками на предприятии, увидевшей свет в ноябре 2007 года я выделяю два основных варианта, из которых обычно выбирает большинство людей, принимая решение, как управлять оболочками при решении проблемы совместимости приложений в организации. Кратко напомню, о каких вариантах идет речь.

Единая централизованно управляемая база данных оболочек С данной функцией разворачивается одна централизованно управляемая база данных оболочек, содержащая записи о всех приложениях, нуждающихся в оболочке. При выявлении новых приложений, которым нужны оболочки, центральная база данных обновляется. Именно этот подход использует Microsoft. Мы выпустили Windows 7 с системной базой данных оболочек для тысяч приложений, и обнаруживая новые приложения, нуждающиеся в оболочке, распространяем обновления базы данных средствами Windows Update. Вы можете сделать ту же самую вещь: создать базу данных оболочек и обновлять ее, используя ПО системного управления (например, System Center Configuration Manager).

Отдельные базы данных оболочек для каждого приложения Можно разворачивать оболочки непосредственно с самими приложениями. Обычно этот вариант выбирают, когда есть лишь одно-два приложения, требующие исправления, поскольку в небольшой среде организация управления централизованной базой данных потребует больше усилий. Существенный недостаток разбиения баз данных оболочек по приложениям — сложность обновления этих баз в случае неполадок. Однако App-V устраняет этот недостаток, так как теперь можно обновлять эти базы данных и обновленная версия автоматически попадет к пользователям. (Но, как вы увидите далее, это создает другую, намного более существенную проблему.)

Примененный в Microsoft App-V подход к развертыванию ПО расширяет возможности развертывания исправлений приложений на предприятии, и можно выбрать метод, который максимально подходит существующей на предприятии модели процессов.

Хранение оболочек для приложений App-V в единой централизованной базе данных

Итак, что же с тактической точки зрения нужно сделать, чтобы развернуть единую централизованно управляемую базу данных оболочек и обеспечить ее применение при виртуализации приложения средствами App-V? Все просто — надо устанавливать приложение, как обычно! Установленное средствами App-V приложение запускается практически так же, как и обычное и использует те же механизмы загрузчика, что и в среде, где есть оболочки. Они запускаются суррогатным процессом. В частности новый процесс запускает sfttray.exe, а не проводник. Получающееся дерево процессов показано на рис. 3.

Рис. 3 Дерево суррогатных процессов

При запуске приложение обслуживает загрузчик, как это происходит всюду в мире прикладного программирования. Клиентский интерфейс виртуализации приложений (sftintf.dll) вызывает фунцию CreateProcessW, которая в свою очередь вызывает внутреннюю API-функцию CreateProcessInternalW. Именно в CreateProcessInternalW вызывается механизм оболочки и оболочки прикрепляются к процессу.

Хорошо, все вроде просто. Есть ли какие-либо засады? Ну, есть одна. Не обслуживается повышение уровня доступа. Нельзя просто просить о повышении уровня доступа приложения (используя оболочку RunAsAdmin) или решать проблему, к примеру, используя ElevateCreateProcess. Почему? Из-за слоя изоляции (bubble).

Например, посмотрим на приложение, пытающееся инициировать автоматическое обновление себя самого (к сожалению, это очень часто выполняемая задача). Это невозможно при работе приложения в обычном режиме из-за использования API-функции CreateProcess, которая не поддерживает повышение уровня доступа, а при попытке сделать это вернет ошибку «1073740756 - STATUS_ELEVATION_REQUIRED». Оболочка ElevateCreateProcess перехватывает это значение и вызывает Службу сведений о приложениях (Application Information Service) для обеспечения повышения уровня доступа. Но эта служба не сможет найти приложение, которому нужно поднять уровень доступа, потому как располагается за пределами слоя изоляции!

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

Размещение оболочек для приложений App-V в базах данных приложений

Развертывать оболочки, решающие проблемы совместимости, можно вместе с приложением. В мире MSI в этом случае обычно включали в установщик .sdb-файл, и затем создавали нестандартную операцию, вызывающую программу sdbinst для обработки этого .sdb-файла. В этому случае в процессе установки развертывается нестандартная оболочка. (Если в дальнейшем потребуется обновить оболочки этого приложения, придется найти все установленные клиенты и выполнить сценарий обновления. Это несколько усложняет ситуацию.)

App-V позволяет делать почти то же самое. Можно включить базу данных оболочки (.sdb) в саму виртуализацию, чтобы SDB-файл располагался в пределах слоя изоляции. Сначала виртуализуют приложение, нуждающееся в оболочках, после чего я обычно предпочитаю размещать свою базу данных оболочек в папке system32.

(Хотя я обычно категорически не рекомендую читателям размещать что-либо в папке system32, если только они не разработчики Windows, но в данном случае я предлагаю именно это, потому что так сильно облегчается создание сценариев: system32 уже содержится в переменной PATH и фактически в промышленной среде system32 не остается — остается только там, где по мнению виртуальной файловой системы находится system32).

После этого я редактирую .sprj-файл. Я перехожу на вкладку Virtual File System и выбираю View/Virtual File System/Add. Далее я перехожу к месту, где находится SDB-файл (c:\windows\system32\appshim.sdb) и щелкаю OK. Теперь, этот .sdb файл будет присутствовать в слое изоляции и будет установлен при установке пакета SoftGrid. Так как файл является частью контейнера, он будет всегда с приложением (и может быть обновляться при обновлении приложения).

Ясно, что простого наличия SDB-файла в файловой системе недостаточно для применения исправлений — их нужно установить. Однако база данных оболочек должна устанавливаться за пределами слоя изоляции App-V. Если установить базу данных оболочек в слое изоляции, то виртуализованный SDB-файл не будет обнаружен, пока не создан процесс, но тогда уже слишком поздно — механизм оболочки не найдет его и не сможет принять нужные меры. База данных оболочек должна быть доступна загрузчику за пределами слоя изоляции в момент создания процесса.

К счастью в App-V предусмотрен механизм выполнения сценариев в процессе запуска приложения. Открыв OSD-файл приложения в текстовом редакторе, вы увидите, что это текст формата XML, который можно редактировать. Элемент <SOFTPGK> содержит элементы <IMPLEMENTATION>, <DEPENDENCY>, <PACKAGE>, <ABSTRACT>, <MGMT_SHORTCUTLIST> и <MGMT_FILEASSOCIATIONS>. Для выполнения установки базы данных оболочек потребуется отредактировать элемент <DEPENDENCY>, добавив дочерний элемент <SCRIPT>. Вот пример сценария, устанавливающего базу данных оболочек при запуске приложения и удаляющего ее по завершении работы приложения (таким образом обеспечивается JIT-реализация, «прибирающая» за собой «мусор», — именно, что нужно для App-V):

<DEPENDENCY>
       <CLIENTVERSION VERSION="4.6.0.0"/>
       <SCRIPT EVENT="LAUNCH" PROTECT="TRUE" TIMING="PRE" WAIT="TRUE" EXTERN="TRUE">
<SCRIPTBODY LANGUAGE="Batch">sdbinst /q appshims.sdb</SCRIPTBODY>
       </SCRIPT>
       <SCRIPT EVENT="SHUTDOWN" PROTECT="TRUE" TIMING="POST" WAIT="TRUE" EXTERN="TRUE">
              <SCRIPTBODY LANGUAGE="Batch">sdbinst /u appshims.sdb</SCRIPTBODY>
       </SCRIPT>
</DEPENDENCY>

Этот сценарий вызывает установщик базы данных оболочек (sdbinst.exe) из вне слоя изоляции App-V, но использует параметр .sdb, который находится в слое изоляции App-V, и далее разворачивается в рамках общего процесса развертывания приложения. Таким образом получается просто развертывать и обновлять исправления приложений, как будто они еще одна часть приложения.

Процесс установки баз данных оболочки требует прав администратора, но не создает ли это проблем, ведь мы устанавливаем ее во время выполнения? Нельзя предоставлять пользователям административных прав, к тому же им не понравится щелкать в окне повышения уровня доступа при каждом запуске приложение. К счастью, этого не нужно делать — вызов sdbinst.exe автоматически повышает уровень доступа. Дерево процессов установки оболочек показан на рис. 4.

Рис. 4 Дерево процесса установки оболочки

Создается командная оболочка, которая вызывает sdbinst.exe для установки базы данных оболочек. Происходит два сбоя из-за недостатка уровня доступа (STATUS_ELEVATION_REQUIRED) прежде, чем вызов попадает в Службу сведений о приложениях, которая и отвечает за повышение уровня доступа. Она, в свою очередь, вызывает утилиту consent.exe, которая сверяется с политикой, нужно ли повышать уровень доступа приложения. Политика (в виртуальной среде) отвечает положительно, и разрешение у пользователя не запрашивается; consent.exe одобряет повышение уровня доступа и создается экземпляр sdbinst.exe с повышенным уровнем доступа, который устанавливает базу данных оболочек. Важно иметь в виду, что политика повышает уровень доступа без запроса, только если есть возможность повышения. Если вы стандартный пользователь, при каждом запуске (и при закрытии) приложения будет отображаться окно с предложением ввести учетные данные администратора. Как правило, такая ситуация считается недопустимой в обычной рабочей среде, поэтому такой подход работает, только если пользователей являются локальными администраторами. Хочется надеяться, что доля пользователей, к которым ограничение применимо исключительно мала!

Заключение

Microsoft Application Virtualization — мощное средство управления и развертывания приложений. При разработке планов миграции на Windows 7 можно рассчитывать на существенное сокращение (но не снижение до нуля) затрат на тестирование установки приложений.

Вполне можно продолжать пользоваться теми же процессами для решения проблемы совместимости приложений с применением оболочек. Если развертывать единую базу данных оболочек всей организации, усилия по переходу будут минимальны: нужно только аккуратно избегать оболочек, требующих повышения уровня доступа (практически так же, как избегают повышения уровня доступа в среде App-V). Если оболочки развертываются отдельно для каждого приложения, есть несколько удачных способов упаковки и развертывания базы данных оболочек вместе с приложением, но есть очень существенный недостаток: очень сложно будет обойтись без выполнения приложений под административными учетными записями. Поэтому лично я настоятельно рекомендую (это же касается развертывания приложений на основе технологии MSI) размещать оболочки в единой централизованно управляемой базе данных, которую можно развертывать, используя имеющееся ПО системного управления. Это дает перспективу на будущее, когда все больше пользователей не будет работать под учетными записями, обладающими административными правами.

Крис Джексон (Chris Jackson) — («спец о совместимости ПО») главный консультант в Microsoft и технический руководитель команды Windows Application Experience SWAT. Будучи признанным экспертом в области совместимости приложений Windows, Джексон создает техническую документацию и учебные курсы, предлагает услуги, которые пользуются популярностью как в самой Microsoft, так и за ее пределами. Его знания подкреплены многолетней практикой практической работы с корпоративными клиентами и независимыми производителями ПО. С Джексоном можно связаться через его популярный блог.

Материалы на подобные темы

• Блог группы разработчиков App-V
• Технический центр по виртуализации приложений
• Приступая к работе с Application Virtualization