Горизонт программа для удаленного доступа windows 7

Horizon – одно из интереснейших и мощнейших направлений VMware, отвечающее за поддержку виртуальной десктопной инфраструктуры (VDI), службу удаленных рабочих столов (RDS) и публикацию приложений. В простоте и отсутствии масштаба заподозрить его, согласитесь, получится вряд ли, и тем не менее, тема эта по своей актуальности равна немногим. 7 января 2021 вендор выпустил очередной релиз продукта серии – 2012, – и сегодня нашей задачей как раз и станет максимально содержательное с ним знакомство.

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

Объем работ нами намечен колоссальный, и приступим мы к нему, естественно, с обязательного изучения требований и совместимости. Однако, вначале, в двух словах коснемся необходимой для понимания всего нижеследующего теории – ценного помощника в будущем в процессе реализации Horizon-архитектуры на практике.

Введение в теорию десктопной виртуализации

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

• Виртуализация пользовательских рабочих столов по всей инфраструктуре дата-центра;
• Предоставление доступа пользователям к опубликованным приложениям вне клиентского устройства;
• Упрощение доступа к онлайн-сервисам путем предоставления единого цифрового рабочего пространства:

Тонкость задумки заключается в том, что благодаря Horizon ИТ-департаменты компаний могут доставлять десктопы и приложения дата-центра их сотрудникам как услугу, реализуя на практике стратегию «компьютер в компьютере». В итоге на каждом физическом ядре сервера может запускаться по нескольку виртуальных машин, а управление рабочими столами и приложениями при этом значительно упрощается за счет автоматизации. Одновременно соблюдаются все политики организации в отношении безопасности, иерархичности доступа, унификация стандартов использования ресурсов, а также, что невероятно удобно и немаловажно, становится доступной функция совместной работы сотрудников.

Функции Horizon

Помимо воплощения в жизнь легендарного лозунга VMware о работе с любого устройства и в любом месте, Horizon готов предложить весьма богатый функционал:

• Пакетное решение управления пулами десктопов, виртуальную печать, виртуализацию приложений и координацию их прав, хранение данных и пр.;
• Встроенные функции автоматической доставки рабочих столов и приложений в режиме реального времени (технология Instant Clone; Environment Manager для персонализации и индивидуальной настройки пользователей и приложений, которыми они пользуются, конфигурирования их сред; присоединение приложений к ВМ прямо при логине благодаря App Volumes), усовершенствование безопасности путем удаления десктопов при логауте пользователя;
• Тесное сотрудничество с другими продуктами вендора для создания монолитной полнофункциональной и очень гибко подстраивающейся под текущие требования виртуальной среды Software-Defined Data Center (SDDC) (включая vSphere, vSAN и NSX). Оперирование решением как в on-premise, так и в публичных облаках:

Любая поддерживаемая ESXi гостевая ОС может использоваться в качестве десктопа, а система vCenter Server при этом управляет ресурсами и помогает разворачивать рабочие столы, работать с балансировкой нагрузки и НА. Десктопная виртуализация обладает собственным Connection Server, автоматизирующим связь между клиентскими компьютерными устройствами и виртуальным десктопом, а в ряде случаев – позволяя подключаться к одному из нескольких идентичных рабочих столов в пуле. Для связи удаленного клиента с виртуальным десктопом используется удаленный протокол, построенный на TCP/IP, и в общем случае он включает Virtual Network Computing (VNC), Remote Desktop Protocol (RDP), Independent Computing Architecture (ICA) и X Window System. При этом протоколов можно использовать сразу множество.

Horizon поддерживает виртуальные десктопы как на базе Windows, так и Linux, а также хостящиеся на RDS приложения без необходимости подключения пользователей к полноценному рабочему столу. Хочется немного рассказать и о термине JMP (Just-in-Time Management Platform) – замечательной технологии VMware, позволяющей снизить потребление ресурсов и сложность организации виртуальной среды благодаря апдейтам с нулевым простоем, контекстному управлению политиками, мгновенной доставке приложений и в целом очень быстрой работе всей инфраструктуры.

Важной и очень актуальной сегодня составляющей решения десктопной виртуализации является Horizon Cloud – возможность расширения виртуальных Windows-десктопов до облачных рабочих столов:

Помимо этого, доступна автоматизация и интеграция благодаря сторонним инструментам управления. В частности, тесному сотрудничеству с Windows PowerShell и Microsoft System Center Operations Manager (SCOM). Для администрирования из командной строки PowerCLI предоставляет cmdlet Windows PowerShell, и использование их аналогично применению в любой консольной среде.

Архитектура и дизайн десктопной виртуализации

Архитектура Horizon удобно масштабируема и организована она по модульному принципу, отвечая строгим требованиям к стандартизации работы, планируемому расширению и простоте управления. Для наглядности она поделена на уровни, дизайн которых не может осуществляться изолированно, так как все в них глубоко взаимосвязано:

Рассмотрим их в деталях:

1. Физический уровень. Состоит из компонентов подключения и сети, настроенных под клиентскую коммуникацию;
2. Уровень виртуализации. Использование всех возможностей и ресурсов гипервизора, сервисов вычисления, хранилищ, сетевых функций и графики;
3. Уровень ресурсов десктопа. Предоставление профилей и сеансов, определяющих ассоциируемые с управлением множеством виртуальных десктопов требования в разнообразных пользовательских сообществах. Обеспечение интеграции в AD, функции контроля над аутентификацией, пользовательскими данными и настройками;
4. Уровень ресурсов приложений. Предоставление приложений как части сеансов, других приложений или профилей. Определяет инфраструктуру, которая нужна для компоновки, разворота и управления приложениями;
5. Уровень пользовательского доступа. Обращение к физическим устройствам, дающим пользователям доступ к виртуальному рабочему столу.

Схема взаимодействия компонентов уровней архитектуры Horizon при этом может выглядеть так:

Компоненты Horizon

Как все это выглядит в целом, для чего нужно и как взаимодействует, теперь мы примерно понимаем. Резюмируя приведенную выше информацию, можно сказать, что для работы Horizon нам нужны клиентские точки доступа и ПО на них, с помощью которого они обращаются к распределяющим виртуальные рабочие столы и приложения компонентам, сам агент, который будет управлять этим процессом, а также программно-определяемая возможность налаживания связи между перечисленным:

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

Connection Server

Connection Server представляет собой программную службу, осуществляющую предоставление и распределение пользовательских подключений. Его функционал следующий:

• Аутентификация пользователей с AD и направление запроса на подходящую ВМ, физический компьютер или Microsoft RDS-хост;
• Обеспечение безопасной связи между пользователями и удаленными десктопами и приложениями;
• Предоставление пользователям доступа к указанным пулам и рабочим столам.

Клиентские устройства

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

Horizon Client

Horizon Client – это клиентское ПО для доступа к удаленным рабочим столам и приложениям, которое может запускаться на планшете, телефоне, ПК или ноутбуке с Windows, Linux или MacOS семействами ОС, на тонком клиенте и других устройствах.

Horizon agent

Служба, устанавливаемая на всех ВМ, физических системах и Microsoft RDS-хостах, используемых в качестве источника для приложений и удаленных десктопов, называется Horizon Аgent. На уровне виртуальной машины она связывается с Horizon Client, чтобы предоставлять такие функции:

• мониторинг связи,
• виртуальную печать,
• Horizon Persona Management (управление профилями пользователей),
• Доступ к локально подключенным USB-устройствам.

Unified Access Gateway (UAG)

UAG предоставляет защищенный шлюз для внешних пользовательских подключений к десктопам и приложениям. Обычно располагается на DMZ и работает как прокси-хост для подключений внутри доверенной корпоративной сети.

Десктопы и приложения

Windows-ресурсы десктопов и приложений предоставляются пулами десктопов в рамках одной сессии или сессий совместного использования ферм RDSH-сервера.

Фермы RDSH-сервера и пулы виртуальных десктопов

В таких пулах ВМ создаются из золотого образа. Проинсталлированный на виртуальном десктопе или RDSH-сервере агент Horizon подключается к Horizon Client с пользовательского устройства для определения, какие десктопы и приложения стоит предоставить юзеру. Также агент в этом случае предлагает множество полезных функций, вроде мониторинга соединения, перенаправления клиентского диска, интегрированной печати VMware и доступа к локально подключенным USB-устройствам.

Хосты vCenter Server и ESXi

Базовые элементы любой виртуальной среды, без которых, разумеется, десктопная виртуализация существовать попросту не сможет. vCenter Server отвечает за ключевые операционные и административные функции в отношении ВМ:

• предоставление,
• клонирование,
• управление.

А ESXi – тот самый наш традиционный гипервизор, с разворота которого и начинается любое внедрение виртуализации.

Также опционально можно использовать Workspace ONE Access, Horizon Control Plane и Cloud Connector (для облаков), Dynamic Environment Manager. Их комбинации с Horizon будут посвящены главы отдельных наших будущих материалов, а про App Volumes в деталях поговорим ниже, в разделе о лицензировании, так как доступен он ограниченному количеству лицензий. Либо же за более детальной информацией по этим специфическим вопросам рекомендуем обратиться к официальным тематическим курсам VMware.

