Where did the Remote Desktop Services properties go in 2012 R2? In 2008 R2, we had the RDP-TCP connections properties… where did all that go in 2012 R2?
asked Jan 23, 2015 at 4:59
It went to Servermanager -> Remote Desktop Services -> Collections -> $collectionname -> The «tasks» button on the properties field (upper left):
Tim
31.1k7 gold badges49 silver badges77 bronze badges
answered Jan 23, 2015 at 8:21
1
I had this same issue, it appears that it is not longer a Administrative Tool for managing your server. This will need be handled by using Group Policy. To access it hit the Windows button and type «Edit Group Policy» to access the Local GPO.
The settings are located here:
Computer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop Services
Source: https://technet.microsoft.com/en-us/library/dd834779.aspx
answered Apr 5, 2016 at 19:57
BRNDRBRNDR
11 bronze badge
- Remove From My Forums
-
Вопрос
-
Hi,
On server 2008 R2 I could install remote desktop session host then navigate to Administrative Tools > Remote Desktop > Remote Desktop Host Session Configuration. Then I would right click on RDP-tcp then click the tab «logon settings».
This would allow me to put in the domain name.What I am trying to achieve is that when a user is trying to log into this server they dont have to type in «DOMAINusername» they just type the username and password. Below the input fields it shows the FQDN.
Hope that makes sense and someone can answer me?
Thanks
Ответы
-
This really isn’t a server setting. When users logon the first time the
DomainNameUserName is cached in the current user hive on client machine (one for each terminal server) atHKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers{server}UsernameHint
So they only need to type it correct the first time, thereafter it is prepopulated.
Regards, Dave Patrick ….
Microsoft Certified Professional
Microsoft MVP [Windows]Disclaimer: This posting is provided «AS IS» with no warranties or guarantees , and confers no rights.
-
Изменено
2 сентября 2014 г. 1:04
-
Предложено в качестве ответа
cguan
2 сентября 2014 г. 6:50 -
Помечено в качестве ответа
Susie Long
8 сентября 2014 г. 5:10
-
Изменено
Привет.
Вчера, общаясь с Иваном Никитиным, получил дельный совет осветить работу и настройку протокола RDP. Мысль дельная, дальше – подробнее.
Введение
Протокол RDP – удобное, эффективное и практичное средство для удалённого доступа как для целей администрирования, так и для повседневной работы.
Учитывая, что его реализации есть практически везде (различные платформы и ОС), и их много, нужно хорошо представлять его возможности.
По крайней мере, это будет нужно по ряду причин:
- Зачастую вместо RDP используется другое решение (VNC, Citrix ICA) по простой причине – предполагается, что “встроенный RDP минимальный и ничего не умеет”.
- Во многих решениях, связанных с модными сейчас облачными технологиями (перевод офисов на “тонкие клиенты”, да и просто организация терминальных серверов), бытует мнение что “RDP плохой потому что встроенный”.
- Есть стандартный миф про то, что “RDP нельзя без VPN наружу выставлять, ломанут” (миф имеет под собой обоснование, но уже давно не актуален).
- Ну, раз уж про мифы заговорили – бытует мнение, что “Перейдя с RDP на Citrix трафик в пару раз падает”. Ведь цитрикс – это дорого, следовательно как минимум на 157% круче.
Все эти мифы – ерунда и смесь устаревших “дельных советов”, актуальных во времена NT 4.0, а так же откровенных вымыслов, не имеющих никаких причин к существованию. Так как IT – это точная наука, надо разобраться. Хорошо настроеный протокол RDP новых версий, с учётом всех новых функциональных возможностей, является достаточно хорошим и надёжным инструментом для организации удалённого доступа.
Поэтому мы займёмся:
- Кратким упоминанием про версии RDP
- Настройкой режима защиты RDP-сессии
- Настройкой шифрования для RDP
- Привязкой к конкретному адаптеру и порту
- Меняем стандартный порт на нужный
- Делаем раздельные настройки RDP для нескольких сетевых адаптеров
- Включением NLA
- Как включается NLA со стороны RDP-сервера
- NLA и Windows XP
- Как включить CredSSP в XP
- Выбором правильного сертификата для RDP
- Блокированием подключений по RDP учётным записям с пустым паролем
- Настройка ACL для подключения по RDP
- Оптимизацией скорости RDP
- Отключаем редирект неиспользуемых устройств
- Настраиваем общую логику оптимизации визуальных данных RDP
- Оптимизацией сжатия RDP
- Настраиваем общее сжатие RDP
- Настраиваем сжатие аудиопотока RDP
- Оптимизацией соотношения потоков данных RDP
- Включением Require secure RPC communication для RDP
Приступим.
Версии протокола RDP
Протокол имеет достаточно длительную историю, начиная с NT 4.0. Исторические детали мы оставим в стороне по простой причине – на данный момент имеет смысл говорить только про версию RDP 7.0, которая есть в Windows Vista SP1 / Windows Server 2008 и бесплатно добавляема в Windows XP установкой SP3 и обновлённого клиента RDP (находится по ссылке на KB 969084). Я предполагаю, что у Вас как минимум Windows XP, и что Вы поставили/можете поставить последний Service Pack и не трачу Ваше время на обсуждение преимуществ RDP в Windows 2000 SP2 перед NT 4.0 SP5.
Настройка режима защиты RDP-сессии
В принципе, это самая простая часть задачи. Суть в следующем. В различных версиях RDP применяется два основных механизма защиты сессии – встроенный в RDP и “заворачивание” сессии в TLS. Встроенный является недостаточно безопасным, и рекомендация “RDP можно наружу только в VPN” – про него. Поэтому всегда включайте поддержку TLS. Это тот минимум, с которого Вы должны начать. Ограничениями будут разве что версия сервера не ниже Windows Server 2003 SP1 и клиент RDP 5.2 и выше, но, думается, это в конце 2011 года вполне решаемо.
Как включить RDP over TLS
Вариантов, как всегда, несколько. Первый – включение через групповую политику. Для этого надо зайти в целевой объект групповой политики (ну или локально на своей домашней рабочей станции запустить gpedit.msc) и там последовательно выбрать “Computer Configuration” -> “Administrative Templates” -> “Windows Components” -> “Remote Desktop Session Host” -> “Security” и там включить параметр Require use of specific security layer for remote connections, выбрав в нём SSL (TLS 1.0) only. Можно выбрать и более мягкий Negotiate, но я бы не рекомендовал, т.к. на данный момент это банально ниже приемлемого уровня безопасности. Как человек, создававший private cloud’ы с достаточно высоким уровнем безопасности, я могу сказать, что смысл выносить особо ценные данные в датацентр под Лондоном и ходить туда дефолтным RDP – нулевой и является поиском неприятностей.
Можно и проще – откройте оснастку Remote Desktop Session Host Configuration (найдёте в mmc или готовую в меню Administrative Tools -> Remote Desktop Connections), выберите из списка Connections нужное подключение (обычно оно одно и называется RDP-Tcp), и откройте Properties, после – вкладку General и там выбрать нужный Security Layer.
Для работы TLS необходим цифровой сертификат (как минимум – со стороны сервера). Обычно он уже есть (генерится автоматически), убедитесь в его наличии, про то, как сделать его хорошим, поговорим после. Пока надо, чтобы он просто был, иначе подключиться не получится.
Настраиваем шифрование для RDP
Для конфигурирования будет доступно 4 варианта шифрования. Рассмотрим каждый из них.
Режим RDP Low Encryption
Самый “никакой” режим. Наследие страшных времён и версий RDP 5.x. Может согласовать шифрование на базе 56ти битового DES или 40ка битового RC2, что на текущий момент является несерьёзным. Не нужен и опасен. Например, если включить его, то не включится TLS, т.к. TLS уже откажется согласовывать такие слабые шифры, которые предлагает этот вариант.
Режим RDP Client Compatible Encryption
Второй “никакой” режим. Наследие страшных времён и версий RDP 5.x. Попробует до 128 бит RC4, но сразу согласится на DES/RC2. Не нужен и опасен. Тоже не совместим с TLS.
Режим RDP High Encryption
Минимально допустимый режим. Потребует хотя бы 128ми битовый RC4. Работает со всеми серверами, начиная с Windows 2000 Server w/HEP.
Режим RDP FIPS140-1 Encryption
То, что нужно. Будет поддерживать современные симметричные алгоритмы и в явном виде не будет поддерживать RC2, RC4, одиночный DES, а также будет заставлять использовать для вычисления целостности (Message Authentication Code – MAC) алгоритм SHA-1, а не MD5. Включайте этот вариант всегда, найти сервер, который не умеет 3DES, AES или SHA-1 практически нереально.
Где делается эта настройка? Откройте оснастку Remote Desktop Session Host Configuration (найдёте в mmc или готовую в меню Administrative Tools -> Remote Desktop Connections), выберите из списка Connections нужное подключение (обычно оно одно и называется RDP-Tcp), и откройте Properties, после – вкладку General и там выберите нужный Encryption Level.
Привязываем RDP к конкретному адаптеру и порту
Для того, чтобы сервер работал безопасно и предсказуемо (например, не начинал принимать подключения с нового, свежедобавленного сетевого адаптера), необходимо в явном виде указать, на каких интерфейсах служба RDP-сервера должна принимать подключения. Плюс, достаточно часто бывает полезным переключить порт, на котором сервер слушает подключения. Конечно, можно это сделать и публикуя сервер с RDP через какой-нибудь шлюз, но можно и без этого. Такие, казалось бы, базовые действия в реальности ощутимо снизят процент дураков-скрипткиддисов, которые очередной “мощной тулзой” проверяют wellknown-порты.
Как привязать службу RDP к конкретному сетевому адаптеру или сделать несколько RDP с разными настройками для разных адаптеров
Откройте оснастку Remote Desktop Session Host Configuration (найдёте в mmc или готовую в меню Administrative Tools -> Remote Desktop Connections), выберите из списка Connections нужное подключение (обычно оно одно и называется RDP-Tcp), и откройте Properties, после – вкладку Network Interfaces. В ней Вы сможете выбрать один конкретный интерфейс, на котором надо ожидать подключения, плюс ограничить количество параллельных сессий.
Если у Вас много интерфейсов, и Вам надо, допустим, чтобы можно было подключаться через 2 из 5 доступных, то Вам надо будет привязать существующий по-умолчанию RDP-Tcp к одному адаптеру, после зайти в меню Action и там выбрать Create New Connection. Подключение может слушать либо на всех интерфейсах, либо на одном, и в случае, когда надо, чтобы оно слушало на N интерфейсах, придётся создать N подключений.
Соответственно, если у Вас есть задача “Чтобы на одном интерфейсе RDP слушал на одном порту, а на другом – на другом”, она решаема так же – отвязываете дефолтный RDP-Tcp от всех адаптеров и привязываете к конкретному, после – создаёте новое RDP-подключение и тоже привязываете к нужному сетевому интерфейсу.
Как привязать службу RDP к не-дефолтному порту
Порт по умолчанию – 3389 TCP. Кстати, не забудьте разрешить его в пакетном фильтре. Ну а если хотите другой – надо зайти в ключ реестра
HKEY_LOCAL_MACHINESystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp
и поправить в нём значение PortNumber. Учитывайте, что отслеживание конфликтов в плане занятости портов – на Вашей совести, сам он, обнаружив, что назначенный Вами порт занят, “перепрыгнуть” никуда не сможет.
Включаем NLA – Network Level Authentication
Функция NLA появляется в NT 6.0, а позже добавляется возможность её частичного использования в предыдущей версии ОС путём установки SP3 для XP.
Суть данной функции достаточно проста. В версиях RDP до 6.0 при подключении по RDP клиенту до аутентификации надо показать окно входа – т.е. вначале показать, а потом уже он попробует зайти в систему. Это создаёт простую уязвимость – сервер можно перегрузить пачкой запросов “а дай-ка мне попробовать новую сессию начать”, и он будет вынужден на все запросы отвечать созданием сессии и ожиданием входа пользователя. Фактически, это возможность DoS. Как с этим можно бороться? Логично, что надо придумать схему, целью которой будет как можно раньше запросить у клиента учётные данные. Оптимально – чтобы было что-то типа как kerberos в домене. Это и было сделано. NLA решает две задачи:
- Клиент аутентифицируется до инициации терминальной сессии.
- Появляется возможность передать данные локального клиентского SSP на сервер, т.е. начинает работать Single Sign-On.
Реализуется это через новый провайдер безопасности – CredSSP. Почитать его техническую спецификацию можно тут, ну, а говоря проще, надо всегда включать данную функцию. Конечно, учитывая, что для её работы нужно, чтобы:
- Клиентская ОС (та, с которой идёт подключение) была Windows XP SP3 и выше.
- Серверная ОС (та, к которой будет подключение) была Windows Server 2008 и выше.
Как включается NLA со стороны RDP-сервера
Лучше всего включить NLA на всех серверах через групповую политику. Для этого надо зайти в целевой объект групповой политики и там последовательно выбрать “Computer Configuration” -> “Administrative Templates” -> “Windows Components” -> “Remote Desktop Session Host” -> “Security” и там включить параметр Require user authentication for remote connections by using Network Layer Authentication.
Можно включить и локально. Это делается путём вызова подменю Properties (стандартное подменю у Computer) и выбора там вкладки Remote, в которой будет выбор из трёх вариантов – запрещать подключения по RDP к данному хосту, разрешать подключения по любому RDP, разрешать только с NLA. Всегда включайте вариант с NLA, это в первую очередь защищает сервер.
NLA и Windows XP
В случае, если у Вас Windows XP, то Вы также можете воспользоваться данной функцией. Распространённое утверждение “Для NLA нужна как минимум виста, это Microsoft сделал чтобы апгрейдились” ложно. В Service Pack 3 добавляется реализация CredSSP, позволяющая делегировать клиентские credentials’ы, которыми обладает местный SSP, на сервер. Т.е., говоря проще, это специально сделано, чтобы с Windows XP можно было подключаться на системы с NT 6.0+. На саму Windows XP SP3 с данной функцией подключаться не получится, поддержка NLA будет частичной (поэтому RDP сервер с поддержкой подключения клиентов с использованием NLA из Windows XP сделать штатными способами не получится, Windows XP будет только NLA-совместимым клиентом).
Включать данный функционал нужно в явном виде, так как несмотря на то, что Service Pack 3 добавляет приносит новую dll криптопровайдера, он её не включает.
Как включить CredSSP в XP
Ещё раз – данная операция проводится строго после установки Service Pack 3 на Windows XP и в контексте нашего разговора нужна для того, чтобы было возможно подключение к другим серверам по RDP 6.1 с использованием NLA.
Шаг первый – расширяем перечень Security Packages.
Для этого мы откроем ключ реестра
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa
и найдём в нём значение Security Packages. Нажмём правую кнопку и выберем “Modify” (не Modify Binary Data, а просто Modify). Там будет список вида “название package на каждой строке”. Нам надо добавить туда tspkg. Остальное надо оставить. Место добавления некритично.
Второй шаг – подцепляем библиотеку.
Ключ будет другим:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProviders
В нём надо будет найти значение SecurityProviders (заметьте, как и в предыдущем случае, это не subkey, а значение), и модифицировать его по аналогии, только добавив credssp.dll. Остальное в списке, опять же, трогать не надо.
Теперь редактор реестра можно закрыть. После этих операций систему надо будет обязательно перезагрузить, т.к. криптопровайдеры – штука такая, которая на ходу точно не подцепится, и это скорее хорошо, чем плохо.
Выбираем правильный сертификат для RDP
Если у Вас есть возможность пользоваться не-дефолтным сертификатом для RDP, то лучше пользоваться именно им. Это не повлияет на безопасность сессии как таковой, но повлияет на безопасность и удобство подключения. В сертификате, который оптимально использовать, должны быть следующие момент:
- Имя (в subject или SAN), посимвольно совпадающее с тем именем, которое вводит клиент, подключающийся к серверу.
- Нормальное расширение CDP, указывающее на рабочий CRL (желательно хотя бы на два – OCSP и статический).
- Желательный размер ключа – 2048 бит. Можно и больше, но помните об ограничениях CAPI2 в XP/2003.
- Не экспериментируйте с алгоритмами подписи/хэширования, если Вам нужны подключения со стороны XP/2003. Чуть больше информации про это в статье про настройку TLS, но вкратце – выберите SHA-1, этого вполне достаточно.
Чуть подробнее остановлюсь на выпуске специального сертификата для RDP-сервера.
Делаем всё красиво – специальный шаблон сертификата для RDP-серверов
Идеально будет, если сертификат для RDP сделать не на основе обычного шаблона (типа Web Server) и иметь в поле Application Policy (которое в сертификате будет более привычно называться Enchanced Key Usage – EKU) стандартные значения Client Authentication и Server Authentication, а добавить свой шаблон, в котором будет единственное, специальное, не добавляемое стандартными способами значение применения – Remote Desktop Authentication. Это значение Application Policy придётся создать вручную, его OID’ом будет 1.3.6.1.4.1.311.54.1.2, ну а после – уже можно сделать новый шаблон сертификата, на основании которого и выпустить сертификат, адресно “заточеный” под RDP Server.
Чтобы полностью автоматизировать эту операцию, сделайте у нового шаблона предсказуемое название – например, “RDPServerCert” – и зайдите в объект групповой политики, а там откройте Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Выберите параметр Server Authentication Certificate Template и включите его, а в поле значения введите название – мы сделали RDPServerCert. Теперь все доменные хосты, подпадающие под эту политику, будут в случае включения на них RDP сами идти к Certification Authority, запрашивать в случае отсутствия себе сертификат на основе указанного шаблона, и автоматически делать его дефолтным для защиты подключений по RDP. Просто, удобно, эффективно.
Блокируем подключения по RDP учётным записям с пустым паролем
Мелочь, а забывать про неё не нужно.
Для блокировки подключения учёток без паролей к RDP надо зайти в настройку объекта групповой политики: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options и установить “Accounts: Limit local account use of blank passwords to console logon only” в Enabled. Не поленитесь проверить, что это так и есть.
Настройка ACL для подключения по RDP
По умолчанию для подключения к RDP-серверу необходимо иметь явное разрешение User Access или Guest Access.
Это разрешение есть у локальных групп Administrators и Remote Desktop Users. Лучше всего использовать для управления доступом к RDP-серверу группу Remote Desktop Users, добавляя в неё нужные доменные группы, а не отдельных пользователей. Модицифируйте содержимое вкладки Security в настройках Properties у RDP-Tcp только в крайних случаях, лучше всего – добавляя группу “имя хоста RDP Blocked”, которой явно запрещен доступ по RDP к указанному узлу.
Оптимизация скорости RDP
Оптимизация скорости RDP – достаточно обширная тема, поэтому я разделю её на части. В этой будут те способы, которые будут уменьшать нагрузку на протокол до сжатия и до оптимизации сетевого уровня.
Цветность (битовая глубина)
В RDP 7.0 и выше доступны варианты 32,16 и 8 бит. Если речь идёт о работе, то для неё будет достаточно 16 бит. Это ощутимо снизит нагрузку на канал, притом иногда больше, чем в 2 раза, что удивительно, но факт. 8 бит, конечно, тоже можно, но уж больно страшно оно будет выглядеть. 16 бит же вполне приемлемы.
Включите на сервере параметр Limit Maximum Color Depth, либо сделайте аналогичное действие в настройках RDP client.
Отключите ClearType
Когда у Вас выключен ClearType, протокол RDP передаёт не картинку, а команды по отрисовке символов. Когда включен – рендерит картинку со стороны сервера, сжимает и пересылает клиенту. Это с гарантией в разы менее эффективно, поэтому отключение ClearType значительно ускорит процесс работы и уменьшит время отклика. Сами удивитесь, насколько.
Это можно сделать как на уровне настроек клиента, так и на стороне сервера (параметр Do not allow font smoothing в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host).
Уберите wallpaper
Параметр Enforce removal of RD Wallpaper в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host резко улучшит ситуацию с перерисовкой экрана терминальной сессии. Пользователи без котиков на десктопе выживают нормально, проверено.
Включаем и настраиваем кэширование изображений
Если на клиенте есть достаточно оперативной памяти, то имеет смысл включить и настроить кэширование битмапов. Это позволит выиграть до 20-50% полосы пропускания. Для установки надо будет зайти в ключ
HKEY_CURRENT_USERSOFTWAREMicrosoftTerminal Server Client
и создать там параметры BitmapPersistCacheSize и BitmapCacheSize, оба типа DWORD 32.
Параметр BitmapPersistCacheSize обозначает размер в килобайтах дискового кэша. Значение по умолчанию – 10. Имеет смысл увеличить этот параметр хотя бы до 1000.
Параметр BitmapCacheSize обозначает размер в килобайтах кэша в RAM. Значение по умолчанию – 1500. Имеет смысл увеличить этот параметр хотя бы до 5000. Это будет всего 5 мегабайт на клиентскую сессию, при современных масштабах оперативной памяти это несущественно, и даже если приведёт к выигрышу 10% производительности, уже себя окупит. Кстати, этот же параметр можно поправить и в .rdp-файле; если сохранить своё RDP-подключение, а после открыть файл блокнотом, то среди параметров можно добавить что-то вида bitmapcachesize:i:5000, где 5000 – это 5МБ кэша.
Отключаем Desktop Composition
Desktop Composition привносит всякие “красивости” типа Aero и его друзей и ощутимо кушает полосу пропускания. Для работы это не нужно и вредно. Параметр Allow desktop composition for RDP Sessions в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host необходимо выставить в параметр Disabled.
Оптимизируем параметры Desktop Window Manager
Параметры, находящиеся в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Desktop Window Manager, будут управлять “красивым” отображением плавно выезжающих меню и подобного. Их три – Do not allow window animations, Do not allow desktop compositions и Do not allow Flip3D invocation. Все их надо переключить в режим Enabled, т.е. по сути – отключить все эти функции.
Отключаем редирект неиспользуемых устройств
Если у Вас не планируется подключение определённых классов устройств (например, COM и LPT-портов), или аудио, имеет смысл отключить возможность их перенаправления со стороны сервера. Чтобы клиенты с дефолтными настройками RDP Client не тратили время подключения на согласование неиспользуемого функционала. Это делается там же, где и остальные настройки сервера, в Properties у RDP-Tcp, вкладка Client Settings (там же, где мы делали настройки с глубиной цвета), раздел Redirection.
Настраиваем общую логику оптимизации визуальных данных RDP
Параметр, называющийся Optimize visual experience for RDP sessions, находящийся в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Enviroment, будет управлять тем, как RDP будет воспринимает визуальные данные – как мультимедийные или как текстовые. Это, грубо говоря, “подсказка” алгоритму сжатия, как грамотнее себя вести. Соответственно, для работы надо будет выставить этот параметр в Text, а если хочется много красивых flash-баннеров, HTML5 и просматривать видеоклипы – лучше вариант Rich Multimedia.
Оптимизация сжатия RDP
Сжатие в RDP прошло долгий путь развития. По RDP 5.2 включительно была подсистема сжатия (“компрессор”), имеющий внутреннее название “Version 1” – самый простой и лёгкий вариант с точки зрения загрузки процессора клиента, но самый плохой с точки зрения нагрузки сети трафиком. В RDP 6.0 сделали “Version 2”, который был незначительно, но улучшен по параметру эффективности сжатия. Нам интересен “Version 3”, который работает только при подключении к серверам Windows Server 2008 и старше. Он сжимает лучше всех, а затраты процессорного времени с учётом мощностей современных компьютеров несуществены.
Выигрыш при включении V3 может, судя по тестам, достигать 60% и, в общем-то, и без тестов ощутимо заметен на глаз.
Как включить оптимальное сжатие в RDP
Это – клиентская настройка. Откройте в нужном объекте групповой политики Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Enviroment, выберите там параметр Set compression algoritm for RDP data, включите его и выберите значение Optimize to use less network bandwidth.
Настройка сжатия звукового потока
RDP 7.0 приносит отличную возможность регулировать качество сжатия входящего звукового потока (т.е. звука, который идёт с сервера на клиента). Это достаточно полезно – например, если идёт работа на терминальном сервере, то кроме всяких служебных звуков вида “пришло сообщение в ICQ” другие особо как не планируются. Нет смысла передавать с сервера несжатый звук CD-качества, если для работы это не нужно. Соответственно, нужно настроить уровень сжатия звукового потока.
Данный параметр будет называться Limit audio playback quality и находиться в разделе Device and Resource Redirection в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host. Вариантов будет три:
High– звук будет идти без сжатия. Вообще. То есть, он будет подпадать под общее сжатие протокола RDP, но специфическое сжатие звука (с потерей качества) производиться не будет.Medium– сжатие будет адаптироваться под канал так, чтобы не увеличивать задержку при передаче данных.Dynamic– сжатие будет динамически адаптироваться под канал так, чтобы задержка не превышала 150ms.
Выберите подходящий. Как понятно, для офисной работы лучше выбрать Dynamic.
Оптимизация соотношения потоков данных в RDP
Трафик RDP-сессии не является чем-то монолитным. Наоборот, он достаточно чётко разделён на потоки данных перенаправляемых устройств (например, копирования файла с локального хоста на терминальный сервер), аудиопоток, поток команд примитивов отрисовки (RDP старается передавать команды примитивов отрисовки, и передаёт битмапы в крайнем случае), а также потоки устройств ввода (мышка и клавиатура).
На взаимное соотношение этих потоков и логику его (соотношения) вычисления (этакий локальный QoS) можно влиять. Для этого надо со стороны сервера зайти в ключ реестра
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTermDD
и создать там для начала (если их там нет) четыре ключа:
- FlowControlDisable
- FlowControlDisplayBandwidth
- FlowControlChannelBandwidth
- FlowControlChargePostCompression
Тип у всех – DWORD 32. Функционал у ключей будет следующим.
Ключ FlowControlDisable будет определять, используется ли приоритезация вообще. Если задать единицу, то приоритезация будет выключена, если нуль – включена. Включите её.
Ключи FlowControlDisplayBandwidth и FlowControlChannelBandwidth будут определять взаимное соотношение двух потоков данных:
- Поток взаимодействия с пользователем (изображение+устройства ввода)
- Прочие данные (блочные устройства, буфер обмена и всё остальное)
Сами значения этих ключей не критичны; критично то, как они соотносятся. То есть, если Вы сделаете FlowControlDisplayBandwidth равным единице, а FlowControlChannelBandwidth – четырём, то соотношение будет 1:4, и на поток взаимодействия с пользователем будет выделяться 20% полосы пропускания, а на остальное – 80%. Если сделаете 15 и 60 – результат будет идентичным, так как соотношение то же самое.
Ключ FlowControlChargePostCompression будет определять, когда считается это соотношение – до сжатия или после. Нуль – это до сжатия, единица – после.
Я рекомендую для использования вида “наш удалённый сервак далеко и к нему все по RDP подключаются и в офисе и 1С работают” ставить соотношение 1:1 и считать его после сжатия. По опыту это может реально помочь в ситуации “печать большого документа с терминального сервера на локальный принтер”. Но это не догма – пробуйте, главный инструмент – знание, как это считается и работает – у Вас уже есть.
Включаем Require secure RPC communication для RDP
Данный параметр действует аналогично настройкам для Secure RPC, которые есть в разделе Security групповой политики и действуют на всю систему, только настраивается проще. Включив этот параметр Вы сделаете обязательным для всех клиентских RPC-запросов шифрование (в зависимости от настроек системы “нижняя планка” шифрования будет разной – RC4/DES или, в случае включения FIPS-140 – 3DES/AES) и использование как минимум NTLMv2 для аутентификации удалённого вызова процедур. Всегда включайте этот параметр. Есть миф про то, что он не работает во внедоменной среде. Это не так, и усиление защиты RPC никому не помешает.
Это – серверная настройка. Откройте в нужном объекте групповой политики Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security, выберите там параметр Require secure RPC communication и включите его.
Заключение
Так как все уже давно вытащили сервера на внешние площадки за бугром, то этот материал является Я надеюсь, что данный материал будет Вам полезен для оптимизации и защиты RDP. Если я что-то пропустил – прошу в комментарии.
Начало
В данном руководстве будет рассмотрена процедура изменения порта RDP в операционной системе Windows Server 2012.
Обратите внимание что — все дальнейшие процедуры меняют порт RDP что приведет к отключению текущего соединения с сервером, в связи с этим рекомендуем использовать другие варианты подключения к серверу (например через Веб консоль из личного кабинета).
Для того чтобы выполнить эту задачу, необходимо осуществить редактирование реестра операционной системы.
Редактирование реестра производится с помощью программы-редактора.
Нажмите Пуск и в панели Поиск напечатайте cmd.
В появившемся черном окошке консоли наберите и выполните команду regedit.
В редакторе реестра нужно отыскать раздел RDP-Tcp, сделать это можно, пройдя такой путь:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp:
В нем необходимо отыскать элемент PortNumber (как на картинке выше), и открыть этот параметр.
Далее следует переключиться в Десятичный (Decimal) формат ввода и задать новый порт для подключения по протоколу RDP:
При выборе нового порта для подключения необходимо помнить о том, что существует несколько категорий портов в разбивке по их номерам:
- Номера от 0 до 10213 — известные порты, которые назначаются и контролируются организацией IANA (Internet Assigned Numbers Authority).
Как правило, их используют различные системные приложения ОС. - Порты от 1024 до 49151 — зарегистрированные порты, назначаемые IANA. Их позволяется использовать для решения частных задач.
- Номера портов от 49152 до 65535 — динамические (приватные) порты, которые могут использоваться любыми приложениями или процессами для решения рабочих задач.
Правило для порта
После изменения порта для удаленного подключения, необходимо открыть его в настройках межсетевого экрана, иначе попытки внешнего соединения будут блокироваться.
Для этого, нужно воспользоваться оснасткой управления Брандмаэур Windows в режиме повышенной безопасности
Открыть ее можно, зайдя в меню: Диспетчер Серверов —> Средства.
В ней нужно выбрать пункт «Правила для входящих подключений», кликнуть по этому пункту правой кнопкой мыши и выбрать «Создать правило»:
Мы будем создавать правило для порта:
Нужно выбрать тип протокола (TCP или UDP) и указать порт, который мы задавали в ходе редактирования реестра
(в нашем примере — протокол TCP, номер порта 60000):
На следующем этапе нужно выбрать тип действия, которое описывает правило.
В нашем случае нужно разрешить подключение с использованием указанного порта.
На следующем шаге необходимо указать область действия правила — оно зависит от того, где работает сервер (в рабочей группе, домене, или частном доступе):
Затем нужно выбрать имя для правила (рекомендуется выбирать его таким образом, чтобы затем правило было легко узнать среди других):
После этого нужно перезагрузить сервер.
Теперь для подключения к нему по протоколу RDP нужно использовать новый порт.
Let’s try to figure out how to fix an RDP connection error This computer can’t connect to the remote computer. It occurs when you try to connect to a remote Windows computer or Windows Server host running Remote Desktop Services (RDS) role using the built-in Windows RDP client (mstsc.exe).
The problem looks like this: when you try to connect to a remote Windows server/desktop via RDP, the mstsc.exe client freezes for a minute, and a window with the following RDP error appears:
Remote Desktop Connection
This computer can’t connect to the remote computer.
Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.
Check the RDP Network Connectivity
First of all, check if the remote computer is accessible from your device over the network, and the default Remote Desktop port (TCP 3389) is responding (and not blocked by firewalls).
Make sure the DNS address of the remote RDP host is correctly resolved from your computer. Use the following commands:
nslookup rdp_server_name1 ping rdp_server_name1
If the DNS name is not resolved properly, check your DNS settings or try connecting to a remote host using its IP address.
Hint. Be sure to check the contents of the local hosts file. It should not contain static entries for the name or IP address of your remote server. Remove extra entries from the hosts file. You can list the contents of the hosts file using PowerShell:
Get-Content $env:SystemRootSystem32Driversetchosts
You can check the RDP port availability on a remote server from a client workstation using:
The Telnet client:
telnet rdp_server_name1 3389
PowerShell 4.0 and higher:
Test-NetConnection rdp_server_name1 -Port 3389 -InformationLevel Quiet
Note. If this command returned True, then the RDP port responds on the server and it’s not blocked.
PowerShell all versions:
New-Object System.Net.Sockets.TcpClient).Connect(‘rdp_server_name1’, 3389)
If port 3389 is unavailable, you should check if the Remote Connection is enabled on the remote server (right-click on Start button > Settings > System > Remote Desktop > Enable Remote Desktop).
You can enable RDP remotely on a Windows computer by changing the fDenyTSConnections registry.
Check the RDP Service Settings on the Remote Computer
If Remote Desktop is enabled, next you should check the setting, which determines the maximum number of simultaneous users’ connections to a Remote Desktop. Open tsadmin.msc mmc snap-in (Administrative tools > Remote Desktop Services > Remote desktop Session Host Configuration). Click on RDP-TCP properties, and check the value of the Maximum connections property in Network Adapter tab.
The tsadmin.msc is missing in modern Windows versions (like Windows 10 or Windows Server 2016), so you should set the RDP service settings using Group Policies.
- Open the local GPO editor on the remote host: Win + R > gpedit.msc;
- Navigate to the following GPO section: Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections;
- Enable the policy parameter named Allow users to connect remotely using Remote Desktop Services (if this policy is disabled, the remote user will not be able to connect to this computer using Remote Desktop Services);
- Also, check if the Remote Desktop Services do not limit the number of simultaneous connections to the server. A maximum number of RDP connections can be specified in the section Connections using the policy Limit number of connections. Set unlimited connections by specifying 999999 in the option RD Maximum Connections allowed;
Use the netstat command to verify if TCP port 3389 is in the Listening state. Open a command prompt as administrator, and execute the command:
netstat -a -o|find "LIST"
As you can see, in our example, port 3389 is listening.
TCP 0.0.0.0:3389 DESKTOP-JOPF9:0 LISTENING 1096
Try to restart the Remote Desktop Services service. You can perform this action using the services.msc console or with the following command in the elevated PowerShell prompt:
get-service TermService| Restart-Service -force -Verbose
Check RDP Port and Windows Firewall Settings
In some cases, the administrator can change the RDP port number from default 3389 to something else (although Microsoft does not recommend this). To check the current port on which the Remote Desktop service is listening on the computer, open the registry editor (regedit.exe), and go to the registry key:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp
Note the value of the PortNumber REG_DWORD parameter. It indicates the current TCP port assigned to the RDP service. In our example, this is 3389 (d3d hexadecimal value). If you have a different port, you can change it to 3389 (in decimal), and restart the computer.
You can check the current Remote Desktop listening port number using PowerShell:
Get-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp' -name "PortNumber"
In order to check the RDP port on a remote computer, use the Invoke-Command command:
Invoke-Command -ComputerName computername1 {Get-ItemProperty -Path HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp -Name PortNumber | select PortNumber}
If a non-standard port is configured for Remote Desktop on a remote computer, you must specify the port number separated by a colon when connecting to the computer through the Remote Desktop Connection client. For example, rdp_server_name1:3320.
Also, check that the rule which allows incoming RDP connections is enabled in the Windows Defender Firewall settings.
- To do this, go to the Control Panel > System and Security > Windows Defender Firewall;
- Press the “Allow an app or feature through Windows Defender Firewall” > Change Settings;
- Find the Remote Desktop rule, and make sure it is enabled for Private and Public networks.
Hint. You can enable the built-in firewall rule for the Remote Desktop Service running on port TCP/3389 using PowerShell:
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
If this built-in firewall rule is missing, you can create a new one:
New-NetFirewallRule -DisplayName "AllowRDP_connection" -Direction Inbound -Protocol TCP –LocalPort 3389 -Action Allow
Check your network connection profile. You may encounter various RDP connection errors if a Public profile is configured for your network location. Try changing it to Private.
You can change the network location using the Control Panel (Network and Internet > Status > Connection Properties), or with PowerShell.
Get current network profile:
Get-NetConnectionProfile
Change network connection profile to Private:
Set-NetConnectionProfile -InterfaceIndex 14 -NetworkCategory Private
If you use a third-party firewall or antivirus, make sure it does not block incoming RDP connections. You can temporarily disable your antivirus software.
Next, check your network connection properties. Verify if the network connection status is set to Public. Change it from Private to Public if needed (Settings > Network & Internet > Status > Network status > Change connection properties).
In some cases, you need to try resetting the winsock and IP stack settings for the network adapter on the remote computer. Open a command prompt with administrator rights and run the commands:
netsh winsock reset netsh int ip reset ipconfig /release ipconfig /renew ipconfig /flushdns
In Windows 10, there is a special option to reset network settings in Settings > Network and Internet > Status > Network reset.
After resetting the network settings, you need to reboot Windows.
RDP This computer can’t connect to the remote computer: a possible cause
Another possible cause of the RDP error may be a high level of security, which is not supported by older versions of the RDP client.
In this case, open the General tab on the RDP-Tcp properties window, and change the Security layer from default Negotiate to less secure RDP Security Layer.
Tip. Snap-in tsadmin.msc and RDP-Tcp Properties dialog boxes are missing in Windows Server 2019/2016 and 2012 R2. But you can configure the Remote Desktop setting using the local Group Policy Editor (gpedit.msc). The necessary policies are located in the following GPO section: Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.
RDP security level can be specified using the policy named Require user of specific security layer for remote (RDP) connections. Enable this policy, and in the dropdown menu select the RDP Security level. This will change the Remote Desktop security layer from the default Negotiate to the less secure RDP.
Save the changes, update local GPO settings using the “gpupdate /force” command, and restart the Remote Desktop Service:
net stop TermService && net start TermService
RemoteApp Disconnected: Can’t Connect to the Remote Computer
In some cases, when connecting with Windows 10 to a remote desktop on Remote Desktop Gateway on Windows 2012 R2, an error occurs:
RemoteApp Disconnected
Your computer can’t connect to the remote computer because an error occurred on the remote computer that you want to connect to. Contact your network administrator for assistance.
To fix this problem, you need to perform the following steps on the RDP client:
- Open the Registry Editor (regedit.exe);
- Go to the registry key HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server Client;
- Create a DWORD parameter with the name RDGClientTransport and the value 1;
- Restart the computer.
The RDGClientTransport parameter forces the clients to use the RPC/HTTP connections instead of HTTP/UDP to connect to the server.
If the above solution didn’t fix the RDP connection error, try to change the collection settings on the RDSH server side. Open properties of your problematic application collection, go to the Security tab, and uncheck the option “Allow connections only from computers running Remote Desktop with Network Level Authentication”.
If the RemoteApp Disconnected error occurs on only a single not-domain joined computer, it is possible, that the different LAN Manager/NTLM policy settings are used on the RDSH host and the desktop computer. Often, this can cause authentication problems.
Check current Network Security: LAN Manager authentication level policy settings on RSDH using the command gpresult /r c:tmpgpreport.html (inspect html file) or using rsop.msc (this policy is located in the section Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options). If LM and NTLMv1 protocols are disabled on your RDSH server (Send NTLMv2 Response only policy value), you must change the appropriate policy settings on the client side.
- To do this, open the local GPO editor (gpedit.msc);
- Go to the GPO section above;
- Enable the policy “Network Security: LAN Manager authentication level”, and set its value to Send NTLMv2 Response only;
- Update the policies on the client with the gpupdate command;
- Check your RemoteApp connection.
Fix: Can’t Connect to the Remote Desktop Gateway Server
There is another error related to Remote Desktop Gateway which is used to deliver RemoteApps to users:
RemoteApp Disconnected.
Your computer can’t connect to the remote computer because the Remote Desktop Gateway server address is unreachable or incorrect. Type a valid Remote Desktop Gateway server address.
This error looks like this:
Your computer can’t connect to the remote computer because the Remote Desktop Gateway server is temporarily unavailable. Try reconnecting later or contact your network administrator for assistance.
If you are facing one of the errors above, then, most likely, the problem is that your computer can’t resolve the public FQDN name of your Remote Desktop Gateway server. In some cases, the public RDGW name can’t match the hostname.
To fix this problem:
- Open the Internet Information Services (IIS) Manager on the Remote Desktop Gateway server;
- Go to the IIS section Sites > Default Website > RDWeb > Pages > Application Settings;
- For the DefaultTSGateway value, enter the server’s FQDN public name of your RD Gateway server, and then restart the web services with the command:
iisreset
Also, check your RDGW certificate. Your certificate must not be expired.
You can find your SSL certificate info by going to Server Manager > Remote Desktop Services > Collections > Your_Collection > Tasks > Edit Deployment Properties > Certificates > RD Gateway > View Details. Check the certificate expiration date.
Go back to your client’s PC, and try to start a new RDP session. The connection should be established successfully.
Remote Desktop Connection: Error Code 0x904, Extended Error Code: 0x7
In modern versions of Windows 10/11 and Windows Server 2016/2019/2022, you may encounter another common RDP connection error:
Remote Desktop Connection
This computer can’t connect to the remote computer.
Try connecting again.
Error Code: 0x904
Extended Error Code: 0x7
Most often, when connecting to RDP, an error 0x904 appears on an unstable network connection (not enough bandwidth, packages lost, mismatch encryption cyphers, etc.), or when your VPN connection to a corporate network is too slow. Try to reconnect to your VPN workspace or change your ISP.
- About
- Latest Posts
I enjoy technology and developing websites. Since 2012 I’m running a few of my own websites, and share useful content on gadgets, PC administration and website promotion.
Рассмотрим вопрос делегирования полномочий пользователю конфигурации узла сеансов удаленных рабочих столов Windows Server 2012-2019. Эта задача в Windows Server 2008 решалась во вкладке «Безопасность» свойств подключения «RDP-TCP» консоли «Конфигурация узла сеансов удаленных рабочих столов». Начиная с Windows Server 2012 R2 такой консоли нет, соответственно, подход к настройке делегирования полномочий изменился.
С использованием PowerShell и поставщика инструментария управления Windows (WMI) служб удаленных рабочих столов Windows Server 2012-2019 это можно сделать.
Первым делом необходимо создать новую группу, локальную на сервере, либо в домене, в которую будут входить пользователи с делегированными полномочиями. На каждом сервере с ролью узла сеансов удаленных рабочих столов(RDSH) необходимо выполнить следующую команду (в cmd с правами локального администратора — этим мы задаем пользовательские права для группы):
для локальной группы на сервере
wmic /namespace:\rootCIMV2TerminalServices PATH Win32_TSPermissionsSetting WHERE (TerminalName ="RDP-Tcp") CALL AddAccount "servergroup",1
для доменной группы
wmic /namespace:\rootCIMV2TerminalServices PATH Win32_TSPermissionsSetting WHERE (TerminalName ="RDP-Tcp") CALL AddAccount "Domaingroup",1
Обозначения:
- server — имя вашего локального сервера;
- Domain — имя вашего домена;
- group — имя созданной группы.
После выполнения этих команд, пользователи получат разрешения (см. приложение 1 ниже).
В PowerShell мы задаем пользовательские права для группы:
(Get-WmiObject Win32_TSAccount -Namespace rootCIMV2TerminalServices -Filter "TerminalName='RDP-Tcp' AND Accountname='server\group'").ModifyPermissions(X,Y)
Не забываем:
- server\group — меняем на свои;
- вместо X — нужный номер параметра, который хотите разрешить (см. приложение 1);
- вместо Y : 0 — запрещает действие ;1 — разрешает действие .
Например:
- ModifyPermissions(2,1) — Разрешить выход пользователя из сеанса;
- ModifyPermissions(7,1) — Разрешить отправку сообщения через msg;
- ModifyPermissions(9,1) — Разрешить отключение сеанса пользователя.
Приложение 1.
Запрос сведений о сеансах и серверах Узел сеансов удаленных рабочих столов (Query
Information) = 0.
Настройка свойств подключения (Set Information) = 1.
Просмотр или активное управление сеансом другого пользователя (Remote Control) = 4.
Вход в сеанс на сервере Узел сеансов удаленных рабочих столов (Logon) = 5.
Выход пользователя из сеанса (Logoff) = 2.
Отправка сообщения сеансу пользователя (Message) = 7.
Подключение к сеансу другого пользователя (Connect) = 8.
Отключение сеанса пользователя (Disconnect) = 9.
Использование в сеансе виртуального канала, обеспечивающего перенаправление локальных устройств и ресурсов (Virtual Channels) = 3.
После применения всех параметров возможно потребуется перезагрузить сервер.
Нужна помощь? Настройки Windows Server мы осуществляем в рамках услуги ИТ-аутсорсинг. Также возможны разовые проектные работы.