Using Terminal Services and RemoteApp to Extend Your Microsoft Access and other Windows Applications Over the Internet

by John Litchfield, FMS Development Support Specialist, and Luke Chung, FMS President

Overview

One of the features of Microsoft Windows Server that is increasingly popular over the last few years is the Terminal Server and more recently RemoteApp. With higher internet bandwidth, working from home or from an offsite location is more feasible today than ever before. With few exceptions, most applications work within a Terminal Server environment, provided you have the appropriate client access licenses (CALS) to make them available on a Terminal Server Host. By doing so, your investment in existing applications, and the power of Windows desktop features and interoperability can be exposed over the Internet.

Screenshot of Microsoft Access application running over RemoteApp

How Does a Terminal Server Work?

A Terminal Server virtualizes an actual Windows desktop environment experience using a Remote Desktop Protocol (RDP) session created for each user that connects to it. Concurrent connections (depending upon the number of CALS you have) are possible. A Terminal Server authenticates the user connections against the Active Directly list of users of groups that are maintained by your domain controller. The Terminal Server can be setup with a publicly assessable IP address or it can be configured using a private IP address (obtained from a DHCP host) in order to enable your end users with the ability to connect with their VPN (Virtual Private Network) connections. In either case, it is always best to ensure that your Terminal Server is properly protected within the confines of a network firewall.

With Terminal Server, a user can experience running a desktop over the internet with the Windows Remote Desktop Connection feature. They do not need to install any programs on their machine and none of the data streams across the internet. Only screen refreshes are sent over the Internet so it feels like you're running the application locally but it's all happening on the server. Printing also occurs locally, so a user can run an application over Terminal Server and have it print reports on their local printer.

Application Must be Multiuser Compatible

Since multiple users will be running your program on the same machine, your application needs to be designed to be multiuser friendly to avoid conflicts between users.

For instance, it should store any temporary files in the user (profile) based location, update registry entries in the HKEY_CURRENT_USER (not HKEY_LOCAL_MACHINE) section, etc.

Microsoft Access and Terminal Server

Terminal Server is particularly powerful for database applications such as Microsoft Access since you don't need to worry about installing Microsoft Access on each user's machine, making sure the right version of Access is loaded, whether the latest front-end database application is deployed, and the need to send large amounts of data over the Internet for Access to process. It's all being done on the Terminal Server machine with the local network bandwidth, and only the screen is refreshed as it changes.

For multi-user and scalable support, your Microsoft Access application should be a split database design where each user has their own copy of the front-end database installed under their profile. For more information on this, visit Splitting Microsoft Access Databases to Improve Performance and Simplify Maintainability. Our Total Access Startup program can also help with deployment for each user to ensure they have the latest copy of your front-end database.

Additionally, to support a Microsoft Access application, you can use install the free runtime version of Access, so you don't need to purchase an additional Office/Access license for each user.

Remote Desktop Application in Windows Server 2008 R2

However, giving users a virtual desktop on your network can be too much power if you only want to let people run one application over the Internet.

With the release of Windows Server 2008 R2, many enhancements were made to the Terminal Server feature. In particular, a powerful feature called "RemoteApp" is now available (see RemoteApp and Desktop Connection from Microsoft for more details). With RemoteApp, you can "lock down" the Windows desktop to limit users to a single Windows application. Unlike a remote desktop environment, RemoteApp restricts the user from running other applications, browsing the network, etc.

This allows you to safely expose your existing Windows applications built on Microsoft Access, Excel, Visual Basic 6, Visual Studio .NET, etc. over the web. For example, you can use Terminal Server with RemoteApp to let your external contractors access your organization's Windows invoice submission application over the web without exposing any other programs or resources to them.

Setting Up Terminal Server

Below are the steps for setting up a Terminal Server on your network, then exposing a particular application with RemoteApp.

Choosing the Host Computer

The computer must be a 64 bit machine, with enough hardware and memory to support running the maximum number of simultaneous sessions you expect. It's essentially the same as running multiple instances of your application on one machine. The computer also needs to be on your network and Internet to allow remote users to run it.

Network Access and Security Issues

There are a couple options in terms of security:

1. Terminal Server can be setup to use a publicly accessible IP address (this may require setting up the firewall to allow access for the IP address you are using).
2. Terminal Server can be configured using an internal/private IP address (obtained from an internal network DHCP server host). You can then provide your external end users with the ability to connect to the Terminal Server using their VPN (Virtual Private Network) connections. If you already have VPN setup, this would normally not require additional modifications to be made to the firewall security policy.

In either case, it is always best to ensure that your Terminal Server is properly protected within the confines of a network firewall.

Licensing

In addition to the server license, you must have a license for the maximum number of simultaneous users of your RemoteApp sessions. These Terminal Services Client Access Licenses (CALS) cost about $400 for a 5-pack and may be considerably less depending on your existing Microsoft licenses and contracts. The CALS are limited by the number of users, not the number of applications you want to support and expose over the web. For more details on Microsoft licensing rules, visit Licensing Remote Desktop Services in Windows Server 2008 R2.

