Microsoft RDS Policies explained (Part 4)

by [Published on 9 Sept. 2014 / Last Updated on 9 Sept. 2014]

In this article the author explains policy settings for RD Session Host and User Configuration.

If you would like to read the other parts in this article series please go to


In Part 2 and Part 3 of the article series MS RDS Policies, I started describing the policy settings available for the RD Session Host. In this fourth and last part I will describe the settings we did not cover in the RD Session Host, followed by the settings available on the user configuration level.

Machine Configuration

Remote Desktop Session Host

Figure 1: Remote Desktop Session Host - Security

Security – Always prompt for password upon connection

As already described at the RDP client policy settings nowadays the user supplies the credentials before the connection is set-up. When this setting is enabled the user always needs to provide the password at the RDP session, even if the user already filled in the password at the RDP client. Enabling this setting will lead to users needing to provide the password twice.

Security – Do not allow local administrators to customize permissions

With this setting you can control if local administrators are allowed to change security permissions on an RD Session Host like defining which users are allowed to connect to the RD Session Host. Enabling this setting prevents local administrators from changing the security permissions. Logically you need to have another method to control access like the Remote Desktop Users group or GPO configuration.

Security – Require secure RPC communication

This is a setting that’s pretty difficult to explain. It’s easy to see that enabling this feature requires secure RPC communication between the server and the client, but how do you accomplish that? I cannot find much useful information about it and as this policy is from Windows 2003, I expect that it is the default behavior nowadays. But correct me if I’m wrong.

Security – Require use of specific security layer for remote (RDP) Connections

With Windows 2008 R2, Microsoft offers improved security for RDP Connections via TLS support. TLS requires certificates and Microsoft made its implementation not so straight forward. However if you have TLS in place you can configure that the TLS method is the only way to connect to the RD Session Host via this policy.

Security – Require user authentication for remote connections by using Network Level Authentication

Also introduced in Windows 2008 R2 for additional security and requires a client that supports Network Level Authentication. All current clients support that so it’s advisable to use Network Level Authentication. If you have clients that don’t support network level authentication you should disable this setting, especially for Windows Server 2012 where NLA is enforced by default.

Security – Server authentication certificate template

If you are securing the connection using TLS you require certificates. Via this setting you specify the name of the certificate template so a certificate is automatically selected to authenticate an RD Session Host.

Security – Set client connection encryption level

The encryption level specified in this setting determines the minimum encryption level the client should support. If using an older client, a lower encryption level should be chosen. Options available are High Level, Low Level and Client compatible.

Figure 2: Remote Desktop Session Host – Session Time Limits

Session Time Limits – End session when time limits are reached

This session is used in combination with Set time limit for active but idle Remote Desktop Services sessions or Set time limit for active Remote Desktop Services sessions, but not using the Set time limit for disconnect sessions. So when the time limit is reached for active but idle Remote Desktop Services sessions or Set time limit for active Remote Desktop Services sessions, and you don’t want to change the session to became disconnected. I personally don’t use this one, but specifies an interval for a disconnect session.

Session Time Limits – Set time limit for active but idle Remote Desktop Services sessions

With this setting you define a maximum time a session may be in the idle state. After this time the session will set in disconnected state by default (it will be ended if the settingEnd session when time limits are reached” is enabled). Configuring this settings can arrange that Thin Clients are available again for other users and user sessions are not running forever.

Session Time Limits – Set time limit for active Remote Desktop Services sessions

With this setting you define how long a user can actually work within one RD session. When the time limit is reached (started when the session is created) the session will become disconnected by default or ended by policy settings as described above. Personally I don’t use this policy as when people are still working, it’s a bit odd to disconnect or end their session.

Session Time Limits – Set time limit for disconnected sessions

When a session is in disconnected state (for example because it was idle for the maximum specified time limit or user did not end the session properly) for a long(er) time you would like to end the session to free up system resources. With this setting you can specify the time frame a disconnected session will end.

