MSI Custom Action Conditions - Basic Application Packaging

Action run only during Install
NOT Installed AND NOT PATCH

Action runs during Install and repair
NOT REMOVE

Run on initial installation only:
NOT Installed

Run on initial install or when repair is selected.
NOT Installed OR MaintenanceMode="Modify"

To only run an action during uninstall use the following condition:
REMOVE~="ALL"

To only run an action during upgrade:
Installed AND NOT REMOVE

Deleting Runtime Generated Folder through VBScript - Advance Application Packaging

Lets say we have "%ProgramData%\Oracle Installation Products" as an INSTALLDIR and some extra folders are beng created during runtime and you dont want to delete INSTALLDIR but want to delete all subfolders then use below script:

Option Explicit
On Error Resume Next
Dim objshell, objFSO, StrprgData, objFolder, colSubfolders, objRegEx, colMatches
Dim Path, Test, objSubfolder

Set objShell=CreateObject ("wscript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFolder = objFSO.GetFolder( StrprgData & "\Microsoft\Windows\Start Menu\Programs")
Set colSubfolders = objFolder.Subfolders

StrprgData = objShell.ExpandEnvironmentStrings("%ProgramData%") 

For Each objSubfolder in colSubfolders
Set objRegEx = CreateObject("VBScript.RegExp")
objRegEx.Global = True
objRegEx.IgnoreCase = True
objRegEx.Pattern = "Oracle -"

Set colMatches = objRegEx.Execute(objSubfolder.Name)   

If colMatches.Count = 1 Then
Path = StrprgData & "\Microsoft\Windows\Start Menu\Programs\"

If objfso.FolderExists ( Path & objSubfolder.Name & "\Oracle Installation Products\") Then
Test = StrprgData & "\Microsoft\Windows\Start Menu\Programs\" & objSubfolder.Name

objfso.DeleteFolder test

End If
End if
Next

Thank you for reading.

Ideal setting for building IRP to ISM - Advance Application Packaging

Here is the screenshot which shows Ideal checks when we build ISM form IRP (Repackager)
This will generally excludes Merge Modules and System language which is set during capture.

Repackager Setting Screenshot

Thank you for reading :)

Getting Java INSTALLDIR through VBScript and using this value to assign to a system environment variable - Advance Application Packaging

During packaging there is case where SYSTEM Environment variable needs to be created and it value supposed to be a path of JAVA installed, and this path will deffer from defferent verion to version of java.

Firstly it is difficult to find java path installed on system using MSI System search, so this is the alternative way to get this path.

Drawback of this script if there are two java installed on same system it will return first path found, to overcome this issue we can specify search string more clearly  in pattern matching string. In my example it it "jre" only
I have created a SYSTEM environment variable named "JRE64_HOME"
and its value supposed to be "C:\Program Files\Java\jre1.8.0_45" which is fetch by script.
This value will defer from system to system.


Option Explicit
On Error Resume Next
Dim objshell, objFSO, StrprgData, objFolder, colSubfolders, objRegEx, colMatches
Dim Path, Test, objSubfolder
Dim strVarName, objVar, objVarClass
Set objShell=CreateObject ("wscript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")
StrprgData = objShell.ExpandEnvironmentStrings("%ProgramFiles%")
'This is the folder location "C:\Program Files\Java"
'script will look for subfolder of this folder Foe Ex here : "jre1.8.0_45"
Set objFolder = objFSO.GetFolder( StrprgData & "\java")
Set colSubfolders = objFolder.Subfolders
Set objVarClass = GetObject( "winmgmts://./root/cimv2:Win32_Environment" )
For Each objSubfolder in colSubfolders
Set objRegEx = CreateObject("VBScript.RegExp")
objRegEx.Global = True
objRegEx.IgnoreCase = True
objRegEx.Pattern = "jre"
'This ascript will check all subfolders of java and return first occourance of
'folder which name starts with "jre"
Set colMatches = objRegEx.Execute(objSubfolder.Name)
If colMatches.Count = 1 Then
Path = StrprgData & "\java\"
If objfso.FolderExists ( Path & objSubfolder.Name) Then
Test = StrprgData & "\java\" & objSubfolder.Name
'Test will return - C:\Program Files\Java\jre1.8.0_45
End If
End if
Next
'Below code will create a system variable JRE64_HOME and
'its value will be path returned by "Test" variable
strVarName = "JRE64_HOME"
Set objVar      = objVarClass.SpawnInstance_
objVar.Name          = strVarName
objVar.VariableValue = Test
objVar.UserName      = "<SYSTEM>"
objVar.Put_
'WScript.Echo "Created environment variable " & strVarName
Set objVar      = Nothing
Set objVarClass = Nothing


Thank you for reading :)
 

