First Time Self Healing

If the package is containing some HKCU entries then the package will always go for self healing for the first time. This happens because the HKCU keys are only installed for the current user present while installing the package and not all the users as it is the property of the HKCU. So, if other user logs
in then 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 is called the Self Healing.

ARP related Properties in MSI

Add/Remove Programs related MSI Properties

Property name	Brief description of property
ARPAUTHORIZEDCDFPREFIX	URL of the update channel for the application. The value the installer writes under the Uninstall Registry Key.
ARPCOMMENTS	Provides Comments for the Add/Remove Programs in the Control Panel. The value the installer writes under the Uninstall Registry Key.
ARPCONTACT	Provides the Contact for Add/Remove Programs in the Control Panel. The value the installer writes under the Uninstall Registry Key.
ARPINSTALLLOCATION	Fully qualified path to the application's primary folder. The value the installer writes under the Uninstall Registry Key.
ARPHELPLINK	Internet address, or URL, for technical support. The value the installer writes under the Uninstall Registry Key.
ARPHELPTELEPHONE	Technical support phone numbers. The value the installer writes under the Uninstall Registry Key.
ARPNOMODIFY	Prevents display of a Change button for the product in Add/Remove Programs in the Control Panel. Note   This only affects the display in the ARP. The Windows Installer is still capable of repairing, installing-on-demand, and uninstalling applications through a command line or the programming interface. Windows NT 4.0 and Windows 98/95:  Clicking on Add/Remove for the product uninstalls the product after prompting the user to confirm the uninstallation.
ARPNOREMOVE	Prevents display of a Remove button for the product in the Add/Remove Programs in the Control Panel. The product can still be removed by selecting the Change button if the installation package has been authored with a user interface that provides product removal as an option. Note   This only affects the display in the ARP. The Windows Installer is still capable of repairing, installing-on-demand, and uninstalling applications through a command line or the programming interface. Windows NT 4.0 and Windows 98/95:   This property prevents display of the application in the Programs List of the Add/Remove Programs in the Control Panel.
ARPNOREPAIR	Disables the Repair button in the Add/Remove Programs in the Control Panel. Note   This only affects the display in the ARP. The Windows Installer is still capable of repairing, installing-on-demand, and uninstalling applications through a command line or the programming interface.
ARPPRODUCTICON	Identifies the icon displayed in Add/Remove Programs. If this property is not defined, Add/Remove Programs specifies the display icon.
ARPREADME	Provides the ReadMe for Add/Remove Programs in Control Panel. The value the installer writes under the Uninstall Registry Key.
ARPSIZE	Estimated size of the application in kilobytes.
ARPSYSTEMCOMPONENT	Prevents display of the application in the Programs List of the Add/Remove Programs in the Control Panel. Note   This only affects the display in the ARP. The Windows Installer is still capable of repairing, installing-on-demand, and uninstalling applications through a command line or the programming interface. Windows NT 4.0 and Windows 98/95:  This property has no effect.
ARPURLINFOABOUT	URL for application's home page. The value the installer writes under the Uninstall Registry Key.
ARPURLUPDATEINFO	URL for application updates information. The value the installer writes under the Uninstall Registry Key.

How to hide Drives in My Computer?

Create registry as described below:


HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
Name: NoDrives
Data Type: REG_DWORD
Value: varies - see below
  
To calculate the value to use, add up the following codes for the drives that you want to hide:
A=1
B=2
C=4
D=8
E=16
F=32   
For instance to hide the E and F drives, the value would be 48

How Should I add my Application to Run at Startup?

If you want to do it for all users on a system, create a entry in following registry hive


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run


If you want to do it for Current User create entry in following registry hive


HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

Process for Creating InstalShield Response file (iss)

Here is an example of how to create the response file:

1.      Download the j2re1_4_0-win.exe installation bundle.

2. Run the JRE installation bundle with the additional flags -a -r -f1"<path><filename.iss>", where path is the path to filename.iss and filename.iss is the name you want to use for your setup.iss file. For example:

j2re1_4_0-win.exe -a -r -f1"C:\setup.iss"

Note that there is no space between -f1 and "<path><filename.iss>"

3. Go through the install dialogs as normal, selecting the options that you want to be used in subsequent silent installs.

InstallShield will record all of your installation choices in your setup.iss file. This response file can be used later for the silent installation.

Here is an example of a response file:

[InstallShield Silent]
Version=v5.00.000
File=Response File
[DlgOrder]
Dlg0=SdLicense-0
Count=2
Dlg1=SdAskDestPath-0
[SdLicense-0]
Result=1
[SdAskDestPath-0]
szDir=C:\Program Files\Java Plug-in 1.4
Result=1
[Application]
Name=Java Plug-in
Version=1.4
Company=JavaSoft

Running InstallShield in Silent Mode

After you have created the response file, you are ready to run the installation in silent mode using InstallShield Silent. When running an installation in silent mode, be aware that no messages are displayed. Instead, you can request creation of a log file, which will record installation information, including if the installation was successful. You can review the log file to determine the result of the installation.
To launch InstallShield Silent, run your j2re1_4_0-win.exe install bundle with the flags -s -a -s -f1"<path><filename.iss>", where path is the path to filename.iss and filename.iss is the name of your setup.iss file. If you want to register Plug-in with Internet Explorer and/or Netscape 6, include the -iexplorer and/or -netscape6 options in the command line. They can be in any order but must come after the -a and before the second -s. For example,

j2re1_4_0-win.exe -s -a -iexplorer -netscape6 -s -f1"<path><filename.iss>"

