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.
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. Rule 36: Enable Logging on Clients
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.
Windows Installer supports very detailed logging, which can be invaluable when things go wrong during deployment (and development and testing). Rule 37: Enable the DisableMedia Policy
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.
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. Rule 39: Uninstall Cleanly
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.
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.