Компоненты набора Microsoft Desktop Optimization Pack (MDOP) позволяют создавать мощные комплексные решения для оптимизации и автоматизации управления ИТ-инфраструктурой, реализуемые с использованием Microsoft System Center, с которым компоненты пакета либо прозрачно интегрируются, либо, по сути, являются его элементами. Безусловно, в каждом случае специалисты найдут особую ценность каждой из составных частей пакета, но все-таки, на мой взгляд, бриллиантом в короне MDOP, без сомнения, является технология Microsoft Application Virtualization.
Microsoft Application Virtualization, или AppV, — это патентованная технология, предлагаемая Microsoft в рамках одного из направлений общей стратегии виртуализации. В отличие от остальных технологий, AppV «отделяет» приложения от операционной системы и позволяет им функционировать через сетевые службы, полностью избавляя от необходимости установки самого приложения на конкретную рабочую станцию или терминальный сервер.
Технологии AppV позволяют организовать «потоковую доставку» кода приложения, выполнение которого происходит в полностью изолированном виртуальном окружении, не оставляя следов в самой операционной системе, что избавляет администраторов и службу поддержки от решения целого ряда проблем, связанных с совместимостью, миграцией и версионностью приложений.
Конечно, это требует развертывания определенной инфраструктуры, основу для которой и предлагает компонент Microsoft Application Virtualization из состава Desktop Optimization Pack. В AppV версии 4.5 реализованы такие ее варианты:
-
полная инфраструктура с аутентификацией и авторизацией клиентов в Active Directory и хранением настроек и статистики доставки приложений в базе данных SQL Server (так называемый «тяжелый вариант», Heavyweight Solution);
-
отдельный самостоятельный потоковый сервер (так называемый «облегченный вариант», Lightweight Solution);
-
автономный режим, при котором осуществляется распространение готовых виртуализованных приложений в виде *.msi пакетов (допустим, через Software Installation Active Directory или даже на съемных носителях).
В качестве «оконечных устройств» для каждого из вариантов выступают рабочие станции или сервер терминалов.
Рассмотрим развертывание Microsoft Application Virtualization на примере и начнем, как полагается, с построения инфраструктуры. Учитывая реалии производства, придется ориентироваться на «облегченный вариант», так как «тяжелое» решение потребует некоторых изменений в членстве в группах Active Directory, а также либо развертывания еще одного локального сервера SQL Server, либо предоставления доступа на запись-чтение к уже существующему. Кроме того, администратору AppV придется делегировать ряд полномочий в AD и на SQL Server, что в производственных условиях, скорее всего, встретит сопротивление. Таким образом, в основе нашей среды лежит обычный рядовой сервер домена, на котором «в одиночку» будет функционировать самодостаточный потоковый сервер AppV (см. экран 1).
Процесс настройки серверной составляющей прямолинеен и очень прост. Перед установкой потокового сервера необходимо создать на нем роль IIS, так как HTTP-транспорт IIS нам впоследствии потребуется. Далее устанавливаем Streaming Server с дистрибутива MDOP, запустив соответствующий мастер (см. экран 2).
Мастер установки выполняется с сохранением всех значений по умолчанию, за исключением страницы Advanced Settings, где мы снимаем флажок у параметра Enable User authentication, так как не будем использовать контроллер домена (см. экран 3).
До перезагрузки сервера нужно выполнить еще одно действие: предоставить общий доступ к папке C:Program FilesMicrosoft System Center App Virt Streaming Servercontent (хотя можно и к любой другой). Она станет корневой папкой, в которой будут храниться пакеты приложений. На данный момент разрешения на общий доступ и разрешения NTFS можно оставить по умолчанию.
После перезагрузки выполняем еще одно действие — настраиваем потоковый сервер для работы по HTTP. Это новая возможность версии 4.5, которая имеет ряд преимуществ (впрочем, и недостатков тоже).
Первое преимущество — отсутствие упомянутых организационных проблем и чрезвычайная простота настройки. Второе — IIS, которые используются для этого, хорошо всем знакомы, и их настройка и обслуживание не вызовут затруднений.
Третье — используется протокол передачи данных и порт, который обычно остается открытым на сетевых экранах и, как правило, не требует изменения существующей настройки маршрутизаторов. Если бы мы настраивали потоковый сервер на использование «родного» протокола доставки кода приложений Real Time Streaming Protocol (RTSP), такие дополнительные настройки потребовалось бы сделать.
Недостатки такого варианта следующие. Потоковый сервер без сервера управления инфраструктурой (Management Server) лишен практически всех административных удобств полного варианта. Он не способен публиковать приложения на стороне клиента, не поддерживает формирование значков виртуализованных приложений на рабочем столе, в меню и прочих местах, где можно было бы ими непосредственно воспользоваться, не учитывает использования лицензий на приложения, не позволяет создавать наборы приложений и привязывать их публикацию к конкретным группам пользователей. Самый серьезный недостаток при использовании именно http заключается в том, что не поддерживается активное динамическое обновление (Active Upgrade) приложений на клиентах, если таковое состоялось на сервере.
Для настройки работы сервера AppV через HTTP нужно запустить оснастку IIS, перейти в узел Default Website и создать на нем виртуальную папку Content, которая бы указывала на ранее предоставленную в общий доступ папку Content (см. экран 4).
Далее через контекстное меню следует войти в настройки Default Website, открыть вкладку HTTP headers и создать два типа MIME: для расширения *.osd и расширения *.sft, указав тип MIME как App-V Application (см. экран 5).
После завершения настройки серверной части устанавливаем клиент AppV на контрольную рабочую станцию. При установке указываем настройки сервера. Хотя в нашем случае это и необязательно. Все остальные параметры оставляем по умолчанию (см. экран 6).
Ну вот, среда доставки приложения готова, теперь необходимо определить перечень приложений, которые будут подвергнуты виртуализации, и группы пользователей, которым наборы этих приложений будут доставляться.
Чаще всего самыми востребованными и критичными с точки зрения доступности и взаимосовместимости оказываются приложения офисного плана, и даже на какой-то период освоения AppV специалистами вопрос «а можно ли в нем виртуализировать офисный пакет?» являлся мерилом ценности продукта MDOP. Поэтому дальнейшее рассмотрение возможностей и порядка использования AppV из пакета MDOP пройдет именно на таком примере — виртуализация пакета офисных приложений.
Для этого нам потребуется еще одна рабочая станция, на которую будет установлено приложение виртуализации — секвенсор. Желательно, чтобы эта система была максимально производительной. Кроме того, одному из разделов ее жестких дисков должна быть присвоена буква виртуального системного диска, которая была указана при установке клиента AppV. По умолчанию это буква Q:. Именно на данный раздел и будут устанавливаться приложения, отслеживаемые секвенсором.
Это делается для того, чтобы настройки приложений оставались неизменными для всех клиентских рабочих станциях в окружении сервера. Поэтому для секвенсора используется логический раздел Q, а на клиентских рабочих станциях, благодаря технологии SystemGuard, создается виртуальный Q-раздел.
Установка секвенсора тоже выполняется с дистрибутива MDOP и традиционно для MDOP не вызывает никаких проблем: все установки — по-умолчанию (см. экран 7).
Теперь приступаем к виртуализации Microsoft Office 2007 непосредственно и запускаем секвенсор. Секвенсор — это, по сути, мастер, в котором отслеживается установка программных продуктов, вносимые по ходу изменения, а затем происходит перепаковка приложений и настройка параметров их доставки потоковым сервером.
Пошаговые инструкции по выполнению этой процедуры можно найти по ссылке: http://support.microsoft.com/kb/939796
Теперь вот на что хотелось бы дополнительно обратить внимание. При настройке пакета MSP — на то, что все параметры установки приложений необходимо выставлять либо в Not Available, либо в Run from My Computer. Установка дополнительных компонентов «по требованию», Installed on First Use, не поддерживается, так как локальный репозиторий Local Installation Source (LIS), формируемый при любой установке Microsoft Office 2007, доступен не будет.
Последний этап работы в секвенсоре — окно окончательных настроек перед сохранением проекта. Здесь, кроме выполнения некоторых обязательных изменений в соответствии с упомянутой инструкцией, необходимо проконтролировать значения параметров на вкладке Deployment. Именно они определяют, как клиент будет «общаться» с потоковым сервером (см. экран 8).
В результате работы секвенсора будут созданы следующие файлы:
-
файлы значков приложений в отдельном каталоге. При использовании сервера управления инфраструктурой они используются при доставке значков приложений на рабочий стол пользователя и «привязке» типов файлов к приложениям;
-
файлы *.OSD (формата Open Software Description) для каждого из виртуализованных приложений. В моем случае по окончании виртуализации я оставил только Microsoft Word, Excel, Outlook, Powerpoint. В этих файлах XML описаны все необходимые атрибуты запуска виртуального приложения клиентом. Файл *.OSD также указывает на местоположение файла.sft. Именно файл *.OSD используется клиентом AppV для установки соединения с потоковым сервером и начала загрузки приложения;
-
файл *.SFT — содержит в себе приведенный к последовательному виду код всех установленных приложений Microsoft Office 2007. Данные в этом файле разбиты на сегменты по 32 Кбайт, которые объединяются в два блока: Feature Block 1 (FB1), содержащий код наиболее часто используемых функций приложений, и Feature Block 2 (FB2), содержащий все остальное. При первом запуске приложения на стороне клиента доставляется и кэшируется FB1, а FB2 доставляется по требованию (см. экран 9). Содержимое FB1 определяет администратор секвенсора. Для этого в окне мастера секвенсора Sequencing Wizard — Step 6 of 7 необходимо последовательно запустить каждое из приложений и поэкспериментировать со всеми наиболее часто используемыми функциями, чтобы FB1 был сформирован правильно. Кстати, если этого не с делать, то весь «захваченный код» приложения будет помещен в FB1;
-
файл *.SPRJ — файл проекта секвенсора. Он может использоваться для последующей корректировки пакетов виртуализованных приложений.
-
файл манифеста — *_manifest.xml, генерируется всегда и, кроме всего прочего, содержит информацию о том, где создавать значки приложений, как ассоциировать расширения имен файлов с приложениями и формировать дополнительные пункты в контекстных меню. В обычных режимах работы инфраструктуры этот файл нигде не применяется, но может быть использован для распространения приложений, обработанных секвенсором через системы электронной доставки программных продуктов (ESD — electronic software distribution systems) и при импорте в System Center Configuration Manager 2007 R2.
Файлы *.OSD и *.SFT, а также каталог со значками и манифест следует скопировать в папку Content на потоковом сервере. Настоятельно рекомендую также проверить содержимое файлов *.OSD вручную, в особенности содержимое тэгов
Теперь необходимо создать комфортные условия для пользователей, то есть выполнить «доставку» ярлыков приложений в легкодоступные места интерфейса и создать необходимые ассоциации для расширений имен файлов, чтобы их можно было запускать привычным двойным щелчком.
В нашем упрощенном сценарии облегченной инфраструктуры присутствует только потоковый сервер. Как уже было упомянуто при описании недостатков этого варианта, централизованная публикация приложений на стороне клиента со всеми атрибутами в таком случае не выполняется. Поэтому сделаем это вручную — воспользуемся приложением SFTMIME. EXE, которое входит в комплект клиентской поставки, запустив его из командной строки:
SFTMIME ADD PACKAGE:»office12»
/MANIFEST\str-srvcontent
Office12_manifest.xml
/OVERRIDEURL\str-srvcontent
office12_2.sft/GLOBAL
SFTMIME обработает содержимое файла манифеста и *.sft файла и внесет необходимые изменения в рабочее окружение, а также выполнит настройки клиента AppV, направленные на использование виртуального пакета Microsoft Office 2007 (см. экран 11).
Вообще, SFTMIME задумывалось как средство удаленного администрирования клиентов AppV. Будучи приложением для командной строки, оно позволяет выполнить те же самые настройки, которые выполняются в графическом режиме в оснастке MMC Application Virtualization Client. Через использование SFTMIME в сценариях регистрации групповых политик Active Directory можно выполнить все необходимые административные задачи на клиентах AppV, допустим, сделать предварительную загрузку приложений, отозвать отдельные приложения, переназначить потоковый сервер и.т.д.
Последнее, что осталось сделать, — это назначить селективные разрешения пользователям на работу с приложениями. Ведь не все всем должно быть доступно, верно?
В варианте Lightweight Solution разрешения на запуск приложений регулируются через списки ACL общей папки Content или ее подпапок на потоковом сервере и селективным предоставлением приложений различным группам пользователей в контексте SFTMIME ADD APP или SFTMIME DELETE. В моем случае в окончательном варианте я раздал разрешения NTFS и разрешения на общий доступ «по чтению» для членов группы Authenticated Users на папку Content и этим ограничился.
При принятии решения на внедрение Application Virtualization следует выполнить тщательную оценку существующего окружения, а также определиться с имеющимися ограничениями и рисками, связанными с использованием этого продукта. Если условия жесткие, а риски для производственного окружения неприемлемы, то вполне можно ограничиться и рассмотренным упрощенным вариантом.
Впрочем, это имеет и оборотную сторону: успешное внедрение новых технологий зависит не только от их привлекательности и перспектив, но и от простоты их интеграции, а также от подготовленности инфраструктуры к новым веяниям. Пример, который я привел в своей статье, абсолютно нетребователен ни к одному, ни к другому, и поэтому я считаю, что MDOP и Application Virtalization обречены на успех.
Валерий Волобуев (vvolobuev@techexpert.ua) — тренер-консультант по информационным технологиям, УЦ «Сетевые Технологии», компания TechExpert, г. Киев
Создание виртуальной папки в IIS
Настройки потокового сервера в проекте приложения