Geek of All Trades

How to Extend your Applications and Data to…Everywhere!

Greg Shields


When you clear away all the smoke and mirrors, the core of every IT professional’s job is really pretty cut-and-dried. The mission statement I like to use is: The core mission of IT is to create, manage and ensure secure access to business applications and data. Everything else—the patching, the troubleshooting, the help desk support—all are activities that support that core mission. Whether you’re an IT professional in a large enterprise or a jack-of-all-trades in a small business, keeping those applications running and their data secure is what ultimately keeps the paycheck coming.
That’s why a technology like Microsoft’s Remote Desktop Services (RDS) is a smart solution for fulfilling that mission. Using RDS, it becomes trivial to create pervasive and secure application access to anywhere with a network connection.
While RDS’s predecessor, Terminal Services, has long been a solution for positioning application access around the LAN, only since Windows Server 2008 has the product matured to make Internet-based access a possibility. What’s particularly compelling about RDS today is its ease of implementation. You can, with very little effort or previous experience, extend your applications and data everywhere on the Internet. All you need are two servers, an SSL certificate, and a couple of mouse clicks to get started.
What You’ll Need

Microsoft’s former Terminal Services solution was renamed Remote Desktop Services with the release of Windows Server 2008 R2. This new name reflects RDS’s expanded role as a hosted virtualdesktop solution as well as its traditional role as a hosted application solution. It is now possible to use the same RDS to connect users to a set of applications or an entire virtual desktop. I’ll leave the hosted virtual desktop configuration for a later column; I want to show you here how simple it can be to connect users to hosted applications.
To get started, you’ll need two servers. One of the servers will need to be outfitted with significant processor and memory resources (the exact amount I’ll leave to your determination). This beefier server will be your Remote Desktop Session Host (RDSH) server. On it you will install the applications you wish to make available to users. As such, it must be built with sufficient resources to support multiple simultaneous users running those applications.
In this article’s simple example, the application to be hosted over the Internet will be Microsoft Outlook 2007. Because launching attachments in Outlook 2007 often requires the assistance of Microsoft Office, the entire Office suite will be installed. Note that while the entire suite is installed, only Outlook will be directly made available to users.
Your second server can be significantly less powerful. This server will act as your Remote Desktop Gateway (RDG) server, and is used as a kind of proxy between Internet-based “outside” connections and the “inside” RDSH server. Because this second server handles only the gateway functions, its resource configuration can be substantially smaller.
As you’re preparing your RDG server, know that you will require a single port to be opened on your firewall between the Internet and the RDG server. Opening 443/TCP will enable outside clients to connect to the RDG server. The RDG server will operate as a protecting gateway for passing secured RDSH traffic (commonly on 3389/TCP) to clients (see Figure 1).


Figure 1 The RDG server operates as a protecting gateway between Internet clients and the Remote Desktop Session Host.
The third item you’ll require is an SSL certificate with a subject name that is your gateway server, specifically the Internet-accessible fully-qualified domain name of that server. While you can create such a certificate at no cost using Microsoft’s built-in Certificate Services, you’ll find that spending the $30/year or so on a public certificate from a trusted provider substantially reduces the complexity of your deployment. In this example, the certificate used is linked to the server named server1.contoso.com.
Installing Remote Desktop Session Host

The first step in extending your applications to the Internet has nothing to do with applications at all. Due to how RDS changes the operating environment of a Windows server, it is recommended that RDSH be installed prior to any applications. Thus, starting with a fresh installation of Windows Server 2008 R2 on \\server2, add the Remote Desktop Services role with the Remote Desktop Session Host role service.
If this is your first installation of RDS, you’ll also need to install the Remote Desktop Licensing service as well, although this article won’t go into the details of configuring this component. For detailed information, see http://technet.microsoft.com/en-us/library/dd983943(WS.10).aspx.
Four important configurations are required as part of the RDSH installation:

  1. Authentication method. Network Level Authentication (NLA) improves the security of user authentication to your RDSH server, but is supported only by Windows XP SP3, Windows Vista, and Windows 7 clients that are installed with version 6.0 or greater of the Remote Desktop Client. If your clients fit these requirements, it is a preferable setting to enable NLA.
  2. Licensing mode. Two methods for licensing are possible, and are fully dependent on the types of RDS Client Access Licenses (CALs) you’ve purchased for this implementation. Per Device CALs are linked to individual devices but can be used by any number of users. Per User CALs are linked to users but can be used on any device. If this is an evaluation environment for which you haven’t yet purchased CALs, you can elect to configure this information later. Licensing must be configured within 120 days or RDS will no longer accept connections.
  3. User groups. Here, configure the users or groups that will have access to connect to this RDSH server over the Internet.
  4. Client experience. This final configuration enables or disables special client functionality on the RDSH server, specifically audio and video playback, audio recording redirection, and Windows Aero user interface elements. Each of these capabilities increases the amount of data that must pass between client and server during a session, so only enable these features if your implementation requires them.

