Hoping someone can shed some light for me. I have an MSI and MST I'm intending to deploy via GPO computer assignment, but it needs to register its DLL once on every profile in order to work. It's a Microsoft MSI for an Outlook addin that has no entry points, in fact as per an MS document about this problem, even when installed manually on a machine, when I log in with another profile I have to manually regsvr32 its DLL to get it to work on that profile. So I have created an MST that puts in a reg key:
\\HKLM\Software\Microsoft\Active Setup\Installed Components\{ProductGUID} and have two values under here:
Version = 1
StubPath = regsvr32 "C:\Program Files\Microsoft Office\Office10\Addins\Outbak.dll"
(once I get this working I'll make it silent).
So I'm thinking I'm being clever having every profile register this DLL on first log in. However, when I log in with another profile and I check the registry, this key has made it into the HKCU already, but it hasn't run. Huh? Now, if I increase the version number manually in the HKLM then it starts to do the Active Setup on all profile log ins like I want, so I know my syntax is good. But it seems Installer is beating me to the punch and populating the Active Setup portion of the user portion of the registry for every user prior the user logging in OR during their log in but prior to the Active Setup portion. Why when I install this package, which contains no registry keys under HKCU, does it populate HKCU with the Active Setup key (without the StubPath value - in HKCU it lists only the version value)? Isn't the whole point of including Active Setup reg keys in HKLM that when a user logs in and either doesn't yet have a matching user Active Setup key OR a lower version number in their Active Setup key that it will execute the HKLM's StubPath string in that user's context (then update the HKCU with that key so it won't happen again until version is increased in HKLM)?

It boils down to this, what do I need to do to my MSI to make it add the regkey to the HKLM, but not do whatever Installer does to automatically put the same key (without StubPath) into the HKCU of every potential profile? BTW, I figure maybe it's tied to ALLUSERS property, this MSI and MST has no value set for that property.
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


%WINDIR%\system32\regsvr32.exe -i -s "C:\Program Files\Microsoft Office\Office10\Addins\Outbak.dll"
As your Active Setup Entry.. -i for install, -s for silent no msg boxes...

Also one most ( I can't say all) XP boxes ... when a silent active setup runs it will pop up a box which says
Now Setting up.....

<Application Name>

This application name is the Default Value data that you put in the Active Setup Key...The value "@="Application Name" in a regedit export... just a little fyi... otherwise it will show the GUID where the application name is...

The HKCU only stores the Default Value Data and the Version -- maybe a few others... but usually not the stubpath info...

This Launches a Active Setup for each user
HKLM\Software\Microsoft\Active Setup\Installed Components\{ProductGUID}

This key existing means it has run for the user...
HKCU\Software\Microsoft\Active Setup\Installed Components\{ProductGUID}

Most likely you have an incorrect stubpath and windows it attempting to run it but errors, there is no error control on stubpath so it just marks it as executed...

Good luck...
Answered 11/30/2006 by: gmorgan618
Blue Belt

Please log in to comment
a few things here,

1. do you REALLY need to register the DLL for each user? That just seems odd, and I can't think of any program where that would have to be done. you want a per machine installation I'm sure.
2. have you tried putting the dll it in the selfreg table of the msi?
3. usually active setup is used for per user settings, not registering DLLs (see http://www.etlengineering.com/installer/activesetup.txt)
4. definitely better to let windows installer advertised entry point cascade per user settings, if this is possible.
Answered 11/30/2006 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
Thank you both for your responses.

First off, Grant: The StubPath is correct, and works if I manually increase the version number on the HKLM Active Setup value then it starts behaving as expected - meaning the DLL starts registering with each profile log in. So I'm certain my problem is not syntax. Though thanks for pointing out that HKCU key's will be devoid of some values found in the corresponding HKLM key - that makes sense to me as the HKCU key's Version value is the only value needed to compare against HKLM during Active Setup.

Owen, I appreciate your advice here. I will investigate how to use SELF REG to have this DLL register properly. Though will this take care of things for me considering the package is still just an addin with no advertised shortcuts, file associations or any entry points? I figure I might still need to use Active Setup to get this thing to work on each profile on the computer. Yes, I want per-machine installation. Do you have any idea why this package seems to make the HKCU key without actually executing the StubPath of my HKLM key? That's the thing that's really confusing me. Maybe I'm missing something basic here - what are the basics to configuring the MSI for per-machine installation?

And lastly, if I can figure out how to deliver a working Active Setup registry key in the MSI, and I opt to use a StubPath of something like MSIEXEC /fup {GUID} /qb will I need to specify the MST in that statement? If so, how?

Thanks again,

Answered 11/30/2006 by: fosteky
Purple Belt

Please log in to comment
Just had a little look myself at what the outbak.dll puts specifically in the HKCU registry upon registration and established the following (this is in an Office 10 environment BTW)

"FileName"="C:\\Program Files\\Microsoft Office\\OFFICE10\\ADDINS\\outbak.dll"
"FriendlyName"="Outlook Backup Addin"

which would account for why you have had to register the DLL for each user up until now.

So if you create a component in your transform to hold the above settings, make one of the values a keypath, then you can take a more conventional approach to using Active Setup - i.e. the msiexec /fup {ProductCode} discussed several times in this forum.

To answer your last question, you do not need to specify the transform in the repair string, Windows Installer will work out which cached transform it needs to use (if any) when the Active Setup triggers.


Answered 12/01/2006 by: spartacus
Black Belt

Please log in to comment
Where you able to resolve this issue? I am having same problem when logged in as admin user active install created an entry in HKCU only with version number and no StubPath. When logged in as a regular user then active setup work fine?
Any help?
Thank you.
Answered 05/14/2007 by: ogeccut
Black Belt

Please log in to comment