Trouble Installing a COM Add-in for Non-Admin Users

[Jim Black]

I have developed a COM Add-in and want to test to ensure that the MSI file
can be installed for non-administrators using the Windows Installer
"advertise" feature. I execute the following as an administrative user:

msiexec -jm MyPackage.msi -L*v MyLogFile.txt

I then reboot the computer, log into a non-admin user account on the same
machine, and launch the Office app. I expected the Windows Installer to
launch as soon at the Office app tried to load the Add-in, but nothing
happens. The Add-in is not visible in the COM Add-Ins list. Checking the
registry, I see none of the registry entries in HKCU that would tell the
Office app (Excel) that my add-in has been advertised. What am I doing
wrong?
--- Jim Black

P.S. The Windows Installer log has some "Note: 1: 2262 2: MsiFileHash 3:
-2147287038" messages on the "msiexec -jm" command, but my research indicates
that 2262 errors may not mean that anything is really wrong. In any event,
the error messages do not give much of a clue!

 

[Bob Eaton]

Just had this one myself.

When you launch the installer via an executable that is running with
administrative user credentials, it maps HKCU to the user key hive of the
admin user account; *not* the Standard user account that you are logged
into.

Interestingly enough, if you just double-click on the .msi file in Explorer
to launch it, it *will* use the Standard User hive as HKCU. But for some
reason, it doesn't if the msi is "launched" via another program that is
being run "as administrator" (in your case, the msiexec in a "run as
administrator" command prompt window and in my case a "master installer" exe
program).

This effectively prevents a setup programs from being installable on a
Standard User account if it needs to modify HKCU (unless your installer is
*just* a .msi which can be double-clicked on to run).

P.S. My workaround solution was to put the keys in HKLM rather than HKCU and
it seems to work (I.e. HKLM\Software\Microsoft\Office\Word\Add-ins\... seems
to work for loading my add-in).

Bob

 

[Jim Black]

Bob,
Thanks for the reply. It's reassuring to see that others are dealing with
this issue. Your information is helpful. However, one of the problems with
falling back to the HKLM solution that you mentioned at the end of your post
is that it does not allow the user to enable/disable the addin via the COM
Addins menu item in Microsoft Office. Only registration under HKCU allows
the user to do this. So if we want to allow the use to temporarily disable
the addin (say, because it's causing the Microsoft Office app to be slow to
load, etc) then we need to find a way to do an HKCU installation. That's why
I've been struggling to find a way to do an HKCU installation for non-admin
users.

 

[Jim Black]

My problem is that I turn the MSI file over to my customers' IT people, and
then it's up to them how they use the MSI file. I need to be able to support
all the standard ways in which they may want to install software for
non-admin users, including running with elevated privileges. From what I
understand, the "advertised install" is a standard way to do this type of
install: the admininstrator "advertises" the Add-In to the non-admin user.
Then when the non-admin user acts on the advertisement (i.e. by launching
MS-Excel) the install is completed under that user's account, putting
everything in HKCU for that user. The trouble is that the standard
advertised MSI file does not put the hooks into the registry that MS Office
needs to find the Add-In in the first place, so the advertise process does
not work. To me this seems like a major oversight on the part of Visual
Studio, and I'm surprised that only you and I are struggling with it!
--
--- Jim Black

The other possibility I toyed with was to set the keys apart from the msi.
For example, you could install a .reg file that contains the keys, and tell
the user that they must double-click on it to install the keys if installing
on a Standard User account. Or, you could have a dummy, non-elevated
privilege .exe that writes the keys using code. It could even then launch
the .msi after it does it's thing via CreateProcess("msiexec..."). [aside:
the reason this won't work for me is because my "master installer" must be
run as Administrator for other reasons, and launching msiexec from an
already elevated application doesn't work].

