Application Packaging Guide

Contact: 09742878183

Page 1

Contents
1.1

Repackaging

1.2

Why do organizations Repackage software

1.3

Differences between Software Repackaging and Software Packaging

1.4

Why not to repackage

1.5

Steps involved in repackaging process

1.6

Advantages of repackaging

2.1

Windows Installer

11

2.2

Overview of Windows Installer Engine

11

2.3

Introduction of Windows Installer technology

12

2.4

Windows Installer Features (MSI benefits)

12

2.5

MSI installation mechanism

14

2.6

MSI internal architecture

15

2.7

Command line options

17

2.8

Windows installer file extensions

19

2.9

Released versions of Windows Installer

19

2.10

GUID in Windows Installer

20

2.11

Component ID

20

2.12

Package Code

20

2.13

Product Code

21

2.14

Upgrade Code

22

2.15

Windows Installer Logging

22

2.16

Active Setup

23

2.17

Component Rules

25

2.18

Multiple msiexec.exe running during an installation

25

2.19

DLL Hell

26

2.20

Companion Files

26

2.21

File Versioning Rules

27

2.22

Per-machine and Per-user installations

28

2.23

Transforms

28

2.24

Upgrades

31

2.25

Properties

34

2.26

Application Isolation

41

2.27

Merge Modules

43

2.28

ICE Validation

44

2.29

Summary Information Stream

45

2.30

Standard Actions

46

Contact: 09742878183

Page 2

2.31

Custom Actions

50

2.32

Registry

55

2.33

Shortcuts

56

2.34

INI Files

57

2.35

Services

58

2.36

ODBC

58

2.37

File associations

59

2.38

Environment Variables

60

2.39

Dll Cache folder

61

2.40

System File Checker

61

2.41

Windows File protection

61

2.42

Files, folders and registries are not getting remove after uninstall

61

2.43

Windows Installer Tables

62

3.1

Wise Setup capture

66

3.2

Create a transform using Install Tailor in wise package studio

73

3.3

Create a major upgrade using wise package studio

76

3.4

Different ways of giving permissions in MSI installation

81

3.5

Installing and loading Excel add-ins with Wise script

90

3.6

Packaging Device driver applications

92

3.7

Step by step procedure for creating a patch using WPS

93

3.8

Nested MSI installation

98

3.9

Significance of SelfReg table entry

100

3.10

Common registry entries used during packaging

104

3.11

Files and registry keys to be excluded while doing setup capture

106

3.12

Capture Methodologies Smart Monitor and Snapshot

108

Contact: 09742878183

Page 3

1.1 - Repackaging

Repackaging is the process of capturing the changes made by an installation program for the
purpose of creating a new, customized installation. This new installation, which is called a
package, is designed to support company standards and distribution methods.

Application packaging is a process of binding the relevant files and components to build a
customized application for a customer using tools like Wise Package Studio and Install Shield.

Repackaging saves time, effort, and money by allowing the system administrator to customize
installations to meet the standards set for software distribution within their company.
1.2 - Why do organizations Repackage software

The main reason for repackaging an installation is to create a consistent, yet customized,
installation. The main benefit of creating a consistent, customized installation is to reduce desktop
support costs.

By standardizing the applications that are installed on company desktops, administrators reduce
variability in end users desktops which results in reducing the support costs in resolving issues.
Repackaging seeks to eliminate these types of issues through customized consistency.
Customized consistency means customizing, or repackaging, an installation so that it behaves in
a manner consistent with the companys standards.
1.3 - Differences between Software Repackaging and Software Packaging

Both system administrators and software developers create installations, however, the methods
for how and why they create installations vary.

Administrators repackage existing installations in order to customize the package to their

companys standards for mass deployment. In contrast, software developers typically author new
installations based on the requirements of the application they are installing.

The following chart differentiates software developers and system administrators requirements
when creating installations.

Contact: 09742878183

Page 4

Software Packaging

System Administrators (Repackaging)

Method of installation creation: author

Method of installation creation: repackaging

new installations

Software developers typically author new

installation by repackaging it.

Administrators

customize

an

existing

installations from the ground up.

Install on one PC

Install on many PCs.

Target is individual PCs.

An application can be distributed via a

network, eliminating the need to walk to each
PC and install it individually.

Minimal integration with other applications

Integration with other applications is critical

Little or no concern if the installed application

It is imperative that each installed application

breaks other applications.

work with all other applications on the end

users PC.

Support several platforms

Support limited number of platforms

Doesnt know specification of target platform,

Knows target desktop specifications, so

so application installation is designed for

application installation only needs to run on

several platforms.

specific platforms.

Flexible installation

Inflexible installation

Installation can be installed where a user

Requires the application to be installed in the

decides.

same location every time.

Media distribution

Network distribution

Typically distributes an application on a

CD for each user.

network to multiple users.

Extensive user input

No user input desired

Users interact with the installation and make

The system administrator determines what

their own choices about how the installation is

features users will have and creates an

installed.

automated installation that installs without user

Distributes an

application through

the

interaction.
User-executed installation

Distribution system-executed

User initiates the application installation.

Distribution occurs through a network and

can run silently on users machines as they
work, during the night, or when the user
executes the application.

Reports status to user

Reports status to distribution system

User receives constant messages about the

User is not encumbered by application

application installations progress.

installation status reports.

Contact: 09742878183

Page 5

1.4 - What Not to Repackage

It is not recommended to repackage certain types of applications. These include:

1. MSI files
Installations that are already in .MSI format should not be repackaged, but instead should be
customized using a transform. A transform customizes an .MSI installation without recreating it
from scratch.

2. Operating systems.
Capturing is not appropriate for operating systems or service patches. It is not recommended to
repackage these types of applications.
3. Windows Media Player, Microsoft Internet Explorer, anti-virus software, and device drivers.
All four types of applications listed make low-level changes to the operating system involving
Windows File Protection. It is not recommended repackaging these applications. But still we can
repackage these applications at own risk.
1.5 - Steps involved in Repackaging Process

1. Review packaging requirements with the customer - Requirement Analysis

2. Analyze the vendor package - Technical Evaluation
3. Repackage the application Packaging using Setup Capture
4. Customize the package Editing the package using Windows Installer Editor
5. Test the package Quality Assurance or User Acceptance Testing (UAT))
6. Release the package to end users - Deployment

Deployment

Requirement
Analysis

Evaluation

Testing (UAT)

Packaging

Figure 1: Repackaging life cycle

Contact: 09742878183

Page 6

Step 1: Review packaging requirements with the customer

The first step in a successful repackaging project is to gather information from the customer of the
project. This information is then included in a report that the repackaging team refers to
throughout the repackaging process. Without this information, the repackager will be unsure how
to install the application correctly.

Step 2: Analyze the vendor package

The next step is to become familiar with the applications installation. The report created in Step
1, which involved instructions from the customer, will be helpful in understanding how to proceed
through the installation.
The information learned in this phase should be added to the report for a thorough record of the
actions to take when repackaging starts.
The goal in familiarization with the applications installation is to understand exactly how the
installation functions. In other words, what happens on the PC when the installation is run such as
below?

What files are installed?

What registry keys are created?
Are shortcuts installed on the desktop?
Is there any MSI present inside the EXE?

Step 3: Repackage the Application and Customizing

Completing steps 1 and 2 provides the information necessary to repackage the applications
installation.
All package development work should be done on a clean machine in order to not introduce
extraneous dependencies into the package. Else, the repackaged application will be dependent
on the files that were already installed on the repackaging machine.

To eliminate this issue, always repackage on a clean machine. Also, do not run any other
applications on the clean machine while using the packaging tool; otherwise the integrity of the
package is compromised.
Use Wise Package studios Setup Capture and Windows Installer Editor Tool for repackaging the
applications.

Contact: 09742878183

Page 7

After finishing the capturing process, the repackager can customize the package in an .MSI editor
or a script-based editor, depending on the format in which the package was initially created.
Customization steps might include:

Creating a silent installation that does not require end user interaction.
Editing feature names.
Creating additional shortcuts, creating environment variables etc.
Setting system requirements, such as requiring the destination machine to have Windows 98 or
a higher operating system installed, for the installation to run.
After the repackager makes modifications, the installation should be tested to be sure it compiles
without errors and functions in the intended manner.

Step 4: Test the package

Testing is an important step in creating a robust package that installs and functions correctly.

Complete package testing requires two kinds of tests:

-

Quality Assurance testing by members of the repackaging team and

User Acceptance testing by the customer and/or end users.

The repackaging team needs to verify that the package performs as expected according to the
report created in Step 1 with the projects customer, the uninstall functions correctly, and there
are no conflicts between the package and other software applications installed on the end users
PCs.

The focus of user-acceptance testing is to confirm that the application conforms to users
expectations and that it functions as expected. This means that users can execute basic tasks
such as opening the application and using common features.

Step 5: Release the package to Customers

Once the package is tested, it is ready for distribution. Distribution can happen in a number of
ways.

Contact: 09742878183

Page 8

The installation can be copied to a CD-ROM, network share point, or intranet site and users could
install the package from that location. Or a distribution system, such as Microsoft SMS, Tivoli, CA
Unicenter, Novadigms Radia, Marimba, and others can distribute the package.
Depending on the number of end-users who will receive the package, a pilot test may be
warranted before it is rolled out to the entire organization. This can be accomplished by rolling
out the package in stages, in case there is a problem and the package needs to be recalled.

Distribution of the package can occur in waves: distribute to 10% of users first, a few days later
distribute the package to 20% of the remaining users and so on.
1.6 - Advantages of Packaging:
Customize Applications to suit the user needs.
Simplify the Installation and Un-installation Procedures.
Saves Time in both Installation and Un-installation.
Once packaged, applications can be quickly installed on a range of desktops in multiple
locations, saving administrative costs, simplifying the management of licensing fees and
minimizing support and repair expenditures.
Saves Space of the product by doing apt modifications to applications.
Has a great flexibility of obtaining the lost files through a phenomenon called Self Heal,
this reduces the down time of application. If a critical file (a .DLL or .EXE file, for
example) that is part of the distribution is corrupt or is deleted, the user can be prompted
to repair the installation by presenting the original .MSI distribution. Additionally, if the
installation media is available (for example, on a network share), the repair simply
happens automatically.
Can be advertised. So that on demand installation could take place.
Upgrading of the application can be done with ease.
Clean installation and Un-Installation is achieved by a process called Roll-Back.
Simplifies management of new user set-up along with the revision and distribution of
software repairs and new applications to existing users. Application recovery can also be
improved.
Helps eliminate uncontrolled software downloads and installation, enables applications to
be safely removed and reduces non-business traffic on a corporate network.
Using .MSI format can automate software distribution process and ensure that the
installation doesn't break other applications that have already been installed.
Application is installed via an OS service.

Contact: 09742878183

Page 9

State management is maintained. In the past, it's been difficult to know whether an
application is installed on a machine. You would have to query for a .DLL with a specific
version number or determine whether an .EXE file with a specific name was present.
Windows Installer provides an application programming interface (API) that lets
programmers and administrators see whether a specific application is installed on a
machine.
Scriptable API. This whips together a VBScript to help us with the MSI file manipulations.
The API to manipulate MSI files is so powerful that it can create, validate and update
packages, trigger installs and uninstalls, examine the MSI repository data on computers,
and perform some custom actions.
Served installs. Because MSI files can be housed in a share point and delivered via a
server, we can keep our installation files all in one place or move them around -- closer to
the users if necessary.

Contact: 09742878183

Page 10

2.1 - Windows Installer

The Windows Installer (previously known as Microsoft Installer) is a software component used for
the installation, maintenance, and removal of software on modern Microsoft Windows systems.
The Windows Installer is an operating system service that was developed by Microsoft to improve
the installation and uninstallation of programs, make software deployment in corporate networks
easier, and to solve common problems such as shared dll conflicts.
2.2 - Overview of Windows Installer Engine

On Windows, the installer consists of two executable components: a Client Install Engine that
runs with user privileges and an Install Service that can run with elevated administrative privileges
because it is implemented as a Windows Service. All changes to the system configuration are
done as a single installation transaction by the Install Service.

In addition to the install package for the product being installed, the installer can apply a
"transform." This is a method of customizing the package for a specific group of users.
Transforms can be used to disable or enable certain installation features, or even add additional
items to the installation (for example, to add customer-specific content to the rollout of a product).

Contact: 09742878183

Page 11

2.3 - Introduction to Windows Installer Technology

Windows Installer Technology offers many advantages to developers and systems admins.
Standardization of installs and uninstalls will simplify an administrator's job by creating one set of
rules for file overwrites, instead of leaving rule selection up to individual developers.

Previously, installation packages took the form of a setup.exe file. Unfortunately, inconsistencies
in the way independent software vendors and internal software development groups created
these installation files sometimes led to complications when administrators attempted to manage
automated installations.

The emerging standard is for Windows Installer to use the msiexec.exe program to process the
installation packages at an end user's PC. The packages follow a standardized database
structure containing the information that Windows Installer requires to install or uninstall an
application and to run the user interface for the setup.
Each installation package includes an .msi file containing the installation database, a summary
information stream, and data streams for various parts of the installation. The .msi file can also
contain one or more transforms, internal source files, and external source files or cabinet files
required by the installation. This approach enables Windows Installer to determine components
that belong to an application, and to safely remove application components and restore a system
to a working state.
Furthermore, because Windows Installer is a service, it is designed to support software
installations as the local Administrator role in locked environments, enhancing the application
process.
2.4 - Windows installer features (MSI benefits)
2.4.1 - Advertisement
Windows Installer can advertise a product rather than actually installing it. The product will appear
installed to the user, but it will not actually be installed until it is run for the first time by triggering
an entry point (by means of a Start menu shortcut, by opening a document that the product is
configured to handle, or by invoking an advertised COM class).

A package can be advertised by an administrator using Group Policy or other deployment

mechanism, or by running the msiexec executable with the /jm (for per-machine advertisement)
or /ju (for per-user advertisement) switch.

Contact: 09742878183

Page 12

2.4.2 - Installation on demand

Similar to advertisement, it consists in the installation of features as soon as the user tries to use
them. For example if the user tries to launch the advertised shortcut, the actual installation starts
at that point.
2.4.3 - Rollback
All installation operations are transactional. For each operation that Windows Installer performs, it
generates an equivalent undo operation that would undo the change made to the system. In case
any script action fails during deferred execution, or the operation is cancelled by the user, all the
actions performed until that point are rolled back, restoring the system to its original state.
2.4.4 - Self-Repair or Self-heal
When launching an application, files, registry entries etc. which are marked as component key
paths are automatically checked for their existence in the machine. If they are deleted or
damaged, the feature to which the component belongs will be installed again.

2.4.5 - Source resiliency

Applications that rely on network resources for installation-on-demand are susceptible to source
failures if the source location should change for any reason or become damaged. The Windows
Installer provides source resiliency for features that are installed on-demand by using a source
list.
The source list contains the locations searched by the installer for installation packages. The
entries in this list can be network locations, Uniform Resource Locators (URLs), or compact discs.
If one of these sources fails, the installer can quickly and seamlessly try the next.
2.4.6 - Administrative installation
An administrative installation creates an uncompressed source image for a product, typically to
be used for installing or running an application from a network location. An administrative
installation is not a typical installation, in that it does not create any shortcuts, register any COM
servers, create any Add or Remove Programs entry, and so on. Often an administrative
installation enables a user to install the product in such a way that its features run from the
uncompressed installation source.
An administrative installation is performed by running the msiexec executable with the /a switch.

Contact: 09742878183

Page 13

2.4.7 - Custom Actions

