Access 2007 Runtime – Security & Trusted Locations

[Brad]

We are starting to roll out a new Access 2007 application to a number of
users who only have “Access 2007 Runtime†and not the full version of Access
2007.

The new application works fine, but each time a user opens up the
application they receive the message “A Potential Security Concern Has Been
Identified†…etc.

With the Runtime version it appears that we cannot simply add a Trusted
Location on our users’ PCs.

Is there an easy way to suppress this message or to add a Trusted Location
via an alternative method?

Thanks,
Brad

 

[Arvin Meyer [MVP]]

Here's some code that MVP Graham Mandeno wrote to create a Trusted Location:

Public Function CreateTrustedLocation( _
Key As String, _
Path As String, _
Optional AllowSubfolders As Boolean, _
Optional Description As String, _
Optional Version As Integer = 12) As Boolean

Const cProcName = "CreateTrustedLocation"

Dim reg As New Registry, hk As Long
On Error GoTo ProcErr
With reg
hk = .OpenKey(HKEY_CURRENT_USER, _
"Software\Microsoft\Office\" & Version _
& ".0\Access\Security\Trusted Locations\" & Key, True)
.SetValue hk, "", "Path", Path

' Also try: .SetValue hk + 1, "", "Path", Path

.SetValue hk, "", "AllowSubfolders", IIf(AllowSubfolders, 1, 0)
.SetValue hk, "", "Description", Description
.CloseKey hk
End With
CreateTrustedLocation = True

ProcEnd:
On Error Resume Next
If hk <> 0 Then reg.CloseKey hk
Set reg = Nothing
Exit Function

ProcErr:
mb_Error cProcName
Resume ProcEnd
End Function

 

[Brad]

Arvin,

Thanks for the assistance, I appreciate it.

I have come from the IBM mainframe world to the realm of Windows, so the
Registry is still somewhat of a mysterious animal to me. I plan to dig into
it as I have never needed to add an entry to it until now.

Do you know where I could find an example of VBA code that calls Graham
Mandeno’s function. I am not 100% clear about the fields that are being
passed to it. Because of my lack of experience with the Registry, I am a bit
gun-shy to experiment without fully knowing what I am doing.

Thanks again


Brad

 

[Graham Mandeno]

Hi Brad

I think that code has been lifted out of context from somewhere, because it
calls a class module "Registry" that is obviously not included.

Basically, the concept is quite simple. You create a new key at the
following location:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\Trusted
Locations

(that line probably wrapped, but it's all one registry key path)

The name of the key can be anything, so it might as well be the name of the
app.

The values under the key are:
- Path : the fill path to the trusted location
- AllowSubfolders : 1 to trust any subfolders of Path (optional)
- Description : anything you like (optional)
- Date : haven't figured out the use for this (optional)

The code that Arvin posted will create such a key, provided it includes the
Registry class module. The problem is that to put it in the database which
you want to trust is a sort of a Catch-22, because in order to execute the
code, you first have to create the trusted location.

Because of this, the code is rather useless, unless you are creating trusted
locations for other databases.

What I do is create this registry key in my install script. Any install
script worth its salt (I use Inno Setup) can create registry keys as part of
the installation.

It would also be very easy to create a small .REG file to create the
required key. Something like this:

========== start REG file ==============
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\Trusted
Locations\MyApp]
"Path"="C:\\MyApp"
"AllowSubfolders"=dword:00000001
"Description"="My trusted location"
========== end REG file ==============

Note that the part in the square brackets [HKEY...MyApp] should be all one
line. Just change "MyApp" to the name of your application, and change the
path and description (any \ in the path needs to be \\) and paste into a
textfile named TrustedLocation.reg.

--
Good Luck

Graham Mandeno [Access MVP]
Auckland, New Zealand

 

[Arvin Meyer [MVP]]

Hi Brad

I think that code has been lifted out of context from somewhere, because
it calls a class module "Registry" that is obviously not included.

Hmm. I had to have lifted it from something you wrote, or I wouldn't have
known to whom to attribute it. I know I haven't used it, but since you
always write great code (yes, I have several other snippets) I never thought
to question it. So where's the class module?

 

[Brad]

Graham,

Thanks for your assistance. I really appreciate your thorough explanation.
I started to experiment with the registry on my PC at home last night. It
doesn’t look so mysterious now that I have dug into it a bit.

Thanks again,

Brad

Hi Brad

I think that code has been lifted out of context from somewhere, because it
calls a class module "Registry" that is obviously not included.

Basically, the concept is quite simple. You create a new key at the
following location:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\Trusted
Locations

(that line probably wrapped, but it's all one registry key path)

The name of the key can be anything, so it might as well be the name of the
app.

The values under the key are:
- Path : the fill path to the trusted location
- AllowSubfolders : 1 to trust any subfolders of Path (optional)
- Description : anything you like (optional)
- Date : haven't figured out the use for this (optional)

The code that Arvin posted will create such a key, provided it includes the
Registry class module. The problem is that to put it in the database which
you want to trust is a sort of a Catch-22, because in order to execute the
code, you first have to create the trusted location.

Because of this, the code is rather useless, unless you are creating trusted
locations for other databases.

What I do is create this registry key in my install script. Any install
script worth its salt (I use Inno Setup) can create registry keys as part of
the installation.

It would also be very easy to create a small .REG file to create the
required key. Something like this:

========== start REG file ==============
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\Trusted
Locations\MyApp]
"Path"="C:\\MyApp"
"AllowSubfolders"=dword:00000001
"Description"="My trusted location"
========== end REG file ==============

Note that the part in the square brackets [HKEY...MyApp] should be all one
line. Just change "MyApp" to the name of your application, and change the
path and description (any \ in the path needs to be \\) and paste into a
textfile named TrustedLocation.reg.

--
Good Luck

Graham Mandeno [Access MVP]
Auckland, New Zealand

Arvin,

Thanks for the assistance, I appreciate it.

I have come from the IBM mainframe world to the realm of Windows, so the
Registry is still somewhat of a mysterious animal to me. I plan to dig
into
it as I have never needed to add an entry to it until now.

Do you know where I could find an example of VBA code that calls Graham
Mandeno's function. I am not 100% clear about the fields that are being
passed to it. Because of my lack of experience with the Registry, I am a
bit
gun-shy to experiment without fully knowing what I am doing.

Thanks again


Brad

 

[Graham Mandeno]

Hi Arvin

Yes, it certainly is my code. I think I posted it in a discussion in the
private NG a year or so back with the caveat (probably implied <g>) that it
had dependencies.

I figured an audience of our MVP colleagues would understand what the
methods OpenKey, SetValue and CloseKey were doing.

I could post the class module, but it, too, has dependencies to common error
handling code and such-like. I'll see if I can clean it up and make it
stand-alone for you to publish on the Access Web.

There are heaps of examples on the web of reading and writing registry data
from VB(A). The OP can just google "declare function regsetvalueex".

Cheers,
Graham

 

[Arvin Meyer [MVP]]

I could post the class module, but it, too, has dependencies to common
error handling code and such-like. I'll see if I can clean it up and make
it stand-alone for you to publish on the Access Web.

It would be a most welcome addition.

 

[Arvin Meyer [MVP]]

More than 12 years ago. I went to classes to achieve the MCSE certification.
The instructor's words still ring in my mind:

"The registry is a place where only fools and gurus go"

I've never thought of myself as a guru <g>, but I am comfortable in the
registry. Those words still inhibit me from making suggestions to others
that they dink around in the registry. If you are comfortable, go for it, it
really isn't all that hard. After all, if the word happens, you just need to
reinstall everything. A pain to be sure, but not the end of the world.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

Graham,

Thanks for your assistance. I really appreciate your thorough
explanation.
I started to experiment with the registry on my PC at home last night. It
doesn't look so mysterious now that I have dug into it a bit.

Thanks again,

Brad

Hi Brad

I think that code has been lifted out of context from somewhere, because
it
calls a class module "Registry" that is obviously not included.

Basically, the concept is quite simple. You create a new key at the
following location:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\Trusted
Locations

(that line probably wrapped, but it's all one registry key path)

The name of the key can be anything, so it might as well be the name of
the
app.

The values under the key are:
- Path : the fill path to the trusted location
- AllowSubfolders : 1 to trust any subfolders of Path (optional)
- Description : anything you like (optional)
- Date : haven't figured out the use for this (optional)

The code that Arvin posted will create such a key, provided it includes
the
Registry class module. The problem is that to put it in the database
which
you want to trust is a sort of a Catch-22, because in order to execute
the
code, you first have to create the trusted location.

Because of this, the code is rather useless, unless you are creating
trusted
locations for other databases.

What I do is create this registry key in my install script. Any install
script worth its salt (I use Inno Setup) can create registry keys as part
of
the installation.

It would also be very easy to create a small .REG file to create the
required key. Something like this:

========== start REG file ==============
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\Trusted
Locations\MyApp]
"Path"="C:\\MyApp"
"AllowSubfolders"=dword:00000001
"Description"="My trusted location"
========== end REG file ==============

Note that the part in the square brackets [HKEY...MyApp] should be all
one
line. Just change "MyApp" to the name of your application, and change
the
path and description (any \ in the path needs to be \\) and paste into a
textfile named TrustedLocation.reg.

--
Good Luck

Graham Mandeno [Access MVP]
Auckland, New Zealand

Arvin,

Thanks for the assistance, I appreciate it.

I have come from the IBM mainframe world to the realm of Windows, so
the
Registry is still somewhat of a mysterious animal to me. I plan to dig
into
it as I have never needed to add an entry to it until now.

Do you know where I could find an example of VBA code that calls Graham
Mandeno's function. I am not 100% clear about the fields that are
being
passed to it. Because of my lack of experience with the Registry, I am
a
bit
gun-shy to experiment without fully knowing what I am doing.

Thanks again


Brad


:

Here's some code that MVP Graham Mandeno wrote to create a Trusted
Location:

Public Function CreateTrustedLocation( _
Key As String, _
Path As String, _
Optional AllowSubfolders As Boolean, _
Optional Description As String, _
Optional Version As Integer = 12) As Boolean

Const cProcName = "CreateTrustedLocation"

Dim reg As New Registry, hk As Long
On Error GoTo ProcErr
With reg
hk = .OpenKey(HKEY_CURRENT_USER, _
"Software\Microsoft\Office\" & Version _
& ".0\Access\Security\Trusted Locations\" & Key, True)
.SetValue hk, "", "Path", Path

' Also try: .SetValue hk + 1, "", "Path", Path

.SetValue hk, "", "AllowSubfolders", IIf(AllowSubfolders, 1, 0)
.SetValue hk, "", "Description", Description
.CloseKey hk
End With
CreateTrustedLocation = True

ProcEnd:
On Error Resume Next
If hk <> 0 Then reg.CloseKey hk
Set reg = Nothing
Exit Function

ProcErr:
mb_Error cProcName
Resume ProcEnd
End Function
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


We are starting to roll out a new Access 2007 application to a
number
of
users who only have "Access 2007 Runtime" and not the full version
of
Access
2007.

The new application works fine, but each time a user opens up the
application they receive the message "A Potential Security Concern
Has
Been
Identified" .etc.

With the Runtime version it appears that we cannot simply add a
Trusted
Location on our users' PCs.

Is there an easy way to suppress this message or to add a Trusted
Location
via an alternative method?

Thanks,
Brad

 

[David W. Fenton]

More than 12 years ago. I went to classes to achieve the MCSE
certification. The instructor's words still ring in my mind:

"The registry is a place where only fools and gurus go"

I've never thought of myself as a guru <g>, but I am comfortable
in the registry. Those words still inhibit me from making
suggestions to others that they dink around in the registry. If
you are comfortable, go for it, it really isn't all that hard.
After all, if the word happens, you just need to reinstall
everything. A pain to be sure, but not the end of the world.

Back in the days of Win95, when most of us first really got our feet
wet with the system registry (I'd already encountered it in Win3.x
running Office, which was highly dependent on the system registry,
since it was already all COM, though it was called OLE back then),
and back then, it really did seem to be pretty fragile.

Since then, it's gotten much better.

I once accidentally deleted the entire Windows registry key on a
client's PC. The machine actually booted to the GUI, though almost
nothing worked properly. I was able to run system setup again and
fix it (and the machine ran blazingly fast after that!), but it did
tell me something about the robustness of Win9x and the registry.

These days, I edit the registry all the time and almost never make
any backups. It's really easy to backup a registry before
editing/deleting it, so I should to that all the time, but almost
never do.

On a client's machine that would install but not run Google Desktop
(I would never recommend it, but the client had come to depend on
it), I recently cleaned out all references to Google applications
from the registry (after running all uninstallers and deleting all
program folders related to Google apps). It was tedious, using
Ctrl-F to find all instances of "google" in the registry and
deciding which ones to delete and which ones not, but it did the
job.

A few months ago I had to do a major registry edit with a client's
QuickBooks installation. Using FIND, I edited something like a
thousand registry keys by hand (I had no Internet connection and
lacked my usual registry search/replace tools). I assumed I would
have made some mistakes, but the client never reported a single
error (and this wasn't just deleting keys, but editing a path that
had been input wrong and couldn't be gotten rid of because of the
awful way in which QB uses the registry to store app paths).

Like you, I don't recommend it to anyone else, but I feel perfectly
comfortable making the edits, precisely because I've been doing it
for so long without killing any PCs.

So far...