Making Addins installable by non-admin users

[Mark J. McGinty]

Greets,

Until the other day I had thought my AddIn was installable by non-admin
level users, but I see from tests this is not the case. Even if they use
runas to execute the installer they are still out of luck -- the AddIn
installs for the user specified in the runas dialog, but not the
unprivileged user.

At the heart of the problem, I suspect, is that regsvr32 fails (error 5,
access denied) when executed by an unprivileged user. And even when it has
already been run by a privileged user (and the AddIn's ProgIds are in the
registry) the unprivileged user cannot load or connect to the AddIn using
the COM AddIns dialog.

If I temporarily make the unprivileged user an admin, installation succeeds
and the AddIn continues to work after removing the user from the
Administrators group -- so I know that it is not something in the AddIn's
code that requires admin privileges.

I am guessing that its self-registration attempts to alter HKCR first, and
then HKCU second -- otherwise, logically, it should be able to succeed if
its ProgIds have already been registered.

Is there any way around this behavior? (env = VB6)


TIA,
Mark

 

[Mark J. McGinty]

I found the answer, using RegMon from sysinternals.com, and by conducting a
few experiments...

Greets,

Until the other day I had thought my AddIn was installable by non-admin
level users, but I see from tests this is not the case. Even if they use
runas to execute the installer they are still out of luck -- the AddIn
installs for the user specified in the runas dialog, but not the
unprivileged user.

At the heart of the problem, I suspect, is that regsvr32 fails (error 5,
access denied) when executed by an unprivileged user. And even when it
has already been run by a privileged user (and the AddIn's ProgIds are in
the registry) the unprivileged user cannot load or connect to the AddIn
using the COM AddIns dialog.

If I temporarily make the unprivileged user an admin, installation
succeeds and the AddIn continues to work after removing the user from the
Administrators group -- so I know that it is not something in the AddIn's
code that requires admin privileges.

I am guessing that its self-registration attempts to alter HKCR first, and
then HKCU second -- otherwise, logically, it should be able to succeed if
its ProgIds have already been registered.

This is, in fact, the case.

Is there any way around this behavior? (env = VB6)

Yes, there is, given that the COM registrations for the AddIn object have
been performed, all that's necessary is to merge (or create using registry
API the following:

[HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\YourAddIn.ExtensibilityClass]
"FriendlyName"="YourAddIn"
"Description"="Description of your AddIn"
"LoadBehavior"=dword:00000003
"CommandLineSafe"=dword:00000000

The string "YourAddIn" is a place holder for the name of your AddIn.
"ExtensibilityClass" is a place holder for the name of either the AddIn
Designer [class] module ("Connect" by default), or the class in your AddIn
project that implements IDTExtensibility2.


-Mark