Making Addins installable by non-admin users

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

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

"Mark J. McGinty" <mmcginty.RemoveThis@spamfromyou.com> wrote in message
news:%23eefheH0HHA.5644@TK2MSFTNGP05.phx.gbl...
> 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




> TIA,
> Mark
>