Why do I receive the "Some of the updates failed to install properly" message?

Any update defined in the Updates Configuration file uses a detection criteria. This criteria is usually a file or a registry entry which contains the package version. If it's not met after the update is installed, the Updater will show this message. Therefore, you need to make sure you specified a correct file or registry entry in the Installed Detection section of the Update Properties page.

Why do I receive the "Another version of this product is already installed" message?

Usually, this message is showed if you created a package, installed it, modified its contents and then you tried to install it again without uninstalling the original one. Basically, Windows Installer can upgrade the original package only if the modified one has a higher version and a different Product Code. If you don't want to create a new version of the package, you need to uninstall the original MSI before installing the modified one. However, if you want to create a new version which will upgrade the old one, you can follow the steps explained in the Upgrades article.

NoteThis error can only occur on development machines during the installer's authoring process. You needn't consider preventing it on clients' machines.

Why does "updater.exe" disappear after an upgrade is performed?

This behavior is caused by a Windows Installer bug which appears when a file needs to be upgraded with itself (the version of the file was not increased in the upgraded package). This happens because of the Windows Installer versioning rules and because of the way the upgrade process works. The solution is to set the Ensure that this file overwrites any installed target file option in the Version tab of the "Edit File" dialog.

How do I determine if an Upgrade is being performed?

An upgrade process can be detected by using two properties:

  • OLDPRODUCTS - this property is set in the upgrading MSI if the package found an older version installed on the target machine
  • UPGRADINGPRODUCTCODE - this property is set in the MSI which is being upgraded if the package is uninstalled by a newer version

What do I do if the certificate used in LUA patching has already expired?

If the certificate used for LUA patching has already expired there are a few options that you can try, although none of them are guaranteed to work:

  • Alter Windows Installer security policy using Group Policy. In HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer create 2 REG_DWORD keys, AllowLockdownPatch and AllowLockdownBrowse, and set their values to 1.

This will allow non-administrators users to run signed and unsigned patches. Subsequent patches can be run by non-administrators even when AllowLockdownPatch and AllowLockdownBrowse permissions have been revoked. This option may not be viable if you have no control over your customers’ security policy.

  • Run a patch that has been signed with the new certificate while logged in as an administrator. Both the MSI file and the Patch must be signed with the same certificate. This may not be a viable option if admin permissions for your users cannot be obtained.
  • Start a new patch family. This option has the same downsides as the above option due to the need for administrator rights.
  • On your build machine, turn the computer’s clock back to prior to the expiry date of the expired certificate.

This option should not work due to the use of a time stamp server but in some occasions it does. After you have turned the clock back simply create a MSI file and patch, signing them both with the expired certificate. Once these steps have been completed you will be able to create subsequent patches with the renewed certificate and LUA patching will work. For more information please read the How do I renew a certificate for LUA Patching? article.