Servers Windows Installer Best Practices

Windows Installer Best Practices





by John Loomes

OK, we’ve all read Microsoft’s
MSI Whitepapers (well some of us have, the rest of you probably get
out more often….), but how do you really go about producing
quality MSI-based packages? Ive compiled the following list of ‘Best
Practices’ to consider when writing MSI Packages, based on my
experience. This list is by no mean exhaustive, but quality MSI
information is so hard to find at the moment, that hopefully these
suggestions will prove to be useful to those of you in the process
of, or considering, doing some MSI packaging….


OK, we’ve all read Microsoft’s
MSI Whitepapers (well some of us have, the rest of you probably get
out more often….), but how do you really go about producing
quality MSI-based packages?

This article assume that you
are familiar with MSI terminology – so apologies if the remainder of
this is ‘Greek’ to you!!

  • Set the Property ALLUSERS =
    2
    in the property table. This will force the application
    to install for all users, if installed under an Admin account, and
    to Current User, if using a non-admin account…
  • Set the Property ROOTDRIVE =
    C:
    in the property table – This will force applications
    to install to drive C:. Otherwise, if you have more than one
    drive in the target machine, MSI will look for the one with most
    free space. this means you cant always gaurantee when your
    applications will install to.
  • Ensure that all user specific parts of
    the install i.e. all HKEY_CURRENT _USER registry entries, are
    contained in a separate component. When a new user logs into a
    machine, the self-heal functionality of MSI will detect a missing
    component in the users profile, and will populate the users
    registy with the settings for the application in
    question.
  • Be sure to generate a new Product ID
    for each application – otherwise you will encounter installation
    problems when trying to install more than on MSI application on a
    single machine.
  • Ensure that any INI file changes are
    recorded in the INI file table, rather than just as files in the
    file table. This will ensure that INI files are edited if they
    exist already, rather than replaced with the version within the
    MSI Package.
  • Set the property REBOOT =
    Force
    in the property table to force a reboot at the end
    of the installation – if one is required.
  • In the registry table, anything
    enclosed in square brackets [ ] is assumed to be an MSI property,
    and Windows Installer will attempt to resolve it. Whilst this is
    often quite useful, sometime you WANT to have square brackets in a
    registry value. To acheive this use the following syntax:
    [[[[]]
  • Follow the components rules: Dont mix
    user and machine specific entries in a single component. Ensure
    that only one .exe exists in each component. Ensure that
    components are UNIQUE i.e. dont have a .dll that exists in more
    than one component.
  • Dont use Custom Actions to make any
    critical system changes. Anything done in a custom action doesnt
    have any rollback capability, so if your install goes ‘pear
    shaped’ you cant roll back changes made during a custom
    action.
  • Generate Merge Modules (MSM’s), for
    any common components, and use the Merge Module in any application
    that requires the component. Try to source and use commercially
    produced Merge Modules if you can. If you can’t (and you wont be
    able to for most things…) then produce your
    own….
  • Make custom configuration changes
    using Transforms (MST’s), rather than by editing the MSI itself.
    This will make it easier to produce ‘generic’ packages that can be
    modified for several environments.

Latest Posts

How to Convert a Physical Computer to a Virtual Machine

Many organizations are implementing virtualization technology into their networks to convert physical computers to virtual machines (VM). This helps reduce overall physical hardware costs,...

HPE ProLiant DL380 Gen10: Rack Server Overview and Insight

The HPE ProLiant DL380 series has consistently been a market leader in the server space. The Gen10 released in 2017 further increased HPE's market...

Best Server Management Software & Tools 2021

Finding the best server management software tools for your organization can have a major impact on the success of your business operations. Manually handling...

IBM AS/400: Lasting the Test of Time

Some server operating systems (OS) were built to survive the test of time – the IBM AS/400 is one such system.  The AS/400 (Application System/400)...

What is Disaster Recovery?

The modern organization's heavy dependence on using data to drive their business has made having a Disaster Recovery (DR) plan in place a necessity....

Related Stories