For that matter, do you absolutely have to run your .msi file via the
elevated privilege exe? As I mentioned in my earlier response, the reason
you had the problem is because you launched msi via the msiexec command
which was run in a command prompt window with elevated credentials. If you
don't launch it via msiexec (or launch it with msiexec, but not from an
elevated command prompt window), then it will set HKCU to the Standard User
account info *even if* during the installation it brings up the admin
credentials dialog box. [it's the difference between the .msi *starting*
with elevated privileges vs. *acquiring* them during its execution. In the
former case, it uses the admin account for HKCU and in the latter case,
it'll use the Standard User account for HKCU].

The bottom line is that you have to get the keys into the registry while you
aren't elevated.

Bob

Bob,
Thanks for the reply. It's reassuring to see that others are dealing with
this issue. Your information is helpful. However, one of the problems
with
falling back to the HKLM solution that you mentioned at the end of your
post
is that it does not allow the user to enable/disable the addin via the COM
Addins menu item in Microsoft Office. Only registration under HKCU
allows
the user to do this. So if we want to allow the use to temporarily
disable
the addin (say, because it's causing the Microsoft Office app to be slow
to
load, etc) then we need to find a way to do an HKCU installation. That's
why
I've been struggling to find a way to do an HKCU installation for
non-admin
users.

 

[Svercek]

Did you guys ever figure out a "reasonable" solution to this issue? I have
been avoiding it for years, however, it appears Vista is finally being
deployed in my industry and I have to make my Outlook Addin installable for a
standard user on Vista.

I have been working with the InstallSheild folks and apparently they are not
aware of any standard solution to the issue. At this point it looks like I
will need two msi files, one to install the user stuff (including manually
adding registry entries), and one for the dlls.

Thanks,

I agree. I think it is a huge oversight and in my opinion the only reason it
hasn't been noticed by more people is because people aren't targeting being
able to install from Standard User accounts (since that wasn't possible in
XP). In fact, I came across the following quote (from
http://www.vistaheads.com/forums/mi...252974-install-application-standard-user.html):

If the application and installer must be validated/certified as
"Vista-ready" than it absolutely cannot and must not be installable by a
standard user. That is utterly contrary to Vista's security model.

Now... maybe he meant, "must not be installable by a standard user *without
being able to provide admin credentials*", but nevertheless, the quote makes
me wonder if I even need to handle this case.

I haven't looked into 'advertised install', but my guess is that if the
standard user launches MS Excel and that automatically launches the msi,
then it probably would work. Remember that I said that if the installer is
run from a non-admin app (such as MS Excel), then it may then ask for admin
account credentials, but even if it does, it should still set HKCU as you
want it to (i.e. for the currently logged in Standard User).

Bob

My problem is that I turn the MSI file over to my customers' IT people,
and
then it's up to them how they use the MSI file. I need to be able to
support
all the standard ways in which they may want to install software for
non-admin users, including running with elevated privileges. From what
I
understand, the "advertised install" is a standard way to do this type of
install: the admininstrator "advertises" the Add-In to the non-admin user.
Then when the non-admin user acts on the advertisement (i.e. by launching
MS-Excel) the install is completed under that user's account, putting
everything in HKCU for that user. The trouble is that the standard
advertised MSI file does not put the hooks into the registry that MS
Office
needs to find the Add-In in the first place, so the advertise process does
not work. To me this seems like a major oversight on the part of Visual
Studio, and I'm surprised that only you and I are struggling with it!
--
--- Jim Black

The other possibility I toyed with was to set the keys apart from the
msi.
For example, you could install a .reg file that contains the keys, and
tell
the user that they must double-click on it to install the keys if
installing
on a Standard User account. Or, you could have a dummy, non-elevated
privilege .exe that writes the keys using code. It could even then launch
the .msi after it does it's thing via CreateProcess("msiexec...").
[aside:
the reason this won't work for me is because my "master installer" must
be
run as Administrator for other reasons, and launching msiexec from an
already elevated application doesn't work].

For that matter, do you absolutely have to run your .msi file via the
elevated privilege exe? As I mentioned in my earlier response, the reason
you had the problem is because you launched msi via the msiexec command
which was run in a command prompt window with elevated credentials. If
you
don't launch it via msiexec (or launch it with msiexec, but not from an
elevated command prompt window), then it will set HKCU to the Standard
User
account info *even if* during the installation it brings up the admin
credentials dialog box. [it's the difference between the .msi *starting*
with elevated privileges vs. *acquiring* them during its execution. In
the
former case, it uses the admin account for HKCU and in the latter case,
it'll use the Standard User account for HKCU].

The bottom line is that you have to get the keys into the registry while
you
aren't elevated.

Bob



Bob,
Thanks for the reply. It's reassuring to see that others are dealing
with
this issue. Your information is helpful. However, one of the
problems
with
falling back to the HKLM solution that you mentioned at the end of your
post
is that it does not allow the user to enable/disable the addin via the
COM
Addins menu item in Microsoft Office. Only registration under HKCU
allows
the user to do this. So if we want to allow the use to temporarily
disable
the addin (say, because it's causing the Microsoft Office app to be
slow
to
load, etc) then we need to find a way to do an HKCU installation.
That's
why
I've been struggling to find a way to do an HKCU installation for
non-admin
users.
--
--- Jim Black


:

Just had this one myself.

When you launch the installer via an executable that is running with
administrative user credentials, it maps HKCU to the user key hive of
the
admin user account; *not* the Standard user account that you are
logged
into.

Interestingly enough, if you just double-click on the .msi file in
Explorer
to launch it, it *will* use the Standard User hive as HKCU. But for
some
reason, it doesn't if the msi is "launched" via another program that
is
being run "as administrator" (in your case, the msiexec in a "run as
administrator" command prompt window and in my case a "master
installer"
exe
program).

This effectively prevents a setup programs from being installable on a
Standard User account if it needs to modify HKCU (unless your
installer
is
*just* a .msi which can be double-clicked on to run).

P.S. My workaround solution was to put the keys in HKLM rather than
HKCU
and
it seems to work (I.e. HKLM\Software\Microsoft\Office\Word\Add-ins\...
seems
to work for loading my add-in).

Bob


I have developed a COM Add-in and want to test to ensure that the
MSI
file
can be installed for non-administrators using the Windows Installer
"advertise" feature. I execute the following as an administrative
user:

msiexec -jm MyPackage.msi -L*v MyLogFile.txt

I then reboot the computer, log into a non-admin user account on the
same
machine, and launch the Office app. I expected the Windows
Installer
to
launch as soon at the Office app tried to load the Add-in, but
nothing
happens. The Add-in is not visible in the COM Add-Ins list.
Checking
the
registry, I see none of the registry entries in HKCU that would
tell
the
Office app (Excel) that my add-in has been advertised. What am I
doing
wrong?
--- Jim Black

P.S. The Windows Installer log has some "Note: 1: 2262 2:
MsiFileHash
3:
-2147287038" messages on the "msiexec -jm" command, but my research
indicates
that 2262 errors may not mean that anything is really wrong. In
any
event,
the error messages do not give much of a clue!