Ondrej Sevecek's English Pages

Here follow my fast publish crucial and proofed notes for building and troubleshooting RDP (remote desktop) farms based on the new Windows 2012 R2 server manager deployment technology.

Assume we have two RD Session Hosts named RDHOST1 and RDHOST2. Assume that we want to run seperate operating systems for RD connection broker and possibly have two high available RD connection brokers RDBROKER1 and RDBROKER2, but we may start with a single broker without high-availability. Thus the RD connection brokers will not be placed on the session hosts. Further, we plan to have separate RD Web servers (RDWEB1 and RDWEB2) and separate RD gateway servers (RDGW1 and RDGW2).

Internal DNS domain name is gopas.virtual, thus running on a non-public/local DNS suffix which affects certificate contents primarily. We also assume that the users will need access from the internet with public DNS names from gopas.cz domain.

The following table summarizes the DNS names and their IP address mappings:

DNS names and aliases

With the older Windows 2008 R2 the farm DNS alias (office.gopas.virtual) would point to the actual RD session hosts. With Windows 2012 this changed. With Windows 2012 and newer the load-balanced farm DNS alias (office.gopas.virtual) must point to the RD connection broker servers if you have them in the high available configuration with SQL server. If you deploy only a single RD connection broker, you will not have any load-balanced DNS name at all.

Note that there is also something else called session collection name. The session collection name is not any DNS related at all. It is just a workspace name. So please distinguish between the session collection name (not important to us) and the more important load-balanced farm DNS name.

Just remind you also that RD connection brokers themselves generate RDP file contents for their farm into their WMI provider namespace root\cimv2\TerminalServices (class/table Win32_TSPublishedApplication) where it is downloaded from by the RD web servers and made available through their web site. So the RD connection brokers actually define the RDP file contents, especially the target DNS name inside.

If you do not have load-balanced RD connection brokers and run only a single one, the clients using RD web will be pointed to its actual DNS name. In my case, if I run only a single RDBROKER1 without high-availability the clients have to point their MSTSC to the DNS name of rdbroker1.gopas.virtual. Once I enable high-availability for the two RD brokers, their clients will be pointed to the load-balanced DNS farm name office.gopas.virtual.

If you want to change this default DNS name while you do not have the high-available RD broker setup, you can change the DNS name that the broker puts into its RDP files. This can be done with Set-RdClientAccessName PowerShell cmdlet. To verify you can then obtain the contents of the RDP file from broker's WMI:

Set-RdClientAccessName -ClientAccessName office.gopas.virtual
gwmi Win32_TSPublishedApplication | select -Expand RDPFileContents

With Windows 2012 RD farm users cannot point mstsc client directly to any actual RD session host computer. If they did so, they might receive one of the two following error messages saying the following:

Remote Desktop Connection cannot connect to the remote computer.
The remote computer that you are trying to connect to is redirecting you to another remote computer. Remote Desktop Connection cannot verify that the computers belong to the same RD session host server farm. You must use the farm name, not the computer name, when you connect to an RD session host server farm.

The connection cannot be completed because the remote computer that was reached is not the one you specified. This could be caused by an outdated entry in the DNS cache.

This happens when the specified target session host redirects the client to another node in the farm. This may happen because the target session host contacts RD connection broker itself over DCOM/RPC and queries the broker for the user's session and possibly redirects to another farm node using the other node's DNS name. Just like it was done with older Windows 2008 R2 RD farms.

Users must use the farm DNS name instead. Note again, the farm name points to the RD connection brokers. In case of a single RD broker, it is the DNS name of the single connection broker instead of the session hosts' names (or the name set manually by the Set-RdClientAccessName).

As it will become clear with certificates, if you have the brokers in high-available design, you should use the load-balanced farm DNS name directly on public DNS alias, such as office.gopas.cz instead of the office.gopas.virtual. The same applies for the manually set DNS name if you change it with the Set-RdClientAccessName. Rather use a public domain to save you troubles with non-domain public clients and mobile devices.

Manually connecting to the farm with mstsc client

Although RD connection brokers run the standard TCP port 3389, they are not acting as RDP application session hosts. They act as redirectors for the client connections. If you manually start the mstsc client and manually type the DNS name of one of the connection brokers or the load-balanced farm name (such as rdbroker1.gopas.virtual or rdbroker2.gopas.virtual or office.gopas.virtual), you may receive the following error message:

The connection was denied, because the user account is not authorized for remote login.

Sure, the users are not members of Remote Desktop Users local group on the RD connection brokers. Thus this error is absolutelly correct. Yet we said that the clients actually connect to the RD connection broker DNS name or the farm load-balanced DNS name which all lead to the connection broker computers. Yes, but with different options, that you cannot configure in the mstsc GUI manually.

If you want to connect to the farm manually, you must inform the client that the DNS name specified is the redirector in fact and not a name of a target RDP machine. In order to do this, you have to save the connection into an RDP file, open it in notepad and modify or add the following two lines:

use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.Office

The importance of the /admin switch

If you need an administrative RDP access to a certain RD session host node or one of the RD connection brokers, you must use the mstsc /admin switch. In my scenario, if an administrator needs to connect explicitly to rdhost2.gopas.virtual, in mstsc he must type the address as rdhost2.gopas.virtual /admin.

