Изменение параметров приложения RemoteApp
Каждое приложение RemoteApp имеет ряд ключевых опций, которые можно изменить в соответствии с требованиями. Для того, чтобы зайти в меню настроек приложения достаточно в окне коллекции сеансов (в данном случае в окне Коллекция сеансов RDS) на панели Удалённые приложения RemoteApp вызвать контекстное меню приложения, параметры которого необходимо изменить, и там выбрать единственный пункт Изменить свойства.
На вкладке Общие окна свойств приложения доступны следующие настройки:
Кроме настроек, в данном окне отображается информация о пути размещения приложения, его псевдониме и иконке.
Папку удалённого приложения RemoteApp можно либо задать вручную, написав в соответствующем поле желаемое имя папки, либо выбрав из существующего списка, если папки были созданы ранее.На вкладке Параметры можно задать параметры командной строки для приложения. Именно здесь можно разрешить использовать любые параметры командной строки или вообще запретить их использование. Помимо этого можно задать принудительное использование заранее заданных параметров.
Свойства вкладки Назначение пользователей позволяют настроить видимость приложения в системе веб-доступа для заданных пользователей или групп пользователей. Поскольку по умолчанию все пользователи коллекции сеансов имеют доступ ко всем опубликованным в ней приложениям, данная вкладка позволяет гибко настроить доступ пользователей к приложениям RemoteApp внутри самой коллекции.
На вкладке Сопоставление типов файлов можно задать типы файлов, которые автоматически будут открываться с помощью выбранного приложения RemoteApp.
Следует помнить об одном очень важном ограничении — данная опция не работает в случае веб-доступа к приложениям
Установка ролей классическим методом
Откройте диспетчер серверов. в правом верхнем углу есть кнопка «Управление», с ее помощью вы легко сможете установить любую серверную роль или компонент в Windows Server 2019.
У вас откроется окно «Выбор типа установки», тут вы можете установить локально или VDI, оставляем первый пункт и жмем «далее».
Следующим шагом будет выбор сервера для установки, это может быть локальный или удаленный, очень часты сценарии, когда например создают RDS-ферму, скажем так из 15 участников, и из одной установки в диспетчере серверов, производят инсталляцию роли сразу на все сервера, экономя время.
На следующем окне вы увидите доступные роли, которые можно устанавливать в Windows Server 2019, как я и говорил их тут 20:
- DHCP-сервер
- DNS-сервер — сервер разрешения имен
- Hyper-V — для виртуализации
- Аттестация работоспособности устройств
- Веб-сервер IIS — организация инфраструктуры веб-приложений
- Доменные службы Active Directory — создание домена на предприятии
- Служба опекуна узла — служба Guardian аттестация и защита ключей, для экранированных виртуальных машин
- Службы Active Directory облегченного доступа к каталогам
- Службы Windows Server Update Services (WSUS)
- Службы активации корпоративных лицензий
- Службы печати и документов
- Службы политики сети и доступа — NPS-сервер
- Службы развертывания Windows — WDS-сервер
- Службы сертификатов Active Directory
- Службы удаленных рабочих столов
- Службы управления правами Active Directory — RMS-сервер
- Службы федерации Active Directory
- Удаленный доступ
- Файловые службы и службы хранилища
- Факс-сервер
В своем примере я установлю роль «Веб-сервер IIS», выделяю его галкой. У вас появится дополнительное окно «добавить компоненты, необходимые для Веб-сервер (IIS)» и будет их список, нажимаем добавить и далее.
Далее будет окно с выбором компонентов, которые в большинстве случаев можно устанавливать совместно с ролями, но бывают моменты, когда они могут конфликтовать и их нужно разделять. Для примера я выделил Telnet Client и нажимаю далее.
Далее вам приведут общую информацию, что будет поставлена IIS 10 с ASP.NET, идем дальше.
После этого вы можете, как в комбайне, добавить нужное количество дополнительных служб ролей, просто выставив соответствующие галки, я оставлю стандартно.
Последний этап попросит от вас просто нажать соответствующую кнопку «Установить».
Начнется процесс установки роли
Установка роли успешно выполнена, можно закрывать окно.
Открыв диспетчер серверов, вы можете увидеть добавленную роль.
Remote Desktop Services High Availability на Windows Server 2019
Обновлено 03.08.2020
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами разобрали ситуацию, когда ваш жесткий диск виделся в формате RAW и не позволял получить доступ к данным, мы это благополучно решили. Сегодня мы рассмотрим задачу установки отказоустойчивой терминальной фермы Remote Desktop Services, где посредники подключений (RD Connection Broker) работают в режиме высокой доступности (High Availability) и все это дело будет работать на Windows Server 2019 в связке с хостами подключений (RDSH) на базе Windows Server 2016. Давно хотелось у себя на сайте иметь такую инструкцию, тем более что давно стояла задача перехода с W2012R2.
Постановка задачи
Необходимо организовать высоко доступную ферму RDS (Remote Desktop Services), где в качестве брокеров подключения будут выступать операционные системы с Windows Server 2019. В качестве хостов подключений, на которых будут работать конечные пользователи требуется иметь операционную систему Windows Server 2016. Развернуть сервер лицензирования, раздающий лицензии на пользователя или устройства. Чем хорошо использовать в качестве посредников подключений именно Windows Server 2019, все просто, когда большинство клиентского программного обеспечения станет поддерживаться данной ОС, можно будет легко вывести из эксплуатации сервера с W2016 и заменить их на более новые.
Вопрос
Может ли сервер лицензирования RD выдавать лицензию клиентского доступа (CAL) пользователям или устройствам, подключенным к серверам RD Session Host (Terminal Server) при любых следующих условиях?
- Хост-серверы сеансов RD находятся в домене Active Directory, а сервер лицензирования RD находится в рабочей группе.
- Серверы хост-серверов сеансов RD находятся в рабочей группе и сервер лицензирования RD в домене Active Directory.
- Хост-серверы сеансов RD и сервер лицензирования RD находятся в разных лесах. Между этими лесами нет доверия (в одну или две стороны).
- Серверы RD Session Host и серверы лицензирования RD находятся в одной рабочей группе.
Вторая программа — Duo Authentication for Windows Logon and RDP
это инструмент для мультифакторной аутентификации от Duo Security (Cisco), коммерческий многофункциональный продукт, который безупречно работает и позволяет использовать смартфоны, токены и коды для 2FA.
Настраивается ПО немного сложнее предыдущей программы, но благодаря хорошей документации от разработчика довольно таки быстро.
-
Зарегистрируйте себе административный аккаунт, для доступа к панели управления (Личный кабинет). Рекомендуем сразу добавить еще одного администратора, потому как восстановить доступ с помощью разработчика довольно таки проблематично, а прецеденты с неожиданной утратой смартфона администратора возникают часто.
-
Войдите в панель администратора Duo и перейдите в Приложения (Applications).
-
Нажмите «Защитить приложение» и найдите в списке приложений запись для Microsoft RDP. Щелкните Защитить в крайнем правом углу, чтобы настроить приложение и получить ключ интеграции, секретный ключ и имя хоста API. Эта информация понадобится вам для завершения настройки (в процессе установки Duo Authentication for Windows Logon).
Мы рекомендуем установить политики по умолчанию для новых пользователей приложения Microsoft RDP значение «Запрет доступа», поскольку ни один незарегистрированный в Duo пользователь не должен успешно проходить авторизацию. Но для этого вам будет необходимо добавить всех пользователей в Duo через панель управления вручную или, что намного удобнее, через импорт из Active Directory (об этом расскажем позже) и выслать им ссылку для активации приложения Duo Security, предварительно установленному на их смартфонах.
4. Загрузите и установите пакет установщика Duo Authentication for Windows Logon. Во время установки введите данные, полученные на предыдущем шаге.
Если вы хотите включить автономный доступ с помощью Duo MFA, вы можете сделать это сейчас в разделе «Настройки автономного доступа» на странице приложения Duo или вернуться в панель администратора позже, чтобы настроить автономный доступ после первой проверки успешного входа в систему с помощью двух-факторной аутентификации.
Также во время установки рекомендуем установить все 3 галки в чекбоксах — эти настройки позволят вам получать доступ в ОС без 2FA, например при использовании консоли гипервизора или при отсутствии подключения к серверам Duo (частый случай — большое расхождение по времени):
Теперь при подключении и успешной авторизации (по логину и паролю) пользователю будет отправлено Push уведомление на смартфон с активированным приложением Duo Mobile:
Если на смартфоне нет доступа в Интернет (и соответственно Push приходить не будут), то можно подтвердить авторизацию сгенерированным кодом (Passcode ) из приложения:
Настройка синхронизации пользователей с глобальным каталогом (Azure AD — Active Directory — LDAP) хорошо описана в документации разработчика, хочу лишь уточнить что это платный функционал. Основной компонент для синхронизации пользователей, это — ПО, которое обеспечивает подключение к каталогу.
Если вы используете RDWEb (клиентский доступ или шлюз), то вам пригодится еще один компонент — Duo Authentication for Microsoft Remote Desktop Web. Настройка его аналогична Duo Authentication for Windows Logon и не должна вызвать затруднений.
Подводя итоги заметим, что рассмотренное ПО не является панацеей от всех бед для публичных сервисов (доступных из сети Интернет), потому как бывают уязвимости, эксплуатация которых позволяет злоумшленникам обходить даже такие меры по обеспечению безопасности ОС\инфраструктуры в целом. Поэтому требуется всегда комплесно подходить к этому вопросу — мониторинг, аудит и регламентные процедуры по обновлению позволят вам почувствовать себя защищенными в этом неспокойном мире. Берегите свои данные!
Как настроить remoteapp в windows server 2019
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами разобрали ситуацию, когда ваш жесткий диск виделся в формате RAW и не позволял получить доступ к данным, мы это благополучно решили. Сегодня мы рассмотрим задачу установки отказоустойчивой терминальной фермы Remote Desktop Services, где посредники подключений (RD Connection Broker) работают в режиме высокой доступности (High Availability) и все это дело будет работать на Windows Server 2019 в связке с хостами подключений (RDSH) на базе Windows Server 2016. Давно хотелось у себя на сайте иметь такую инструкцию, тем более что давно стояла задача перехода с W2012R2.
Постановка задачи
Необходимо организовать высоко доступную ферму RDS (Remote Desktop Services), где в качестве брокеров подключения будут выступать операционные системы с Windows Server 2019. В качестве хостов подключений, на которых будут работать конечные пользователи требуется иметь операционную систему Windows Server 2016. Развернуть сервер лицензирования, раздающий лицензии на пользователя или устройства. Чем хорошо использовать в качестве посредников подключений именно Windows Server 2019, все просто, когда большинство клиентского программного обеспечения станет поддерживаться данной ОС, можно будет легко вывести из эксплуатации сервера с W2016 и заменить их на более новые.
Консоли администрирования ролей в клиентских Windows
Добрый день уважаемые читатели и гости блога, продолжаем наши уроки по системному администрирования. Задачей любого администратора, по мимо организации безотказной работы сервисов, является организация удобной среды администрирования. Если мы говорим про Windows платформы, то там сервера запускают сервисы, посредством серверных ролей, для администрирования которых используются mmc оснастки, расположенные на сервере, но согласитесь, что не совсем удобно для, того чтобы, что то подправить или проверить на сервере, нужно на него заходить и открывать оснастку там, удобнее было бы открывать ее на привычном, своем компьютере, на котором может стоять Windows 7 или Windows 8.1. Проблема в том, что данные серверные оснастки там в комплекте не идут и их нужно до устанавливать, сегодня я расскажу как их установить с помощью пакета RSAT, для клиентских версий Windows.
И так задача перед нами стоит такая, нужно на клиентской, рабочей станции администратора, сделать возможным запускать серверные оснастки, для примера:
- Active Directory – Пользователи и компьютеры
- DNS
- WSUS
Что хорошо, их потом можно будет включать в единую консоль управления Windows серверами, о которой я рассказывал. Для установки оснасток ролей Windows, нам потребуется дополнительный пакет обновлений под названием RSAT (Remote Server Administration Tools) или как в России средства удаленного администрирования сервера. Он скачивается и устанавливается отдельно на клиентскую версию операционной системы, для расширения ее возможностей, а точнее компонентов системы.
Какие оснастки добавляет RSAT
Давайте я приведу список оснасток, которые добавляются при установке RSAT:
- Диспетчер сервера > RemoteServerAdministrationTools-ServerManager
- Клиент управления IP адресами (IPAM) > RemoteServerAdministrationTools-Features-IPAM
- Средство балансировки сетевой нагрузки > RemoteServerAdministrationTools-Features-LoadBalancing
- Средства объединения сетевых карт > RemoteServerAdministrationTools-Features-NICTeaming
- Средства отказоустойчивой кластеризации > RemoteServerAdministrationTools-Features-Clustering
- Средства управления групповыми политиками > RemoteServerAdministrationTools-Features-GP
- Средство просмотра пароля восстановления Bitlocker > RemoteServerAdministrationTools-Features-BitLocker
- Модуль Active Directory для power shell > RemoteServerAdministrationTools-Roles-AD-Powershell
- Оснастки и программы командной строки AD DS > RemoteServerAdministrationTools-Roles-AD-DS
- Средства сервера для NIS > RemoteServerAdministrationTools-Roles-AD-DS-NIS
- Центр администрирования Active Directory > RemoteServerAdministrationTools-Roles-AD-DS-AdministrativeCenter
- Средства активации корпоративных лицензий > RemoteServerAdministrationTools-Roles-VA
- Средства серверов DHCP > RemoteServerAdministrationTools-Roles-DHCP
- Средства серверов DNS > RemoteServerAdministrationTools-Roles-DNS
- Средства серверов WSUS > RemoteServerAdministrationTools-Roles-WSUS
- Средства служб сертификации Active Directory > RemoteServerAdministrationTools-Roles-CertificateServices
- Средства сетевого ответчика > RemoteServerAdministrationTools-Roles-CertificateServices-OnlineResponder
- Средства центра сертификации > RemoteServerAdministrationTools-Roles-CertificateServices-CA
- Средства служб удаленных рабочих столов > RemoteServerAdministrationTools-Roles-RDS
- Средства диагностики лицензирования удаленных рабочих столов > RemoteServerAdministrationTools-Roles-RDS-LicensingDiagUI
- Средства лицензирования удаленных рабочих столов > RemoteServerAdministrationTools-Roles-RDS-LicensingUI
- Средства шлюзов удаленных рабочих столов > RemoteServerAdministrationTools-Roles-RDS-Gateway
- Средства управления удаленным доступом > RemoteServerAdministrationTools-Roles-RemoteAccess
- Средства файловых служб > RemoteServerAdministrationTools-Roles-FileServices
- Средства администрирования NFS > RemoteServerAdministrationTools-Roles-FileServices-Nfs
- Средства диспетчера ресурсов файлового сервера > RemoteServerAdministrationTools-Roles-FileServices-Fsrm
- Средства распределенной файловой системы > RemoteServerAdministrationTools-Roles-FileServices-Dfs
- Средства управления общими ресурсами и хранилищем > RemoteServerAdministrationTools-Roles-FileServices-StorageMgmt
Несколько терминальных серверов и dns round robin
При наличие нескольких серверов терминалов, мы можем создать несколько записей в DNS, чтобы получать по round robin разные серверы:
Однако, при попытке подключиться к незарегистрированному серверу мы увидим ошибку:
Для решения переходим в настройку шлюза — кликаем правой кнопкой по Политики авторизации ресурсов и выбираем Управление локальными группами компьютеров:
Выбираем нужную группу компьютеров и нажимаем Свойства:
* в моем случае это была единственная группа, созданная по умолчанию.
На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:
Теперь подключение будет выполняться без ошибок.
Process of deploying RDS service roles
The process of deploying RDS service roles on a single workgroup server or DC differs from that of deploying a standard RDS configuration on multiple computers.
Unless otherwise noted, these steps apply to both workgroup computer and DC cases.
Important
If you are using a single computer as both the RDS server and as a DC, configure the computer as a DC before you begin installing the RDS roles. For more information about how to install Active Directory Domain Services (AD DS) and configure the computer as a DC in Windows Server 2016 or Windows Server 2012, see Install Active Directory Domain Services (Level 100).
-
On the workgroup computer or DC, install the Remote Desktop Licensing role service and the Remote Desktop Session Host role service. To do this, follow these steps:
- Open Server Manager.
- Click Manage and select Add Roles and Features.
- Select Role-based or Feature-based installation.
- Select the computer as the destination server.
- On the Select server roles page, select Remote Desktop Services.
- On the Select role services page, select the Remote Desktop Licensing and Remote Desktop Session Host role services.
- Continue the installation. Select default values for the remaining settings.
-
DC step: Open Remote Desktop Licensing Manager, right-click the server, and then select Review Configuration.
-
Select Add to group.
Note
If you have to manage group memberships manually, the Terminal Server License Servers group is located in the Built-in container in Active Directory Users and Computers.
-
Restart the Remote Desktop Services service.
-
Use one of the following methods to activate the RDS license server:
- To activate a Windows Server 2012 RDS license server, see .
- To activate a Windows Server 2016 RDS license server, see Activate the Remote Desktop Services license server.
-
Install the appropriate RDS CALs.
Important
If you are using a workgroup server, you must use per-device CALs. For more information, see License your RDS deployment with client access licenses (CALs). For more information about how to install RDS CALs, see Install Remote Desktop Services Client Access Licenses.
-
Add the users that you want to allow to connect to the Remote Desktop Users group. To do this, use the following tools:
- To find the Remote Desktop Users group on a DC, open Active Directory Users and Computers and navigate to the Builtin container.
- To find the Remote Desktop Users group on a workgroup server, open Computer Management and then navigate to Local Users and Groups\Groups.
-
Change the local policy of the computer to add your remote desktop users to the Allow logon through Remote Desktop Services local policy object. To do this, follow these steps:
- Open Local Security Policy.
- Navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.
- Double-click Allow log on through Remote Desktop Services, and then select Add User or Group.
- Type Remote Desktop Users (or the user names of each user account that you want to add, separated by semicolons), and then select OK two times.
-
Configure the Remote Desktop Session Host role service to use the local RDS license server.
Important
Before you begin this procedure, make sure that the RDS license server is activated.
To do this, follow these steps:
-
Open an elevated Windows PowerShell Command Prompt window.
-
Run the following command:
-
To set the licensing mode, run the following command:
Note
In this command, <value> represents the licensing mode and is either 2 (if you are using per-device licensing) or 4 (if you are using per-user licensing). If you are using a workgroup server, you must use 2.
-
Run the following command:
-
To verify the settings, run the following command:
You should see the RDS licensing server name in the output. After you finish this step, users can start remote desktop sessions by using any supported RDS client.
-
-
DC step: To enable printer redirection to function correctly on a DC that is acting as the RDSH host, follow these additional steps.
-
Open an elevated Command Prompt window.
-
Run the following commands:
-
Restart the computer.
-
Поддержка ускорения с помощью графического процессора (GPU)
Службы удаленных рабочих столов поддерживают системы, оснащенные графическими процессорами. Приложения, которым требуется GPU, можно использовать через удаленное подключение. Кроме того, можно включить ускорение отрисовки и кодирования с помощью GPU, чтобы повысить производительность и улучшить масштабируемость приложений.
Узлы сеансов служб удаленных рабочих столов и односеансовые клиентские операционные системы поддерживают возможности физических или виртуальных графических процессоров, представляемых в операционной системе различными способами. Сюда входят размеры виртуальных машин, оптимизированных для Azure GPU; GPU, доступные для физического сервера RDSH; GPU, предоставляемые виртуальным машинам поддерживаемыми гипервизорами.
Чтобы узнать, что вам нужно, см. раздел Какие технологии виртуализации графики подходят вам?. Узнайте подробные сведения о DDA в Плане развертывания дискретного назначения устройств.
Поставщики GPU могут применять отдельную схему лицензирования для сценариев узлов сеансов удаленных рабочих столов или ограничивать использование GPU в серверных ОС. Ознакомьтесь с требованиями выбранного поставщика.
Графические процессоры, представленные гипервизорами или облачной платформой сторонних производителей, должны иметь драйверы с цифровой подписью WHQL, предоставляемые соответствующими поставщиками.
Поддержка GPU узлами сеансов удаленных рабочих столов
В следующей таблице приведены сценарии, в которых возможно применение различных версий узлов RDSH.
Функция | Windows Server 2008 R2 | Windows Server 2012 R2 | Windows Server 2016 | Windows Server 2019 |
---|---|---|---|---|
Использование аппаратного GPU для всех сеансов RDP | Нет | Да | Да | Да |
Аппаратное кодирование H.264/AVC (если поддерживается GPU) | Нет | Нет | Да | Да |
Балансировка нагрузки между несколькими GPU, предоставленными операционной системе | Нет | Нет | Нет | Да |
Оптимизация кодирования H.264/AVC для минимизации использования пропускной способности | Нет | Нет | Нет | Да |
Поддержка кодирования H.264/AVC для разрешения 4K | Нет | Нет | Нет | Да |
Поддержка VDI для GPU
В следующей таблице описывается поддержка применения GPU в клиентской операционной системе.
Функция | Windows 7 с пакетом обновления 1 (SP1) | Windows 8.1 | Windows 10 |
---|---|---|---|
Использование аппаратного GPU для всех сеансов RDP | Нет | Да | Да |
Аппаратное кодирование H.264/AVC (если поддерживается GPU) | Нет | Нет | Windows 10 (сборка 1703) и более поздние версии |
Балансировка нагрузки между несколькими GPU, предоставленными операционной системе | Нет | Нет | Windows 10 (сборка 1803) и более поздние версии |
Оптимизация кодирования H.264/AVC для минимизации использования пропускной способности | Нет | Нет | Windows 10 (сборка 1803) и более поздние версии |
Поддержка кодирования H.264/AVC для разрешения 4K | Нет | Нет | Windows 10 (сборка 1803) и более поздние версии |
Поддержка 3D-видеоадаптера RemoteFX (vGPU)
Примечание
Из соображений безопасности процессор RemoteFX vGPU по умолчанию отключен для всех версий Windows, начиная с обновления для системы безопасности за 14 июля 2020 г., и удален, начиная с обновления для системы безопасности за 13 апреля 2021 г. См. KB 4570006.
Службы удаленных рабочих столов поддерживают процессоры vGPU RemoteFX, когда виртуальная машина работает в качестве гостевой виртуальной машины Hyper-V в Windows Server 2012 R2 или Windows Server 2016. В следующих гостевых операционных системах поддерживается vGPU RemoteFX:
- Windows 7 с пакетом обновления 1 (SP1)
- Windows 8.1
- Windows 10 (сборка 1703) или более поздней версии
- Windows Server 2016 (только односеансовое развертывание)
Поддержка дискретного назначения устройств
Службы удаленных рабочих столов поддерживают физические GPU, предоставляемые с помощью дискретного назначения устройств с узлов Hyper-V Windows Server 2016 или Windows Server 2019. Дополнительные сведения см. в разделе Планирование развертывания устройств с помощью дискретного назначения устройств.
Best practices
-
Use Windows Server 2019 for your Remote Desktop infrastructure (the Web Access, Gateway, Connection Broker, and license server). Windows Server 2019 is backward-compatible with these components, which means a Windows Server 2016 or Windows Server 2012 R2 RD Session Host can connect to a 2019 RD Connection Broker, but not the other way around.
-
For RD Session Hosts — all Session Hosts in a collection need to be at the same level, but you can have multiple collections. You can have a collection with Windows Server 2016 Session Hosts and one with Windows Server 2019 Session Hosts.
-
If you upgrade your RD Session Host to Windows Server 2019, also upgrade the license server. Remember that a 2019 license server can process CALs from all previous versions of Windows Server, down to Windows Server 2003.
-
Follow the upgrade order recommended in .
-
If you are creating a highly available environment, all of your Connection Brokers need to be at the same OS level.
Support for graphics processing unit (GPU) acceleration
Remote Desktop Services support systems equipped with GPUs. Applications that require a GPU can be used over the remote connection. Additionally, GPU-accelerated rendering and encoding can be enabled for improved app performance and scalability.
Remote Desktop Services Session Hosts and single-session client operating systems can take advantage of the physical or virtual GPUs presented to the operating system in many ways, including the Azure GPU optimized virtual machine sizes, GPUs available to the physical RDSH server, and GPUs presented to the VMs by supported hypervisors.
See Which graphics virtualization technology is right for you? for help figuring out what you need. For specific information about DDA, check out Plan for deploying Discrete Device Assignment.
GPU vendors may have a separate licensing scheme for RDSH scenarios or restrict GPU use on the server OS, verify the requirements with your favorite vendor.
GPUs presented by a non-Microsoft hypervisor or Cloud Platform must have drivers digitally-signed by WHQL and supplied by the GPU vendor.
Remote Desktop Session Host support for GPUs
The following table shows the scenarios supported by different versions of RDSH hosts.
Feature | Windows Server 2008 R2 | Windows Server 2012 R2 | Windows Server 2016 | Windows Server 2019 |
---|---|---|---|---|
Use of hardware GPU for all RDP sessions | No | Yes | Yes | Yes |
H.264/AVC hardware encoding (if supported by the GPU) | No | No | Yes | Yes |
Load balancing between multiple GPUs presented to the OS | No | No | No | Yes |
H.264/AVC encoding optimizations for minimizing bandwidth usage | No | No | No | Yes |
H.264/AVC support for 4K resolution | No | No | No | Yes |
VDI support for GPUs
The following table shows support for GPU scenarios in the client OS.
Feature | Windows 7 SP1 | Windows 8.1 | Windows 10 |
---|---|---|---|
Use of hardware GPU for all RDP sessions | No | Yes | Yes |
H.264/AVC hardware encoding (if supported by the GPU) | No | No | Windows 10 1703 and later |
Load balancing between multiple GPUs presented to the OS | No | No | Windows 10 1803 and later |
H.264/AVC encoding optimizations for minimizing bandwidth usage | No | No | Windows 10 1803 and later |
H.264/AVC support for 4K resolution | No | No | Windows 10 1803 and later |
RemoteFX 3D Video Adapter (vGPU) support
Note
Because of security concerns, RemoteFX vGPU is disabled by default on all versions of Windows starting with the July 14, 2020 Security Update and removed starting with the April 13, 2021 Security Update. To learn more, see KB 4570006.
Remote Desktop Services supports RemoteFX vGPUs when VM is running as a Hyper-V guest on Windows Server 2012 R2 or Windows Server 2016. The following guest operating systems have RemoteFX vGPU support:
- Windows 7 SP1
- Windows 8.1
- Windows 10 1703 or later
- Windows Server 2016 in a single-session deployment only
Discrete Device Assignment support
Remote Desktop Services supports Physical GPUs presented with Discrete Device Assignment from Windows Server 2016 or Windows Server 2019 Hyper-V hosts. See Plan for deploying Discrete Device Assignment for more details.
Особый порт для подключения
По умолчанию, для подключения к терминальному серверу по RDP используется порт 3389. Если необходимо, чтобы сервер слушал на другом порту, открываем реестр, и переходим в ветку:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Находим ключ PortNumber и задаем ему значение в десятично представлении, равное нужному номеру порта:
Также можно применить команду:
reg add «HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp» /v PortNumber /t REG_DWORD /d 3388 /f
* где 3388 — номер порта, на котором будет принимать запросы терминальный сервер.
Single sign-on
Windows Server 2016 and Windows Server 2019 RDS supports two main SSO experiences:
- In-app (Remote Desktop application on Windows, iOS, Android, and Mac)
- Web SSO
Using the Remote Desktop application, you can store credentials either as part of the connection info (Mac) or as part of managed accounts (, , Windows) securely through the mechanisms unique to each OS.
To connect to desktops and RemoteApps with SSO through the inbox Remote Desktop Connection client on Windows, you must connect to the RD Web page through Internet Explorer. The following configuration options are required on the server side. No other configurations are supported for Web SSO:
- RD Web set to Forms-Based Authentication (Default)
- RD Gateway set to Password Authentication (Default)
- RDS Deployment set to «Use RD Gateway credentials for remote computers» (Default) in the RD Gateway properties
Note
Due to the required configuration options, Web SSO is not supported with smartcards. Users who login via smartcards might face multiple prompts to login.
For more information about creating VDI deployment of Remote Desktop Services, check out Supported Windows 10 security configurations for Remote Desktop Services VDI.
Особый порт для подключения
По умолчанию, для подключения к терминальному серверу по RDP используется порт 3389. Если необходимо, чтобы сервер слушал на другом порту, открываем реестр, и переходим в ветку:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Находим ключ PortNumber и задаем ему значение в десятично представлении, равное нужному номеру порта:
Также можно применить команду:
reg add «HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp» /v PortNumber /t REG_DWORD /d 3388 /f
* где 3388 — номер порта, на котором будет принимать запросы терминальный сервер.
Настройка RemoteApp
Приложения RemoteApp представляют собой программы, удалённый доступ к которым предоставляется с помощью служб удалённых рабочих столов, но выглядят они так, будто это локальные приложения. Проще говоря, приложение RemoteApp представляет собой доступ к удалённому рабочему столу, ограниченному одним приложением. Однако, несмотря на формулировку выше, пользователь может запускать несколько приложений или несколько экземпляров одного и того же приложения в одном сеансе.
Следует помнить, что публикация хотя-бы одного приложения приведет к отмене публикации удалённого рабочего стола. Это означает, что в одной коллекции могут быть либо удалённый рабочий стол полностью либо некий набор отдельных приложений RemoteApp.
Публиковать можно как предустановленные приложения так и свои собственные. Попробуем опубликовать одно предустановленное (Калькулятор) Для этого необходимо отметить его и нажать кнопку Далее.
В следующем окне подтверждаем свой выбор нажав кнопку Опубликовать.
После публикации приложений RemoteApp, будет отображено окно в котором показано состояние приложений и ошибки, возникшие при установке. Если же ошибок не возникло, то нажимаем кнопку Закрыть, для завершения процесса публикации.
Регистрация оснасток Tsconfig.msc и Tsadmin.msc в Windows Server 2019
Теперь когда у вас есть все файлы необходимые для запуска и установки оснасток Tsconfig.msc и Tsadmin.msc, вы должны распаковать архив и положить файлы по тем же путям, приведу их сюда еще раз:
- c:\windows\system32\tsadmin.dll
- c:\windows\system32\tsconfig.dll
- c:\windows\system32\wts.dll
- c:\windows\system32\tsconfig.msc
- c:\windows\system32\tsadmin.msc
- c:\windows\system32\ru\tsconfig.resources.dll
- c:\windows\system32\ru\tsadmin.resources.dll
Далее вам необходимо на вашем сервере Windows Server 2019 запустить два ключа реестра, которые мы выгружали. При их запуске будет предупреждение, говорим «Да».
Файлы должны успешно импортироваться в реестр Windows.
Запрос назначений пользователей
Используйте командлет Get-RDPersonalSessionDesktopAssignment, чтобы получить список личных сеансовых рабочих столов и связанных учетных записей пользователей. Этот командлет поддерживает следующие параметры.
-CollectionName <строка>
-ConnectionBroker <строка>
-User <строка>
-Name <строка>
Вы можете выполнить этот командлет, чтобы выполнить запрос по имени коллекции, пользователя или сеансового рабочего стола. Если указать только параметр -CollectionName, то командлет возвращает список узлов сеансов и связанных с ними пользователей. Если также указать параметр -User, то будет возвращен узел сеансов, связанный с данным пользователем. Если указать параметр -Name, будет возвращен пользователь, связанный с этим узлом сеансов.
Командлет Export-RDPersonalPersonalDesktopAssignment экспортирует текущие связи между пользователями и личными виртуальными рабочими столами в текстовый файл. Этот командлет поддерживает следующие параметры.
-CollectionName <строка>
-ConnectionBroker <строка>
-Path <строка>
Все новые командлеты поддерживают общие параметры: -Verbose, -Debug, -ErrorAction, -ErrorVariable, -OutBuffer и -OutVariable. См. сведения в разделе about_CommonParameters.