Построение VDI инфрастуктуры и публикация персональных рабочих столов VDI на UAG 2010 SP1

ПРИМЕЧАНИЕ ОТ АВТОРА: 

Всем привет.

Думаю, что реализации технологии Microsoft VDI являются достаточно редким являением на просторах России, особенно в купе с использованием Unified Access Gateway 2010 для публикации VDI персональных рабочих столов, поэтому я решил осветить в этом посте данную тему достаточно подробно.

Многие вопросы по архитектуре, эксплуатации решений по Microsoft VDI и Microsoft Forefront Unified Access Gateway 2010 остаются за рамками данной статьи, т.к. она является отражением моего субъективного практического опыта работы с этими технологиями и основанными на них решениями на текущий момент времени.

Людям же интересующимся данным вопросом грубоко и желающим детально ознакомиться с замечательным продуктом Microsoft Forefront Unified Access Gateway 2010, я рекомендую прочитать книгу Microsoft Forefront UAG 2010 Administrator's Handbook авторы Erez Ben-Ari, Ran Dolev. А так же воспользоваться официальной документацией, размещенной на technet.microsoft.com в разделе Библиотека.


Информация по развёртыванию Microsoft VDI:

http://blogs.msdn.com/b/rds/archive/2009/08/19/microsoft-vdi-overview.aspx
http://www.techdays.ru/videos/3561.html

http://blogs.technet.com/b/abeshkov/archive/2010/08/05/3348565.aspx

http://go.microsoft.com/fwlink/?LinkId=193399

http://go.microsoft.com/fwlink/?LinkId=192601

http://go.microsoft.com/fwlink/?LinkId=186939

http://go.microsoft.com/fwlink/?LinkId=79603

http://www.microsoftvirtualacademy.com/tracks/770

Итак, начнём

Основные особенности реализации VDI на платформе Microsoft следующие:

• Наличие Hyper-V сервера виртуализации;
• Клиентские рабочие станции должны работать с протоколом RDP 6.1 и выше (На Windows XP/Server 2003/Vista придётся установить RDP клиент  требуемой  версии дополнительно)
• Наличие грамотно построенной инфрастуктуры PKI;
• Наличие Active Directory Domain Services 2.0;

Планируемая инфраструктура проекта будет включать в себя следующие компоненты:

Для консолидации ресурсов в тестовой зоне мы используем один сервер виртуализации Windows Server 2008 R2 SP1.

• Все сервера будут являться членами домена msft.local;
• Внешние пользователи должны получать доступ к порталу UAG по адресу uag.msft.ru;
• Все сервера внутри инфраструктуры являются членами одной сети класса "C" 10.235.1.0/24;
• Клиентские ПК инфраструктуры VDI получают адреса с DHCP сервера, установленного на DC01;
• Так как мы реализуем всё на тестовом стенде для эмуляции внешней сети мы будем использовать диапазон сети класса "C" 192.168.1.0/24;
• В данном сценарии не планируется использование RD Gateway SSL Bridging HTTPS to HTTPS, реализуем сценарий HTTPS to HTTP;

Распределение компонентов (ролей) VDI инфраструктуры:

• VMSERVER2 - физический сервер с ролью RD Virtualization Host;
• RDS -  виртуальный сервер с совмещенными ролями RD Session Host, RD Connection Broker, RD Web Access Portal;
• RDL - сервер лицензирования служб RDS;
• GW01 - сервер  UAG 2010 SP1, RD Gateway;
• DC01 - доменный контроллер на базе Windows Server 2008 R2 SP1 Enterprise с ролями AD DS, Enterprise CA, DHCP;
• WRKS02, WRKS03 - пул VDI рабочих станций;
• WRKS01, WRKS04 - персональные рабочие станция VDI;

Мы создали все необходимые виртуальные машины на нашем сервере (выделенные желтым).

Для начала необходимо подготовить инфраструктуру к внедрению VDI.

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

 Для успешного подключения к UAG  из внешнего мира нам необходим сертификат веб-сервера, которому будет доверять клиент, для установления SSL сессии.  Для этого можно использовать сертификат, выданый публичным CA, или выпустить свой (в этом сценарии нам потребуется обеспечить публикацию CRL на каком либо ресурсе, размещенном в интернет), чтобы подключающиеся клиенты могли проверить подлинность сертификата сервера UAG.

