I have written a Com Add-in for Outlook. The plugin adds a toolbar
with multiple buttons to the explorer on the Outlook open event. When
the buttons are clicked a value is written to the users registry.

objRegistrySettings.RegWrite HKEY_LOCAL_MACHINE, "SOFTWARE\AddinName
\Settings", Button1, "1"


After the value is written to the registry shellexecute is called.

' Start application
If ShellExecute(0, "open", AppPath & "\" & APP_EXECUTABLE, APP_VERSION
& "|" & CMDLINE_START_APPLICATION, "", SW_NORMAL) 32 Then
' Display error message
MsgBox LoadResourceString(MSG_CANNOT_START_APPLICATION), vbCritical,
App.Title
' Reset the registry key
objRegistrySettings.RegWrite HKEY_LOCAL_MACHINE, "SOFTWARE\AddinName
\Settings", Button1, "0"
End If

The plugin functions as expected when installed on a machine that is
not part of a domain environment. Unfortunately when installed on a
machine that is part of a domain where the user is subject to the
domain security settings the registry write and shellexecute
statements fail. When I say fail what I mean is despite no error
message no value is written to the registry and when the shellexecute
statement is reached a message pops up saying the file could not be
found it may not exist or you may not have sufficient privilege to
access the file. Assuming this was the result of the domain
restrictions I spent some time working with the user and found that he
had sufficient privilege to execute from the folder the file
shellexecute is pointing too. I also confirmed with the user that he
could create a folder with in that particular folder using windows
explorer. I then also confirmed that the user had delete access by
having him delete the folder we had created. At this point having
confirmed the user has sufficient privilege to execute, write, and
delete I decided to check on his registry access level. The user was
able to manually edit his registry using regedit. He was able to
create and delete a new key in the specified location in the registry
as well as modify the current value of the key whose value is not
being changed.

At this point Im not sure where to go next. Outside of the CommAddin
the user can execute files and write to the registry in the specific
desired locations. Does Outlook decrease the security permissions of
ComAddins to be more strict than the users current profile security
settings?

I understand the reasons for wanting to use HKCU to store settings
since this particular hive is specific to the user currently logged
in. The situation is this. I have an Installshield Script Installation
that installs the plugin and registers the appropriate support files.
One of the things this Installer does is place the Outlook .dll in
"Windows/system32" and then register it using regsvr32 MyAddin.dll.
Unfortunately in the domain environment this solution was designed for
it is necessary for the addin to be installed by an administrator
since the end users will be restricted users and dont have install
privileges. IT doesnt seem to want to temperarily elevate the users
profile privilege to allow installing. This created a situation where
I needed to register the plugin for use for all users including the
restricted users the administrator is installing for. The problem then
became where can the registry entries be placed so that all users
(restricted users) will have the plugin available to them when they
login. Using the method outlined above regsvr32 MyPlugin.dll registers
the plugin with the HKCU hive and therefor registering it only with
the current user so that didnt fit my purpose. I added to the
Installer a function that adds the appropriate registry entries in the
HKLM hive but unfortunately if regsvr32 MyAddin.dll wasnt run in
addition to the manual HKLM entries to register the plugin it wouldnt
load for all users. I found however that if i did both manually
register the plugin under HKLM and register it to HKCU using regsvr32
MyAddin.dll it accomplished the purpose of registering the plugin for
all users( a side affect being that the users all do not see the
plugin available for enable\disable ). As you can see the situation is
a bit environment specific. I believe I have overcome all challenges
except the restriction to registry and shellexecute. Any help would be
much appreciated.

Brandon