В первой части статьи, опубликованной в предыдущем номере журнала, мы рассматривали технологии, реализующие виртуализацию настольных систем, включая виртуализацию приложений, перемещаемые профили, перенаправление папок и виртуализацию операционной системы. Я рассказал о том, как с помощью этих технологий можно динамически сформировать необходимую полнофункциональную рабочую среду в локальной операционной системе, на платформе виртуализации представления, такой как службы удаленных рабочих столов Remote Desktop Services (RDS), и на базе инфраструктуры виртуальных настольных систем Virtual Desktop Infrastructure (VDI). В данной статье речь пойдет о компонентах, необходимых для создания решения VDI на платформе Windows Server 2008 R2, использующего только продукты Microsoft.

Предварительные сведения

Прежде чем рассмотреть все шаги типичного процесса подключения к развертываемой настольной системе, будет полезно определить типы служб, необходимых для построения архитектуры VDI. На рисунке показаны основные шаги, необходимые для функционирования VDI, от начального подключения пользователя до формирования рабочей сессии VDI, за исключением таких технологий, как виртуализация приложений от Microsoft Application Virtualization (App-V), перемещаемые профили и т. д.

 

Рисунок. Компоненты VDI

Данный процесс состоит из семи шагов. Сначала пользователи должны найти удаленные настольные системы, к которым они могут подключиться и которые могут быть либо сессиями виртуализации представления (службы терминалов), либо опубликованными приложениями, либо сессиями VDI. И хотя для этой цели можно создать файл RDP и передать его тем или иным способом пользователям, существует более динамичный подход, с использованием службы веб-доступа к удаленным рабочим столам Remote Desktop Web Access, позволяющей отображать в браузере список доступных подключений, из которых пользователь может выбирать. Альтернативой просмотру на сайте списка динамически публикуемых подключений и приложений является использование имеющегося в Windows 7 компонента подключения к удаленным рабочим столам и приложениям RemoteApp для подписки на каналы RSS с серверов веб-доступа к удаленным рабочим столам, автоматически формирующим доступные подключения, которые могут быть настроены через сценарии, распространяемые с помощью групповых политик. Пользователи могут видеть эти публикуемые службы непосредственно в главном меню своих систем.

Второй шаг — создание списка опубликованных приложений и подключений, доступных пользователям. Для выполнения этой задачи сервер веб-доступа к удаленным рабочим столам подключается к посреднику подключений к удаленному рабочему столу Remote Desktop Connection Broker, который получает информацию о пулах VDI, личных рабочих столах и других опубликованных подключениях и приложениях с помощью собственных процедур взаимодействия с настроенными источниками удаленных приложений RemoteApp.

На третьем шаге посредник подключений к удаленным рабочим столам взаимодействует с Active Directory для определения прав доступа пользователя. Благодаря этому взаимодействию в свойствах пользователя отображаются также настройки личных рабочих столов, которые мы обсудим ниже.

