Both of these have the exact same GUID in the ProductCode. The purpose of the product code(Global Unique Identifier) is to uniquely identify installers. The two MSI's obviously contain different files and different settings based on the OS type. This is highly problematic when you are using any of the major software deployment infrastructures. For example System Center Configuration Manager. These software deployment systems key into that GUID and use that to differentiate unique products throughout a network. When they inventory or run detection rules on assets they would assume that this software is one and the same, but they are not, I know that they are slightly different because you made a decision to split them into two different MSI's. If I ran a hashcheck it would come back as not being the same. This is dire misstep that goes against a known established standard. It makes it very difficult to manage this software across multiple managed machines. You could have chosen to have one MSI that worked on both x86 and x64. I think you took the right path in splitting these off into two different MSI's but you absolutely need to make that ProductCode unique. There's that word unique again.....hmmm. These are two different files, you should mark them that way.
https://msdn.microsoft.com/en-us/librar ... s.85).aspx
If the purchasing decision was up to me I would have passed on this product due to this issue. This is an extremely easy issue to fix, should take about 30 seconds when you are compiling the MSI's for the next version. Also please lay out your lifecycle for patching the product, you should be releasing MSP's for minor releases and then a new set of two MSI's for major releases (3.x). Deployment engineers have to look at the entire lifecycle of all these versions and your current GUID decision makes that very difficult. We will have to reference the ProductCodes and UpgradeCodes for years, please make this easier for us.
Lastly you need to stop using so many CustomAction objects as errors in those will not get fully recorded in the install log file. If you need to write a registry entry use the Registry table instead of your custom dll. That would make install issues much easier to troubleshoot. Then I would know if it was permissions or some other common registry issue.
this is black box to me because you did a simple reg entry with a homegrown dll instead of following standards:
Code: Select all
MSI (s) (B0:5C) [10:14:26:653]: Invoking remote custom action. DLL: C:\windows\Installer\MSI8201.tmp, Entrypoint: _VmACreateRecoveryMediaUpdateValue@4
Action 10:14:26: VmACreateRecoveryMediaUpdateValue. Setting Recovery Media update requirement flag...
***Veeam*** Storage name: 'C:\ProgramData\Veeam\Setup\Temp\{39C68361-38C1-4528-8064-AA5A182DBE0B}\VmCreateRecoveryMediaUpdateValue'.
Failed to create RecoveryMediaUpdateRequired registry value.
MSI (s) (B0!D8) [10:23:20:465]: Product: Veeam Agent for Microsoft Windows -- Failed to create RecoveryMediaUpdateRequired registry value.
Action 10:23:20: .
CustomAction VmACreateRecoveryMediaUpdateValue_Collect returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 10:23:20: VmACreateRecoveryMediaUpdateValue_Collect. Return value 3.
Action ended 10:23:20: INSTALL. Return value 3.