У виртуализации Microsoft SoftGrid Application Virtualization много важных преимуществ. Благодаря SoftGrid необязательно устанавливать приложения непосредственно на клиентских компьютерах. У администратора появляется очень удобная возможность: предоставить пользователям приложения, размещенные на сервере, но задействовать при этом вычислительные ресурсы клиентского компьютера и избавиться от хлопот, связанных с устранением программных конфликтов. Даже если пользователи никогда не работали с приложением на этом компьютере, им достаточно щелкнуть пиктограмму приложения на рабочем столе или в меню Start, и приложение запускается с сервера. При этом приложение на клиентском компьютере не устанавливается.

Инфраструктура SoftGrid устанавливается на сервере и клиентах (см. статью «Виртуальные приложения SoftGrid», опубликованную в Windows IT Pro/RE № 8 за 2007 г.) и по порядку распространяет приложения: во-первых, клиент SoftGrid направляет запрос на сервер, затем сервер выполняет потоковую передачу тех компонентов приложения, которые нужны пользователю в данный момент. Все компоненты приложения, к которым обращается пользователь, сохраняются в кэше на клиентском компьютере. Если пользователь ранее работал с приложением или даже его частью, эта часть извлекается из кэша, а не пересылается с сервера. Но если пользователю требуются дополнительные компоненты приложения, например Thesaurus программы Microsoft Word, то клиент SoftGrid автоматически устанавливает соединение с сервером и загружает (и записывает в кэш) именно нужные фрагменты, обеспечивая в будущем доступ к кэшированному компоненту.

SoftGrid — отличное решение для настольных компьютеров, но пригодно ли оно для ноутбуков? Пользователю, который находится вне офиса, будет трудно получить доступ к компоненту Thesaurus программы Word, если он не обращался к нему в прошлом. От некоторых приложений пользователь может получить краткое сообщение о необходимости закрыть приложение в течение двух минут, иначе оно будет закрыто принудительно. В данной статье я расскажу о нескольких способах избежать этой проблемы и дам рекомендации по эффективному использованию SoftGrid вне офиса.

SoftGrid для мобильных пользователей

Существует три варианта работы с SoftGrid в дороге. К сожалению, в двух из них пользователю приходится выполнять какие-нибудь действия или запускать не совсем изящный сценарий. Третий сценарий наиболее удобен. Как будет показано далее, с его помощью можно заранее загрузить определенные приложения с использованием уже имеющейся инфраструктуры развертывания программ, такой как групповая политика, диспетчер Microsoft System Center Configuration Manager (SCCM) 2007 и т. д.

Вариант 1. Самообслуживание пользователя. Можно попросить пользователей поработать со всеми нужными компонентами в офисе, до отъезда в командировку. Недостатки этого варианта проявляются, когда раздается звонок от директора компании, который интересуется, почему сводные таблицы Excel не работают на его ноутбуке на высоте в 10 тыс. метров. Конечно, звонка не будет, если директор обратится к этой функции, работая в офисе, но очевидно, что полагаться на пользователя в этом деле — не лучший выход.

Вариант 2. Принудительно загрузить приложение в кэш целиком. С помощью параметра командной строки клиента SoftGrid можно принудительно записать в кэш определенное приложение целиком (или все приложения, к которым пользователю предоставлен доступ) перед отъездом в командировку. Можно обучить пользователей, чтобы они делали это самостоятельно. Или же можно использовать сценарий групповой политики, чтобы выполнять эту операцию в определенных обстоятельствах (например, подготовить и развернуть сценарий завершения работы, в котором пользователь должен указать, какие приложения нужно взять в дорогу; однако такая задача выходит за рамки данной статьи).

При подготовке приложения для распространения через SoftGrid нужно преобразовать его в «последовательность» (потоковую форму). В процессе этой операции формируется файл Open Software Description (.osd). Чтобы клиент кэшировал определенное приложение, необходимо знать точное имя osd-файла, используемого клиентом для извлечения данных о приложении с сервера. Лицо, выполнившее преобразование приложения в потоковую форму, должно предоставить это имя (оно является свойством потокового приложения).

Располагая именем osd-файла, можно, например, обеспечить загрузку всей потоковой последовательности Adobe Reader на клиентскую систему. Попросите пользователей выполнить на клиенте следующую команду (или подготовьте соответствующий сценарий):

sfttray.exe/load «Adobe Reader 7.0
7.0.8.218»

Или же можно принудительно загрузить на клиента SoftGrid все используемые сотрудником компании приложения с помощью команды:

sfttray.exe/loadall