Построение дизайна десктопной виртуализации

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

Как правило, утрируя, в любой компании применим одним из следующих сценариев требований (либо их комбинация):

1. Все сотрудники работают с данными на своих защищенных ПК, доступ по USB и перенаправление буфера обмена запрещены. Тем не менее руководящему звену разрешено использовать некоторые USB-устройства;
2. Руководителям высшего звена часто приходится работать удаленно, из-за чего они нуждаются в специфических конфигурациях для поддержки пользовательского подключения, учитывая ограничения пропускной способности и задержки сети.

В первом случае используются только защищенные внутренние коммуникации, а в качестве приложений, ОС и устройств – лишь MS Office, Windows 10 и тонкий клиент. Во втором же соединение может быть, как внешним, так и внутренним, девайсы – это и лэптопы, и другие варианты устройств (с микрофонами и веб-камерами), система, допустим, та же, но с внедренными приложениями, вроде ERP и CRM.

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

• Статические исполнители задач (зафиксированные в определенной локации работники без удаленного доступа – сотрудники колл-центров, административное звено, продажники и т.д.);
• Мобильные работники умственного труда (квалифицированный персонал для различных производственных задач с необходимостью доступа из разных конечных точек – экономические отделы, маркетинг, HR, персонал больниц и других социальных служб и пр.);
• IT или разработчики софта (сотрудники, нуждающиеся в правах администратора для инсталляции приложений, использующие огромное их количество, в том числе и такие, которые требуют дополнительные ресурсы памяти и CPU);
• Инженеры и дизайнеры мультимедиа (активные пользователи, нуждающиеся в мощных GPU-приложениях, использовании огромного количества памяти и CPU);
• Работники по контракту (внешние пользователи, которым требуется доступ к специфическим бизнес-приложениям удаленно или с мобильных девайсов).

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

• Принадлежность к определенной бизнес-единице (колл-центр, IT-департамент, девелоперы и т.д.);
• Количество пользователей в бизнес-группе (рассчитать полное кол-во и кол-во конкурентных пользователей);
• Класс десктопа;
• Тип вычислительного устройства, конфигурация «железа» и ОС, с которых будет осуществляться клиентский вход;
• Устройство клиентского доступа;
• Доступ к периферийным устройствам;
• Метод аутентификации;
• Способ подключения (тип сети – LAN, удаленный доступ по VPN, SSL-туннель);
• Желаемая пропускная способность канала и показатели задержки;
• Специфические требования к виртуальному десктопу (постоянный доступ/уменьшение ресурсов для обновления рабочего стола/повышенные запросы по ресурсам/мультимедиа и видео, улучшенная графика и пр.) и нужды в определенных программных средствах, в т. ч. драйверах, к примеру.

Кроме того, важно учесть, какой почтой пользуются сотрудники, применяется ли ПО Microsoft Office и другие наборы инструментов в работе, насколько активными будут они в процессе и есть ли пики загруженности десктопов в течение рабочего дня?

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

Понятие строительных блоков и подов Horizon

В дизайне десктопной виртуализации используется понятие «строительных блоков» – комбинации физических серверов, инфраструктуры vSphere, серверов самого Horizon, общих хранилищ, сетевых компонентов, ВМ десктопов для конечных пользователей. Это логическая конструкция, предельные размеры которой будут рассмотрены ниже в разделе «Требования и совместимость». Строительные блоки бывают двух видов:

• управляющие (единственный),
• ресурсные:

По best practice не стоит допускать более 4 000 сеансов на каждый блок Horizon.

Строительные блоки могут собираться в т.н. поды (до пяти ресурсных блоков в одном поде и только один – в управляющем), которые, в свою очередь, управляются как одно целое. В случае подов легко добиться мульти-серверной сетевой конфигурации при развороте десктопной виртуализации, использующей технологии реплицирования во избежание потерь коннекта пользователей и простоев в работе даже в случае падения одного из инстансов Connection Server:

Также в этом случае доступны преимущества балансировки нагрузки и рост емкости ресурсов:

Пулы десктопов

В средних и больших средах, тем более с разнообразием категорий пользователей и вариативными их требованиями, без создания пулов десктопов никак не обойтись. Один такой пул может включать тысячи удаленных рабочих столов. Удобно, что, создав единственный образ десктопа по каждой категории, с помощью Horizon 2012 можно сгенерировать любое поддерживаемое количество его клонов.

При этом весь пул будет управляться централизованно, используя в качестве источника ресурсов:

• физическую систему или физический десктопный ПК,
• виртуальную машину на ESXi-хосте под vCenter Server или на другой платформе виртуализации, поддерживающей Horizon Agent,
• сессионный рабочий стол на RDS-хосте.

В случае vSphere для него устанавливается минимальное и максимальное кол-во создаваемых десктопов, а затем можно ими управлять, применяя сразу к пулу определенные настройки, разворачивая приложения по всем удаленным рабочим столам, указывая, какие именно пользователи или их группы (категории) могут иметь к нему доступ, назначать протокол удаленного отображения по умолчанию, предоставляя юзерам права на замену этого протокола. Как для ВМ полных клонов, так и для linked-clone-машин, можно задавать настройки прямо по всему пулу, решать, удалять ли полностью виртуалку по окончанию с ней работы, выключать ли ее при простое и т.д.

В зависимости от назначения пулы десктопов бывают двух видов:

• С выделенным назначением (каждому пользователю сопоставляется конкретный удаленный рабочий стол, и всякий раз, входя в систему, он будет возвращаться на него же. При этом требуется однозначное соответствие десктопа и юзера, то есть, сколько пользователей – столько и рабочих столов);
• С плавающим назначением (пользователи одного десктопа могут тасоваться, некоторое кол-во рабочих столов может использоваться превышающим это значение числом пользователей. Удаленный десктоп можно удалить и воссоздать заново после каждого использования, а среда строго контролируется администратором).

Пулы приложений

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

• Доступность приложений независимо от точки подключения к сети, возможность настраивать безопасность сетевого доступа;
• Независимость устройств с возможностью использовать самый широкий их спектр под управлением всех распространенных ОС;
• Контроль доступа к приложениям как отдельных пользователей, так и сразу групп юзеров;
• Ускоренный разворот приложений;
• Полная управляемость софтом (разворот, настройка, поддержка, техобслуживание и апгрейды комплексом для всех приложений в пуле одновременно);
• Рост безопасности использования приложений;
• Снижение ресурсных затрат.

О том, как создавать и настраивать пулы десктопов и приложений средствами Horizon, мы поговорим ниже.

Требования и совместимость

Так как Horizon, по факту, является своеобразным придатком виртуальной среды, он весьма неприхотлив в плане требований к своему развороту и совместимости с другими продуктами. Как уже было отмечено, он с равным успехом сотрудничает с любой современной клиентской ОС, однако характеризуется, все же, некоторыми ограничениями и богатым функционалом разных уровней лицензирования.

Совместимость с другими продуктами VMware (в частности, с версией компонентов vSphere, хранилища, NSX, Workspace ONE-линейкой продуктов, Identity Manager, VMware Tools и др.), а также с клиентами самого Horizon следует проверять здесь. А интеграцию с партнерскими платформами и продуктами, «железом» и операционными системами – здесь.

Сетевые требования

Для нормальной работы десктопной виртуализации нужно достичь, минимум 1 Гбит/с скорости связи между всеми компонентами Horizon и десктопами. При расчете пропускной способности хранилища следует учесть, что такая скорость расписывается на каждую сотню ВМ в инфраструктуре.

В большинстве же своем, все ограничения, которые мы описывали в статье «Инсталляция и разворот VMware vSphere 7.0» актуальны и для нее.

Также следует открыть все необходимые порты для существующих типов связи и всех компонентов Horizon. Соответствующие таблицы и схемы будут приведены ниже в разделе «Подготовка к инсталляции компонентов VMware Horizon 8 2012».

Требования к хранилищу

Все, что писалось выше для сети, работает и при выделении хранилища под компоненты Horizon. В самых простейших случаях, если, к примеру, нет отдельного стораджа или не пользуетесь vSAN, можно создать обычное локальное хранилище на ESXi-хосте.

Требования к браузеру

Администрирование Horizon через консоль (веб-приложение) диктует определенные требования к браузеру. Это может быть лишь:

• Internet Explorer 11,
• Firefox (последние версии),
• Chrome (последние версии),
• Safari (последние версии),
• Microsoft Edge (Windows 10).

Поддерживаемые базы данных

Чтобы проверить совместимость своей базы данных с Horizon 2012 нужно зайти на страницу, и на второй вкладке «Solution/Database Interoperability» выбрать в первой секции «VMware Horizon» и «2012». Ниже будет следующий список:

Требования к инстансам Connection Server

По «железу», Connection Server нуждается в, минимум, одном процессоре класса Pentium IV 2.0GHz или выше (рекомендовано использовать 4 CPU), 4-10 ГБ памяти (верхний диапазон здесь – минимальное значение для разворотов Connection Server, обслуживающих 50 и более удаленных десктопов).

