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
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.
Since multiple users are running your program on the same machine, your application needs 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.
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.
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.
Below are the steps for setting up a Terminal Server on your network, then exposing a particular application with RemoteApp.
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.
There are a couple options in terms of security:
In either case, it is always best to ensure that your Terminal Server is properly protected within the confines of a network firewall.
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.
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.
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:
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:
For example, the following path does not work:
Instead, you must use an absolute path reference like this:
where "Bob" is the name of the user account.
A solution to this limitation would be to use Total Access Startup as described below.
RemoteApp is 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.
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 does not work:
Instead, you must use an absolute path reference like this: "C:\Users\Bob\AppData\Roaming\App\DatabaseFile.accdb", 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:
By specifying the user's database in the %PROFILE% folder, Total Access Startup copies the master front-end database to each user's private folder to avoid conflicts in your Remote App environment. You don't need to create special settings for each user.
Total Access Startup lets you specify the version of your front-end database. When that changes, the user's copy is updated automatically the next time they launch your program.
Ensure that the database is opened within the version of Access which it 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. You can control this for each database regardless of having multiple instances of Access installed on the PC.
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.
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.).
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 eventually gets converted to a web based solution or not.
Our consulting team can help you evaluate the options and tradeoffs, and implement a migration path to ensure a smooth transition to a remote hosted platform. For more information visit our page, Running Microsoft Access via Remote Desktop and Remote App including Hosting on the Microsoft Azure Cloud.
Have any suggestions or comments? Head to our blog post, Using Terminal Services and RemoteApp to Extend Your Microsoft Access and other Windows Applications Over the Internet and leave us your feedback!
Supports Microsoft Office 365/2016, 2013, 2010, 2007, 2003, 2002, 97, and 95
"Total Access Startup is an amazing product and an incredible value. It's not only made my job as a developer easier but it provides a great service to our users"
M. Killough, a happy customer