Однако нельзя превышать размер кэша на клиенте. Размер кэша SoftGrid строго задается администратором во время установки клиента. Размер по умолчанию составляет 2 Гбайт, и изменить его можно только во время установки клиента. Следует отметить, что после заполнения кэша текущий поток приложения останавливается, а затем отображается сообщение о неудачном запуске (Launch Failed).

У вариантов 1 и 2 есть недостатки: пользователям по-прежнему требуется связь с сервером, чтобы получить дополнительные компоненты. Процесс загрузки дополнительных фрагментов приложения или запись в кэш приложения по-прежнему целиком выполняется вручную или связан со сценарием.

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

Вариант 3. Развертывание потоковых последовательностей, упакованных как приложения Windows Installer на клиентах SoftGrid в автономном режиме. Сторонники использования групповых политик были разочарованы, узнав, что не существует способа доставить поток SoftGrid через групповую политику. Сейчас положение изменилось. Новейший клиент SoftGrid версии 4.2.1 можно настроить для работы в новом автономном режиме. Затем можно специально развернуть потоковые последовательности, упакованные как приложения Windows Installer (.msi). После развертывания этих msi-файлов на клиентских компьютерах SoftGrid приложения целиком принудительно записываются в кэш. Таким образом достигается двойной выигрыш: потоковые последовательности можно развертывать с помощью привычных инструментов (групповой политики, SCCM 2007, LANDesk и любых других средств, совместимых с msi-файлами) и записать определенное приложение в кэш компьютера. При таком подходе не приходится полагаться на пользователя, чтобы полностью кэшировать приложение.

Приступаем к задаче

В основе третьего варианта лежат два компонента. Чтобы приступить к задаче, необходимы следующие компоненты:

1. Утилита MSI для виртуализации приложений SoftGrid. Утилита MSI Utility — инструмент для упаковки фрагментов приложения SoftGrid и размещения их в msi-файле (всех фрагментов, кроме sft-файла). Этот файл может оказаться слишком большим, чтобы разместиться в msi-файле, так как именно в нем содержится приложение. Ниже будет показано, как упаковать существующие потоковые последовательности SoftGrid. Затем, при развертывании msi-приложения (с помощью инструмента по выбору пользователя), приложение в действительности не устанавливается. Вместо этого msi-установка просто извлекает sft-файл (собственно потоковую последовательность приложения) и вставляет его в локальный кэш SoftGrid. Во врезке «Использование SMS-коннектора Softgrid» объясняется, почему необходимо использовать утилиту MSI Utility вместо SMS-коннектора.

2. Обновленный клиент SoftGrid (версии 4.2.1 или более новой) функционирует в автономном режиме. Если потоковые последовательности SoftGrid упакованы как msi-файлы и развернуты с использованием групповой политики (или иного метода), это не означает, что обычные клиенты SoftGrid успешно обработают полученный msi-пакет. Чтобы запустить созданные msi-файлы для SoftGrid с помощью инструмента MSI, необходимо обновить до версии 4.2.1 или более поздней (или заново установить) те клиенты SoftGrid, которым предстоит работать в автономном режиме.

Клиент SoftGrid (версии 4.2.1 или более поздней) можно получить по адресу support.microsoft.com/kb/941408.

При этом следует обратить особое внимание на версию клиента: она должна быть 4.2.1 или более новой (в данный момент последней является версия 4.2.2.15). По ошибке легко загрузить версию 4.2.0, размещенную на той же Web-странице. Я лишь спустя четыре или пять часов обнаружил, что загрузил неподходящую версию клиента.

Следует также отметить, что бета-версия 4.5 клиента SoftGrid (к счастью, размещенная на другой Web-странице) несовместима с msi-пакетами, подготовленными с помощью MSI Utility. Требуется по крайней мере версия 4.2.1. Предупреждение: если обновить старый клиент SoftGrid до версии 4.2.1 или более новой, то кэш приложений очищается, и все пакеты приходится загружать заново.

Перевод клиента SoftGrid в автономный режим

В данной статье показано, как установить SoftGrid Client 4.2.1 в автономном режиме вручную. Для этого достаточно выполнить команду msiexec/i с флагом MSIDEPLOYMENT= TRUE:

msiexec/i softgrid-wd-setup.msi
MSIDEPLOYMENT=TRUE

Затем клиент SoftGrid устанавливается обычным способом с использованием мастера. Однако на экране Desktop Configuration Server (экран 1) не нужно вводить никаких данных, а только щелкнуть на кнопке Next. Причина в том, что клиенту не требуется соединение с сервером, ведь он будет работать автономно.

Экран 1. Установка клиента в автономном режиме