Требования к агенту Horizon

Устанавливать Horizon Agent можно на таких Windows 10-гостевых операционных системах:

• Windows 10 20H2 SAC (Pro,Education,Enterprise),
• Windows 10 2004 SAC (Pro,Education,Enterprise),
• Windows 10 1909 SAC (Pro,Education,Enterprise),
• Windows 10 LTSC 2019 (Enterprise),
• Windows 10 1607 LTSB (Enterprise).

И на следующих ОС, не относящихся к семейству Windows 10:

• Win Server 2019 (Standard/Datacenter) – 64 bit,
• Win Server 2016 (Standard/Datacenter) – 64 bit,
• Win Server 2012 R2 (Standard/Datacenter) – 64 bit,
• Ubuntu 16.04 и04 x64,
• RHEL 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 8.0, 8.1 и2 x64,
• CentOS 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 8.0, 8.1 и2 x64,
• SLED 12.x SP3,
• SLES 12.x SP3 и

Требования к ВМ для удаленных десктопов

По понятным причинам, размер памяти, CPU и дисков ВМ напрямую влияет на функционал, скорость и качество работы предоставляемых Horizon десктопов и приложений. Здесь все, конечно же, очень индивидуально, и зависит от состава требований, описанных выше в дизайне категорий пользователей, плотности графика обращения к ВМ, вычислительной или мультимедийной сложности приложений.

Для пользователей, нуждающихся в высокопроизводительных десктопах и приложениях (ярким примером их служат разработчики ПО), рекомендована дуальная система vCPU или даже из четырех единиц. Последняя справится и с 4К-разрешением экрана, проигрыванием HD-видео и тяжелыми CAD-приложениями. Для всех других классов пользователей за глаза хватит и одного процессора.

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

Стандарт разрешения	Размеры, в px	RAM для 1 монитора, в МБ	RAM для 2 мониторов, в МБ	RAM для 3 мониторов, в МБ	RAM для 4 мониторов, в МБ
VGA	640х480	1.20	3.20	4.80	5.60
WXGA	1280х800	4.00	12.50	18.75	25.00
1080p	1920х1080	8.00	25.40	38.00	50.60
WQXGA	2560х1600	16.00	60.00	84.80	109.60
UHD (4K)	3840х2160	32.00	78.00	124.00	170.00

Минимально же для 32-bit Windows 7-десктопов и более новых следует выделять 1 ГБ памяти, а для 64-bit Windows 7 и новее – 2 ГБ. 3D-рабочие процессы требуют не менее 4 ГБ RAM и 2 vCPU.

Что же касается размера дискового пространства, следует помнить, что в стандартных случаях рекомендуется выделять для ВМ удаленного десктопа 24 ГБ (немного меньше, чем в обычном случае) системного диска и более 5 ГБ места для пользовательских данных. В случае же доставки приложений, для работы пользователя с Microsoft Word, Excel, PowerPoint, Adobe Reader, Internet Explorer, McAfee Antivirus и PKZIP пользователю понадобится, минимум 8 ГБ места на системном диске.

Требования к ВМ для RDS-хоста

В отношении RDS-хоста справедливы следующие минимумы:

• RAM – 24 ГБ,
• vCPU – 4,
• емкость системного диска – 40 ГБ,
• ОС – 64-bit Windows Server 2008 R2 или Windows Server 2012 R2.

Лимиты для Horizon 2012

На этой странице содержится полезная информация о максимумах конфигурации Horizon 2012 для Cloud Pod Architecture (федерация и поды), организации Connection Server (память и vCPU ВМ на каждый сервер), а также предельно доступное количество сессий для них, сколько может быть десктопов в одном инстант-клоне, связанном или полном клоне, RDS-хостов в ферме, кол-во активных сессий для UAG и многие другие нужные вещи.

Лицензирование

Важным моментом в подготовке к установке и дальнейшему использованию Horizon является выбор подходящего уровня лицензии. Для этого продукта их предлагается три:

	VMware Horizon	VMware Horizon Advanced Edition	VMware Horizon Enterprise Edition
Что подлежит лицензированию?	Каждое конкурентное соединение	Доступно и для каждого конкурентного пользователя, и для именованного	Доступно и для каждого конкурентного пользователя, и для именованного
Возможности и компоненты	VMware Horizon ThinApp vSphere Desktop vCenter Desktop Blast Performance	Все, что для VMware Horizon-лицензии + Workspace ONE Access Virtualization Pack для Skype for Business vSAN для Horizon RDSH Hosted Applications	Все, что для VMware Horizon Advanced Edition-лицензии + VMware vRealize Operations для Horizon vRealize Automation Plug-In App Volumes VMware Dynamic Environment Manager Horizon для Linux

Первый вариант – это автономная версия с базовым функционалом для тестов, демонстраций и очень небольших компаний со скромными требованиями. Advanced ведет себя куда гибче в процессе доставки приложений и рабочих столов, имеет расширенные возможности автоматизации. Этот тип лицензии позволяет обращаться к десктопам и приложениям не только конкурентным пользователям, но и именованным. То есть тем, для кого актуален доступ к ВМ в течение всего дня. Что для нее, что для Enterprise предлагается Workspace ONE Access, но в случае последней имеем вдобавок весь комплект вкусностей от vRealize, включая автоматизацию и облака, а также App Volumes.

Приятно, что vSphere Desktop, участвующая во всех трех уровнях лицензирования равна по своему функционалу vSphere Enterprise Plus.

App Volumes

Корпоративные уровни лицензии позволяют использовать систему централизованного управления всеми приложениями App Volumes. Она помогает построить динамичную схему доставки приложений с помощью виртуальных дисков на десктопы в режиме реального времени. Сами рабочие столы или приложения при этом не требуют никакой модификации.

Инфраструктура App Volumes состоит из следующих компонент:

• База данных App Volumes (Microsoft SQL для продакшена или SQL Express для не-продакшен приложений), содержащая конфигурационную информацию для AppStack, томов с возможностью записи, пользователей, ВМ, прав и транзакций;
• Пакет приложений (Application Package) – том, доступный только для чтения, в котором может находится любое количество Windows-приложений. Несколько пакетов могут сопоставляться с индивидуальной системой или пользователем;
• Том с возможностью записи (Writable volume) представляет собой пользовательский том, где можно хранить свои данные (информацию локального профиля вроде настроек приложений, лицензии и т.д., установленных пользователем приложения). В каждый момент времени пользователю может быть доступен только один Writable volume.

Все эти компоненты содержатся в хранилище, поэтому производительность стораджа оказывает на них прямое влияние.

В Horizon не обойтись без концепции SDDC (программно-определяемого дата-центра). Следовательно, нужны, по крайней мере, базовые знания в организации виртуальной среды vSphere, в виртуализации хранилищ и сети. Освежить их, при необходимости, рекомендуем в наших статьях: «Инсталляция и разворот VMware vSphere 7.0», «Дизайн и разворот vSAN 7.0U1», «Дизайн VMware NSX-T Data Center 3.1» и «VMware NSX-T Data Center 3.1: Разворот с нуля».

Далее будем готовиться к развороту Horizon, предполагая, что установка гипервизора и vCenter Server, разворот виртуальных машин, использование VMware Tools (гайд по ним можно прочитать здесь), организация виртуального хранилища и сети, работа с AD и Identity Manager, а также другими сопутствующими технологиями и продуктами не представляют сложности для читателя.

Так как целью этой статьи является обучение базовым принципам разворота Horizon и обеспечения его минимальной функциональности в процессе использования, в качестве исходных данных будем рассматривать on-premise-среду vSphere (клауд-случаям в разрезе сотрудничающих вендоров уделим внимание в будущем соответствующем цикле материалов нашего блога). Она станет использовать минимум ресурсов и всего несколько опубликованных приложений, а также виртуальный десктопный пул. Приложения будут доставляться при помощи RDSH-серверов, а десктопный пул и серверная ферма создадутся с использованием instant-clone-технологии. Устройства клиентов Horizon, предположим, используют ОС Windows-семейства.

Также понадобится предварительно загрузить все требуемые инсталляторы в соответствии с уровнем приобретенной лицензии с этой страницы. Если лицензия еще не приобретена, а посмотреть на возможности продукта вживую все же хочется, доступен 90-дневный бесплатный триал. Скачать нужно следующее:

• Horizon Connection Server (64-bit),
• Horizon Agent (64-bit),
• Horizon GPO Bundle.

Учтите, что, если лицензия была уже куплена, в процессе инсталлятор предложит ввести ее ключ.

Удобно, что в случае отсутствия готовой развернутой среды vSphere, последние версии гипервизора и vCenter Server Appliance можно скачать там же. Понадобится минимум 1 ESXi-хост и 1 инстанс vCenter Server.

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

Следующим этапом подготовки станет открытие нужных портов и проверка, включает ли наша аутентификационная инфраструктура AD, DNS и DHCP, настроена ли (опционально) TLS/SSL-сертификация (по дефолту сервера Horizon включают само-подписанные сертификаты), развернут ли сервер базы данных SQL для создания базы событий, куда будет записываться все, что вы делаете в системе (если нет, простая схема его создания будет приведена ниже).

