application re packaging guide

Contact: 09742878183

Application Packaging Guide

Contact: 09742878183

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

http://juice.altiris.com/glossary/1/letters#term119

http://juice.altiris.com/glossary/1/letterm#term310

Contact: 09742878183

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

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

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

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

http://juice.altiris.com/glossary/1/letteru#term262

Contact: 09742878183

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

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

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

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

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:

http://en.wikipedia.org/wiki/Application_software

http://en.wikipedia.org/wiki/Filename_extension

http://en.wikipedia.org/wiki/Filename_extension

http://en.wikipedia.org/wiki/.txt

http://en.wikipedia.org/wiki/Text_editor

Contact: 09742878183

- 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

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

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

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

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

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

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

Double-Click the SetupCapture icon to launch the wizard.

Contact: 09742878183

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

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

Click Next to start the Before Snapshot.

Contact: 09742878183

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

Allow the scanning process to complete.

Contact: 09742878183

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

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

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

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

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

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

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

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

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

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

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

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

After this Click on Add

Contact: 09742878183

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

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

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

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

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

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

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

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

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

/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

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

Click on 'Next'

Click on 'Add' then the following screen appears:

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

Contact: 09742878183

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

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

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

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

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

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

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

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

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

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

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


http://juice.altiris.com/glossary/1/letterh#term507

Contact: 09742878183

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\Clone

HKLM\System\CurrentControlSet\Services\NICSHORTNAME\Parameters\Tcpip

"NICSHORTNAME" will be something like "EL09x1"

HKLM\System\CurrentControlSet\Services\NWCWorkstation

Contact: 09742878183

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.

http://juice.altiris.com/glossary/1/letterd#term285

http://juice.altiris.com/glossary/1/letters#term112

http://juice.altiris.com/glossary/1/lettero#term276

Contact: 09742878183

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.

application re packaging guide

Documents