MSI cache locations and deploying with SCCM
Heya.
We have switched assets, configuration management and deployments from BMC Marimba to SCCM 2012
Now when we are deploying MSI's everything is fine, untill we need to repair an application through ARP.
When we had marimba , we had a msi cache directory that marimba referenced.
In my screenshot below, this is what I see when I am trying an ARP repair. Its referring to the SCCM msi cache that is no longer available. My SCCM guy is telling me its how the packages are made and they need to be fixed.
My main questions and concerns are:
Do we need to create/modify vendor and our MSI/MSTs differently?
Is there a way in SCCM to handle these properly for the self heals and ARP repairs to work?
Will Active setup work ?
Will advertised Self Healing key still work?
I thought these functions took place from %WINDIR%\installer
Thank you!
Indie
Answers (3)
This normally happens whenn you have CAB files. MSI files are cached in the Windows Installer dir (good), but CAB files are not (lame).
This issue will only occur when you have external CAB files, MSIs with the CAB file steamed into the MSI are OK.
To work aroud this issue you have to do some jiggery do with the installer. Basicly you need to copy the MSI and CAB files to local area and run the installer from there - this can be done with SCCM but its a bit of a faff. The MSI and CABs need to stay afterwards.
*SCCM copies it locally to run, but it removes it afterwards.
Oh, an alternative method is to run the installer as you are doing now, but afterwards or before copy the files down locally. Use the SourceList property to set an alternartive location for the MSI
- Install Software In Task Sequence (with midded MST to inculde alt source location)
- Copy files locally to alt source location.
Comments:
-
SMS/SCCM can handle the source list for you.
On the program for the package there is a Windows Installer tab where you can import the MSI GUID.
Adding this will allow SMS/SCCM to update the source list on the machine as part of the policy retrievals (Windows Installer Source List Update Cycle).
This will allow the machine to go back to any available DP to locate the source if it can't be found in the SMS Cache location.
The issue with your application is that it was installed as part of a Task Sequence, and the TS cache is removed after successfully running.
Further details can be found on this link: http://technet.microsoft.com/en-us/library/bb892810.aspx - dunnpy 10 years ago-
Ooo, I did not know! But I always filled in that section, lol! (:
*it appears the itninja server had a opsie... - rileyz 10 years ago
Under ‘HKEY_CLASSES_ROOT\Installer\Products’ there is a list of compressed package codes, under which there is a key ’SourceList’. This holds the MSI name + the location it was installed from. Also, under here is a further key ‘Net’ which holds source locations known i.e. the source location used and also any extra locations added by the SOURCELIST property (as Rileyz states above). The install location should be under HKEY_CLASSES_ROOT\Installer\Products\<CompressedGuid>\SourceList\Net\1, whilst a value added by SOURCELIST will be under HKEY_CLASSES_ROOT\Installer\Products\<CompressedGuid>\SourceList\Net\2. A repair will work down the list looking for a usable source location.
In answer to Indierox’s questions, if files are required during an ActiveSetup or self-heal then (again, as Rileyz states) if an external CAB was used, the process will fail. If the error is only occurring occasionally, you can search under ‘HKEY_CLASSES_ROOT\Installer\Products\’ for the name of the product e.g. ‘Windows Live Essentials’ and then look under here (in the case of Windows Live ‘HKEY_CLASSES_ROOT\Installer\Products\032440EF5AC97F34B985A55C2AA8F133’) and change the invalid Sourcelist\Net value (i.e. HKEY_CLASSES_ROOT\Installer\Products\<CompressedGuid>\SourceList\Net\1) to point at a share with the full source files. If it is occurring for a lot of installs of a product, you could use SCCM to send out the registry value to all machines with the product installed.
If the application is set to install from an SCCM Distribution Point, it will select any of the available DPs, which may be unavailable when a repair is called for, or if set to download first, may be cleared from cache after a while, so it is always useful to add a SOURCELIST entry to your MSI/MST’s to point at a location that will always have the source on.
Assuming you are using Windows 7 or later, there is a simple solution that maximises the efficient use of disk space. With the arrival of windows installer 5, Microsoft started caching the entire package to avoid the uninstall errors generated by signed packages when their cab files were no longer present. I wrote an article a couple of years ago which you can find here:
https://www-secure.symantec.com/connect/articles/reducing-windows-installer-disk-wastage-windows-7
This explicitly adds the cached package location to the sourcelist, which Microsoft could have done easily but didn't think through properly (sound familiar?), so there is no need to hold yet another full copy of the software on the local system.
If anyone still relies on a call to an MSI for active setup - don't! ANY other MSI process running at the same time as the active setup will cause active setup to fail but the HKCU keys are still updated to show it has run, so it never runs again. I have seen this on production systems so it's not just theory. Active Setup must be written to be able to run independently of ANY other process otherwise you are saving up grief for a later date.