Setting Up Terminal Server

1. Install Windows Server 2008 R2 on the computer.
2. Install Terminal Server. Terminal Server is available as a "role". While not installed by default, it can be added by turning the feature on within Programs and Features.
   1. Open Programs and Features (assessable via the Control Panel).
   2. Select the option on the top left entitled "Turn Windows Features on and off". This will open the Server Manager.
   3. Within the Server Manager node on the top left, select the item entitled "Roles".
   4. Click the link entitled "Add Roles" on the right side.
   5. The Add Roles wizard will now load.
   6. Follow the prompts of the role wizard to install the Terminal Server Role.
3. Install Terminal Server Licensing. This also installs as a Role service. Several licensing options are available from Microsoft. This task requires Membership in the local Administrators group or equivalent.
   1. Open Server Manager. To open Server Manager, click Start, point to Administrative Tools, and then click Server Manager.
   2. In the left pane, expand Roles.
   3. Right-click Terminal Services, and then click Add Role Services.
   4. On the Select Role Services page, select the TS Licensing check box, and then click Next.
   5. On the Configure Discovery Scope for TS Licensing page, specify the discovery scope for TS Licensing. On the Configure Discovery Scope for TS Licensing page, you can also specify the location where the TS Licensing database will be stored. If you want to specify a database location other than the default location provided, click Browse. Note that the database location must be a local folder on the computer on which the TS Licensing role service is being installed.
4. Add users and groups to the Terminal Server. Members of the local Administrators Group inherit the ability to connect to the Terminal Server. However, if you have other local users (or Domain user accounts and groups) that need to have access, these can be added using the Local System Properties Tool. Each user must have a Client Access License (CAL); more on this topic below. To add users and groups to the Remote Desktop Users group by using the Remote tab:
   1. Start the System tool. To start the System tool, click Start, click Run, type control system and then click OK.
   2. Under Tasks, click Remote settings.
   3. In the System Properties dialog box, on the Remote tab, click Select Users. Add the users or groups that need to connect to the terminal server by using Remote Desktop. The users and groups that you add are added to the Remote Desktop Users group. Note: Members of the local Administrators group can connect even if they are not listed.
   4. If you select Don't allow connections to this computer on the Remote tab, no users will be able to connect remotely to this computer, even if they are members of the Remote Desktop Users group. Each user must have a Client Access License (CAL); more on this topic below.
