RDS 2012 connect users to session host servers via connection broker

Hello,

I was led to believe that in Windows 2012 RDS, in order for clients to connect to the session host "farm" we should be pointing our RDP clients directly to the connection broker server, and they will be dropped on to one of the session host servers

If we do that however, the connections seem to go directly to the desktop of the connection broker server and not to one of the session host servers. Is there anything we need to do to enable this?



Unfortunately you were (slightly) misinformed. First, a terminology correction (because it matters in understanding how things work.)

First, farms should be no more. In most deployments, you'll be creating collections, not farms. This matters from an actual implementation standpoint in that you can have multiple unique collections and they have names that the connection broker knows about.

Now, if you want to connect to a collection and have the RDCB load balance, it *is* true that you connect to the RDCB first, unlike 2008 era when you'd connect to a member and it's redirect to the RDCB. But since there can be multiple collections, the RDCB can only redirect you to a collection member if it knows which collection you want to connect to. If you simply open the RDC and type in the RDCB, that is the server you'll connect to (even if it collocated with an RDSH server) and will not even attempt to load balance or redirect... since it doesn't know where you want to go.

And therein lies the real rub. With RemoteFX exposing a ton of new port and device redirection settings, and with advances in the RDGateway, the options for pooled VDI or assigned VDI, plus a myriad of other things, the RDC GUI is downright antiquated. It would be immensely crowded to cram yet more settings in the GUI. Since generally RDSH is deployed and intended for end users, Microsoft's thought (whether you or I agree or not) was that asking end users to remember the name of their RDGateway, RDCB, collection, and app (in the case of remoteapps) was increasingly asking end users to do something complex that is inherently simple. So the GUI for RDC simply was never redesigned and therefore doesn't expose the setting that includes the collection name.

Microsoft's approach is instead that end users can use RDWeb. They only have to remember one thing; the URL. The .rdp files generated by the RDWeb role include proper collection name with each link, so the RDCB will properly load balance when connected to in this way. Users can also "subscribe" to a feed generated by RDWeb so these .rdp files are included in their start menu. And in 8.1, users can subscribe just by using their email address so they don't even need to remember a URL. That is available either through the new modern RDP app or through the traditional desktop control panel, so you don't *have* to use the modern app at all. And finally, for managed devices (domain joined) you can use group policy to subscribe users to feeds so they don't have to do anything to have apps and desktop collections appear in their start menu. And again, all these .rdp files include the collection name so RDCB can redirect.

So yes, you do connect to the RDCB in 2012 to connect to a collection. But if you are using RDC, you will get the default behavior of connecting to the RDCB itself. RDC is relegated primarily to admin duties now and is not considered the end user solution anymore.



Unfortunately you were (slightly) misinformed. First, a terminology correction (because it matters in understanding how things work.)

First, farms should be no more. In most deployments, you'll be creating collections, not farms. This matters from an actual implementation standpoint in that you can have multiple unique collections and they have names that the connection broker knows about.

Now, if you want to connect to a collection and have the RDCB load balance, it *is* true that you connect to the RDCB first, unlike 2008 era when you'd connect to a member and it's redirect to the RDCB. But since there can be multiple collections, the RDCB can only redirect you to a collection member if it knows which collection you want to connect to. If you simply open the RDC and type in the RDCB, that is the server you'll connect to (even if it collocated with an RDSH server) and will not even attempt to load balance or redirect... since it doesn't know where you want to go.

And therein lies the real rub. With RemoteFX exposing a ton of new port and device redirection settings, and with advances in the RDGateway, the options for pooled VDI or assigned VDI, plus a myriad of other things, the RDC GUI is downright antiquated. It would be immensely crowded to cram yet more settings in the GUI. Since generally RDSH is deployed and intended for end users, Microsoft's thought (whether you or I agree or not) was that asking end users to remember the name of their RDGateway, RDCB, collection, and app (in the case of remoteapps) was increasingly asking end users to do something complex that is inherently simple. So the GUI for RDC simply was never redesigned and therefore doesn't expose the setting that includes the collection name.

Microsoft's approach is instead that end users can use RDWeb. They only have to remember one thing; the URL. The .rdp files generated by the RDWeb role include proper collection name with each link, so the RDCB will properly load balance when connected to in this way. Users can also "subscribe" to a feed generated by RDWeb so these .rdp files are included in their start menu. And in 8.1, users can subscribe just by using their email address so they don't even need to remember a URL. That is available either through the new modern RDP app or through the traditional desktop control panel, so you don't *have* to use the modern app at all. And finally, for managed devices (domain joined) you can use group policy to subscribe users to feeds so they don't have to do anything to have apps and desktop collections appear in their start menu. And again, all these .rdp files include the collection name so RDCB can redirect.

So yes, you do connect to the RDCB in 2012 to connect to a collection. But if you are using RDC, you will get the default behavior of connecting to the RDCB itself. RDC is relegated primarily to admin duties now and is not considered the end user solution anymore.



Hi Cliff,

Many thanks for the very detailed answer this has helped a lot! I have done some work with 2008 RDS but am new to 2012 RDS

So the long and short of it is to use RDWeb for all users both internal and external?

We have the following setup

2 x RDGateway servers with RDWeb installed (in a DMZ)
3 x Session Host servers
1 x Connection Broker

We have the a CA signed certificate installed (wildcard) and internally everything works by pointing the internal users to RDWeb (we are using split brain DNS).

We have a problem connection externally however I expect that may be a firewall issue. RDWeb page comes up but the remote apps don't connect and just time out



Using RDWeb is indeed a simple solution to your problem. It is now considered a core component for an RDS deployment and the scenario based wizard deploys it by default. Now you know why. :) Your problem could be firewall related or related to the specifics of the rdgateway setup. A few movng parts to investigate there...



Thanks again Cliff. I'm going to award you the points. I'll open up other questions in a new thread. Big believer in not polluting a question with multiple offshoot questions!



Share this

Related Posts

There was an error in this gadget