Сетевые порты для Horizon

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

(Если на диаграмме плохо видно детали, вот ссылка на ее HTML5-версию, где есть возможности зумминга).

На этой схеме показаны три различных типа клиентских подключений и все варианты их организации. Однако в производственных схемах далеко не всегда есть нужда в открытии всех этих портов. Например, если Blast Extreme является единственным используемым протоколом, нет необходимости открывать PCoIP и RDP-порты.

Важно! UDP-протоколы Horizon являются двунаправленными. Следует настроить stateful-файерволы на ответный прием UDP датаграмм.

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

Внутренняя связь

Начальная аутентификация в этом случае производится на Connection Server, после чего клиент подключается напрямую к агенту на виртуальном десктопе или RDS-хосте.

Источник	Назначение	Сетевой протокол	Порт назначения	Примечания
Клиент Horizon	Connection Server	TCP	443	Трафик логгирования. SSL (HTTPS-доступ) включен по дефолту для клиентских подключений, однако порт 80 (HTTP-доступ) все равно может использоваться в ряде случаев
Агент Horizon	TCP	22443	Blast Extreme
UDP	22443	Blast Extreme
TCP	4172	PCoIP
UDP	4172	PCoIP
TCP	3389	RDP
TCP	9427	Опционально, для перенаправления диска клиента и перенаправления мультимедиа
TCP	32111	Опционально, для перенаправления USB
Браузер	Connection Server	TCP	8443	Доступ по HTML
Workspace ONE Access Appliance	TCP	443	Логгирование и трафик данных Workspace ONE Access
оба	88	iOS SSO
TCP	5262	Android SSO
TCP	7443	Аутентификация SSL-сертификата
Workspace ONE Access Connector	TCP	443	Требуется только для использования во входящем режиме коннектора (рекомендован исходящий) при настроенной проверке подлинности Kerberos

Внешняя связь

Этот вид связи отвечает за безопасный доступ к ресурсам Horizon из внешней сети (с помощью Unified Access Gateway (UAG)). Этот сервис располагается на Edge, куда поступают все запросы клиента извне, после чего они связываются с внутренними ресурсами.

Источник	Назначение	Сетевой протокол	Порт назначения	Примечания
Клиент Horizon	UAG	TCP	443	Трафик логгирования. SSL (HTTPS-доступ) включен по дефолту для клиентских подключений, однако порт 80 (HTTP-доступ) все равно может использоваться в ряде случаев. Также может нести туннелированный RDP, Client Drive Redirection и USB-перенаправление трафика
TCP	4172	PCoIP черезPCoIP Secure Gateway на UAG
UDP	4172	PCoIP черезPCoIP Secure Gateway на UAG
TCP	8443	Blast Extreme через Blast Secure Gateway на UAG для трафика данных (производительный канал)
UDP	8443	Blast Extreme через Blast Secure Gateway на UAG для трафика данных (адаптивный транспорт)
TCP	443	Blast Extreme через Blast Secure Gateway на UAG для трафика данных с использованием расшаривания портов (вместо TCP 8443)
Браузер	UAG	TCP	8443 или 443	Horizon HTML Access (дефолтный 8443 на UAG меняется на 443)
Workspace ONE Access Appliance	TCP	443	Логин в Workspace ONE Access и трафик данных
оба	88	iOS SSO
TCP	5262	Android SSO
TCP	7443	Аутентификация SSL-сертификата
Workspace ONE Access Connector	TCP	443	Требуется только для использования во входящем режиме коннектора (рекомендован исходящий) при настроенной проверке подлинности Kerberos

Важно! Если UAG настраивается для использования и IPv4, и IPv6, TCP/UDP нужно установить на порт 443. Можно включить UAG как мост между клиентами IPv6 для подключения к Connection Server на IPv4 или к среде агента.

Туннелированная связь

Туннелированная связь использует Connection Server для предоставления служб шлюза. Аутентификация и трафик сеансов в этом случае идет через Connection Server. Эта ситуация не так распространена на практике, потому как UAG даже более функционален в этом смысле.

Источник	Назначение	Сетевой протокол	Порт назначения	Примечания
Клиент Horizon	Connection Server	TCP	443	Трафик логгирования. SSL (HTTPS-доступ) включен по дефолту для клиентских подключений, однако порт 80 (HTTP-доступ) все равно может использоваться в ряде случаев. Также может нести туннелированный RDP, Client Drive Redirection и USB-перенаправление трафика
TCP	8443	Blast Extreme на o Blast Secure Gateway
TCP	4172	PCoIP на PCoIP Secure Gateway
UDP	4172	PCoIP на PCoIP Secure Gateway
Браузер	Connection Server	TCP	8443	Horizon HTML Access
Workspace ONE Access Appliance	TCP	443	Вход в Workspace ONE Access и трафик данных
оба	88	iOS SSO
TCP	5262	Android SSO
TCP	7443	Аутентификация SSL-сертификата
Workspace ONE Access Connector	TCP	443	Требуется только для использования во входящем режиме коннектора (рекомендован исходящий) при настроенной проверке подлинности Kerberos

Сетевые порты для связи виртуального десктопа или RDS-хоста с другими компонентами Horizon

Источник	Назначение	Сетевой протокол	Порт назначения	Примечания
Агент Horizon	Connection Server	TCP	4002	Java Message Service (JMS) при использовании расширенной безопасности (по умолчанию)
TCP	4001	JMS (устаревший)
TCP	389	Требуется исключительно при регистрации неуправляемого агента
Cloud Connector	TCP	11002	Сбор данных агентом
Агент App Volumes	App Volumes Manager	TCP	443	Если не используются SSL-сертификаты можно применять порт 80
Dynamic Environment Manager FlexEngine	Общедоступные файловые ресурсы	TCP	445	Для доступа агента Dynamic Environment Manager к SMB-файловым ресурсам

Порты для связи Connection Server с другими компонентами

Источник	Назначение	Сетевой протокол	Порт назначения	Примечания
Connection Server	Агент Horizon	TCP	22443	Blast Extreme для туннелированной связи
TCP	4172	PCoIP для туннелированной связи
UDP	4172	PCoIP для туннелированной связи
TCP	3389	RDP для туннелированной связи
TCP	9427	Опционально, для перенаправления диска клиента и перенаправления мультимедиа для туннелированной связи
TCP	32111	Framework-канал, используемый ws_admin. Один из вариантов применения: для vdmadmin с целью настройки или чтения из агента
TCP	32111	Опционально, для USB-перенаправления при туннелированной связи
vCenter Server	TCP	443	SOAP-сообщения
Connection Server	TCP	4100	JMS для реплицирования Connection Server с целью масштабирования и избыточности
TCP	4101	JMS SSL для реплицирования Connection Server с целью масштабирования и избыточности
TCP	32111	При инсталляции реплики Connection Server и при смене ключа мастера кластера
TCP	135	При сопоставлении конечной точки MS-RPC. Требуется для репликации Connection Server
TCP	49152 -65535	Динамический диапазон клиентских портов MS-RPC. Для нормальной работы Remote Procedure Call (RPC) и репликации AD (Microsoft Windows)
TCP	389	Используется исключительно в процессе инсталляции реплики Connection Server
TCP	22389	Cloud Pod Architecture ADLDS – глобальная LDAP-репликация
TCP	22636	Cloud Pod Architecture ADLDS – защищенная глобальная LDAPS -репликация
TCP	8472	Cloud Pod Architecture внутренний под VIPA
База данных (события)	TCP	1433	Если используется Microsoft SQL база данных (по дефолту 1443)
TCP	1521	Если используется Oracle база данных
Сервер регистрации	TCP	32111	Framework-канал
Workspace ONE Access Appliance	TCP	443	Шина сообщений
RSA SecurID Authentication Manager	UDP	5500	Двухфакторная аутентификация. Порт настраивается

Порты для связи UAG с другими Horizon-компонентами

Источник	Назначение	Сетевой протокол	Порт назначения	Примечания
UAG	Connection Server	TCP	443	Вход
Агент Horizon	TCP	22443	Blast Extreme
UDP	22443	Blast Extreme
TCP	4172	PCoIP
UDP	4172	PCoIP
TCP	3389	RDP
TCP	9427	Опционально, для перенаправления диска клиента и перенаправления мультимедиа
TCP	32111	Опционально, для USB-перенаправления
RADIUS и др.	UDP	5500	Аутентификация другого типа. Настраивается

Порты для сервера регистрации (Enrollment Server)

Источник	Назначение	Сетевой протокол	Порт назначения	Примечания
Сервер регистрации	AD Certificate Services	TCP	135	Запросы на получение временного краткосрочного CA-сертификата Microsoft
Домен-контроллеры AD	Использует все соответствующие порты для обнаружения домен-контроллеров, привязки и запросов к AD. Подробности здесь

Порты для связи App Volumes Manager с другими компонентами Horizon