Creating a system environment variable through VBScript - Advance Application Packaging

Here is a way to create a system environment variable through VBScript

"JREPATH" = "C:\ProgramFiles\Java"

strVarName = "JREPATH"
strVarValue = "C:\ProgramFiles\Java"
Set objVarClass = GetObject( "winmgmts://./root/cimv2:Win32_Environment" )
Set objVar      = objVarClass.SpawnInstance_
objVar.Name          = strVarName
objVar.VariableValue = strVarValue
objVar.UserName      = "<SYSTEM>"
objVar.Put_
WScript.Echo "Created environment variable " & strVarName
Set objVar      = Nothing
Set objVarClass = Nothing


Thank you for reading :)

Accessing PUBLIC Property in Deffered Mode Custom Action - Advance Application Packaging

Step 1 :
Create PUBLIC property/Properties with needed Name-Value

In My example Im taking HOSTNAME , HOST1 & HOST2 as a three propeties.

Step 2 :
Create Set Property CA (Type51)

In my example Im am creating "SetPropForDefferedAccess"

Property Name - To identify the Propertys further by deffered CA (Here Set_PROPERTY)

Property Value - Give the list of properties you want to access in deffered mode [HOSTNAME];[HOST1];[HOST2]

CA Sequence should be set after Install Initialize

Step 3 :
Create New CA- VBscript stored in CA OR any other you need

In my example Im using VBScript stored in Custom action and named as "Set_PROPERTY"
NOTE : This CA name must be identical with the Property name mentioned in Set Property CA (Step 2)

Sequence should be set before Install Finalize

In Script use below code to fetch public property :

Option Explicit
on error resume next
Dim objShell,objFSO
Dim Test,Prop1,Prop2,Prop3
Dim PropArray
Set objShell = CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")
'To Access Single Property
Test=Session.Property("CustomActionData")
Msgbox Test
'To Access Multiple Properties
PropArray = Split(Session.Property("CustomActionData"), ";")
Prop1 = PropArray(0)
Prop2 = PropArray(1)
Prop3 = PropArray(2)
msgbox Prop1 & " " & Prop2 & " " & Prop3

Please add your comments just to addup more knoweledge about article.

Thanks for the reading :)

Reading LOGs for MSI Troubleshooting - Advance Application Packaging

What is LOG file!

A log file is a record of events taking place in the execution of a system and could be useful to perform log analysis in system troubleshooting

Logs are essential to understand the activities of complex systems in the case of applications with little user interaction.

VERBOSE LOGGING

Verbose means using more words than necessary.

Verbose logging is a computer logging mode that records more information than the usual logging mode. 

Logging can be enabled by adding keys and values to the registry.

After the entries have been added and enabled, we can retry the problem installation and Windows Installer which will track the progress and post it to the Temp folder.

The new log's file name is random, but begins with the letters "Msi" and end with a .log extension.

Command line to locate the Temp folder location as following

cd %temp%

NOTE:

In case of an Active Directory/GPO deployment, there will be no logged on user at the time the installation occurs. In this case the log file will be created in the "Windows\Temp" folder.

