Microsoft announced an upcoming change in how it handles code in Office applications–including Access applications–that are downloaded from the internet.
Beginning with Version 2203, set to release in early April 2022, VBA code will be disabled automatically with no manual override option if the file was downloaded from the internet or another untrusted source. For the time being, users have the option to enable these macros at startup.
Here's what you currently see if you try to run an Access file that was downloaded from the internet:
As you can see, the security restriction can be bypassed by simply clicking the [Enable Content] button.
Beginning with the new update in April, the above warning will be replaced with the following message.
Notice that there is no override button. The Learn More button will take you to the following webpage: A Potentially Dangerous Macro Has Been Blocked.
Mark of the Web
Part of what triggers this warning is the presence of the so-called "Mark of the Web" (MOTW) in the downloaded file's properties. That's the check box you see when you right-click a downloaded file and view its Properties dialog:
To remove the MOTW, you check the "Unblock" box in the dialog window above, then click [OK] or [Apply].
Office Macro Security Flowchart
Microsoft provides a handy flowchart that demonstrates how Office applications decide whether to block or enable macros (i.e., VBA code).
The Mark of the Web (MOTW) attribute is added by Windows to files from an untrusted location, such as the internet or Restricted Zone. The attribute only applies to files saved on an NTFS file system, not files saved to FAT32 formatted devices.
Working Around the New Restriction
There are a few ways to work around this issue:
Remove the Mark of the Web
As described above, this approach requires modifying the downloaded file before opening it. See the "Mark of the Web" section above for detailed instructions to "Unblock" the downloaded file.
The user will still see the yellow "Security Warning" banner the first time they open the unblocked file. If they click the [Enable Content] button, the file location will get saved as a Trusted Document and all VBA code will work from that point forward.
Run Access Applications from a Trusted Folder
This is the preferred approach, but it requires that you have some way to set up a trusted folder on the user's device.
Adding a Trusted Location via the Access User Interface
If the user has a full version of Access, then they can do this via File > Options > Trust Center > [Trust Center Settings...] > Trusted Locations > [Add new location...]. Trusted locations added through the Access user interface are stored in the user profile section of the Windows Registry (i.e., the HKCU hive).
The locations appear as subkeys under the following registry entry ("16.0" is the version number for Office 2016+, earlier versions will have a different number there):
Adding a Trusted Location via an Installer
If you distribute your applications with some sort of installer, such as Inno Setup, then you can set the trusted location as part of the setup process.
The problem with the HKCU hive, though, is that it is tied to the current user's profile. If your application gets installed via an administrator account that is separate from the end user's account, then any entries made to the HKCU registry hive will be for naught when the end user launches your application. That's because the trusted location will be tied to the administrator's user profile, instead of the end user's profile.
Luckily, there is a machine-wide trusted location registry entry that you can set up in the HKLM hive. This allows you, as a developer, to build this into your installer as part of the application setup process.
I'll write up more detailed instructions in a separate post, but for now just know that you would need to create Trusted Locations as subkeys of the following registry key:
Note that you will need to replace the "16.0" with your Access version and you may not need the "WOW6432Node" key at all. Here's a sample:
The only required value is "Path."
Digitally Sign Your VBA Project
I'm including this option for completeness, but I don't recommend it.
As you can see from the above flowchart, one way to avoid the macro warning is to digitally sign your application with a Trusted Publisher's certificate. There are many steps involved in this approach.
- Purchase a code-signing certificate (several hundred USD) OR create a self-signed certificate
- Sign the VBA project
- Verify the certificate publisher is registered as a "trusted publisher" on the end user's machine (I believe this is necessary even with a commercial code-signing cert)
There are many pitfalls. It's easy to shoot yourself in the foot at any one of the above stages. If you go this route, brace yourself for frequent frustration.
For what it's worth, I have paid for a commercial code-signing certificate for many years. However, I only use it to sign my installation packages and not my VBA code projects.
UPDATE [2022-02-14]: Added sample HKCU key under section "Adding a Trusted Location via the Access User Interface."