The developer of an installer package may write code to serve their own purpose, delivered in a
DLL, VBScript, and Jscript etc. This can be executed during the installation sequences, including
when the user clicks a button in the user interface, or during the InstallExecuteSequence. Custom
Actions typically validate product license keys, or initialize more complex services.
2.4.8 - Merge Modules and Nested Executable
A Windows Installer package may contain another package to be installed at the same time.
These are ideally provided as an .msm file component, but may also be a separate executable
program which will be unpacked from the installer package during the InstallExecuteSequence
and can be run immediately. The file can then optionally be deleted before the end of the
InstallExecuteSequence, and so is ideal for using with older installers.
2.4.9 - Elevated privileges
Setup can run with Administrator privileges even if it is launched from a normal user account.

2.5 - MSI Installation mechanism

There are three ways in which a managed application is installed or removed from the machine.
They are:
-

Installation

Un-Installation

Roll back

Installation
The MSI Packaged Installation usually takes place in two phases:
-

Acquisition

Execution

Acquisition
The acquisition is further divided into two phases, in which the first phase collects the information
from the user and the second phase acquires the information from the MSI database. Over here,
the Windows installer will generate the installation and the un-installation scripts.

Execution
Once when the required information is collected from the user and the database, the MSI
executes the Installation script and kicks off the installation of components.

Contact: 09742878183

Page 14

The Windows installer also has the ability to detect and restore the resources of an application,
which are required to make its successful execution.

Un-Installation
This process occurs only when it finds an application that is already installed. Over here, a uninstallation script is executed and it takes the validating entries from the MSI database and
removes the application clearly.

Roll back
This major feature of MSI Technology is used to obtain clean installation and un-installation of an
application. This process is used only during installation or un-installation phase. When an
application is terminated or stopped while installing or uninstalling, the roll back restores the
system to its previous stable state. This explains that, the files that were added during the initial
process of installation will also be removed.

2.6 - MSI internal architecture

A Windows Installer installation package (.msi) can contain everything required to perform an
install or uninstall with a user interface. Optionally, the package file can contain additional
streams with the actual file bits compressed in cabinet files. Package files have the extension
.msi and are associated with msiexec.exe, which kicks off the installation process.

The Technology Consists of Installer Client, Installer Server and Database (MSI). The installer
organizes installations around the concept of components and features, and stores all information
about the installation in a relational database (MSI).

Figure 2: MSI Architecture

Contact: 09742878183

Page 15

The MSI relational database will have the information in a hierarchical nature and will include:
Product This is the highest layer of hierarchy. It usually identifies what needs to be installed, for
example Microsoft Office 2007. The product is identified by its Product Code, which is globally
unique identifier specific to the product.
Features The product is composed of Features. Features are units of installation that can be
discretely selected during installation. For example in MS Office, MS Word, MS Excel, MS
PowerPoint are features and the users can select and deselect them when installing MS Office.
Features can also include Sub-Features and it had the parent child relation between them. For
example in MS Excel, the help files are a sub-feature.
Features can be shared among applications. One good example is the Spell Checker in MS
Office. It is shared between all Office applications, but it is not automatically removed when a
feature that uses the shared feature is uninstalled.
Components Features are made of components. A Component is a collection of files, registry
keys, shortcuts and other types of resources. Components are single units that are identified with
special GUIDs called the component code within the installation database.
Because they are considered as single, cohesive units, components do not share files or any
other objects.
Components can be shared between applications, but if two applications need to rely on the
same component, both must include in its installation.
Resources Components consist of resources which are nothing but files, registry keys,
shortcuts, icon files etc.
Key Paths A key path is a specific file, registry key, or ODBC data source that the package
author specifies as critical for a given component. Because a file is the most common type of key
path, the term key file is commonly used. A component can contain at most one key path; if a
component has no explicit key path, the component's destination directory is taken to be the key
path.
When an MSI-based application is launched, Windows Installer checks the existence of these
critical files or registry keys (that is, the key paths). If there is a mismatch between the current
system state and the value specified in the MSI package (e.g., a key file is missing), then the
related feature is re-installed. This process is also known as self-healing or self-repair. No two
components should use the same key path.

Contact: 09742878183

Page 16

Windows installer uses the key path to determine the health of each component with the product.
If the keypath is missing or incomplete, Windows installer service will trace it back to the feature it
belongs and reinstall the entire Feature and Sub-feature. This is the engine that provides selfhealing for windows installer service installations.

2.7 - Command line options

Msiexec.exe /Option <Required Parameter> [Optional Parameter]

Install Options
/I

Installs a product

/j

Advertise a product

Advertises to the current user

m - Advertises to all users of machine
g - Language identifier
t - Applies transform to advertised package

/a

Administrative Installation

/x

Uninstall a product

E.g.: Msiexec /I C:\Adobe.msi.

Display Options (during Installation & Uninstallation)
/quiet

no user interaction

/passive

unattended mode

/q

sets user interface level

n - No UI
n+ - No UI except for a modal dialog at the end
r

- Reduced UI with no modal dialog at the end

b - Basic UI
b! - Basic UI with hide cancel button
b+ - Basic UI with a modal dialog at the end
b+! Basic UI with a modal dialog at the end & hide cancel
button
b- - Basic UI with no modal dialog at the end
b-! - Basic UI with no modal dialog at the end & hide cancel
button
/help

Contact: 09742878183

help information

Page 17

Restart Options
/norestart

Do not restart after the Installation

/promptrestart -

Prompts the user for restart if necessary

/forcerestart

Always restart the computer after Installation

Logging Options (Writes logging information into a log file at the specified existing path.
The default value is 'iwearmo'

/l

I - Status messages
w - Nonfatal warnings
e - All error messages
a - Startup of actions
r - Action-specific records
u - User requests
c - Initial UI parameters
m - Out-of-memory or fatal exit information
o - Out-of-disk-space messages
p - Terminal properties
v - Verbose output
x - Extra debugging information
+ - Append to existing log file
! - Flush each line to the log
*- Log all information, except for v and x options

/ log

<Log File>

Equivalent of /l* <Log File>

E.g.: Msiexec /I path of msi /l*v log file path /qb+

Update Options
/update
/uninstall
/p

- Applies a Patch

Repair Options (Repairs a product)

/f

- Repairs a product
p - Only if file is missing If file is missing or an older version is installed (default)
e- If file is missing or an equal or older version is installed
d - If file is missing or a different version is installed
c - If file is missing or checksum does not match the calculated value

Contact: 09742878183

Page 18

a - forces all files to be reinstalled

u - All required user-specific registry entries (default)
m - All required computer-specific registry entries (default)
s - All existing shortcuts (default)
v - Runs from source and reaches local package

Registering Dll files:

regsvr32 <Path to Dll File>

For Register the Dll

regsvr32 /u <Path of DLL>

For Unregistered the Dll

regsvr32 /s <Path of DLL>

For Silent register

For registering a exe file

Registering EXE files:

<Path to exe file> /regserver

<Path to exe file> /unregserver -

For unregistering a exe file

2.8 - Windows Installer File extensions

.msi

Windows Installer Database

.msm

Windows Installer Merge Module

.msp

Windows Installer Patch

.mst

Windows Installer Transforms

.idt

Exported Windows Installer Database Table

.pcp

Windows Installer Patch creation File

.cub

Validation modules

2.9 - Released versions of Windows Installer

Windows Installer Version

Description

1.0

Released with Office 2000 and as a redistributable

1.1

Released with Windows 2000.

2.0

Released with Windows XP, XP SP1, Windows Server 2003

3.0

Released with XP SP2

Released as a redistributable package

3.1

Released as a redistributable package

Included with XP SP3, 2003 SP1 & SP2

4.0

Contact: 09742878183

Released with Vista, Vista SP1 and Server 2008

Page 19

4.5

Released with Vista SP2, Server 2008 SP2

Released as a redistributable package

5.0

Released with Windows 7 and Windows Server 2008 R2

2.10 - GUIDs in Windows Installer

GUID is the abbreviation for Globally Unique Identifier. It is a 128 bit number, represented as a
string of hexadecimal digits. There is an operating system function that can create such unique
numbers.

For example, a GUID will look like {50EFC3E0-8AF8-11D4-94C7-00E09876D9C4}.

2.11 - Component ID
Component ID is used to identify a specific component in a windows installer product.
Every component in a windows installer database should be assigned with a Component ID or
Component GUID.

Every Component GUID should be unique and any two components that share the same
component ID are treated as multiple instances of the same component regardless of their actual
content.
Only a single instance of any component is installed on a user's computer. Therefore, no file,
registry entry, shortcut, or other resources should ever be shipped as a member of more than one
component. This applies across products, product versions, and companies.
2.12 - Package Code
As the name implies, the package code identifies a specific msi file. Just note it again: not a
product, but an msi file.
No two msi files that are not identical copies of each other should ever have the same package
code, even if they install (different versions of) the same product. Windows Installer keeps copies
of all installed msi files in a cache (under C:\Windows\Installer folder).

If you start a Windows Installer setup, the runtime engine first checks to see if an msi file with the
same package code already exists in the cache, and uses this copy instead. So whenever you
rebuild your msi file you should give it a new package code.

Contact: 09742878183

Page 20

2.13 - Product Code

The product Code is again a unique GUID which identifies a specific product.

This code should only be changed if significant changes are made to the application -changes
that warrant calling it a different product.

Two different products should never have the same product code.
If you have two flavors of a product, say "Acrobat Express" and "Acrobat Professional", these
should have different product codes. The same is true for different language versions of a
program - they must use different product codes.

Windows Installer cannot install two instances of the same product (i.e. two msi packages with
the same product code) on the same machine.

Using different product codes is required to allow two applications to coexist on the same
computer. If you try to install two msi packages with different package codes, but with the same
product code, you will get an error message as shown below.

The following changes in your setup project require that you change the product code:
The name of the .msi file has been changed.
The component code of an existing component has changed.
A component has been removed from an existing feature.
An existing feature has been made into a child of an existing feature.
An existing child feature has been removed from its parent feature.

Note that adding a new feature (top level or child), consisting entirely of new components, does
not require changing the product code.

Contact: 09742878183

Page 21

2.14 - Upgrade Code

The upgrade code is a unique GUID which identifies a specific product family.

For example the different version of MS Office, say Office 2000, Office 2003, Office 2007, and
Office 2010 will share the same upgrade code.

Such a group of related applications can consist of different versions and different language
versions of the same product.

You should never change this code, unless you want to prevent major upgrades.
A major upgrade could replace Acrobat Express with Acrobat Professional. Therefore both
members of the Acrobat family should have the same upgrade code.

When you install Acrobat Professional, Windows Installer will detect that another family member
is already installed, and automatically remove Acrobat Express before installing Acrobat
Professional.

2.15 - Windows Installer Logging

Windows Installer records errors and events in its own error log and in the Event log. The
diagnostic information that the installer writes to these logs can help users and administrators
understand the cause of a failed installation.
The type of logging performed by the installer is determined by setting the logging mode. Logging
is enabled and the mode can be set by following methods:
Use the /L option with Msiexec.exe. For details refer Command Line Options given
earlier.
Use the Logging policy Create the registry string key Logging with the value
voicewarmup under the registry hive
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer. After
enabling this log file option, whenever we run an installation program, a log file with a
dynamic name like MSI***.log will be generated under the Temp directory.

Contact: 09742878183

Page 22

Logging of Action Return Values

Error Code

Values that appear in log

Description

ERROR_FUNCTION_NOT_CALLED

Function could not be

executed.

ERROR_SUCCESS

Action completed
successfully.

ERROR_INSTALL_USEREXIT

User canceled installation.

ERROR_INSTALL_FAILURE

Fatal error.

ERROR_INSTALL_SUSPEND

Installation suspended,
incomplete.

ERROR_SUCCESS

Action completed
successfully.

ERROR_INVALID_HANDLE_STATE

Handle is in an invalid state.

ERROR_INVALID_DATA

The data is invalid.

To create a log file using command line, type

Msiexec.exe /I Product.msi /L*v C:\Install.log /qb+

2.16 - Active Setup

Active setup provides a solution when the aim is to deliver user based components when
no advertised entry points exist in an MSI package. Here the user based components means
that if files going under %USERPROFILE% folder and/or the registry entries populated under
HKCU registry hive.
Most packages will contain some kind on entry point; commonly an advertised shortcut. When
launching this kind of shortcut Windows Installer will check the key path of the component the
shortcut belongs to and verifies that the component is installed. If it is found to be missing
Windows Install will kick off a self-repair.
So what do you do if there are no shortcuts to advertise? Active Setup will solve the
problem.
On logon by the new user, the following registry keys are compared:

Contact: 09742878183

Page 23

HKLM\Software\Microsoft\Active Setup\Installed Components\<ProductCode>

HKCU\Software\Microsoft\Active Setup\Installed Components\<ProductCode>
If the HKCU key is not found, the content of the string value StubPath is executed. The
HKLM key is then copied to HKCU.

The executable in StubPath can be anything (a VBS script, a regsvr32.exe call, etc), but our aim,
in this example, is to deliver missing current user data from a previously installed MSI. To do this
we need to force the package to repair, so msiexec.exe will be used:

msiexec.exe /fpu [ProductCode] /qb+

/f - Repair
/p - only if file is missing
/u - all required user-specific registry entries

HKLM should look as follows:

[HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode]]

"Version"="1"
"StubPath"="msiexec.exe /fpu [ProductCode] /qb+"

Where a version is included; StubPath will only execute if the version of HKCU is less than the
version of HKLM.

When a new user logs on Windows will find the HKCU active setup key missing, run Msiexec.exe
with the repair arguments from StubPath and copy the HKLM key to HKCU. Next time this user
logs in the repair won't run as the key already exists in HKCU.

Contact: 09742878183

Page 24

2.17 - Component Rules

Every component should have a component GUID.

Do not mark an editable file (like text file, word document) as a component key
path.
Two components must not have the same key path file. The key path value points to
a particular file or folder belonging to the component that the installer uses to detect the
component. If two components had the same key path file, the installer would be unable
to distinguish which component is installed.
No file, registry entry, shortcut, or other resources should ever be shipped as a
member of more than one component. This applies across products, product versions,
and companies.
Never create two components that install a resource under the same name and
target location. If a resource must be duplicated in multiple components, change its
name or target location in each component. This rule should be applied across
applications, products, product versions, and companies.
Do not create a version of a component that is incompatible with all previous
versions of the component. This rule should be applied across applications, products,
product versions, and companies.
Do not create components containing resources that will need to be installed into
more than one directory on the user's system. The installer installs all of the
resources in a component into the same directory. It is not possible to install some
resources into subdirectories.
Do not include more than one COM server per component. If a component contains a
COM server, this must be the key path for the component.
2.18 - Multiple msiexec.exe running during an installation

A number of msiexec.exe processes can be running during an installation. The reason for this is
that Windows Installer uses a client-server model for performing installations. Additionally for
security reasons, Windows Installer hosts DLL and script custom actions in a "sandbox" process.
Depending on how the install was initiated, one of the msiexec.exe processes can be the client
process. Another msiexec.exe process is Windows Installer service.
Any remaining msiexec.exe processes are usually sandbox processes for hosting custom
actions.

Contact: 09742878183

Page 25

The determination as to which msiexec.exe process will serve as the sandbox process for a script
or DLL custom action depends in part on whether the custom action will run elevated or
impersonated and whether the custom action is 32-bit or 64-bit.

2.19 - DLL Hell

DLL Hell is the problem related to .DLL (dynamic linking library) files. In the most typical case,
one application will install a new version of the shared component (.dll file) that is not
backward compatible with the version already on the machine, or an application may
install the previous version. All it takes is a single DLL, VBX or OCX to be missing, or present
in an older version for an application to fail.
DLL Hell refers to a set of problems caused when multiple applications attempt to share a
common component like a dynamic link library (DLL). The reason for this issue was that the
version information about the different components of an application was not recorded by the
system.