After answering these questions, RDSH will install to \\server2. When that’s done, the next step is to install the Microsoft Office suite. Be aware that installing applications to an RDSH server requires an extra step that is not required for a typical install. To install Office or any application, first navigate to the Control Panel item titled Install Application on Remote Desktop Server. Now enter the path to Office’s setup file and allow the installation to run within this Control Panel application.
All software that is installed to RDSH servers must be installed through this mechanism. Also, be aware that some applications may require special configurations to install to RDSH. Microsoft provides the free RDS Application Analyzer tool at https://connect.microsoft.com/tsappcomp to assist you with understanding the needs of these special installations.
Installing Remote Desktop Gateway

When the installation of your Remote Desktop Session Host is complete, you can enable it for Internet-based clients via the Remote Desktop Gateway. The first step in this process is to install your purchased SSL certificate to \\server1. While the actual process of obtaining this certificate depends on the issuer, the certificate must be installed to the local computer’s Personal Store (as opposed to the current user’s Personal Store) to be usable by RDG.


Figure 2 Configuring certificates for RDG.
With the certificate properly installed, the next step is to install the Remote Desktop Services role onto \\server1, but this time with the Remote Desktop Gateway role service. As shown in Figure 2, while the configurations for this installation appear more complex than with the RDSH, there are still only four that require attention:

  • Server authentication certificate. If you’ve correctly installed your SSL certificate to the local computer’s Personal Store, you’ll see that certificate listed in the box as in Figure 2.
  • RD Gateway User Groups. Groups that are identified in this location are allowed to connect to internal resources through this RDG server.
  • RD CAP. A Remote Desktop Connection Authorization Policy identifies which mechanisms are used for authenticating users to the RD Gateway server. This can be through entering a password, using a smart card, or both. This simple example will use only a password for authenticating users.
  • RD RAP. A Remote Desktop Resource Authorization Policy identifies which internal resources can be accessed by users who enter through the RDG. Here you can identify a group of computers (or all computers on the network) for access. In this example, the group of computers will be limited to only the RDSH server, \\server2.

Clicking through the rest of the steps in the wizard completes the installation and prepares the RDG for use. At this point, the RDG will begin accepting connections that are destined for the RDSH server.
Configuring the Outlook RemoteApp

For many JOAT administrators, this is where the confusing part begins. The next step in this process is actually accomplished back at the RDSH server. There, you will create the RemoteApp configuration for Microsoft Outlook. In that configuration, you’ll include the necessary information so external clients can attach to the RDG server via the Internet.
Navigate to the RemoteApp Manager in Server Manager. Right-click its link and select Add RemoteApp Programs. In the resulting wizard, check the box next to Microsoft Office Outlook 2007 in the list of installed applications, then click Next and Finish. This creates the connection to the Outlook RemoteApp.


Figure 3 Configuring RDG settings for the RDSH server.
Your next step is to identify the RDG server that Internet-facing clients will use for connection. Click Change next to RD Gateway Settings to see a dialog similar to Figure 3. This screen provides a place for you to enter the server name for your RDG server as well as a login method. Notice here that one checkbox is filled in. The first enables a kind of single sign-on, with users entering credentials only once for both the RDG and RDSH. The second allows users on the LAN to connect without being forced through the RDG. Since LAN-based users don’t necessarily require the RDG’s extra protections, this enables them to connect directly to the RDSH. Check both checkboxes and click OK to complete this configuration.
The final step in this simple example is to create a connection file that users can double-click to automatically connect to Outlook. To do this, single-click on the Outlook RemoteApp and then click Create .rdp File, then Next and Finish through the resulting wizard. The .rdp file will be created in the folder C:\Program Files\Packaged Programs and can be handed out to users. Your users will need only to double-click the file and enter their credentials to connect to Outlook over the Internet.
Another Notice. Another Certificate.

As you complete these steps and make your first connection to the hosted Outlook application, you’ll see a notice that appears after double-clicking the Outlook .rdp file (see Figure 4). This notice is not technically an error, although its presence often causes confusion for users. The notice represents an extra verification by the Remote Desktop Client to authenticate the .rdp file prior to executing it. As before, this authentication is enabled by signing the .rdp file with a certificate, which can be the same one used in installing the RDG.


Figure 4 The Remote Desktop Client’s final notice, which requires an extra public SSL certificate on each RDSH server.
To eliminate the error message, install the RDG’s certificate to the local computer’s Personal Store on the RDSH server, then navigate back to the RemoteApp Manager in Server Manager. There, click Change next to Digital Signature Settings. In the resulting window, check the box marked Sign with a digital certificate and click the Change button. If you’ve correctly installed the certificate to the local computer’s Personal Store, the certificate will appear for selection. Finally, recreate the Outlook .rdp file.
Completing this step changes the notice from a warning to a question, which now asks “Do you trust the publisher of this RemoteApp program?” If users agree, they can click the Connect button to continue or check the box to instruct the computer not to ask them again.
So, there you have it: Internet access for internal Outlook in 2000 words or less. Obviously, RDS arrives with a substantially greater set of options for configuring and further securing the environment. But this simple example will help get your small environment started down the road to pervasive and secure application access.
Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Geek-of-all-Trades tips and tricks at ConcentratedTech.com



موضوعات مشابه: