четверг, 2 февраля 2012 г.

Построение 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:

Итак, начнём
Основные особенности реализации 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 ServicesNPS, 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
                        но лучше использовать последнюю 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 и на самой машине. Отсюда возникает проблема.

                        Решение:

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



                        Ошибка при попытке запуска персонального рабочего стола через портал 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 и рабочие станции).


                        4 комментария:

                        1. Сколько сейчас не бьюсь над VDI в RD Connection Manager -> RD Virtualization Host Server у хоста виртуализации общее количество виртуальных виртуальных машин - 0. Заеб....ся уже с Микрософтовскими полутехнологиями воевать - их наверное специально придумывают, чтобы издеваться над людьми.

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

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

                          Как это сделать? Какие сертификаты выпускать, как, куда их класть, откуда забирать?

                          ОтветитьУдалить
                          Ответы
                          1. Добрый вечер, Илья.

                            Первое, в рамках данной статьи я не пытаюсь обучить базовым навыкам работы с PKI, подразумевается, что они у Вас уже есть.
                            Тем не менее вы можете внимательно изучить материалы на эту тему по ссылке http://www.windowsecurity.com/articles/microsoft-pki-quick-guide-part1.html. Думаю достаточно неплохо изложено. Аналогичные материалы есть на TechNet в свободном доступе и на русском языке.
                            Для справки: сертификат сервера со свойствами:

                            Проверка подлинности сервера;
                            Проверка подлинности клиента;

                            Выдаётся ЦС предприятия, которому доверяют все сервера, задействованные в инфраструктуре VDI.

                            Второе, данная статья обзорная и описывает лабораторную среду, пригодную для теста, но не для производственного внедрения, если вы планируете VDI в корпоративной и сложной среде внимательно, именно внимательно ознакомьтесь с документами http://technet.microsoft.com/ru-ru/library/dd647502(v=ws.10).aspx

                            Третье, есть несколько вопросов:
                            Вы подготовили виртуальную машину рабочей станции для использования её в инфраструктуре VDI в соответствии с требованиями?
                            Вы планируете пул виртуальных рабочих столов или персональные рабочие столы?
                            Вы создали пул для виртуальных рабочих столов?
                            Вы добавили виртуальные машины в пул или назначили пользователей на виртуальные столы?

                            Внимательно изучите журналы на всех серверах вовлечённых в проект - всё ли у вас хорошо?

                            Если у вас есть вопросы, вы можете связаться со мной по почте cheryatnikov@gmail.com.

                            Удалить
                        3. Цитата:

                          "Если на хосте виртуализации поставил роль Hyper-V, создал виртуальные машины, скрипт подготовки выполнился успешно, поднял роли Connection Broker, RD Session Host и т. д. на другом сервере и не можешь добавить ВМ в оснастке, про которую писал - значит проблема в:

                          а. сами виртуальные машины рабочих столов
                          б. хост виртуализации с ролью Hyper-V
                          в. хост на котором установлены Connection Broker, RD Session Host
                          "

                          Проблема была в следующем:
                          Цитирую:
                          "Правильный ответ: б. ...Всё оказалось намного проще: у меня был физический гипервизор с 2012 сервером. А поднимал я на нём ВМ с 2008 осью....Сервер добавляется, а ВМ не показываются..."

                          ОтветитьУдалить

                        Уважаемый коллега, Ваш комментарий пройдёт модерацию, чтобы избежать спам-атак в ленте. Спасибо за понимание.