Remote Desktop Services roles

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2019, Windows Server 2016

This article describes the roles within a Remote Desktop Services environment.

Remote Desktop Session Host

The Remote Desktop Session Host (RD Session Host) holds the session-based apps and desktops you share with users. Users get to these desktops and apps through one of the Remote Desktop clients that run on Windows, MacOS, iOS, and Android. Users can also connect through a supported browser by using the web client.

You can organize desktops and apps into one or more RD Session Host servers, called «collections.» You can customize these collections for specific groups of users within each tenant. For example, you can create a collection where a specific user group can access specific apps, but anyone outside of the group you designated won’t be able to access those apps.

For small deployments, you can install applications directly onto the RD Session Host servers. For larger deployments, we recommend building a base image and provisioning virtual machines from that image.

You can expand collections by adding RD Session Host server virtual machines to a collection farm with each RDSH virtual machine within a collection assigned to same availability set. This provides higher collection availability and increases scale to support more users or resource-heavy applications.

In most cases, multiple users share the same RD Session Host server, which most efficiently utilizes Azure resources for a desktop hosting solution. In this configuration, users must sign in to collections with non-administrative accounts. You can also give some users full administrative access to their remote desktop by creating personal session desktop collections.

You can customize desktops even more by creating and uploading a virtual hard disk with the Windows Server OS that you can use as a template for creating new RD Session Host virtual machines.

For more information, see the following articles:

Remote Desktop Connection Broker

Remote Desktop Connection Broker (RD Connection Broker) manages incoming remote desktop connections to RD Session Host server farms. RD Connection Broker handles connections to both collections of full desktops and collections of remote apps. RD Connection Broker can balance the load across the collection’s servers when making new connections. If RD Connection Broker is enabled, using DNS round robin to RD Session Hosts for balacing servers is not supported. If a session disconnects, RD Connection Broker will reconnect the user to the correct RD Session Host server and their interrupted session, which still exists in the RD Session Host farm.

You’ll need to install matching digital certificates on both the RD Connection Broker server and the client to support single sign-on and application publishing. When developing or testing a network, you can use a self-generated and self-signed certificate. However, released services require a digital certificate from a trusted certification authority. The name you give the certificate must be the same as the internal Fully Qualified Domain Name (FQDN) of the RD Connection Broker virtual machine.

You can install the Windows Server 2016 RD Connection Broker on the same virtual machine as AD DS to reduce cost. If you need to scale out to more users, you can also add additional RD Connection Broker virtual machines in the same availability set to create an RD Connection Broker cluster.

Before you can create an RD Connection Broker cluster, you must either deploy an Azure SQL Database in the tenant’s environment or create an SQL Server AlwaysOn Availability Group.

For more information, see the following articles:

Remote Desktop Gateway

Remote Desktop Gateway (RD Gateway) grants users on public networks access to Windows desktops and applications hosted in Microsoft Azure’s cloud services.

The RD Gateway component uses Secure Sockets Layer (SSL) to encrypt the communications channel between clients and the server. The RD Gateway virtual machine must be accessible through a public IP address that allows inbound TCP connections to port 443 and inbound UDP connections to port 3391. This lets users connect through the internet using the HTTPS communications transport protocol and the UDP protocol, respectively.

The digital certificates installed on the server and client have to match for this to work. When you’re developing or testing a network, you can use a self-generated and self-signed certificate. However, a released service requires a certificate from a trusted certification authority. The name of the certificate must match the FQDN used to access RD Gateway, whether the FQDN is the public IP address’ externally facing DNS name or the CNAME DNS record pointing to the public IP address.

For tenants with fewer users, the RD Web Access and RD Gateway roles can be combined on a single virtual machine to reduce cost. You can also add more RD Gateway virtual machines to an RD Gateway farm to increase service availability and scale out to more users. Virtual machines in larger RD Gateway farms should be configured in a load-balanced set. IP affinity isn’t required when you’re using RD Gateway on a Windows Server 2016 virtual machine, but it is when you’re running it on a Windows Server 2012 R2 virtual machine.

For more information, see the following articles:

Remote Desktop Web Access