In windows applications some dlls are shared ones. Suppose App1 is an application running
perfectly. It is sharing a shared dll named shared1.dll. You are installing another application
App2. Suppose App2 application is also having a shared dll named shared1.dll. At the time of
App2 installation, installer will overwrite the shared1.dll which is already there on our system and
being shared by App1. The new shared1.dll may be different than the previous dll which is
overwritten. Now the application app1 which is depending on overwritten shared1.dll will become
defunct. App1 will fail which is referred as dll hell.
In Windows installer technology, the DLL Hell issue is overcome by using the techniques
like Application isolation, Shared DLL reference count and file versioning rules.

2.20 - Companion Files

The use of companion files enables you to bind the installation action of one file to another file.
For example, if your installation project has two filesFileA.exe and FileB.dat - companion files
let you bind FileB.dat to FileA.exe so that if FileA.exe needs to be installed or reinstalled, then
FileB.dat is also installed or reinstalled. If FileA.exe needs to be uninstalled, then FileB.dat is also
uninstalled.

Contact: 09742878183

Page 26

This mechanism is useful when trying to override the Windows Installers default file versioning
rules. For instance, file versioning rules state that for non-versioned files, any file on the target
machine that has a modified date later than its created date is considered user data and should
not be overwritten.

In the following example, FileA is the companion parent and FileB is the companion file.

File

Version

FileA.exe

1.0.0.0

FileB.dat

FileA.exe

2.21 - File Versioning Rules

Any installer program is just the actual installation of files. Determining whether to install a file is a
complex process. Once determined by the installer that a file should be copied, the process is
complicated if another file with the same name exists in the target folder. In such situations,
making the determination requires a set of rules involving the following properties:
Version
Date
Language
In this case, the Windows Installer uses the following rules, all other things being equal, to
determine whether to install the file or not.
1. Highest Version Wins - All other things being equal, the file with the highest version
wins, even if the file on the computer has the highest version.
2. Versioned Files Win - A versioned file gets installed over a non-versioned file.
3. Favor Product Language - If the file being installed has a different language than the file
on the computer, favor the file with the language that matches the product being installed.
4. Mismatched Multiple Languages - After factoring out any common languages between
the file being installed and the file on the computer, any remaining languages are favored
according to what is needed by the product being installed.
5. Preserve Superset Languages - Preserve the file that supports multiple languages
regardless of whether it is already on the computer or is being installed.

Contact: 09742878183

Page 27

6. Non-versioned Files are User Data - If the Modified date is later than the Create date
for the file on the computer, do not install the file because user customizations would be
deleted. If the Modified and Create dates are the same, install the file. If the Create date
is later than the Modified date, the file is considered unmodified, install the file.
2.22 - Per-Machine and Per-User installations
The per-machine installation of an application means that the application is available for all users
of a computer.
It also means:
Shortcuts are installed to the All Users profile.
COM registration is always written to HKLM\Software\Classes.
On Windows 2000 and Windows NT, at elevated privileges.
Icons and transforms are stored in %WINDOWS%\Installer\{ProductCode}.
The per-user installation of an application means that the application is available only for a
particular user. It also means that:
Shortcuts are installed only to that users' profile.
Applications appear only under Add/Remove Programs on Control Panel for users that
have installed the applications.
On Windows 2000, COM registration is written to HKCU\Software\Classes.
Applications may or may not run at elevated privileges.
Icons and transforms are stored in %USERPROFILE%\Application
Data\Microsoft\Installer\{ProductCode}

2.23 - Transforms

Transforms alter the installation database (.msi) and can be used to encapsulate the various
customizations of a base package required by different groups of users. The MSI format lets you
easily modify or customize the software install by creating a transform.

An MSI transform is a file (.mst) that describes how windows installer service should install an
MSI package. A transform is a collection of changes applied to an installation. By applying a

Contact: 09742878183

Page 28

transform to a base installation package, the installer can add or replace data in the installation
database. The installer can only apply transforms during an installation.

The three types of Windows Installer transforms are

Embedded Transforms
Secured Transforms
Unsecured Transforms
Embedded transforms
Embedded transforms are stored inside the .msi file of the package.
This guarantees to users that the transform is always available when the installation package is
available.

If the installation source is read-only, such as a CD or a network share to which the person
creating the transform has read-only access, this is not an option because you must be able to
write to the source to embed the transform in the *.msi file.

To add an embedded transform to the transforms list, add a colon (:) prefix to the file name.
Embedded transforms are not cached separately on the client computer, because Windows
Installer can always obtain the transform from the .msi file. .Embedded transforms might be used
in combination with secured or unsecured transforms.

Secured transforms
Secured transforms are recommended for security reasons. If an application is installed at an
elevated level, either per-user or per-computer, a user with low rights can modify an unsecured
transform and use it to make changes to the computers that have elevated privileges.

Secured transforms are stored locally on the client computer in a location where, on a secure file
system such as NTFS, the user does not have write access. Such transforms are cached in this
location during the installation or advertisement of the package. During subsequent installationon-demand or maintenance installations of the package, Windows Installer uses the cached
transforms.

To specify secured transform storage, set the TransformsSecure policy, or set the
TRANSFORMSSECURE property, or pass the @ or | symbol in the transforms list.

Contact: 09742878183

Page 29

Important: You cannot combine unsecured transforms and secured transforms in the same
TRANSFORMS list.

If a user removes the product, Windows Installer removes all secured transforms for that product
from that user's computer. If Windows Installer finds that a secured transform is not locally
available, it then attempts to restore the transform cache from a source.

Secure transforms can be

Secure-at-source
Secure-full-path
Secure-At-Source transforms that are missing from the local transform cache are restored from
the root of the source of the .msi file.
Secure-Full-Path transforms that are missing from the local transform cache are restored from
the original full path specified by the transform list.
Unsecured transforms

Unsecured transforms have not been secured as described in Secured Transforms in the
preceding list. When a package is installed or advertised as a per-user installation, and the
package has unsecured transforms, Windows Installer saves the unsecured transforms in the
Application Data folder in the user's profile. This enables a user to maintain a customization of a
product while roaming from computer to computer.
When the package is installed or advertised as a per-computer installation, and the package uses
unsecured transforms, Windows Installer saves the unsecured transforms in the
%windir%\Installer folder.

If the cached copy of the transform becomes unavailable, Windows Installer can restore the
transform cache using a source listed in the SOURCELIST property. Windows Installer uses the
same method to search for a transform source as it uses to search for an .msi file.
To apply unsecured transforms when installing a package, pass the transform file names in the
TRANSFORMS property or in the command-line string, and do not begin the string with the @ or
| characters. Do not set the TransformsSecure policy or the TRANSFORMSSECURE property.

Contact: 09742878183

Page 30

Below is the command-line for installing transforms with an msi.

Msiexec /I Product.msi TRANSFORMS=transform1.mst /qb+

To install multiple transforms,

Msiexec /I Product.msi TRANSFORMS=transform1.mst;transform2.mst;transfrom3.mst /qb+

2.24 - Upgrades

Upgrades will uninstall the older version of the product already present in the system and install
the newer version of the product to the system.

There are three types of upgrade possible with Windows Installer.

Small update
Minor Upgrade
Major Upgrade
A Small Update would be used to make very small changes that do not warrant a new version
number. Only the package code is changed. In practice, this should not be used because every
time a new version of an application is rolled out we want the precise version of this application to
be clearly visible. A small update does not clearly represent this version and is not recommended.
A Minor Upgrade is used to make small changes. For instance, you might upgrade a DLL to a
higher version or install a new file. With a minor upgrade the package code changes and the
version number, as defined by the ProductVersion property, is modified.
A Major Upgrade is used to make, wait for it, major changes to an installed MSI. With a major
upgrade you could add a new top-level feature and install many files. If you are rolling out a whole
new version of an application with lots of extra functionality it would be a major upgrade. With a
major upgrade the Product Code and Package Code change and the Product Version is
incremented.

In summary, a minor upgrade installs on top of an existing version and makes a few small
changes. A major upgrade uninstalls a previous version and replaces it with a new version. There

Contact: 09742878183

Page 31

are no limits on the changes which can be made with a Major Upgrade. A Small Update should
not be used because it does not modify the visible version of the installed application.

Type of update

PackageCode

ProductVersion

ProductCode

Small update

Changed

No Change

No Change

Minor upgrade

Changed

Changed

No Change

Major upgrade

Changed

Changed

Changed

2.24.1 - When to Choose Minor or Major Upgrade

The general rule is to create a Minor Upgrade for small changes and anything else would be a
major upgrade. To be more precise in the following scenarios a major upgrade would be required
and a minor upgrade would not work.

A new top-level feature is being added

A component code has been modified. A minor upgrade must never change the name of
a components key file because this would require the component code to change.
The name of the MSI file must not be modified. If you did do this you would see strange
network errors at installation time.
A component is removed from an existing feature.
2.24.2 - How to Apply a Minor Upgrade

A Minor Upgrade MSI can not be installed by double-clicking the MSI. The only way to install a
Minor Upgrade is by specifying the following command line:

msiexec /i myminorupgrade.msi REINSTALL="ALL" REINSTALLMODE=vomus

REINSTALL is a public property which specifies a list of features to be reinstalled. Setting this to
ALL means all features will be reinstalled. REINSTALLMODE is a public property which defines
which defines which resources will be reinstalled during the upgrade.

The major upgrade solution has two different upgrade possibilities.

Uninstall old version first and then install new version
The upgrade process performs the following actions:

Contact: 09742878183

Page 32

1. Detect and completely remove older products.

2. Install the new product.

This order is considered to be simpler because the upgrade process works out of the box. No
extra product customization is necessary in order for the upgrade process to be successful.
However it is inefficient because all reused files will be removed and then recopied. All changes
made to the installed resources will be lost.

Install new version first and then uninstall old version

The upgrade process performs the following actions:
1. Start installation of the new product
2. Check for matching components between products. Install the new components
from new product.
3. Uninstall the components that are not used by the new product.

This upgrade ordering is considered more efficient because the updated files are installed first
and then the old files are removed. Resources that are shared by both packages will not be
removed thus any change will be preserved.
2.24.3 - Patches

An application that has been installed using the Microsoft Windows Installer can be upgraded by
reinstalling an updated installation package (.msi file), or by applying a Windows Installer patch
(an .msp file) to the application.

Servicing applications by delivering a Windows Installer patch, rather than a complete installation
package for the updated product can have the following advantages:
A patch can contain an entire file or only the file bits necessary to update part of the file.
This can enable the user to download an upgrade patch that is much smaller than the
installation package for the entire product.
An update using a patch can preserve a user customization of the application through the
upgrade.

A Windows Installer patch (.msp file) is a self-contained package that contains the actual updates
to the application and describes which versions of the application can receive the patch.
Patches contain at minimum, two database transforms and can contain patch files that are stored
in the cabinet file stream of the patch package.

Contact: 09742878183

Page 33

For installing a patch, follow the command line as below

msiexec.exe /p samplepatch.msp REINSTALL=ALL REINSTALLMODE=omus

2.25 - Properties:

Properties are global variables that Windows Installer uses during an installation.

Windows Installer can configure software installation by using the values of variables defined in
an installation package or by the user.
Windows Installer uses three categories of global variables during an installation:
Private properties: The installer uses private properties internally and their values must be
authored into the installation database or set to values determined by the operating environment.

Private properties have at least one lowercase letter in their name and cannot be changed from
the user interface. For example, ProgramFilesFolder is a private property. End users have no
control over the values of private properties, as they cannot be set from the command line.

Example include Manufacture, ProductCode, ProductID, ProductName, ProductVersion etc

Public properties: Public properties can be authored into the database and changed by a user
or system administrator on the command line, by applying a transform, or by interacting with an
authored user interface.
Public properties have names that contain only uppercase letters. For example, INSTALLDIR is a
public property. Public properties can be specified at the command line used to launch the
installation or chosen by using an authored user interface. If you are creating your own
properties, use all uppercase letters if you want end users to have access to these properties.

Examples include INSTALLDIR, INSTALLLEVEL, ADDLOCAL etc

Contact: 09742878183

Page 34

Restricted public properties: For security purposes, the author of an installation package can
restrict the public properties a user can change. Only administrators can be able to change the
resticted public properties.
One can make a public property as a restricted public property by defining it in the
SecureCustomProperties property value delimited by semi-colons.

Examples include ALLUSERS, REBOOT, REINSTALLMODE etc

Not all properties need to be defined in every package; there is a small set of required properties
that must be defined in every package. The installer sets the values of properties in a particular
order of precedence.
Below are the mandatory properties that need to be defined inside every msi package.

1. ProductName
2. ProductLanguage
3. ProductVersion
4. ProductCode
5. Manufacturer
2.25.1 - Important properties used in Windows Installer

Public properties are differentiated from private properties by being listed in all capital letters.
Public properties may be set on the command line (or in a transform file.)

Below is the list of standard public properties you may set. Keep in mind that vendors may also
provide additional public properties specific to their applications.

Property

Description

TARGETDIR

Used as the location to copy the Installer

installation package during an administrative
installation.

ALLUSERS

Determines where configuration information will

be stored.

ARPCOMMENTS

Provides Comments for the Add/Remove

Control Panel.

Contact: 09742878183

Page 35

ARPCONTACT

Provides Contact for the Add/Remove Control

Panel.

ARPNOREPAIR

Disables the Repair button in the Programs

Wizard.

ARPPRODUCTICON

Specifies the primary icon for the installation

package.

ARPREADME

Provides ReadMe for the Add/Remove Control

Panel.

ARPSYSTEMCOMPONENT

Prevents display of application in Add/Remove

programs list.

ARPURLINFOABOUT

URL for application's home page.

ARPURLUPDATEINFO

URL for application updates information.

ARPNOMODIFY

Disables functionality that would modify the

product from the Add/Remove Control Panel.

ARPNOREMOVE

Disables functionality that would remove the

product from the Add/Remove Control Panel.

DISABLEADVTSHORTCUTS

Set to disable the generation of certain

shortcuts supporting installation-on-demand.

DISABLEMEDIA

Prevents the installer from registering media

sources, such as a CD-ROMs, as valid sources
for the product.

DISABLEROLLBACK

Disables rollback for the current configuration.

INSTALLLEVEL

Initial "level" at which features will be installed.

PROMPTROLLBACKCOST

Action if there is insufficient disk space for the

installation.

REBOOTPROMPT

Suppresses the display of prompts for reboots

to the user. Any reboots that are needed
happen automatically.

SHORTFILENAMES

Causes short file names to be used.

TRANSFORMS

List of transforms to be applied to the

database.

TRANSFORMSSECURE

Setting the TRANSFORMSECURE property to

1 informs the installer that transforms are to be
cached locally on the user's computer in a
location where the user does not have write
access.

Contact: 09742878183

Page 36

LIMITUI

UI level capped as Basic. If LIMITUI is set, the

ARPNOMODIFY property should be set as
well.

ADDLOCAL

List of features to be installed locally.

ADVERTISE

List of features to be advertised.

ADDDEFAULT

List of features to be installed in their default

configuration.

ADDSOURCE

List of features to be run from source.

REMOVE

List of features to be removed.

REINSTALL

List of features to be reinstalled.

REINSTALLMODE

A string containing letters that specify the type

of reinstall to perform.

COMPADDLOCAL

List of component IDs to be installed locally.

COMPADDSOURCE

List of component IDs to run from source

media.

FILEADDDEFAULT

Property List of file keys of files that are to be

installed in their default configuration.

FILEADDLOCAL

List of file keys of the files to be run locally.

FILEADDSOURCE

List of file keys to be run from the source

media.

NOUSERNAME

Suppresses the automatic setting of the

USERNAME property.

NOCOMPANYNAME

Suppresses the automatic setting of the

USERNAME property.

ARPHELPLINK

Internet address, or URL, for technical support.

ARPHELPTELEPHONE

Technical support phone numbers.

COMPANYNAME

Organization of user performing the installation.

PIDKEY

Part of the Product ID entered by user.

USERNAME

User performing the installation.

INSTALLLANGUAGE

Language used by Setup to configure

language-dependent user settings.

INSTALLLOCATION

Installation location.

SOURCELIST

Specifies a list of network server shares for the

Windows Installer to search if the primary
server is unavailable. Separate multiple server
shares with semi-colons.

Contact: 09742878183

Page 37

Some of the important public properties which are listed above are explained in detail below.
ALLUSERS
The ALLUSERS property determines where the configuration information of the installed
application is stored.
If ALLUSERS is not set, the installer does a per-user installation.
The following tables illustrate how the property affects the application installation when combined
with the access privileges of the user and the type of operating system.
Property

ALLUSERS is not set.

ALLUSERS=1

ALLUSERS=2

Not Valid returns error

Per-user installation

(ALLUSERS="") or
ALLUSERS=0
User access

Per-user installation

privileges

stating user not having

permission

Admin access

Per-user installation

Per-machine installation

privileges

Per-machine
installation

The command line is like

Msiexec /I Product.msi ALLUSERS=1 /qb+
REBOOT
The Reboot property is used to control the system reboot during or after the installation is
completed.
The REBOOT property suppresses certain prompts for a reboot of the system.
You can suppress certain prompts for reboots by setting the REBOOT property as follows.
REBOOT Value

Description

Force

Always prompt for a reboot at the end of the installation.

Suppress

Suppress prompts for a reboot at the end of the installation. The installer
still prompts the user with an option to reboot during the installation
whenever it encounters the ForceReboot action.

ReallySuppress

Suppress all reboots and reboot prompts initiated by ForceReboot during

the installation

The command line should look like

Msiexec /I Product.msi REBOOT=ReallySuppress /qb+

Contact: 09742878183

Page 38

REINSTALL
The value of the REINSTALL property is a list of features delimited by commas that are to be
reinstalled.
The features listed must be present in the Feature column of the Feature table. To reinstall all
features use REINSTALL=ALL on the command line.

For reinstalling selected features, use

Msiexec /I Product.msi REINSTALL=Feature1;Feature3 REINSTALLMODE=omus /qb+

For reinstalling all features, use

Msiexec /I Product.msi REINSTALL=ALL REINSTALLMODE=omus /qb+
REINSTALLMODE

The REINSTALLMODE property is a string that contains letters specifying the type of reinstall to
perform. Options are case-insensitive and order-independent. This property should normally
always be used in conjunction with the REINSTALL property.

By default the REINSTALLMODE is "omus".

p - Reinstall only if the file is missing.
o - Reinstall if the file is missing or is an older version.
e - Reinstall if the file is missing, or is an equal or older version.
d - Reinstall if the file is missing or a different version is present.
c - Verify the checksum values, and reinstall the file if they are missing or corrupt.
a - Force all files to be reinstalled, regardless of checksum or version.
u - Rewrite all required registry entries from the Registry Table that go to the HKCU
registry hive.
m - Rewrite all required registry entries from the Registry Table that go to the
HKLM or HKEY_CLASSES_ROOT registry hive.
s - Reinstall all shortcuts and re-cache all icons overwriting any existing shortcuts and
icons.
v - Use to run from the source package and re-cache the local package. Do not use the v
reinstall option code for the first installation of an application or feature.

Contact: 09742878183

Page 39

ADDLOCAL
The value of the ADDLOCAL property is a list of features delimited by commas that are to be
installed locally. The features must be present in the Feature column of the Feature table. To
install all features locally, use ADDLOCAL=ALL on the command line.
For Installing selected features, use
Msiexec /I Product.msi ADDLOCAL=Feature1;Feature4 /qb+

For installing all the features, use

Msiexec /I Product.msi ADDLOCAL=ALL /qb+
INSTALLLEVEL
The INSTALLLEVEL property is the initial level at which features are selected "ON" for installation
by default.
A feature is installed only if the value in the Level field of the Feature table is less than or equal to
the current INSTALLLEVEL value. The installation level for any installation is specified by the
INSTALLLEVEL property, and can be an integral from 1 to 32,767.
If no value is specified, the install level defaults to 1.
ROOTDRIVE
The ROOTDRIVE property specifies the default drive for the destination directory of the
installation. For example like C:\ or D:\

If ROOTDRIVE is not set at a command line or authored into the Property table, the installer sets
this property. During an administrative installation the installer sets ROOTDRIVE to the first
connected network drive it finds that can be written to. If it is not an administrative installation, or if
the installer can find no network drives, the installer sets ROOTDRIVE to the local drive that can
be written to having the more free space.

For example, use

Msiexec /I Product.msi ROOTDRIVE=C:\ /qb+

Contact: 09742878183

Page 40

2.26 - Application isolation

Application Isolation is the process which ensures that the packages that we create won't
interfere with each other by scanning them to determine if they are using only local resources and
DLLs. Isolating an application with its support files ensures that your application always uses the
version of shared files with which it was installed.
Why isolate an application?
Application isolation is one solution to component versioning conflicts, or DLL hell.
Isolation reduces versioning conflicts by modifying an application so it always loads the
versions of components such as DLLs with which it was originally developed and
tested.
Application isolation provides increased stability and reliability for applications because
they are unaffected by changes caused by installation and ongoing maintenance of other
applications on the system.
Resolve incompatibilities between different versions of shared components.
Reduce the complexity of the installation by storing COM activation data in a manifest
instead of the registry.
Insulate the application from changes to shared components.
The two application isolation techniques are
DLL/COM redirections, supported by Windows 2000 and later
WIN32 Assemblies, supported by Windows XP.
2.26.1 - DLL/COM Redirection (Local)

Windows XP and Windows 98 second edition support a feature called DLL/COM Redirection
(Sometimes just "DLL Redirection", or "Isolated components"), where an executable and its DLLs
can be installed to the same directory and Windows will use the copies of the DLLs in the
executable directory. To enable the DLL redirection, one creates a "Redirection file", which is an
empty (Zero-byte) file named after the application with extension "Local appended to it, in the
application directory for an executable called "sample.exe", the Redirection file would be named
"Sample.exe.local".
Windows Installer supports DLL/COM redirection using the isolated component table in MSI
database, along with the standard Isolate components action. Using MSI for DLL/ COM
redirection requires the executable and a library to isolate to be located in components inside the
same feature.

Contact: 09742878183

Page 41

2.26.2 - Win32 Assemblies (manifest)

In Addition to supporting DLL/COM Redirection, Windows XP supports a second type of isolation

using Win32 assemblies. A win32 assembly is an executable or DLL with a manifest file-a
formatted XML text file - describing the assembly's dependencies.

The main advantage of using Win 32 assemblies is that can be installed without writing COM data
to the registry, ideally making the application and its libraries completely self-contained.
The two types of manifests used in Win32 assemblies are Application manifests and Assembly
manifests.

An application manifest contains an application's name and version information, and the names
and COM information for its dependent libraries (An application manifest file should be named
AppName.exe.manifest).

The other type of manifest, an assembly, is a manifest for a DLL or OCX file, containing the
library's file name, version, and COM information. Every manifest contains an assembly identity.
An assembly identity is a name of the form OrganizationName.DivisionName.AssemblyName.

Unlike application manifest, which are named after an executable, assembly manifests are
named after the assembly identity with the extension ".manifest" appended, as in:
OurCompany.AppMigration.AssemblyName1.manifest
2.26.3 - Steps to describe how to implement isolation using WPS:

1. Invoke the Application Isolation wizard from the side pane of Wise package studio
2. Browse the .WSI or .MSI file on which the isolation has to be performed.
3. Choose on the isolation method and the isolation type. The next screens depend on the
options selected here.
4. Choose how the process of isolation has to be taken place.
5. Isolation is ready to be performed.
6. The updated Windows Installer file can be either the default MSI file appended with
_isolated or a new MSI file or a MST file.

Contact: 09742878183

Page 42

2.27 - Merge Modules

Merge modules provide a standard method by which developers deliver shared Windows
Installer components and setup logic to their applications.

Merge modules are used to deliver shared code, files, resources, registry entries, and setup logic
to applications as a single compound file.
A merge module is similar in structure to a simplified Windows Installer .msi file. However, a
merge module cannot be installed alone; it must be merged into an installation package
using a merge tool such as Mergemod.dll.

When a merge module is merged into the .msi file of an application, all the information and
resources required to install the components delivered by the merge module are incorporated into
the application's .msi file. The merge module is then no longer required to install these
components and the merge module does not need to be accessible to a user.
Because all the information needed to install the components is delivered as a single file, the use
of merge modules can eliminate many instances of version conflicts, missing registry
entries, and improperly installed files.
A standard merge module has an .msm file name extension. All the Microsoft Visual Studio
merge modules will be present under the folder C:\Program Files\Common Files\Merge
Modules.

A merge module cannot be installed alone because its lacks some vital database tables
that are present in an installation database. Merge modules also contain additional tables that
are unique to themselves.
To install the information delivered by a merge module with an application, the module must first
be merged into the application's .msi file.

A merge module consists of the following parts:

A Merge Module Database containing the installation properties and setup logic being
delivered by the merge module.
A Merge Module Summary Information Stream Reference describing the module.
A MergeModule.CABinet cabinet file stored as a stream inside the merge module. This
cabinet contains all the files required by the components delivered by the merge module.

Contact: 09742878183

Page 43

2.28 - Internal Consistency Evaluators (ICE) Validation

Internal Consistency Evaluators (ICE) is a set of rules created by Microsoft to help validate
a Windows Installer package.
ICE rules check the integrity of the package as well as ensure that the Windows Installer best
practices were followed when creating an MSI package. It is strongly recommended that authors
run validation on every new or newly modified installation package before attempting to install the
package for the first time.
ICE Rules are stored in files with .cub extension. For example, darice.cub, shipped by
Microsoft, contains all the standard ICE rules that can be run on your package. A .cub file is
nothing but a database, just like your MSI package and can be edited in Orca.
ICE rules behind the scenes are basically Custom Actions that are run on the MSI package
during the ICE Validation process. You can create your own Custom ICE rules to suit your
organization's needs.

You can ICE validate your MSI package with pretty much any tool that allows you to create an
MSI package e.g. InstallShield, Wise Package Studio or even Orca. Till now Microsoft has
released about 99+ ICE Errors/Warnings.
Most Common ICEs found in repackaged applications are given below
ICE09 - Validates that any component destined for the System folder is marked as being
permanent.
ICE24 - Validates that the product code, product version, and product language have appropriate
formats.
ICE27 - Validates the organization and order of the sequence tables.

ICE33 - This ICE is caused by the fact that repackager adds COM related information into the
registry table as supposed to the Microsoft recommended Class ID, Prog ID and Type Lib tables.
This Error can safely be ignored as the application should work properly as your COM information
will be registered via the Registry table.

Contact: 09742878183

Page 44

ICE64 - This ICE warns about directories created under the User Profile folder not being specified
in the RemoveFile table. So, for example, if your MSI package contains [AppDataFolder]mydir or
[PersonalFolder]mysubfolder, ensure that 'mydir' & 'mysubfolder' are specified in the RemoveFile
table. Doing so will ensure that they get removed at un-installation time.
ICE57 - If you have a component in your MSI package that contains both per-user & per-machine
data. For example, if the component is installing a file to [AppDataFolder] and also contains a
registry key being installed under HKLM you can expect to see this Error/Warning. The ideal thing
to do is separate User data from machine data into separate components.
ICE50 - This ICE usually occurs when your installation tool is unable to extract icon from the Icon
file specified in the shortcut. The best way to work around it is to specify an Exe or different icon
file in the shortcut to extract the icon from.

2.29 - Summary Information Stream

The summary information stream is used by the installer for two purposes.
First, it contains information about the package that can be viewed through
Microsoft Windows Explorer. This information is accessible through the IStream
interface. It is up to the author to provide the values for each of these properties.
Second, it contains properties that are used by the installer to install the package.

The following list shows the some of the summary information stream properties for Windows
Installer:
Author Summary Property
Codepage Summary Property
Comments Summary Property
Create Time/Date Summary Property
Creating Application Summary Property
Keywords Summary Property
Last Saved Time/Date Summary Property
Revision Number Summary Property
Subject Summary Property
Template Summary Property
Title Summary Property

Contact: 09742878183

Page 45

2.30 - Standard Actions

An action encapsulates a typical function performed during the installation or maintenance of an
application. Windows Installer has many built-in standard actions that are used in the sequence
tables.
Examples of installer standard actions include CreateShortCuts Action, InstallFiles Action and
WriteRegistryValues Action.

The order of action execution is determined by the sequence of actions that have been authored
into the sequence tables and by the order in which the installer runs the sequence tables.
When the installer runs a sequence table, it executes actions in the order of the sequence
numbers listed in the Sequence column.
The action order is always linear with no branching or looping. Package developers can
conditionally prevent a particular action from being executed by authoring a logical expression
into the Condition column. The installer skips the action whenever the condition evaluates to
False.
If the installer is passed the INSTALL/ADVERTISE/ADMIN action and the installation package
has been executed with a user interface, the installer first runs the actions in
InstallUISequence/AdvtUISequence/AdminUISequence table and then executes the actions in
the InstallExecuteSequence/AdvtExecuteSequence/AdminExecuteSequence table in order.

If the package has no user interface, the installer executes the actions in the
InstallExecuteSequence/AdvtExecuteSequence/AdminExecuteSequence table in order.

All sequence tables have the following columns.

Column

Description

Action

The primary key for the table; the action name must be unique.

Condition

A Boolean expression used to determine whether to perform the action. The

action is executed if this field is either blank or contains an expression that
evaluates to True. The action is not executed if the expression evaluates to
False.

Sequence

A relative sequence number used to determine the order in which actions are
executed.

Contact: 09742878183

Page 46

Below are some of the important actions that the windows installer will execute.

ADMIN Action
The ADMIN action is a top-level action used to perform administrative installations.
ADVERTISE Action
The ADVERTISE action is a top-level action called to install or remove advertised components.

AppSearch Action
AppSeacrh action is used to check the existence of any required software is already present in
the machine. It is used to check for any existing files, folders and registry keys which in turn
check the existence of required software.
CostInitialize Action
The CostInitialize action initiates the installation costing process. Any standard or custom actions
that affect costing should be sequenced before the CostInitialize action.

CostFinalize Action
The CostFinalize action ends the internal installation costing process begun by the CostInitialize
action
CreateFolders Action
The CreateFolders action creates empty folders for components that are set to be installed. The
installer creates folders both for components that run locally and run from source.

CreateShortCuts and RemoveShortcuts Action

The CreateShortCuts action manages the creation of shortcuts during installation and
RemoveShortcuts action removes the shortcuts during uninstallation.

DeleteServices Action
The DeleteServices action stops a service and removes its registration from the system. This
action queries the ServiceControl table

DisableRollback Action
The DisableRollback Action disables rollback for the remainder of the installation

Contact: 09742878183

Page 47

FileCost Action
The FileCost action initiates dynamic costing of standard installation actions.

FindRelatedProducts Action
This action is used to find the existence of already installed previous versions of the product by
using the upgrade code. The FindRelatedProducts action runs through each record of the
Upgrade table in sequence and compares the upgrade code, product version, and language in
each row to products installed on the system. If it founds the matching entry, it will upgrade the
installation

INSTALL Action
The INSTALL action is a top-level action called to install or remove components.
InstallFiles Action
The InstallFiles action copies files specified in the File table from the source directory to the
destination directory.

InstallInitialize Action
The InstallInitialize action and InstallFinalize action mark the beginning and end of a sequence of
actions that change the system.
InstallFinalize Action
The InstallFinalize action runs a script that contains all operations spooled since either the start of
the installation or the execution of the InstallExecute or InstallExecuteAgain actions. This action
marks the end of a transaction that begins with the InstallInitialize action.

InstallServices Action
The InstallServices action registers a service for the system. This action queries the ServiceInstall
table.

InstallValidate Action
The InstallValidate action verifies that all volumes to which cost has been attributed have
sufficient space for the installation. The InstallValidate action ends the installation with a fatal
error if any volume is short of disk space.

Contact: 09742878183

Page 48

LaunchConditions Action
The LaunchConditions action queries the LaunchCondition table and evaluates each conditional
statement recorded there. If any of these conditional statements fail, an error message is
displayed to the user and the installation is terminated.
RegisterProduct Action
The RegisterProduct action registers the product information with the installer. Additionally, this
action stores the installer database on the local computer.

RemoveExistingProducts Action
This action will remove the any earlier versions of the product installed while upgrading the
product.
RemoveFiles Action
The RemoveFiles action removes files previously installed by the InstallFiles action.

RemoveFolders Action
The RemoveFolders action removes any folders linked to components set to be removed or run
from source. These folders are removed only if they are empty.
RemoveRegistryValues and WriteRegistryValues Action
Used to delete the registry keys while uninstallation and create the registry values during the
installation of the product.

ResolveSource Action
The ResolveSource action determines the location of the source and sets the SourceDir property
if the source has not been resolved yet.
StartServices/StopServices Action
These actions are used to start and stop the services during installation and uninstallation.

WriteEnvironmentStrings/RemoveEnvironmentStrings Action
These actions will create and delete the environment variables values during the installation and
uninstallation of the product.

Contact: 09742878183

Page 49

2.31 - Custom Actions

Custom actions play a very prominent role in getting the Developer's task done easily. The
Microsoft Windows Installer provides many built-in custom actions for performing the installation
process. The standard actions can also be defined as a part of the packaging template. Standard
actions are sufficient to execute an installation in most cases.
However, there are situations where the developer of an installation package finds it necessary to
write a custom action. The Custom Actions are the actions entirely defined by the users i.e. the
developer writes an action to execute his own installation. This is basically written to achieve few
tasks which are not possible through the MSI.
2.31.1 - Types of Custom Actions (CA)
Executable files (.exe)
Calling an exe file from the Destination computer
Calling an exe from Installation (stored in the Binary table)
Calling an exe file from the Installed files (installed by the Application)
Calling an exe file whose path is stored in a property

Example Scenario:
This CA is written to launch an executable during installation that is installed on the user's
machine or that is being installed with the application. This type of CA can be used when we have
a pre-defined exe to be run for our desired result.
Best example would be to write a CA which gives permissions to registry keys using "setacl.exe".
Calling a system exe "RefreshPolicies" which would refresh the user permissions and policies
after the installation is complete. (This CA will be used only when we set permission to registry or
file for the user.)
Dynamic linked libraries (.dll)
Calling a Custom dll file from the Destination computer
Calling a Custom dll from Installation (stored in the Binary table)
Calling a Custom dll file from the Installed files (installed by the Application)
Calling an dll from the Installation (stored in the Binary table)
Calling an dll file from the Installed files (installed by the Application)

Example Scenario: To call special functions during an installation those are defined in a dynamiclink library (DLL). This type of CA can be used when we have a system dll or an application dll to
be invoked for our desired result.

Contact: 09742878183

Page 50

Best example: In driver packages, where we need to customize the package in such a way that it
should check for the max XX value that is present in the machine and install the PNF or INF file. If
the file oem14.INF is the max XX value that is present in the machine, while installing the
package it should install the INF as oem15.INF resulting in the unique name for the INF file for
that machine. For this purpose we write a custom action using setupapi.dll.
Visual Basic Script files
Calling a VBScript from Embedded code (stored in the custom action table)
Calling a VBScript file from the Installation (stored in the binary table)
Calling a VBScript file from the Installed files (installed by the Application)
Calling a VBScript file whose path is stored in the property
Java Script files
Calling a JScript from Embedded code (stored in the custom action table)
Calling a JScript from the Installation (stored in the binary table)
Calling a JScript file from the Installed files (installed by the Application)
Calling a JScript file whose path is stored in the property
Wise Script files
Run WiseScript from the Destination computer
Run WiseScript from the Installation (stored in the binary table)
Run WiseScript from the Installed files (installed by the Application)

Example Scenario: This type of CA is written to Use functions written in the development
languages Microsoft Visual Basic Scripting Edition, Wise Script or Microsoft JScript literal script
text during an installation. This type of CA can be used by writing a script as an embedded code
or as a script file which would reside in the source directory.
Best example: Handling excel addins, deleting a run time folder which remains back after uninstallation., creating a folder in network share etc.
2.31.2 - Using CA in MSI Package
Steps for creating a Custom Action:
Select the Custom Action type in the MSI Script tab
Select the Sequence in the location tab
Apply the Condition in the location tab
Select the Scripting Options in the properties tab
Select the Processing Options in the properties tab

Contact: 09742878183

Page 51

Select the Scheduling Options in the properties tab

Sequences:
Normal User Interface - execute the custom action only when the application Installs in
the user interface

Normal Execute Immediate/Deferred - execute the custom action only when the
application Installs in the silent mode

Administrative User Interface - execute the custom action only when the application
Installs in "/A" mode with the user interface

Administrative Execute Immediate/Deferred - execute the custom action only when

the application installs in "/A" with silent mode

Advertisement Execute Immediate/Deferred - execute the custom action only when

the application installs in "/ju or /jm" mode.
Conditions:
Action run only during Install
Condition: NOT Installed AND NOT PATCH
Action only runs during removal of MSI
Condition: REMOVE
Action runs during Install and repair
Condition: NOT REMOVE
Action runs during Install and remove
Condition: There must be no condition
Action calls EXE installed by MSI
Condition: NOT Installed AND NOT PATCH
Run on initial installation only:
NOT Installed
Run on initial install or when repair is selected.
NOT Installed OR MaintenanceMode="Modify"
Run when being uninstalled from command line or add / remove menu.
REMOVE~="All" OR MaintenanceMode="Remove"

Contact: 09742878183

Page 52

Scripting options
Immediate Execution
Immediate custom actions, can be sequenced anywhere within any of the sequence
tables. It has access to the installation database (read & set installation properties,
modify feature & component states, add temporary columns, rows, and tables).

Deferred Execution - User Context

Deferred custom actions can only be sequenced between the InstallInitialize and
InstallFinalize actions in execute sequence tables. It doesn't have access to the
installation database. Deferred custom actions are not executed immediately. Instead
they are scheduled to run later during the execution script. The execution script isn't
processed until the InstallExecute, InstallExecuteAgain, or InstallFinalize action is run.

If the Current User doesn't have the elevated privileges (Permission to make changes in
the system directly), the custom actions should run in Deferred Execution in User Context
only.

Rollback only
This Action should be executed during the Installation of the Rollback script or if the
Installation is Unsuccessful

Commit only
This Action should be executed during the Installation of the Commit script.

Deferred Execution - System Context

Deferred custom actions can only be sequenced between the InstallInitialize and
InstallFinalize actions in execute sequence tables. It doesn't have access to the
installation database. Deferred custom actions are not executed immediately. Instead
they are scheduled to run later during the execution script. The execution script isn't
processed until the InstallExecute, InstallExecuteAgain, or InstallFinalize action is run.

If the Current User has the elevated privileges (Permission to make changes in the
system directly), then it should run in Deferred Execution in System Context only.

Contact: 09742878183

Page 53

Processing Options
Synchronous
Windows Installer runs the custom action synchronously to the main installation. It waits
for the custom action to complete successfully before continuing the main installation.

Synchronous, ignore exit code

Windows Installer runs the custom action synchronously to the main installation. It waits
for the custom action to complete before continuing the main installation; the action can
be either success or fail.

Asynchronous, wait at end of sequence

Windows Installer runs the custom action simultaneously with the main installation. At the
end it waits for the exit code from the custom action before continuing.

Asynchronous, no wait
Windows Installer runs the custom action simultaneously with the main installation. It
doesn't wait for completion of the custom action and doesn't check the exit code also.
Scheduling Options
Always Execute: This action execute in all sequences
Run first time: This action execute only the first time Windows Installer encounters it.
Run once per process: This action execute only one time either Execute sequence that
should not run if the installation is running in silent mode.
Run only if UI sequence was run: This action execute only if either Execute sequence
is run following User Interface sequence.
2.31.3 - Difference Between "Immediate Execute / Deferred Execute

Immediate
Custom actions, can be sequenced anywhere within any of the sequence tables
Custom actions have access to the Installation database
Custom actions can only run in the User Context
Custom actions should never modify the system state i.e. should not run in elevated
context
Deferred
Custom actions can be sequenced only between the InstallInitialize and InstallFinalize
actions in the sequence tables

Contact: 09742878183

Page 54

Custom actions doesn't have access to the Installation database

Custom actions can run both in the context of the user and elevated using the system
context.
Custom actions can modify the system state i.e. can be run in elevated context
2.31.4 - Difference Between "Deferred in System Context / Deferred in User Context"

User Context: Custom action which installs or modifies a file under the INSTALLDIR

System Context: Custom action which installs or modifies the file under INSTALLDIR or System
folder directly.
2.32 - Registry
The Windows Registry is a hierarchical database that stores configuration settings and options on
Microsoft Windows operating systems. It contains settings for low-level operating system
components as well as the applications running on the platform: the kernel, device drivers,
services, SAM, user interface and third party applications all make use of the registry.

To open the registry, click the Start

Run

type regedit

Structure
Root Keys
Sub keys
Hives
Entries
Types
Machine-Specific (HKCR, HKLM, HKCC, HKU)
User-Specific (HKCU, HKU)
Root Keys
HKEY_CLASS_ROOT (HKCR)
HKEY_LOCAL_MACHINE (HKLM)
HKEY_CURRENT_CONFIG (HKCC)
HKEY_CURRENT_USER (HKCU)
HKEY_USERS (HKU)
Folder/predefined key

Description

HKEY_CURRENT_USER

Contains the root of the configuration information for the user who
is currently logged on. The user's folders, screen colors, and
Control Panel settings are stored here. This information is
associated with the user's profile. This key is sometimes
abbreviated as "HKCU."

Contact: 09742878183

Page 55

HKEY_USERS

Contains all the actively loaded user profiles on the computer.

HKEY_CURRENT_USER is a sub-key of HKEY_USERS.
HKEY_USERS is sometimes abbreviated as "HKU."

HKEY_LOCAL_MACHINE

Contains configuration information particular to the computer (for

any user). This key is sometimes abbreviated as "HKLM."

HKEY_CLASSES_ROOT

Is a sub-key of HKEY_LOCAL_MACHINE\Software. The

information that is stored here makes sure that the correct program
opens when you open a file by using Windows Explorer. This key
is sometimes abbreviated as "HKCR."

HKEY_CURRENT_CONFIG Contains information about the hardware profile that is used by the
local computer at system startup.

2.33 - Shortcuts
Shortcuts are the entry points to the applications installed on the system which is normally points
to a file. Those are links to files or applications installed on the target system
-

Advertised (Windows Installer) Shortcuts

Non-advertised (Standard) Shortcuts

It is important to know the differences between the two.

A non-advertised shortcut (Standard Shortcuts) is a standard windows shortcut. If you rightclick it you will see the target field points to the executable that will be launched. If, for whatever
reason, this executable is missing the application will simply fail.
An advertised shortcut (Windows Installer Shortcuts) is a technology specific to Windows
Installer. If you right-click an advertised shortcut the target field will be grayed out. An advertised
shortcut supports advertisement and repair.
Repair means that if the executable to which the shortcut is pointing is not there then windows
installer will repair the application and replace the missing file.
Advertisement types
Advertisement is the process of the creating an entry point to the user without installing the actual
application. Once we launch the entry point then the actual application will install and launch the
shortcut which is called Installation on Demand
Types
Publishing
No Entry points appear to a user or others, when an Application published to the group. It is
activated only if the group Application activates the published Application i.e. Installation on

Contact: 09742878183

Page 56

Demand. Or simply it is a normal advertisement which will simply installs the entry point without
installation of the application and when the user launches the entry point then actual application
will installs and launches the shortcut.
Assigning
An Application appears (shortcuts, files & registries) to a user or others, when an Application is
assigned. When the user tries to open, it is installed upon demand. Or simply we can define
that the entry point will show in add and remove programs and when the user trigger the entry
point then the application will install.
Note: If a Feature or Component is advertised, only the interfaces required for loading and
launching the application are installed to the user or others. If a user activates an advertised
interface the installer then proceeds to install the necessary Components & Features.

2.34 - INI Files

INI files are plain-text files that contain configuration information.
"INI" stands for initialization. The INI file format is a de facto standard for configuration files. INI
files are simple text files with a basic structure. They are commonly associated with Microsoft
Windows, but are also used on other platforms.
The format of the INI file will be
[Section]
Name = Value
Properties
The basic element contained in an INI file is the property. Every property has a name and a
value, delimited by an equals sign (=). The name appears to the left of the equals sign.
Name = Value
Sections
Properties may be grouped into arbitrarily named sections. The section name appears on a line
by itself, in square brackets ([ and ]). All properties after the section declaration are associated
with that section.

[Section]

2.35 - Services
A windows service is a background process which is loaded by the Service Control Manager of
the OS.

Contact: 09742878183

Page 57

Win32 Service - Win32 services are the services which are running by the executable
file installed by the Application.
System or Kernel Services - Kernel services are the services which are used by the OS
to communicate to the hardware devices.
Most of the Service information is stored under
HKLM\System\CurrentControlSet\<Name of the Service>

the

windows

registry

key

In windows installer database, the below mentioned two tables will handle the services
ServiceInstall Used to install service and contain the service details
ServiceControl - Controlling the service during Installation & Uninstallation

2.36 - ODBC
ODBC is an abbreviation for Open Database Connectivity. It is a protocol access method to
databases developed by Microsoft. Open Database Connectivity (ODBC) is a standard
application programming interface (API) that allows a program to access data in any ODBCcompliant relational database language.

Purpose of ODBC
It is to allow the user to access data from any application regardless of which Database
Management System (DBMS) being used. It achieves this by creating a middle layer between the
application and the DBMS. This layer is known as the Driver.

The ODBC architecture has four components:

Application - (Spreadsheet, Word processor, Data Access & Retrievable Tool, Development
Language etc.) Performs processing by passing SQL Statements to and receiving results from
the ODBC Driver Manager.

Driver Manager - a Dynamic Link Library that Loads drivers on behalf of an application.

Driver - a Dynamic Link Library that Processes ODBC function calls received from the Driver
Manager, submitting the resultant SQL requests to a specific data source, and returns results to
the application. If necessary, the driver modifies an application's request so that the request
conforms to syntax supported by the associated DBMS.

Contact: 09742878183

Page 58

Data Source - Consists of a DBMS, the operating system the DBMS runs on, and the network (if
any) used to access the DBMS.
A database server can have any number of operating databases. A Unique Data Source Name
(DSN) must be given to the data source to specify which database to use.
The Data Source allows the user to select between three connections, User, System and File
DSN's.
User DSN's are used for the connection of an individual user to a data source. This connection is
very secure, but is not a good solution if distributed access is required. The DSN will only be
visible to the specific user when he or she is logged on. User DSN connection information is
stored in the HKEY_CURRENT_USER_ Registry key
Systems DSN's are good solutions when a single computer is expected to access the database.
They are independent of who is logged onto the console. The connection information for a
System DSN is stored in the HKLM Registry. The major drawback in using System DSN
connections is that the connections are dependent on the machine on which they have been set
up
File DSN is located on the network and does not reside on any particular machine. File DSNs are
available to all users who have the same drivers installed. In this way, multiple computers can
use a single File DSN to access a Web server.
In case you are adding ODBC through Registry Entries, add/Import appropriate registry entries
as per your application under following hive
Per Machine: HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\
Per User: HKEY_CURRENT_USER\SOFTWARE\ODBC\

2.37 - File associations

A file association associates a file with an application capable of opening that file. More
commonly, a file association associates a class of files (usually determined by their filename
extension, such as .txt) with a corresponding application (such as a text editor).

A single file extension may have several associations for performing various actions, also known
as verbs.
Some of the common verbs are:

Contact: 09742878183

Page 59

open to open a file

edit to open a file for editing

print to print a file

E.g., .doc, .xls, .pdf

2.38 - Environment Variables
Environment variables are strings that contain information about the environment for the system,
and the currently logged on user. Some software programs use the information to determine
where to place files (such as temporary files). During installation, Windows XP Setup configures
the default system variables, such as the path to the Windows files.
There are two types of variables
-

System Variables

User Variables

System Variables - You must be an administrator to modify a system environment variable.

System environment variables are defined by Windows and apply to all computer users. Changes
to the system environment are written to the registry, and usually require a restart to become
effective.

User Variables - Any user can add, modify, or remove a user environment variable. These
variables are established by Windows XP Setup, by some programs, and by users. The changes
are written to the registry, and are usually effective immediately. However, after a change to user
environment variables is made, any open software programs should be restarted to force them to
read the new registry values.

To view or change environment variables,

Right-click My Computer

Click Properties

Click the Advanced tab

Click Environment

variables.
-

Click one the following options, for either a user or a system variable:

Click New to add a new variable name and value.

Click an existing variable, and then click Edit to change its name or value.

Click an existing variable, and then click Delete to remove it.

Contact: 09742878183

Page 60

2.39 - Dll Cache folder

During the process of SFC (System File Checker) or WFP (Windows File Protection), it will scan
all the protected files (.SYS, .DLL, .EXE, .TTF, .FON, and .OCX extensions) to verify their
versions. If the versions are not correct, it will replace the particular files from the back up folder
called DLL Cache folder which is C:\WINDOWS\system32\dllcache.

2.40 - System File Checker (SFC)

SFC means "System File Checker." It is a command-line utility that scans the operating system's
files to ensure that they are the correct ones (original Microsoft files). But it can be run or
scheduled manually only.
During the process, it will scan all the protected files (.SYS, .DLL, .EXE, .TTF, .FON, and .OCX)
to verify their versions. If the versions are not correct, it will replace the particular files from the
back up folder called DLL Cache folder

2.41 - Windows File Protection (WFP)

WFP is also a utility tool which will run automatically.

Some applications will replace the system files (SYS, .DLL, .EXE, .TTF, .FON, and .OCX) with
different files of the same name or with same file with different versions.
If the files are in a protected folder, then Windows File Protection automatically determines which
file was affected, and looks up the file signature in a catalogue file to see if the file is the correct
Microsoft version, and if it is digitally signed.
If it is not, then the correct file will be copied over it from either the winnt\system32\dllcache
folder, or from the Windows CD.

2.42 - Files, folders and registries are not getting remove after uninstall

Files not removed

There are four common reasons for why files may not be removed during Uninstallation
The components to which these files belong are marked as permanent. (This is done
through the Attributes column of the Component table.)

Contact: 09742878183

Page 61

None of the components to which these files belong have component GUIDs. (The value
for the component in the ComponentId column of the Component table is NULL).
Components without GUIDs are not managed by Windows Installer.
If the KeyPath of the component has a shared DLL reference count, then the component
will not be uninstalled.
If the component is installed in the system folder and at the time of Uninstallation there is
an external shared DLL reference count for any one file in the component, then the
component will not be uninstalled.
Folders not removed
The reasons could be
The RemoveFolders action is missing from the execute sequence table when both the
CreateFolder table and CreateFolders action are used.
The folders were not created by Windows Installer; therefore it will not remove them
unless told to do so.
Resources still exist in the folder.
Registries not removed
Most common causes for leaving behind registry keys during Uninstallation are
The Registry table contains entries marked with the '+' sign. This directs the installer to
leave behind those registry keys during uninstallation.
In the InstallExecuteSequence table, the RemoveRegistryValues action is sequenced
after the UnregisterProgIdInfo and UnregisterMIMEInfo actions. The sequence of these
actions needs to be reversed. The presence of some registry values written from the
Registry table prevents certain ProgId, extension, and CLSID keys from being removed.

2.43 Windows Installer Tables

Database Tables
The following table identifies the Windows Installer database tables.
Table
ActionText
AdminExecuteSequence
AdminUISequence
AdvtExecuteSequence
AdvtUISequence

Contact: 09742878183

Description
Lists text in a progress dialog box or action log.
Lists ADMIN actions in sequence.
Lists UI ADMIN actions in sequence.
Lists ADVERTISE actions in sequence.
The Windows Installer does not use this table. The AdvtUISequence

Page 62

AppId
AppSearch
BBControl
Billboard
Binary
BindImage
CCPSearch
CheckBox
Class
ComboBox
CompLocator
Complus
Component
Condition
Control
ControlCondition
ControlEvent
CreateFolder
CustomAction
Dialog
Directory
DrLocator
DuplicateFile
Environment
Error
EventMapping
Extension
Feature
FeatureComponents
File
FileSFPCatalog
Font
Icon
IniFile
IniLocator
InstallExecuteSequence
InstallUISequence
IsolatedComponent
LaunchCondition
ListBox
ListView
LockPermissions

Contact: 09742878183

table should not exist in the installation database or it should be left

empty.
Specifies that the installer configure and register DCOM servers
Lists properties used to search by file signature.
Lists controls displayed on each billboard.
Lists billboards displayed in full UI.
Holds binary data for bitmaps and icons.
Lists executables bound to the DLLs.
Lists file signatures for the Compliance Checking Program.
Lists the values for the check boxes.
Lists COM server information for product advertisement.
Lists the values for each combo box.
Find file or directory by installer configuration data.
Contains information needed to install COM+ applications.
Lists installation components.
Modifies feature selection states conditionally.
Lists the controls on each dialog box.
Lists actions applied to controls based on a property.
Specifies the actions of controls in dialog boxes.
Lists folders that must be created for a component.
Integrates custom actions into the installation.
Lists dialog boxes in the user interface.
Directory layout for the application.
Lists file searches using the directory tree.
Lists files to be duplicated.
Lists the environment variables.
Lists error message formatting templates.
Lists the events subscribed to by controls.
Lists file extension server information.
Defines the logical tree structure of features.
Defines features and component relationships.
Complete list of source files with their attributes.
Associates specified files with the catalog files.
Registry information for font files.
Contains the icon files.
Information needed to set in an .ini file.
Searches for file or directory using an .ini file.
Lists INSTALL actions in sequence.
Lists UI INSTALL actions in sequence.
Lists Isolated Components.
Lists conditions for the installation to begin.
Lists the values for all list boxes.
Lists the values for all listviews.
Defines locked-down portions of the application.

Page 63

Media
MIME
MoveFile

Lists source media disks for the installation.

Lists MIME content type, file extension, or CLSID.
Lists files to be moved or copied.
Specifies Windows Installer settings for Microsoft .NET Framework
MsiAssembly
assemblies and Win32 assemblies.
Specifies the schema for the elements of a strong assembly cache
MsiAssemblyName
name for a .NET Framework or Win32 assembly.
Stores certificates in binary stream format and associates each
MsiDigitalCertificate
certificate with a primary key.
Contains the signature information for every digitally-signed object
MsiDigitalSignature
in the installation database.
Each row in this table references a different user-defined function
that can be used to install multiple Windows Installer packages from
MsiEmbeddedChainer
a single package.
Windows Installer 4.0 and earlier: Not supported.
Defines a user interface embedded in the Windows Installer
MsiEmbeddedUI
package.
Windows Installer 4.0 and earlier: Not supported.
Stores a 128-bit hash of source files provided by the Windows
MsiFileHash
Installer package.
Lists digital signature certificates being used to verify the identity of
MsiPackageCertificate
installation packages that make this Multiple-Package Installation.
Available beginning with Windows Installer 4.5.
Contains the information needed to enable User Account Control
MsiPatchCertificate
(UAC) Patching. Available beginning with Windows Installer 3.0.
MsiPatchHeaders
Holds the binary patch header streams used for patch validation.
Holds information about a Windows Installer patch required to
MsiPatchMetadata
remove the patch and used by Add/Remove Programs. Available
beginning with Windows Installer 3.0.
MsiPatchOldAssemblyName Specifies the old name for an assembly.
MsiPatchOldAssemblyFile Relates a file in the File Table to an assembly name.
Contains the information required to determine the sequence of
MsiPatchSequence
application of a small update patch relative to all other patches.
Available beginning with Windows Installer 3.0.
Lists files that should bypass Windows File Protection on
MsiSFCBypass
Windows Me.
ODBCAttribute
Lists attributes of ODBC drivers and translators.
ODBCDataSource
Lists data sources belonging to the installation.
ODBCDriver
Lists ODBC drivers belonging to the installation.
ODBCSourceAttribute
Lists the attributes of data sources.
ODBCTranslator
Lists ODBC translators of the installation.
Patch
Lists files that are to receive a particular patch.
PatchPackage
Lists all patch packages applied to this product.
ProgId
Lists information for program IDs.
Property
Lists property names and values for all properties.
PublishComponent
Lists information used for component publishing.
RadioButton
Lists buttons for all the radio button groups.
Registry
Lists registry information for the application.

Contact: 09742878183

Page 64

RegLocator
RemoveFile
RemoveIniFile
RemoveRegistry
ReserveCost
SelfReg
ServiceControl
ServiceInstall
SFPCatalog
Shortcut
Signature
TextStyle
TypeLib
UIText
Verb
_Validation
_Columns
_Streams
_Storages
_Tables
_TransformView Table
Upgrade

Contact: 09742878183

Searches for file or directory using the registry.

Lists files to be removed by RemoveFiles action.
Lists information needed to delete from an .ini file.
Lists information needed to delete from system registry.
Reserves disk space in any directory conditionally.
Lists information about self-registered modules.
Controls installed or uninstalled services.
Lists information used to install a service.
Lists SFP catalogs.
Lists information needed to create shortcuts.
Lists the unique file signatures that identify files.
Lists text styles used in the text controls.
Lists registry information for type libraries.
Lists localized versions of some strings used in the user interface.
Lists command-verb information for file extensions.
Lists column names and values for all tables.
Read-only column catalog.
Lists embedded OLE data streams.
Lists embedded OLE sub-storages.
Read-only system table listing all the tables.
A read-only temporary table used to view transforms.
Lists information used in an upgrade of an application.

Page 65

3.1 - Wise Setup Capture

SetupCapture is the process which monitors the changes that occur to your system as a setup
installation program is run. The SetupCapture wizard takes a before install and after install
snapshot of the workstation then creates a package based on the differences between the before
and after snapshots.
The SetupCapture Wizard will walk you through the steps necessary to begin the scanning and
installation process. Since SetupCapture monitors any changes made during an installation, it's
very important to start with a 'clean' machine. This will ensure that unnecessary changes are not
captured in the .MSI package

SetupCapture records an installation by using various capture methods:

Virtual Capture:
Virtual Capture creates a clean virtual OS on your computer, and the installation is redirected in
the clean virtual OS.

Smart Monitor:
With Smart Monitor, SetupCapture watches the installation and records the changes the
installation performs. Available only when you're running Windows NT, 2000, or XP.
Snapshot:
With snapshot comparisons, SetupCapture scans the computer before and after the installation
and records the differences between the first scan and the second. Snapshot can also be used in
conjunction with SmartMonitor.

To run SetupCapture, do the following:

Run Wise Package Studio Client 7 SP2 on the Packaging workstation.

Logon using an account supplied by the Packing Team Lead
Click the Projects tab in the Left Pane of the Workbench
Select an Active Project assignment.

Contact: 09742878183

Page 66

Double-Click the SetupCapture icon to launch the wizard.

Contact: 09742878183

Page 67

Select the SetupCapture option.

Browse to the Target Installation option and create a WSI file in application to be captured
directory.

Click Next.

Contact: 09742878183

Page 68

Choose Snapshot and check "Use Smart Monitor in conjunction with Snapshot". Click Next.

Click Next to start the Before Snapshot.

Contact: 09742878183

Page 69

Click Execute to run the application's original Setup.exe install. You can run multiple installs or
configuration files (registry merges, patches, etc.); then click Next to proceed continue.

Verify that you ready to end this capture. Click Next.

Contact: 09742878183

Page 70

Allow the scanning process to complete.

Contact: 09742878183

Page 71

View the Inclusion drop-down list and review the Files, Registry, and INI Files to verify that the
items listed are needed to complete the install. If they are not needed select the item then click
Exclude. Click Next to continue.

Complete the Product Information details on this form, Click Finish.

Contact: 09742878183

Page 72

3.2 Create a transform using Install Tailor in Wise Package studio

Start Wise Package Studio, and go to Tools.
Select Install Tailor

Now you have to select the MSI that you want to build the transform. When you already have an
MST file, then you can select that one in the line were you can select the Base MST file. That will
help you alter the MST to add changes to it. Click Next to continue.

Contact: 09742878183

Page 73

As you see we now have our own created MSI, and we are going to select to all the options we
get.
This first screen is the welcome screen. Here we say Next to go to the following screen.

Give a Name and a Company in the boxes. Click Next to go to the next screen.

Now we specify the default path where we'd like the installation to be. In this case I leave the
default path. If you want to test, you might change the default path to some other path.

Contact: 09742878183

Page 74

Click Next to go the next screen.

The next and last screen is confirming the options you selected. Press Next to install the
application.
Now you get a screen telling you that your options are captured. Click OK to go to the final steps.
Edit this transform file using Windows Installer Editor and save it.

To deploy the created transform using command line, use

Msiexec /I Product.msi TRANSFORMS=transform1.mst /qb+

Contact: 09742878183

Page 75

3.3 - Creating a Major Upgrade in Wise Package studio

1. In this exercise you will add to the folders you created in the previous exercise. Open the
versions.wsi in the 1.1 folder. Choose File > Save As. Save a copy under 2.0 folder.
Name this Versions.wsi.

2. Remember that with a Major Upgrade you are able to add a new top-level feature. So
let's do that. Go to the Features view under the Installation Expert. Choose the Add
button on the right side. Fill out the details for the feature. You could, for instance, name it
NewMajorUpgradeFeature. Make sure the Parent: field is set to <None> so it does not
become a sub-feature.

Contact: 09742878183

Page 76

3. Add some files to the new Feature using the Files view under the Installation Expert. With
a Major Upgrade there is no limitation on what you can do so feel free to add as many
files as you want. Remember though if you add a lot of files it will take the Wise for
Windows Installer Editor a long time to process this.
4. Compile the new package using the Compile button on the bottom right-hand of the
window.
5. Check to make sure you have a new MSI package in the 2.0 folder.

Now you have a base and an upgraded version you are ready to create a Major Upgrade.
There are two steps:
1. Run UpgradeSynch to correctly modify the ProductCode, PackageCode and
ProductVersion.
2. Use the Upgrades view in the Installation Expert to populate the Upgrade table.
This will remove the previous version.
6. Run the UpgradeSynch tool from the Tools tab under Wise Package Studio. At the first
window click the Browse button and select the versions.wsi file in the 2.0 folder. Before
running the UpgradeSynch tool ensure that all Wise for Windows Installer Editor windows
are closed.

Contact: 09742878183

Page 77

7. Click Next. At the next window click the Browse button and choose the wsi in the 1.1
folder. Remember to select Files of type at the bottom of the screen in order to select the
WSI rather than the MSI file.

Contact: 09742878183

Page 78

8. Click Next. On the following window select the radio button for Major Upgrade and set the
Current Version field to 2.0.

9. Click Next. On the following window no errors should appear. Click Finish.
10. Re-open the versions.wsi from the 2.0 folder. Make sure that the Version filed under the
Product Details view has been incremented to 2.0.0.
11. At this point the UpgradeCode, ProductCode, PackageCode and ProductVersion should
be correctly configured. Now you must populate the Upgrade table. Select the Upgrades
view from the Installation Expert tab.

Contact: 09742878183

Page 79

12. Select the Add button on the right hand side and browse to the versions.msi file under the
1.1 folder. When the Upgrade Details window appears you do not have to modify
anything. Leave all the defaults and click OK. Compile.

13. Now the Upgrade table, viewable under the Setup Editor tab > Tables view has been
filled in. This will automatically remove the previous version at install time.
Now you are ready to test the Major Upgrade!
14. 14. Make sure the versions.msi in the 1.1 folder is installed on the machine. Now double
click the versions.msi in the 2.0 folder. It should automatically detect and remove the
previous version. When you look in Add/Remove programs you should see only one
Versions with a version number of 2.0.
If you see multiple entries for Versions in Add/Remove programs the upgrade process
has not worked correctly. The Upgrade table was probably not filled in correctly.

Contact: 09742878183

Page 80

3.4 - Different ways of giving permissions in MSI installation

Windows XP works under a locked down environment in most organizations. The MSI authors
generally have to provide permissions to the installation directory, so that the users without admin
rights are able to access and write data into the installation directory.
When you set permissions, you are specifying what level of access the user has to the folder and
its files and what users can do within that folder such as save, delete, or read files.
There are six standard permission types which apply to files and folders in Windows XP:
Full Control
Modify
Read & Execute
List Folder Contents
Read
Write
Each level represents a different set of actions users can perform. See the table below for more
information. For folders you can also set your own unique permissions or create a variation of any
of the standard permission levels. Within each of the permission levels are many possible
variations.
The following table represents the available standard permission types with their descriptions:
Full Control - Permits the user(s) to:
view file name and subfolders
navigate to subfolders
view data in the folder's files
add files and subfolders to the folder
change the folder's files
delete the folder and its files
change permissions
take ownership of the folder and its files
Modify - Permits the user(s) to:
view the file names and subfolders
navigate to subfolders
view data in the folder's files
add files and subfolders to the folder
change the folder's files
delete the folder and its files
Read & Execute - Permits the user(s) to:
view file names and subfolder names
navigate to subfolders
view data in the folder's files
add files and subfolders to the folder

Contact: 09742878183

Page 81

List Folder Contents - Permits the user(s) to:

view folders
navigate to subfolders
view folders
does not permit access to the folder's files
Read - Permits the user(s) to:
view the file names and subfolder names
navigate to subfolders
run applications
open files
copy and view data in the folder's files
Write - The Read permissions, plus permits the user(s) to:
create folders
add new files
open and change files
delete files
You can set permission to folders in following ways:
1. Secedit
2. XCACLS
3. LockPermission table.
SECEDIT:
SECEDIT command-line tool can be used to impose group policy object settings upon a target
workstation immediately.
To use Secedit to give permission in your package, perform the following steps:
Go to Run and type MMC.
A Console will open up as shown in the below picture.
Go to File -> and click on Add / Remove Snap in.

Contact: 09742878183

Page 82

The Add / Remove Snap in window opens up as shown in the below picture.

After this Click on Add

Contact: 09742878183

Page 83

Add standalone Snap in console opens up as shown in the below picture.

Choose Security Template from the list of Snap in, and click on Add. The Security template will
be added to the console.
You can see the File System, with all the listed directories on the right. This is shown in below
picture.

Contact: 09742878183

Page 84

Now, delete all files on right.

Right click and click on Add File, browse and select the required directory to give permission to.
Similarly you can give permission to registry too.

Now, delete all files on right. Right click and click on Add File, browse and select the required
directory to give permission to.
Similarly you can give permission to registry too.

Contact: 09742878183

Page 85

Click on OK and save this template as .inf (such as {PackageName}.inf) file.

Now we have to include this file in the package.
Add this file to %Windir%\security\templates folder.
Use the following Custom Action in your package to implement Secedit.
Use Execute Program from Destination Custom Action.
Give Custom Action name as per your standards
Working Directory to be set is Templates folder (where we have placed the .inf file.
In exe and Command line give the following command:

secedit /configure /db "[security]Database\{PackageName}.sdb" /cfg

"[security]templates\{PackageName}.inf" /log "[security]logs\{PackageName}.log" /quiet

Here [security] refers to the security folder is C:\Windows or %Windir%\Security. It is always good
to use directory instead of hardcoded paths.
{PackageName} refers to the name you would like to give to your .inf file, to your log file you
create and to the .sdb file you create.
Note that this will create .sdb file in %windir%\security\Database folder and .log file in
%windir%\security\logs folder. So while un-installation of package you need to remember to
delete these files from the folder. You can do that by using remove file table.
The location of the Custom action should be just before install finalize.
The Condition for launch of Custom Action should be "NOT REMOVE"
The Custom action can be run in deferred mode in system context.
XCACLS:
XCACLS or Extended Change Access Control List tool is an advanced version of CACLS, the
difference being that we do not have to answer Yes/No prompts in XCACLS. CACLS and
XCACLS are tools which are used to modify the ACLs (Access Control Lists), by which in turn we
are modifying the folder permissions for users in windows.
CACLS is installed in all users machine in System32 folder.
XCACLS ships with the Windows NT Resource Kit or can be easily downloaded from net.
XCACLS allows you to set permissions to the same granular level of control that you have with
the GUI.
CACLS Syntax
CACLS filename [/T] [/E] [/C] [/G user:perm] [/R user [...]] [/P user:perm [...]] [/D user [...]]

Contact: 09742878183

Page 86

filename

Displays ACLs.

/T

Changes ACLs of specified files in the current directory and all subdirectories.

/E

Edit ACL instead of replacing it.

/C

Continue on access denied errors.

/G user:perm

Grant specified user access rights.

Perm can be:
R Read
C Change (write)
F Full control

/R user

Revoke specified user's access rights (only valid with /E).

/P user:perm

Replace specified user's access rights.

Perm can be:
N None
R Read
C Change (write)
F Full control

/D user

Deny specified user access.

Wildcards can be used to specify more than one file in a command.

You can specify more than one user in a command.
XCACLS Syntax
XCACLS filename [/T] [/E] [/C] [/G user:perm;spec] [/R user [...]][/P user:perm;spec [...]]
[/D user [...]] [/Y]

filename

Displays ACLs.

/T

Changes ACLs of specified files in the current directory and all

subdirectories.

/E

Edit ACL instead of replacing it.

/C

Continue on access denied errors.

/G
user:perm;spec

Grant specified user access rights.

Perm can be:
R Read

Contact: 09742878183

Page 87

C - Change (write)
F - Full control
P - Change Permissions (Special access)
O - Take Ownership (Special access)
X - EXecute (Special access)
E - REad (Special access)
W - Write (Special access)
D - Delete (Special access)
T - NoT Specified (for file inherit, only for dirs valid)
/R user

Revoke specified user's access rights.

/P user:perm;spec

Replace specified user's access rights.

for access right specification see /G option

/D user

Deny specified user access.

/Y

Replace user's rights without verify

Wildcards can be used to specify more that one file in a command.

You can specify more than one user in a command.
You can combine access rights.
Example of XCACLS can be:
xcacls "[INSTALLDIR]FOLDER" /e /g users:ewxd;ewx

LockPermission table:
LockPermission table can be also used to give permission to files, folders and registries.
With the help of LockPermission table you can give permission to only those users who already
exist on the computer or domain.
For giving permission through LockPermission table follow the below procedure:
On the File section in Installation expert (You can do the same with Registry too), either go to file
or the directory (depending on to which you want to give permission) and click on Details. There
will be a permission tab there. For giving permission to file you will get the below screen where
there will be a permissions tab among other tabs as shown in the picture. If you have chosen
directory then there will only be a permissions tab. Click on Add. In the domain, you can mention
the domain of the user for which permissions are to be set. You can either give a standalone
machine or a domain name. I have used an environment variable here [%USERDOMAIN] which
will pick the domain at run time for the user for which the package is being installed. The user

Contact: 09742878183

Page 88

which you can set can be Administrator, Everyone or Logged on User. I have selected everyone
here.

After that you can select the permissions from below what all permissions you want to give to the
user. Click ok and the permissions work is over.
Now when you go to the LockPermission table in Tables section, you can see the following
columns there:
Lock Object, Table, Domain, User and permission
Lock Object and Table column together specify the file, directory or registry key to be given
permission to. Lock Object contains the name of the file, directory or the registry name. Table
column can be filled with File, Create Folder or Registry. Lock Object is the foreign key to the
primary key of Table mentioned by Table column.
Domain as I have mentioned earlier is the domain of the user.
User too as I have mentioned earlier is the User to whom we want to give the permission.
Permission is the Generic number to the permissions we have specified.
Every file, registry key, or directory that is listed in the LockPermission Table receives an explicit
security descriptor, whether it replaces an existing object or not. The Windows Installer attempts
to preserve the security on objects that already exist on the system. If an object is not listed in the
LockPermission Table, and replaces an existing object, the replacement gets the security settings
of the object that it replaces.

Contact: 09742878183

Page 89

If an object is not listed in the LockPermission Table, and does not replace an existing object, it
receives no explicit security descriptor. The access to the new object is based on the attributes of
its parent or container object. If an object is not listed in the table, and replaces an object with no
explicit security descriptor, the access to the new object is based on the attributes of its parent or
container object.

3.5 - Installing and Loading Excel Add-ins with Wise Script

An Excel Add-In is a file (usually with an .xla or .xll extension) that Excel can load when it starts
up.
There are two methods of adding the Excel Addins through MSI Package:
1. Best way is to drop the .xla or .xll files to XLstart folder in Office folder. Say if its Office XP or
2002 - then the folder will be (C:\Program Files\Microsoft Office\Office10\XLStart)
2. Placing the Addin in the following user-specific registry key. When the user launches Excel
the Addins will be loaded as per the order of OPEN keys.
HKCU\Software\Microsoft\office\<version>\Excel\Options

The first method described here is pretty much straight forward; we can achieve it by placing the
files in the Xlstart folder.
The problem with the second method is that when we do a setup capture of the application, Wise
captures these Add-in keys as OPEN, OPEN1, OPEN2 depending on the number of Excel Addins present. We cannot ship these keys as such using an MSI as it will replace the registry keys in
the destination computer.
Solution: In order to overcome this issue, we need to write a Wise Script that will fetch the current
OPEN keys and increment the OPEN key Number. If OPEN1, OPEN2 are already present in the
box, then the script will install the Add-in as OPEN3 and so on. This will avoid corrupting the
existing Add-ins on the box.

Contact: 09742878183

Page 90

This is a sample WiseScript designed to overcome this issue. The script accepts a value for the
Add-in using a variable called ADDIN.

Contact: 09742878183

Page 91

3.6 - Packaging Device driver applications

Repackaging of Device Driver is a difficult task. But some tools are available in market which can
be used for installing driver. A very well-known tool is DPINST which most used for installing
drivers through MSI.
Driver Files:
While repackaging we need to make sure that following files are available for proper installation of
device drivers:
1.
2.

Driver Files
Install Files
Driver Files: Driver files are a DLL file with generally a .sys files extension.
Install File: In the install file we get following important files:
INF file or Information files: Which contains information about drivers.
CAT File: It's a Driver Catalog File. This file contain information about each file in driver package.
Using DPINST.exe
It's a third party executable can be downloaded from net.The syntax and its command line
options are as given below:
Syntax:
DPInst.exe [/U INF-file][/S | /Q][/LM][/P][/F][/SH][/SA][/A][/PATH Path][
/EL][/L LanguageID][/C][/D][/LogTitle Title][/SW][/? | /h | /help]C

Command Line options:

/U path to INF file Uninstall a driver package (INF-file).
/S | /Q Silent (Quiet) mode. Suppresses the Device Installation Wizard and any dialogs
popped-up by the operating system.
/LM Legacy mode. Accepts unsigned driver packages and packages with missing files.
These packages won't install on the latest version of Windows.
/P Prompt if the driver package to be installed is not better than the current one.
/F Force install inf the driver package is not better than the current one.

Contact: 09742878183

Page 92

/SH Scans hardware for matching devices and only copies and installs those drivers for
which a device is present. Only valid for Plug and Play drivers.
/SA Suppress the Add/Remove Programs entry normally created for each driver
package.
/A Install all or none.
/PATH Path Search for driver packages under the given path.
/EL Enables all languages not explicitly listed in the XML file.
/L LanguageID Tries to use the given language in all UI. Useful for localization tests.
/SE Suppress the EULA.
/C Dump logging output to attached Console (Windows XP and above).
/D Delete driver binaries on uninstall.
/SW Suppresses the Device Installation Wizard, the operating system might still pop-up
user dialogs.
/? | /h | /help Shows this help.
Driver Package Install
Command Line:
DPInst.exe /PATH "<files path>\." /Q /A /F /SA

Where <files path> is a folder in which the driver installation files i.e. .inf, .cat or .sys files are
present.
It is important to give "\." at the end of< files path>, so that the executable will take care of all the
driver files present under that folder.

3.7 - Step by Step Procedure for creating a Patch using Wise package studio
Modify the project file to reflect changes to incorporate into the patch. Make all the
changes normally made to a new project
Build a new MSI for the project.
Use MSIPackageDiff program from DevStudio Tools (or menu to review the differences
between the original production and new MSI). The two MSIs should be kept as similar
as possible.
Create admin image of both the msi.
Open Wise Package Studio, Select 'Patch Creation' and double-click the Patch Creation
in 'Tool tab'.

Contact: 09742878183

Page 93

The Welcome dialog appears, listing the basic steps for creating a patch file. The wizard
guides you through each step.
Click on 'Next'

Contact: 09742878183

Page 94

Click on 'Next'

Click on 'Add' then the following screen appears:

Brows the previous MSI in previous MSI path And click 'OK'

Contact: 09742878183

Page 95

The following screen appears with the older version of MSI. Click on 'Next'.

Note that the .MSI files must have all files placed outside of the installation because the patching
engine compares the contents of files; it needs to be able to see those files.
If your MSI is in compressed format then the Wizard will ask you where you want to decompress
the files to. Choose a temporary folder as this can be safely deleted once the patch has been
made.

Contact: 09742878183

Page 96

Specify the updated MSI path with the help of 'Browse' button. Then click on 'Next'
button.

Select the destination path for the patch package using Browse button, then click on
'Next'

To make this patch removable through Add/Remove Programs, click Allow Removal and
complete the Patch Removal Settings dialog in the above screen.

Contact: 09742878183

Page 97

Click 'Finish' and the .msp and .psp files are ready in the specified folder.

The patch file will be saved in the specified location. If the patch file could not be created, use this
log file to determine the source of the error.
To apply the patch use the following command line with appropriate switches as necessary.
msiexec /i mypackage.msi PATCH=mypatch.msp

3.8 - Nested MSI Installation

A nested installation is a type of Custom Action that installs or removes another .msi package
(sometimes called the child MSI) from within a running installation (called the parent MSI).
Properties of Nested Installs
Nested installations do not display a user interface.
A child product generally does not appear in the user's Add/Remove Programs panel,
and is not automatically uninstalled when the parent product is uninstalled.
Creating a Nested Installation
Step 1: To create two .MSI files for a nested installation:
1. Open Wise for Windows Installer, Wise for Visual Studio .NET, or Wise Package Studio. If
you are working in Wise Package Studio, open the Windows Installer Editor tool.
2. Select New from the File menu. The New Installation File dialog appears.
3. Select the Windows Application icon, then click OK.
4. Fill in the Product Details page in Installation Expert with information about your installation.

Contact: 09742878183

Page 98

5. On the Files page in each .WSI, add at least one file to the installation. (Every .MSI needs to
have at least one component in the package in order to avoid getting a Windows Installer
error).
6. Save your file with the name Parent.WSI. Compile Parent.WSI into Parent .MSI.
7. Follow steps 2 through 5 to create another .MSI file and name the next .WSI Child.WSI and
compile it into an .MSI.
8. On the Product Details page, copy the product code listed in the Product Code field to
Notepad.
9. Save this installation file with the name Child.MSI.
Step 2: To create a custom action for the nested installation:
1.
2.
3.
4.
5.
6.

7.
8.
9.
10.

Open the Parent.MSI installation.

Click No in the message to convert the .MSI to a .WSI file.
Click the MSI Script tab, then click the Execute Immediate tab.
Scroll down to the Cost Finalize script line in the Installation Sequence pane. It's the last line
in the fifth section of script.
Select the blank line below the Cost Finalize action then double-click the Install MSI from
Installation action in the Actions pane. The Install MSI from Installation dialog appears.
Fill in the fields as follows:
Custom Action Name: Enter a name for this custom action.
Installation to Run: Enter the path to the Child.MSI file.
Leave the Property Settings field blank.
Click OK.
Double-click the If Statement action in the Actions pane. The If Settings dialog appears.
Enter Not Installed in the If Condition field, then click OK.
Select the blank script line below the new custom action.
Double-click the End Statement action in the Actions pane.

To install all the features of the child installation with their default settings, and to use the same
value for the ALLUSERS property used by the parent installation, type the following into the
Target field.
ARPSYSTEMCOMPONENT=1 ADDDEFAULT=ALL ALLUSERS=[ALLUSERS]

One can use similar expressions to use the same value of INSTALLDIR in the child as in the
parent.
Step 3: To create a custom action for the un-install:
1. Scroll down to the REM. Begin the sequence of actions that makes changes to the system
script line, which is seven lines below the End statement you added to the script.
2. Select this script line then double-click the Install MSI from Destination action in the Actions
pane. The Install MSI from Destination dialog appears.
3. Fill in the fields as follows:
Custom Action: Enter the name of the custom action.
Product Code: Copy and paste the Child.MSI product code from the Notepad file.
Property Settings: Enter REMOVE=ALL
Click OK.
4. Double-click the If Statement action in the Actions pane. The If Settings dialog appears.
5. Enter REMOVE~="ALL" in the If Condition field, then click OK.

Contact: 09742878183

Page 99

6. In the Installation Sequence pane, select the line below the Install MSI from Destination
Product Code that One created.
7. Double-click the End Statement action in the Actions pane.
8. Save and compile the Parent.MSI installation.
Media Options for Nested Installations:
The child installation must not be compressed inside a Setup.exe installation launcher.
If the child installation's files are not compressed inside the child .msi database, we must
manually copy the child installation's files to the SourceDir folder of the parent
installation.
Removing Nested Installation:
A child MSI is not automatically removed when the parent product is removed. However, one can
create a second nested-installation custom action that does this.
Disadvantages of Nested MSIs:
The cons of using the Nested MSI's are,
Nested Installations cannot share components.
An administrative installation cannot contain a nested installation.
Patching and upgrading will not work with nested installations.
The installer will not correctly cost a nested installation.
Integrated Progress Bars cannot be used with nested installations.
Resources that are to be advertised cannot be installed by the nested installation.
A package that performs a nested installation of an application should also uninstall the
nested application when the parent product is uninstalled.

3.9 - Significance of SelfReg Table entry

The SelfReg table contains information about modules that need to be self-registered. The
installer calls the DllRegisterServer function during installation of the module; it calls
DllUnregisterServer during Uninstallation of the module. The installer does not self-register EXE
files.
Steps to follow when a package contains a SelfReg entry
Whenever SelfReg entries are there in the package, you should do the following:
1. Look for WiseComcapture.exe in %ProgramFiles%\Wise Package Studio\Windows
Installer Editor\, as shown in Fig 1.

Contact: 09742878183

Page 100

2. On double clicking this exe, you will understand the command. See Fig. 2

3. Install the application source/Copy that file to the respective physical location. Ex: if the
SelfReg having a reference for "Comdlg32.ocx", then locate the component
"Comdlg32.ocx" and note down the path where it is getting installed, say
"C:\Windows\System32". See Fig 3

Contact: 09742878183

Page 101

4. Now use "WiseComCapture" to get the registry entries as follows:

WiseComCapture.exe /r "C:\Windows\System32\Comdlg32.ocx"
C:\Comdlg32.reg

5. Now "Comdlg32.reg" will have the registries which are associated with Comdlg32.ocx
See below figures.

Contact: 09742878183

Page 102

6. Now delete the registry entries from "Class" table, "ProgID" Table, "Registry" table, which
is associated with "Comdlg32.ocx" Component in the package. And also delete the
"Comdlg32.ocx" entry in the SelfReg table.
7. Locate "Comdlg32.ocx" component and import the registry "Comdlg32.reg", say "NO" (Or
yes, if it is required) when prompted for advertisement. See next pictures

Contact: 09742878183

Page 103

8. Continue all the above steps for other SelfReg entries.

Why shouldn't a package contain a SelfReg entry?
The package should not contain any SelfReg entries because:
Rollback of an installation with self-registered modules cannot be safely done using
DllUnregisterServer because there is no way of telling if the self-registered keys are used
by another feature or application.
The ability to use advertisement is reduced if Class or extension server registration is
performed within self-registration routines.
The installer automatically handles HKCR keys in the registry tables for both per-user or
per-machine installations. DllRegisterServer routines currently do not support the notion
of a per-user HKCR key.
If multiple users are using a self-registered application on the same computer, each user
must install the application the first time they run it. Otherwise the installer cannot easily
determine that the proper HKCU registry keys exist.
The DllRegisterServer can be denied access to network resources such as type libraries
if a component is both specified as run-from-source and is listed in the SelfReg table.
This can cause the installation of the component to fail to during an administrative
installation.
Self-registering DLLs are more susceptible to coding errors because the new code
required for DllRegisterServer is commonly different for each DLL. Instead use the
registry tables in the database to take advantage of existing code provided by the
installer.
Self-registering DLLs can sometimes link to auxiliary DLLs that are not present or are the
wrong version. In contrast, the installer can register the DLLs using the registry tables
with no dependency on the current state of the system.

3.10 - Common Registry entries used during packaging

Here's some reference information about the registry hives. (I like to keep lists like this close,
because I never know when I need them.) Hopefully this info will be as helpful to you as it has
been to me.
HKEY_CLASSES_ROOT - This branch contains all of your file types as well as OLE information
for all your OLE-aware applications.
HKEY_CURRENT_USER - This branch points to the part of HKEY_USERS appropriate for the
current user.

Contact: 09742878183

Page 104

HKEY_LOCAL_MACHINE - This branch contains information about all of the hardware and
software installed on your computer. Since you can specify multiple hardware configurations, the
current hardware configuration is specified in HKEY_CURRENT_CONFIG.
HKEY_USERS - This branch contains certain preferences (such as colors and control panel
settings) for each of the users of the computer. In Windows 95/98/Me, the default branch here
contains the currently-logged in user. In Windows 2000/XP, the default branch here contains a
template to be used for newly-added users.
HKEY_CURRENT_CONFIG - This branch points to the part of HKEY_LOCAL_MACHINE
appropriate for the current hardware configuration.
HKEY_DYN_DATA (Windows 95/98/Me only) - This branch points to the part of
HKEY_LOCAL_MACHINE, for use with Windows' Plug-&-Play subsystem.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.

24.

Services -- HKLM\SYSTEM\Currentcontrolset\Services
Enable USB -- HKLM\System\CurrentControlSet\Services\USBSTOR - 3
Disable USB -- HKLM\System\CurrentControlSet\Services\USBSTOR - 4
Environment Variable -HKLM\System\CurrentControlSet\Control\SessionManager\Environment\
Suite of Windows OS -- HKLM\System\CurrentControlSet\Control\ProductOptions [
ProductSuite ]
Type of workstation -- HKLM\System\CurrentControlSet\Control\ProductOptions [
ProductType ]
Driver & Printer info -- HKLM\SYSTEM\CurrentControlSet\Control\Print
Application Paths -- HKLM\Software\Microsoft\Windows\CurrentVersion\App
Paths\ProgramName.exe
Shared DLLs -- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs
Namespaces -HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\Namespace
Uninstall -- HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\{product key}
System DSN -- HKLM\Software\ODBC\ODBC.INI
Version of Internet Explorer -- HKLM\Software\Microsoft\Internet Explorer
Run key -- HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Service pack on Windows OS -- HKLM\Software\Microsoft\Windows NT\CurrentVersion
[CSDVersion]
AutoLogon -- HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Run Once Key -- HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
Windows Explorer configuration -- HKCU\Software\Microsoft\Windows\Currrent
Version\Explorer
Internet Explorer configuration -- HKCU\Software\Microsoft\Internet
Explorer\Toolbar\Explorer
USER DSN -- HKCU\Software\ODBC\ODBC.INI
COM registrations -- HKCU\Software\Classes
User Preferences for the printer -- HKCU\Software\Microsoft\Windows
NT\CurrentVersion\Windows
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
Configure all Windows Installer installations to run with elevated privileges
HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer -- AlwaysInstallElevated -1
HKCU\Software\Policies\Microsoft\Windows\Installer -- AlwyasInstallElevated -1

Contact: 09742878183

Page 105

25. In Windows 95, 98, and Me, the Registry is contained in two hidden files in your Windows
directory, called USER.DAT and SYSTEM.DAT.

3.11 - Files and Registry Keys to be EXCLUDED while doing setup capture

There is a situation that happens where we all get confused while working on excluding lists.
Then when you complete a Setup Capture, the resulting package contains both necessary and
unnecessary information and entries for the installation.
The unnecessary information should be removed so it is important to know which entries are
extra and what information is not important.
This is where having a concise Exclusion list becomes invaluable in ensuring that only nonessential keys and files are removed from the MSI.

Exclusion List
An Exclusion list of Files and Registry Keys has been compiled over time and is constantly being
amended and updated.

Files to Exclude
As a general rule a repackaged application should not contain the following. Check updated list
for each project:
References to the computer name the product was scripted/compiled on eg. ABSCRIPT
References to a particular user name.
References to a particular domain/server i.e. 'Iloscr#'
Presence of any setup executables or files. (setup.exe)
Presence of any .REG files
folders of files referring to WISE Solutions or InstallShield particularly under HKCU
Config.sys
Autoexec.bat
User.dat
User.da0
.iss files
.isu files
uninst.exe (or deinstall) (we do not want end-users to have access to uninstall files)
uninstall.exe (or deinstall)
.tmp files
Unnecessary .log files
Pagefile.sys

Contact: 09742878183

Page 106

C:\Temp (this temporary folder should never contain info. needed by an application)
C:\WINNT\RECENT (this area contains links to recently used data files)
C:\WINNT\Debug
C:\WINNT\Tasks
C:\WINNT\System32\NtmsData
C:\WINNT\dllcache

Registry Keys to Exclude

As a general rule a repackaged application should not contain the following registry keys. Check
updated list for each project:
HKEY_CURRENT_USER settings
HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDLL's
HKLM\Software\Description\Microsoft\Rpc\UuidPersistentData\
HKLM\Software\Program Groups\
HKLM\Software\Classes\
HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList
HKLM\Software\Microsoft\WindowsNT\Current Version\WinLogon
HKLM\Software\Microsoft\Mounted Devices
HKLM\Software\Microsoft\Cryptography
HKLM\Software\Microsoft\DRM
HKLM\Software\Novell
HKLM\Hardware\
HKLM\System\CurrentControlSet\Control\
HKLM\System\CurrentControlSet\Enum\
HKLM\System\CurrentControlSet\hardwareProfiles\
HKLM\System\ControlSet000\
HKLM\System\ControlSet001\
HKLM\System\ControlSet002\
HKLM\System\ControlSet003\
HKLM\System\ControlSet004\
HKLM\System\ControlSet005\
HKLM\System\ControlSet006\
HKLM\System\Clone
HKLM\System\CurrentControlSet\Services\NICSHORTNAME\Parameters\Tcpip
"NICSHORTNAME" will be something like "EL09x1"
HKLM\System\CurrentControlSet\Services\NWCWorkstation

Contact: 09742878183

Page 107

HKLM\System\CurrentControlSet\Services\VxD\DHCP
HKLM\System\CurrentControlSet\Services\VxD\VCACHE
HKLM\System\CurrentControlSet\Services\kmixer\Enum
HKLM\System\Select
HKLM\CLONE
HKLM\SAM
HKLM\Software\Microsoft\Windows\CurrentVersion\Syncmgr\Autosync
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer
HKEY_CURRENT_USER\Volatile Environment
HKEY_CURRENT_USER\Software\Microsoft\Internet\Explorer\Toolbar\Shellbrowser
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Syncmgr\Handler
s
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\
3.12 - Capture Methodologies: SmartMonitor and Snapshot

SmartMonitor
This Setup Capture mechanism monitors and records the installation's operations as they
happen. This method is faster than snapshot comparisons, because it doesn't require a timeconsuming scan of the computer. SmartMonitor records the following operations:
Copying, moving, deleting, or opening a file.
Replacing files even if they are the same size, modification date, and version.
Creating or removing a directory.
Creating, starting, stopping, or deleting a service.
Setting or deleting a registry value, creating or deleting a registry key.
Overwriting existing registry keys with the same value.
Installing ODBC drivers or configuring ODBC data sources.
Changing .INI files regardless of their location.
Snapshot
This Setup Capture mechanism scans the computer before installation occurs, then you perform
the installation, then Setup Capture rescans the computer. Setup Capture records the differences
between the two scans and adds them to the repackaged installation.
The disadvantages of this method are:
It does not capture the replacement of files if the files are the same size, modification
date, and version.
It does not capture overwriting of existing registry keys.

Contact: 09742878183

Page 108

INI file changes are handled differently-if an .INI file is in the Windows directory, changes
to it are recorded as an .INI file change. If an .INI file is outside the Windows directory,
the entire .INI file is added instead of just editing the file.
Using SmartMonitor in conjunction with Snapshot

Merge the results of both methods. If the results of the two methods don't match, the differences
between the methods are added to the repackaged installation as well. This provides the most
accurate and complete representation of the captured installation. If you selected the snapshot
method, the Initial Scan dialog might appear. Specify whether to rerun the initial scan or use the
initial scan that was created previously.

Contact: 09742878183

Page 109