Установка проводилась в специальном режиме MSI-DEPLOYMENT = TRUE, поэтому клиент должен внести в реестр особые записи, указывающие на автономный режим. После завершения установки можно выполнить быструю проверку: откройте редактор реестра на клиенте и загляните в раздел HKEY_LOCAL_MACHINESOFTWARE SoftricitySoftGrid ClientCurrentVersion Network. Найдите параметр с именем Online. Если он существует и имеет значение 0, то установка в автономном режиме выполнена успешно. Однако один параметр реестра не устанавливается в нужное состояние автоматически, его необходимо изменить вручную. Это параметр DOTimeoutMinutes.DOTimeoutMinutes в разделе HKEY_LOCAL_MACHINESOFTWARE SoftricitySoftGrid ClientCurrentVersion Network, которому следует присвоить значение ffffff (шесть символов f) типа DWORD. Благодаря этому параметру клиенты кэшируют автономные приложения на 31,9 года вместо 90 дней по умолчанию. Иначе было бы неудобно, если бы на 91-й день приложения внезапно перестали функционировать.

Преобразование потоковой последовательности SoftGrid в пакет MSI

Основная цель автономного режима — запустить потоковую последовательность исключительно из кэша, без соединения с сервером. Для этого существующие пакеты и проекты с помощью утилиты MSI Utility преобразуются в msi-пакет. MSI Utility опубликована по адресу tinyurl.com/2zlpyq.

После запуска утилиты MSI Utility достаточно нацелить ее на существующий osd-файл (в одном каталоге с sft-файлом). На экране 2 видно, как направить утилиту MSI Utility на файл проекта Adobe Acrobat Reader и создать выходной msi-файл в том же каталоге. Весь процесс упаковки каждого приложения занимает около двух секунд.

Экран 2. Создание msi из существующего файла проекта SoftGrid

Обратите внимание, что большой sft-файл не входит в состав нового msi-файла. msi-файл — просто новый способ запустить установку. sft-файл по-прежнему должен быть доступен на этапе установки. На клиенте выполняется не установка приложения, а установка msi-файла и запись Acrobat Reader в локальный кэш SoftGrid.

Тестирование нового msi-файла

После того как новый msi-файл готов, можно провести тестирование. На экране 3 показан объект групповой политики (GPO) для развертывания новой упакованной потоковой последовательности Acrobat Reader (как MSI) на компьютерах. Обратите внимание, что msi- и sft-файлы находятся в том же общем ресурсе (в данном примере именуемом sgContent), что также показано на экране 3.

Экран 3. Использование GPSI для развертывания новой упакованной потоковой последовательности Adobe Reader

Пользователи должны иметь возможность прочитать msi-файл и sft-файл из общего ресурса. Поэтому следует установить разрешение Read for Authenticated Users как на общем ресурсе, так и в базовых разрешениях NTFS. Таким образом, пользователи и компьютеры, которые все считаются (довольно странный подход) проверенными пользователями (Authenticated Users), получают доступ к файлам. Без разрешений Read для проверенных пользователей развертывание закончится неудачей.

Если автономный клиент SoftGrid перезагружается, групповая политика обнаруживает любые msi-приложения, готовые к установке. Если таковые имеются, то msi-приложение целиком помещается в кэш. Если пользователь выполняет регистрацию и пытается запустить приложение SoftGrid, то приложение автоматически извлекается из локального кэша, а не из сервера.

Недостатки автономного режима

У автономного режима клиента SoftGrid есть несколько недостатков. Ниже приведен их список и способы борьбы с ними.

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

Чтобы смягчить эту проблему, нужен соответственно документированный план с указанием клиентских компьютеров, на которых размещается автономный клиент. Диагностика оперативных клиентов SoftGrid отличается от диагностики автономных клиентов. В большинстве случаев оперативный режим используется в настольных компьютерах, а автономный режим — в ноутбуках.

Автономные клиенты создают неудобства для оперативных клиентов. Если msi-пакет направляется обычным клиентам SoftGrid (не переведенным в автономный режим), то MSI пытается выполнить установку при каждой перезагрузке оперативных клиентов SoftGrid. Это связано с безуспешной попыткой msi-пакета выполнить установку на оперативном клиенте, которая завершается тайм-аутом. В результате увеличивается время начальной загрузки обычных оперативных клиентов. Чтобы этого избежать, следует направлять msi-пакеты только автономным клиентам SoftGrid.

Автономные клиенты лишены некоторых важных функций SoftGrid. Любые клиенты, в которых используется автономный режим, автоматически лишаются удобных функций аудита и оценки показателей использования программных продуктов. Это происходит потому, что вся потоковая последовательность выполняется локально, а не с сервера SoftGrid; процесс регистрации отсутствует, и выполнить аудит или лицензионные замеры нельзя. В настоящее время не существует способа смягчить эту проблему. Чтобы получить дневник аудита при каждом запуске приложения SoftGrid, необходимо задействовать оперативный режим.

