application re packaging guide
Post on 18-Jul-2016
48 Views
Preview:
DESCRIPTION
TRANSCRIPT
Contact: 09742878183 Page 1
Application Packaging Guide
Contact: 09742878183 Page 2
Contents
1.1 Repackaging 4
1.2 Why do organizations Repackage software 4
1.3 Differences between Software Repackaging and Software Packaging 4
1.4 Why not to repackage 6
1.5 Steps involved in repackaging process 6
1.6 Advantages of repackaging 9
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 3
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 4
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 company’s 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
company’s 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 administrator’s requirements
when creating installations.
Contact: 09742878183 Page 5
Software Packaging System Administrators (Repackaging)
– Method of installation creation: author
new installations
– Software developers typically author new
installations from the ground up.
– Method of installation creation: repackaging
– Administrators customize an existing
installation by repackaging it.
– Install on one PC
– Target is individual PCs.
– Install on many 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
– Little or no concern if the installed application
breaks other applications.
– Integration with other applications is critical
– It is imperative that each installed application
work with all other applications on the end
user’s PC.
– Support several platforms
– Doesn’t know specification of target platform,
so application installation is designed for
several platforms.
– Support limited number of platforms
– Knows target desktop specifications, so
application installation only needs to run on
specific platforms.
– Flexible installation
– Installation can be installed where a user
decides.
– Inflexible installation
– Requires the application to be installed in the
same location every time.
– Media distribution
– Typically distributes an application on a
CD for each user.
– Network distribution
– Distributes an application through the
network to multiple users.
– Extensive user input
– Users interact with the installation and make
their own choices about how the installation is
installed.
– No user input desired
– The system administrator determines what
features users will have and creates an
automated installation that installs without user
interaction.
– User-executed installation
– User initiates the application installation.
– Distribution system-executed
– 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
– User receives constant messages about the
application installation’s progress.
– Reports status to distribution system
– User is not encumbered by application
installation status reports.
Contact: 09742878183 Page 6
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
Figure 1: Repackaging life cycle
Requirement Analysis
Evaluation
Packaging
Testing (UAT)
Deployment
Contact: 09742878183 Page 7
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 application’s 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 application’s 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 application’s
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 studio’s Setup Capture and Windows Installer Editor Tool for repackaging the
applications.
Contact: 09742878183 Page 8
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 project’s 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 9
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, Novadigm’s 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 10
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 11
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 12
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 13
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 14
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 15
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 un-
installation 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 16
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 GUID’s 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 17
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 self-
healing 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
u - 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 - help information
Contact: 09742878183 Page 18
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 19
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
Registering EXE files:
<Path to exe file> /regserver - For registering a exe file
<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 Released with Vista, Vista SP1 and Server 2008
Contact: 09742878183 Page 20
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 - GUID’s 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 21
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 22
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 23
Logging of Action Return Values
Error Code Values that appear in log Description
ERROR_FUNCTION_NOT_CALLED 0 Function could not be
executed.
ERROR_SUCCESS 1 Action completed
successfully.
ERROR_INSTALL_USEREXIT 2 User canceled installation.
ERROR_INSTALL_FAILURE 3 Fatal error.
ERROR_INSTALL_SUSPEND 4 Installation suspended,
incomplete.
ERROR_SUCCESS 5 Action completed
successfully.
ERROR_INVALID_HANDLE_STATE 6 Handle is in an invalid state.
ERROR_INVALID_DATA 7 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 24
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 25
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 26
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 dll’s 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 files—FileA.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 27
This mechanism is useful when trying to override the Windows Installer’s 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 28
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 29
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 installation-
on-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 30
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 31
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 32
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 component’s 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 33
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 34
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 35
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 36
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 37
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 38
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="") or
ALLUSERS=”0”
ALLUSERS=1 ALLUSERS=2
User access
privileges
Per-user installation Not Valid – returns error
stating user not having
permission
Per-user installation
Admin access
privileges
Per-user installation Per-machine installation 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 39
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 40
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 41
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 42
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 43
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 44
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 ICE’s 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 45
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 46
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 47
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 48
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 49
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 50
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 dynamic-
link 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 51
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 un-
installation., 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 52
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 53
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 54
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 55
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 56
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 right-click 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 57
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 58
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 the windows registry key HKLM\System\CurrentControlSet\<Name of the Service>
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 ODBC-
compliant 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 59
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 60
- 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 61
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 62
None of the components to which these files belong have component GUID’s. (The value
for the component in the ComponentId column of the Component table is NULL).
Components without GUID’s 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 Description ActionText Lists text in a progress dialog box or action log.
AdminExecuteSequence Lists ADMIN actions in sequence. AdminUISequence Lists UI ADMIN actions in sequence. AdvtExecuteSequence Lists ADVERTISE actions in sequence. AdvtUISequence The Windows Installer does not use this table. The AdvtUISequence
Contact: 09742878183 Page 63
table should not exist in the installation database or it should be left empty.
AppId Specifies that the installer configure and register DCOM servers AppSearch Lists properties used to search by file signature. BBControl Lists controls displayed on each billboard. Billboard Lists billboards displayed in full UI. Binary Holds binary data for bitmaps and icons. BindImage Lists executables bound to the DLLs. CCPSearch Lists file signatures for the Compliance Checking Program. CheckBox Lists the values for the check boxes. Class Lists COM server information for product advertisement. ComboBox Lists the values for each combo box. CompLocator Find file or directory by installer configuration data. Complus Contains information needed to install COM+ applications. Component Lists installation components. Condition Modifies feature selection states conditionally. Control Lists the controls on each dialog box. ControlCondition Lists actions applied to controls based on a property. ControlEvent Specifies the actions of controls in dialog boxes. CreateFolder Lists folders that must be created for a component. CustomAction Integrates custom actions into the installation. Dialog Lists dialog boxes in the user interface. Directory Directory layout for the application. DrLocator Lists file searches using the directory tree. DuplicateFile Lists files to be duplicated. Environment Lists the environment variables. Error Lists error message formatting templates. EventMapping Lists the events subscribed to by controls. Extension Lists file extension server information. Feature Defines the logical tree structure of features. FeatureComponents Defines features and component relationships. File Complete list of source files with their attributes. FileSFPCatalog Associates specified files with the catalog files. Font Registry information for font files. Icon Contains the icon files. IniFile Information needed to set in an .ini file. IniLocator Searches for file or directory using an .ini file. InstallExecuteSequence Lists INSTALL actions in sequence. InstallUISequence Lists UI INSTALL actions in sequence. IsolatedComponent Lists Isolated Components. LaunchCondition Lists conditions for the installation to begin. ListBox Lists the values for all list boxes. ListView Lists the values for all listviews. LockPermissions Defines locked-down portions of the application.
Contact: 09742878183 Page 64
Media Lists source media disks for the installation. MIME Lists MIME content type, file extension, or CLSID. MoveFile Lists files to be moved or copied.
MsiAssembly Specifies Windows Installer settings for Microsoft .NET Framework assemblies and Win32 assemblies.
MsiAssemblyName Specifies the schema for the elements of a strong assembly cache name for a .NET Framework or Win32 assembly.
MsiDigitalCertificate Stores certificates in binary stream format and associates each certificate with a primary key.
MsiDigitalSignature Contains the signature information for every digitally-signed object in the installation database.
MsiEmbeddedChainer
Each row in this table references a different user-defined function that can be used to install multiple Windows Installer packages from a single package. Windows Installer 4.0 and earlier: Not supported.
MsiEmbeddedUI Defines a user interface embedded in the Windows Installer package. Windows Installer 4.0 and earlier: Not supported.
MsiFileHash Stores a 128-bit hash of source files provided by the Windows Installer package.
MsiPackageCertificate Lists digital signature certificates being used to verify the identity of installation packages that make this Multiple-Package Installation. Available beginning with Windows Installer 4.5.
MsiPatchCertificate Contains the information needed to enable User Account Control (UAC) Patching. Available beginning with Windows Installer 3.0.
MsiPatchHeaders Holds the binary patch header streams used for patch validation.
MsiPatchMetadata Holds information about a Windows Installer patch required to 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.
MsiPatchSequence Contains the information required to determine the sequence of application of a small update patch relative to all other patches. Available beginning with Windows Installer 3.0.
MsiSFCBypass Lists files that should bypass Windows File Protection on 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 65
RegLocator Searches for file or directory using the registry. RemoveFile Lists files to be removed by RemoveFiles action. RemoveIniFile Lists information needed to delete from an .ini file. RemoveRegistry Lists information needed to delete from system registry. ReserveCost Reserves disk space in any directory conditionally. SelfReg Lists information about self-registered modules. ServiceControl Controls installed or uninstalled services. ServiceInstall Lists information used to install a service. SFPCatalog Lists SFP catalogs. Shortcut Lists information needed to create shortcuts. Signature Lists the unique file signatures that identify files. TextStyle Lists text styles used in the text controls. TypeLib Lists registry information for type libraries. UIText Lists localized versions of some strings used in the user interface. Verb Lists command-verb information for file extensions. _Validation Lists column names and values for all tables. _Columns Read-only column catalog. _Streams Lists embedded OLE data streams. _Storages Lists embedded OLE sub-storages. _Tables Read-only system table listing all the tables. _TransformView Table A read-only temporary table used to view transforms. Upgrade Lists information used in an upgrade of an application.
Contact: 09742878183 Page 66
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 67
Double-Click the SetupCapture icon to launch the wizard.
Contact: 09742878183 Page 68
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 69
Choose Snapshot and check "Use Smart Monitor in conjunction with Snapshot". Click Next.
Click Next to start the Before Snapshot.
Contact: 09742878183 Page 70
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 71
Allow the scanning process to complete.
Contact: 09742878183 Page 72
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 73
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 74
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 75
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 76
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 77
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 78
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 79
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 80
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 81
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 82
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 83
The Add / Remove Snap in window opens up as shown in the below picture.
After this Click on Add
Contact: 09742878183 Page 84
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 85
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 86
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 87
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 88
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 89
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 90
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 Add-ins 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 91
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 92
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. Driver Files 2. 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 93
/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 94
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 95
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 96
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 97
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 98
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 99
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. Open the Parent.MSI installation. 2. Click No in the message to convert the .MSI to a .WSI file. 3. Click the MSI Script tab, then click the Execute Immediate tab. 4. Scroll down to the Cost Finalize script line in the Installation Sequence pane. It's the last line
in the fifth section of script. 5. 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. 6. 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.
7. Double-click the If Statement action in the Actions pane. The If Settings dialog appears. 8. Enter Not Installed in the If Condition field, then click OK. 9. Select the blank script line below the new custom action. 10. 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 100
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 101
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 102
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 103
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 104
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 105
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. Services -- HKLM\SYSTEM\Currentcontrolset\Services 2. Enable USB -- HKLM\System\CurrentControlSet\Services\USBSTOR - 3 3. Disable USB -- HKLM\System\CurrentControlSet\Services\USBSTOR - 4 4. Environment Variable --
HKLM\System\CurrentControlSet\Control\SessionManager\Environment\ 5. Suite of Windows OS -- HKLM\System\CurrentControlSet\Control\ProductOptions [
ProductSuite ] 6. Type of workstation -- HKLM\System\CurrentControlSet\Control\ProductOptions [
ProductType ] 7. Driver & Printer info -- HKLM\SYSTEM\CurrentControlSet\Control\Print 8. Application Paths -- HKLM\Software\Microsoft\Windows\CurrentVersion\App
Paths\ProgramName.exe 9. Shared DLLs -- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs 10. Namespaces --
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\Namespace 11. Uninstall -- HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\{product key} 12. System DSN -- HKLM\Software\ODBC\ODBC.INI 13. Version of Internet Explorer -- HKLM\Software\Microsoft\Internet Explorer 14. Run key -- HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run 15. Service pack on Windows OS -- HKLM\Software\Microsoft\Windows NT\CurrentVersion
[CSDVersion] 16. AutoLogon -- HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon 17. Run Once Key -- HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce 18. Windows Explorer configuration -- HKCU\Software\Microsoft\Windows\Currrent
Version\Explorer 19. Internet Explorer configuration -- HKCU\Software\Microsoft\Internet
Explorer\Toolbar\Explorer 20. USER DSN -- HKCU\Software\ODBC\ODBC.INI 21. COM registrations -- HKCU\Software\Classes 22. User Preferences for the printer -- HKCU\Software\Microsoft\Windows
NT\CurrentVersion\Windows 23. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
24. 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 106
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 non-
essential 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 107
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 108
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 time-
consuming 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 109
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.
top related