To enable Windows Installer logging we should add the following registry in system

REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer]

"Logging"="voicewarmup"

The letters in the value field can be in any order. Each letter turns on a different logging mode and described as follows

/L    [i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] Logfile & If no flags are specified, the default is 'iwearmo.'

                v - Verbose output

                o - Out-of-disk-space messages

                i - Status messages

                c - Initial UI parameters

                e - All error messages

                w - Non-fatal warnings

                a - Startup of actions

                r - Action-specific records

                m - Out-of-memory or fatal exit information

                u - User requests

                p - Terminal properties

                + - Append to existing file

                x - Extra debugging information.

"*" - Wildcard, log all information except for the v and the x option. To include the v and the x option, specify "/l*vx".

We can use Group Policy to enable logging:

Click Start->Run->gpedit.msc to start the Group Policy Editor.

Computer Configuration->Administrative Templates->Windows Components->Windows Installer.

Double-click Logging, and then click Enabled.

Driver Installation LOG:

To enable add the following registry in system

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup

LogLevel (DWORD) = 4800FFFF (hexadecimal).

This will result some logs as follows in Temp folder

        setupapi.log

        setupapi.app.log

        setupapi.dev.log

In case of command line installation on windows installer we can get the log using following command,

Msiexec /i AppName.msi /l*vx %temp%\AppName.log

Using the "*vx" modifier gives the most detail possible

Verbose logs will contain at least the following information:

 

• Most errors that occurred during the install including all Windows Installer errors that generate a user dialog.
• All standard actions executed as well as any custom actions that were executed
• Whether a reboot was requested and completed.
• Values of Installer Properties, including details of any changes.
• The source location of the installation media
• Whether the user cancelled the install.
• If the installation was completed or stopped.
• If the installation was rolled back, this will also be notated in the log
• Client and Server information

Reading Verbose log

Return Values

After each action the Installer will record the 'return value' in the log.

This is an indicator of the success or otherwise of the action. Possible values are:

Value	Meaning
0	Action was invoked, but did not run (not necessarily a bad thing, maybe there was nothing for it to do)
1	Action was a success
2	Action was cancelled by user
3	An unrecoverable error has occurred
4	The installation was suspended awaiting a reboot

Simply searching for the phrase "Return Value 3" can be a quick way of pinpointing the errors in a log.

This isn't guaranteed to lead to the source of a problem as some problems are quite subtle, but its good first step.

It may also break down in localized setup scenarios.

Basic understanding of MSI log files

1. It is a good idea to read the file from the bottom up, as the error will have occurred nearer the end of the file.

2. You will notice that an MSI log is split into two categories; 'Properties', which are displayed at the end of the article and 'Actions'.

An Action looks like:

MSI (s) (0C:50) [04:01:06:723]: PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'.

A Property looks like:

Property(S): IdentityCacheDir = C:\WINDOWS\Microsoft.NET\Framework64\

Focus on the Actions as opposed to Properties. Each action makes up a part of the installation procedure.

3. To determine which action has failed during the installation, search for the error generated during installation.

Ex: if error 1603 was displayed during the Application installation, search for 1603 in Application Install Log.txt

4.When you have located the error, look at the Action that was performed just before the error. A return value code is written in the log to show if the action completed successfully or not. One of the following will be displayed:

    Return Value 1 – The Action completed successfully

    Return Value 2 – The user terminated the action

    Return Value 3 – The Action failed (will cause the installation to terminate)

Make a note of which of the actions gives a return value of 3, and record any additional error information in the log file that may not have been displayed in the on-screen error.

5. The name will reflect what the action is trying to perform.

Ex:    The Action CreateUserGroups attempts to create the users used by Application.

    The Action CheckRegForNullDACLs will check registry keys required by Application to ensure they have the correct access control.

Some scenarios discussed

