Making Addins installable by non-admin users

  • Thread starter Thread starter Mark J. McGinty
  • Start date Start date
M

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
 
I found the answer, using RegMon from sysinternals.com, and by conducting a
few experiments...

Mark J. McGinty said:
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.
Click to expand...

This is, in fact, the case.

Is there any way around this behavior? (env = VB6)
Click to expand...

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
 
Back
Top