Источник	Назначение	Сетевой протокол	Порт назначения	Примечания
App Volumes Manager	App Volumes Manager	TCP	3001-3004	HTTP
TCP	54311	HTTPS
vCenter Server	TCP	443	SOAP
ESXi	TCP	443	Hostd
База данных	TCP	1433	Дефолтный порт для Microsoft SQL
AD	TCP	389	LDAP
TCP	636	Опциональный, LDAPS

Порты для консоли администрирования

Источник	Назначение	Сетевой протокол	Порт назначения	Примечания
Браузер, с которого осуществляется администрирование	Horizon Connection Server	TCP	443	https://<FQDN Connection Server>/admin
vCenter Server	TCP	443	https://<vCenter Server FQDN>/
Horizon Cloud Connector	TCP	443
App Volumes Manager	TCP	443	https:// <App Volumes Manager Server FQDN>/
Workspace ONE Access Appliance	TCP	443	https://<W1 Access Instance FQDN>
TCP	8443	https://<W1 Access Appliance FQDN>:8443/cfg/login
TCP	22	SSH
Workspace ONE Access Connector	TCP	8443
TCP	22	SSH
UAG	TCP	9443	https://<UAG FQDN or IP Address>:9443/admin/
Microsoft Remote Assistant	Virtual Desktop or RDS Host	TCP	3389	RDP-трафик для удаленных сеансов

Завершая тему сетевой организации Horizon, напомним, что vCenter Server связывается с ESXi по TCP-протоколу через порт 902 для получения SOAP.

О портах и сетевых настройках, необходимых для работы Horizon Cloud Connector, подробный разговор состоится в отдельном цикле статей, посвященных облачной виртуализации от VMware. Аналогично и по Workspace ONE.

Создание ВМ для Connection Server и сервера базы данных

Важно! Если вы уже работаете с vSphere-средой и там проинсталлированы ВМ с Windows Server, можно использовать их, или же их клоны, в случае соответствия требованиям по виртуальному «железу».

Для начала нужно запастись ISO-файлом Windows и загрузить его на датасторадж vSphere (версия ОС должна поддерживаться – см. выше в разделе «Требования и совместимость»). Все дальнейшие операции следует проделывать под привилегиями, позволяющими создавать ВМ.

Принцип создания новой ВМ в веб-клиенте нам хорошо знаком, но все же приведем его пример с подготовкой конкретно под Horizon с нашими исходными данными:

• Кликаем правой кнопкой на дата-центр, кластер, хост или папку с ВМ и выбираем «New Virtual Machine»:

• В появившемся визарде пройдем последовательно все его пункты:

«Select a creation type». Выбираем первую строку из приведенного меню – «Create a new virtual machine»:

«Next»;

«Select a name and a folder». Называем как-то информативно нашу ВМ и выбираем ее месторасположение:

«Next»;

«Select a compute resource». Выбираем кластер или хост в качестве вычислительного ресурса:

«Next»;

«Select storage». Выбираем хранилище для новой ВМ:

«Next»;

«Select compatibility». Выбираем минимальную версию ESXi-хоста, на которой наша ВМ будет разворачиваться:

«Next»;

«Select a guest OS». Назначаем гостевую операционную систему как Windows и выбираем ее версию с корректной архитектурой (Microsoft Windows Server 2019):

«Next»;

«Customize hardware». Этот пункт меню состоит из двух вкладок. Начнем с «Virtual hardware».

Указываем настройки виртуального «железа». 4 CPU, 4 ГБ памяти, обязательно раскрываем секцию «Memory», где ставим галочку на «Reserve all guest memory (All locked)». Затем далее выбираем подходящий размер жесткого диска (40 ГБ), тип нового SCSI контроллера (LSI Logic SAS), в «New Network» назначаем подходящую сеть и раскрываем эту секцию, чтобы выбрать тип адаптера как «VMXNET 3», ставим галочки на статусе подключения и включении прямого пути ввода-вывода. После в пункте «Datastore ISO File» ищем наш предварительно загруженный ISO Windows и ставим галочку на «Connect…», удаляем крестиком USB-контроллер по строке «New USB Controller». Теперь нужно раскрыть секцию «Video card», выбрать количество желаемых мониторов (у нас – 1) и выделить под память для видео, например, 32 МБ (см. табличку сверху в теме «Требования к ВМ для удаленных десктопов» раздела «Требования и совместимость»):

Вторая вкладка – «VM Options» – здесь раскрываем секцию «Advanced» и нажимаем на «Edit Configuration…»:

В появившемся окне нажимаем на «Add configuration params» и в поле «Name» набираем «devices.hotplug», а напротив в «Value» – «False», чтобы отключить функцию авто-определения:

После этого нажимаем на «ОК» для сохранения настройки и жмем «Next»;

В последнем пункте визарда «Ready to complete» проверяем сделанные настройки, и, если все устраивает, кликаем на «Finish».

• После загрузки новой ВМ инсталляция операционной системы (мы ее указали в предыдущем пункте) стартует автоматически. Принимаем все дефолтные настройки и соглашаемся с предупреждениями. Обязательно указываем, что речь о новой инсталляции, а не об апдейте. Открываем удаленную консоль, выбираем новосозданную ВМ в инвентаре и запускаем ее консоль, нажав на «Launch Remote Console» (если она предварительно проинсталлирована. Если нет – выбираем «Launch Web Console». Кстати, удаленную консоль можно прямо тут же загрузить и установить, если нажать на «i»):

В консоли включаем ВМ соответствующей иконкой:

Загружаем ВМ с виртуального CD, нажав любую клавишу на клавиатуре:

В появившемся окне выбираем настройки региона:

«Next»;

Нажимаем на «Install now»:

В выскочившем окне выбираем операционную систему:

Ставим галочку в лицензионном соглашении и нажимаем «Next»;

В следующем окне нам нужно выбрать второй пункт – «Custom: Install Windows only (advanced)»:

Выбираем место для установки (по дефолту) и жмем «Next»:

Какое-то время будет идти инсталляция. Затем нужно задать традиционные настройки, чтобы завершить процесс инсталляции Windows.

• Устанавливаем VMware Tools, используя веб-клиент vSphere, где нужно подмонтировать соответствующий виртуальный DVD:

Нажав на «Install VMware Tools», а затем на «Mount», получим искомый результат. Альтернативно, можно выбрать ВМ в инвентаре, и в выпадающем меню «Actions» нажать на «Guest OS», и после – на «Install VMware Tools».

Теперь открываем командную строку и запускаем следующую команду:

d:setup64.exe /s /v” /qb REBOOT=R ADDLOCAL=ALL REMOVE=Hgfs,SVGA,VSS,AppDefense,NetworkIntrospection”

• Для инсталляции .NET Framework 3.5 открываем командную строку и запускаем команду:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:sourcessxs

Устанавливаем все требуемые компоненты, которые используют Windows Update (C++ runtime, Office и др.).

• В завершение нам нужно установить последние апдейты Для этого в настройках кликаем на «Update & Security»:

В открывшемся окне нажимаем на «Check for updates»:

Важно! Если речь о не принадлежащих к LTSB версиях Windows 10, вначале нужно кликнуть на «Advanced options» и выбрать «Defer feature upgrades».

Ждем окончания инсталляции обновлений и перезапускаем ОС:

Этой новой виртуальной машине с установленной на ней ОС суждено стать шаблоном – золотым образом, с которого будем клонировать все остальные необходимые в дальнейшем. Процесс полностью повторяет то, к чему мы привыкли в vSphere. Если есть необходимость освежить знания по этому вопросу, рекомендуем воспользоваться этим и этим гайдами.

Одним из созданных клонов будет ВМ Connection Server (в зависимости от дизайна их может быть несколько – см. выше), другим – машина для сервера базы данных, если она необходима. Учтите, что для дальнейшего разворота сервера базы данных нужны Microsoft SQL Server Management Studio, Microsoft SQL Server Configuration Manager, которые должны быть проинсталлированы на SQL-сервере.

Важно! В процессе разворота этих ВМ им нужно назначить неизменяемый IP-адрес. В средах IPv4 следует настроить статический IP, а в IPv6 машины будут автоматически получать неизменяемый адрес.

Последним шагом подготовки нашей ВМ к развороту компонент Horizon станет копирование на нее инсталлятора Connection Server, а также снятие снэпшотов средствами веб-клиента vSphere после выключения созданных и настроенных, как было показано выше, виртуалок золотых образов.

Разворот VMware Horizon 2012

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

1. Проинсталлировать Connection Server. После этого станет доступна консоль администрирования Horizon и можно сконфигурировать должным образом на начальной стадии инструменты нашей десктопной виртуализации;
2. С помощью веб-клиента vSphere создать золотые образа десктопов Windows и RDSH-сервер, на котором будут хоститься приложения. На подготовленных виртуальных машинах устанавливаются и настраиваются нужные ОС, а также агенты Horizon;
3. Используя консоль Horizon, создать пулы десктопов из готовых золотых образов (автоматическое клонирование десктопов) и ферму RDSH-серверов (автоматическое клонирование серверов);
4. Опубликовать один или несколько пулов приложений при помощи визарда Add Application Pool;
5. Через консоль предоставить пользователям или их группам права доступа к десктопам и приложениям, предварительно зарегистрировав их в AD;
6. Загрузить бесплатное ПО Horizon Client от VMware/app store и проинсталлировать на клиентских устройствах с iOS, Android, Chromebook, Windows, macOS или Linux, либо же просто научиться заходить на URL сервера в браузере, чтобы использовать веб-клиент HTML Access.

