forcing local cache from network install
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?
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
[ + ] Show comments
Answers (7)
Please log in to answer
Posted by:
nheim
16 years ago
Hi Tom,
you're almost there...
Please, read this post from John McFadyen carefully:
http://itninja.com/question/how-do-you-roll-out-new-machines?4146
You need to cascade your features and set the right component keys to make this work.
Hope this helps.
Regards, Nick
you're almost there...
Please, read this post from John McFadyen carefully:
http://itninja.com/question/how-do-you-roll-out-new-machines?4146
You need to cascade your features and set the right component keys to make this work.
Hope this helps.
Regards, Nick
Posted by:
tmountjr
16 years ago
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?
*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?
Posted by:
anonymous_9363
16 years ago
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
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
Posted by:
AngelD
16 years ago
tmountjr,
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.
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.
Posted by:
rlgura
16 years ago
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
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
Posted by:
jmcfadyen
16 years ago
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.
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.
Posted by:
anonymous_9363
16 years ago
objInstaller.AddSource(productcode,username,addsource)
UserName is generally the user's login name, in my experience or you can simply pass a null string:
objInstaller.AddSource(productcode,"",addsource)
UserName is generally the user's login name, in my experience or you can simply pass a null string:
objInstaller.AddSource(productcode,"",addsource)
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.