Remote Desktop Web Access (RD Web Access) lets users access desktops and applications through a web portal and launches them through the device’s native Microsoft Remote Desktop client application. You can use the web portal to publish Windows desktops and applications to Windows and non-Windows client devices, and you can also selectively publish desktops or apps to specific users or groups.

RD Web Access needs Internet Information Services (IIS) to work properly. A Hypertext Transfer Protocol Secure (HTTPS) connection provides an encrypted communications channel between the clients and the RD Web server. The RD Web Access virtual machine must be accessible through a public IP address that allows inbound TCP connections to port 443 to allow the tenant’s users to connect from the internet using the HTTPS communications transport protocol.

Matching digital certificates must be installed on the server and clients. For development and testing purposes, this can be a self-generated and self-signed certificate. For a released service, the digital certificate must be obtained from a trusted certification authority. The name of the certificate must match the Fully Qualified Domain Name (FQDN) used to access RD Web Access. Possible FQDNs include the externally facing DNS name for the public IP address and the CNAME DNS record pointing to the public IP address.

For tenants with fewer users, you can reduce costs by combining the RD Web Access and Remote Desktop Gateway workloads into a single virtual machine. You can also add additional RD Web virtual machines to an RD Web Access farm to increase service availability and scale out to more users. In an RD Web Access farm with multiple virtual machines, you’ll have to configure the virtual machines in a load-balanced set.

For more information about how to configure RD Web Access, see the following articles:

Remote Desktop Licensing

Activated Remote Desktop Licensing (RD Licensing) servers let users connect to the RD Session Host servers hosting the tenant’s desktops and apps. Tenant environments usually come with the RD Licensing server already installed, but for hosted environments you’ll have to configure the server in per-user mode.

The service provider needs enough RDS Subscriber Access Licenses (SALs) to cover all authorized unique (not concurrent) users that sign in to the service each month. Service providers can purchase Microsoft Azure Infrastructure Services directly, and can purchase SALs through the Microsoft Service Provider Licensing Agreement (SPLA) program. Customers looking for a hosted desktop solution must purchase the complete hosted solution (Azure and RDS) from the service provider.

Small tenants can reduce costs by combining the file server and RD Licensing components onto a single virtual machine. To provide higher service availability, tenants can deploy two RD License server virtual machines in the same availability set. All RD servers in the tenant’s environment are associated with both RD License servers to keep users able to connect to new sessions even if one of the servers goes down.

For more information, see the following articles:

Remote recording windows server

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

Is Microphone support / available when i’m connect to Windows 7 and Windows XP from VDI Using RDS?

I can get speaker sound but when click on Microphone, it mentioned No audio detected.

Answers

First get audio recording working with a direct RDP connection to a VM, then go ahead and work on it working via RDWeb/RD Virtualization Host, if that is what you are using.

Connecting to a XP Pro VM is not going to work, since XP does not support audio recording redirection.

When connecting to a Windows 7 Enterprise VM (or physical PC, does not matter), please make sure that audio recording is enabled at the host . First check the registry:

fDisableAudioCapture REG_DWORD 0x00000000

Next check that it is enabled in any group policy that is applicable to the VM. The GP setting is here:

Computer Configuration \ Administrative Templates \ Windows Components \ Remote Desktop Services \ Remote Desktop Session Host \ Device and Resource Redirection

Allow audio recording redirection Enabled

Finally when you are connecting to the Windows 7 Enterprise make sure you have enabled remote audio recording. Of course your local PC must have a microphone installed.

• Marked as answer by Lai Yoong Seng MVP Tuesday, September 7, 2010 3:30 PM

There are several settings that control if Remote Audio Capture is enabled or disabled.

1. The Client License. If the Client is not Pro/Ent/universal, Remote Audio Capture is not available.

2. A GPO exists in order to get this feature enabled or disabled.
— Computer configuration, administrative templates, windows components, remote desktop services, device and resource redirection .

Reading the explanation, when this policy is not configured, Server 2008 does not allow audio and and video playback redirection by default.
However, Client Version allow by default, unless configured as disabled. So there is no need to configure this policy on windows 7 VDI machine to get this working. Configuration is only necessary if you wish to disable this feature in Windows 7.
This policy (as any other GPO) is not modifying registry keys outside Software\Policies

3. Registry key HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp fDisableAudioCapture REG_DWORD
I can confirm that Ultimate has a setting of 0 (does not actively disable), but Enterprise Edition has a value of 1 ( disable this feature).
That’s a decision that has been made to meet most business needs.

To determine how Remote Audio Capture is enabled, and the logic is as follows:

If any of the 3 possible settings above, (License, GPO, RegKey) disable this feature, it remains disabled.

So the correct thing to do in your environment is ensure that the Registry Value fDisableAudioCapture is NULL. There are various methods to do so, one is GP Preferences.

For more information, please refer to the KB article 2020918:

If you have any feedback on our support, please contact tngfb@microsoft.com

This posting is provided «AS IS» with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

Remote recording windows server

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I need to hear the microphone connected to the 3.5 mm jack of a remote computer over Remote Desktop Connection (RDP). The remote computer (where the microphone is) is a Windows 10 Pro 32 bit laptop. If present near the remote computer, the sound of that microphone can be heard on its speakers. I need to hear it however on my local laptop, a Windows 10 Pro 64 bit. During the RDP session I did set up the Local Resources / Remote Audio to «Play on this computer» and/or «Record from this computer». However, no audio is received and no new recording microphone appears in the local computer. In order to solve this issue I also enabled in Group Policy both «Allow audio recording redirection» and «Allow audio and video playback redirection», as explained at

However, the microphone redirection over RDP is still unsuccessful! Other audio, like music played on the remote computer, is well transferred to my local laptop over RDP. Only the microphone redirection doesn’t work!

Is there any limitation for such feature in Windows 10 Pro 32 bit? Do you have any advise that might help out, please?

Что нового в Windows Server 2016 RDS. Часть 2

Автор статьи — Роман Левченко (www.rlevchenko.com), MVP — Cloud and Datacenter Management

Продолжаем погружаться в новшества RDS Windows Server 2016.
Первая часть была посвящена новому типу развертывания RDS – MultiPoint Services.
Сегодня будем говорить о не менее прекрасном, а именно Personal Session Desktop и других нововведениях, которые расширяют и дополняют имеющуюся функциональность RDS в средах Windows Server 2012 и Windows Server 2012 R2.

Еще раз отмечу, что на данный момент отталкиваемся от той версии Windows Server 2016, которая официально доступна и открыта для использования – Technical Preview 4. В RTM-версии, возможно, будут изменения, о которых непременно оповестим.

Personal Session Desktop

Если Вы сервис-провайдер и хотите предоставить полноценный «десктоп» своим клиентам, то в текущих условиях сценарий VDI и SPLA (Service Provider License Agreement) являются непреодолимой стеной ну пути решения поставленной задачи. Согласно SPLA, нельзя предоставлять инфраструктуру VDI, построенную на базе клиентских ОС, «облачным» пользователям.

Хабр любит доказательства, поэтому привожу цитаты из официальных руководств по лицензированию DaaS (Desktop As A Service).

SPLA (январь, 2016):

Desktops delivered as a service are supported under SPLA using Windows Server and Remote Desktop Services (RDS). The Windows Desktop Operating System cannot be used to provide a hosted client, hosted graphical user interface or desktop as a service.

Руководство по лицензированию «Microsoft Desktop as a Service»:

No option is available in the SPLA to provide a hosted virtual desktop using the Windows Desktop Operating System; however this is possible to do through Dedicated Outsourcing

Под Dedicated Outsourcing понимается ситуация, когда клиент лицензируется через VL, и Вы, как сервис-провайдер, предоставляете выделенные физические ресурсы под VDI на базе клиентских ОС. Важно отметить, что этот сценарий так же не даёт нам право на предоставление ресурсов по схеме one to many (1 апп. сервер много клиентов). Только соотношение 1:1. По сути, мы отдаём пару юнитов в нашем шкафу в аренду одному и только одному клиенту.