Session Time Limits – Set time limit for logoff of RemoteApp sessions

When using RemoteApps you still would like to use session sharing (so the RemoteApps are started on the same server as this server offers that applications). However when a user shuts down the latest RemoteApp, the user will be logged off the server. When a user directly selects another application it is possible that the user connects to a session that is actually still logging off or at least the user has to wait for the session on the RD Session Host to set-up again. With this setting you can define how long a RemoteApp session should remain in a disconnected state before the session is ended. By specifying a logoff delay the user can quickly start another RemoteApps without the possible scenarios described.

Temporary Folders – Do not delete temp folder upon exit

When session temp folders are used (in use by default, see the next policy setting for more information) this folder is deleted by default when the session ends. If need be you can change this behavior to prevent deleting the temp folder by enabling this policy setting.

Temporary Folders – Do not use temporary folders per session

By default an RD Session Host creates a temporary folder per session so information written to the temp folder does not conflict between sessions. If you would like to use a single temp folder per user independent of the amount of session you need to enable this setting.

User Configuration

As stated in the first part of this article series, policy settings are also available within the User Configuration. As those settings are defined on User level you can create different configurations for different users/groups. Many settings on the user configuration level are also available on the machine configuration level. If the setting is both defined on user as machine level, the machine level takes precedence. So if you need different configurations it is not possible to define the basic on machine level and the differentiations on the user level.

Figure 3:
User Configuration of RDS Policy Settings

In Figure 3, the folders within the RDS Policy Setting are shown. All settings available in the Remote Desktop Connection Client and Remote Desktop Session Hosts are the same also on the machine level. Therefore I’m not describing those again, you can check the description of these settings on the machine level.

The RD Gateway and RemoteApp and Desktop Connections settings are only available on the user configuration level, so let’s take a look at these.

RD Gateway

Set RD Gateway authentication method

The RD Gateway is developed to provide secure access to the RD Session Hosts via the internet. Users can authenticate via several methods which can be configured by the user within the RDP client (advanced tab). With this setting you can enforce that the user(s) use a specific authentication methodology or provide the default authentication method, but users are allowed to choose another methodology.

Enable connection through RD Gateway

With this setting you can enforce a user to connect only via the RD Gateway. The user cannot connect directly to an RD Session Host, only when within this policy the option “Allow users to change this setting” is checked (than you provide a default methodology, but the user can use another way). When this policy is enabled you are required to configure the setting “Set RD Gateway server address” as well.

Set RD Gateway server address

With this setting you provide RD Gateway server address enforced to the user. Only when the option “Allow users to change this setting” is checked, users can change the address, otherwise it’s enforced and the user cannot make adjustments.

RemoteApp and Desktop Connections

The RemoteApp and Desktop Connections is part of the RDP client and the configuration is available in the Control Panel. This feature makes it possible that RemoteApps are shown in the local client Start Menu. This is done by specifying a URL to fetch the assigned RemoteApps of that user. Within the setting “Specify default connection URL” you can define that URL via GPO so the user does not have to fill it in manually.


Within this article series I have shown that there are many policy settings available for Remote Desktop Services and tried to explain each setting in detail including some advice and best practices. I also provided the information on which level a policy can be configured and on which system it should be applied. However, configuring policy settings is dependent on many factors. Hopefully, this article series helped you get a good insight of the available policies and for which purpose they can be configured.

If you would like to read the other parts in this article series please go to

See Also

The Author — Wilco van Bragt

Wilco van Bragt avatar

After working for a couple of consulting firms as a senior technical consultant and technical project leader Wilco started his own freelance company VanBragt.Net Consultancy in April 2008. Wilco is certified n Citrix (CCIA, CCEE/CCEA, CCA), Microsoft (MCITP, MCTS, MSCE, MSCA) and Prince2 (Foundation). Wilco is also a RSVP (RES Software Valued Professional), Citrix CTP (Citrix Technology Professional) and a Microsoft MVP (Most Valuable Professional) on RDS.


Featured Links