Frequently Asked Questions about upgrades and updates

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 tab of the Update Properties page.

This error may occur during installation if you configured the updater to run Automatic: using a Windows scheduled task and further updates will be installed silently through updater's support service.

In this case the Updater will install all the update packages under System account. However, the Updater scheduled task is like this:

• User: [%UserDomain]\[LogonUser]
• Run only if this user is logged on: checked

Please note this is a wrong configuration because at updates install time the User will be set to System. In this case, the scheduled task installation will fail because the "Run only if this user is logged on" flag cannot be set for "System" account.

To avoid this issue, in the project file configure the scheduled task of your Updater to be installed under "System" account. Just go to Account tab and leave the User field empty (just delete the existing [%USERDOMAIN]\[LogonUser]" references).

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.

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

This behavior is caused by a Windows Installer bug which appears when a file needs to be upgraded with itself and the version of the file is the same or lower in the upgrading package.

For example a file from the old package (already installed) has version 2.0.0, but this file has version 1.5.0 in the new upgrading package. In this case, during upgrade, the enginge detects file version 2.0.0 on the target machine and skips version 1.5.0 installation. Then, in the next phase it completely removes file version 2.0.0 along with the old package from the target machine.

The solution is to increase the version of the file from the upgrading project or set the Always overwrite existing file option in the File Operations Tab of the "Edit File" dialog.

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

The UILevel property in a package that is being upgraded by a newer version is set to the value of the UI used during the upgrade process. During an upgrade, the old version is removed silently and you may expect the UILevel property's value being 2 but this is not happening.

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 an 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 to renew a certificate for LUA Patching article.

An upgrade installation consists in two parts:

1. the uninstall of the old product version
2. the installation of the new product version

So, during an upgrade the installation could fail due to an error triggered either by the old version uninstall or by the new version installation. The best way to isolate an upgrade error is by creating a verbose log and, then by analyzing the verbose log.

Here are some common mistakes you should avoid when creating an upgrade installation project:

1. Do not update only the fourth field of the Product Version. The fourth field of the Product Version is ignored by Windows Installer when comparing product versions. This is why you should make sure the first three fields of your upgraded Product Version have an increased version than those of your old Product Version.
   When the first three fields of the old and upgraded Product Version are identical, then the upgrade installation will either fail with "Another version of this product is already installed" message or will be installed side by side with the old version (when using different Product Codes).
2. Do not manually change the Upgrade Code. If the old and upgraded version of your product have different Upgrade Codes they will be treated as different product families. Therefore the upgrade installation won't remove the old version, but it will be installed side by side with the old one.
3. Do not change the installation type between the old and upgraded version. This is because a per-user installation cannot upgrade a per-machine installation and vice versa. So, you should always make sure that your old and upgraded version have the same installation type.

Note that Windows Installer uses only the first three fields of the Product Version. If you include a fourth field in the product version, the installer ignores it.
For details, please check the ProductVersion article.

However, the previous installed version can still be removed, although only the fourth field from the product version is increased, by following these steps:

• Go to the Upgrades page and enable the Customize Advanced Installer upgrade rules option;
• Double-click on the Advanced Installer rule that is related to the [OLDPRODUCTS] property;
• In the Product Info tab, enable the Include maximum version in range option and click OK;

Also, you need to generate manually a new ProductCode in the Product IDs Tab from the Product Details page.

This odd behavior can occur on a Windows 7 machine when the new setup is a 32-bit installation package and the old installed setup is a 64-bit installation package. Although the entry of the old version is properly removed from the Programs and Features list, its resources are not removed. The remove operation is incorrectly redirected to the Program Files (x86) folder, which is wrong as it should be removing the 64-bit files of the old setup.

The best way to troubleshoot this is to create a verbose log of the installation process. On a Windows 7 machine, you will see that:

Action: RemoveFiles. Removing files
MSI (s) Executing op: ProgressTotal(Total=20,Type=1,ByteEquivalent=175000)
MSI (s) Executing op: SetTargetFolder(Folder=C:\Program Files (x86)\...\)

while on a different Windows machine (e.g. Windows 8.1) you will see that:

Action: RemoveFiles. Removing files
MSI (s) Executing op: ProgressTotal(Total=20,Type=1,ByteEquivalent=175000)
MSI (s) Executing op: SetTargetFolder(Folder=C:\Program Files\...\)

In order to remove the resources files of the old 64-bit installation package you can use the Uninstall cleanup option from the Files and Folders view or a custom action that implements this functionality.

1. In Updater page from your Advanced Installer project set the "Updates configuration file URL". This could be either a local path(eg. "file://e:\test\updates.txt" or a URL (eg. "http://example.com/updates.txt")

2. In the Updates Configuration project > Update Properties Tab set the Main URL to "file://" and leave the Mirror URL empty

"file://" syntax must be used for both local paths and URLs

3. Build the configuration Updates Configuration project

There are some situations when upgrading a package with multiple instances fails with “Another version of this product is already installed.” error. In other situations no error is thrown but the product version is not updated.

To fix this behavior, make sure you use the same location in the “Extract location” field from “Bootstrapper Options” in Builds page for both the old and the upgrade package. Also “Do not delete extracted MSI and CAB files” option should be checked.