Hosting Remote Applications over the Internet with Terminal Services

Giving small business users the applications they want, available everywhere? It’s actually easier than you think. With the release of Windows Server 2008, the venerable Terminal Services gains a host of new capabilities.


These new features enable you to create an affordable remote application infrastructure in even the smallest of business environments.

Terminal Services isn’t new technology. First released in 1988 with Windows NT Terminal Server Edition, this technology enables a way to serve centrally-hosted applications over an internal network. With its new components that are freely available in Windows Server 2008, specifically TS Web Access and TS Gateway (as they’re now called – and look for another change of name with Windows Server 2008 R2 to Remote Desktop Services), those same applications can also be securely hosted across the Internet.

This step-by-step guide will show you exactly how to create such an environment in your small business clients today. Obviously, your individual design for such an environment will vary depending on the security requirements of your customer. Some businesses may require complex DMZ configurations with multiple hops between internal servers and the outside world. Others may require only that the communication itself that passes across the Internet is secure. We’ll explain how to create the simplest of these architectures, requiring only a few servers, a server certificate, and a lightweight firewall at the network’s perimeter.

Create RemoteApps in the TS RemoteApp Manager
Create RemoteApps in the TS RemoteApp Manager









You can also see a separate server labelled TS Gateway and TS Web Access. These two role services are new to Windows Server 2008 and are major components for enabling application access across the Internet. The TS Web Access role service works with Windows Server’s IIS role to create a Web site where users select their applications. The TS Gateway service, also installed to this server in this configuration, is the mechanism for proxying and encrypting communication between Terminal Servers and Internet-based clients.

A few steps are necessary for building this environment. First, you will need to enable and configure Terminal Services on each of the servers that will host applications. Then TS Web Access and TS Gateway must be configured on their server. This server should be reserved exclusively for use in these two roles, as this will be the only server in the environment that will be given direct access to the Internet. The last step is to configure your external firewall and set up name resolution so that clients on the Internet can locate and interact with this server.

Some TS Web Access settings are found in IIS Manager.
Some TS Web Access settings are found in IIS Manager.









Building Your Terminal Servers
Because installing the Terminal Server role on a Windows Server changes how that server works with applications so significantly, it’s important to enable the role as soon as you finish building the server and before you install any of the applications you will use with Terminal Services.

On each of the servers that will host applications, right-click the Roles node in Server Manager and choose to Add Roles. When prompted, choose to install the Terminal Services role and the Terminal Server role service.

Once Terminal Services is installed your next step will be to install the applications you wish to host from that server. Remember that Terminal Server applications should be installed by first navigating to the Control Panel and selecting Install Application on Terminal Server.

In Windows Server 2008, the client experience when connecting to a Terminal Servers is no longer limited to a full desktop only. With this version, it is possible to deliver individual application experiences to users. These TS RemoteApps are configured within the TS RemoteApp Manager console.

To create a RemoteApp from an already-installed application, right-click the area at the bottom the console and choose to Add RemoteApp Programs. A short wizard will appear which displays a list of the applications which have properly registered themselves with the server. You can set up applications which are not in the list by clicking the Browse button. Here we have already created three applications – Word, Excel, and WinZip – as TS RemoteApps within this view.

If you plan to deploy individual applications to your users, this step of creating RemoteApps from installed applications is necessary. Also note the column marked TS Web Access. RemoteApps can be rapidly provisioned and deprovisioned from a TS Web Access website by right-clicking the RemoteApp and selecting Show in TS Web Access or Hide in TS Web Access. This enables you to quickly remove applications from view during maintenance or when they experience problems.

To be correctly hosted over the Internet, individual RemoteApps require some additional configurations that you need to take care of after the installation and initial configuration of the other role services. So, you’ll return to this screen shortly.

Multiple components are used for hosting Terminal Services applications on the Internet.
Multiple components are used for hosting Terminal Services applications on the Internet.









In our network diagram of a small business Terminal Services environment you can see that multiple Terminal Servers of similar configuration have been aggregated into a single ‘farm’. The creation of this farm enables load balancing of incoming client connections across multiple servers, and provides a place of redundancy in the case of a server failure. Using multiple servers is entirely optional – only one Terminal Server is strictly required – but is a good idea to ensure that users can always connect to applications should one server fail.


Installing Web Access
As a type of proxy device, it is important to limit the server that hosts TS Web Access and TS Gateway to only those activities. It is also important that this server is secured with the proper updates and other security features that your customer’s business requires (or that you tell them to require) for hosts that are exposed to the Internet.