Для обхода подобных ограничений, как правило, строится система на базе классических терминальных решений (session-based архитектура, конечно, с desktop experience на борту) и отдаётся на «растерзание» клиентам или пользователям.

В Windows Server 2016 решили это дело упростить и добавить метод «привязки» пользователей к конкретным терминальным узлам (в рамках RDS это узлы Remote Desktop Session Host, RDSH). В итоге, получаем новый вид RDS-коллекции — Personal Session Desktops (PSD) или частные рабочие столы на базе терминальных сессий. Очевидно, что можно провести аналогию с Personal Virtual Desktops в VDI, предназначенные так же для выделения «изолированной» среды пользователям.

Давайте посмотрим на пару сценариев, которые успешно решаются благодаря PSD:

• Если пользователю для работы требуется, чтобы ОС имела все возможности и внешний вид «как у клиентской» (к примеру, Windows 10), то полноценной заменой его рабочего стола будет PSD с установленными компонентами Desktop Experience, которые позволяют добиться внешнего вида интерфейса Windows Server близкого к обычной клиентской ОС.
• Если пользователь имеет административные полномочия на своём привычном ПК, и вы хотите перевести его на PSD, то это возможно сделать путем добавления пользователя в группу локальных администраторов (определяется на этапе развертывания PSD, «ручной труд» не требуется)
• Если пользователь не видит свою дальнейшую жизнь без графических приложений, требующих дополнительных аппаратных ресурсов, то можно предоставить PSD с обновленными возможностями RemoteFX. Об этом поговорим чуть позже. Забегая вперед, наконец-то мы дождались…

Впервые PSD был анонсирован в Technical Preview 2 и изменен в TP3/TP4 (одним из изменений была замена структуры cmdlet, отвечающего за конфигурацию PSD). На текущий момент единственный способ развернуть PSD – PowerShell. Опцию GUI планируют добавить не ранее RTM-релиза.

Для целей демонстраций и тестирования можно использовать тип развертывания Quick Start на базе сессий. При этом будут установлены RD Connection Broker, RD Web Access и RD Session Host на одном физическом сервере. Для реального использования рекомендуется сформировать распределенную архитектуру. Не забываем, что каждый компонент RDS поддерживает виртуализацию (к примеру, 1 VM RDSH 1 PSD User) и высокую доступность (например, RD Connection Broker иметь высокодоступную конфигурацию).

На всякий случай привожу шаги по конфигурации

Дополнительно устанавливаем Desktop Experience на узле RDSH

Переходим к созданию коллекции PSD.

New-RDSessionCollection был дополнен свитчем -PersonalUnmanaged, который используется для создания коллекции типа Personal Session Desktop (в Technical Preview 2 наименование свитча было другим, а именно -PersonalSessionCollection)

Если RDSH уже находится в одной из PSD-коллекций, то на его основе нельзя создать новую коллекцию. Только после удаления данного RDSH из текущей коллекции появится возможность определить его в новую.