Could not open Registry Key

The Installer logs a lot of useful information in the form of 'error' codes.

Sometimes these are genuine errors, but often they are simply for information purposes and do not indicate a real problem.

Full details of all codes can be found in the MSDN Library or the Windows Installer SDK Link.

Ex: take the following entry from the annotated log below:

MSI (c) (C0:6C) [22:17:24:953]: Note: 1: 1402 2: HKEY_CURRENT_USER\Software\Microsoft\MS Setup (ACME)\User Info 3: 2

The SDK defines the code 1402 as: Could not open key: [2]. System error [3].

Feature and component state

Useful item that is included in a verbose log file is the feature and component state values that are used during the installation.

The following is an example entry in a verbose log file for a feature state, note the areas highlighted in bold.

        MSI (s) (34:A1): Feature: _MainFeature; Installed: Absent; Request: Local; Action: Local

For a feature state entry in the log file, the entry will be prefaced with Feature: and the feature name will follow.

In this case, the feature state being displayed is for the feature named _MainFeature.

The Installed entry represents the current state of the feature on the machine.

When the setup package is being in installed for the first time, this value following Installed: will typically be absent meaning the feature is not currently installed on the machine.

Other values are possible such as Local, Null, Request, etc.

Particular file was or was not copied

This can be useful when trying to determine why a particular file is or is not copied to the machine.

Ex: line in the log file may look like the following,

       MSI (s) (34:A1): Executing op : FileCopy(SourceName=Global_Vba_VBStockProp_f0.7EBEDD3E_AA66_11D2_B980_006097C4DE24,DestName=msstkprp.dll,Attributes=0,FileSize=94208,Version=6.0.81.69,Language=1033,InstallMode=58982400)

       MSI (s) (34:A1): File: C:\WINNT\System32\msstkprp.dll; Won't Overwrite; Existing file is of an equal version

When the setup package is being in installed listed file is already present on target build with same version and hence installer is giving a warning about it.

Installation encounters an error, rolling back the installation.

We can find rollback information in the log file by searching for Rollback:

        Rollback: Registering type libraries

In this example, we can see that the RegisterTypeLibraries standard action is rolling back the previous work done earlier in the installation when the RegisterTypeLibraries action executed.

Component state

For a component state entry in the log file, the entry will be prefaced with Component: and the component name will follow.

        MSI (s) (34:A1): Component: Global_Notepad; Installed: Local; Request: Null; Action: Null

In this case, the component state being displayed is for the component named Global_Notepad.

The Installed entry represents the current state of the feature on the machine.

When the setup package is being in installed for the first time, this value following Installed will typically be Absent meaning the component is not currently installed on the machine.

Ex: Installed is set to Local meaning that the underlying component is already installed on the machine.

There are other values are possible for Installed such as Local, Null, Request, etc.

Property

At the end of the verbose log file is a complete property dump of the property names and values which can have either client or server properties listed, client only or server only depending on what operating system the log was generated on and what the user interface level was set to.

Ex:  in a quiet mode installation on Windows NT, 2000 or XP, only the server process is executed and only server process properties would be displayed at the end of the log file.  The following is an example line found in a verbose log file of a property and its value at the end of the client part of the installation before switching to the server process.

        Property(C): USERNAME = someuser

This line shows the value of the USERNAME property on the client side of the installation before switching over to the server process was set to someuser.

You can tell this is a client property by noticing the C in the Property (C) notation.

The following is an example line found in a verbose log file of a property and its value at the end of the server part of the installation just before the installation terminated.

        Property(S): USERNAME = someuser

This line shows the value of the USERNAME property on the server side of the installation was set to someuser.

You can tell this is a server property by noticing the S in the Property (S) notation.

Please note that the USERNAME property in this case has the same value on both the client and server side, however this may not always be the case for all properties as some properties may change on the server side due to custom actions changing the property.