Once secured, install the TS Web Access and TS Gateway role services to this server in much the same way that the Terminal Server role service was installed. TS Web Access has very few configurations that must be set to get started. First, navigate to Local Users and Groups on each Terminal Server and look for the TS Web Access Servers group. Add the computer account for your TS Web Access Server to this group and reboot the computer. Next, navigate to the IIS Manager console and locate the TS subfolder under the Default Web Site. Once there, double-click the IIS control panel item marked Application Settings. Enter the fully-qualified domain name for the TS Gateway server, which in this example should be the same server.

The final configuration requirement is to point the TS Web Access server to a Terminal Server or Terminal Server farm for its applications. Do this by navigating to http://{serverName}/ts within a web browser. Click the button marked Configuration to open a page that will display the TS RemoteApps available. On the right side of the screen a single setting needs to be entered; fill in the name of the Terminal Server or Terminal Server farm from which you want this TS Web Access server to gather its list of RemoteApps. If you’ve done everything correctly, a refresh of the screen should begin displaying the created RemoteApps from your Terminal Servers.

One benefit of this network configuration is that one TS Web Access server can be used by both internal and external clients for finding applications – so you could offer remote applications from your own server to small businesses that don’t want to run their own Terminal Server. Users within your local area network can connect to the LAN address of your TS Web Access server, while those that are external can connect via its external address. With this architecture, it is possible to configure your RemoteApps to bypass the TS Gateway for internal users, a setting we’ll look at next. By creating a single location for accessing your hosted applications, your users will have a comfortable interface for finding their applications no matter where they are.

Point TS Web Access to a single Terminal Server or Terminal Server farm for its list of RemoteApps.
Point TS Web Access to a single Terminal Server or Terminal Server farm for its list of RemoteApps.










Configuring TS Gateway
So far we’ve configured TS Web Access to make it available for internal users; however, there are a few more required settings before those applications can be made available to the Internet. In order to encrypt traffic heading towards the Internet, the TS Gateway server needs to be configured with a server SSL certificate. While TS Gateway can use a self-generated certificate for this process and you might choose that to save money if you were only supporting tech-savvy internal users, it’s much better – and easier – to use a certificate that has been created by a public and well-known certification authority. You want to use these types of certificates because they are likely already trusted by the clients that will connect to your server and won’t cause confusion by requiring exceptions to security policy. Be aware that these types of SSL certificates come in many forms, with prices ranging from under $50 to many hundreds of dollars per year (certificates from US providers still tend to be cheaper). Let your wallet (or your customer’s budget) be your guide.

Once you’ve obtained and installed your certificate to the TS Gateway server – a process that can differ depending on which public certification authority you select – you’re ready to begin configuring TS Gateway.

TS Gateway uses two types of policies for identifying which users and resources are allowed access. The first policy is called a Connection Authorization Policy, or TS CAP. One or more TS CAPs are created to identify which external users are authorized to connect through the TS Gateway server. TS CAPs can be defined by users, user groups or computer groups, and can be limited to either smart card or password authentication for connecting (or both).

A TS CAP limits the users who can connect and the authentication methods they are allowed to connect with.
A TS CAP limits the users who can connect and the authentication methods they are allowed to connect with.













TS CAPs also provide a place to limit the functionality that is enabled for clients connecting via the Internet. The Device Redirection tab allows you to disable device redirection for drives, the clipboard, and attached peripherals for external clients. Limiting these kinds of device redirection for external clients increases data security by preventing users from transferring business data to their personal computers outside the protective confines of the LAN. If you get requests to enable this that you cannot easily refuse (usually from senior staff at the client), develop a policy document explaining the risks and accepting that they are reducing security; ensure it is read and signed by them and their manager before making any changes.

The second type of policy to be created is a Resource Authorization Policy, or TS RAP. The TS CAP determines which users are approved to access Terminal Services; the TS RAP identifies which resources they can access on the inside. There are three elements to configure in any TS RAP. The first is a list of users who can connect to remote computers on the internal network. The second, on the Computer Group tab, is the list of computers you wish to allow them access to; this list can be identified through an Active Directory security group or a TS Gateway-managed computer group. Using a TS Gateway-managed group can be useful as it provides a locked-down list of computers that can be accessed on the inside. At a minimum you should add those Terminal Servers that you intended the TS Web Access server to access.

A TS CAP is an excellent location for restricting device redirection for uncontrolled Internet clients.
A TS CAP is an excellent location for restricting device redirection for uncontrolled Internet clients.











