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

Posted on March 30, 2011 by LukeChung

Read our new paper on using Terminal Services and RemoteApp to Extend Microsoft Access and Other Windows Applications Over the Internet.

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 few exceptions, most Windows applications work within a Terminal Server environment. By doing so, your investment in existing applications, and the power of Windows desktop features and interoperability, can be exposed over the Internet.

This is particularly powerful for database applications such as Microsoft Access since it eliminates the need to send large amounts of data over the Internet for Access to process and users do not need to install Access on their machine. With RemoteApp, you can set up a terminal server experience where your users can only run your application without running other applications or browsing your network. Easily web enable all your desktop applications.

7 thoughts on “Using Terminal Services and RemoteApp to Extend Your Microsoft Access and other Windows Applications Over the Internet”

Ken Hockley on May 3, 2011 at 11:16 PM said:

Hi

I Read your article with interest – I have a client retention system in MS Access 2007 with around 50 users running on a LAN – no problems, speed is good

Some of the users are wanting to work from home. When the user logs in from home most of the systems are slightly slower, however the MS Access DB is very slow

Could you suggest a reason why this is so

Thanks

Reply ↓
Luke on May 4, 2011 at 9:01 AM said:

Hi Ken,

There are many ways to improve Access database design and performance. Our article related to Total Access Analyzer covers a lot of potential areas: http://www.fmsinc.com/Products/analyzer/ErrorsList.html

As for your particular situation, it’s difficult to tell with such limited information. I presume you have a split front-end/back-end database design so that each user has a copy of the front-end application on their local machine. If not, check out this paper: http://www.fmsinc.com/MicrosoftAccess/DatabaseSplitter/Index.html

Do you have a permanent link from the front-end database to the back-end? Read this resource for more info: http://www.fmsinc.com/MicrosoftAccess/Performance/LinkedDatabase.html

Unlike a client-server environment, a file-server database like Microsoft Access processes all it’s data on the front-end. That means, a lot of data may have to pass across the wire to your remote user’s machine. That can be minimized if you use SQL Server on the back-end and design it properly. Bandwidth can also play an important role.

Of course, the point of this paper is to use VPN and RemoteApp to let people run the application over the Internet without any of the data streaming across the line. By keeping the data on the local network, the only info that crosses the Internet are the screen refreshes which should be relatively quick. Hope this helps.

Reply ↓
Ken Hockley on May 8, 2011 at 10:12 PM said:

Thanks Luke

I’ll get back to the client now and ensure they are using VPN and RemoteApp

Thanks again for your help

Ken

Reply ↓
Gabriel on June 1, 2011 at 12:52 PM said:

Hi
Do you have any stats regarding Harware/Memory/Space vs optimal #Users?
I know you’re going to say it all depends the App requirements …
Could you please use a sample app you have used/tested with this schema

Thanks in advance
Gab

Reply ↓
Luke on June 1, 2011 at 3:39 PM said:

Hi Gab,

Well, start by figuring out what kind of hardware you’d need to support for one user. Based on that, you can provide that many times it for the number of simultaneous users you want to support. That would be the high end cost. You may be able to support more with less cost per user based on what their workload would be while logged in. Hope this helps.

Luke

Reply ↓
James Cox on September 7, 2011 at 2:49 PM said:

Wonder if you could comment on the issues that would be involved by putting the Access front-end database as a read-only file in a SharePoint document library and the back end on a \\server\share location.

This would require that the user copy down the front end to his PC before every use (thus ensuring the correct version of the front end was always being used) and having all the data being updated/appended on the \\server\share backend would mean that the user would not need to (nor be able to, given the front end’s read-only status) save the downloaded front end back to SharePoint.

Any gotcha’s that haven’t occurred to me with this scenario? We’re running in a mixed Access 2007 and 2010 environment and there are some issues with references to the Outlook and Word object libraries not always being appropriate for whichever version is opening the .accdb, but those have been worked around…

Thanks for your time on this!

Reply ↓
Luke on September 7, 2011 at 6:41 PM said:

We’ve heard of some people using SharePoint to handle deployment of Access databases, but that’s not ideal as you’ve found. We created a program, Total Access Startup, that lets you centrally manage and deploy Microsoft Access databases to your users and set which version of Access they launch. We’re about to release our Access 2010 version which will also let you control whether they use (or not use) the 32 or 64 bit versions. It’s great when you need to manage multiple Access databases and want one location to control and change it.

More information on the product along with a trial version is here: http://www.fmsinc.com/MicrosoftAccess/VersionLauncher.asp

Reply ↓