После создания коллекции PSD и привязки к ней пользователя, перейдем в RD Web Access узел (https://host fqdn/rdweb) для дополнительной проверки, используя учетные данные нашего пользователя. Должен появиться список коллекций, доступных пользователю

Отмечу, что в привычном для администратора списке коллекций (Server Manager –> RDS –> Collection List) данный вид коллекций не отображается, поскольку он создается и управляется только с помощью PowerShell (по крайней мере, до выхода RTM-версии).

Вот такой вид имеет панель «Пуск» в сессии PSD:

Наша коллекция была создана с ключом -GrantAdministrativePrivilege, поэтому пользователь автоматически был добавлен в группу Администраторов на выделенном сервере RDSH.

Улучшения RemoteFX

В Windows Server 2012 R2 RemoteFX-адаптер имеет ряд ограничений: 256 MB максимальный объем выделенной VRAM, поддержка только OpenGL 1.1, отсутствие поддержки OpenCL. Всё это сказывается на поддерживаемом количестве мониторов, разрешении и адекватной работе новых графических приложений (к примеру, Autocad Re-Cap требует OpenGL 3.3 и 1 GB VRAM, Photoshop CC — OpenGL 2.0 и 512 MB VRAM как минимум).

Windows Server 2016 призван решить данные проблемы и вносит ряд изменений:

Возможность выделения до 1 GB VRAM. Виртуальные машины Hyper-V могут использовать до 1 GB выделенной VRAM + увеличивать количество VRAM за счет системной памяти ВМ, получая до 2 GB VRAM, в зависимости от величины имеющейся у виртуальной машины памяти.

Кроме того, динамическое определение объема VRAM на основе количества мониторов и разрешения заменяется возможностью задания конкретного значения VRAM для каждой ВМ вне зависимости от максимального количества мониторов и разрешения.

Поддержка OpenGL 4.4 и OpenCL 1.1. Как итог, имеем «карт-бланш» на использование современных графических приложений.

Параметры RemoteFX определяются как через GUI, так и через PowerShell.

Новые клиенты RDS

Ещё буквально недавно у Microsoft не было ни одного мобильного клиента для доступа к удаленным рабочим столам, и приходилось использовать платные решения сторонних производителей с поддержкой RD Gateway. Однако по мере продвижения и использования RDS-решений были выпущены и добавлены следующие клиенты:

• RD Client for Android
• RD Client for iOS
• RD Client for Mac

Клиент RDP (MSTSC.EXE) был обновлен до 10-ой версии, которая имеет улучшенную поддержку кодека AVC/H.264 и режима AVC 444, призванного улучшить fps, понизить потерю цветности за счет использования функций аппаратного декодера H.264 в высоких разрешениях вплоть до 4K (GPU должен иметь поддержку DirectX 11.0, H.264 декодер Level 4.1/BT.709). Пока только в рамках полноценного клиента, но планируется добавить поддержку и для мобильных клиентов, обозначенных выше.
Режим AVC444 используется по умолчанию в RemoteFX, но есть возможность использования AVC444 и в других сценариях с помощью настройки групповой политики:

Сomputer Configuration/Administrative Templates/Windows Components/Remote Desktop Session Host/Remote Session Environment:
Prioritize H.264/AVC 444 Graphics mode for Remote Desktop connections
и
Configure H.264/AVC hardware encoding for Remote Desktop connections>

Поддержка виртуальных машин второго поколения

ВМ второго поколения (Generation 2) стали доступны ещё в Windows Server 2012 R2, но их использование в рамках RDS/VDI (и не только) откладывалось. Например, возможность создания шаблонов сервисов VMM на базе Gen2 была добавлена только в рамках UR6.
В Windows Server 2016 мы можем задействовать оба поколения для использования в различных типах коллекций (personal/pooled или personal session). Дополнительная конфигурация не требуется.

Поддержка стилуса и браузера Edge

Если ваше устройство, например Surface, поддерживает работу со стилусом, а локальная система не ниже Windows 10, то вы можете использовать стилус в рамках RDP-сессии.

В Windows Server 2012/2012 R2 подобные устройства также перенаправляются, но используются в качестве замены мыши. В рамках Windows Server 2016 и Windows 10 стилусом можно рисовать или писать, открыв, например, граффити-приложение в Microsoft Edge, который так же обзавелся поддержкой при работе в удаленной сессии.

Выводы

Обновленные RemoteFX и RDP с поддержкой разрешения 4K увеличивают отдачу от ВМ с «тяжелыми» приложениями в рамках VDI и повышают их быстродействие по сравнению с Windows Server 2012 / 2012 R2 (конечно, необходимо провести тестирование и взглянуть на реальные цифры).

MultiPoint Server, переехавший под «крыло» RDS, расширяет область применения удаленных рабочих столов и делает более привлекательным их использование (интерактивность в dashboard, простота настройки играют в этом не последнюю роль).

Personal Session Desktop (PSD) упрощает предоставление рабочих столов в рамках DaaS-услуги и расширяет возможности RDS в Azure. Ожидать глобального изменения условий SPLA, думаю, не приходится. Скажем «спасибо», что и тут не забыли о нас.

Надеюсь, что было интересно. Всем хорошей виртуализации и RDS-имплементации.