I've been repackaging WinDVD 7 as an MSI because it seems that's the only way to install it with our volume licensing key. In the process, I found that it copies wholesale the entire HKLM\Software\InterVideo key over to HKCU\Software\Intervideo, then adds a key to that user specifically indicating that it's been registered (or at least that it kicked off the registration screen, even if the user chose not to register). I followed the directions here on creating a self-healing MSI, and it works like a charm - Windows Installer kicks off for each new user to insert that registration key from the souce MSI.

The problem is that, in our environment, a tech would install the MSI from a server that's not available to anyone outside IT. Is there are way to force the MSI to cache itself on the hard drive and use that cache location for any subsequent repairs?
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


Hi Tom,
you're almost there...
Please, read this post from John McFadyen carefully:
You need to cascade your features and set the right component keys to make this work.
Hope this helps.
Regards, Nick
Answered 08/29/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
The problem is that the registry information it's attempting to heal is stored in the MSI, not as a file in the media table. As I said, the healing starts just fine, but it pops up a dialog box saying it can't find "z:\packages\windvd_7\windvd.msi" and asking me to find a comparable .msi file to use.

*UPDATE* I just looked in c:\windows\installer and found the MSI it left (c:\windows\installer\2dcef4.msi). I opened it up in Orca and the registry key is there. How do I tell it not to use the original installation source (z:\, a mapped network drive) and use the one that the installer left behind locally?
Answered 08/29/2007 by: tmountjr
Senior Yellow Belt

Please log in to comment
From memory, I think you could "edit" the SourceList entry for the MSIs in the local registry. First off, use the guts of the script which Kim posted earlier today to get the MSI name (http://itninja.com/question/migrate-2000-professional-workstation-snmp192) then copy that info to the SourceList. If you don't want to roll your own script this one (http://desktopengineer.com/msisources?op=makePrintable&styleId=1010) may be helpful.

Sorry: the 'link' button doesn't seem to be working for me so the links here don't actually work: you'll need to CAP them into your browser
Answered 08/29/2007 by: VBScab
Red Belt

Please log in to comment

Repairing registry doesn't require the original MSI, only files and custom actions that explicit does so.
I would first try to find out which components that requires the original MSI instead of the cached one or CAs.

Look in the Event Viewer or generate a verbose log during repair to investigate whats triggering the original MSI.
Answered 09/02/2007 by: AngelD
Red Belt

Please log in to comment
I have the opposite problem - when I push installs, a user cannot use the network copy to uninstall or repair because the app was installed locally. Windows Installer has a property called InstallSource that you can specify multiple locations to your source MSI:

MSIEXEC /I "\\SVR1\myapps\sourcefiles\myapp1.msi" /QB SOURCELIST=”\\SVR1\myapps\sourcefiles;\\SVR2\myapps\sourcefiles;C:\myapps\sourcefiles”

I think you'll have to manually copy down a copy of the MSI because it needs to be named the same as the original install file.

Alternately, you could use a VBScript to
1) Copy the MSI to a local location (C:\myapps\sourcefiles)
2) Launch the installation from that location
Then just instruct your techs to use the VBscript instead of the MSI directly
Answered 10/08/2007 by: rlgura
Senior Yellow Belt

Please log in to comment
Windows Installer 3 supports easily changing the source pointers of an installed MSI.

set objInstaller = CreateObject("Windowsinstaller.Installer")
set objInstaller.AddSource("ProductCode", "SourceList")

you may want to check the syntax in the SDK I rattled this out from memory.
Answered 10/11/2007 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment

UserName is generally the user's login name, in my experience or you can simply pass a null string:

Answered 10/11/2007 by: VBScab
Red Belt

Please log in to comment