VB6 Outlook Com Addin cant access registry or utilize shell execute

[OutlookDevSLC]

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

 

[Ken Slovak - [MVP - Outlook]]

It's hard to know where to start.

You should not be installing your addin dll to \System32, it should be
installed either in a user specific area such as LocalAppData or in Program
Files. You should not assume a user has permissions to write to HKLM or that
your code can do that. If you need settings other than those needed for COM
addin registration you should install them in HKCU or in LocalAppData.

Group permissions aren't the only things that are going to mess up what
you're doing, so will Vista and many AV and other programs with script
stoppers. I forsee a neverending parade of problems that could be avoided if
you don't do those things.

InstallShield lets you set up target registry settings in UserSelectable,
HKCU, HKLM, etc. so there never should be a need to jump the hoops you're
jumping. Why not just put the keys you need in the InstallShield target HKLM
and have done with it? Then when the installer runs the addin will be
registered in HKLM as well as HKCU if you set that in InstallShield or by
using a designer.

What are you running with ShellExecute? I'm not at all clear on that. If you
are attempting to run the addin DLL then why? The addin running should be
controlled by the LoadBehavior key of the addin registration. I'm afraid I
don't understand the logic of what you're doing at all. None of my VB6
addins (well over 100) have had to do anything like that even when I want to
register them for all users.

 

[OutlookDevSLC]

It's hard to know where to start.

You should not be installing your addin dll to \System32, it should be
installed either in a user specific area such as LocalAppData or in Program
Files. You should not assume a user has permissions to write to HKLM or that
your code can do that. If you need settings other than those needed for COM
addin registration you should install them in HKCU or in LocalAppData.

Group permissions aren't the only things that are going to mess up what
you're doing, so will Vista and many AV and other programs with script
stoppers. I forsee a neverending parade of problems that could be avoided if
you don't do those things.

InstallShield lets you set up target registry settings in UserSelectable,
HKCU, HKLM, etc. so there never should be a need to jump the hoops you're
jumping. Why not just put the keys you need in the InstallShield target HKLM
and have done with it? Then when the installer runs the addin will be
registered in HKLM as well as HKCU if you set that in InstallShield or by
using a designer.

What are you running with ShellExecute? I'm not at all clear on that. If you
are attempting to run the addin DLL then why? The addin running should be
controlled by the LoadBehavior key of the addin registration. I'm afraid I
don't understand the logic of what you're doing at all. None of my VB6
addins (well over 100) have had to do anything like that even when I want to
register them for all users.















- Show quoted text -

Thanks for responding so quickly Ken. The installation is not one of
my design though I have made significant changes to it. During the
installation the user enters profile data (First Name, Last Name,
ect.) unfortunately since the user isnt the one installing the
application if the data isnt stored in HKLM the intended restricted
users profile wont have access to the profile data entered during the
install once they log onto their restricted profile. Hence the reason
I was writing user specific data to a non user specific hive. I could
perhaps write an additional function that moves the profile data from
HKLM to HKCU and then deletes the HKLM entries but that assumes I wont
run into the same problem accessing HKLM...I will work to move the
location of the registry value written by the button click to HKCU to
prevent the complications you have outlined.

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

To elaborate further on the intended design when the button is clicked
the value that is written to the registry acts as a state switch. Once
the state switch has been set in the registry a seperate executable is
called via shellexecute that reads the state switch and loads to the
appropriate form then resets the state switch. Version 2 of the plugin
is a work in progress and will no longer require information be
entered during installation but rather on first launch in the meantime
however I would like to get the current version to an acceptable
functional level with out too much work on the installer. Im willing
to do what must be done any input would be greatly appreciated.

Brandon

 

[Ken Slovak - [MVP - Outlook]]

My only opinion on this is that it's a mess and should be re-architected.
Just about the worst way of doing things has been carefully selected at
almost every step of the process. Like I said originally it's hard to know
even where to start. A day or so of re-design should solve many, many days
of troubleshooting.

 

[OutlookDevSLC]

My only opinion on this is that it's a mess and should be re-architected.
Just about the worst way of doing things has been carefully selected at
almost every step of the process. Like I said originally it's hard to know
even where to start. A day or so of re-design should solve many, many days
of troubleshooting.




<snip>







- Show quoted text -

Understood I will begin the process. My plans so far are as follows if
i have missed something please feel free to make suggestions.

So far.

I will move the MyAddin.dll from system32 into the app program files
folder.
I will move all entries besides the entry that registers the plugin
for all users with Outlook from HKLM to HKCU.
I will then move the profile creation screen from the installer to the
first addin launch overcoming the need to place profile data in HKLM.

Thanks once again,
Brandon

 

[Ken Slovak - [MVP - Outlook]]

Now that sounds like a plan...