Крайне не рекомендую использовать корпоративный СА, используемый внутри организации, т.к. компрометация ключей, может вызвать необходимость перевыпуска всей цепочки сертификатов для внутренней инфрастуктуры.  Для этой цели лучше поднять stand-alone CA, который будет поддерживать сертификаты для ресурсов внешней зоны *.msft.ru и обеспечить публикацию CRL. Более того в данном сценарии появляется возможность использовать SAN (Subject Alternative Name) аттрибут сертификатов для имен внешней зоны *.msft.ru (крайне полезная вещь при публикации различных веб-ресурсов компании, как то OWA, портал UAG, Lync и т. д.).

Проверить, включен ли функционал поддержки SAN на Вашем CA Web enrollment  можно командой:

certutil -getreg policy\EditFlags

 Вывод данных будет такой:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ca\Po

licyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

  EditFlags REG_DWORD = 15014e (1376590)

    EDITF_REQUESTEXTENSIONLIST -- 2

    EDITF_DISABLEEXTENSIONLIST -- 4

    EDITF_ADDOLDKEYUSAGE -- 8

    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)

    EDITF_ENABLEAKIKEYID -- 100 (256)

    EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)

    EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)

CertUtil: -getreg command completed successfully.

  

Если строка EDITF_ATTRIBUTESUBJECTALTNAME2 отсутствует, то можно активировать функицонал поддержки SAN через CA Web enrollment можно с помощью команды:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

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

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

http://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx

Конфигурирование инфраструктуры VDI

Перед началом настройки инфраструктуры VDI обеспечьте сертификатами, выданными корпоративным СА, все её компоненты.


В чём разница между пулом виртуальных рабочих станций и персональной виртуальной рабочей станцией?

Персональный виртуальный рабочий стол назначается пользователю явно. Только этот пользователь имеет право на подлючение к этому виртуальному рабочему столу. В AD DS, с помощью дополнительного аттрибута учётной записи пользователя, за конкретным пользователем закрепляется определённая виртуальная персональная рабочая станция.


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


Подготовка виртуальных рабочих станций к использованию в VDI инфрастуктуре

Вводим в домен msft.local виртуальные рабочие станции.

Затем необходимо подготовить вируальные машины рабочих станций для использования в инфраструктуре VDI, можно сделать это и в ручную , но я рекомендую использовать готовый скрипт http://gallery.technet.microsoft.com/scriptcenter/bd2e02d0-efe7-4f89-84e5-7ad70f9a7bf0.

В параметрах скрипта нужно указать сервер виртуализации, в нашем случае это msft\vmserver2 и группу пользователей RDS,  в нашем случае это msft\VDIUsers - она будет добавлена в группу пользователи удалённого рабочего стола.

При успешном выполнении на англоязычной версии Windows 7 в логе скрипта будет следующий вывод:

Preparing virtual machine for the RD Virtualization Host server:

  RDV Host  : msft\vmserver2

  RD Users  : msft\VDIusers

  Enabling Remote Desktop...

    Done

  Enabling RPC...

    Done

  Adding users to the Remote Desktop Users group...

    Done

  Granting RD Virtualization hosts RDP-TCP listener permissions...

  msft\vmserver2$ is being added to the RDP-TCP permissions list

  Granting permissions : msft\vmserver2$

    Done

  Enabling firewall for 'remote desktop'...

    Done

  Enabling firewall for 'remote service management'...

  Done

Restarting the Remote Desktop Services service...

  Stopping TermService...

  Starting TermService...

Virtual machine was prepared for use with the RD Virtualization Host server

 На русскоязычной версии  Windows 7 возникает ошибка:

Preparing virtual machine for the RD Virtualization Host server:

  RDV Host  : msft\vmserver2

  RD Users  : msft\VDIusers

  Enabling Remote Desktop...

    Done

  Enabling RPC...

    Done

  Adding users to the Remote Desktop Users group...

    Done

  Granting RD Virtualization hosts RDP-TCP listener permissions...

    Done

  Enabling firewall for 'remote desktop'...

