How do I connect to an RD farm using the farm name?

Question

New to RD... I'd think this a very obvious question but my web searches come up dry...

I've got two Server 2012 servers, call them ALPHA and BETA. ALPHA is an RD Gateway, RD Connection Broker, and RD Session Host. (I imagine this system doubling as a session host could be trouble under heavy load, but this is only a trial.) BETA is simply an RD Session Host.

I've got ALPHA and BETA in a collection, we'll call "My Collection".

If I set my RD client to use the gateway, and then enter "ALPHA.domain.com" where it says "Computer:" on the connection dialog, I invariably get a session on ALPHA.

If I enter "BETA.domain.com", one of two things happen. Either I get a session on BETA, or I get an error saying:

Remote Desktop Connection cannot connect to the remote computer.

The remote computer BETA.domain.com that you are trying to connect to is redirecting you to another remote computer named ALPHA.domain.com. 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.

If you are using an RDP Connection provided to you by your administrator, contact your administrator for assistance.

If you want to connect to a specific farm member to administer it, type "mstsc.exe /admin" at a command prompt.

This message suggests I use the "farm name", but if I try entering "My Collection" as the computer name, it firstly truncates this to "My", and then basically tells me there's no such computer. There wouldn't be one called "My Collection", either.

(Of course, the Help button is no help.)

Questions:

1. What am I supposed to do on the client in order to connect to whichever of the two hosts is least busy?

2. Should the redirect mentioned in the error message have worked, and if so, what things should I look at to explain why it didn't?

Thank you for any insight!

Solution

Kevin, to answer one point you wrote:

"I imagine this system doubling as a session host could be trouble under heavy load, but this is only a trial."

Not at all, the broker service is a very lean service which all it does is poll the various servers in the farm and maintain who is logged on where in a small database and tell where to go.

There are a few steps in setting up RD Session Farms.

This is the best starting point: http://technet.microsoft.com/en-us/library/cc753891.aspx

But in essence:

1) Create a round robin dns entry with the farm name which has the IP of all your session host servers. 2) On the broker, add all session host (alpha + beta in your case) to the group Remote Desktop Server (may be slightly different name, I don't have it in front of me). 3) Setup the Remote desktop service telling it that it is part of a farm. 4) Enable the policy of "one session per user" - otherwise you may have a situation where a user has a session on each server.

Then with all that, on the client you just go to the farm name (since it's in DNS).

Your client will be directed to one of the entry in the round robin dns. They will get a logon prompt. The server they got will then check with the broker to see whether they should let the user on or redirect him to a different server and proceed.

If you are using pre-win7 clients, then they will get a repeated login screen if they get redirected. A bit annoying my users are saying! But on win7+ clients then it does not do that.

Comments

[WookieeKushin]

Thank you for the rundown. I'll give this a try. I notice the link you mention is for 2008 R2. Have you tried this on Server 2012? I think I read somewhere there were some significant changes to load balancing in 2012. As for sharing the roles, the broker probably is pretty lightweight but I'd be a bit more worried about the gateway. If my understanding is correct, it carries and encrypts traffic for all the hosts (for clients which need to connect through a gateway, which in our case is most of them).

[ETL]

Good point on the gateway - that is something I did not try (don't use it as I don't need it accessible through web based protocol).