Another benefit of this architecture is that it means you can allow users to connect directly to their personal desktop via the Internet. The Remote Desktop button on the TS Web Access page lets users create a connection from their remote location directly to their internal desktop. To make this more useful, you may want to select the bottom radio button on the TS RAP Computer Group tab, ‘Allow users to access any network resource’ (once they’re authorized).

The final setting for a TS RAP is to identify which ports are to be used for the RDP protocol. By default the RDP protocol is configured to operate over port 3389/tcp. On the Allowed Ports tab you also have the option of configuring other ports for access. If you change these ports, remember you’ll also need to reconfigure any internal Terminal Servers to operate over the new port.

Once you’ve finished these steps, you have to configure each Terminal Server to interact with the TS Gateway. Go back to the TS RemoteApp Manager and click the link marked TS Gateway settings. There, select the option for ‘Use these TS Gateway server settings’ and enter the TS Gateway’s server name into the correct box. There are two additional options. The first allows you to use the same user credentials for TS Gateway and the Terminal Server. Enabling this means the users have one less dialog for authenticating to the system. The other option allows users to bypass the TS Gateway for local addresses, to let internal users work directly with Terminal Servers.

A TS RAP identifies which internal resources can be accessed by approved users.
A TS RAP identifies which internal resources can be accessed by approved users.










Enabling Internet Access
There are only a few steps left. First, enable the correct network access from the Internet to your TS Gateway and TS Web Access server through your perimeter firewall (that connection will be over port 443/tcp). Next, you will need to adjust the configuration of the TS Web Access site so that it can operate over https. Do this by adjusting the bindings of the Default Web Site in IIS Manager to add a Site Binding for https that is attached to your SSL certificate.

Enabling bidirectional access to this server over port 443/tcp will allow clients to connect to the TS Web Access web site for authentication and to see and access applications. It also enables the TS Gateway to proxy Terminal Server connections over this same port back to clients.

Using a TS RAP, it is possible to change the ports on which RDP traffic will be allowed.
Using a TS RAP, it is possible to change the ports on which RDP traffic will be allowed.









Finally, ensure that Internet-based DNS can resolve the external fully-qualified domain name of this server, so that clients on the Internet can locate the server. Remember, if you plan to use your TS Web Access server for both internal and external access, many of the configurations shown in this example will need to be set with both internal and external DNS information.

What about Citrix?
We’re looking at how to configure Terminal Services for access through the Internet, but you may be wondering how Citrix, and specifically Citrix’s XenApp product, change the ballgame for external applications. It’s a valid question, because Citrix and XenApp provide advanced management functionality and a more efficient protocol, but at added cost.

The core of Citrix XenApp is to be found in four different editions. The first, the Advanced Edition, provides core capabilities for hosting and serving applications over an intranet and the Internet. In this and its Enterprise edition, XenApp uses a software-based SSL VPN that is similar in concept to TS Gateway. However XenApp’s Secure Gateway provides additional management features and greater levels of customizability. XenApp Platinum Edition replaces the software-based gateway with a hardware appliance called the Access Gateway.

As a hardware appliance, this offers a greater level of security than software-based solutions. It also provides a greater level of granularity associated with the types of resources and accesses that can be given to connecting users.

Users can work with remote applications or simply view and manage documents directly through the Access Gateway. Each of these features comes at a cost, however, with the per-concurrent user cost going up with each subsequent edition.

For small businesses with less than 75 users, Citrix also provides an inexpensive but user-limited edition called Citrix XenApp Fundamentals. This version includes the core functionality of the other versions, but not the high end features.

Find more information about each edition and the features in them at:

TS Session Broker Load Balancing Step-by-Step Guide
If you want to learn more about creating Terminal Server farms, check out:

TS Gateway Step-by-Step Guide
You can find more information about remote application TS configuration
as well alternate ways to set up this architecture here:




Show other articles by this author

Share |
Write comment
security image
smaller | bigger
Comments (1)
Posted: Jul, 2 2010

network design and confuguration

good,it provides us an exellent information



Subscribe and get the magazine in the post before it's online

Subscribe and get access to all of the back issues

To read a sample eMagazine - March 2010



2008 Download the Windows Server 2008 Administrative templates from to get Group Policy setting information for the items under Administrative Templates.
In Windows Server 2008 and Windows Vista Administrative template files can be either ADMX (language-neutral) files, stored by default in the %Systemroot%\PolicyDefinitions folder or ADML (language-specific) files stored in a language-specific folder within that. read more


Unified communications


The #1 Bestseller for Only 77p