MSI-Properties

MSI-files contain settings in the table 'properties' that affect the behaviour of the installer or of the installed product.

I have yet to find an MSI-file which I can use as-is, without having to set or change some of the properties to make it work correctly and/or reliably.

Some common properties can be set in all MSI-files, some are specific to individual software packages. In this list the common properties are written in upper case letters. You must give them this precise name. The others are written here in lower case letters. These names are just examples for a certain kind of property that exists in many, but not in all MSI-files. Every company gives them somewhat different names, but similar function.

ALLUSERS

common, recommended value:1

Setting this property to 1 causes the software product in that MSI-file to be installed per machine, not per user.

All examples listed on these web pages assume this, because I'm doing only 'per machine' installations.

(more info in MSDN)

ARPNOREMOVE

common, recommended value:1

Setting this property to 1 disables the uninstall-button in appwiz.cpl (the applet 'Add/Remove Programs' in the Control Panel of Windows).

It is still possible to uninstall the software by right-clicking on the MSI-file and selecting uninstall there.

If you had set the option to automatically remove the package whenever the GPO is disabled, then you can disable it with this method as well.

You should set this property if you deploy MSI-files via GPO. This prevent that somebody (e.g. yourself) mistakenly removes the program locally instead of doing that via GPO.

ARPNOMODIFY

common, recommended value:1

Setting this property to 1 disables the modify-button in appwiz.cpl (the applet 'Add/Remove Programs' in the Control Panel of Windows).

You should set this property if you deploy MSI-files via GPO and don't want that somebody (e.g. yourself) mistakenly reconfigures the installation locally instead of doing that via GPO.

ARPNOREPAIR

common, recommendation: don't touch this

Setting this property to 1 disables the repair-button in appwiz.cpl (the applet 'Add/Remove Programs' in the Control Panel of Windows).

It is still possible to repair the software by right-clicking on the MSI-file and selecting repair there.

I see no reason why one should set this property. However if you download an MSI-file and it already has this property set, you should probably leave it this way. Maybe that MSI-file doesn't have the ability do do a repair. This might happen if the MSI is just a setup-wrapper instead of a true MSI-file. In this case you cannot add the feature just be changing this property, instead the MSI-file would have to be created differently first.

ARPCOMMENT

common, recommended

This property allows to define a short message that will be displayed if somebody (e.g. you) starts appwiz.cpl (the applet 'Add/Remove Programs' in the Control Panel of Windows) and clicks on the line of the program, that was installed by this MSI-file.

I usually write there that this software was deployed from the server and thus cannot be modified locally.

update-check

custom, recommended value: disable, example: set AUTOUPDATECHECK to 0 in Java

Several MSI-files contain custom actions (programs that run during installation) that check the version: they compare if the version in that MSI-file is is the latest version that is currently available. The installation aborts if this is not the case.

I welcome this in installers of kind setup.exe, but it's a very bad idea for software that is deployed to many machines.

You cannot deploy new versions in the same second when they become available. That check would cause problems if some computer has been sitting switched off for a while (e.g. during holiday), then a new version has just come out, and now the computer is switched on. But you haven't yet updated the GPO to deliver that new version. In this case the computer should install the old version (and hopefully update a few days later, as soon as you deploy the new version).

auto-update

custom, recommended value: disable, example: set JAVAUPDATE to 0 in Java

Some software products come with their own automatic updaters.

Many of these updaters work only if a user is logged on who has admin-rights (exceptions: virus scanners, Adobe Flash 11.2, Firefox 12).

Generally I welcome the idea of automating the installation of updates. But if you decided to do this via GPO, then you don't want the included updaters to try do do it as well. Thus you should disable them.

Every software product has some other method to disable its updater. Some require you to set a registry key, some require a config file, and some allow to do it by setting a property in the MSI-file.