Приступим к воплощению этих этапов в жизнь.

Установка и начальная настройка Connection Server

В первую очередь, приступаем к инсталляции Connection Server:

• Находим загруженный ранее инсталляционный файл Connection Server и дважды на него кликаем для запуска соответствующего визарда (это файл вида «VMware-Horizon-Connection-Server-x86_64-x.x.x-build_number.exe»). Соглашаемся с предупреждением, что приложение может внести изменения в наше устройство кнопкой «Yes»;
• В появившемся окне опций инсталляции выбираем из выпадающего списка тип установки «Horizon Standard Server», ставим галочку на «Install HTML Access» и указываем тип протокола для связи (IPv4):

• В окне «Data Recovery» вводим пароль, который хотим в будущем использовать для восстановления данных с бэкапа;
• В окне «Firewall Configuration» все принимаем по дефолту («Configure Windows Firewall automatically»);
• В окне «Initial Horizon Administrators» авторизируем AD-домен-группу:

• В окне «User Experience Improvement Program» можно снять отметку с «Join the VMware Customer Experience Improvement Program» по желанию;
• В окне «Ready to Install» оставляем дефолтное значение из выпадающего списка («General»), так как у нас on-premise-среда, и жмем «Install»:

• В окне «Installer Completed» нажимаем «Finish».

После этого запустится процесс инсталляции Connection Server и станет доступной консоль, зайти в которую можно двумя способами:

• Либо дважды нажав на соответствующий ярлык на рабочем столе («Horizon Administrator Console») после захода на сервер, где установлен Connection Server. Альтернатива – открыть браузер и ввести URL «https://localhost/admin/»;
• Либо открыть браузер и ввести «https://<connection-server-hostname>/admin/», если заход в консоль осуществляется с машины, которая не использовалась в процессе инсталляции. В этом случае в процессе вероятно появление предупреждения о безопасности, обойти которое можно используя подходящие инструменты пользовательского интерфейса, индивидуальные для типа браузера (в Firefox, к примеру, нужно нажать на кнопку «Advanced», прокрутить вниз страничку и кликнуть на «Accept the risk and continue»).

Вход в консоль администрирования Horizon осуществляется под привилегиями пользователя или группы пользователей, которые мы указывали выше в процессе инсталляции Connection Server. И теперь нам доступна настройка этого компонента, перед которой стоит огласить ряд замечаний.

Далее мы научимся создавать аккаунты пользователей домена и юниты организации AD для операций клонирования, однако этот момент является опциональным, так как демонстрационные среды, к примеру, могут обойтись и без них. Аналогично рассмотрим установку базы данных событий, чтобы отслеживать операции входа в Horizon, но, если этого не сделать, ничего критичного не случится – все равно будет доступ напрямую к логам, которые можно, например, настроить для отсылки информации на Syslog-сервер.

Создание Domain User Account и юнитов организации в AD для операций клонирования

Задача перед нами на этом этапе стоит простая: создать пользовательский аккаунт в AD с привилегиями для разворота и удаления склонированных десктопов, а также один организационный юнит (OU) в AD для моментально склонированных десктопов и других инстант-клонов RDSH-серверов.

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

• Заходим под правами администратора на машину домен-контроллера AD и нажимаем кнопку «Start» – «Administrative Tools» – «Active Directory Users and Computers»;
• Раскрываем список домена, находим папку «Users», кликаем на нее правой кнопкой мыши, после чего из появившегося меню выбираем «New», а затем «User»:

• Проходим последовательно все пункты диалогового окна «New Object – User», введя для удобства одинаковый логин в поля «Full name» и «User logon name». «Next»;
• В окне установки пароля, чтобы упростить себе задачу в дальнейшем, следует отжать галочку на «User must change password at next logon» и выбрать «Password never expires».

Теперь мы сможем добавить этого пользователя в OU AD, где будут содержаться ВМ аккаунтов, и дать ему разрешение на создание и удаление машин в OU:

• Заходим под администратором на машину домен-контроллера AD и проходим по пути «Start» – «Administrative Tools» – «Active Directory Users and Computers»;
• Кликаем правой кнопкой на имя домена, выбираем «New» и затем – «Organizational Unit»;
• В диалоговом окне «New Object – Organizational Unit» вводим имя (например, «Instant Clones») и нажимаем «ОК», и после прохождения этого окна OU появится в домене;
• Находим созданный OU и выбираем «Delegate Control», после чего откроется соответствующий визард, в приветственной странице которого надо нажать «Next»;
• В окне «Users or Groups» нажимаем кнопку «Add», после чего в окне «Select Users, Computers, or Groups» выбираем тип объекта, его локацию и вводим имя объекта (имя администратора, которое задавали выше), после чего кликаем на кнопку «Check Names», чтобы проверить, существует ли такое в AD, и нажимаем на «ОК»:

• После этого нас вернет в окно «Users or Groups», где надо нажать на «Next»;
• В окне «Tasks to Delegate» выбираем «Create a custom task to delegate» и жмем «Next»;
• В окне «Active Directory Object Type» выбираем в «Only the following objects in the folder» – «Computer objects», ставим галочку на «Create selected objects in this folder» и на «Delete selected objects in this folder»:

• В окне «Permissions» отмечаем галочками все в блоке «Show these permissions», и конкретизируем список разрешений, пометив обязательно «Create All Child Objects», «Delete All Child Objects», «Read All Properties», «Write All Properties» и «Reset password»:

«Next». Появится последнее окно визарда, где кликаем на «Finish».

Для задания OU с целью создания инстант-клонов ферм RDSH-серверов повторяем приведенную выше процедуру, но имя в этом случае выбираем «OU RDSH Servers».

Добавление лицензионных ключей

Начинать настройку нашего Connection Server следует с добавления лицензионных ключей продукта, так как, когда вы впервые попытаетесь зайти на Connection Server, консоль откроет страницу «Product Licensing and Usage», которую нужно будет корректно пройти.

Важно! Если лицензия соответствующего уровня еще не куплена, можно пока использовать ознакомительную.

Для добавления лицензионных ключей заходим в консоль Horizon по одному из описанных выше методов, кликаем на «Settings» – «Product Licensing and Usage», где жмем «Edit». Вводим серийный номер лицензии и подтверждаем ввод «ОК». Теперь на странице «Product Licensing and Usage» появятся информация о нашей лицензии, и здесь нужно проверить, не вышел ли ее срок, и включена ли она для десктопов, удаленных действий с приложениями и мгновенного клонирования:

Добавление инстанса vCenter Server

Добавление инстанса vCenter Server в Horizon-среду нужно, как рассказывалось выше в теории, для подключения нашего Connection Server к нему по защищенному каналу. Для этого:

1. В консоли Horizon выбираем в «Settings» – «Servers», после чего откроется вкладка «vCenter Servers», где нужно нажать на кнопку «Add»;
2. На странице «Add vCenter Server» заполняем поля «Server address» (FQDN инстанса vCenter Server) и «User Name and Password» (имя должно быть в формате «name@domain.com»). Остальное все можно оставить по дефолту;

Важно! Если сертификат не валиден, покажется предупреждение «Invalid Certificate Detected». В нем можно посмотреть данные этого сертификата, кликнув на «View Certificate», после чего нажать на «Accept».

1. Остальные страницы визарда прокликиваем, принимая все по дефолту кнопкой «Next», а на странице «Ready to Complete» жмем «Submit»:

По окончанию добавления нового инстанса vCenter Server, он появится на вкладке «vCenter Servers» раздела «Servers».

Добавление администратора домена мгновенного клонирования

В консоли Horizon проходим в «Settings» – «Instant Clone Domain Accounts» и нажимаем на кнопку «Add», в результате чего появится страница «Add Domain Admin», где нужно выбрать домен из списка, ввести имя администратора и пароль, которые впервые инициировались, когда мы создавали пользователя домена с правами администратора, а затем нажать на «ОК»:

После этого нас возвратит на страницу «Instant Clone Domain Accounts», где появится добавленный нами админский аккаунт.

Создание и настройка базы данных событий

Как уже говорилось выше, база данных событий – вещь очень полезная, ведь она фиксирует не только ошибки и системные сбои, но и действия конечных пользователей (открытие десктопных сеансов и приложений), администратора (создание пулов десктопов и приложений, предоставление прав), а также выдает весьма информативную статистику, благодаря которой легче отслеживать загруженность Horizon и планировать его дальнейшую судьбу.

Сама же процедура создания базы данных событий выглядит так:

