Tao of the Windows Installer, Part 3

We have reached the mid-way point in this series and will be taking a look at deployment-related recommendations.  Shorter than last time, this section is potentially more interesting to system administrators than package developers - in either case, if you have come across some 'gotchas' or know any nice workarounds for deployment problems, please post them. Similarly, if there is anything you always make sure to do in this area, post it as it might make a good rule to help other Installer users.

Series links:


Rule 30: Per-machine Installs are Easier to Manage
Because per-machine packages are installed for every user, there are fewer problems for subsequent repair, patching and uninstall. For example, if a user installs an application only for themselves, another user (even an administrator) cannot later uninstall the application.

Rule 31: Keep the Original Source Files Available
Be aware that when you roll out packages that the original source package may have to remain available. For install-on-demand, repair and some patching situations the Installer returns to the original source of the relevant MSI package to find the required files. If this source is no longer available (e.g the server has been renamed or the original package removed) the user will by default see a prompt such as ‘Please insert CD #2’, or inviting them to browse the network.

Mechanisms for avoiding problems with this include:

  • Correctly authoring the SourceList property for all packages. Set this to a semi-colon delimited list of all the possible servers where the software can be found. The clients will failover each server until one that succeeds is found. This can be done with a transform.
  • Using a DFS share for the source path. Using a DFS server as the source means that changes to the actual physical location are hidden from the end user and the Installer. It also means that you can take advantage of site-awareness to point the user to a local copy of the source packages, even if they move to a location in another town, country or continent.
  • Programmatically altering the registry source list on the client. You can use the Installer sourcelist API calls or a simple VBScript to do this on local or remote clients.

Rule 32: Anticipate Installation on Terminal Server
If your package might be installed on a Terminal Server, keep in mind the following points:

  • Administrators and non-administrators can install from Terminal Services console sessions
  • Non-administrators cannot install from Terminal Services remote sessions. Non-administrators can only install from a console session
  • Administrators can install from a remote session only if the EnableAdminTSRemote system policy has been set
  • When an administrator installs from a remote session that is hosted on Windows 2000, the installation must use a UNC path and not a mapped drive letter. This restriction only exists for remote sessions hosted on Windows 2000
  • Windows Installer can perform per-machine installations without using install mode. It is unnecessary to place the Terminal Server computer into install mode to perform a per-machine installation. Windows Installer does not automatically place the Terminal Server computer in install mode, regardless of the type of installation
  • When installing software for an individual user, placing the computer into install mode may incorrectly copy the application’s shortcuts or data to the profiles of other users, even if the application is not installed for these users. It is recommended that applications installed per-user be installed with the Terminal Server computer in the execute mode

Rule 33: Avoid Black-boxes
Make your packages as customisable as possible. Users like to decide for themselves where and what to install on their systems. Provide valid and sensible defaults, but allow users to over-ride these where possible.

Rule 34: Support Silent Installation
Corporate deployment scenarios almost always demand the ability to deploy with no user interactions. You should design your packages to use public properties for configuration information, which administrators can specify on the command-line.

You should also avoid relying on data gathered from users via dialogues. During silent installs, this data is not going to be availalbe.

Rule 35: Avoid Reboots
Being told to reboot their system is one thing that is sure to annoy users, particularly if there is no obvious reason for it. Even worse is the system automatically rebooting due to a silent install the user was entirely unaware of.

In the case of user applications it is usually not necessary to reboot the entire system. If this is required in your case, your install should handle situations where the application or service must be stopped.

Ideally, you should design your application such that if it is being upgraded or patched it can handle requests to shutdown/restart by saving the current state and restoring it later. this scenario is very much the recommended one for Windows Vista, where eliminating unnecessary reboots is a key objective. You can be ahead of the game by writing your applications to be work this way now.

If an application or service needs to be stopped, the user should be warned. Similarly, in cases where a reboot is completely unavoidable (e.g. replacing the GINA), the user should be warned and given a choice to defer the reboot.
Rule 36: Enable Logging on Clients
Windows Installer supports very detailed logging, which can be invaluable when things go wrong during deployment (and development and testing).

This article gives information on how to enable logging:

How to enable Windows Installer logging

