Disable Access 2010 security messages

Your assumption that there is an IT server group, like much of Microsoft's recent design structures, belies the assumption that this is a large company, with all the specialized IT resources to manage group policies. This is, indeed, the direction I have seen MS go with many things (Windows 7, Office 2010, etc): it is relatively easy to manage for very small peer-to-peer networks of perhaps one to four computers where I can just explain to each user what to do. This approach is unworkable when there are 10 computers because it takes too much time to explain it to the individual users; however, it is likewise a fair amount of work to configure Group Policies. With a network of a hundred computers, it is entirely a different matter. While I will stop short of accusing MS of ignoring the small man here, I can say that small- to mid-size networks fall in between the ease of individual-based networks and the ease of Group Policy-based networks having specialized server-side staff. For sure, every time there is an upgrade, there are complex issues far beyond the scope of either programming or small-systems management that I must research and implement.

I will take a look at Group Policies; however, here is the full picture: I am the entire IT group, supporting several small networks (servers, PCs, network/routing, and phones) for companies of different sizes--none of which are interested in hiring server-specific IT groups to manage policies, etc. I also do Access programming for several of them. Some of them are domain-based, some are not. I will also have to look at the impact of distributing Group Policies in mixed environments: Windows XP and 7 with Office/Access full and runtime 2003, 2007, and 2010 on various computers in the same network. I have not used Group Policies for this before, and I suspect that mixed environment may not fit into Group Policies as easily as it may seem.

In the past, it was relatively easy, once I found the appropriate registry entry, to create the setting on one computer, then simply export the .reg file and run it once when installing Access.

Now, instead of just programming and managing infrastructure, I am spending more and more time explaining to people why they get these messages and how to get past them. This pretty much makes me look like an idiot to the end user, so I am just trying to find creative ways to avoid spending all this extra time explaining the issue and tinkering with group policies (for domain-based clients).  Besides that, I have to charge my client for all this setup time, and then they want to know what took so long.

There....that is my opportunity to vent for the day...

Hi, Tom.

I did find the HKLM registry location, and I exported the HKCU entry, then modified it to be placed in the cognate position under HKLM and imported it there, but I still received the warnings until I added it to HKCU.

Do you know how to set a Trusted Location for the entire machine? I will do some more searching on that topic; however, this will involve not just Access, but Excel as well.

I have many users that just want to do their work; they do not need to be bothered with having to deal with security warnings, and I do not need to be bothered explaining the process over and over as new users connect to the computers.

The increasing complexities of managing all of this continues to creep beyond the scope of the small-system application developer, and it just becomes a little frustrating at times.

I am with the originator why make this so complicated.  I too am looking for a registry setting to set HKLM so all users have specific Trusted Locations. 

This can be done using the Office customization tool when modifying an Office 2010 installation package to be distributed to desktops.  Again by large companies with IT staff available for custom packaging of Office 2010. 

If this can be modified during packaging it must be some registry key that I have yet to find.  I also thought to export the appropriate HKCU keys modify to HKLM with no avail.  If there is anyone that can help with this I am sure it would be appreciated by many.

When you created this key in your local machine hive, what was the exact path of the key you were trying to set?  If you just modified the current user path and pointed it to a local machine path (basically substituting HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER), this most likely won’t work if you are on a 64 bit OS and using the 32 bit version of Access 2010.  If you are using a 64 bit OS and the 32 bit version of Access, you will need to use the key within the Wow6432Node.  For example:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access\Security\Trusted Locations\Location9

So if you have a working key within the current user hive, you can export it and modify this .reg file, but when doing so just make sure the key begins with: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node

If you are on a 32 bit OS or you are using the 64 bit version of Office, then just modifying substituting HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER should work.

Best Regards,

Nathan O.

Microsoft Online Community Support

This problem does not seem to go away. The suggested registry setting change did not resolve the issue on our test machines. (XP SP3 and Windows 7.)

The environment is:  Service Pack 1 for Microsoft Access Runtime 2010 installed on XP SP3 or Windows 7 machines with office 2007 or 2003 already installed.

Access 2010 created ACCDB or MDB when launched always shows the “Microsoft Access Security Notice” message.

The Access 2010 created databases are web deployed to many end users. The end users have limited skills sets and won’t use the database due to the “Microsoft Access Security Notice” message.

Regards,

Des

Thank you Nathan. I had everything working with HKEY_Local_Machine but then had to switch from 64-bit to 32-bit. When I did, I couldn't figure out why it wasn't working. It was exactly as you said.

Thanks,

Patrick

Brian,

I'd be interested to know the complexities of file versioning for the varied platform, varied product support you are implementing there... Do you ever have issues where users in Office 11 (2003) open files from say Office 14 (2010) and any embedded VBA modules cease to function or reference libraries refuse to play nice?