Независимо от используемого метода (это может быть веб-доступ к удаленным рабочим столам, либо компонент подключения к удаленным рабочим столам и приложениям RemoteApp, либо подготовленный файл RDP), пользователи получают файл RDP, который можно задействовать для инициализации подключения (шаг 4). Если пользователь находится вне корпоративной сети, прямое подключение RDP блокируется большинством корпоративных брандмауэров. Таким образом, необходимо устанавливать защищенное подключение VPN. Однако существует альтернативное решение, которое не требует каких-либо действий пользователя или дополнительного клиентского программного обеспечения. В Windows Server 2008 имеется шлюз служб терминалов Terminal Services Gateway, который позволяет инкапсулировать трафик протокола RDP в пакеты протокола HTTPS (порт 443). Шлюз служб терминалов в системе Server 2008 R2 переименован в шлюз удаленных рабочих столов Remote Desktop Gateway. Для использования шлюза удаленных рабочих столов мы помещаем данный сервер в так называемую демилитаризованную зону (DMZ) или, для более высокой степени защиты, за каким-либо брандмауэром или прокси-сервером. Клиенты теперь подключаются к серверу RDP через шлюз удаленных рабочих столов путем добавления адреса шлюза в настройки файла RDP, передаваемого клиенту. Клиент инкапсулирует трафик протокола RDP в протокол HTTPS и посылает инкапсулированные данные на шлюз удаленных рабочих столов, на котором данные RDP извлекаются и пересылаются на соответствующий сервер терминалов. При возврате данных от сервера RDP назад к клиенту шлюз удаленных рабочих столов снова инкапсулирует данные RDP в пакеты HTTPS и передает их клиенту. Таким образом клиент, находящийся вне корпоративной сети, получает доступ ко всем ресурсам RDP без дополнительных действий и программных продуктов. Пользователи в корпоративной сети без обращения к шлюзу удаленных рабочих столов напрямую подключаются к серверу RDP. Проверка подлинности на шлюзе удаленных рабочих столов может производиться традиционным для Windows способом (имя/пароль) или с помощью смарт-карт, включая возможность подключения с текущими введенными учетными данными, без повторного ввода.

На шаге 5 пользователю необходимо знать точку начального подключения RDP, так как назначенная ему виртуальная машина клиенту VDI пока что неизвестна, если только у пользователя нет настроенного личного рабочего стола. Сервер сеансов удаленных рабочих столов Remote Desktop Session Host настраивается в режиме перенаправления подключений, то есть сервер принимает запросы пользователей на подключение RDP-, а затем перенаправляет клиента к сеансу DVI. Узел сеансов удаленных рабочих столов подключается к посреднику подключений к удаленному рабочему столу Remote Desktop Connection Broker для определения точки подключения клиента. В данной архитектуре сервер сеансов удаленных рабочих столов и посредник подключений к удаленному рабочему столу — это один и тот же сервер, однако вы не обязаны их размещать на одном узле (хотя обычно делается именно так из-за тесной взаимосвязи между этими ролями).

На шаге 6 посредник подключений к удаленному рабочему столу подключается к узлу виртуализации удаленных рабочих столов Remote Desktop Virtualization Host, настроенному на серверах Hyper-V, для проверки состояния виртуальной машины, ее запуска, если это необходимо, и сбора всей необходимой информации, такой как IP-адрес операционной системы клиентской виртуальной машины, который затем передается посреднику подключений к удаленному рабочему столу, узлу сеансов удаленных рабочих столов в режиме перенаправления и, наконец, самому клиенту.

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

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

На рисунке показан элемент, который мы не рассматривали, — это Microsoft System Center Virtual Machine Manager (VMM). И хотя VMM не является абсолютно необходимым для среды VDI, он будет очень полезен в управлении этой средой с помощью средств управления фермой Hyper-V, библиотек, поддержки PowerShell и других инструментов.

Для среды VDI можно использовать бесплатный продукт Microsoft Hyper-V Server и сэкономить на покупке Server 2008 R2. Полнофункциональный Server 2008 R2 предоставляет те же возможности Hyper-V, что и бесплатный Hyper-V Server, но при этом он предоставляет много дополнительных функций, помимо виртуализации. Кроме того, у Hyper-V из состава Server 2008 R2 имеются дополнительные лицензии на экземпляры виртуальных серверов, в которых в данном случае нет необходимости, поэтому вы можете сэкономить и использовать бесплатное решение.

