-->
This article provides guidelines to install and configure the Remote Desktop Session Host role service on a computer that is running Windows Server 2019, Windows Server 2016, or Windows Server 2012 R2 without the Remote Desktop Connection Broker role service installed.
You need to open up Administrative ToolsRemote Desktop ServicesRemote Desktop Session Host Configuration on the destination server and double click on the top RDP-TCP connection. This brings up the RDP-Tcp properties box. In my case with DC #3, the cert hyperlink at the bottom was not clickable like the one on DC #1 which I could RDP into. Original product version: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 Original KB number: 2833839. When you create a standard deployment of Remote Desktop Services, the Remote Desktop Connection Broker role service provides access to the complete functionality of Remote Desktop Services.
Original product version: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 2833839
Summary
When you create a standard deployment of Remote Desktop Services, the Remote Desktop Connection Broker role service provides access to the complete functionality of Remote Desktop Services. A configuration that does not use the RD Connection Broker role service provides desktop sessions to users based on the number of Remote Desktop Services client access licenses (RDS CALs) that are installed on the server. Such a configuration does not provide access to RemoteApp programs or the RDWeb website. Because a configuration without the RD Connection Broker role service does not provide access to all RDS functionality, you should use such a configuration only if there is no other option.
You can use the instructions in this article to configure RDS service by using a single server (either a member of a workgroup or a domain controller (DC)). If you have a separate DC, we recommend that you use the Standard Remote Desktop Services deployment wizard.
Important
Configuring RDS on a workgroup server creates the following additional restrictions:
- You must use per-device licensing instead of per-user licensing. For more information, see License your RDS deployment with client access licenses (CALs).
- You must use Windows PowerShell to manage the RDS role services. This is because the Server Manager tools for RDS do not work. For more about using PowerShell cmdlets together with RDS, see Using Powershell to Install, Configure and Maintain RDS in Windows Server 2012.
For more information about the RDS roles, see Remote Desktop Services roles.
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 Test Lab Guide: Remote Desktop Licensing.
- 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 GroupsGroups.
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 ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser 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.
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:
- SQL database in Desktop hosting service.
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.
Remote Desktop Server Setup
For more information about how to configure RD Web Access, see the following articles:
Remote Desktop Licensing
Remote Desktop Connection Manager Download
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: