PSS Module 1.

2
Learning
Services

Contents

Lesson 2: Windows Installer 33

Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Active Accessibility, ActiveX, FrontPage, MS-DOS, Outlook, PhotoDraw, PowerPoint,

SQL Server, Visual Basic, Visual C++, Visual J++, Windows, and Windows are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other
countries/regions.

The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
 Module 1.2 33

Lesson 2: Windows Installer

Overview
Microsoft® Project 2000 uses a new setup technology based on
Microsoft® Windows® Installer. Through this technology, setup has been able to
reduce many of the problems associated with installing and maintaining
Microsoft Project installations.

What You Will Learn

After completing this lesson, you will be able to:
 Identify two main components responsible for Microsoft Project 2000
installation
 Define the function of setup.exe
 Define the function of msiexec.exe and the files it uses
 Define the function of instmsi.exe and instmsiw.exe
 Compare and contrast Windows Installer vs. ACME setup
 Define components of an .MSI file
 Define a transform
 Flowchart the installation process
 List and describe the features of Windows Installer
Microsoft Project 2000 Installation
The Two Components of a Microsoft Project 2000 Installation
Installing Microsoft Project 2000 is preformed in a two-step process.
 The file SETUP.EXE performs the first step. It runs through a series of
checks to make sure system and permission parameters are correct.
 Windows Installer (MSIEXEC.EXE) performs the second step. It
executes the actual installation of the application.

Functionality Overview of SETUP.EXE

SETUP.EXE’s main functionality is to prepare a system for installation. Among
the more important steps it performs are verifying that the OS meets minimum
system requirements, installing Windows Installer (if necessary) and parsing the
command line for custom switches to pass on to Windows installer. More
specifically it performs the functions listed below.
1. Searches to find a SETUP.INI file that may alter the path to needed installer
files.
2. Parses the command line for custom switches the installer may need.
3. Detects if the installer requested the CD-ROM when SETUP.EXE is called
with the /AutoRun switch.
4. Checks if SETUP.EXE was called from source and if Office was previously
installed.
5. Checks to make sure the operating system is qualified, and has the correct
level of operating system service pack installed.
6. Checks version of MSI.DLL to make sure it meets the minimum version
requirements.
7. Determines if the user has appropriate permissions to update the operating
system.
8. If SETUP.EXE is run with the /AutoRun Switch, goes to AUTORUN.INF
and starts the actions in that file.
9. If the /AutoRun switch is not used and the installer is already on the target
computer SETUP.EXE calls the local installer to start
Microsoft Project 2000 setup and exits.
10. If SETUP.EXE detects that the installer is not present on the target
computer it makes a call to INSTMSI(W).EXE on the CD or source network
drive. (Note: INSTMSI.EXE is used for the Microsoft® Windows® 95 and/or
Microsoft® Windows® 98 platforms, INSTMSIW.EXE for
Microsoft® Windows NT® 4.0)
 Module 1.2 35

The logic flow chart of SETUP.EXE is shown below in Figure 1.

In s e rt
CD
RO M Yes A le r t U s e r a n d E n d

N o

D id
Is O S Is U s e r
I n s t a lle r
Yes E nd N T No an
R equest
3 .5 1 ? A d m in ?
C D ?

N o N o Yes

Has
Is
P r o je c t
W in d o w s Is O S C a ll I N S T M S I . E X E
B een N o No Yes
I n s t a lle r W in 9 .x ? fro m s o u rc e & E n d
I n s t a lle d
P re s e n t?
?

Yes Yes

R un
P r o je c t C a ll lo c a l I n s t a lle r
N o
F ro m and E nd
S o u rc e ?

Yes

E nd

Figure 1 - Flowchart of SETUP.EXE Logic

Looking at SETUP.EXE Level Customization In-Depth

As noted in the above steps, SETUP.EXE parses customization information and
passes that on to installation. There are three types of customization information
that is passed on by SETUP.EXE. They are Command Line Switches, the
information within the SETUP.INI file, and Setup Properties. Below we look
more in-depth at these three areas.
Command Line Switches When To Use Command-Line Switches

The first area where we can customize a Microsoft Project 2000 installation is

with switches. Switches are usually run from the command line, but can also be
included in a batch file or a shortcut. Switches can customize installations in
various ways. For example, to install Microsoft Project 2000 as an
administrative install point, the /a switch would be used. (The /a switch also
allows an .MSI file name to be specified.) When typed at a command prompt,
the syntax would look as follows:
D:\setup.exe /a data1.msi

