Software Deployment

Hi.
I think you need a "Version = 1.0" along with the stubpath, as a trigger.

/M.N

Value: msiexec /fuavs <guid> /QN

This GUID is the ProductCode of your app right, no necessarily the same as the GUID used in HKLM\software\Microsoft\Active Setup\Installed Components\<guid>.

Fuz

ORIGINAL: fuz_kitten

Value: msiexec /fuavs <guid> /QN

This GUID is the ProductCode of your app right, no necessarily the same as the GUID used in HKLM\software\Microsoft\Active Setup\Installed Components\<guid>.

Fuz


yes it is, the same code as in the "product code" shown in Wise..

Just found the strangest thing, when the app is installed, and i manually run msiexec /fuavs <productcode> it doesn't repair either.
Feels like i'm completely barking up the wrong tree. [&:]

Its not something like the CU stuff is already in a roaming profile so active setup doesn’t run?

Or

the /qn switch is suppressing the UI so it just looks like nothing is happening?

ermmmmmmmmmm, I’m still thinking!

Seems like it does work, under some user accounts, and it doesn't under some. (including members of LA group.. :X ) Think i'm gonna compile the files into an exe, and call the exe using active setup, see if that resolves the problem. Thanks all..!

Hi ne2000,
you missed some important part here:
Where should this files come from, when a standard user logs in, and AS should copy this 2 files to its destination?
Most likely, your standard users do not have access to the MSI source files.
This is best done through the 'DuplicateFiles table'.
Read this post from John McFadyen carefully:
http://itninja.com/question/how-do-you-roll-out-new-machines?4146&mpage=1&key=active%2Csetup幺

Another thing is to be aware that this will only work as a per Computer install. So make sure ALLUSERS is set to 1.
Your msiexec call can't work because it would only work with admin rights!
Value: msiexec /fuavs <guid> /QN
Excerpt from MSDN:
/f [p|o|e|d|c|a|u|m|s|v] Package|ProductCode Repairs a product.
p - Reinstalls only if file is missing.
a - Forces all files to be reinstalled.
u - Rewrites all required user-specific registry entries.
s - Overwrites all existing shortcuts.
v - Runs from source and recaches the local package. Do not use the v reinstall option for the first installation of an application or feature.

A standard user does lack the necessary privileges to do a reinstall with the /f 'a', 's' and 'v' switches.
So far, i all the times used "msiexec /i [ProductCode] REINSTALL=UserSettingsFeature /fup /qn"

Hope this points you on the right track.
Regards, Nick

Nheim/Nick, you set me on the right track..! With the duplicate files, it does seem to work.

However, i do get another issue.. The package does selfrepair now at logon, however, on pc's where the folder is already present in the user profile, the files don't get added to the exisiting folder.. If a user logs on where the folders aren't present, the self repair runs fine..? I'm going to check if settings rights on the directories for the users helps.

Hi ne2000,
what kind of files are we talking about here? Be aware, that there are several rules for file replacement.
In general, you should make sure, that each file has its entry in the MSIFileHash table.
See: http://blogs.msdn.com/astebner/archive/2005/08/30/458295.aspx for an in deep explanation of this.
And make sure, that Active Setup is really running on those profiles. To test it, remove the associated AS entry from the HKCU branch of the registry an logon again.
Make sure, logging is running and get the logfile from the profiles temp folder.
Hope this helps.
Regards, Nick

When I do active setup I always import a Regkey in my msi file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode]]
"Default"=""{[ProductName] [ProductVersion]}""
"StubPath"="msiexec /fup [ProductCode] /qb"

By doing this it´s universal, and the switches (in this case /fup) can be easilly changed)
I have also in some cases trigger some exe files or similar if that have to be done "as the user".

Just a reflection.

Well, actually, the package is supposed to add a default signature to the users signatures.. So it's going to have to add some HTM files (default company signatures) to c:\documents and settings\username$\application data\microsoft\signatures\
The installation of the msi runs when no user is logged on (so after a reboot), to prevent users from having Outlook running at the time of installation. Probably won't cause a big of a deal even IF outlook is running, but just to be on the safe side.. If the folder already exists (EG, the user has started Outlook for the first time or even when i create an empy folder manually), the windows logs tell me that the configuration completed successfully for that user, but no files are placed in the folder. If the folder doesn't exists the repair runs OK.. [&:]
Checked the security rights, users have full control on the folder, so rights can't be the issue either.. And since i'm using the duplicate file table and i'm placing the files in c:\program files\_user\signatures, they get copied from there so the files are always available for the self repair, even when the MSI is not available.

I'm going to check out the website you mentioned.. Thanks for your help!

more often than not people miss the HKCU keypath on the duplicate file component.