Once you have the log, you obviously need to know what to look for. A very useful resource for this is WiLogUtl.exe, which ships with the SDK. As well as automating the parsing of the log, it also has some documentations describing typical log contents.
Rule 37: Enable the DisableMedia Policy
This policy helps prevent unauthorised installation. When enabled, users cannot install from anything except a local fixed drive or a remote server. This prevents users installing unauthorised MSI packages from removable media such as CD or Floppy Disk.
Rule 38: Avoid Using the AlwaysInstallElevated Policy
While this policy setting will allow a non-administrator to install packages they would otherwise not have right to install, it would allow them to install any package, not just ones provided by their administrator.

Since this policy causes the install to run with SYSTEM privileges, it effectively serves as a possible elevation of privilege security breach. A reasonably smart user could craft an MSI package that would add them to the administrators group, install kernel drivers, alter file and registry permissions and perform other undesirable actions.

As tempting as this policy may seem as a solution to issues of user rights and permissions that are blocking a deployment, do not use it.
Rule 39: Uninstall Cleanly
While most packaging effort goes into the creation and install phases, you should also think carefully about what happens when the user uninstalls the package. Your packages should be authored such that they leave no trace of themselves after uninstall.

[Author: Richard Macdonald]

This posting is provided "AS IS" with no warranties, and confers no rights.

Comments (6)
  1. Peter Thomas says:

    Installing Per Machine has become very important for my company.  Our product’s service pack installations are complex enough that we they have their own product code.  We use MSI calls from IS script to detect which features of our product were installed and then update the appropriate files and perform the required configuration.

    If the product was installed "per user" then we would have to run the service pack as the same user who installed the main product.  This is because the MSI calls will report that the product was not installed for that use so you can’t detect which features were installed.

  2. Mark Rovetta says:

    “Rule 30: Per-machine Installs are Easier to Manage”

    I’m not sure that this should be a rule or claimed as a best practice. It really depends upon the situation.  Per-user installation is important for management and deployment with Group Policy.  Also, my understanding is that an application installed with administrator authorization via User Account Control (UAC) in Windows Vista will be installed in the per-user-managed state.

    This is another example of something that needs to be considered when planning the deployment of a package, and even during the package development process:  Should the application be available to only particular users or all users of a computer?

    As a general rule, the better package is the one capable of being easily customized for deployment as either a per-user installation or per-machine installation.

    Rule ##:  Test packages for both per-user and per-machine installation deployment

    • Consider whether the application should be available to only particular users or all users of the computer during the development process.

    • Test that the package works correctly for both the per-user installation and per-machine installation contexts.

    • Make the package easily customizable and let customers decide whether to deploy it per-user or per-machine.  

  3. zhakim says:

    “Rule 30: Per-machine Installs are Easier to Manage” – I’m not sure that this should be a rule or claimed as a best practice. It really depends upon the situation.

    Yes, it could do with a bit of re-wording.  This rule sounds a bit more like a statement of fact than a rule to follow.  

    In fact a lot of the “rules” could be bent or broken depending on the situation – they are just intended to point out obvious places you could have problems and how to avoid these.

    [Author: Richard Macdonald]
    This posting is provided “AS IS” with no warranties, and confers no rights.
  4. Mark Rovetta says:

    Rule 37: Enable the DisableMedia Policy

    “When enabled, users cannot install from anything except a local fixed drive or a remote server.”

    Is that correct?  I thought with this policy set, it is still possible for the user to reinstall the product from media if the user has a correctly labeled media source.

    Can this be revised along these lines?

    Rule ##: Enable the DisableMedia Policy to limit unauthorized installation from media

    This policy can prevent unauthorized installation of applications. When this policy is enabled, users and administrators running a maintenance installation of one product are prevented from using the Browse Dialog to browse media sources, such as CD-ROM, for the sources of other installable products. Browsing for other products is prevented regardless of whether the installation is done with elevated privileges. It is still possible for the user to reinstall the product from media if the user has a correctly labeled media source.

  5. Peerke says:

    <b>Rule 31: Keep the Original Source Files Available</b>

    What about laptop users?!

  6. I recently noticed a series of in-depth articles that have been posted on the Windows Installer team…

Comments are closed.

Skip to main content