Если мы посмотрим на шаги, осуществляемые в процессе подключения, то увидим, что мы используем пять служб роли RDS. Если вы решите задействовать RemoteFX с SP1 (о котором я расскажу в одной из следующих статей), получится шесть служб роли удаленных рабочих столов. Использование любой из служб роли удаленных рабочих столов требует клиентских лицензий для доступа к RDS, в дополнение к лицензиям на доступ к виртуальным настольным системам/подписке Software Assurance. Теперь рассмотрим подробнее все эти службы и особые моменты, относящиеся к VDI. Полную информацию о развертывании VDI можно найти в статье Microsoft TechNet «Getting Started: Remote Desktop Services» по адресу technet.microsoft.com/en-us/library/dd736539(WS.10).aspx (на русском языке — «Начало работы. Службы удаленных рабочих столов» на странице http://technet.microsoft.com/ru-ru/library/dd736539(WS.10).aspx).

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

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

В Windows 7 появился компонент подключения к удаленным рабочим столам и приложениям RemoteApp and Desktop Connection, который, не являясь напрямую частью веб-доступа к удаленным рабочим столам, позволяет передавать от сервера веб-доступа к удаленным рабочим столам содержимое, отображаемое на данном веб-сайте, напрямую в главное меню, избавляя от необходимости использования сайта. На экране 1 показаны локальное главное меню и представление с веб-сайта. Заметим, что мы здесь можем видеть не только пул VDI, но и приложения, опубликованные на серверах сеансов удаленных рабочих столов.

 

Экран 1. Представление опубликованных приложений и рабочих столов в веб-браузере и через подключения к удаленным рабочим столам и приложениям RemoteApp

Если вы хотите создать конфигурационный файл для автоматической настройки компонента подключения к удаленным рабочим столам и приложениям RemoteApp для клиентов Windows 7, используйте параметр Create Configuration File в диспетчере подключений к удаленному рабочему столу. При этом создается файл, который можно запускать на клиенте Windows 7 для автоматической настройки. Это очень удачное решение для крупных систем.

Посредник подключений к удаленному рабочему столу

Служба посредника подключений к удаленному рабочему столу Remote Desktop Connection Broker в системе Server 2008 R2 — один из основных компонентов, позволяющий построить решение VDI на продуктах Microsoft. Он предоставляет роли RDS возможность балансировать нагрузку и отслеживать подключения к системам, не являющимся серверами терминалов, в особенности — возможность управлять подключениями к клиентским операционным системам. И, кроме того, в системе Server 2008 R2 у службы посредника подключений к удаленному рабочему столу появилась возможность осуществлять балансировку удаленных приложений и поддерживать серверы с различными опубликованными приложениями, что позволяет получить суммарное представление различных приложений, собранных со всех серверов фермы, отображаемое у пользователя, и вам уже не потребуется иметь на всех серверах один и тот же набор приложений.

Служба Remote Desktop Connection Broker — это мозг среды VDI. Она обменивается информацией и управляет всеми остальными компонентами, наиболее тесно взаимодействуя с сервером сеансов удаленных рабочих столов в режиме перенаправления, поэтому посредник подключений к удаленному рабочему столу и сервер сеансов удаленных рабочих столов в режиме перенаправления часто устанавливаются в одной и той же системе. Однако, если у вас более 250 одновременных подключений, вам может потребоваться установка данных ролей на различных серверах.

Пулы VDI создаются с помощью службы Remote Desktop Connection Broker посредством инструмента Remote Desktop Connection Manager, который управляет опубликованным приложением, опубликованным сеансом и ресурсами виртуального рабочего стола. Диспетчер подключений к удаленным рабочим столам будет вашим любимым инструментом при управлении средой DVI. Этот инструмент не только создает пулы VDI, но и настраивает службы Remote Desktop Virtualization Host, Remote Desktop Web Access и Remote Desktop Session Host. Он также переводит сервер сеансов удаленных рабочих столов в режим перенаправления, избавляя вас от настройки вручную каждой службы для роли VDI.

Когда создается пул VDI, необходимо указать серверы Hyper-V, на которых размещаются виртуальные машины, а затем выбрать клиентские виртуальные машины, которые будут входить в состав пула. Мастер создания пула VDI выполнит остальные настройки.

Служба Remote Desktop Connection Broker обрабатывает все входящие запросы VDI и вначале проверяет, не остался ли у пользователя отключенный сеанс в пуле VDI. Если да, то пользователь подключается к этому сеансу, в противном случае ему назначается не используемый в настоящий момент виртуальный рабочий стол.

Узел сеансов удаленных рабочих столов в режиме перенаправления

Идея использования сервера сеансов удаленных рабочих столов в режиме перенаправления не нова. Такой подход применялся в предыдущей версии Windows Server при создании большой фермы терминальных серверов. Чтобы избавить пользователей от необходимости подключения к разным серверам терминалов, начальная точка входа всегда является выделенным сервером сеансов, который только взаимодействует с посредником подключений и перенаправляет подключения RDP на нужный сервер. Такой же процесс происходит и в среде VDI, нам по-прежнему нужна начальная точка подключения RDP для клиентов RDP, каковой является сервер сеансов удаленных рабочих столов в режиме перенаправления. Данный узел перенаправляет клиентов RDP к соответствующей клиентской виртуальной машине, предоставляющей операционную систему.

Сервер сеансов удаленных рабочих столов — это то, что мы привыкли называть сервером терминалов, то есть сервер, на котором размещены пользовательские сеансы. Но, поскольку в Server 2008 R2 имеется много различных компонентов RDS, надо точнее определять сервер, предоставляющий пользовательские сеансы, отсюда использование термина «сервер сеансов удаленных рабочих столов».

Можно вручную настроить сервер сеансов удаленных рабочих столов для работы в режиме перенаправления. Однако, если мы используем мастер создания пула VDI в диспетчере подключений к удаленным рабочим столам, настройка сервера сеансов удаленных рабочих столов выполняется автоматически, как показано на экране 2. Заметим, что, как только сервер сеансов удаленных рабочих столов переводится в режим перенаправления, он уже не может более запускать обычные сеансы, а только будет выполнять перенаправление подключений.

 

Экран 2. Автоматическая настройка сервера сеансов удаленных рабочих столов с помощью мастера пула VDI

Узел виртуализации удаленных рабочих столов

Служба Remote Desktop Virtualiza­tion Host устанавливается на каждом узле Hyper-V, который включается в пул VDI. Эта служба позволяет службе посредника подключений к удаленному рабочему столу обмениваться информацией с узлами Hyper-V, запускать и останавливать виртуальные машины и собирать внутреннюю информацию для обеспечения клиентских подключений.

Шлюз удаленных рабочих столов

Служба шлюза удаленных рабочих столов инкапсулирует трафик RDP в пакеты HTTPS, обеспечивая защищенные подключения RDP через корпоративные брандмауэры без необходимости открывать на брандмауэрах дополнительные порты и без дополнительных VPN-решений. Шлюз удаленных рабочих столов можно использовать для настройки параметров: кто может подключаться через данный шлюз, куда подключаться, а также для настройки поддерживаемых параметров протокола RDP, таких как перенаправление устройств.

Высокодоступные решения VDI

Построение решения VDI требует централизации среды рабочих столов в едином центре обработки данных. Если происходит сбой на сервере, то пользователь может продолжать работу в локальной операционной системе. Но если мы разворачиваем VDI, то вся среда рабочих столов теперь находится в центре обработки данных, так что если какая-то часть VDI выходит из строя, пользователь полностью лишается настольной среды и не может работать. Обеспечение отказоустойчивости всех элементов VDI становится критически важной задачей. К счастью, у нас есть решения для каждой части архитектуры VDI.

Считая службу Remote Desktop Connection Broker мозгом всей среды VDI, необходимо использовать отказоустойчивый кластер, так как данная служба поддерживает кластеризацию, что обеспечивает доступность этой службы при выходе из строя любого узла. Поскольку обычно служба сервера сеансов удаленных рабочих столов в режиме перенаправления устанавливается совместно с посредником подключений к удаленному рабочему столу, необходимо установить службу сервера сеансов удаленных рабочих столов и настроить на работу в режиме перенаправления на всех узлах кластера. На сервере DNS создается ресурсная запись для узлов сеансов, которая ссылается на IP-адреса всех узлов сеансов. При подключении эти IP-адреса пересылаются клиентам в различном порядке. Если один из серверов недоступен, клиенты будут пытаться подключиться, используя следующий IP-адрес.

Служба балансировки сетевой нагрузки Network Load Balancing (NLB) применяется для распределения запросов между несколькими экземплярами шлюза удаленных рабочих столов. Мы можем задействовать как службу NLB, встроенную в систему Windows, так и аппаратный балансировщик нагрузки. Те же технологии NLB можно использовать для обеспечения высокой доступности службы веб-доступа к удаленным рабочим столам.

Узлы Hyper-V могут быть размещены в отказоустойчивом кластере таким образом, что при сбое узла Hyper-V клиентская виртуальная машина перемещается на другие узлы. Если потребуется, технология динамической миграции Live Migration может быть использована для перемещения работающих клиентских виртуальных машин между узлами при техническом обслуживании серверов. Однако, поскольку пользовательские настройки и данные отделены от экземпляра операционной системы, если один экземпляр выходит из строя, пользователям нужно всего лишь переключиться на альтернативный экземпляр операционной системы. Настройки и данные пользователя снова будут доступны.

Личные рабочие столы или рабочие столы в составе пула

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

Рабочие столы в составе пула должны быть рабочими столами по умолчанию для всех пользователей. Однако для некоторых пользователей может возникнуть необходимость иметь один и тот же экземпляр операционной системы при каждом подключении. Возможно, они каким-то особым образом настраивают свою систему или им нужно установить приложение, которое не может быть виртуализовано. В любом случае у нас есть возможность статического назначения отдельной виртуальной машины какому-либо пользователю, чтобы этот пользователь всегда получал одну и ту же клиентскую операционную систему. Это называется личным рабочим столом и настраивается в консоли Active Directory Users and Computers, как показано на экране 3. Пользователю можно назначить только один личный рабочий стол, виртуальная машина в качестве личного рабочего стола может быть назначена только одному пользователю, личный рабочий стол не должен входить в состав пула VDI, а должен быть обычной виртуальной машиной в среде виртуализации. Необходимо, чтобы имя личного рабочего стола совпадало с именем виртуальной машины, которое должно быть полным именем FQDN, например client.savilltech.net, то есть виртуальной машине необходимо назначать имя FQDN экземпляра клиентской операционной системы.

 

Экран 3. Назначение пользователю личного рабочего стола

Настройка клиентской виртуальной машины

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

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

  • разрешить удаленный рабочий стол Remote Desktop;
  • добавить соответствующих пользователей в группу Remote Desktop Users;
  • разрешить RPC;
  • настроить исключения в брандмауэре для удаленного управления службами;
  • настроить разрешения в протоколе RDP для сервера виртуализации удаленных рабочих столов.

Все необходимые действия для каждой виртуальной машины могут быть выполнены вручную. Подробнее об этом рассказано в статье Microsoft TechNet Remote Desktop Services in Windows Server 2008 R2, Appendix A, «Configuring the Virtual Machine Manually», размещенной по адресу technet.microsoft.com/en-us/library/ff603843(WS.10).aspx); можно использовать и групповые политики для автоматизации применения этих настроек, а также задействовать разработанный Microsoft сценарий для упрощения всего процесса (gallery.technet.microsoft.com/ScriptCenter/en-us/bd2e02d0-efe7-4f89-84e5-7ad70f9a7bf0).

