Deployment

Adding a Machine-Wide Trusted Location in MS Access

Let me show you how to add a Trusted Location for every user on a device even if that device doesn't have a full copy of Microsoft Access.

Mike Wolfe

Feb 14, 2022 • 6 min read

Microsoft recently announced that Office will start disabling VBA in ALL files downloaded from the internet.

There are a few ways to deal with this:

Open "Properties" for the downloaded file and check the [√] Unblock box
Sign the VBA project with a code-signing certificate that is trusted on your user's device
Open the downloaded file from a Trusted Folder

In this article, I'm going to focus on the third option. More specifically, I'm going to explain how to create a machine-wide Trusted Folder.

Adding Trusted Folders the Usual Way

The typical way to add a trusted folder is to go through the Access user interface:

File > Options > Trust Center > [Trust Center Settings...] > Trusted Locations > [Add new location...].

There are two obstacles with this approach:

Users must have a full version of Access to set this up
The settings are saved to the user area of the registry

Thus, the process must be repeated for every user, and it's not practical to create these locations as part of an installer. If the end user does not have local administrative rights to the machine, then the installer will set up the Trusted Location for the admin user and not the day-to-day user.

Here is a look at the Windows Registry that shows you the entries that get created to go along with the above screenshot:

The locations appear as auto-named subkeys (Location0, Location1, Location2, etc.) under the following registry entry:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Access\Security\Trusted Locations

Note that "16.0" is the version number for Office 2016; other versions will have a different number. Also, in contrast to the HKLM key that I will talk about next, the HKCU key never requires a "WOW6432Node" key.

Adding Machine-Wide Trusted Locations

I am a big fan of scripting as much of my work as possible.

Not only is scripting faster (once it is set up) than going through the user interface, it is also more repeatable and more version-control-friendly. To get the most value out of a script, we want it to be something that we only have to run once per machine. This means that the standard HKCU key is not an option.

We need a location in the HKLM hive. But where?

Finding the Machine-Wide Trusted Location

For this, I used a variation of the ProcMon technique I wrote about previously.

In this case, I fired up Process Monitor and added the following filters:

Process Name is msaccess.exe [Include]
Path ends with Trusted Locations [Include]
Path begins with HKCU [Exclude]

Then I started capturing events in ProcMon and fired up a copy of Access. Once Access finished starting up, I stopped capturing events in ProcMon. Here's what I was left with:

Click on the image above to open or download the original in full size.

The screen shot is a bit hard to read, so let me hit the highlights:

Operation: RegOpenKey
Result: NAME NOT FOUND
Path(s):
(A)
HKLM\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access\Security\Trusted Locations
(B)
HKLM\Software\WOW6432Node\Microsoft\Office\16.0\Access\Security\Trusted Locations

If you're not familiar with Process Monitor, the amount of data it collects can be overwhelming (hence the reason for the various filters). I want to highlight the fact that the result of the above operations was, "NAME NOT FOUND."

In other words, before the Trusted Locations registry key even exists, Access is looking for it just in case it happens to be there.

I have the ClickToRun (C2R) version of Access installed on my test computer. Notice that Access checks two different registry keys in the above ProcMon output: one with a \ClickToRun\ subkey and one without. We will use the registry key without the \ClickToRun\ subkey because that is compatible with both MSI and C2R versions of the Access installer.

Determining the Correct HKLM Key

It's not practical to run ProcMon on every machine that you need to update.

The main reason I showed it here was to give you a peek behind the curtain at how I go about reverse-engineering these types of hidden program settings. I also wanted you to have a way to troubleshoot a particular machine that may give you trouble.

Generally speaking, you only need three pieces of information to determine the base HKLM key:

The installed Access version
The Windows bitness (64- or 32-bit)
The Office bitness (64- or 32-bit)

The Installed Access Version

This will determine the embedded version number:

16.0: Access 2016/2019/2021; Microsoft 365
15.0: Access 2013
14.0: Access 2010
12.0: Access 2007

The Windows/Office Bitness

The combination of these two properties tells you whether you need the \WOW6432Node\ as part of the key path:

64-bit Windows + 64-bit Office/Access: not needed
64-bit Windows + 32-bit Office/Access: include \WOW6432Node\
32-bit Windows + 32-bit Office/Access: not needed
32-bit Windows + 64-bit Office/Access: not supported

Some examples

Here's the key for 64-bit Office 365 running on 64-bit Windows:

HKLM\Software\Microsoft\Office\16.0\Access\Security\Trusted Locations

Here's the key for 32-bit Office 2013 running on 64-bit Windows:

HKLM\Software\WOW6432Node\Microsoft\Office\15.0\Access\Security\Trusted Locations

Here's the key for 32-bit Office 2010 running on 32-bit Windows:

HKLM\Software\Microsoft\Office\14.0\Access\Security\Trusted Locations

Now that we know where the relevant registry key is located, we can add our own subkeys to match the format of the keys as created in the HKCU block.

Adding the Trusted Location

Chances are the HKLM key we determined above will not exist in your registry.

You should see an \InstallRoot\ subkey at the same level as where the \Security\Trusted Locations\ subkeys need to go:

You'll likely need to add the \Security\ subkey as well as the \Trusted Locations\ subkey. Once you do that, you can start adding trusted folders.

Locations that get added through the Access user interface get unique names of the form "Location{x}" where the {x} is an auto-incrementing number. However, there is nothing special about the name "Location0" or "Location1". I recommend giving your Trusted Location subkeys more descriptive names than Location{x}.

My Inno Setup installer creates a \GandB\ subfolder inside the appropriate Program Files folder on the user's machine. Here's what my Trusted Location looks like for my company's applications:

Verifying the Changes are Successful

Let's go back to the Access Trust Center (File > Options > Trust Center > [Trust Center Settings...] > Trusted Locations.

If everything went according to plan, your new Trusted Location should appear under a Policy Locations heading–which is separate from the User Locations section.

Scripting the Registry Changes

How you actually go about modifying the registry is left as an exercise for the reader.

There is no shortage of articles explaining the various ways to do this. One important thing to keep in mind is that you will need to provide admin credentials no matter what technique you use (PowerShell, Inno Setup, VBScript, etc.), as that it is a requirement whenever you edit the HKLM registry hive.