FOLLOWUP: http://blog.subvertallmedia.com/2011/03/25/rds-setup-for-n00bz-followup/

A client of ours, a non-profit with two old Citrix servers, is finally taking our advice to get some new equipment in there. We got a used by still very good server from another client, maxed out the RAM, and today I installed Server 2008 R2 Enterprise and Hyper-V. I offered two scenarios: one in which we use Server 2008 R2 VMs with RDS, the other in which we P2V their existing Windows Server 2003 machines. The first solution is obviously the better choice but with old programs, you can’t be too sure what will and won’t work, so I had to test them out. I also hadn’t configured an RDS farm before and wanted to make sure that they wouldn’t lose the easy accessibility offered by way of a web portal.

The basic details really aren’t worth getting into, nor am I going into a whole explanation of what RDS is and how it differs from TS. Use Google, dude. If you want to configure RDS, there are tons of great blog posts that will walk you through it. What might help you, though, is a really brief walk-through of the key components. I mean, knowing how to do something is great but it’s hard to find directions if you don’t know where you’re going. This would have saved me quite a bit of time but I have to admit that it was kind of fun to dig through it and figure out exactly how it all worked together. So… here we go.

The equipment: one physical box running Server 2008 R2 Enterprise Edition, one Hyper-V machine also running 2008 R2 Enterprise. The Hyper-V host, against best practices, is also my web-facing RDS Gateway machine. Yeah, I know, shouldn’t do that, shut up — the server, while better than what they had, is still sort of old, RAM is at a premium, and I don’t want to waste resources on another VM. Once I have proven that all of their apps will work in Hyper-V, I will build a second RDS virtual machine.

The goal: web-based login to remote desktop. I also wanted their key apps available as remote apps so they don’t need to login to a full desktop. We needed multiple RDS machines available with automatic load balancing. Simplicity is key.

Shit you need to know! (For my scenario.)

First, some basic definitions.

The remote desktop server, formerly known as the terminal server, AKA the machine where all the apps actually run, is now the Remote Desktop Session Host.

The web-accessible portal is the Remote Desktop Web Access.

The load-balancing component is the Remote Desktop Connection Broker.

The component that allows external users to access RDS resources behind your firewall is the Remote Desktop Gateway.

So with all that said, how does one do this? It’s not all that hard.

First of all, both machines need to be in a domain. In my test environment, I was trying to do it in a workgroup. Once your roles are installed, you need to add your machine accounts to a few different local groups, so the Session Host needs to go in the Broker’s “Session Broker Computers” group and your broker needs to go in the “TS Web Access Computers” group on your RDS session host. This can’t be done unless you’re in a domain! In my case, I complicated things dramatically by joining both machines to the domain over a VPN. This caused a snag at a later point but we’ll get to that soon.

Next, I installed different RDS roles on both machines. On my web-facing machine, I installed the Connection Broker, Gateway, and Web Access components. On the RDS host, I installed only the Remote Desktop Session Host role. At this point, you can add the machines to the proper local groups. Knowing this ahead of time doesn’t really matter because the configuration tools do a very good job of telling you to do that, so pay attention to error messages.

Make sure everything is registered properly in DNS. If you want to use an RDS farm, you need to register it in DNS, one entry with the name of your choice for each RDS Session Host. In my case, I had one RDS Session Host with plans to add more so I only created one DNS entry for the farm but when I add my second server, I will need a second DNS entry.

Configure your servers to look in the right places. Because I was using a Connection Broker in a farm, I needed my Session Host to know this. Remote Desktop Session Host Configuration, then “Member of a farm in RD Connection Broker” under the “Edit settings” heading in the middle of the screen. Your RD Connection Broker is the internal DNS name of the machine with that role; your farm name is the internal DNS name that you created. It will not check if these are accurate so don’t mess it up!

The web-facing server needed a bit more work. In “Remote Desktop Connection Manager,” add your farm as a RemoteApp Source. I wasn’t using Virtualization Hosting so none of that stuff really mattered. The RD Gateway server can be set to automatically detect or a static entry — I used a static entry. Licensing is rather self-explanatory. Make sure to specify your RD Web Access servers on this screen as well — it wants an internal name though I have a hunch that your external name would work if you were doing everything through a single server.

Configuring the Web Access component is a breeze, just enter your broker or stand-alone server address in the web portal. I ran into a snag here because of my whole domain-over-VPN nonsense. There is a service, “Remote Desktop Connection Broker,” that will not start if your machine cannot authenticate with the domain. In my case, I was logging in using the VPN, but the service already failed at that point and I didn’t realize it! Because of that, the Web Portal did not want to accept a server address and the error message was vague. The solution was to ensure the VPN was connected and then start the service, at which point it worked perfectly. Don’t forget to forward 80, 443, and 3389 to this server!

You need to configure RemoteApp settings or your web portal won’t show anything accessible. Simple thing here: open RemoteApp Manager and make sure to go into “RD Session Host Server Settings,” “RD Session Host Server” tabm and add in your farm name and click “Show a remote desktop connection to this RD Session Host Server in RD Web Access.” If you want web apps available, you do that from the RemoteApp manager as well.

Finally, you need to do some basic configuration on your gateway server. The Remote Desktop Gateway Manager is pretty easy to figure out if you want a very basic setup, probably the easiest part of this whole thing. Right-click the server in the left-hand column, go to “SSL Certificate” tab, and do what you need to do. For my testing purposes, I used a self-signed cert but would never do this for a production server because it requires the cert installed as a trusted authority on each client machine. Creating the self-signed cert is done right from this window, which is quite convenient. You also need to go to the Server Farm tab and specify the internal name of your RD Gateway. It does verify the name so make sure you’re connected to your domain using your VPN… (grumble grumble…).

Seriously, that’s it. It took me all day to figure this crap out. I realize that this was hastily written and quite vague but it’s short enough and covers enough ground that it might save someone some time. I know that it would have saved me a few hours! It’s a very cool feeling to connect over the net to your new RDS Web Access server and launch MS Word through the browser, knowing that it’s using the gateway to access resources that aren’t publicly available to the web. Good luck!