Software Deployment

It sounds like the components containing the files have been marked as 'permanent' which, if they're being installed to %SystemRoot%\SYSTEM32, is best practice.

Also, please edit the tags you have attached to this post. The following are irrelevant to it:
'Software Scripting' 'Supporting Windows', 'Best Practices', 'Windows Installer (MSI) Error Messages', 'Windows Installer Repackaging (MSI)'

http://msdn.microsoft.com/en-us/library/aa368007%28v=vs.85%29.aspx - anonymous_9363 9 years ago

Or components have been marked as 'Shared' and you have not follow component creation rule to use the same GUID for the same components in both MSIs (also known as GUID synchronizing)

http://msdn.microsoft.com/en-us/library/windows/desktop/aa370561%28v=vs.85%29.aspx

<q> " Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies. " </q>

I've experienced this issue many times in my factory ;)
To solve it you may use the same Component codes in new MSI (depends on number of components may take many hours ;),
or do not use Upgrade table and remove old version in a separate msiexec /x command prior installation of the new one. - rad33k 9 years ago

Or the components have been reference counted using the legacy method which would have the same effect. The key path issue is a red herring, my gut feeling is that the GUID were not synchronised on the upgrade, or that the testing did not take place on a clean O/S build and there were reference counting issues already stacking up. Simple check - run an MSIDIFF on the original and upgrade MSI - only the upgraded components should be flagged. If any unchanged components are flagged then GUID sync is the issue. - EdT 9 years ago

@rad33k. You can still use the upgrade table without guid sync but only if you resequence the RemoveExistingProducts custom action to between InstallValidate and InstallInitialize. This causes the original MSI to be totally uninstalled before the new one is installed so no reference counting issues. Only suitable for a major upgrade though. - EdT 9 years ago

@EdT Are you sure? I've made this test some time ago, with major upgrade configured (RemoveExistingProducts placed like you said between InstallValidate and InstallInitialize) and it worked fine only when component GUIDs were synchronized. Otherwise ...Windows\CurrentVersion\SharedDlls\ entry disappeared on RemoveExistingProducts action and was created at the end of the installation with value 2 (?!?). Initially I was shocked, but I've explained this situation myself that in the same msiexec session, DLL counter is not cleaned because of component GUIDs are different so Windows Installer assumes that file was installed by 2 different products. If you could take a look at this example: https://onedrive.live.com/redir?resid=18278F304E19AD4!280&authkey=!AJviY6Wzo3_wjIk&ithint=file%2crar or create it yourself (just remember to mark component with 0x0008 SharedDllRefCount, and do not synchronize component GUID in second MSI) and let me know if I have missed something - I would greatly appreciate your feedback! - rad33k 9 years ago