The server process performs the actual installation functions such as copying files, writing to the registry, etc.  Most actions appear in two forms in a verbose log file.

The first form is to add it to the installation script that will be ran later on in the installation.

    MSI (s) (24:24): Doing action: RegisterTypeLibraries

    Action start 13:02:32: RegisterTypeLibraries.

    GenerateScript: Registering type libraries

    Action ended 13:02:32: RegisterTypeLibraries. Return value 1.

The second form is the actual execution of the action:

        MSI (s) (24:24): Executing op: ActionStart(Name=RegisterTypeLibraries,Description=Registering type libraries,Template=LibID: )

        Action 13:04:42: RegisterTypeLibraries. Registering type libraries

Bootstrapper Logs

Install Shield has a method for creating a log file for the Setup.exe and Update.exe bootstrappers. You can simply use the /debuglog parameter from the command line when you run Setup.exe. This command line parameter can be used with the Setup launcher for Basic MSI, Install Script MSI, and Web projects.

Here it is:

          Setup.exe /debuglog

You will notice that a file called InstallShield.log has been created in the same folder as Setup.exe.

What you must remember here is that, this is only the log file for the Setup.exe bootstrapper. At least that is what it seems. When you look at this log file, you see that it doesn’t contain the detailed information available when compared to the log file created as a result of placing the value in the registry, which was outlined in the previous movie.

There is one more thing to know about the /debuglog command line parameter. You can also specify the full path to the log file, so it could be created in an entirely different location from Setup.exe. This is useful if Setup.exe is on a CD-ROM, or any other unwrittable location. Here is an example of that:

          Setup.exe /debuglog”C:\SetupLogFile.txt”

EVENT LOGING

The event-logging service stores events from various sources in a single collection called an event log.

The installer also writes entries into the event log. These record events such as following:

                Success or failure of the installation.

                Errors during product configuration.

                Detection of corrupted configuration data.

Message ID=Error + 10,000.

Ex: Error number in the Error table for an installation completed successfully is 1707

The successful installation is logged in the Application Event Log with a message ID of 11707 (1707 + 10,000).

10005-The installer has encountered an unexpected error installing this package.

11707 - Installation operation completed successfully.

11708 - Installation operation failed

11728- Configuration completed successfully

Thank you for reading !

WindowsInstaller Update/Upgrade/Patch - Application Packaging Concepts

What is an upgrade?

In simple words upgrade is a new version of a software is designed to replace an older version of the same product.

In addition, the installation routines for upgrades often check to make sure that an older version is already installed on your computer; if not, you cannot install the upgrade.

Windows Installer supports three types of product upgrades: major upgrades, minor upgrades, and small updates

MSI Properties responsible for Upgrade are:

·         Product Code

·         Package Code

·         Product Version

Product Code

Windows Installer property that contains the GUID of a product.

Windows Installer treats two products with different Product Code GUIDs as unrelated, even if the values for the Product Name Property are the same.

Package Code

The package code identifies a particular database therefore EVERY MSI build have different package code.

Product Version

Windows Installer property that contains the product version & uses only the first three fields of the Product Version property for version comparisons.

For example, for a product version of 1.2.3.4, the 4 is ignored.

Upgrade Code

Windows Installer property that contains a GUID representing the product family.

The Upgrade Code is primarily used for supporting major upgrades, we may never need to change the Upgrade Code

The Upgrade Code should be consistent across different versions and languages of a family of related products for patching purposes.

For any type of upgrade, we can change various combinations of the package code, product version, and product code to identify the product being installed. The following table identifies when each code should be changed for different types of upgrades.

The following table indicates the change in property as per the Update/Upgrade type:

Upgrade Type	Package Code	Product Version	Product Code	Upgrade Code
Small Update	Yes	No	No	Never Change
Minor Upgrade	Yes	Yes	No	Never Change
Major Upgrade	Yes	Yes	Yes	Never Change

Types of Upgrade

