После отпуска в Крыму продолжаем перепечатывать статьи Алексея Максимова, посвященные продуктам Microsoft.
С выходом новой версии Microsoft Application Virtualization (App-V) 5.0 появился ряд улучшений и нововведений в этой технологии, которые всерьёз заставили задуматься об обновлении, особенно учитывая уже «набившие оскомину» проблемы с используемой нами до этого момента версии 4.6, в частности описанные в заметке SC 2012 Orchestrator — Режим обслуживания SCOM по расписанию. Планируя внедрение новой версии App-V, после ознакомления с материалами TechNet Library — Planning for High Availability with App-V 5.0 и KB2780309 — How to provide fault tolerance and load balancing in Microsoft App-V v5возникло желание создать такую архитектуру, при которой серверные компоненты App-V имели бы дополнительную отказоустойчивость. Далее мы рассмотрим пошагово процесс создания такой конфигурации…
Среда исполнения
В рассматриваемом примере мы построим двух-узловой NLB-кластер для серверных ролей App-V 5.0 — Management Server, Publishing Server и Reporting Server. Узлы кластера – виртуальные сервера одинаковой конфигурации на базе Hyper-V из Windows Server 2012 Datacenter EN. На виртуальных серверах устанавливается Windows Server 2012 Standard EN.
Каждый из виртуальных серверов создается с двумя сетевыми интерфейсами, настройка которых будет рассмотрена далее.
Серверам присвоены имена – KOM-AD01-APPV01 и KOM-AD01-APPV02
Создаваемый NLB-кластер будет иметь виртуальное имя KOM-AD01-APPVCL. Это имя будет использоваться в качестве точки входа для всех серверных ролей App-V 5.0
Базы данных серверных ролей App-V 5.0 Management Server и Reporting Server будут расположены на отдельном уже действующем кластере SQL Server 2012 c именем KOM-SQLCL
Централизованное хранилище App-V пакетов будет расположено на отдельном уже действующем файловом кластере с именем KOM-FSCL
Дополнительно будет развернута виртуальная машина с именем KOM-AD01-APPV03 для виртуализации приложений – создания пакетов App-V с помощью App-V Sequencer.
Упрощённая схема разворачиваемой инфраструктуры App-V 5.0 в нашем случае будет выглядеть так:
Адреса точек доступа к соответствующим службам App-V будут следующими:
Management Service — http://KOM-APPVCL.holding.com:8080/Console.html
Reporting Service — http://KOM-APPVCL.holding.com:8081
Publishing Service— http://KOM-APPVCL.holding.com:8082
Основными клиентами серверных служб App-V в нашем случае будут выступать сервера служб удалённых рабочих столов Remote Desktop Services (RDS) под управлением Windows Server 2012, поэтому в дальнейшем будем рассматривать установку и настройку клиентов App-V Client for RDS
Предварительная подготовка виртуальных серверов
Поддерживаемые конфигурации — App-V 5.0 Supported Configurations
Предварительные требования для функционирования — App-V 5.0 Prerequisites
Создадим по 2 сетевых адаптера на виртуальных серверах KOM-AD01-APPV01 и KOM-AD01-APPV02. Назовём их условно на каждом сервере таким образом чтобы было понятно за что отвечает этот интерфейс — NIC1 (Management) и NIC2 (NLB Cluster)
При создании второго сетевого адаптера, который будет использоваться для построения NLB в свойствах виртуальной машины Hyper-V необходимо разрешить спуфинг МАС-адресов (Enable spoofing of MAC addresses)
Согласно нашей схемы, выделим и распределим статические IP адреса на серверах следующим образом:
| Имя сервера | Настройки IPv4 NIC1 | Настройки IPv4 NIC2 (NLB) |
| KOM-AD01-APPV01 | IP 10.160.0.133/24
GW 10.160.0.254 |
IP 10.160.0.131/24
GW 10.160.0.254 |
| KOM-AD01-APPV02 | IP 10.160.0.134/24
GW 10.160.0.254 |
IP 10.160.0.132/24
GW 10.160.0.254 |
В классическом понимании администраторов Windows-систем при использовании двух сетевых адаптеров адрес шлюза по умолчанию должен быть указан только на одном сетевом адаптере сервера. Если в таком случае для обоих интерфейсов использовать IP адреса из одной подсети, то виртуальная машина на Windows Server 2012 начинает как-то странно себя вести, а именно с этой машины начинается мощный поток мультикаста который приводит в полное иступление коммутаторы, обслуживающие этот сегмент сети…начинается блокировка портов, потери пакетов и т.п. бардак. Такие проблемы фиксировали наши телекомщики сразу же после того как на сетевом интерфейсе NLB мной включался IP Forwarding. Самое интересное, что точно такая-же конфигурация на Windows Server 2008 R2, которая была описана мной ранее, например, в заметке Exchange Server 2010 How-to: Установка ролей Client Access и Hub Transport в NLB кластере на Windows Server 2008 R2работает без каких-либо нареканий по сей день. Понять корень проблемы нам так и не удалось и поэтому после проведения ряда проверок был выбран вариант с указанием адреса шлюза по умолчанию на обоих сетевых адаптерах, при котором вышеописанных проблем с Windows Server 2012 замечено не было.
Интерфейс NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера), а NIC2 (для которого включён спуфинг MAC адресов) будет участником NLB кластера. Выполним настройку сетевых интерфейсов на каждом из серверов согласно вышеприведённой таблицы на примере сервера KOM-AD01-APPV01
Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections).
NIC1 должен иметь приоритет над NIC2.
В свойствах сетевого подключения, которое будет использоваться для подключения к NLB кластеру (NIC2) можно отключить все компоненты, за исключением TCP/IPv4 и Client for Microsoft Networks:
В свойствах компонента TCP/IPv4 зададим настройки согласно приведённой ранее таблицы и по кнопке Advancedоткроем окно дополнительных настроек
В окне дополнительных настроек TCP/IP на закладке DNSотключим механизм регистрации в DNS:
Интерфейс NIC1 настроим согласно вышеприведённой таблицы аналогичным образом, за исключением того, что на нём может быть включена опция регистрации в DNS и обязательно должны быть включены компоненты TCP/IPv4 , Client for Microsoft Networks и File and Printer Sharing for Microsoft Networks
После того как описанным способом настроены сетевые интерфейсы на обоих серверах, зарегистрируем их имена в доменной зоне прямого просмотра DNS (если запрещена динамическая регистрация в DNS и/или отключена опция регистрации в свойствах интерфейсов NIC1). Для пакетной регистрации A-записей в DNS можно воспользоваться скриптом описанным в заметке DNS – Пакетное создание А-записей с помощью WMI и Powershell
Дополнительно сразу же создаём в DNS статическую А-запись для будущего NLBкластера.
На разворачиваемых виртуальных серверах KOM-AD01-APPV01 и KOM-AD01-APPV02 серверные компоненты App-V будут использовать для хранения баз данных Management Server DB и Reporting Server DB — общий экземпляр SQL Server, поэтому эти сервера должны иметь установленные клиентские компоненты SQL Server, а также привилегии доступа к SQL Server. Настройку доступа к SQL Server выполним позже, а пока установим на каждый сервер свежую версию пакета Microsoft SQL Server 2012 Native Client. Скачать его можно со страницы загрузки Microsoft SQL Server 2012 SP1 Feature Pack(файл sqlncli.msi)
После установки клиента SQL Server создадим на каждом сервере SQL-Alias, который будем в дальнейшем использовать для подключения к удалённому экземпляру SQL Server. Этого конечно можно и не делать, но это может оказаться полезным (даст нам дополнительную гибкость) в случае необходимости переноса БД на другой SQL-сервер или даже экземпляр. Запустим встроенную в ОС утилиту SQL Server Client Network Utility (C:\windows\system32\cliconfg.exe) и добавим два новых алиаса – с коротким именем сервера и FQDN
Фактически созданные SQL-алиасы в интерфейсе утилиты были записаны в ключ реестра: HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo
Теперь нужно проверить созданные нами SQL-алиасы. Для этого создадим пустой файл Universal Data Link с расширением *.udl и запустим его. На закладке Connection укажем SQL-алиас, выберем режим аутентификации Use Windows NT Integrated security и нажмём кнопку Test Connection
Если мы всё сделали правильно, то получим положительный результат подключения.
При этом перечень всех активных БД на новом SQL сервере будет доступен в выпадающем списке Select the database on the server. Таким образом проверим алиас созданный как по NetBIOS имени так и по FQDN.
***
Далее, с помощью PowerShell установим на оба сервера исполняемые компоненты NLB
Import-Module «ServerManager»
Add-WindowsFeature «NLB» –IncludeManagementTools
Затем создадим разрешающее правило в Windows Firewall для входящих подключений на порты служб App-V на обоих серверах:
Import-Module NetSecurity
New-NetFirewallRule -DisplayName «App-V Management Server (TCP-In)» -Direction Inbound -LocalPort 8080 -Protocol TCP -Action Allow -Profile Any
New-NetFirewallRule -DisplayName «App-V Reporting Server (TCP-In)» -Direction Inbound -LocalPort 8081 -Protocol TCP -Action Allow -Profile Any
New-NetFirewallRule -DisplayName «App-V Publishing Server (TCP-In)» -Direction Inbound -LocalPort 8082 -Protocol TCP -Action Allow -Profile Any
Создание кластера NLB
На первом виртуальном сервере (KOM-AD01-APPV01) открываем консоль Network Load Balancing Manager (nlbmgr.exe). Выбираем пункт меню Cluster > New Cluster
Вводим имя первого узла, который хотим добавить в NLB, кнопкой Connectподключаемся к нему, и получив с него набор доступных интерфейсов, выбираем тот который хотим сделать участником кластера:
На странице параметров хоста (Host Parameters) оставляем настройки по умолчанию:
В следующем окне мастера создания кластера добавляем IP адрес NLBкластера, на который мы ранее в DNS зарегистрировали А-запись.
Далее указываем FQDN кластера NLB (по той самой A-записи), а также режим его работы. Режим работы кластера – режим одноадресной рассылки – Unicast.
На странице правил портов (Port rules) удаляем имеющееся по умолчанию правило и добавляем необходимые нам правила. При добавлении правила портов убираем флажок All и указываем конкретный интерфейс NLB и диапазон портов, который хотим добавить в кластер NLB.
В общей сложности, в нашем примере балансировке в NLB кластере мы будем подвергать следующие порты:
TCP 8080 – для роли App-V Management Server;
TCP 8081 – для роли App-V Reporting Server;
TCP 8082 – для роли App-V Publishing Server;
Если по какой-то причине необходимо сделать так чтобы все 3 серверные роли App-V использовали один порт, можно попробовать использовать метод изложенный в статье Kirx’ Blog — How to share ports of App-V 5 services
Все необходимые параметры кластера заданы, создаем его по нажатию кнопки Finishи после первоначальной инициализации, если в конфигурации не допущены ошибки, NLB кластер запустится в конфигурации с одним узлом
Далее, переходим на имя NLB кластера и пунктом меню Add Host to Clusterвызываем мастер добавления второго сервера в кластер.
В конечном итоге после добавления (по аналогии с первым узлом) второго сервера мы получим работоспособный Windows NLB кластер
С помощью Ping -tпроверяем из клиентской подсети доступность кластерного интерфейса по очереди перезагружая узлы кластера.
Дополнительная подготовка инфраструктуры
Создадим сетевой каталог для хранения пакетов App-V на надёжном файловом ресурсе. В нашем примере это будет файловый кластер KOM-FSCL. Из этого каталога клиенты App-V будут загружать пакеты виртуальных приложений опубликованные в службе публикации App-V Publishing Server. Доступ к каталогу настроим на чтение для всех пользователей домена.
Создадим доменную группу безопасности объединяющую учетные записи администраторов App-V. В нашем примере это будет группа KOM\KOM-APPV-Administrators.
Создадим доменную группу безопасности объединяющую учетные записи компьютеров на которые будут установлены роли серверов управления App-V. В нашем примере это будет группа KOM\KOM-APPV-ManagementServers. Включим в эту группу учетные записи компьютеров KOM-AD01-APPV01 и KOM-AD01-APPV02.
Созданные группы будут в дальнейшем использоваться для делегирования прав управления серверными службами App-V и доступа к базам данных Management и Reporting.
Установка баз данных App-V
Так как в нашем случае для БД App-V будет использоваться удалённый кластеризованный экземпляр SQL Server, следуя инструкции Planning for High Availability with App-V 5.0 — Support for Microsoft SQL Server clustering нам необходимо будет вручную создать и настроить соответствующие базы данных ManagementDatabase и ReportingDatabase в кластере SQL Server.
Убеждаемся в том, что службы SQL Server и SQL Server Agentработают от имени доменной учетной записи.
Монтируем образ с дистрибутивом App-V (в нашем случае это будет App-V for RDS v5.0 с интегрированным пакетом исправлений SP1)
Распаковываем инсталлятор \APP-V 5.0 SERVER SP1\APPV_SERVER_SETUP.EXE в отдельный каталог:
APPV_SERVER_SETUP.EXE /LAYOUT /LAYOUTDIR=»C:\Temp\APPV_SERVER»
После завершения распаковки переходим в подкаталог DatabaseScriptsгде сможем найти скрипты установки БД и инструкции.
***
Для создания App-V 5.0 Management Database читаем инструкцию Readme.txt из папки ManagementDatabase. На текущий момент там содержатся следующие инструкции:
1) Выполняем SQL-скрипт ManagementDatabase\Database.sql для БД master. В результате будет создана БД с именем AppVManagement
2) Выполняем по порядку SQL-скрипты для созданной БД AppVManagementчтобы создать необходимую структуру внутри этой БД (обязательно соблюдать порядок)
ManagementDatabase\CreateTables.sql
ManagementDatabase\CreateStoredProcs.sql
ManagementDatabase\UpdateTables.sql
ManagementDatabase\InsertVersionInfo.sql
3) Открываем SQL-скрипт ManagementDatabase\Permissions.sql и устанавливаем SID и имена доменных групп безопасности, которым будет дано право на чтение и редактирование БД AppVManagement. Нам нужно изменить значения ManagementDbPublicAccessAccount и ManagementDbWriteAccessAccount
Исходя из примера в статье The Microsoft App-V Team Blog — How to install the App-V 5.0 Database and Management Server using SQL scripts on the DB предполагается, что в качестве ManagementDbPublicAccessAccount мы можем указать доменную группу безопасности администраторов App-V (в нашем случае KOM\KOM-APPV-Administrators), а в качестве ManagementDbWriteAccessAccount мы можем указать доменную учетную запись сервера App-V (в нашем случае например KOM\KOM-AD01-APPV01$). Но так как у нас фактически будет не один сервер управления, в качестве ManagementDbWriteAccessAccount мы укажем ранее созданную ранее доменную группу безопасности, в которую будут включены учетные записи серверов App-V (в нашем случае KOM\KOM-APPV-ManagementServers)
Чтобы получить значение SID в том виде в котором его нужно указывать в этом SQL-скрипте выполним в PowerShell следующую конструкцию:
$NTAccountName = «KOM\KOM-APPV-Administrators»
$NTAccountObject = New-Object System.Security.Principal.NTAccount($NTAccountName)
$NTAccountSid = $NTAccountObject.Translate([System.Security.Principal.Securityidentifier])
[string]$StringNTAccountSid = $NTAccountSid.value
$TrimmedSid = $StringNTAccountSid.Replace(«-»,«»)
$TrimmedSid = $TrimmedSid.Substring(1,($TrimmedSid.Length-1))
Write-Host $TrimmedSid
В конечном счете скрипт примет примерно следующий вид:
После внесённых изменений выполняем SQL-скрипт ManagementDatabase\Permissions.sql для БД AppVManagement.
На этом настройку БД AppVManagement можно считать законченной.
***
Для создания App-V 5.0 Reporting Database соответственно читаем Readme.txt из папки ReportingDatabase. На текущий момент там содержатся следующие инструкции:
1) Выполняем SQL-скрипт ReportingDatabase\Database.sql для БД master. В результате будет создана БД с именем AppVReporting
2) Модифицируем SQL-скрипт ReportingDatabase\Permissions.sql по аналогии со скриптом ManagementDatabase\Permissions.sql и устанавливаем SID и имена доменных групп безопасности, которым будет дано право на чтение и редактирование БД AppVReporting. Нам нужно изменить значения ReportingDbPublicAccessAccount и ReportingDbWriteAccessAccount. В конечном счете скрипт примет примерно следующий вид:
3) Выполняем по порядку SQL-скрипты для созданной БД AppVReportingчтобы создать необходимую структуру внутри этой БД и настроить разрешения (обязательно соблюдать порядок)
ReportingDatabase\CreateTables.sql
ReportingDatabase\CreateReportingStoredProcs.sql
ReportingDatabase\CreateStoredProcs.sql
ReportingDatabase\CreateViews.sql
ReportingDatabase\InsertVersionInfo.sql
ReportingDatabase\Permissions.sql
ReportingDatabase\ScheduleReportingJob.sql
Скрипт ReportingDatabase\UpdateFromBeta.sql выполнять в нашем случае не нужно так как он используется лишь в случае обновления базы с версии Beta.
На этом настройку БД AppVReporting можно считать законченной.
Установка серверов управления, отчетов и публикации App-V
Приступим к установке серверных компонент App-V на первом сервере – KOM-AD01-APPV01
Перед запуском программы установки серверных компонент App-V устанавливаем предварительно требуемые компоненты:
1) Скачиваем и устанавливаем пакет
Microsoft Visual C++ 2010 SP1 Redistributable Package (x64)
2) Скачиваем и устанавливаем
Microsoft Visual C++ 2010 SP1 Redistributable Package (x86)
3) Устанавливаем роль Windows Web Server (Роль IIS и необходимые для App-V сопутствующие компоненты):
– Common HTTP Features (static content , default document),
– Application Development (ASP.NET, .NET Extensibility, ISAPI Extensions, ISAPI Filters),
– Security (Windows Authentication, Request Filtering),
– Management Tools (IIS Management Console)
Import-Module «ServerManager»
Add-WindowsFeature Web-Server, Web-Asp-Net, Web-Asp-Net45, Web-Net-Ext, Web-Net-Ext45, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Windows-Auth, Web-Filtering, Web-Mgmt-Console
4) Для использования веб-консоли App-V понадобится Microsoft Silverlight. В нашем случае он уже установлен на сервера в составе рекомендуемых обновлений через WSUS.
Устанавливаем…
Запускаем программу установки APPV_SERVER_SETUP.EXE, принимаем условия лицензионного соглашения и дойдя до шага выбора устанавливаемых компонент отмечаем Management Server, Publishing Server и Reporting Server
Расположение каталога установки оставляем по умолчанию..
Далее указываем имя удалённого SQL-сервера (в нашем случае в виде SQL-алиаса, который мы настроили ранее). Имя БД управления Management Databaseоставляем по умолчанию, так как именно с таким именем БД была предварительно создана нами ранее на кластере SQL Server
Здесь небольшое отступление. Если мы решили использовать SQL-алиас, то есть один нюанс – в DNS придётся создать запись типа CNAMEс именем SQL-алиаса (ссылающуюся на A-запись самого сервера SQL).
Если мы этого не сделаем, инсталлятор App-V нам упорно будет говорить что SQL сервер недоступен, при этом в логе инсталлятора %temp%\appv_server_*.log можно будет обнаружить записи типа
AppvUX: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 — Error Locating Server/Instance Specified)
То есть, как я понял, инсталлятор перед непосредственной проверкой соединения с SQL Server выполняет проверку сетевой доступности указанного имени SQL сервера.
Вернёмся к процессу установки. На следующем шаге указываем параметры подключения к БД отчетности App-V Reporting Database— имя удалённого SQL-сервера (в нашем случае в виде SQL-алиаса, который мы настроили ранее). Имя БД оставляем по умолчанию, так как именно с таким именем БД была предварительно создана нами ранее.
Далее укажем параметры настройки роли Management Server — доменную группу безопасности включающую администраторов App-V и номер TCP порта на котором будет создан веб-сайт Management Service в IIS — 8080
На следующем шаге укажем параметры роли Publishing Server. Здесь в качестве службы управления используемой сервером публикации мы должны указать URL на котором служба публикации сможет обнаружить службу управления. В силу того, что в нашем случае, служба публикации будет работать на той же системе что и служба управления, – мы можем указать адрес http://localhost:8080
Имя веб-сайта службы публикации оставляем по умолчанию, порт – 8082
На следующем шаге укажем параметры роли Reporting Server. Имя веб-сайта службы отчетов оставляем по умолчанию, порт — 8081
Дожидаемся успешного окончания процесса установки..
По окончании проверим доступность веб-консоли службы управления App-V по указанной в инсталляторе ссылке http://localhost:8080/Console.html а также проверим доступность консоли удалённо по сети с использованием FQDN имени сервера http://KOM-AD01-APPV01.holding.com:8080/Console.html
Сразу скачиваем и устанавливаем недавно выпущенное исправление KB2873465 — Hotfix Package 1 for Microsoft Application Virtualization 5.0 Server Service Pack 1. После его установки основа открываем веб-консоль службы управления и убеждаемся что версия App-V обновилась до 5.0.1211.0
***
Итак, серверные компоненты App-V на первом сервере установлены, и теперь по аналогии выполняем установку на втором сервере – KOM-AD01-APPV02.
***
После этого удалённо откроем консоль управления обратившись к виртуальному имени NLB кластера: http://KOM-AD01-APPVCL.holding.com:8080/Console.html перейдём в раздел консоли SERVERSи добавим оба сервера в формате <Имя домена>\<Имя сервера>
На этом установку и базовую настройку серверных ролей можно считать законченной.
Установка Sequencer и создание App-V пакета
Так как в нашем случае App-V Client предполагается использовать на серверах служб удалённых рабочих столов (RDS) c ОС Windows Server 2012, то и на виртуальную машину на которой мы хотим установить App-V Sequencer мы установим Windows Server 2012. После чистой установки операционной системы присвоим компьютеру имя (KOM-AD01-APPV03) и настроим сетевой интерфейс. На этих настройках мы ограничимся, так как система должна быть максимально чистой. То есть мы не станем ни ставить на систему обновления, ни вводить её в домен или делать какие-либо другие настройки.
Загрузим на эту виртуальную машину инсталлятор APPV_SEQUENCER_SETUP.EXEи выполним его бесхитростную установку…
Перед непосредственным началом процесса виртуализации какого-либо приложения завершим работу ОС на виртуальной машине App-V Sequencer и создадим моментальный снимок (снапшот) этой виртуальной машины, чтобы после создания App-V пакета мы смогли вернуть систему в исходное чистое состояние и её можно было использовать в дальнейшем для сиквенсинга. После того как снимок сделан и мы снова включаем VM и входим в систему от имени встроенной учетной записи локального Администратора.
Рассмотрим пример создания App-V пакета небольшого бизнес-приложения ISC_Netc которым работают наши пользователи. Особенной отличительной чертой, из-за которой нам потребовалось виртуализация данного приложения является то, что приложение при каждом запуске требует доступ на запись к тем областям системного реестра, которые в обычной практике с точки зрения безопасности доступны рядовым пользователям только на чтение.
Виртуализуемое приложение имеет зависимость. Для его работы необходимо наличие установленного .NET Framework 2.0. Мы предполагаем что на всех компьютерах которые будут выступать в качестве App-V Client уже развернут .NET Framework 2.0 (в составе .NET Framework 3.5) и поэтому мы не будем включать установку .NET Framework в процесс виртуализации. Вместо этого выполним для приложения зависимость установив на нашем сервере App-V Sequencer компоненты .NET Framework 2.0 через консоль Server Manager…
В любом случае после окончания виртуализации приложения и откату на сделанный ранее снимок мы получим чистую ОС без установленных компонент .NET Framework
Запустим App-V Sequencer и выберем пункт создания нового пакета – Create a New Virtual Application Package
Укажем что мы создаём простой пакет с использованием инсталляционных файлов виртуализируемого приложения – Create Package (default)
Sequencer проверит готовность нашей системы к началу процесса виртуализации приложения и если обнаружит какие-то проблемы – сообщит нам о них…
Далее оставим используемый по умолчанию тип приложения – Standard Application
Укажем путь к инсталлятору нашего приложения, расположенному в отдельном локальном каталоге
Затем укажем имя и при желании номер версии создаваемого App-V пакета отталкиваясь от имени приложения в этом пакете. В качестве Primary Virtual Application Directory (PVAD) укажем путь к каталогу в который обычно устанавливается приложение. Этот путь не имеет отношения в реальной файловой системе и фактически будет сэмулирован приложению в виртуальной файловой системе клиента App-V. При назначении PVAD нужно постараться соблюдать уникальность этого пути для всех пакетов App-V используемых на клиенте (во избежание возможных конфликтов виртуальных приложений). По этой причине я обычно добавляю к дефолтному пути имя подпапки отражающей версию приложения на тот случай, если на клиентах потребуется запуск одного и того же виртуального приложения но в разных его версиях. Есть интересное мнение по поводу выбора PVAD в статье Confessions of a Guru — What I Do: App-V 5 and the “Primary Virtual Application Directory”
На следующем шаге запустится инсталлятор нашего приложения и Sequencer начнёт фиксировать все изменения происходящие в системе, например изменения ключей реестра или изменения на уровне файловой системы. В запустившемся инсталляторе нашего приложения выполняем все действия которые обычно выполняются при обычной локальной установке…
… в частности указываем то что приложение будет установлено в режиме “для всех пользователей”. При этом путь установки приложения можно не менять, так как он для нас не имеет значения, ибо путь установки приложения в виртуальной файловой системе мы уже указали ранее в качестве PVAD
Проходим весь процесс установки и штатно закрываем инсталлятор..
После закрытия инсталлятора, устанавливаем признак того, что процесс установки приложений закончен (если в пакет собирается несколько приложений то последующие инсталляторы можно запустить кнопкой Run) – I am finished installing.
После этого нам будет предложено выполнить запуск найденных исполняемых файлов приложения для того чтобы выполнить базовую после-установочную настройку приложения, если такая требуется. Все настройки сохранённые в приложении также будут сохранены в App-V пакет и другим пользователям запускаемым в дальнейшем это приложение уже не придётся выполнять эти настройки заново. Например сюда можно отнести первый запуск и согласие с лицензионным соглашением производителя программы и т.п. На этом этапе желательно, чтобы любое приложение было запущено хотя бы один раз…
В рассматриваемом примере в нашем приложении мы отключили опцию авто-обновления и завершили его работу.
На следующем шаге Sequencer соберёт данные об изменениях произошедших в системе в процессе установки, запуска и настройки нашего приложения и предложит нам либо сразу сохранить пакет либо немного изменить его свойства – выберем второй вариант..
На шаге Streaming мы должны либо по отдельности снова запустить исполняемые файлы нашего приложения для оптимизации пакета для потоковой передачи, либо включить опцию полной предварительной загрузки пакета на клиенте перед использованием приложения – Force application(s) to be fully downloaded before launching
Выберем операционные системы на которых может запускаться создаваемый App-V пакет. Выбираем системы одного поколения в соответчики с той системой, на которой в данный момент выполняется Sequencer.
На следующем шаге мы можем либо продолжить редактирование создаваемого пакета, либо закончить процесс, сохранив пакет в текущей конфигурации. Сохраняем пакет…
После того как пакет сохранён Sequencer выведет нам дополнительную информацию о том какие файлы были исключены из пакета в процессе его создания. Щелкнув по надписи Files excluded from packageоткроется окно с подробной информацией обо всех исключённых файлах. Как правило в исключения попадают временные файлы не имеющие прямого отношения к нормальному функционированию виртуализируемого приложения.
В результате работы Sequencer в указанном каталоге будет создано несколько файлов. Самый главный для нас файл это собственно сам App-V пакет – файл с расширением *.appv. Информацию об исключенных в процессе виртуализации приложения файлах можно также будет найти и после, — в файле report.xml
Для того чтобы просмотреть или изменить содержимое пакета, достаточно двойным кликом запустить файл *.appv В открывшемся окне выберем опцию изменения пакета – Edit Package
В открывшемся окне свойств App-V пакета перемещаясь по закладкам можно, например посмотреть и при необходимости изменить состав файлов приложения…
После того как мы закончили манипуляции по настройке App-V пакета, копируем его с виртуальной машины на надёжный сетевой ресурс (в нашем случае это будет сетевой каталог на файловом кластере KOM-FSCL). Теперь можно выключить виртуальную машину App-V Sequencer и с помощью ранее сделанного снапшота вернуть её к исходному чистому состоянию для виртуализации других приложений в дальнейшем.
Публикация App-V пакета
Теперь наш App-V пакет, размещённый на файловом ресурсе, нужно опубликовать в службе публикации App-V. Для этого откроем в браузере веб-консоль службы управления, перейдём в раздел PACKAGES и выберем ссылку ADD or UPGRADE PACKAGE
В открывшейся форме укажем UNС путь до нашего пакета на, размещённого на файловом ресурсе и жмакнем Add
После того как пакет успешно добавлен, установим на него курсор и через контекстное меню выберем команду публикации – publish
После того как пакет изменит свой статус на published, нам нужно предоставить доступ к этому пакету. Для этого выберем ссылку EDIT в разделе AD ACCESS
Введём имя доменной группы безопасности пользователей, для которой мы хотим предоставить право использования виртуальных приложений из данного пакета. В нашем упрощённом примере это будет группа всех пользователей, имеющих доступ к серверам RDS (KOM\KOM-AD01-RDS-AllUsers). Введя имя группы сначала нужно выполнить его проверку Check а затем добавление Grant Access
В App-V v5 есть два подхода к назначению доступа к приложениям из пакета App-V – доступ ориентированный на пользователя и доступ ориентированный на систему в целом. И в зависимости от текущих потребностей мы можем предоставлять доступ к пакету как доменной группе, объединяющей каких-либо пользователей, так и к доменно группе,объединяющей какие-либо компьютеры. По умолчанию клиенты App-V настроены на юзер-ориентированный подход, и для того, чтобы работало назначение пакетов на компьютеры, необходимо выполнить небольшую настройку клиентов. Рассмотрим эту процедуру далее.
Установка и настройка клиентов App-V
В нашем случае клиенты App-V будут устанавливаться на сервера фермы RDS на базе Windows Server 2012. На наши сервера RDS мы будем устанавливать специальную версию клиента — App-V 5.0 Remote Desktop Services client. Исходя из документа App-V 5.0 Prerequisites нам не требуется предварительная установка каких-либо компонент на Windows Server 2012, хотя на самом деле это может оказаться не совсем так. С требованиями к .NET Framework 4 и PowerShell 3.0всё понятно, – они присутствуют в Windows Server 2012 изначально, но вот компоненты…
Microsoft Visual C++ 2010 SP1 Redistributable Package MFC Security Update
Microsoft Visual C++ 2005 SP1 Redistributable Package MFC Security Update
возможно потребуется предварительно установить отдельно. Я сказал возможно, потому что это зависит от способа установки клиента App-V который мы выберем.
Согласно документа How to Deploy the Client Выполнить установку App-V 5.0 RDS Client на сервере RDS можно двумя путями – с помощью программы установки APPV_CLIENT_SETUP_RDS.EXE или же с помощью MSI-пакетов APPV_CLIENT_RDS_MSI_X64.MSI (основной пакет программы) и APPV_CLIENT_LP_ENUS_X64.MSI и APPV_CLIENT_LP_RURU_X64.MSI(языковые пакеты).
Установка с помощью программы установки хороша тем, что в систему автоматически до-устанавливаются требуемые для App-V компоненты такие как Visual C++ 2005/2010. После окончания установки вас попросят перезагрузить сервер
Однако не очень приятным моментом такого варианта установки является то, что в систему устанавливается целый ворох языковых пакетов для клиента App-V. Если вы считаете, что что в списке установленных приложений вам совершенно не нужен например корейский или турецкий языковой пакет, то можно выбрать вариант с установкой через MSI пакеты. Однако в таком случае компоненты Visual C++ 2005/2010 придётся самостоятельно установить в систему перед установкой клиента App-V. Вот простой пример командного файла который выполняет установку необходимых компонент, дистрибутивы которых расположены на файловом сервере:
SET «DISTR=\\KOM-FSCL\Distributives»
SET «DAPPVRDS=Microsoft\App-V-RDS\5.0_SP1\CLIENT»
SET «DVP2010=Microsoft\Visual C++ 2010″
SET «DVP2005=Microsoft\Visual C++ 2005″
«%DISTR%\%DVP2005%\vcredist_x86.exe» /Q
«%DISTR%\%DVP2005%\vcredist_x64.exe» /Q
«%DISTR%\%DVP2010%\vcredist_x86.exe» /q /norestart
«%DISTR%\%DVP2010%\vcredist_x64.exe» /q /norestart
msiexec -i «%DISTR%\%DAPPVRDS%\CORE MSI\APPV_CLIENT_RDS_MSI_X64.MSI» /norestart AcceptEULA=1
msiexec -i «%DISTR%\%DAPPVRDS%\LANGUAGE PACKS\ENGLISH\APPV_CLIENT_LP_ENUS_X64.MSI» /norestart AcceptEULA=1
msiexec -i «%DISTR%\%DAPPVRDS%\LANGUAGE PACKS\RUSSIAN\APPV_CLIENT_LP_RURU_X64.MSI» /norestart AcceptEULA=1
В результате мы получим следующий перечень установленных пакетов, что на порядок скромнее чем в случае использования инсталятора APPV_CLIENT_SETUP_RDS.EXE…
После окончания установки перезагружаем сервер RDS.
Теперь нам нужно настроить App-V клиента. Сделать это можно двумя путями:
1) С помощью командлетов PowerShell которые добавляются в систему в процессе установки клиента App-V. Список доступных командлетов можно получить с помощью Get-Command *AppV* или Get-Command -Module AppVClient
2) С помощью доменных групповых политик. Для этого необходимо загрузить ADMX шаблоны групповых политик по ссылке Microsoft Desktop Optimization Pack Administrative Templates (ADMX templates for MDOP products — UE-V and App-V)
… и добавить файлы appv.admx, ru-ru\appv.adml и en-us\appv.adml в центральное хранилище шаблонов в домене в каталог \\holding.com\SYSVOL\holding.com\Policies\PolicyDefinitions
После этого в редакторе групповой политики появятся параметры настройки клиентов App-V в разделе Computer Configuration\Administrative Templates\System\App-V
Разумеется когда клиентов App-V больше одного-двух имеет смысл выполнять их настройку массово с помощью групповых политик.
Сначала рассмотрим пример настройки клиента App-V на одном сервере RDS с помощью PowerShell.
Информацию о возможных параметрах которые можно передать клиенту App-V через PS можно найти в документе About Client Configuration Settings
Зададим клиенту данные о том на какой сервер публикации за App-V пакетами он должен обращаться. В нашем случае в качестве сервера публикации указывается виртуальное имя NLB кластера App-V
$PubServer = «KOM-AD01-APPVCL»
$PubURL = «http://KOM-AD01-APPVCL.holding.com:8082″
Add-AppvPublishingServer -Name $PubServer -URL $PubURL
Далее выполним команду синхронизации клиента с добавленным сервером службы публикации:
Sync-AppvPublishingServer -Name $PubServer
После этого запустим графический интерфейс (UI) клиента App-V (по значку в трее или по ярлыку в стартовом экране) и увидим что стали активны кнопки Update и Download
По нажатию кнопки Update должно произойти обновление информации о доступных пакетах App-V. Переключившись на вкладку Virtual Appsмы увидим, что нам доступно одно приложение
По нажатию кнопки Downloadдолжна произойти загрузка в кэш клиента App-V приложений пакета для возможности запуска этих виртуальных приложений даже при недоступности серверов публикации. Ну или же приложение будет автоматически загружено при первой попытке его запуска пользователем.
Как мы сможем увидеть, ярлык который появится у пользователя на рабочем столе будет ссылаться на исполняемый файл виртуального приложения в папке внутри пользовательского профиля, в нашем случае это
%LOCALAPPDATA%\Microsoft\AppV\Client\Integration\B32525C7-3043-420D-B5AC-FB5DE8FA7AB8\Root\VFS\ProgramFilesX86\APBE\ISC_Net\isc_net.exe
На самом деле каталог %LOCALAPPDATA%\Microsoft\AppV\Client\Integration\B32525C7-3043-420D-B5AC-FB5DE8FA7AB8 является символической ссылкой на другой каталог (junction) – подкаталог внутри C:\ProgramData\App-V
В представленном примере публикация App-V приложения выполняется с нацеливанием на пользователя. Если же приложение нужно сделать глобальным для всего сервера RDS, то есть, чтобы оно было доступно всем пользователям системы независимо от их членства в группах AD, — необходимо для клиента App-V активировать режим глобального обновления, который по умолчанию выключен. Для того, чтобы например включить глобальное обновление для настроенного на клиенте сервера публикации, выполним команды:
$PubServer = «KOM-AD01-APPVCL»
Get-AppvPublishingServer -Name $PubServer | Set-AppvPublishingServer
-GlobalRefreshEnabled $true
-GlobalRefreshOnLogon $true
-GlobalRefreshInterval 1
-GlobalRefreshIntervalUnit Day
Ну и конечно не стоит забывать про то что, чтобы App-V приложение на серверах RDS было доступно как глобальное, — в группах доступа на веб-консоли App-V должна быть добавлена доменная группа безопасности, в которую включены учетные записи серверов RDS. Дополнительно про нацеливание прав доступа на уровне системы можно почитать в статье TechNet Blogs — VirtualVibes — Enabling computer based targeting in App-V 5.0
Так как концепция выдачи прав доступа к виртуальным приложениям на уровней всей системы а не на пользователя более подходит в нашем случае с публикацией приложений на серверах RDS, — изменим настройки наших клиентов App-V на серверах RDS (с помощью GPO) а также изменим правила AD ACCESS для нашего пакета App-V на сервере публикации. Создадим для этого в домене группу безопасности, в которую включим учетные записи серверов RDS на которых мы планируем распространять пакеты виртуальных приложений App-V (в нашем примере KOM\KOM-AD01-RDS-App-V-Client-Computers)
В веб-консоли службы управления App-V дадим этой группе безопасности доступ к пакету App-V
В разделе групповой политики Computer Configuration\Administrative Templates\System\App-V\Publishingприменяемой к нашим серверам RDS настроим параметры сервера публикации таким образом, чтобы глобальное обновление пакетов App-V (на уровне системы) было включено, а обновление на уровне пользователя – отключено (при этом пользователи сервера RDS не смогут «баловаться» кнопками в UI клиента App-V)
После применения групповой политики на наших серверах RDS с помощью PowerShell проверим текущие настройки клиента App-V и убедимся что информация о службе публикации назначена в соответствии с заданными нами в GPO настройками.
Выполняем синхронизацию клиента с службой публикации:
Get-AppvPublishingServer | Sync-AppvPublishingServer
Перелогинимся на сервере RDS и убедимся в том, что опубликованное нами приложение доступно всем пользователям на уровне системы
Get-AppvClientPackage | Select Name, IsPublishedToUser, IsPublishedGlobally | fl
Также обращаем внимание на то, что путь в свойствах ярлыка виртуального приложения уже ссылается не на профиль конкретного пользователя, а на общий профиль %ALLUSERSPROFILE%, то есть junction в системе делается только один раз.
Теперь нам остаётся только включить на наших клиентах App-V функцию отсылки сведений в службу App-V Reporting Server. О том как задать все параметры отчетов на клиенте App-V с помощью PowerShell можно посмотреть в документе How to Enable Reporting on the App-V 5.0 Client using PowerShell.
В частности передача настроек в нашем случае будет выглядеть так:
Set-AppvClientConfiguration -ReportingEnabled $true
-ReportingStartTime 6
-ReportingRandomDelay 30
-ReportingInterval 1
-ReportingServerURL http://KOM-AD01-APPVCL.holding.com:8081
-ReportingDataCacheLimit 100
-ReportingDataBlockSize 131072
Чтобы форсировано вызвать процесс передачи данных в службу отчетов на клиенте можно выполнить командлет
Send-AppvClientReport –DeleteOnSuccess
У нас несколько серверов RDS и поэтому, чтобы включить механизм сбора и отправки отчетов сразу на всех клиентах, – воспользуемся групповой политикой в разделе Computer Configuration\Administrative Templates\System\App-V\Reporting
После применения GPO на наших серверах RDS проверим свойства клиента App-V чтобы убедиться в том что назначенные нами параметры задействованы…
Информацию о технологии сбора отчетов с клиентов можно найти в документе Об отчетности в App-V 5.0
Построение отчета об использовании App-V приложений
В текущей реализации службы отчетности App-V нет собственных инструментов для формирования и просмотра отчетов. Для этих целей предполагается использовать подключение отдельно функционирующей службы отчетов SQL Server (SSRS) или использовать другие сторонние средства для получения информации из БД отчетности. Рассмотрим пример того как можно с помощью подключения к БД отчетности сформировать отчет в Microsoft Office Excel 2013.
Запустим Excel от имени учетной записи пользователя который имеет право на чтение ДБ отчетности. В ленте переключимся на закладку Данные, выберем подключение Из других источников > С сервера SQL Server
В открывшемся мастере введём имя SQL сервера и оставим опцию использования проверки подлинности Windows
На следующем шаге выберем базу данных AppVReporting и таблицу ApplicationUsage
При необходимости введём описание источника данных, которое будет отображаться в списке доступных источников для последующих подключений и нажмём кнопку Готово
В открывшемся окне импорта данных можем оставить настройки по умолчанию, чтобы данные были размещены на текущем листе Excel в виде таблицы. При необходимости по кнопке Свойстваможем посмотреть строку подключения к БД и прочие настройки
Нажимаем OKи получаем таблицу с данными извлечёнными из БД отчетности App-V
Используя заголовки сформированной таблицы мы можем настраивать фильтрацию, чтобы, например, в таблице отображались данные о запусках какого-то конкретного приложения или пользователя. В моём примере в колонке server_nameвместо FQDN имён серверов RDS отображается только имя домена. Полагаю, что на данный момент это можно считать багом службы отчетности App-V (подозреваю, что проявляется он лишь в случае, если имя домена содержит точки, т.е. используются под-домены).
Обратите внимание на то, что после выполнения на клиенте App-V команды отправки данных отчетности (Send-AppvClientReport) в SQL таблице ApplicationUsage эта информация сразу не появится. Это связано с тем, что сначала данные попадают в таблицу UnprocessedCompletedApplicationUsage, а уже из неё перекочёвывают в таблицу ApplicationUsage только после отработки хранимой процедуры spProcessClientReport, которая в свою очередь запускается только один раз в сутки (в 01:00) в задании SQL Agent с именем ProcessAppVReportingDataJob. Поэтому если мы хотим получить оперативный отчет на текущий момент, необходимо самостоятельно выполнить запуск хранимой процедуры spProcessClientReport
***
Отдельно хочется упомянуть одно из дополнительных интересных новшеств клиента App-V v5 — возможность работы в режиме Shared Content Store (SCS) mode, при котором виртуальные приложения не кэшируются на клиенте, а запускаются прямо из сетевого хранилища. Думаю что такой режим работы приемлем только в сетях с повышенной пропускной способностью и с использованием скоростных дисковых хранилищ для хранения App-V пакетов. Подробней о режиме SCS можно почитать по ссылкам:
TechNet Blogs — VirtualVibes — Introducing Shared Content Store in App-V 5.0 (Goodbye Read Only Shared Cache!)
TechNet Blogs — The Microsoft App-V Team Blog — Shared Content Store in Microsoft App-V 5.0 – Behind the Scenes
How to Install the App-V 5.0 Client for Shared Content Store Mode
***
На этом, пожалуй, ограничим наш обзор и подведём итоги:
Серверные компоненты App-V развёрнуты в конфигурации повышенной доступности;
Клиенты App-V установлены и настроены;
Нужное нам приложение виртуализовано, опубликовано и доступно на клиентах App-V для исполнения;
Имеется базовый функционал отчетности об использовании приложений App-V.
Дополнительные источники информации:
TechNet Library — High Level Architecture for App-V 5.0
VirtualVibes Blog — App-V 5.0 Standalone Mode — Adding and Publishing a Package
Microsoft App-V Team Blog — How to install the App-V 5.0 Database and Management Server using SQL scripts on the DB
Community Driven Information Technology Virtualization and Cloud Enthusiasts Blog — Microsoft App-V 5: Installation and Configuration Using Windows Server 2012 and Windows 8
Kirx’ Blog — App-V 5 Beta Basic Troubleshooting