Remote Desktop Services Tutorial #2 (RD Web Access)

Posted: 12/13/2011 by Ryan Ries in Microsoft Windows Server Technologies

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:

rdweb1

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.

rdweb2

rdweb3

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.

rdweb4

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.

rdweb5

 

rdweb6

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:

rdweb7

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.

rdweb9

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.

rdweb10

rdweb11

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. . .

rdweb12

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.

rdweb14

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.

rdweb13

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!

rdweb15

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.

rdweb16

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!

About these ads
Comments
  1. Zachary says:

    I’ve followed your tutorial, but everything I’m seeing seems to indicate that port 3389 is still used :(

    • Ryan Ries says:

      Hmm… I’m sorry. Without some more info on exactly what you did I don’t know really know where it went wrong. But don’t take my word for it:

      http://technet.microsoft.com/en-us/library/cc731150

      “This is because port 3389, the port used for RDP connections, is typically blocked for network security purposes. RD Gateway transmits RDP traffic to port 443 instead, by using an HTTP Secure Sockets Layer/Transport Layer Security (SSL/TLS) tunnel. Because most corporations open port 443 to enable Internet connectivity, RD Gateway takes advantage of this network design to provide remote access connectivity across multiple firewalls.”

    • Hi Zach,

      What PID does the good ol netstat -aon|find “3389″ point you to?

  2. Mark says:

    I have been trying to get the application in RDWeb to launch automatically upon login but can not find the solution anywhere. The only thing I have found is a piece of code that is supposed to work in TS,

    if MsTsc.SecuredSettingsEnabled then
    MsTsc.SecuredSettings.StartProgram = “notepad.exe”
    else
    msgbox “Cannot access secured setting in the current browser zone”

    end if

    I have tried to implement this in the default login page of RDWeb, do you know of any way this can be implemented?

  3. there is a way to avoid the app selection after the login? I need to customize my RD Web Access to automatically open an especific application… is that possible?

  4. Thank you for this article! For enhanced RDP and RDWeb security, you can use Cyberarms IDDS. If offers protection against brute force and dictionary attacks, as well as against password guessing. You can download and use the Free edition which is sufficient for smaller installations and unknown urls.

  5. Ryan Ries says:

    No it doesn’t matter what the name of your domain is. If you cannot resolve a hostname but instead have to use the IP address of the web server, then it is most likely a DNS issue. Are your clients using the correct DNS servers? Does the web server have an A record registered in the correct zone? (It might also be a host header issue.) With the information provided, that’s as good of an answer as I’m able to give you right now.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s