MSP Patching looking for original MSI
I have recently installed Adobe Reader X (10.1.0) using an MSI installation deployed via SCCM across my company (about 600 clients). Now, I would like to deploy the Adobe Reader 10.1.1 patch to these clients. Adobe provides this patch as an MSP file.
So, I deploy the MSP file using SCCM, and it runs this command line on the client computers: msiexec /p Reader1011Patch.msp /qb /norestart. But, I am getting this error on the client machines: "The feature you are trying to use is on a network resource that is unavailable. Enter the path to a folder containing acroread.msi". The message then lists the source path it is checking: "C:\Windows\System32\CCM\Cache\######".
Now, I know what is happening is that the MSP installation is looking for the original MSI that was used to install Adobe Reader in the first place. That MSI used to be in the SCCM cache folder, but has since been cleaned out to make room for other programs to be installed via SCCM, which is normal expected behavior.
What I am asking is: Is there a way to install MSI products so that future MSP patches do not need to look for the original MSI in the SCCM cache folder? I have seen this problem with other products in the past, so maybe there is something that I can do differently to prevent this?
So, I deploy the MSP file using SCCM, and it runs this command line on the client computers: msiexec /p Reader1011Patch.msp /qb /norestart. But, I am getting this error on the client machines: "The feature you are trying to use is on a network resource that is unavailable. Enter the path to a folder containing acroread.msi". The message then lists the source path it is checking: "C:\Windows\System32\CCM\Cache\######".
Now, I know what is happening is that the MSP installation is looking for the original MSI that was used to install Adobe Reader in the first place. That MSI used to be in the SCCM cache folder, but has since been cleaned out to make room for other programs to be installed via SCCM, which is normal expected behavior.
What I am asking is: Is there a way to install MSI products so that future MSP patches do not need to look for the original MSI in the SCCM cache folder? I have seen this problem with other products in the past, so maybe there is something that I can do differently to prevent this?
0 Comments
[ + ] Show comments
Answers (6)
Please log in to answer
Posted by:
jmaclaurin
13 years ago
The whole nature of MSI based apps is the ability to maintain resilience and the integrity of the install which requires the original media/source. Don't delete the source or, surprise, you will get this problem with patching, repairs or even uninstalls. Use a UNC path in your installs and leave the source folder on a network or DFS share, or for that matter, I am sure that your machines are coming with 500gb drives now, why clean up ever?
On the outside, you could attempt to recache the install by using the REINSTALL=ALL switch while using the original source files, but in a different location. You could also attempt to do this if you apply the MSP to your administrative install point, but again, you will likely need the original install source.
Something like:
msiexec /i setup.msi REINSTALL=ALL REINSTALLMODE=VOMUS
My 1cent, keeping the other for gas.
On the outside, you could attempt to recache the install by using the REINSTALL=ALL switch while using the original source files, but in a different location. You could also attempt to do this if you apply the MSP to your administrative install point, but again, you will likely need the original install source.
Something like:
msiexec /i setup.msi REINSTALL=ALL REINSTALLMODE=VOMUS
My 1cent, keeping the other for gas.
Posted by:
jbottcher
5 years ago
I have tried modifying the reg key. That works for Adobe Reader, but not for Acrobat Pro. I incorporated the REINSTALL=ALL REINSTALLMODE=VOMUS into my script and worked great. I use a single powershell script to install or patch my Adobe Acrobat. works great
Posted by:
EdT
5 years ago
There is a simple solution for this which I documented on the Symantec Connect forums many years ago.
All you have to do is remember that since Windows 7, the ENTIRE msi is cached under C:\windows\installer as otherwise a code signed MSI is broken by having the internal CABS removed and will fail on uninstall. So then all you need to do is include the cached location under C:\Windows\Installer in the sourcelist.
The technique is described here:
https://www.symantec.com/connect/articles/reducing-windows-installer-disk-wastage-windows-7
There is absolutely no sense in storing another copy of the MSI on the hard disk.
Posted by:
fitzgerac
13 years ago
Thanks for the response. So there is no way to instruct msiexec at install time to cache the source files on the local machine in an alternate directory? The original source is in a shared network folder, but because the product was installed from the SCCM cache, that location is saved as the source location. Is there a way to set the original source path at install?
UPDATE: I see that there is an InstallSource value in the registry at HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<Product GUID> that references the SCCM cache (in this example). Do you know if I could install products using a command like "acroread.msi /qb INSTALLSOURCE=\\server\AdobeReaderSource"?
UPDATE: I see that there is an InstallSource value in the registry at HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<Product GUID> that references the SCCM cache (in this example). Do you know if I could install products using a command like "acroread.msi /qb INSTALLSOURCE=\\server\AdobeReaderSource"?
Posted by:
jmaclaurin
13 years ago
ORIGINAL: jmaclaurin
On the outside, you could attempt to recache the install by using the REINSTALL=ALL switch while using the original source files, but in a different location. You could also attempt to do this if you apply the MSP to your administrative install point, but again, you will likely need the original install source.
Something like:
msiexec /i setup.msi REINSTALL=ALL REINSTALLMODE=VOMUS
FYI, I have never had luck with changing the reg entries for the source or uninstall, but you could try playing around with that. What I wrote before will likely work to recache the original install source to the network share. Of course, you will need to get the path to the MSI exact and be sure NOT to change anything to the original source and test test test...
Posted by:
anonymous_9363
13 years ago
You could always try futzing with SourceList...
Have a search for that word here on AppDeploy. I'm pretty sure I posted some script which does exactly that but with the proviso that it was experimental and never used in anger.
Have a search for that word here on AppDeploy. I'm pretty sure I posted some script which does exactly that but with the proviso that it was experimental and never used in anger.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.