Note that there is no space between -f1 and <path><filename.iss>.
If you are doing this from an MS-DOS shell, you may find it convenient to use the "start /w" command, as that will cause MS-DOS to wait until the install is complete. For example:

start /w j2re1_4_0-win.exe -s -a -s -f1"C:\setup.iss"

Creating a Log File

If you want to create a log file describing the installation, use the additional flag -f2"<path><filename.log>". This will cause the log to be written to the filename.log file. For example:

start /w j2re1_4_0-win.exe -s -a -s -f1"C:\setup.iss" -f2"C:\setup.log"

Note that there should be no space between -f2 and "<path><filename.log>"
To verify if a silent installation succeeded, look at the ResultCode value in the [ResponseResult] section of setup.log. InstallShield writes an appropriate return value after the ResultCode keyname. 

How to make an MSI unattended by default

By default, when you double-click on an MSI file it prompts you to click Next until you finish installing the application. You can run the MSI unattended from the command line using the /QN switch but that requires typing. What if you need/want to be able to double-click on the MSI file and have it run the MSI unattended? 

Here's how:

-Go to the Setup Editor view:

-Click the Dialogs tab and un-select the following:

-Install Dialogs -> Welcome Dialog Wizard

-Install Dialogs -> Exit Dialog

-Maintenance Dialogs -> Exit Dialog

how to get MSI property value from within a deferred custom action

Background

A Basic MSI installation program does not use an explicit script to drive the installation, but instead uses sequences of actions to determine the dialog boxes and operations the installation program should display and perform. In this sense, MSI actions are analogous to function calls in a typical programming language.

There are two sequences used by a typical installation program: the User Interface sequence and the Execute sequence. The User Interface sequence displays dialog boxes and queries the target system, but does not make any system changes. The Execute sequence performs system changes, but does not display a user interface.

Analogous to variables in a programming language are Windows Installer properties. Windows Installer defines dozens of predefined properties, and an installation author can define custom properties to store any extra data needed at run time. A property can, for example, be set by the user in a dialog box, and then later be written to the registry.

Property names are case sensitive. Two classes of MSI properties are public properties, which have names containing only uppercase letters (examples are USERNAME and INSTALLDIR); and private properties, whose names contain at least one lowercase letter (as in AdminUser and ProgramFilesFolder). The values of public properties can be set at the command line, and their values are preserved when execution switches from the User Interface sequence to the Execute sequence. Private properties, on the other hand, cannot have their values set at the command line, and are reset to their default values when execution switches from the User Interface sequence to the Execute sequence.

During installation, the Execute sequence runs in two stages, immediate mode and deferred mode. Immediate mode walks through the actions in the Execute sequence, generating an internal, hidden installation script; this script contains, for example, instructions for what files, registry data, shortcuts, and so forth, to install. Immediate mode does not touch the target system. Note that the User Interface sequence runs only in immediate mode.

The second stage of the Execute sequence, deferred mode, carries out the system changes described by this internal installation script. (Strictly speaking, deferred mode is performed only for actions between the built-in actions InstallInitialize and InstallFinalize.) During deferred execution, MSI property values are fixed and cannot be changed. Moreover, the values of only a handful of MSI properties can explicitly be read during deferred execution.

Getting Property Values in Custom Actions

When you need to extend the behavior of an installation program, you can write one or more custom actions. MSI supports custom actions that launch executables, set MSI property values, and call various types of DLL and script functions.

During immediate execution, a VBScript custom action can read the value of an MSI property using the Property property of the Session object. For example:

' get a property value during immediate mode
MsgBox "Right now, USERNAME is: " & Session.Property("USERNAME")

Similarly, a C or C++ DLL or an InstallScript custom action can call the MsiGetProperty API function to read the value of a property.

As mentioned above, however, getting the value of an MSI property during deferred execution is somewhat more difficult, as deferred actions have access to only a very few built-in properties: ProductCode, UserSID, and CustomActionData. (Note that this statement is untrue for built-in types of actions that use property values as arguments. For example, a deferred launch-an-EXE action that uses "[INSTALLDIR]Readme.txt" as its argument will have the INSTALLDIR property resolved during immediate mode and fixed during deferred mode. It is only custom actions that explicitly read a property value using Session.Property or MsiGetProperty that need to use the technique described here.)

It is this last property, CustomActionData, that is used to read a property value in a script during deferred mode. For an example, suppose you have a deferred VBScript custom action called "ReadPropDeferred", in which you want to read the value of the USERNAME property. The steps involved in populating this property are the following:

1. Create an immediate-mode set-a-property custom action that sets a property called ReadPropDeferred to the value of the USERNAME property. That is, in the Custom Actions view, create a set-a-property action with property nameReadPropDeferred and value [USERNAME], and schedule the action somewhere before the ReadPropDeferred action. The main idea is that the property name here is the same as your deferred action name.
   
2. In the deferred VBScript code of the ReadPropDeferred action, use Session.Property("CustomActionData") to read the desired value:
   
   ' get property value during deferred mode
   MsgBox "Right now, USERNAME is: " & Session.Property("CustomActionData")

At run time, the immediate action that sets the ReadPropDeferred property populates CustomActionData for that specific deferred action; and the deferred ReadPropDeferred action reads CustomActionData (instead of USERNAME) to determine the desired data. Of course, this same technique can be used with DLL custom actions that use MsiGetProperty to read property values.

As mentioned above, during deferred execution the installation script is fixed, and therefore property values cannot be set from within a deferred custom action.