Firewall could not be enabled for 'remote desktop'  Enabling firewall for 'remote service management'...

Firewall could not be enabled for 'remote service management'Restarting the Remote Desktop Services service...

  Stopping TermService...

  Starting TermService...

Необходимо будет вручную удостовериться, что  компоненты удаленного управления и RDP имеют разрешения брендмауэра для корректной работы. Пока что  не было времени  разобраться до конца в чем проблемма данного скрипта на русскоязычной версии Windows 7.

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

ВНИМАНИЕ! RDV_Rollback является зарезервированным именем для снимка отката в первоначальное состояние. Если сделанные снимки назвать по другому откат в первоначальное состояние происходить не будет.

  

Настройка ролей на сервере RDS

ПРИМЕЧАНИЕ! В данной статье мы считаем, что роли уже установлены и их надо только настроить.

Настройка RD Session Host:

1. В Server Manager выбираем узел Роли, затем Remote Desktop Services, RD Session Host Configuration: RDS.

2. В разделе Edit Settings выбираем General и User Logon Mode, устанавливаем allow reconnections, but prevent new logons.

3. На странице Licensing указываем RDL.MSFT.LOCAL и тип лицензирования Per Device

4. На странице RD Connection Broker выбираем Change Settings.

5. Устанавливаем режим редиректа Virtual Machine Redirection.

6. В поле RD Connection Broker Server Name указываем RDS.MSFT.LOCAL

7. Нажимаем ОК, ОК.

8. Убедимся, что свойства на странице General для RDP-Tcp Connection соответствуют скриншоту, приведённому ниже.

Настройка RD Virtualization Host Servers:

1. В Server Manager выбираем узел Роли, затем Remote Desktop Services, Remote Desktop Connection Manager

2. В центральной части выбираем в разделе  Virtual Desktops Resources and Configuration выбираем RD Virtualization Host Servers.

3. Нажимаем Add и вводим FQDN имя сервера виртуализации, в нашем случае VMSERVER2.MSFT.LOCAL.

4. Нажимаем Add.

Настроим Remote Desktop Session Host server for Redirection:

1. Нажимаем Configure.

2. На странице Redirection Settings в поле Server Name вводим имя сервера RDS.MSFT.LOCAL.

3. На странице RD Gateway Settings указываем параметры. Если не хотим, чтобы для локальных адресов клиенты использовали RD GW - установите соответствующую галочку Bypass RD GWserver for local addresses

4. На странице Digital Signature установите галочку в поле Sign with a digital certificate.

5. Нажмите Select и выберите сертификат сервера, ранее выпущенные для сервера RDS.MSFT.LOCAL корпоративным СА.

6. Нажмите OK.

7. На странице Licensing Settings введите имя сервера лицензий RDL.MSFT.LOCAL и нажмите Add, затем Apply и закройте окно.

Настройка RD Web Access Servers:

1.  Нажимаем Add и указываем FQDN имя сервера RD Web, в нашем случае он расположен на сервере RDS и нажимаем Add.

Сервер отобразиться в верхнем поле (см. скриншот)

ПРИМЕЧАНИЕ! Перед выполнением следующего пункта добавьте групповой политикой адроес портала RDWeb https://rds.msft.local/rdweb  в Надёжные узлы или Местную интрасеть

2. Зайдём по ссылке https://rds.msft.local/rdweb и выполним вход от имени администратора домена MSFT

3. Сконфигурируем портал RDWeb в соответствии со скриншотом

ПРИЧЕЧАНИЕ!  Очень часто у коллег встречаются упоминания о нежелательности размещения ролей RDCB, RDSH и RDWeb на одном сервере. Со своей стороны сделал 2 конфигурации  в продуктиве и на стенде - проблем не заметил. Для небольшого количества пользователей вполне приемлемое решение.

Настройка Connection ID:

1. Нажимаем Change в пункте Display Name

2. Указываем RDS.MSFT.LOCAL в поле Connection ID, всё остальное оставляем по-умолчанию.

Настроим Remote Desktop Connection Broker:

1. В центральной части выбираем в разделе Overview кнопку Configure напротив надписи RD Connection Broker is configured for personal desktops.

2. Указываем имя RDVH сервера в нашем случае VMSERVER2 и нажимаем Add и Next.

3. Указываем имя RDS сервера RDS.MSFT.LOCAL и Next.

4. Указываем имя RDWeb сервера и Next, Apply, Close.

 Настройка пула VDI:

1. В Server Manager выбираем узел Роли, затем Remote Desktop Services, Remote Desktop Connection Manager, RD Virtualization Host Servers выбираем Create Virtual Desktop

2. В созданый пул добавим виртуальные машины WRKS02, WRKS03.Pool.

3. Задаём Имя пула: VDITestPool и Pool ID: VDITestPool и нажимаем Next.

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

1. В Server Manager выбираем узел Роли, затем Remote Desktop Services, Remote Desktop Connection Manager, RD Virtualization Host Servers, выбираем Personal Virtual Desktop и нажимаем Assign Personal Desktop to User. 

2. Указываем учётную запись доменного пользователя и выбираем из выпадающего списка виртуальную машину, которую хотим назначить

3. Нажимаем Next, Assign.

Тестируем для внутренних пользователей

ПРИМЕЧАНИЕ! RD Gateway у нас ещё не сконфигурирован, не забудьте поставить галочку Bypass RD Gateway server for local addresses


После того, как вся необходимая подготовительная работа проделана, мы можем протестировать работу VDI внутри инфраструктуры:

1. Зайдем на ресус https://rds.msft.local/rdweb