1. Small Updates

A small update is also commonly referred to as a quick fix engineering (QFE) update and does not permit reorganization of the feature-component tree.

A typical small update changes only one or two files or a registry key. Because a small update changes the information in the .msi file, the installation package code must be changed. The package code is stored in the Revision Number Summary property of the Summary Information Stream.

The product code is never changed with a small update, so all of the changes introduced by a small update have to be consistent with the guidelines described in Changing the Product Code. An update requires a major upgrade to change the Product Code. If it is necessary to differentiate between products without changing the product code, use a minor upgrade.

In Small update:

·         An update to one or two files that is too small to warrant changing the Product      Version.

·         The package code GUID does change.

·         Can be shipped as a full installation package or as a patch package.

·         No change in Product Code and Product Version.

2. Minor update

A minor upgrade is an update that makes changes to many resources and can be used to add new features and components but cannot reorganize the feature-component tree.

Can be shipped as a full installation package or as a patch package.

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

In Minor update:

·         No change in Product Code

Command line for small and minor update

Msiexec /fvomus [path to updated .msi file]                       OR

Msiexec /I [path to updated .msi file] REINSTALL=ALL     REINSTALLMODE=vomus                             OR

Msiexec /I [path to updated .msi file] REINSTALL= F1, F2               REINSTALLMODE=vomus

The REINSTALLMODE property is a string that contains letters specifying the type of reinstall to perform.

Code	Option
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. This flag only repairs files that have msidbFileAttributesChecksum in the Attributes column of file table.
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 HKEY_CURRENT_USER Or HKEY_USERS registry hive.
m	Rewrite all required registry entries from the Registry table that go to the HKEY_LOCAL_MACHINE 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.

3. Major update

A major upgrade is a comprehensive update of a product that needs a change of the Product Code Property

During major upgrades following actions detect, migrate, and remove previous versions of the product.

·         FindRelatedProducts

·         MigrateFeatureStates

·         RemoveExistingProducts

The FindRelatedProducts action searches for products using criteria based upon the Upgrade Code, Product Language, and Product Version. These criteria are specified in the Upgrade table.

How to start working on Major Updates

Steps to Create Major Upgrade with InstallShild

Major upgrade generally uninstalls the earlier version and installs a new version

Step1: change version

Go to General Information->Product Properties->Version Field->Update the new version (Ex 1.0 to 2.0)

Step2: change Product Code

Go to General Information->Product code->Generate GUID

Step3: change Package Code

Go to Summery information->Package code->Generate GUID

Step 4: Upgrade View

Go to Media->Upgrade->Add automatic Upgrade Items->Add major Upgrade Item->Name it

We can do several configuration as per the need in this section

(Default Setting Style Complete Uninstall and Install)

This step adds an entry in UPGRADE Table which can be edited later and discussed further.

Step 5:

Make the new configuration/changes in project.

Step 6:

Build/save the project.

NOTE: Before installing major upgrade earlier version must be present on target build.

UPGRADE Table

The Upgrade table contains the columns shown in the following table.

Columns of Upgrade Table are as follows

Upgrade Code

The Upgrade Code property in this column specifies the upgrade code of the products that are to be detected by the FindRelatedProducts action.

VersionMin

Lower boundary of the range of product versions detected by FindRelatedProducts.

If VersionMin equals an empty string ("") it is evaluated the same as 0.

If VersionMin is null, FindRelatedProducts detects all previous versions.

VersionMin and VersionMax must not both be null.

Note that Windows Installer uses only the first three fields of the product version. If you include a fourth field in your product version, the installer ignores the fourth field.

Language

The set of languages detected by FindRelatedProducts.

Enter a list of numeric language identifiers (LANGID) separated by commas.

If Language is null or an empty string (""), FindRelatedProducts detects all languages.

Remove

The installer sets the REMOVE property to features specified in this column.

The Formatted string entered in this field must evaluate to a comma-delimited list of feature names.

For example: [Feature1], [Feature2], [Feature3].

No features are removed if the field contains formatted text that evaluates to an empty string ("").

The installer sets REMOVE=ALL only if the Remove field is empty.

Action Property

When the FindRelatedProducts action detects a related product installed on the system, it appends the product code to the property specified in this field.

The property specified in this column must be a public property and the package author must add the property to the SecureCustomProperties property.

Each row in the Upgrade table must have a unique Action Property value.

Attributes

This column contains bit flags specifying attributes of the Upgrade table.

Custom Action Responsible for Upgrade

1. FindRelatedProducts.

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.

When FindRelatedProducts detects a correspondence between the upgrade information and an installed product, it appends the product code to the property specified in the Action Property column of the Upgrade Table.

2. MigrateFeatureStates. 

This action is used during upgrading and when installing a new application over a related application.

MigrateFeatureStates reads the feature states in the existing application and then sets these feature states in the pending installation.

The method is only useful when the new feature tree has not greatly changed from the original.

MigrateFeatureStates action runs through each record of the Upgrade table in sequence and compares the upgrade code, product version, and language in each row to all products installed on the system.

If MigrateFeatureStates action detects a correspondence, and if the msidbUpgradeAttributesMigrateFeatures bit flag is set in the Attributes column of the Upgrade table, the installer queries the existing feature states for the product and sets these states for the same features in the new application.

3. RemoveExistingProducts.

This action goes through the product codes listed in the Action Property column of the Upgrade table and removes the products in sequence by invoking nested installations.

If the Remove field in Upgrade Table is blank, its value defaults to ALL and the installer removes the entire product.

NOTE:

The product code must be changed if any of the following are true for the update:

·         Coexisting installations of both original and updated products on the same system must be possible.

·         The name of the .msi file has been changed.

·         The component code of an existing component has changed.

·         A component is 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.

Some common scenarios which help us to decide which type of update/upgrade is to be used during packaging

Refer below table

Requirement for the Upgrade	Use a Major Upgrade?	Use a Minor Upgrade?	Use a Small Update?	Notes
Change the name of the .msi package	Yes	No	No	The default file name is taken from the Product Name property, provided the .msi file is not compressed in a Setup.exe installation launcher.
Enable end users to install earlier versions and the latest version on the same machine	Yes	No	No
Add a new sub feature	Yes	In some cases	In some cases	If the new sub feature consists of new components only, you can use a small update, a minor upgrade, or a major upgrade. If the new sub feature consists of existing components, you must use a major upgrade.
Move or delete a feature in the product tree	Yes	No	No
Add a new component to a new feature	Yes	Yes	Yes
Add a new component to an existing feature	Yes	Yes, if the version of Windows Installer is 2.0 or later	Yes, if the version of Windows Installer is 2.0 or later	Windows Installer 1.x requires new components in an upgrade package to be placed in new features for minor upgrades and small updates; it also requires special command-line handling.
Move or delete a component in the product tree	Yes	No	No
Change the component code of an existing component	Yes	No	No
Change the key file of a component	Yes	No	No
Add, remove, or modify any of the following: files, registry keys, or shortcuts	Yes	Yes	Yes	If the file, registry key, or shortcut is in more than one component and the component is shared by two or more features, a major upgrade must be used.

Determining the Best Packaging Option for Our Upgrade

Solution includes a table that we can review to determine what type of packing option we should use to update an earlier version of our product.

In some cases, a standard patch or a Quick Patch may be seem to be the ideal mechanism for packaging our upgrade. However, under certain conditions, we should package our upgrade as a full installation instead of a patch.

For example, if the target image was created with Windows Installer 1.2 or earlier, and the upgraded image is created with Windows Installer 2.0 or later, we should package our upgrade as a full installation, but not as a patch.

Creating patches for packages that span this schema inflection point can be problematic.