The /admin switch prevents the target host from redirecting the user to another node. It also prevents the connection to require and consume RD CAL which might be nice in case your farm is configured to use device RD CALs.

Note although that profile disks are still applied on the session hosts. So if you connect under the same user account to multiple nodes simultaneously with the /admin switch, only for the first session you will get the profile VHDX disk attached and mapped to the C:\Users profile root folder. All later administrative sessions on other session hosts will have to use temporary user profiles which will get deleted once the administrator logs off.

Also note that the administrative sessions started with the /admin switch to each node fall under the standard two-active-sessions limit which means that all other administrative sessions will have to be disconnected. This applies per node surely, not that you would be limited to only two simultaneous administrative sessions per whole farm.

Server authentication and Kerberos

We run the session hosts and the connection brokers on their real internal domain names. If your client is in LAN and connects to them with domain user credentials, Kerberos authentication for the servers may clearly be possible with NLA. But users use the load-balanced DNS farm name which cannot be mapped to any single session host, so the load-balanced DNS farm name cannot use Kerberos authentication.

We must authenticate the RD brokers with a certificate.

Certificates

You need certificates for the RD connection brokers, RDWeb and RD gateway. You do not need to bother with certificates for the RD session hosts at all. RD session host connections are authenticated by the RD connection broker and do not need their own certificates or be authenticated by Kerberos. As we said already, users always connect to RD session brokers first.

Note: although they always have at least the automatic self-signed certificates valid for half year which are generated on all RDP session hosts by default by their Remote Desktop Configuration (SessionEnv) service. But these are not trusted and are used to establish the TLS cryptography only, not to verify the RDP server identity.

In case of non-high-available RD connection broker it must have SSO (single-sign-on) certificate with its own DNS FQDN name. That is all. Nothing else. Or surely, if you changed the name with Set-RdClientAccessName, then the certificate must contain that new name instead.

In case of high-available RD connection broker it must have SSO (single-sign-on) certificate with the load-balanced DNS name of the farm. That is all. Nothing else required.

Note that public CAs will not issue a certificate with an internal name since ca 2015. So if you use internal DNS domain such as gopas.virtual, you must generate the certificates yourself.

Contrary to some documentations, the GUI nor PowerShell accept certficates with Remote Desktop Authentication Enhanced Key Usage (EKU). The RD broker certificate must contain the common Server Authentication OID in EKU.

All the certificates imported from GUI or PowerShell must have the Subject field with at least something. If the certificates contain Subject Alternative Name (SAN) extension, the only names checked are from the SAN extension and Subject is ignored. But in order to import the certificate from GUI or PowerShell, the Subject must also contain something. Anything. Not important what.

Although the modern TLS 1.1 and newer which is available with RDP from Windows 8 and Windows 2012 does use ECDH key agreement and as such does not need Encryption certficates, to import the RD broker certificate, the certificate must be both Signature and Encryption (you configure this on the Request handling tab of certificate template if you use AD CS with them).

The RD broker signing/publishing certificate must contain Server Authentication EKU. No way you can import anything like code signing or document signing certificates. Thus simply use the same certificate as for the RD connection broker SSO itself.

Same requirements for importing the RD web and RD gateway certificates from GUI or PowerShell. You definitely buy the RD web and RD gateway certificates from a public CA. Yet the non-domain and non-meneagable clients such as mobile phones and tablets will still ask to confirm the non-trusted internal certificate (the RD connection broker's SSO certificate with the internal name office.gopas.virtual).

You should rather configure the load-balanced DNS farm name to be public right from the beginning (such as office.gopas.cz). In order to have the public name for the farm you must have brokers in the high-available configuration.

Ideally do not build the RDP farm on private domain names at all (my case with gopas.virtual). Rather use different public primary DNS suffixes (in my example I would go for gopas.cz) on all farm members (so called disjoint AD/DNS namespace) and buy the certificates from a public CA. This way you save non-domain or non-manageable clients (mobile phones etc.) from manually approving the non-trusted internal certificate. If this is the case, you also do not need the RD broker in the high-available configuration and the clients would still use its public name (such as rdbroker1.gopas.cz).

Note that you should not have the exact same certificate without private key in the machine Personal store or the certificate installation fails.

Why users should not connect both to remote apps and full RDP desktops simultaneously

If you plan to let your users to connect to full desktop view of their RDP connections and simultaneously let them start some RemoteApps, do not do it. RD connection broker may assign the two different types of sessions to different RD session hosts which would prevent the second session from attaching and using the user profile VHDX file leading to a temporary user profile which gets deleted after logoff.

Thus leave the registry value ShowInPortal = DWORD = 0 in the CentralPublishedResources.

RDWeb server must be member of Windows Authorization Access Group

Yes. Right. Or it does not determine the security group membership of the user and then ignores the User Assignment settings on the published RemoteApps. This is because the RDWeb uses S4U kerberos extensions to determine the group membership which in turn requires reading the tokenGroupsGlobalAndUniversal constructed AD attribute.

RD gateway server must be member of RAS and IAS servers group

Yes. Right. You have NPS (Network Policy Server) there.

Starting RDP Shadow against RDP server in remote administration mode without the farm deployment console

mstsc /shadow /s:2 /v:dc.gopas.virtual /control /prompt

You also have to enable the remote control through group policy.

Other notes in my other posts

can be found here and here.