суббота, 3 декабря 2016 г.

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


При разворачивании минимальной конфигурации RDS на скорую руку, в очередной раз сталкиваюсь с проблемами и в очередной раз забываю как их решать. Первое что нужно сделать перед развертыванием это конечно прочитать best practices, а потом составить план. Выписать все что необходимо заранее, подготовить, запросить. 

Например сертификат SSL и доменное имя типа remote.mycompany.ru (DNS запись A).  Даже развертывая очень маленький терминальный сервер для очень маленькой компании имеет смысл прикупить SSL если планируется доступ из сети интернет. Сегодня удаленный доступ нужен только с одного ноутбука, а завтра потребуется еще на десятке смартфонов. Замучаешься устанавливать везде свой локальный сертификат в корневые. Тем более что SSL сертификат сейчас стоит копейки. Я последнее время беру на https://www.ssls.com/ , с кодом 3.88DEAL  вообще копейки. И оплатить можно даже биткойнами. Проще всего запрос сертификата сделать установив на сервер роль IIS, тем более что он все равно потребуется для развертывания шлюза. В IIS есть раздел SSL, там визарды для создания запроса сертификата и для его установки (есть смысл запрашивать сертификат минимум 2048 bit ).
Часто сервер физически один, а службы удаленного доступа хотят иметь в своем составе шлюз, сервер лицензирования, сам терминальный сервер. Да и домен в ряде случаев не поднят. Технически возможна установка RDS на сервер в рабочей группе, но если есть возможность, можно сразу поднять контроллер домена. Если был куплен Windows Server Standard и выше, то его можно установить в двух экземплярах в виде виртуалок на одном физическом хосте. Если есть возможность - почему не использовать? Например DC аппаратный хост, а RDS на нем в Hyper-v. Или наоборот. Да DC в одном экземпляре, да еще и виртуальном, но ведь у нас нет 100500 ПК в этом домене. Всего один сервер и нужно просто иметь логины и пароли локальных админов.
В случае развертывания RDS в малом бизнесе очень часто IP адрес внешний один и нет возможности или желания докупать еще. В итоге создается конкуренция между внутренними сервисами за порты на этом IP. HTTP и HTTPS часто заняты другими ресурсами, и это создает массу проблем при развертывании RDS Gateway. Приходится переносить на другие порты, ручками местами прописывать потом эти порты.
Например, вместо 80 ставим 81, а вместо 443 - 442. Теряется красота ссылок на ресурсы, вместо https://remote.mycompany.ru/rdweb получаем https://remote.mycompany.ru:442/rdweb . Кроме того, наживаем кучу проблем с прописыванием этих самых 442 в разных местах. Есть пара решений, нашел на Windowsitpro.com. В оснастке диспетчера служб удаленных рабочих столов можно указать порты. Кроме того, для RemoteApp нужно тоже прописать порт, иначе приложения будут ссылаться на стандартный 443. Можно отредактировать реестр, указав порт:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<farm>\DeploymentSettings, в нем ищем DeploymentRDPSettings и добавляем к gatewayhostname:s:remote.mycompany.ru:442 номер порта. Сделать это нужно до того как опубликовали приложения RemoteApp, в противном случае приложения придется распубликовать и опубликовать повторно. Можно не реестром, а через PowerShell:
Set-RDSessionCollectionConfiguration –CollectionName "Your Collection" -CustomRdpProperty "gatewayhostname:s:<GATEWAY.FQDN>:<442>" -ConnectionBroker <Your Connection Broker> 
Но у меня на эти часть команд PS ругался, считал что RDS не установлены на сервере.Часто возникает проблема с SSL и hostname. SSL мы получили вида remote.mycompany.ru, а сервер у нас что-то вроде rdsserver.mycompany.local . Поэтому при первых же подключениях можно получить как минимум предупреждение "Имя сервера отличается от имени указанного в сертификате". Это если мы конечно прописали сертификат везде где надо:

  • Привязки в IIS к порту 442 (можно и к 443)
  • В диспетчере серверов (Настройка развертывания служб удаленных рабочих столов)
  • В диспетчере шлюза удаленных рабочих столов ( у меня не прописался сам, пришлось ручками).



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

Решить проблему можно либо командой:
Set-RDSessionCollectionConfiguration –CollectionName QuickSessionCollection -CustomRdpProperty “use redirection server name:i:1 `n alternate full address:s:remote.mycompany.ru”либо скриптом.
.\Set-RDPublishedName.ps1 "remote.mycompany.ru:442"
Скрипт у меня сразу не запустился, нашел ряд решений, например -
powershell.exe -noprofile -executionpolicy bypass -file .\Set-RDPublishedName.ps1
Я зачем-то еще настроил на DC DNS зону mycompany.ru, и в ней создал DNS запись A "remote.mycompany.ru", указывающую на внутренний адрес RDS сервера, но это скорее по привычке.
Все бы ничего, но как только мы решили проблему с несоответствием имени указанном в SSL сертификате и имени сервера к которому подключаемся, появляется другая проблема.
event 301:
Пользователь "mycompany\user" на клиентском компьютере "8.8.8.8" не соответствует требованиям политики авторизации ресурсов и не авторизован для подключения к ресурсу "remote.mycompany.ru". Произошла следующая ошибка: "23002".
Дело в том что по умолчанию создаются политики удаленного доступа для штатной ситуации. А мы уже подправили скриптом, реестром, имя сервера к которому ведется подключение. И в политиках ничего не написано про remote.mycompany.ru. Открываем диспетчер шлюза удаленных рабочих столов и правим политику - добавляем туда наш адрес remote.mycompany.ru.