Security Warning is no longer suppressed

[Mike505]

I know a lot has been written about this and I thought I had it figured out but now all of a sudden the warning is back in 3 of 7 sites.
My main reason for reaching out is to find out if anyone else is experiencing this after they thought that it was resolved.
Any ideas would be appreciated.

The application was developed in Access 2013 32 bit.
It's running on Windows 11 Home machines.
It's deployed in 7 places all using the 365 32 bit runtime.
There is a front end and back end and other support files - all in shared folder "SunShare". Everyone has access to this folder. There are no sub folders. The computer name is "ComputerName". The shared drive letter "S".

Everything lives in a shared folder because in some sites there's a secondary machine running the same code and that needs to get to the primary machine's folder. So "S" is a mapped drive on both machines.

The user runs the application thru a shortcut with the following target: S:\SunUser1.accdb /runtime

When setting up a new site, everything works but the security warning appears.

These are my registry instructions that I use for all sites.:

1. Registry Changes - Primary Computer:
   
   1. Perform the following Registry changes:
   2. HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\A ccess\Security\TrustedLocations
   3. Add a DWORD by right clicking Trusted Locations, New DWORD (32 bit)
   4. Change the name of the DWORD to “AllowNetworkLocations”
   5. Right click and modify the DWORD value to 1
   6. Add a key to Trusted Locations by right clicking it, New Key, name it Sun
   7. Right click the new key and select New > Expandable String Value
   8. Change the name to “Path”, then right click and modify the value data to the network path name of the accdb (ex: \\Computername\SunShare)

At this point everything worked as needed - no security warnings.

Then months later, the security warnings come back in some not all of the 7 sites. This seems to have started around July 2. All sites are setup to automatically check for and install OS updates including updates to Microsoft products.



I did try uninstalling and re-installing the runtime but that was no help.
My guess is that this is related to a Microsoft update since everything was fine for months and then this issue developed. I'm assuming it will affect the other sites soon.

There ae some macros in the code and I thought that may be causing the problem so as a test I removed the macros in a test accdb just to see if that would get me past the security warning and it did not.

I'm at a point where I'm ready to say this is a Microsoft problem that I have no control over but that just goes against my grain.

[CJ_London]

why are you modifying the registry in that way? Usual method is to set it via Access File>Options>Trusted Locations

Also recommend you use UNC paths rather than mapped paths

If you only have runtime installed, no need for the runtime flag in your shortcut

Users should not be sharing the same front end which is what you appear to be doing so. It runs a strong risk of corruption and is very likely that what you are experiencing is an early sign of corruption.. User should each have their own copy of the front end, ideally on their local machine. To have it on the network only increases network traffic and subsequently reduces performance.

The fact it worked OK for months is irrelevant - I had a new client who had allowed users to share the FE. It was fine for 12 months or so, then went bang. I was called in to sort the mess out

So if the users are sharing the FE, the first thing to do is to ensure they each have their own copy.

[moke123]

I'm a little confused as to what constitutes a "Site"

The user runs the application thru a shortcut with the following target: S:\SunUser1.accdb /runtime

Does each user have their own copy of the front end on their local machine?

[Mike505]

The runtime switch is there to support running on a machine that has the full development environment (me).
You can't get to options/trusted locations on a runtime only machine.
No one is sharing the FE, I didn't get that detailed to keep it brief.
The FE is rebuilt daily to prevent your concern. There's a virgin copy that's copied as user1 and that addresses your concern. It also alleviates the need to compact since it's never "run'.

[CJ_London]

OK - what does 'rebuilt' mean?

[moke123]

There is a front end and back end and other support files - all in shared folder "SunShare". Everyone has access to this folder. There are no sub folders. The computer name is "ComputerName". The shared drive letter "S".

Everything lives in a shared folder because in some sites there's a secondary machine running the same code and that needs to get to the primary machine's folder. So "S" is a mapped drive on both machines.

The user runs the application thru a shortcut with the following target: S:\SunUser1.accdb /runtime

Still confused. What is the path to the front end on the users machine? It appears the S drive is mapped to the host machine.
Is there code to download a fresh copy of the front end on each use?

No one is sharing the FE, I didn't get that detailed to keep it brief.

You realize this only means we have to guess at the details.
Are these "sites" all at the same physical location connected by a wired Lan?

[Mike505]

I appreciate the time that all of you have spent. I really mean that. But the question that I asked at the top was has anyone else experienced this after months of having it work. More sites are now having this problem. I expected that because I believe it was caused by an update. So my original question stands, is anyone else experiencing this since the beginning of the month. That, to me, isn the place to start.

[CJ_London]

short answer - for me, No.

[moke123]

No for me too.

I expected that because I believe it was caused by an update.

Have you checked your update history?

[Mike505]

Nothing obvious in the last update, I removed it anyway but that did no good.
More sites are reporting this - that makes sense as those sites get updated.

The Access IDE "enables" the code by creating an entry in Security/Trusted Documents/TrustRecords
I can create that same entry in a bat file and it works on my machine but if I use that same bat file on a client site it doesn't help.
It's getting late, will try more tomorrow.

[moke123]

You seem convinced its an update but removing the last update did no good.

You are ignoring our questions. Your description of your set up leaves more questions than it does answers.
I'm not even sure we're talking about the same security warning.

[Mike505]

Problem Solved.

I've always set a Trusted Location path for shared drive S as follows: \\ComputerName\SharedFolder and that has always worked.

After trying everything that I could think of I tried one last thing and it worked. Setting the path to S:\ removed the security warning.
An accdb run from Access 2013 works either way but an accdb run from Access365 or Runtime365 needs S:\

And all of this did start around 7/1/23. Maybe it wasn't a Microsoft update but I can't imagine what else caused it - not in 7 different locations all within the span of 5 days.

[isladogs]

See if my article helps: Is Location Trusted? (isladogs.co.uk)

[Mike505]

That's an interesting article. Thanks, I learned some things especially about code running slower under certain circumstances.

It suggests using Trusted Locations and that is my preferred method but the issue is that the syntax for defining a Trusted Location seems to have changed. I mentioned previously that after uninstalling the update that seemed to have caused this, the problem remained and it was suggested that the update must not have caused the problem. I don't necessarily agree with that. It seems to me that traces of something included in the install may have been missed in the uninstall. That's the only explanation that makes sense to me.

When you have eliminated the impossible, whatever remains, however improbable, must be the truth. – Sir Arthur Conan Doyle

I eliminated one thing and replaced it with something else and that made all the difference.

Thanks to all who responded.

[isladogs]

AFAIAA, the syntax for creating trusted locations in code hasn't changed in all the time that trusted locations have existed (A2007)
I gave an example of a registry script to set a location as trusted in the article.

As an alternative, purchase a code signing certificate and digitally sign your projects