Repair/configure not using MSI in C:\Windows\installer folder

I've noticed that some MSI based programs have trouble repairing or even launching for the first time if the MSI from the original install location is not present.  I know that Windows renames the MSI and puts it into the C:\Windows\Installer folder, but it does not even try searching there.  Any idea why?  These programs are just single MSI installs, no extra files outside of the MSI.

0 Comments   [ + ] Show comments

Answers (4)

Answer Summary:
Posted by: rileyz 6 years ago
Red Belt
Have you got an example MSI?

The MSI is stored in that location but the CAB file will not be copied over, this used to be a big problem with packaging files into MSTs and its associated CABs. So with that in mind did your MSI use a CAB file? 

Another issue could be CAs looking or files etc which are not accessible anymore.

FYI, when a repair is run, it should run from the Windows\Installer location normally.

Can you provide event logs and MSI logs so we have something to look at, without that we're all just guessing.

  • I have an example program that you can download. Note that I did not develop this, I just package things for config manager. Go to https://www.ngs.noaa.gov/PC_PROD/pc_prod.shtml#WinDesc and download WinDesc. I just used the MSI, not the exe. Deployed through config manager it installs, but if the cache is cleared before the first run it fails to configure itself. Repair fails as well. I have some other programs that do the same thing, including some I have repackaged. - chriz78 6 years ago
Posted by: rad33k 6 years ago
Fourth Degree Brown Belt
You are correct, in some cases (especially when some files have to be repaired) Windows installer looks for he MSI in its original install location. Like rileyz mentioned, external files/CAB(s) are not copied to the C:\Windows\Installer\ folder.
As you have mentioned that in you case you have got single MSI it should work with the cached MSI but you would need to change few registry values. I'm assuming that you are creating a package for Win7 or later as prior to Windows Installer 5.0 (prior to Windows 7), the cab file is stripped from the MSI when windows creates a copy into C:\windows\installer\.
You need to consider if it is worth to mess up in Windows Installer registry keys. In such cases I'm copying the MSI locally (eg. C:\ProgramData\Installers\) and triggers the installation from the local copy or I'm deploying packages directly from the distribution point (users have got read access on those network shares). Anyway if you decide to make a script, here are the registry keys to change:
HKCR\Installer\Products\<<COMPRESSED_GUID>>\SourceList\PackageName = <Name_of_the_MSI_in_the_C:\Windows\Installer\_folder>
HKCR\Installer\Products\<<COMPRESSED_GUID>>\SourceList\Net\"1" or "2" etc. = "C:\WIndows\Installer\"
You can get the MSI name from:

  • I found the local MSI and COMPRESSED_GUID. It shows the path to the MSI in that bottom LocalPackage key you posted. When I look at the HKCR keys, it doesn't show that location as a source. Yes this would be Win7 and later. - chriz78 6 years ago
    • This is the normal behavior - 'works as designed'. I'm not aware of any switch to change standard behavior to use MSI copy from C:\WIndows\Installer\. Possible approaches are posted above, so I think now you've got all the details and it's time to make the decision what is best for you:
      * Prepare a script to modify registry entries.
      * Prepare a script to copy MSI locally and use the local copy for installation.
      * Try some other SCCM options like 'Persist content in the client cache' (you need to take into account cache size limit) or 'Do not download content' in the distribution options. - rad33k 6 years ago
      • So what's the purpose of putting the MSI in the C:\Windows\installer folder if it never uses it? We're trying to get Windows source managerment working as a solution. - chriz78 6 years ago
      • This is a very good question :) unfortunately I'm not able to answer that. I found it useful only in cases like you described, when I had a single MSI and users started to report issues with missing source MSI - then I pushed the script to replace registry entries (but it is very rare situation). - rad33k 6 years ago
Posted by: anonymous_9363 6 years ago
Red Belt
The 'COMPRESSED_GUID referred to is the MSI's ProductCode put through a Darwinian Descriptor conversion. Heaven knows why Microsoft felt that this tortured mess was necessary but we're stuck with it now.

Details on the conversion can be found here. Some time ago, I posted some QAD code to do the conversions back and forth here on ITN.
Posted by: EdT 6 years ago
Red Belt

Top Answer


Describes how to configure the locally cached MSI as the repair source. It's almost 5 years since I wrote it but still should help you in your quest.

There are also articles about GUID/Packed GUID converters and also a Darwin Descriptor utility.

  • Thanks Ed, that explains everything. Knowing this, I think the best solution for my problem is to use Windows Source Management in SCCM, if we can get it working properly. - chriz78 6 years ago
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