• Запускаем SQL Server Management Studio на ВМ с SQL Server и в появившемся окне «Connect to Server» выбираем тип сервера («Database Engine»), его имя, тип аутентификации («SQL Server Authentication»), а также задаем логин и пароль;
• В «Object Explorer», кликаем правой кнопкой на «Databases» и выбираем «New Database», называем ее в новом диалоговом боксе, после чего жмем «ОК»;
• Теперь раскрываем папку «Security» и кликаем правой кнопкой на «Logins», после чего выбираем «New Login». В появившемся окне «General Settings» проходим все пункты, введя логин, используемый для машины Connection Server, выбираем «SQL Server authentication» и вводим пароль. Отжимаем галочку на «Enforce password policy», выбираем нашу базу данных событий как дефолтную и переходим к следующему пункту левого меню визарда:

• В пункте «Server Roles» выбираем «sysadmin»;
• В пункте «User Mapping» выбираем в верхнем блоке пользователя, соответствующего этому логину, а ниже – назначаем роль базы данных:

Теперь наш пользователь появится в панели «Object Explorer» в разделе «Logins» папки «Security», а также в папке «Databases» – «HorizonEvents» – «Security» – «Users».

• В завершение нужно настроить свойства TCP/IP для нашего сервера базы данных. На соответствующей ВМ запускаем SQL Server Configuration Manager и в левом меню раскрываем «SQL Server Network Configuration», где выбираем «Protocols for <server name>». В появившемся справа списке кликаем правой кнопкой на «TCP/IP» и выбираем «Properties». Покажется окошко, где на вкладке «Protocol» следует назначить «Yes» по строке «Enabled», а на вкладке «IP Addresses» установить порт TCP для IPAll (1433. Об открытии портов написано выше в разделе «Подготовка…»), а затем нажать «ОК»:

Нам осталось настроить базу данных событий на консоли Horizon. Для этого заходим в «Settings» – «Event Configuration» и в секции «Event Database» кликаем на кнопку «Edit». Появится соответствующий визард, чьи пункты проходим последовательно, задав FQDN сервера базы данных, его тип («Microsoft SQL Server»), порт (назначенный нами выше 1433), имя базы данных, имя пользователя и пароль, а также префикс таблицы (для просмотра событий – «VE_»):

После чего жмем «ОК». Чтобы убедиться, что связь с нашей базой данных работает нормально, заходим в «Monitor» – «Events» консоли и видим, что некоторые записи о логине уже появились в таблице.

Создание однопользовательских десктопных пулов и RDSH-десктопных пулов

Суть однопользовательского десктопного пула в том, что в каждый момент времени только один пользователь может иметь доступ к ВМ. Если же мы говорим об RDSH-десктопных пулах, один сервер RDSH может поддерживать множество конкурентных подключений пользователей для сессионных десктопов. Далее поучимся разворачивать и то, и другое. Для примера, рассмотрим Windows, а если нужны Линукс-десктопы, с отдельным разделом документации VMware по этому вопросу можно ознакомиться здесь.

Работа с мгновенно склонированными клонами десктопов в обоих случаях включает в себя два глобальных этапа:

• публикацию золотого образа,
• предоставление ВМ из пула или фермы.

Первый этап, как правило, занимает 7-40 минут, в зависимости от используемого типа хранилища. А вот предоставление машин – всего 1-2 секунды для каждой. Исходя из этого, конечно же, публикацией стоит озаботиться заранее. К результату и для ферм, и для десктопных пулов помогает прийти визард консоли «Add Farm»/«Add Desktop Pool», соответственно.

Важно! Заранее стоит внести изменения в настройки таймаута сеанса, чтобы не выкинуло посредине процесса публикации. Для этого заходим в «Settings» – «Global Settings» и редактируем параметр «View Administrator Session Timeout».

Разворот однопользовательского десктопного пула

• Запускаем визард «Add Pool», зайдя в «Desktops» раздела «Inventory» консоли, и нажав на кнопку «Add»;
• В первом его пункте «Type» выбираем «Automated Desktop Pool» и нажимаем «Next»;
• В «vCenter Server» выбираем «Instant Clone». «Next»;
• В «User Assignment» выбираем «Floating». «Next»;

Важно! Альтернативой в этой настройке является «Dedicated». В этом случае каждый десктоп будет назначен указанному юзеру и только ему.

• В «Storage Optimization» выбираем «Use separate datastores for replica and OS disks». «Next»;
• В «Desktop Pool ID» заполняем все поля (ID, отображаемое имя либо, если его не назначить, пользователи будут видеть ID, а также «Access Group» – если не назначить ее, пул будет помещен в группу рута. Механизм последней задачи расписан в этой документации, но мы подробно о нем еще будем писать в  нашей следующей статье «Базовые инструменты администрирования VMware Horizon Version 2012»). «Next»;
• В «Provisioning Settings» заполняем все поля (шаблон наименования, характер предоставления машин в «Provision Machines» – нужно выбрать «Machines on Demand» и задать дефолтный минимум, например, равный 1, размер пула десктопов – максимальное кол-во машин (у нас – 10), а «Spare (Powered On) Machines» равно 1, все остальное оставляем по умолчанию):

• В «vCenter Settings» заполняем настройки «Default Image». По «Parent VM in vCenter» нажимаем на «Browse», чтобы выбрать созданный предварительно золотой образ, затем жмем «Submit». По «Snapshot» так же кликаем на «Browse», чтобы выбрать снэпшот, который мы делали в конце «Подготовки…», и снова принимаем все «Submit»;

В пункте «Virtual Machine Location» нажимаем на «Browse», чтобы выбрать папку нашей ВМ;

В пункте «Resource Settings» кликаем на «Browse», чтобы выбрать соответствующий ресурс vCenter для каждого параметра:

«Next»;

• В «Desktop Pool Settings» все оставляем по дефолту и жмем «Next»;
• В «Remote Display Settings» выбираем «Allow Session Collaboration». «Next»;
• В «Guest Customization» проверяем, правильно ли указан домен и аккаунт его администратора (мы создавали его выше), остальное оставляем по дефолту и жмем «Next»;
• В «Ready to Complete» соглашаемся со всей конфигурацией кнопкой «Submit», после чего нас вернет на страницу «Desktop Pools» инвентаря.

За разворотом пула дектопов можно следить на этой же странице, нажимая на «Refresh»:

Статус публикации пула десктопов проверяется в секции «vCenter Server», и, если проскроллить ее вниз, итог наших действий будет отображаться так:

А готовность мгновенного клона к дальнейшей работе – в секции «General» на вкладке «Summary», где число доступных машин в поле «Machines» для нашего примера будет равно 1:

Просмотреть информацию по инстант-клонам персонально можно на соседней вкладке «Machines» или на той, что еще правее, – «Machines (Instant-Clone Details)».

Чтобы в будущем управлять патчами ОС и апдейтами ПО для инстант-клонов в новосозданном десктопном пуле нужно использовать т.н. операцию «push-image». Причем делается это настолько быстро, что нет нужды в планировании техокон. Перед тем, как приступить к этой задаче, обязательно рекомендуется снова сделать снэпшот ВМ. Далее:

1. Заходим в секцию «Inventory» консоли Horizon и нажимаем на «Desktops»;
2. Справа будет список имен пулов десктопов и после выбора какого-то из них откроется вкладка «Summary», где нужно нажать на кнопку «Maintain», выбрав «Schedule» из выпадающего меню;
3. Запустится визард «Schedule Push Image», где в «Image» выбираем новый, только что сделанный нами снэпшот, и жмем «Next»;
4. В «Schedule» оставляем все по дефолту. «Next»;

Важно! Дефолтное значение в этом пункте – «Wait for users to log off». Также можно выбрать принудительный выход пользователей: они получат предупреждение за пять минут до того, как их десктоп выключится. Этот параметр редактируется кнопкой «Edit» в «Settings» – «Global Settings».

1. В «Ready to Complete» жмем «Finish».

Теперь нас вернет на вкладку «Summary», где в секции «vCenter Server» можно будет следить за прогрессом обновления нашего образа, а статус переведется из «Published» в «Publishing»:

Разворот опубликованных RDSH-десктопов и приложений

Через Microsoft Remote Desktop Services (RDS) администраторы предоставляют пользователям десктопы и сеансы работы с приложениями на RDS-хостах. В этом случае опубликованные десктопы и приложения основываются на сеансах подключения к RDSH-серверам.

На практике это реализовывается следующим образом: вначале создается ферма RDSH-сервера из золотого образа ВМ (подготовленного нами заранее в разделе «Подготовка…»), автоматически клонирующая множество указанных серверов, затем публикуется нужное количество пулов приложений с помощью визарда «Add Application Pool», пул сессионных десктопов общего пользования, к которым юзеры получают доступ с RDSH-серверов, и, наконец, идет выполнение задач техобслуживания образов для RDSH-серверов.

Приступим к выполнению этого плана. Для начала создадим мгновенно склонированную ферму RDSH-сервера. Процесс аналогичен тому, что мы делали для разворота автоматизированного пула инстант-клонов десктопов. Запускаем из консоли Horizon визард «Add Farm», зайдя в раздел «Farms» инвентаря и нажав на кнопку «Add». Пройдемся по пунктам этого визарда:

• «Type». Выбираем «Automated Farm» и жмем «Next»;
• «vCenter Server». Выбираем «Instant Clone». «Next»;
• «Storage Optimization». Просто кликаем на «Next»;
• «Identification and Settings». Заполняем поля ID, Access Group, а остальное оставляем по дефолту. «Next»;
• «Load Balancing and Settings». «Next»;
• «Provisioning Settings». Заполняем поля «Naming Pattern» («RDSH-») и «Farm Sizing» (устанавливаем значение «Maximum Machines» на 10, к примеру, и «Minimum Number of Ready (Provisioned) Machines» на 1). «Next»;
• «vCenter Settings». Заполняем настройки дефолтного образа, выбрав золотой образ ВМ RDSH-сервера, кликнув на «Browse» в «Parent VM in vCenter», а также сделанный только что снэпшот в поле «Snapshot» через «Browse», после чего жмем «Submit». В поле «Virtual Machine Location» с помощью «Browse» выбираем папку ВМ, в «Resource Settings» – соответствующий ресурс vCenter, снова через «Browse», а также все остальные настройки, уже назначенные для нашего vCenter Server, и индивидуальные – для имеющейся среды.

Важно! В поле «Network» обязательно нужно оставить все по дефолту.

Выглядеть все это должно примерно так:

«Next»;

• «Guest Customization». Убеждаемся, что указан правильный домен и аккаунт его администратора. В «AD container» нажимаем на «Browse» и выбираем ранее созданный нами OU, а все остальное оставляем, как есть. «Next»;
• «Ready to Complete». «Submit».

После этого нас вернет на страницу «Farms» инвентаря, где можно следить за разворотом фермы, нажав на ее имя в списке. Если оно там еще не появилось, следует просто обновить страничку кнопочкой «Refresh». Процесс публикации отслеживается аналогично тому, что описано выше для мгновенно склонированных десктопных пулов, как и уточняются детали о параметрах клонов.

Теперь можно публиковать хостящиеся на RDSH-серверах приложения. Для этого надо создать пул приложений.

Создание пула приложений

Запускаем из консоли Horizon визард «Add Application», зайдя в «Applications» инвентаря и после нажатия на кнопку «Add», выбрав «Add from Installed Applications». Пробежимся по пунктам этого визарда:

• «Application Pool Type». Оставляем по дефолту («RDS Farm») – созданный только что сервер фермы должен показаться в выпадающем меню. «Next»;
• «Select Applications». Заполняем поля «Select installed applications», выбрав из списка нужные приложения, ставим галочку на «Entitle Users After Adding Pool» (пользователей установим позднее в отдельной теме):

«Next»;

• «Edit Applications». Добавляем «RDSH–» в начало показываемого имени и кликаем на «Submit».

После этого нас вернет на страницу «Application Pools» раздела «Applications» инвентаря, где увидим добавленные нами приложения:

Выполнение техобслуживания для новосозданной серверной фермы позволяет быстро менять ее размер, откатываться до предыдущего состояния диска, обновлять сервера для использования новых золотых образов. При этом старые машины в мгновенно склонированной ферме удаляются и воссоздаются из текущего золотого образа, либо же ВМ организовываются из новых золотых образов, снэпшотов. Как и в рассмотренном выше примере, расписание техобслуживания может назначаться и управляться администратором. Об этом также поговорим в нашей следующей статье из цикла Horizon: «Базовые инструменты администрирования VMware Horizon Version 2012 и настройка групповых политик».

Назначение прав пользователей и обеспечение их доступа к десктопам и приложениям

Завершающим этапом приведения Horizon в рабочий вид станет назначение прав пользователей и предоставление им доступа к рабочим столам и приложениям.

Установка прав пользователей

Выше, когда создавались пулы десктопов и приложений, в соответствующих визардах, если помните, мы отмечали «Entitle users after this wizard finishes». Теперь настало время заняться этим вплотную. Удобно, что Horizon позволяет конкретно для пулов приложений выбирать множество таких пулов, и назначать пользовательские права для них всех скопом. Что же касается десктопных пулов, здесь мы можем выбирать только один пул за раз.

Процедура определения прав пользователей для доступа аналогична для пулов приложений и десктопных пулов, с той лишь разницей, что соответствующие визарды запускаются из разных блоков инвентаря. Рассмотрим для примера вариант пулов приложений, открыв визард «Add Entitlements» (выпадающее меню верхних блоков действий «Entitlements») из консоли, зайдя в инвентаре на «Applications». Предварительно убедившись, что стоит галочка именно на том пуле, который нас интересует в табличке ниже:

Откроется диалоговое окно, в котором следует нажать на «Add», а затем окно «Find User or Group», где нужно найти пользователей. Здесь очень комфортно продуманы меры по интеллектуальному поиску пользователей, что весьма актуально в случае большого их количества. Например, можно напечатать в поле «Starts with» какую-нибудь букву, и права назначатся для всех юзеров, чье имя с нее начинается. Со сделанным выбором нужно согласится кнопкой «ОК».

Теперь в диалоговом окне «Add Entitlements» появится список наших пользователей, после проверки которого снова нужно нажать «ОК». Если что-то забыли, можно опять кликнуть на «Add», также доступно выделение уже неактуальных пользователей в этом списке и удаление их оттуда кнопкой «Remove».

Правильность наших действий ознаменуется тем, что при клике на имя пула приложений в списке и выборе вкладки «Entitlements» мы увидим всех тех пользователей, которым только что предоставили права доступа.

Запуск удаленных десктопов и приложений с клиентских устройств

Завершая разговор о Horizon, нам осталось обсудить тему подключений конечных пользователей. Как уже упоминалось выше в «Теории…», сделать это можно через разного вида клиенты, включая мобильные и десктопные, с самым различным типом ОС, либо же используя веб-клиент HTML-доступа, введя URL Connection Server (https://<FQDN or IP address>).

В разделе «Подготовка…» описывались необходимые действия, предваряющие следующий порядок подключения. Рассмотрим оба его случая – через лаунчер и через HTML Access. В первом случае:

• На клиентском устройстве запускаем VMware Horizon Client, например, двойным кликом на иконку рабочего стола. Когда откроется его окно, жмем на кнопку «New Server», и, если затребует, вводим FQDN Connection Server, после чего кликаем на «Connect». Может появится предупреждающее сообщение, в котором для продолжения нажимаем на «Continue»;
• В окне логина вводим пользовательское имя и пароль (использовать то, для которого выданы права на этот десктоп или опубликованные приложения в предыдущем подразделе), после чего жмем на «Login»;
• Запускаем десктоп или приложение соответствующей иконкой в клиенте:

• В диалоговом окне «Sharing» жмем на «Allow».

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

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

Для использования HTML 5 веб-клиента открываем поддерживаемый браузер (список подходящих описан в разделе «Требования и совместимость») и вводим адрес Connection Server (https://<connection-server-FQDN>). Откроется страница VMware Horizon, где нужно нажать на «VMware Horizon HTML Access». Затем:

1. Вводим данные учетной записи пользователя, которому выданы права на использование этого десктопа или пула приложений, и жмем «Login»;
2. Нажав на искомую иконку, зайдем в этот десктоп или приложение:

При желании для более быстрого поиска, можно некоторые десктопы и приложения помечать как фаворитов, кликнув на значок «звездочки» в верхнем правом уголке каждого.

В процессе работы навигационная панель спрячется в кнопку сайд-бара с левого края экрана, а если кликнуть на иконку «Open Menu» в правом ее угле, выпадет меню, в котором можно выйти из рабочего стола, перейти в полноэкранный режим, ознакомиться с информацией о нем или задать необходимые настройки в «Settings»:

Окно настроек, к слову, выглядит так:

Как видим, здесь можно включать мульти-мониторный режим, высокое разрешение, симулировать использование Windows-ключей для десктопа, разрешать Н.264-декодинг, устанавливать временную зону и перезагружать все запущенные приложения, а также восстанавливать дефолтную страницу лендинга (две последних опции – соответствующими кнопками). Все сделанные настройки сохранятся после нажатия на «Close».

В этой статье мы рассмотрели самый простой вариант разворота ключевых компонентов Horizon, научились задавать необходимую конфигурацию, создавать пользовательские аккаунты, пулы десктопов и приложений, а также фермы RDSH-серверов, настраивать клиентский доступ к опубликованному. Следующий наш материал в цикле десктопной виртуализации – «Базовые инструменты администрирования VMware Horizon Version 2012 и настройка групповых политик» – постарается охватить максимум вопросов администрирования и использования этого продукта. Очень важную и полезную тему организации удаленного доступа Unified Access Gateway (UAG), а также работу с App Volumes и VMware Dynamic Environment Manager в Horizon 8 2012 вынесем в отдельные статьи, так как они весьма объемны и являются приятными, но не необходимыми надстройками. А если хочется глубокого погружения в эту тему, изучения ее самых тонких аспектов и нюансов, рекомендуем обязательно посетить авторизованные курсы VMware по Horizon.