Command-Line Switches are most useful when few customizations are needed
or when users want to create several different installations quickly. There is no
need to edit any Project files (such as the Setup settings file) or run any special
tools (such as the Office Custom Installation Wizard).
It is possible to create multiple custom installations by defining different
command lines for different users or by creating multiple batch files or
shortcuts. This method is especially useful if there is a need to create multiple
deployment packages by using a systems management tool — and each package
requires a different command line.
For example, if the Engineering and Accounting departments install the same
version of Project but use unique organization names, the Administrator may
create two shortcuts that have the following command lines:
setup.exe /q companyname="Engineering Department"
setup.exe /q companyname="Accounting Department"
SETUP.EXE does not actually process command line switches. Instead it reads them
from the command line and passes them to the Windows Installer to be processed.
There are exceptions to this rule however. The following three switches are
processed by SETUP.EXE.

/autorun - This switch is only used only in the AUTORUN.INF file.

Its purpose is to indicate that setup is being run automatically after you
insert the CD in the CD-ROM drive.
/settings - Specifies a settings file and path that customizes Setup actions.

/wait - Waits for installation to complete before exiting.

Below is a list of switches that can be used when installing

Microsoft Project 2000.

For more information, see the following Knowledge Base article: Q202946 "Setup
Switches for Microsoft  Office  2000 ".

Command- Description Example

line Switch
/a Setup performs an administrative Create a network
installation, using the specified MSI file, share.
to create an administrative point. NOTE:
This option cannot be used along with The share must be
the /i switch (discussed later). accessible by all
users who need to
 Module 1.2 37

install
Microsoft Project,
and you must have
write access to it.
Run Setup from
Microsoft Project
CD by using the /a
command-line
option. For example:
e:\setup.exe /a
data1.msi
When Setup prompts
you for the
installation location,
enter the network
share that you
created.
Setup copies all of
the files from
Microsoft Project
CD to the network
share.

/autorun This switch is only used only in the /autorun

AUTORUN.INF file. Its purpose is to
indicate that setup is being run
automatically after you insert the CD in
the CD-ROM drive.
 Command- Description Example
line Switch
/i <file> Specifies the name of the MSI file. This /i Mso9.msi
option cannot be used along with the /a
option.
/p <package Applies a patch. To apply a patch to
file> an installed Admin
image you must
combine options as
follows /p
<PatchPackage> /a
<Package>/p
<PatchPackage> /a
<Package>
PROPERTY=va Specifies a property value. If the TRANSFORMS=
lue property value contains spaces, enclose "C:\Acct Dept.mst"
the string in double quotation marks ("). INSTALLLANGUAGE
You can specify more than one property =German"
and value pair on the command line,
separated by spaces. See section on
Properties below.
/q<option> Selects the user interface level. Valid /qn
options are:
n: None — No user interface is
displayed
b: Basic — Only simple progress
indicators and errors are displayed.
r: Reduced — No user information is
collected, and full progress indicators
and errors are displayed.
f: Full – With a modal dialog box
displayed at the end
qn+ - No UI except for a modal dialog
box displayed at the end.
qb+ - Basic UI with a modal dialog box
displayed at the end. The modal dialog
box is not displayed if the user cancels
the installation
qb- - Basic UI with no modal dialog
boxes. Note that /qb+- is not a support
UI level. This can be used to
automatically reboot the machine at the
end of setup, but if you use /qb- the
machine will simply restart
automatically.
 Module 1.2 39

Command- Description Example

line Switch
 Command- Description Example
line Switch
/settings <INI Specifies a settings file and path that /settings
file> customizes Setup actions.
C:\office9.ini
/? Displays a list of valid Setup command- /?
line options.
/wait Wait for installation to complete before /wait
exiting.
/j <option> Advertise Locally [u|m]Package
<package path>
u – User or
m – All users [u|m]Package /t
Transform List
Note When using the /j<option> switch
the /t switch should be used to point to a or
particular transform list. Otherwise with
other switches the TRANSFORM [u|m]Package /g
property should be used. LanguageID

/f<options> Setup repairs the Microsoft Project The Detect and

<package path> installation. The .MSI file specified must Repair command
be the .MSI file used to install (Help menu) in
Microsoft Project originally. The .MSI Microsoft Project
file must be in the same folder as performs the same
SETUP.EXE. function as using the
options /focums.
If you run Setup and
p – Reinstall a file only if it is missing. select Reinstall,
o – Reinstall a file if its is missing, or an Setup performs the
older version is present. same function as
using the options
e – Reinstall a file if it is missing, or an /fecums.
equal or older version is present.
d – Reinstall a file if it is missing, or a
different version is present.
c – Reinstall a file if it is missing or
corrupt (the stored checksum doesn’t
match the computed value)
a – Force all files to be reinstalled
regardless of checksum or version.
u – Re-Write all required user registry
entries
m – Re-Write all required local machine
registry entries
 Module 1.2 41

Command- Description Example

line Switch
s – Reinstall all shortcuts, overwriting
any existing shortcut
v– Run from the source package and re-
cache the local package.
 Command- Description Example
line Switch
/x <package Setup uninstalls Microsoft Project. The /x e:\data1.msi
path> MSI file specified must be the MSI file
used to install Microsoft Project
originally. The MSI file must be in the
same folder as Setup.exe.
/t <transform> Specifies the name of the transform /t accounting.mst
(MST) file. When using the /jm
switches, the /t switch must be used,
other wise the TRANSFORM property
should be used.
/l [i|w|e|a|r|u|c|m| Logging switches for MSIEXEC.EXE /l* c:\logname.txt
p|v Specifies path to log file and the flags
indicate which information to log.
|+]Logfile
'i' - Status messages
'w' - Non-fatal warnings
'e' - All error messages
'a' - Start up of actions
'r' - Action-specific records
'u' - User requests
'c' - Initial UI parameters
'm' - Out-of-memory
'p' - Terminal properties
'v' - Verbose output
'+' - Append to existing file
"*" - Wildcard, log all information
(except Verbose output)
“!” - Flushes each line to the log file.
The default behavior is to cache 20 lines
of log file text in memory, and then
dump 20 lines to the log file at once.
This is done to improve performance.
 Module 1.2 43

Command- Description Example

line Switch
/m SMS status .MIF generation option An example
command line would
Creates a .MIF file in the %TEMP% be of the form:
folder. msiexec /i
The SMS status MIF generation option, Data1.msi /m
-m filename, where filename is the 1-8 12345678 (note
char base name without the .MIF, is .MIF extension is
available only for install (-i), remove (- not included.
x), admin install (-a), and reinstall
product (-fv). Fields are filled as follows:
Manufacturer - SummaryInfo
PID_AUTHOR, 4 (Author)
Product - SummaryInfo
PID_REVNUMBER, 9 (ProductCode)
Version - SummaryInfo
PID_SUBJECT, 3 (Product description
and version)
Locale - SummaryInfo
PID_TEMPLATE, 7 (Platform and
language)
Serial Number - not set, not available
Installation - not settable via API, set by
ISMIF32.DLL to "DateTime"
InstallStatus - "Success" or "Failed",
depending on success of install
Description - Error message (as much as
can be obtained), or empty if successful
/g Language ID
Setup Properties

Command- Description Example

line Switch
/y Module Calls the system API
DllRegisterServer to
self-register modules
passed in on the
command line. For
example, msiexec /y
my_file.dll.
This option is only
used for registry
information that
can't be added using
the registry tables of
the .msi file. This is
not used the same
way /y was used in
previous versions of
Office

/z Module Calls the system API

DllUnRegisterServer
to unregister
modules passed in
on the command
line. For example,
msiexec /z
my_file.dll.
This option is only
used for registry
information that
can't be removed
using the registry
tables of the .msi
file.

Setup Properties are global variables used during the installation process. They
can be used to set the information normally entered by a user during
installation. For example, the setup property COMPANYNAME can be set to
automatically populate the organization name that appears in the Help/About
box. Numerous setup properties exist.

For a complete list of setup properties for Microsoft  Project 2000, see the
Microsoft Project  2000 Resource Kit.
Using Switches & Properties in Combination Using Command
Multiple Command
Line Switches
Line Switches
and SetupSetup.ini
Properties
Files

Module 1.2 45

Some properties are public, meaning that they can be overridden at the
command line or set dynamically during the installation using standard actions
or custom actions. (Note: The names of public properties are always in all
uppercase letters.)
Some properties are private, meaning that they cannot be overridden from the
command line because they describe the local system or operating system.
(Note: The names of private properties contain lowercase letters.)
To install Microsoft Project 2000 with the PROPERTY set to a certain
VALUE, you must be careful of the syntax used at the command line. You can
put the property anywhere except between an option and its argument.
For example, you must specify a file when you use the /i switch. In this case,
the /i switch is the option and the specified file is the argument. Thus, when
setting a property and using a switch, we must put the property before or after
the option and its argument, not in between.
Correct syntax:
setup /i A:\Example.msi PROPERTY=VALUE

Incorrect syntax:
setup /i PROPERTY=VALUE A:\Example.msi

Command line switches and setup properties can be combined to customize

installations. However some switches should not be used together and some
properties cannot be used with some switches.

Command Line Switches can generally be divided into two types: verb switches
and adverb switches.
Verb switches are switches that influence setup in a major way. For example,
the /a switch performs an administrative setup, while /x uninstalls Project. Verb
switches should not be used together (except for patching an admin image
which requires both the /p and /a). There are eight verb switches. They are /i, /x,
/f[p|o|e|d|c|a|u|m|s|v], /j[u|m], /a, /p, /y and /z.
Adverb switches are modifier switches that affect a verb switch. There are four
adverb switches. They are /t, /g, /l[a|e|c|i|m|p|r|u|v|w|+|!], /q[n|b|r|f].
/t and /g are for use with /j only.
/l and /q can be used with all verbs except /y and /z.

While Setup Properties do not interact directly with Command Line Switches,
the switches used can influence their efficacy. For example, all Setup Properties
are ignored when used with a /j, /y, or /z switch. And some (like
TRANSFORMS*) are also ignored with /x and /f. Thus caution must be
exercised when using these five switches.
Setup.ini files are also used to customize installations. Their main advantage is
that they are easier to create than long command lines with multiple switches
and setup properties.
Like command line switches, SETUP.EXE does not actually process the
setup.ini file. Instead it reads the setup.ini file and creates a command line that
is then passed on to the Windows Installer.

When a property or value is found in both the SETUP.INI file and on the command
line, the command line overrides the .INI file settings.

SETUP.INI files consist of the following five sections:

 [MSI] - specifies the path to the installation package for this installation.
This is the same as the /i option on the command line.
 [MST] - specifies the path to transforms used with this installation. This is
the same as the /t option on the command line.
 [OPTIONS] - section that displays where administrators can set and
override properties in the MSI or MST files. Each option in the option
section must have a property name and a value.
 [DISPLAY] - is used to set the User Interface level used during setup. This
corresponds to the /q option on the command line. Valid values are - none,
basic, reduced, and full.
 [LOGGING] - is used to set what logging switches are on by default and the
path to where the logging file is created.
Below is an example of the contents of a SETUP.INI file for
Microsoft Project 2000.

; Microsoft Project 2000 Windows installer setup.exe information file.

; If a file exists in the same directory as setup.exe named "setup.ini", or

; /settings <path to ini file> is passed on the command line, that file will

; be read and modify the default behavior of setup as shown below.

;[MSI]

; If a value is present, the MSI section gives the name of the MSI file to install.

; This file must be in the same directory as setup.exe, and both must be in the
root

; of the installation tree.

; If no value is present, setup.exe will look for exactly one file matching "*.msi"

; in its directory and if found, use that.

MSI=INSTALL.MSI

;[MST]

; If a value is present, the MST section gives the full path to a transform to
apply.
 Module 1.2 47

; Specify it in the form MST1=path to MST

; Remember to uncomment both the section name and the value names.

;MST1=\\server\share\some transform.mst

;MST1=D:\transforms\my transform.mst

;[Options]

; If a value is present, the [Options] section gives the values of properties to

apply to

; this installation. Specify them in the format:

; PropName=PropValue

; Remember to uncomment both the section name and the value names.

;USERNAME=Customer

;[Display]

; If a value is present, the [Display] section overrides default UI modes.

; Display has one of the following values:

; quiet, none, basic, reduced, full

; CompletionNotice - if this value is present gives whether or not to display

; a setup completion noticefor otherwise quiet setups. The completion notice

will

; only appear if Setup does not need to reboot to complete the installation.

; Remember to uncomment both the section name and the value names.

;Display=None

;CompletionNotice=Yes

[Logging]

; If a value is present, the logging section provides default logging information.

; There are three possible values, all are optional and have defaults as shown
below
When To Use The Setup Settings File

; Value Default Description

; Type <none> Logging mode to use, e.g. ea

; Use * to get all logging

modes; + to append to the

; logfile if it exists.

; Path %TEMP% Path to create logfiles in.

May contain environment variables.

; Final component may be

non-existent and will be created.

; Template SetupLog(*).txt File name for log file. May

contain environment variables.

; Should end in "(*).txt"; the

* is replaced with a zero-padded

; 4 digit number to make the

file name unique.

;Type=icewarmup

;Path=\\ProjSrv\logfiles\

;Template=Microsoft Project %UserName%(*).txt

Template=Microsoft Project 2000 Setup(*).txt

Type=voicewarmup

When a user double-clicks Setup.exe, Setup reads the customizations from the
SETUP.INI file automatically. A Setup settings file should be used when it is
not necessary or viable for users to enter a complicated command line when
they run Setup or when there is no need to create a batch file or shortcut.
The settings file is also useful when an administrator wants to set options that
are awkward to include in a command line. The settings file organizes Setup
options in an easy-to-read format that typically will be more helpful than
creating a long command line.
Administrators can create multiple settings files for different groups of users.
Users specify the settings file they want to use by using the /settings Setup
command-line option. It is also possible to specify Setup command-line options
along with a custom Setup settings file. If a command-line option is specified
that conflicts with a value in the settings file, Setup uses the command-line
option.
Using Switches, Properties, and *.ini Files The Windows Installer Package: INSTMSI(W).EXE

Module 1.2 49

For example, an administrator can create two settings files for the Engineering
and Accounting departments. Users in each department run Setup by using one
of the following command lines:
setup.exe /settings off9engr.ini
setup.exe /settings off9acct.ini

Suppose, however, that these two departments need to use a common set of
custom options, except that each needs a different organization name. Then it is
possible to customize the default settings file (Setup.ini) with the standard
options, and then the Engineering and Accounting departments use the
following command lines to run Setup:
setup.exe companyname="Engineering Department" /settings off9engr.ini
setup.exe companyname="Accounting Department" /settings off9acct.ini

Setup uses the options defined in the settings file and sets the organization name
according to the command line.

Windows Installer
During the course of its operation, SETUP.EXE looks for the installation of
Windows Installer (MSIEXEC.EXE). If it is already installed on the system,
SETUP.EXE calls upon MSIEXEC.EXE, passes on any switch, property and
.INI information, and the installation proceeds on to the second phase of the
installation process.

SETUP.EXE will use the Windows Installer currently on the system, regardless of
the application from which it was installed. For example, if Office 2000 is already on
the system, Project will simply use the Windows Installer placed on the system at
that time, rather than install Windows Installer again. The reason for this is that
Windows Installer is an operating system “service” that allows the operating system
to take over the installation process. Of the current operating systems, only
Windows 2000 ships with this service pre-installed. Therefore, it is necessary to
install the Windows Installer files on Windows 95/Windows 98 and Windows NT
4.0 before Microsoft Project 2000 installation can proceed.
If Windows Installer is not detected, SETUP.EXE installs it. On Windows 9x
platforms, this is done using the file INSTMSI.EXE. On Windows NT
platforms the file INSTMSIW.EXE is used.
Both INSTMSI.EXE & INSTMSIW.EXE files are IExpress packages that
decompress the complete list of Windows installer files to a new directory
within the temp directory. The name of this directory usually is of the form
IXP###.tmp, for example: IXP001.tmp.

A complete list of Windows Installer files is presented in the following table:

Windows installer File Notes
MSI.DLL This is the main Windows installer
engine .DLL. Contains all the functions
that the installer uses to install and
manage applications.
MSIEXEC.EXE The Service used to control .MSI
 Windows installer File Notes
package setups.
MSIHND.DLL The installer handler .DLL. It is
responsible for the behavior of the user
interface of the installer
CABINET.DLL Always installed since later installs
may have compressed cabinets.
MSPATCHA.DLL System .DLL needed by the installer to
support its file patching capabilities.
SHFOLDER.DLL Exposes API's to create special shell
folders for Windows 2000.
IMAGEHLP.DLL Except on Windows 98 where it is
already present.
RICHED20.DLL Renders text and handles user input and
navigation through languages such as
Arabic, Hebrew, Thai, Vietnamese and
Indic.
MSLS3.DLL Support file for RICHED20.DLL.
USP10.DLL Support file for RICHED20.DLL.
MSIINST.EXE Part of the IExpress package that gets
expanded with the installer files.
Handles installation of the Windows
Installer files, then is deleted.

Once the files are expanded, INTSMSI.EXE calls on the internal file
MSIINST.EXE to install the Windows Installer files. MSIINST then performs
the following steps:
 Checks the platform and the version of the files to be installed. On
incompatible platforms, the message box below will appear.

 MSIINST then opens the package containing the included database(s). It

looks for an appropriate language transform (.MST) for the user's system.
 It first tries the User's default language, then the system, then English.
 If there is a transform available, it will be applied when MSIEXEC.EXE is
run.
 If the operating system of the computer is Microsoft®
Windows® 95/Microsoft® Windows® 98, MSIINST will use the
 Module 1.2 51

decompressed files to run the install. If the operating system of the computer
is Microsoft® Windows NT® or Microsoft® Windows® 2000, the following
are true:
 If the user is not an administrator on the machine and Project setup has been
run with the /jm switches:
MSIINST looks for an existing install of the installer with which to run.
This allows non-administrators to upgrade to newer versions of the installer
if the product code has been assigned to them. (Product codes can be
assigned in Windows 2000)
 If a previous version of the installer cannot be found, or the user is an
administrator on the machine, MSIINST attempts to register the
decompressed files as the installer service. These files will be used to run
the install.
MSIINST then calls MSIEXEC.EXE against the included database(s). The
default database is named INSTALL.MSI for Microsoft Project 2000. It is
called with a basic logging /lv switch, which overrides any policy settings.
The log file is created in the temporary directory along with the other
decompressed files. You must retrieve the log file before completing the
installation or it will be deleted. You can override the default command line
to generate a full log elsewhere. The basic command line (currently) for a
normal install is:
msiexec /I instmsi.msi /lv instmsi.log /qb+

To override this, you can run the following:

msiexec /I instmsi.msi /lv c:\instmsi.log /qb+

Or the suggested:
msiexec /I instmsi.msi /lv* c:\intmsi.log /qb+

Note
In the example above, the command line switches are passed directly to
MSIEXEC.EXE. The same functionality happens when including these
switches on the SETUP.EXE command line.

1. The included database copies files as needed, based on file versions.

COPYMSI will always copy MSI.DLL, MSIHND.DLL, and
MSIEXEC.EXE regardless of file versions. This allows you to install older
versions of the installer over your existing copy. COPYMSI is not included
with Office 2000.
2. Next extension and OLE information is registered.
a. On Windows 95/98, this is accomplished via the following commands:
MSIEXEC /d is called to register the extension .msi and .msp.
MSIEXEC /y msi.dll is called to register other OLE information.
These steps are performed via custom actions to prevent the installer
descriptors from being created. The bootstrapping process for the
installer necessitates these steps, which would normally not be
acceptable for a fully functional application using the installer.
MSIEXEC.EXE MSI Package File

b. On Windows NT, the special command line switch MSIEXEC

/regserverCA is called to perform the basic OLE, Service, and extension
registration. Unlike MSIEXEC /regserver, the service is not stopped by
this call. This, again, is necessary because it is called from within the
running service.
3. The verbs for the Windows Installer are then registered from the registry
table in the installer database. Again, these cannot be written from the verb
or extension table because of the procedure the installer uses for installing.
4. If a reboot is detected as necessary, and the installation was run in a mode
that did not suppress reboots (msiexec /q) the installer will prompt you to
reboot. Note that versions of Internet Explorer 4.01 and later will use the
MSI.DLL when available, and this will generally require a reboot to
completely release files in use. Windows installer version 1.1 will probably
attempt to force these applications to close and restart.
5. After the database install is complete, control is returned to MSIINST. If an
administrator ran the install, the service registered to the temporary folder is
stopped. MSIINST waits up to 30 seconds for the service to complete its
operation, and then returns control to INSTMSI.
6. INSTMSI then cleans up any files that are not in use, deletes
MSIINST.EXE, and exits.

Note
INSTMSI and COPYMSI are only available on Windows 2000 during the betas
and for development purposes. The Windows installer comes pre-installed on
these computers, and will only be updated by service packs.

Overview of Windows Installer (MSIEXEC.EXE)

As mentioned previously, Windows Installer is a service of the operating
system that allows it to take over the installation process. Windows Installer
consists of two parts:
1. MSIEXEC.EXE – a client-side installer service that controls the
installation process
2. MSI Package File – contains information used by Windows Installer to
install Project. It is similar in function to the STF file found in ACME setup.

The MSIEXEC.EXE program is the main component of the Windows installer.

When called by SETUP.EXE, MSIEXEC.EXE uses the dynamic link library,
MSI.DLL, to read the windows installer package (MSI file), apply the Windows
installer transform (MST file), incorporate command-line options supplied by
SETUP.EXE and install Office applications.
Warning!

Never run MSIEXEC.EXE directly. Instead SETUP.EXE should be used to invoke

MSIEXEC.EXE. Running SETUP.EXE ensures that all system verifications are
performed.

The Window Installer database (.MSI file) consists of many interrelated tables
that together comprise a relational database of the information necessary to
Transforms

Module 1.2 53

install a group of features. This database replaces the ACME Setup STF and
INF text files as the key components for installing applications. Because the
database is relational, changes made to one table are propagated automatically
throughout the database. This is a very efficient process for introducing
consistent changes into the installation process and means that users can more
easily customize a large application or group of applications. The database
tables reflect the general layout of the entire group of applications, including:
 Available features
 Components
 Relationships between features and components
 Necessary registry settings
 User interface for the application
To create an installation database, program developers must populate the tables
with all the information about the applications and the installation process.
Even though these files are considered relational databases, it is not possible to
open or modify these databases with tools such as Microsoft Access or
Microsoft® SQL Server™. Manually authoring all these tables is a large task
even for a moderate size installation. Microsoft Technical Support does not
support the modification of the MSI package File.

The Microsoft  Window Installer SDK is available to programmers and contains

database creator/editor tools.

For more information on the general scheme of the installer database, see the
Microsoft Project  2000 Resource Kit.

While the MSI Package could theoretically be changed to customize an

installation, the amount of work to do so prohibits it. Instead, the installation
process can be manipulated by applying transforms (.MST) to the MSI
Package. A transform makes changes to some of the elements of the MSI
Package, such as changing the language in the user interface of an application.
It is important to note that the installer does not change the .MSI package itself,
but only temporarily applies the changes from the transform in memory before
executing the package instructions. A transform is typically much smaller than
the package, so you can easily create multiple custom installations by creating
multiple transforms to use with the default package.
While the function of the MSI package relates directly to that of the
SETUP.STF file in ACME setup, the role it plays in customization does not.
Unlike editing the Acme SETUP.STF in the previous versions of Project to
customize the installation, it is not possible to directly modify the MSI Package
File. Instead the Office Custom Installation Wizard is used to create a new
transform with all the changes necessary to customize the Project installation.
When Setup is run with both the package and the transform, the installer applies
the transform to the original package, and Setup uses the altered configuration
to perform the installation. Creating transforms is described in more detail in
Module 2 of this course.
During the setup process the MSI Package and any transforms are initially
copied to a temp folder. At the same time these files are cached in the system
folders of the operating system for use during additional component installs and
maintenance mode. During setup the files in the temp folder are used. After the
initial setup is completed, the temp files and folder are deleted.

On all platforms, the MSI and MST files cached in the system folder are stored in a
file called Installer. These files must be present for any feature to be installed when
“Installed on First Use” is used. These files are also necessary during additional
component installs and maintenance mode setups. All files in the Installer folder are
Read-Only for Everyone on an NTFS partition.

Looking at Windows Installer In-depth

The following are the actions that Windows installer performs during
Microsoft Project 2000 setup:
 Determines if setup is a new install or a maintenance mode setup
 Determines the installation location
 Determines features installed for a typical installation
 Presents the setup user interface
 Completes setup and installs any patches
 Continues after file migration
 Completes setup at first run

C heck to see if No Licen sing

P ro ject is installed W elco m e Scree n A gr eem e nt & P ID

N am e, O r g,
CD Key

Inst all lo catio n No C usto m T ypical o r C u sto m

U pgrad e Inst all?
& D isk Spa ce

Y es Ye s
Custom

Typical

N ext

Ye s
R em o ve P revio u s U pgrad e
V ersio n
F eatu re T ree
No

Lau nch Inst all P ro ject

M ainten anc e M o de

R ebo o t
C lean-u p &
R esu m e C o m plete S etu p
P ro cess
?
Highest Version Wins Versioned Files Win Favor Product Language

Module 1.2 55

The following flowchart illustrates the installation process performed by the

Windows Installer:

Determining Installation Location

The default installation folder for Microsoft Project 2000 is the \Program
Files\Microsoft Office folder on the same drive where the operating system
exists. This folder also is the default folder for other Microsoft Office products.
If you already have an Office 2000 family product installed and you choose to
install Microsoft Project 2000 into a different folder, extra disk space could be
utilized because of the duplicate files in the two folders.

File Versioning Rules of Window Installer

One of the basic processes of any installer is the copying of files. The Window
Installer makes installation of different products more consistent by enforcing
some rules for copying a file to a folder that already contains a file with the
same name. When a file conflict occurs, it is very important to note that
Window Installer never asks you how to handle the situation, but instead
decides how to handle the situation silently. The rules involve the following
three properties of a file:
 Version
 Date
 Language
The rules Window Installer uses in deciding whether to install a file are the
following with more detail below:
 Highest Version Wins
 Versioned Files Win
 Favor Product Language
Figure 2 - Windows
Installer
 Mismatched Multiple Languages
 Preserve Superset Languages
 Non-versioned Files Are User Data (files with no version number)
 Non-versioned Files Using Companion
 Rules Are Global
All other things being equal, the file with the highest version wins, even if the
file on the machine has the highest version.
All other things being equal, a versioned file gets installed over a non-versioned
file.
All other things being equal, if the file being installed has a different language
than the file on the machine, favor the file with the language that matches the
product being installed. Language neutral files are treated as just another
language so the product being installed is favored again.

This is new setup behavior that is introduced by Window Installer. The behavior is
motivated by the desire to guarantee the application being installed will function.
Mismatched Multiple Languages Non-versioned
Preserve Superset
FilesLanguages
Using Companion
Non-versioned Files Are User Data

All other things being equal, after factoring out any common languages
between the file being installed and the file on the machine, any remaining
languages are favored according to what is needed by the product being
installed.
Example:
 Both files have the same version.
 The file on the machine is a multi-language file (English, French, and
Spanish)
 The file to be installed is a multi-language file (English, Italian, and
German).
The new file is installed since there are languages’ remaining after English is
factored out.
All other things being equal preserve the file that supports multiple languages
regardless of whether it is already on the machine or is being installed.
Example 1:
 Both files have the same version.
 The file on the machine is for English and French.
 The file being installed is for English, French, and Spanish.
The new file is installed since it supports a superset of the languages that the
file on the machine supports.
Example 2:
 Both files have the same version.
 The file on the machine is for English, German and Italian.
 The file being installed is for German.
The existing file is used since it supports a superset of the languages that the file
being installed supports.
All other things being equal, when the Modified date is later than the Create
date for the file on the machine, Window Installer does not install the file
because user customizations would be wiped out. When the Modified and
Create dates are the same, the file is installed. Windows Installer assumes that if
the created and modified dates are essentially the same that the file does not
contain any user data so it is safe to overwrite.
All other things being equal, a non-versioned file that is associated with a
versioned file using the companion mechanism abides by the rules for the
versioned file. The only exception is when the versioned file on the machine
and the versioned file being installed have the same version and language but
the companion file is missing on the machine. In this case, the companion file
being installed is used even though the versioned file on the machine is used.
Non-versioned files can inherit installation rules from a versioned file using the
“companion file mechanism”. Placing the primary key of a versioned file in the
Version field for a non-versioned file associates these two files as
“companions”. An example would be an application executable like
MYWARE.EXE and a corresponding settings file like MYWARE.SET. In
Rules Are Global

Module 1.2 57

general, the settings file should follow the same installation rules as the
application executable. So if the companion versioned file being installed gets
used, so should the non-versioned file being installed. The only exception is
when the versioned file being installed is identical to the versioned file on the
machine, but the non-versioned companion file is missing on the computer. In
this case the non-versioned companion file being installed is used even though
the versioned file being installed does not get used.
The rules for determining when to install a file reside in one place within the
installer and are global, meaning they apply to all files equally. For example, an
author of the installation of a product cannot specify to always overwrite a
particular file