Есть еще один интересный момент, относящийся к среде операционных систем клиентских виртуальных машин. У нас имеется несколько вариантов клиентской операционной системы, разделяемых между многими пользователями. Необходимо ограничить доступ к этим разделяемым клиентским средам, чтобы пользователи не могли изменять настройки операционной системы, а также устанавливать или удалять программы. Однако, в зависимости от конкретной среды, нам может потребоваться возвращать операционную систему в определенное состояние при каждом завершении сеанса работы с системой. Для этого можно использовать снимки Hyper-V и RDS.

Для каждой виртуальной машины можно сделать снимок, в имени которого имеется текст RDV_Rollback. Данный снимок должен быть сделан, когда виртуальная машина находится в «чистом» состоянии, так как нам нужно возвращаться к этому состоянию при каждом завершении сеанса работы с системой. Снимок можно сделать и при работающей, и при неработающей виртуальной машине, но необходимо, чтобы в процессе создания снимка в системе не было сеанса пользователя. Когда пользователь завершает сеанс работы с виртуальной машиной в среде VDI, к которой он подключился через службу посредника подключений к удаленному рабочему столу, состояние данной виртуальной машины возвращается к снимку RDV_Rollback. Заметим, что возможность создания снимка RDV_Rollback имеется только у виртуальных машин в пуле, но не у личных виртуальных рабочих столов.