2. Выполним вход от имени пользователя домена (пользователь должен являться членом группы VDIUsers

3.  Мы видем доступные для нашего пользователя два вида виртуальных рабочих столов: персональный и пулированный

4. Запускаем любой из доступных нам рабочих столов.





UAG 2010 SP 1 для публикации персональных рабочих столов VDI

Общие положения

Установка UAG достаточно проста в конфигурации с одним сервером, поэтому мы её пропускаем и после объяснения принципа работы UAG в схеме с VDI мы перейдем сразу к конфигурированию.

Отмечу несколько моментов:

• При установке UAG так же устанавливается TMG 2010, выполняющий роль Front-end файрвола для UAG и Microsoft SQL Server 2008 в качестве СУБД базы данных. А так же роли Network Policies and Access Services: NPS, Health Registration Authority и службы Routing & Remote Access. Не надо специально перед установкой UAG разворачивать выше перечисленные компоненты иначе произойдёт сбой установки.
• Для поддержки функционала публикации VDI рабочих столов и RDP соединений UAG так же уставнавливает роль RD Gateway на сервере, где он разворачивается, интегрируясь со шлюзом RD Gateway.
• UAG автоматически создаёт набор ACCESS и PUBLISH правил при публикации того или иного приложения или транка. Эти правила крайне не рекомендуется править руками через консоль TMG во избежания нарушения целостности работы системы, все необходимые изменения вносяться при работе через консоль UAG. Правила UAG снабжены двумя якорями PublishingRule::Anchor::Begin и PublishingRule::Anchor::End, обозначающих начало и конец правил UAG

Инфраструктура персональных рабочих столов VDI поддерживается продуктом UAG 2010 с версии Forefront Unified Access Gateway (UAG) Update 2

http://www.winfrasoft.com/kb-38.htm

http://www.microsoft.com/download/en/details.aspx?id=12120

но лучше использовать последнюю UAG 2010 SP1 Rollup 1 (на момент написания статьи)

Как работает UAG 2010 для публикации VDI?

1. Пользователь через интернет, по безопасному SSL соединению, обращается к порталу UAG.MSFT.RU, ему  предлагается установить компонент ActiveX с помощью которого UAG определяет соответствие пользовательской рабочей станции политикам доступа из вне. Если всё отлично, то пользователю предложат ввести логин и пароль. В противном случае будет выдано сообщение о том, что доступ запрещён, т.к. рабочая станция не соответствует политики доступа.

2. После прохождения авторизации пользователь попадает на портал UAG, где видит опубликованные для него приложения, ключая Personal VDI.

Пользователь запускает опубликованный персональный рабочий стол, нажав на иконку.

3. В этот момент UAG используя встроенный RD Gateway устанавливает внутреннюю сессию по RDP протоколу и 3389 порту до сервера RDS. При этом RDP сессия терминируется на  внутреннем сетевом  интерфейсе GW01 сервера. Передача же информации наружу до конечного пользователя происходит по SSL соединению, которое инкапсулирует RDP трафик с внешнего интерфейса GW01, т.е. проброс 443 порта внутрь инфраструктуры не происходит.

4. RDS с ролям и RDCB и RDSH, проверив  наличие лицензий на терминальные подключения, опознав, какая из виртуальных машин назначена пользователю, отдаёт команду для RDVH или в нашем случае VMSERVER2 на пробуждение виртуальной машины из сна.

5. Сервер виртуализации запускает виртуальную машину, принадлежащую пользователю.

6. Соединение от конечной виртуальной машины по RDP устанавливается до UAG с ролью RD Gateway

7. UAG осуществляет передачу RDP сессии инкапсулируя RDP трафик, в установленом с пользователем SSL тунеле.




Конфигурация UAG 2010 SP1

Создание транка HTTPS

1. Заходим на сервер GW01 и запускаем консоль UAG

2. Выбираем правой кнопкой мыши HTTPS Connections и выбираем New Trunk

3. Нажимаем Next и выбираем Portal Trunk (можно не выбирать Publish Exchange Application via the portal, т.к. мы не планируем разворачивать OWA и т .д) и нажимаем Next

4. Указываем имя транка: VDITrunk, внешнее имя доступа: UAG.MSFT.RU, внешний IP адрес и нажимаем Next

5. Указываем сервер служб каталогов и нажимаем Next

6. Указываем SSL сертификат, которые мы выпустили для имени UAG.MSFT.RU и нажимаем Next

7. Выбираем  будут ли использоваться политики Forefront UAG (в нашем случае) или NAP

8. Выбираем политики доступа сессий и  нажимаем Next, Finish

Далее применим нашу конфигурацию нажав последовательно Save и затем Activate Configuration.

После нажатия кнопки Activate Configuration перед применением конфигурации мастер предложит сделать РК текущей конфигурации - оставьте галочку в поле Back up configuration и нажмите Activate.

Вот так вот выглядит созданый нами  HTTPS транк, созданый нами для публикации VDI personal desktop. Обратите внимание, что в данном варианте скриншота у меня уже произведена публикации VDI personal desktop, и находится она ниже приложения Portal. Порядок приложений в поле Applications крайне важен для правильной работы публикации.

Конфигурирование роли Remote Desktop Gateway


ПРИМЕЧАНИЕ! Перед выполнением ниже описаных процедур выпустите для сервера GW01 SSL Certificate в УЦ предприятия


1. Заходим на сервер GW01 и запускаем консоль Server Manager
2. Раскрываем узел Roles, затем Remote Desktop Services, RD Gateway Manager
3. Правой кнопкой мыши нажимаем на GW01 и выбираем Properties
4. В закладке Allow the maximim supported simulteneos connections
5. В закладке SSL Certificate, который мы выпустили на УЦ предприятия для сервера GW01.MSFT.LOCAL и нажимаем Import
6. В закладке RD CAP Store оставляем всё как есть
7. В закладке указываем имя сервера  GW01.MSFT.LOCAL, нажимаем Add и Refresh Status
8. Дальше нас интересует закладка SSL Bridging необходимо выбрать режим HTTPS to HTTP
9. Нажимаем Apply и OK


Создание публикации VDI Presonal Desktop

Для упрощения процедуры публикации в UAG существует большое количество предустановленых шаблонов публикации приложений от служб терминалов до Sharepoint,

но мы  с Вами коснёмся шаблонов раздела Terminal Services (TS)/Remote Desktop Services (RDS), а конкретно шаблона Remote Desktop (Predefined), т.к. именно он отвечает за публикацию.

1. Запускаем консоль UAG

2. Выбираем транк HTTPS VDITrunk

3. В разделе Applications  нажимаем кнопку Add и нажимаем Next

4. Выбираем приложение Terminal Services (TS)/Remote Desktop Services (RDS) и шаблон Remote Desktop (Predefined) и нажимаем Next

5. Называем приложение VDIPersonal и нажимаем Next

6. Оставляем настройки по-умолчанию и нажимаем Next

7. Вводим FQDN RDS.MSFT.LOCAL, ниже в таблице указываем IP адрес RDS и сетевые диапазоны, где находяться все компоненты системы, в нашем случае 10.235.1.0/24

8. Нажимаем Next три раза

9. Указываем группу VDIUsers и нажимаем Next, Finish

10. Сохраните конфигурацию

11. Примените конфигурацию.

После завершения процедуры публикации, откройте свойства приложения и в закладке Server Settings мы должны увидеть следующую картину.

Устранение проблем

Попытаюсь тут описать те проблемы с которыми столкнулся сам в процессе длительного тестирования на двух стендах и в пилоте (более 1-го месяца работы), и решение которых нашел. 

Неудаётся зайти на VDI Pooled Desktop - Waking the virtual machine  завершается с ошибкой 

Для данной проблемы характерны следующие симптомы:

• При попытке подключиться к пулированному виртуальному рабочему столу очень долго висит сообщение Waking the virtual machine и затем завершается с ошибкой

или

• Ошибки в журналах на виртуальной рабочей станции

•  Ошибки в журналах RDS сервера

• Ошибки на сервере виртуализации

•  Персональные рабочие столы запускаются без проблем.
• При попытке зайти на рабочую станцию из под доменной учётной записи получаем

Причина:

Раз в 30-ть дней по - умолчанию AD DS устанавливает новые пароли для объектов компьютеры присутствующих в каталоге. Поскольку пулированная виртуальная машина восстанавливаетя со снимка мы получаем разные пароли учётной записи компьютера в AD DS и на самой машине. Отсюда возникает проблема.

Решение:

На мой взгляд существуют три пути (если есть альтернатива - предлагайте):

• Отключить смену пароля учётной записи компьютера для виртуальной машины рабочего стола (менее безопасный и менее трудоёмкий) 
http://technet.microsoft.com/en-us/library/cc785826(WS.10).aspx http://support.microsoft.com/kb/154501  http://support.microsoft.com/kb/976494
• Пересоздавать скриптом раз в 30 дней пул виртуальных машин (более трудоёмкий и более безопасный)
• Перезавести рабочую станцию в домен.

Ошибка при попытке запуска персонального рабочего стола через портал UAG 2010

Для данной проблемы характерны следующие симптомы:

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

•  Журналы RD Gateway, RDCB, RDSH, RDVH и самой рабочей станции не содержат ошибок. Видно в журналах RDCB и RDSH, что сессия успешно перенаправлена к виртуальной машине.
• Внутри локальной сети всё отлично работает.
• Сканирование сетевым снифером (к примеру Wireshark) показывает, что все компоненты взаимодейстуют и сессия рвётся сразу после того, как виртуальная машины вернулась из состояния Saved и должна была произойти аутентификация
• При захвате трафика на TMG видно что сессия оборвана после того, как получен RST пакет от RDS.
• При разборе событий с помощью UAG Web Monitor  мы видим следующее

Warning

04/30/2010   10:26:18

127

Remote Desktop Gateway Non-Authorized  Resource

Security

(S)

REMOTE

An authorized Remote Desktop Gateway resource for the user <unknown> was detected on trunk <unknown> (secure=1) for application ID <unknown>. The session ID is <unknown>. The error code is internal error.

Причина:

UAG действительно не может установить сессию до конечной виртуальной машины (и наоборот), если в свойствах опубликованного приложения Remote Desktop (Predefined) указан только FQDN или IP адрес RD Session Host с ролями RDSH и RDCB. Особенно, это касается сетевых инфраструктур, где UAG находится в одной подсети, сервера во второй, а рабочие станции получают адреса в третьей.

Решение:

Вводим FQDN RDS, ниже в таблице указываем IP адрес RDS и сетевые диапазоны, где находяться все компоненты системы (сервер UAG, сервера VDI и рабочие станции).