Getting Microsoft Access to Work Remotely

Published 03-30-2020 06:41 PM 6,459 Views

Today's post was written by Juan Soto, a Microsoft Access Developer and MVP.


Ever wanted to use your Access database remotely? Great news, Microsoft Access can be used remotely under certain conditions, and here are the best ways to do so:

  1. Remote Desktop: The easiest and fastest way to remotely consume your database is through a remote desktop software; from Microsoft’s Remote desktop to other commercial software that will allow you to take over your work PC remotely and continue using the database as if you were in the office (See Get Microsoft Remote Desktop and How to Use Remote Desktop)
  2. If you haven’t already, upgrade your database to SQL Server in order to leverage the power of SQL with Access; you can find more info on it HERE: please note you may need to create SQL Server views and stored procedures based on the complexity of your Access database, and although occasionally timely, this is certainly a worthwhile effort.
  3. VPN: If your database is composed of both Microsoft Access Front End and a SQL Server backend, than make sure you are running the Front End file on your local PC after you connect via VPN to work, otherwise it may be slower and unreliable.

About the Author:

Juan Soto.jpg


Juan Soto is the President of IT Impact and a leading professional in the industry. He has been named an Access MVP by Microsoft since 2011 and is a frequent author on the official Microsoft Access blog as well as the co-founder of, where groups of Access enthusiasts around the world meet once a month on a wide range of topics. You can reach Juan at

Senior Member

Hi Ebo,


we also have very good experiences with Access 2010 Runtime/SQL Server based RemoteApps on Windows Server RDSH. Relatively inexpensive License Costs, excellent Performance, Stability, Scalability, Security, Ease of FrontEnd-Deployment/Updates and last but not least macOS and even Android support are strong Plus Points here.


Since we will soon have to set up a new Terminal Server, the question arises whether Office 365 Access Runtime is officially supported or recommended on Windows Server 2019 RDSH. Is it as robust as MSI Versions used to be in this Scenario? Are there any Pitfalls in Installation?

@Transimpex - a couple of tips:


  • Create the Windows Server 2019 RDSH as a virtual machine hosted by Windows Server 2019. This makes any kind of disaster recovery or farming much simpler
  • Let the RDSH VM run off an SSD formatted with ReFS
  • You can use the Access Runtime, but if the users are licensed to Office 365 (Microsoft 365), this can be installed without consuming one of the user's five licenses. The Office Deployment Tool is a must to install Office 365 (Microsoft 365) on an RDSH machine
  • Rename your frontend.accdb to frontend.accdr to make it launch in runtime mode.


Community Manager

Thanks for this information

Regular Visitor

@Transimpex, following on from what @Gustav Brock posted,


  • When licensing Microsoft Office 365 for use with Remote Desktop or RemoteApp, your users need to be licensed for a subscription that includes Shared Computer Activation, such as Microsoft 365 Business Premium.  See  You must also install Office 365 or the Access Runtime using ODT and configure your XML configuration file to use Shared Computer Activation.  On top of Office 365 costs, you also need Windows RDS User or Device CALs and Windows User or Device CALs suitable for 2019 or whatever version you're installing (though you likely already have the Windows CALs).
  • To prevent users from changing the VBA code in your database file, save it out to an accde file so that the VBA code is compiled and the source code is removed... then as suggested by @Gustav Brock, rename that file to accdr to ensure that if the file is opened by the full version of Access rather than the runtime, the database will run as if it was opened by the runtime.  This doesn't prevent users from seeing your local and linked tables or changing the contents of them directly, but it does prevent a malicious actor from adding code that damages your systems, removing password checks, taking a look at your hard-coded passwords or password tables, stealing your source code, etc.
Version history
Last update:
‎Mar 30 2020 06:43 PM
Updated by: