Sorry it’s been so long since my last post — I’ve been awfully busy over at that other blog. And don’t even get me started on that whole ‘life’ thing…
For the first installment in this series, see RDS Tutorial #1 (RD Gateway).
If any of the images are too small for you to see, try clicking on them, they might be thumbnails.
Now that we’ve set up an RDS Gateway, let’s try to add RD Web Access into the mix. RD Web Access is a pretty cool little role service of RDS that puts up a secured website that authorized users can access. From this website, the user can launch remote desktop sessions, and even better – RemoteApp programs. With RemoteApp programs, you can either launch applications from the RDS server by clicking on their icons on the RD Web Access website, or if you use Windows 7 or better, you can actually add them to your local Start Menu and launch them as though they were located on your own PC! It’s pretty sweet. For this tutorial, I’m going to attempt to add the RD Web Access role service to the same server that is currently running my RD Gateway. Were this an enterprise environment, I probably wouldn’t do that. For performance and scalability reasons, I’d probably break out the roles to different servers. But this is just a lab and a proof-of-concept. Let’s start by going to Server Manager on our existing RD Gateway server and adding the RD Web Access role service:
It will ask to install some IIS dependencies just like it did with RD Gateway. Just take the defaults; there shouldn’t be any problems with conflicts.
Alright so let’s look at the settings we’ve chosen above. It’s telling us that our new RD Web Access website will be at https://servername/RDWeb. So for me, if you wanted to access my RD Web site from the Internet, its address would be https://prarlrdgw01.arl.myotherpcisacloud.com/RDWeb. Note that you will still have a “default” website in the / directory. It will have the generic “Welcome to IIS” logo that us IIS users are so familiar with. You might consider adding an automatic redirect that goes to the RDWeb directory from the default site, unless you plan on using the default directory/site for something else. Also notice that the website’s SSL certificate will already be trusted if you access it from the same workstation and if you’ve already followed my RD Gateway tutorial. (And you address it by the FQDN in your browser.) See where it mentions WSRM? Windows System Resource Manager. It’s a nifty little tool that, in my opinion, is best used on servers that will have a lot of clients connected to them simultaneously. That’s because with WSRM you can do things like create system rules that will enforce policies like an equal distribution of CPU power and/or memory to all the connected clients. That way one doofus won’t have the power to adversely effect the experience of everyone else connected to your remote desktop server. But for now it’s outside the scope of this tutorial. We’ll cover it later.
Alright so that’s pretty much all there is to installing the RD Web Access role service. The only thing of note in the above screenshot is that it’s warning us that additional configuration is needed. That’s because we haven’t configured any RemoteApps for publication yet. It will continue warning you about this until you do. We’ll get to that in a bit. So now you have an RD Web Access site running on the same server as your RD Gateway! Below is a screenshot showing you where to find the files if you want to personalize your own RD Web site. You’ll at least want to add your company’s logo and name.
So here I’m just specifying the name of the computer that will host the RemoteApp programs. You can also modify this setting in the web.config files. Since I’m putting all the role services on the same server, I’m pointing to myself. There’s one other setting you can configure: The default port on which RemoteApps will be published. You can change this in the IIS console, or in the web.config for the site:
The interesting thing about this is that I believe this port only matters to internal clients. However, since we’re using an RD Gateway, we don’t have to open that port on our externally-facing firewall. We’re already running an RD Gateway and the RD Web Access website on the same server and on port 443. And now we’re about to be able to transport RemoteApps through 443 as well! That’s pretty freaking amazing if you ask me. How many different services can you squeeze out of one port? Alright, so now we have one final problem. And that is that we don’t have the required role service installed to host RemoteApp programs! That role service is RD Session Host. I’m just going to go and add it to this same server. Like I said before, I’d distribute the load more in an actual production scenario, but this is a lab so what the hell. If you do install RD Session Host on a separate server, be sure to specify it on the configuration page on RD Web Access, as was shown earlier.
Pictured above is just me adding the RD Session Host role service. It’s asking me if I want to enforce NLA. I like security. And I like enforcing. The next step will ask you about CALs. Client Access Licenses. This is that part where I was telling you about how you can only have two users logged in to a device “administratively” at once, but you can have bunches of users simultaneously connected to a proper RDS server. The downside is that you have to pay for that. At least you get to choose how you wanna pay. Per device or per user. I would go with per user, so that I can connect from any number of devices. However if you have several users that share the same workstations (like shift workers in an office) from which they connect to the RD session host, it might make more sense for you to do it per device. If you choose “configure later,” it will at least let you try it out for a few months before it stops working.
The next step asks about which AD groups I want to allow to connect again, just like it did for the RD Gateway. And again, I added the “RDS Users” group to that list. On the next step, pictured above, we configure which parts of the “Client Experience” we want to enable for our remote users. Each of these options will require more bandwidth and will demand more performance from your RD Session Host. And what the hell, why not… let’s drive this poor VM into the ground! I’ll probably be the only person connecting anyway. Except for that kid in China that finally hacks in. After the installation is complete, you’ll need to restart, and it’ll take a couple minutes extra to reboot as there is a lot of new configuring being done. Your server is now a full Remote Desktop Server. The important thing to remember is that from here on out you need to put that server in “RDS install mode” to install applications, unless the installation is a modern .msi package. You can research and find out exactly what it does, but basically it’s an old mechanism that just ensures that the application is installed in such a way that is friendly to being used by multiple users. You now also have a RemoteApp Manager added to your Server Manager console. Now let’s go and try to publish some RemoteApp programs. . .
The first thing I noticed was that it wanted to use a certificate for RemoteApp programs. So I gave it one. The same one that I was already using for the RD Gateway, and was issued by my enterprise CA.
Next I’m going to specify that the client should connect using my RD Gateway, bypassing the gateway when internal. Perfect. This part is crucial if you want to be able to access RemoteApp programs from the Internet, as remember you can’t get through on ports 3389 or 5504 from the Internet. Next I’m going to go to the local Users and Groups. Notice the two new local groups at the bottom, TS Web Access Admins and TS Web Access Computers. Domain Administrators are administrators by default, whether they are in that TS Web Access Admins group or not. Now even though the other group says “computers,” I went ahead and put my custom RDS Users group in there anyway.
Finally we’re ready to add a RemoteApp program. In your RemoteApp Manager, just right-click and add a RemoteApp program. I don’t have anything interesting installed, so I guess we’ll just add Powershell just to test if it works. At this point, you’re ready to connect to your fully-functional RD Web Access website from the Internet!
There’s your RemoteApp program! Also notice down in your taskbar, an interesting little icon popped up that you only see when accessing RemoteApp. It’s a part of the Windows 7 system that allows you to add programs to your Start Menu as if they were local, but are in fact running over that connection through our RD Gateway. Clicking on the Powershell icon will prompt you if you’re sure you want to run this program over a remote connection. Make sure that it correctly specifies both a remote computer name and a gateway server name, which in my case are one and the same. It will then attempt to connect, and you might get prompted for credentials to the RD Gateway server. One oddity that I noticed was that I got my default domain policy greeting message like you would get when normally logging on to any domain server, but it was in an odd resolution, and I had to click OK. My first thought is that it would be easy to wiggle around that with some group policy work, but it doesn’t bother me that badly.
Alright so your remote application launched! Check it out! It looks and feels like it’s running on your own local workstation. Notice down in your taskbar that the application’s icon has a little “remote” symbol on it. The neat thing I tried to convey with the Powershell command I typed in is that it is retrieving information about the remote system, not your local system. And all of this is taking place over an SSL tunnel on port 443. Alright, so that’s all I have for today. Feel free to contact me if you have any feedback or to tell me that something I did could have been done better. ‘Till next time!