If we want our upgrade to move one or more files on the target system from one location to another, we should package our upgrade as a full installation, but not as a patch. If our end users install a patch for an upgrade that moves files on the target system, problems may occur.

For example, the patch may not work, a repair to the target system may not work, a subsequent patch may not work, or end users may not be able to uninstall the product. As a workaround, we can create our patch so that it deletes the files in the old location and adds the files to the new location.

If we want to change our installation from compressed to uncompressed, or vice versa, we should package our upgrade as a full installation, but not as a patch. If we use a patch in this scenario, a repair to the target system may not work, a subsequent patch may not work, or the end user may not be able to uninstall the product.

If we need to move files from one .cab file to another, or if we need to change the order of files in a .cab file, we should package our upgrade as a full installation, but not as a patch.

If our original installation had more than 32,767 files but our latest installation has fewer than 32,767 files, a patch will fail. Similarly, if our original installation had fewer than 32,767 files but our latest installation has more than 32,767 files, a patch will fail. In either case, we should package our upgrade as a full installation.

Note that if both the original installation and the latest installation have more than 32,767 (or both have fewer than 32,767 files), we can package our upgrade as a patch.

Patches cannot be created for major upgrades of InstallScript MSI projects. Therefore, if we need to distribute a major upgrade for an InstallScript MSI project, we should package it as a full installation.

PATCH

A Windows Installer patch (.msp file) is a file used to deliver updates to Windows Installer applications. The patch is a self-contained package that contains all the information required to update the application.

The patch file will contain only the bits that are different between two application files as opposed to copying over the complete file itself. When the patch is applied to the earlier application file, it is turned into the newer application file, changing out those bits that are different between the two files. The major advantage of using a patch file over re-installing a full setup program is that the patch file is very small.

Command line for patch

Installation:

        1) Already installed product:

                Msiexec /p <PatchName.msp> /qb        

        2) By Admin Image:

               a) Create admin image:

                Msiexec /a <MSIname.msi> TARGETDIR="c:\TEMP\MSI"

                b) Apply patch to admin image which was created in above step:

Msiexec /a "Path of admin image msi <MSIName.msi>" /p "Path and name of msp file<MSPName.msp>"

Uninstallation:

Msiexec /I PRODUCTCODE MSIPATCHREMOVE=PATCHCODE /qb              OR

Msiexec /package PRODUCTCODE /uninstall Patch CODE /qb

Multiple Patch Installation:

                Msiexec /I <MSIName>.msi Patch= Patch1.msp;Patch2.msp /qb

Multiple patches can be applied to a product in a constant order, regardless of the order that the patches are provided to the system.

Windows Installer 2.0:  Not supported. Windows Installer versions earlier than 3.0 install patches in order that they are provided to the system.

Windows Installer 3.0 and later:  The installer can use the information provided in the MsiPatchSequence table to determine which patches are applicable to the Windows Installer package and in which order the patches should be applied.

When the patch package does not have an MsiPatchSequence table, the installer always applies the patches in the order that they are provided to the system.

A Windows Installer package can install NO more than 127 patches when installing or updating an application.

Patch Sequence Table view

Patch Family	Product Code	Sequence	Attributes
AppPatch	{18A9233C-0B34-4127-A966-C257386270BC}	1.1.0

PATCH VS SMALL Upgrade

Patches enable us to distribute just the bits and portions of the database necessary to update our application’s files to a specific version, possibly resulting in a much smaller package than an upgrade packaged as a full installation. This enables us to deploy our upgrades using much less bandwidth than that required to deploy a full-installation package.

NOTE:

A patch is not a type of upgrade. Patching is simply a mechanism for distributing a major upgrade, a minor upgrade, or a small update with a small footprint. In fact, creating a patch involves first designing the upgrade and then packaging it as a patch. Before we create a patch, it is recommended that we test the upgrade as a full-installation package.

Thank you!