5. Activate a Terminal Services License Server. A Terminal Server must be activated from the Microsoft site. However, it will function for a period of 90 days before activation is required for continued use (the number of days may vary according to the edition of Windows Server 2008 which you are are using, however (i.e., Standard, Enterprise etc.). Activation of the server can be accomplished using one of the following methods:
   1. Internet (Automatic): This method requires Internet connectivity from the computer running TS Licensing Manager. Internet connectivity is not required from the license server itself. This method uses TCP/IP (TCP Port 443) to connect directly to the Microsoft Clearinghouse.
   2. Web: You can use the Web method when the computer running TS Licensing Manager does not have Internet connectivity, but you have access to the Web by means of a Web browser from another computer. The URL for the Web method is displayed in the Activate Server Wizard.
   3. Telephone: This is accomplished by calling the Microsoft Clearing House. The telephone method allows you to talk to a Microsoft customer service representative to complete the activation process. The appropriate telephone number is determined by the country/region that you choose in the Activate Server Wizard and is displayed by the wizard
      
6. Install Terminal Services Client Access Licenses using the Terminal Server Licensing Manager tool. This can be accomplished online from the same Microsoft site To access this tool, using the following steps:
   1. Open the Microsoft Windows Server Administration Tools.
   2. Select the menu folder entitled "Remote Desktop Services".
   3. A sub menu will appears. Click on Remote Desktop Licensing Manager.
   4. Installing the CALS can be accomplished online from the Microsoft site similar to activating the server.

With Terminal Server installed, your users can establish a VPN connection and use a Remote Desktop Connection to run a virtual PC over the internet. This lets them run the machine as if they were onsite. However, that can give the user too much power and rights to your network.

Setting Up RemoteApp

RemoteApp lets you restrict users to a single program. When the user logs into their Terminal Server account, the program you specified automatically loads. The user doesn't get to the desktop, can't load Windows Explorer, or any other programs while connected.

Specify which program they can use within the Remote Desktop Session Host Configuration Console:

When you install your application on the Terminal Server, you must have Admin rights to install your program, any ActiveX controls, etc. Your user can then run the application. Upon closing the program, the Terminal Server session closes. RemoteApp also supports batch command instructions if you need to initialize anything before the user starts. Below are the basic steps to configure RemoteApp to start a program:

1. From the Windows Server START menu, open the Remote Desktop Services Snap-in.  It can be found here: START => Administrative Tools => Remote Desktop Services => RemoteApp Desktop Session Host Configuration
2. Within the Connections list, right click on the node entitled "RDP-Tcp" and select "RDP-Tcp Properties".
3. From the properties form that is now open, select the Environment tab.
4. Set the option group selection to "Start the following program when the user logs in".
5. Insert the path and file name (most often an executable file) for the program which you wish to have automatically loaded when a user logs into the Terminal Server.

Limitations and Issues with Terminal Server and RemoteApp

While Terminal Server and RemoteApp offer an amazing way to deliver your application over the web, there are limitations and differences compared to a web solution:

1. Due to the licensing CALs, there is a cost for supporting each simultaneous user
2. Unlike a web site, users cannot be anonymous. They will need to log in and their credentials established in advance
3. The number of simultaneous users will be limited by your hardware
4. There is a known limitation with the ability of RemoteApp to support User Path variables. For example, the following path will not work: "%USERPROFILE%\AppData\Roaming\App\DatabaseFile.mdb"

   Instead, you must use an absolute path reference like this: "C:\Users\Bob\AppData\Roaming\App\DatabaseFile.mdb", where "Bob" is the name of the user account. A solution to this limitation would be to use Total Access Startup. For more information, see the paper entitled "How FMS Total Access Startup works with Terminal Services and RemoteApp".

This is definitely not a replacement for an Internet site that is publicly available and can support large numbers of simultaneous users. Those are appropriately created with Visual Studio .NET, Java, or other platforms that scale for such environments.

How FMS Total Access Startup works with Terminal Services and RemoteApp

One of the benefits of using Microsoft Access is the support that is offers for linking or connecting to one or more data sources. However, there is a limitation with the ability of RemoteApp to support User Path variables. For example, the following path will not work: "%USERPROFILE%\AppData\Roaming\App\DatabaseFile.mdb"

Instead, you must use an absolute path reference like this: "C:\Users\Bob\AppData\Roaming\App\DatabaseFile.mdb", where "Bob" is the name of the user account. This is a limitation which Microsoft Access Administrators must deal with since a proper deployment of an Access application requires that each user opens their open local copy of the database.

A solution to this limitation would be to use Total Access Startup. For Access applications, Total Access Startup addresses the following concerns of Access developers and administrators:

1. It ensures that the database is opened within a version of Access which your database is designed to support (as specified by the database administrator within an INI file used by Total Access Startup). For example, you can ensure your users always run Access 2010 with your database, regardless of the Access versions installed on their machine or what Windows considers the default for MDB/ADP files. There's even support to downgrade below the preferred version, if desired.
2. It uses a special version tracking algorithm in order to be sure that each of your users opens the latest official build of your frontend Access database file when they use your application. The simple shortcut which you can place on the desktop profile for each of your end users of the Terminal Server will automatically handle the database name, security settings, location of your files, etc., letting you change these at any time that the need arises. Total Access Startup supports mdb, mde, adp, ade, accdb, and accde database file types. It also supports Workgroup Security.
3. Finally, it offers a solution for using User Path variables for Access database files with RemoteApp. It accomplishes this by storing and using the User Path variables within the master INI file which each user shortcut uses to open the database application.

For more information about Total Access Startup and the functionality is offers, we invite you visit the main page for Total Access Startup. There is fully functional trial version of Total Access Startup available for download here.

Advantages of Terminal Server and RemoteApp

Terminal Server and RemoteApp are an excellent and cost effective option for extending existing Windows based applications to remote users. For existing applications where you only need to support a limited number of remote users, RemoteApp lets you leverage your existing investment in all your applications and get up and running immediately.

There's no need to make the investment in time and money to rewrite the application for the web in these situations. You also won't give up the nice features in Windows that aren't implemented so well on web solutions (e.g. copy and paste, multiple data displays, reports that understand your printer page, etc.).

Conclusion

A Terminal Server and RemoteApp platform offers a convenient, safe, and secure method for your offsite employees, contractors, and selected external users to obtain controlled access to your internal applications and resources.

We have found this technology to be especially impressive with its ease of implementation, use, and customizability. Rather than spending a huge amount of time and money to recreate an existing Windows application for the web, we're able to support remote users with the existing application immediately. For situations where supporting a few remote users is the primary driver for converting an application (and where the application is not intended to be used as a public website), it is no longer necessary to incur the extra expense of converting this suitable Windows application to a web application. With the savings from not having to rewrite the application, we can add new features to the existing application and make it more powerful for local and remote users without giving up any of the Windows features people expect.

This is certainly not a replacement for a full-blown web solution, but most solutions don't need that, especially if they already exist and are working properly. With Terminal Server and RemoteApp, you can immediately extend all of your Windows based internal solutions over the web. That's good regardless of whether the application will eventually get converted to a completely web based solution or not.

Blog about this here.