none
RDS 2012. Задежка при запуске RemoteApp приложения на доменном клиенте. RRS feed

  • Общие обсуждения

  • Доброго дня, уважаемые коллеги!

    Внедряем Remote Desktop Services на основе Windows Server 2012.

    RDS 2012 развернут в домене domainA.local

    В инфраструктуре RDS 2012 имеем:

    два сервера RD Gateway, они же WebAccess - gw1.domainA.local и gw2.domainA.local

    два сервера RD Connection Broker - cb1.domainA.local и cb2.domainA.local

    один сервер RD Session Host - sh1.domainA.local

    серверы Gateway объеденены в ферму средствами GW с общим именем rds.domain.ru

    в интернете создана запись для внешних клиентов rds.domain.ru с двумя IP-адресами (DNS-Round Robin)

    У каждого сервера GW&WA по две сетевые карты - одна смотрит в интернет, другая во внутреннюю сеть (domainA.local)

    На своем CA создали сертификат для GW&WA в котором есть и внешниее DNS имя (rds.domain.ru) и два внутренних (gw1.domainA.local и gw2.domainA.local)

    RD CB развернули высокодоступным с общим именем cb.domainA.local

    Начали тестирование.

    Начали с подключения с компьютера из домена domainB.local, у которого двухсторонних траст с доменом domainA.local

    Открываем RD WebAccess по адресу доступному из интернета - https://rds.domain.ru/RDWeb

    Видим, что с сертификатом все нормально. Кстати, по поводу сертификата. Сделали публикацию CRL серитфиката по адресу crl.domain.ru - это тот же IIS сервер. На всех клиентах проверяем, во всех тестах - CRL и CRT файлы доступны по HTTP всем клиентам. В сертификате один путь для CRL - HTTP (LDAP и прочие удалены).

    Далее запускаем ярлык приложения. Появляется предупреждение


    Хотя это очень странно. Ведь приложение подписано сертификатом с политикой Подписывание кода и выдан доверенным центром сертификации.

    Но вопрос даже не в этом.

    Далее мы жмем на кнопку Подключить.

    И вот здесь самое интересное. Получаем задержку перед запуском приложения в 38 секунд. После чего приложение успешно запускается. Но ведь это слишком большая задержка, и бизнесу это очень не понравится.

    Затем решили проверить это на компьютере в том же сетевом сегменте, но не введенном в домен. То есть машина в рабочей группе и в том же сетевом сегменте.

    Первый запуск. Щелкаем Подключить. Задержка большая, но меньше 30 секунд. Выходим. Заходим второй раз. Щелкаем Подключить - приложение запускается за считанные секунды (секунды 3). Видимо первый вход что-то было получено и закешировалось. Это предположение...

    Вводим компьютер в домен domainB.local - каждый раз задержки в 38 секунд, и первый вход и последующие.

    Посмотрели подключения Wireshark-ом. Когда компьютер в домене - имеется какой-то запрос CLDAP до контроллера домена domailA.local, притом ответа на этот запрос не приходит. Для одной тестовой машины настроили на свитче, чтобы на этот запрос сразу приходил отлуп  - задержка составила 25 секунд. Когда компьютера не в домене - такого запроса нет совсем.

    Вопросы на данный момент:

    1. Откуда такая задержка?

    2. Почему эта задержка есть у доменных клиентов и нет у не доменных?

    3. Как советуйте мониторить трафик? Wireshark на всех серверах и клиенте одновременно довольно сложновато. В логах ошибок нет ни при задержке в 38 секунд, ни при быстром коннекте с не доменной машины.

    4. Почему все таки появляется предупреждение о запуске приложения о надежности издателя?

    5. Что еще можно перепроверить? Где еще что посмотреть?

    16 августа 2013 г. 10:56

Все ответы

  • Посмотрите эту статью c TechNet Wiki, возможно проблема в клиентах, которые не поддерживают подключения с использованием UDP (порт 3391), и задержка обусловлена возвратом на подключение с использованием HTTP.

    17 августа 2013 г. 19:43
    Отвечающий
  • UDP по порту 3391 отключен изначально. Снята галочка с данного протокола в настройках Gateway. Предполагается, что все клиенты будут подключаться только с использованием протокола HTTP.

    Еще один момент, по которому хочется задать вопрос.

    Как я уже писал, у нас развернута ферма GW из двух нод. С помощью Process Explorer из Sysinternals было замечено, что при запуске RemoteApp приложения на клиенте приложение mstsc подключается одновременно к обоим нодам GW. Именно не к одной из них, а к обоим. Притом после того, как приложение открывается образуется еще по одной сессии к каждой ноде. То есть итого, по одной сессии к каждой ноде GW в момент подключения и еще по одной сессии к каждой ноде GW после запуска приложения.

    Возникало предположение, что такое поведение вызвано обеспечением отказоустойчивости. Но фактически соединение происходит лишь на одной ноде. Это видно в мониторинге на GW. Притом, если выключить или перегрузить ту ноду, на которой произошло соединение, то оно обрывается.

    19 августа 2013 г. 2:27
  • Сделали еще вот такой эксперимент:

    Сменили внешние адреса GW&WA серверов на адреса сети домена domainB.local и обнаружили, что при подключении с клиента в домене domainB.local (с того, на котором были задержки в 38 секунд), запуск приложения произошел довольно быстро (за 6 секунд) и самое главное с помощью Wireshark увидели, что GW обращается к контроллеру домена domainB.local для чего-то.

    Данное поведение не понятно. Ведь Gateway должен обеспечивать подключение любых клиентов (доменных\не доменных) и не должен проверять что-то на контроллерах домена клиента.

    Может быть кому-то стало понятнее, что за проблема у нас такая?

    21 августа 2013 г. 3:15