Независимость от сети

Благодаря утилите MSI и новому клиенту SoftGrid 4.2.1 можно отделить клиентов от сети и обеспечить их работу с приложениями повсюду. При этом можно применять привычные инструменты для развертывания потоковых последовательностей SoftGrid (упакованных в msi-файлы). Существует много других вариантов использования автономного клиента SoftGrid. Например, можно выполнить массовое обновление до SoftGrid 4.2.1 и одновременно перевести старые оперативные клиенты SoftGrid в автономный режим. Это можно сделать с использованием групповой политики или собственного сценария.

Джереми Московиц (jeremym@moskowitzinc.com) — организатор сайта http://www.gpanswers.com, общественного форума по групповым политикам. Имеет сертификат MCSE

Проблема
Без доступа к серверу пользователи не могут получить доступ ко всем функциям приложений SoftGrid, находясь вне офиса.

Решение
Заранее загрузить приложения, преобразовав существующую потоковую последовательность SoftGrid в msi-файл и развернув его с использованием групповой политики, диспетчера SCCM или любого инструмента управления системами.

Необходимые компоненты решения
Экземпляр SoftGrid; утилита MSI для виртуализации приложений SoftGrid; клиент SoftGrid 4.2.1.

Этапы решения

  1. Развернуть инфраструктуру SoftGrid.
  2. Получить утилиту MSI для виртуализации приложений SoftGrid.
  3. Убедиться, что обновленный клиент SoftGrid 4.2.1 функционирует в автономном режиме на целевом компьютере.
  4. Преобразовать существующий поток SoftGrid в msi-файл.
  5. Развернуть msi-файл с использованием групповой политики, диспетчера SCCM или любого инструмента управления системами.

Уровень сложности

***

Использование SMS-коннектора Softgrid

Вместе с SoftGrid поставляется компонент, именуемый SoftGrid SMS Connector. Благодаря его удачной технологии администраторы Microsoft Systems Management Server (SMS) могут развертывать приложения SoftGrid, используя, как всегда, процесс SMS. Однако не всем известно, что компания отказалась от SMS Connector.

Проблема SMS Connector заключается не в самой технологии; скорее, технология слишком специализированная для решения Microsoft. Другими словами, компания Microsoft стремилась предоставить пользователям более общий способ развертывания приложений SoftGrid, и этот способ — MSI.

Многие технологии пригодны для развертывания MSI-приложений, в том числе Microsoft System Center Configuration Manager (SCCM) 2007 (новый вариант SMS), групповые политики и программы независимых поставщиков, например компаний LANDesk и Altiris.

Официально компания Microsoft отказалась от SMS Connector с появлением новой утилиты MSI Utility, применяемой в описанном в данной статье решении. Поэтому администраторам, уже использующим SMS Connector с SoftGrid, рекомендуется переходить к новому инструменту упаковки MSI.

За время подготовки статьи к печати разработчики корпорации Microsoft подготовили новую версию технологии виртуализации приложений App-V 4.5, о выпуске которой было объявлено генеральным директором по серверной инфраструктуре Ларри Ореклином на прошедшей в Москве конференции Microsoft Management Summit 2008, посвященной вопросам управления ИТ-инфраструктурой предприятия, семейству продуктов Microsoft System Center и виртуализации. Среди основных новаций App-V 4.5 выделяются следующие.

  1. Стриминг приложений по http с помощью серверов IIS версий 6 или 7, что позволяет достичь значительного роста производительности при масштабных развертываниях.
  2. Новый интерфейс Sequencer стал проще, с помощью одного мастера можно создать новый пакет и задать расширенные настройки.
  3. Создание виртуального пакета с несколькими приложениями с помощью Dynamic Suite Composition (DSC) добавляет гибкости при управлении взаимодействием виртуальных приложений.
  4. Встраивание приложения в MSI-пакет непосредственно в Sequencer избавляет от необходимости в серверной инфраструктуре для развертывания виртуальных приложений.
  5. Интеграция возможностей развертывания виртуальных приложений непосредственно в SCCM 2007 R2. Возможность управления всей средой app-v из его консоли.
  6. Отчеты о работе приложений теперь хранятся локально и централизованно собираются сервером App-V Management Server во время процесса Publishing Refresh. Это позволяет отслеживать автономное использование приложений или работу приложений из разных источников потоковой загрузки.
  7. Мониторинг виртуальной среды при помощи System Center Operations Manager 2007.
  8. Настройка клиентов app-v посредством групповой политики. Добавлен шаблон ADM для управления конфигурацией клиентов с помощью групповых политик.
  9. Размер кэша на клиенте увеличен до 1 Тбайт. Появилась функция его автоочистки.
  10. Появился VSS Writer для серверов app-v.