17 May 2018

Explaining the %WINDIR%\Installer Folder

While recently writing an MSI uninstaller script, I needed to be able to associate the GUID with the applications name. In the process, I was finally able to associate the MSI files inside the Installer folder with the application.

You may wonder why you want to know this. Most of this is probably just for general knowledge, but there are a couple of instances I can think of on why you might want to know. For one, I used it as described above. You may also want to know this if you are checking to see if the MSI is available to do an uninstall or a repair.

The MSI and MSP files inside the %WINDIR%\Installer folder are associated with the installed application or update in the following registry location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\<Unique Identitier>\InstallProperties

The screenshot below shows an example of the unique MSI filename in the %Windir%\Installer directory associated with the installed application. The association is made under the LocalPackage.


Related Posts:

  • SCCM 2012: Report Builder 2.0 is not installed If you are getting the message below, the first step to resolving it is here. One more step you have to do with the solution in that link is to make the changes in both the server and machines with the installed co… Read More
  • MDT: Injecting Variables into Task Names While creating tasks in the task sequencing, you may want to create unique names that are stored in an MDT variable. This can easily be done. For instance, I have setup MDT to automatically install drivers by the make and mo… Read More
  • SCCM 2012: Accessing Reporting Services Website Unlike the old SMS where you could access the reporting services via the SMS server name in the browser, it has changed in 2012. To access the reporting services, you will have to enter the fully qualified name of the SCCM S… Read More
  • ERROR, application GUID not found in application list If your MDT build give the above error at the end of a build, the issue is more than likely caused by a residual GUID left over in another application's dependencies, in which the dependency was deleted. To fix this, yo… Read More
  • Rearranging the Driver Folders in MDT The drivers folders in MDT do not alphabetize as you add new ones. It just adds the new folder at the bottom of the list. There is a simple way to rearrange the folders. MDT is controlled by XML files. You will need to navig… Read More

3 comments:

  1. One of the things to remember about the localpackage is that it is not just the a copy of the msi that ran on install. It's actually the merge of the msi and the applied transform (s) logic. This is how on repair your installation remembers the application language and other properties supplied by your administrator or ESD solution. Examining size of the locally cached msi will show you they are substantially smaller then the original msi. The files are referenced when needed for repair or reconfiguration from the full msi referenced in the installsource regvalue. Lost the source connection? Just find the original msi, update the regkey and you are back in business for repair.

    ReplyDelete
  2. O and another tip, on the %windir%\installer folder add the column "Subject" to "Name", "Date Modified", "Type" and "Size" that are already shown by default. The Subject column will tell you what each weird msi name actually is without going through registry manually.

    ReplyDelete
  3. This is not true that it is a merge, at least with Win 7 and later. I know this because Win7 started caching the original full MSI without stripping out the *.cab files so it could preserve the signature on the package and during maintenance operations show a valid publisher signature. IIRC before then, transforms were also cached and the log would show the transforms loading from the cached location.

    ReplyDelete