Построение 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 и рабочие станции).

SCSM Ошибка "Недопустимая длина массива знаков Base-64." при добавлении отчёта в "избранные отчёты"

Столкнулся со странной ошибкой при попытке добавить отчёт SCSM в избранные отчёты. Настроил параметры отчёта, нажал добавить в "Избранные отчёты". Назвал отчёт следующим образом "Все инциденты находящиеся в работе с понедельника текущей недели по сегодняшний день" и нажал "ОК".
Отчёт добавился в избранные, но при переходе на вкладку столкнулся с ниже приведённой ошибкой.

Дата: 08.12.2011 10:06:11
Приложение: System Center Service Manager
Версия приложения: 7.0.6555.0
Серьезность: Ошибка
Сообщение:
Недопустимая длина массива знаков Base-64.
System.FormatException: Недопустимая длина массива знаков Base-64.
в System.Convert.FromBase64String(String s)
в Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.SrsDataAdapterBase.TryGetInstanceId(IDictionary`2 parameters, String& instanceId)
в Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.EnterpriseFavoriteReportAdapter.GetDataFromSRS(ServiceManagerReportingGroup reportingGroup, AdapterQueryParameters queryParameters)
в Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.SrsDataAdapter`1.DoAction(DataQueryBase query, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs, String outputCollectionName)
в Microsoft.EnterpriseManagement.UI.SdkDataAccess.SdkNodeProvider.GetDataFromAdapter(Uri adapterAddress, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs)
в Microsoft.EnterpriseManagement.UI.SdkDataAccess.SdkNodeProvider.GetNode(Uri providerRoot, NavigationModelNodeBase parentNode, String nodeName)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationNodeProvider.GetNode(Uri providerRoot, Uri nodeLocation)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationModelAdaptor.GetNode(DataQueryBase query, IDictionary`2 parameters)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationNodeProvider.GetNode(Uri providerRoot, Uri nodeLocation)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationModelAdaptor.GetNode(DataQueryBase query, IDictionary`2 parameters)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationNodeProvider.GetNode(Uri providerRoot, Uri nodeLocation)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationModelAdaptor.GetNode(DataQueryBase query, IDictionary`2 parameters)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationNodeProvider.GetNode(Uri providerRoot, Uri nodeLocation)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationModelAdaptor.GetNode(DataQueryBase query, IDictionary`2 parameters)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationModelAdaptor.DoAction(DataQueryBase query, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs, String outputCollectionName)
в Microsoft.EnterpriseManagement.UI.DataModel.QueryQueue.StartExecuteQuery(Object sender, ConsoleJobEventArgs e)
в Microsoft.EnterpriseManagement.ServiceManager.UI.Console.ConsoleJobExceptionHandler.ExecuteJob(IComponent component, EventHandler`1 job, Object sender, ConsoleJobEventArgs args)

Анамнез:

• Избранные отчёты с англ. наименованиями успешно создаются, добавляются во вкладку избранные и успешно работают;
• Проблема с отчётами только с русскоязычным наименованием;
• Проверил Collation SQL Server и БД Cyrillic_General_100_CI_AS, а Collation SSRSLatin_General_CI_AS_KS_WS (SSRS устанавливался в режиме Native в конфигурации по-молчанию);

Причина:
Не поддерживаются наименования отчётов на русском языке длиннее 20 символов (по крайне мере доказал на своем опыте 32, 28, 23 не вошло - ошибку см. выше.);

Что делать:
На сервере, где установлен DW заходим в консоль управления SQL сервер, находим в базе DWStagingAndConfig таблицу dbo.FavoriteReport.

В ней выполняем запрос:

SELECT * 
FROM DWStagingAndConfig.dbo.FavoriteReport
WHERE DWStagingAndConfig.dbo.FavoriteReport.FavoriteReportName='Имя_отчёта_вызывающего_ошибку'

Находим в результатах поле FavoriteReportId и выполняем следующий запрос:

DELETE FROM DWStagingAndConfig.dbo.FavoriteReport
WHERE DWStagingAndConfig.dbo.FavoriteReport.FavoriteReportId=' FavoriteReportId_отчёта_вызывающего_ошибку';

Обновляем закладку избранные отчёты (F5): отчёт вызывающий ошибку исчез.
Ну и создавать короткие русскоязычные имена для отчётов. Кстати, подобных проблема с англ. языком я так и не заметил.

http://social.technet.microsoft.com/Forums/ru-RU/infrastructureru/thread/9f094565-7ad5-4511-a7fc-31f9ebe0f069

Split-Brain DNS: как выбрать правильную реализацию?

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

Как пример рассмотрим следующий сценарий:

существует корпоративная сеть с пользователями, которым необходим доступ к различным интернет ресурсам, а так же веб-сайтам компании, размещенными в DMZ и опубликованных в интернет;

 

Основная цели:

• обеспечить свободное разрешение доменных имён интернет для пользователей корпоративной сети
• обеспечить доступ корпоративных пользователей изнутри и снаружи к веб-сайтам компании
• предотвратить возможность для внешних пользователей разрешать имена внутренних ресурсов компании

  

Существует три возможных сценария построения системы разрешения доменных имён:

• Одинаковое имя DNS внутреннего и внешнего пространства имён организации (Пример: ABC.COM);
• Разное имя DNS для внутреннего и внешнего пространства имён организации, для разрешения имён используется Conditional Forwarding (Пример: ABC.LOCAL и ABC.COM);
• Делегированное имя зоны DNS для внутреннего пространства имён DNS (Пример: AD.ABC.COM и ABC.COM);

  

Одинаковое имя DNS внутреннего и внешнего пространства имён организации (Пример: ABC.COM)

Самый простой способ реализации. На внутреннем DNS размещаются “A” записи веб-ресурсов компании. Когда корпоративные пользователи запрашивают какой либо ресурс, размещённый в DMZ и опубликованный наружу, внутренний DNS отдаёт адрес, указанный в “А” записи, созданной администратором на внутреннем DNS сервере. Внешний DNS служит для обслуживания только внешних пользователей, динамические обновления записей на нём запрещены. Передача зон отключена.

Плюсы:

• Одинаковые имена для ресурсов внутри и снаружи – меньше вопросов от пользователей (пример: корпоративный веб-портал изнутри и снаружи будет доступен для пользователя по одинаковому адресу WEB.ABC.COM, хотя обслуживающие DNS сервера внутренней и внешней зоны друг о друге не знают);
• Не нуждается в дополнительной настройке сетевых экранов;
• Максимальная изоляция пространств имён;

 

Минусы:

• Для каждого веб-ресурса компании необходимо создать “А” запись в ручную, что не совсем удобно при большом их количестве и частых изменениях;
• Необходимо отслеживать актуальность записей в DNS, однако при небольшом количестве – это несложно.

Разное имя DNS для внутреннего и внешнего пространства имён организации, для разрешения имён используется Conditional Forwarding (Пример: ABC.LOCAL и ABC.COM)

ПРИМЕЧАНИЕ! На сегодняшний день, при построении инфраструктуры использование имён DNS, с неподдерживаемым Интернетом форматом (пример:*.local, *.loc,*.internal), не рекомендуется.

 

В данном сценарии существуют два отдельных DNS сервера для разрешения внутренних и внешних имён. Разрешение внешних веб-ресурсов компании происходит за счёт Conditional Forwarding. К примеру, запрос адреса ресурса WEB.ABC.COM к внутреннему DNS серверу будет перенаправлен на внешний DNS сервер отвечающий за зону ABC.COM. Внешний DNS служит для обслуживания внутренних и внешних пользователей, динамические обновления записей на нём запрещены. Передача зон отключена.

 

Плюсы:

• Простота администрирования веб-ресурсов компании (достаточно создать новую “А” запись для ресурса на внешнем DNS и он станет доступен внутренним пользователям, а так же пользователям из интернет);
• Снижение административной нагрузки - нет необходимости отслеживать актуальность “А” записей для внешних веб-ресурсов компании;

 

Минусы:

• Потребуется конфигурировать сетевые экраны компании для разрешения имён веб-ресурсов из внутренней сети;
• Могут возникнуть вопросы у пользователей, придётся объяснять разницу между abc.local и abc.com;
• В случае с настройкой Conditional Forwarding создаётся жесткая привязка имени внешнего домена ABC.COM к IP адресу внешнего DNS, в случае смены IP адреса внешнего DNS не забудьте поменять настройки Conditional Forwarding;

 

Делегированное имя зоны DNS для внутреннего пространства имён DNS (Пример: AD.ABC.COM и ABC.COM)

 

В данном сценарии существует внешний DNS, ответственный за домен ABC.COM, который делегировал внутреннему DNS серверу право на управление внутренней зоной AD.ABC.COM.

 

Плюсы и минусы данного сценария очень напоминают второй случай, однако в данном сценарии нам необходимо предотвратить разрешение имён из зоны AD.ABC.COM запросом снаружи, для этого потребуется сконфигурировать сетевые экраны компании на блокирование такого вида трафика (DNS запроса). Ещё один из возможных плюсов: внешний DNS сервер может являться *nix BIND DNS.

 

 

Сменить IP внешнего DNS будет достаточно проблемно – рекомендуется избегать подобных ситуаций.

 

Разрешение же имён веб-ресурсов компании внутренними пользователями происходит за счёт Conditional Forwarding,внешний DNS служит для обслуживания внутренних и внешних пользователей, динамические обновления записей на нём запрещены. Передача зон отключена.

 

Пожалуй, это основные сценарии реализации Split-Brain DNS, надеюсь данная короткая статья позволит вам выбрать правильную архитектуру DNS.

 

 

 

Источник <http://www.itcommunity.ru/blogs/cheryatnikov/archive/2011/11/22/176056.aspx>