Если вы выбираете применение RDV_Rollback для того, чтобы каждый пользователь при регистрации получал «чистую» среду, в среде VDI приходится применять некий прием, относящийся к членству в домене AD. Обычно пароль учетной записи компьютера автоматически изменяется каждые 30 дней. Если мы периодически будем возвращать систему к контрольной точке — например, после каждого завершения сеанса в системе, — старый пароль учетной записи компьютера, который присутствует в снимке RDV_Rollback, перестанет действовать, после того как компьютер поменяет пароль. Это может произойти, когда пользователь зарегистрируется в системе на 30-й день действия пароля, и может привести к сбоям в проверке подлинности учетной записи компьютера и необходимости сброса его пароля. Имеется несколько способов решения этой проблемы. Один из них — запрет смены пароля учетной записи компьютера, который можно реализовать с помощью групповых политик. Однако данный подход может иметь нежелательные последствия в отношении безопасности и поэтому не рекомендован к использованию.

Другой способ заключается в периодическом удалении всех клиентских виртуальных машин, их пересоздании и генерации новых снимков RDV_Rollback (с интервалом, меньшим, чем интервал смены пароля компьютерных учетных записей). Такой подход может показаться неразумным, но вы можете использовать VMM и сценарии от Microsoft для создания виртуальных машин в среде VDI (сценарий доступен по адресу gallery.technet.microsoft.com/scriptcenter/en-us/904bd2c8-099d-4f27-83da-95f5536233bc). Данные сценарии позволяют автоматизировать массовое создание виртуальных машин для среды VDI, что значительно облегчает повторное создание виртуальных машин в VDI по мере необходимости, а также периодическое пересоздание виртуальных машин. Использование этого подхода решает и еще одну проблему. Если мы используем виртуальные машины в течение длительного времени, нам необходимо устанавливать на них обновления и осуществлять регулярное обслуживание настольных систем. Если мы пересоздаем виртуальные машины каждые 4 недели, нам необходимо устанавливать обновления только на единственный мастер-образ, который используется при создании всех виртуальных машин в пуле VDI.

Следующие шаги

VDI на платформе RDS — очень достойное решение, которое реально может использоваться в производственной среде. Для некоторых крупных организаций статичная природа клиентских виртуальных машин может стать препятствием, и на решение этого вопроса сейчас направлены усилия в рамках партнерства Microsoft и Citrix. Об этом я расскажу в своей следующей статье. А пока рекомендую посетить веб-страницу «Getting Started: Remote Desktop Services» на сайте Microsoft TechNet по адресу technet.microsoft.com/en-us/library/dd736539(WS.10).aspx (русский вариант — «Начало работы. Службы удаленных рабочих столов» на странице http://technet.microsoft.com/ru-ru/library/dd736539(WS.10).aspx), содержащую пошаговые руководства по развертыванию среды VDI. Вполне реально в течение дня развернуть среду VDI в тестовой лаборатории и приступить к экспериментам.

Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP