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.

AppV Client Logging

The App-V client logs information to both the Windows Event log and to a local log file.   Both of these logging options can be adjusted to change the type of information that is captured.   The local file based log can only be accessed by a local administrator of the machine or the SYSTEM account on the machine.

File Log

The local cache is located in profiles \All Users(Public on Vista)\Application Data\Microsoft\Application Virtualization Client\sftlog.txt.  The settings for this file can be modified using the registry at the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Configuration

Value	Default	Description
LogFileName	CSIDL_COMMON_APPDATA\Microsoft\Application Virtualization Client\	Client log file. Can be modified to change the log file location. You must restart the sftlist service after changing this value.
LogMinSeverity	4, Informational	Controls which messages are written to the log.  The value indicates a threshold of what is logged – everything at and below that value is logged. For example, a value of 0x3 (Warning) indicates that Warnings (0x3), Errors (0x2), and Critical Errors (0x1) are logged. Value Range: 0x0 == None, 0x1 == Critical, 0x2 == Error, 0x3 == Warning, 0x4 == Information (Default), 0x5 == Verbose
LogRolloverCount	4	Defines the number of backup copies that are kept of the log file, sftlog.txt when it is reset.  The valid range is 0-9999.  The default is 4.  A value of 0 means no copies will be kept.
LogMaxSize	256	Defines the size in megabytes that the log file can reach before being reset.  The default size is 256 MB.  When this size is reached, a log reset will be forced on the next write attempt.

System Event Log Level

The system event logging level can be configured using the App-V Client Management Console by right clicking the root node and going to properties.

Managing the event logging that will be recorded can also be modified by using the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\Client\CurrentVersion\Configuration\

This registry value indicates the logging level at which App-V log messages will get written to the NT event log. The value indicates a threshold of what is logged – everything at and below that value is logged. For example, a value of 0x3 (Warning) indicates that Warnings (0x3), Errors (0x2), and Critical Errors (0x1) are logged.

Value	Default	Recommend Management Server Configuration
SystemEventLogLevel	4 (Information)	·         0 == None ·         1 == Critical ·         2 == Error ·         3 == Warning ·         4 == Information ·         5 == Verbose

AppV Per-Package File System Container Volumes

The per-package file system container volumes store changes that are made to packages made by users or system processes.  These changes allow for users and the machine to make setting and configuration changes to the base package, without affecting it.  These changes are stored in several PKG files that are described below.  The files are individual for each package and stored in unique directories that are created by combining the Package Root directory name where the package was installed on the sequencer and the first portion of the package GUID.  An example for Microsoft Office 2007 where the Package Root is OFF2K7.V1 and the package GUID for office is 5C99B562-F61F-4009-AB16-B38E16093AE4 the resulting directory would be OFF2K7.V1-5C99B562-F61F-4009.  Two directories for each package will be created, one for the user’s profile and one for the machine at the following locations:

Windows XP

·         Per-user at:  %USERPROFILE%\Application Data\SoftGrid Client

·         Per-machine at:  All Users\Documents\SoftGrid Client\AppFS Storage

Windows Vista

·         Per-user at: %USERPROFILE%\AppData\Roaming\SoftGrid Client\ and %userprofile%\AppData\Local\SoftGrid Client\

·         Per-machine at:  Public\Documents\SoftGrid Client\AppFS Storage

NOTE:  Due to changes in profiles in Windows Vista a third directory is created for the temporary version of the PKG file while the application is in use.

The following description of the files describes how data is populated into these files and will be covered in further detail in a Package and Data Management section of this document.

User Location

The usrvol_sftfs_v1.pkg file contains user-specific files that are modified or new files that are created by any user process in the virtual environment.  This volume also contains the virtual environment configuration as modified by the user.

System Locations

UsrVol_sftfs_v1.pkg contains new or modified user-specific data from a system process that is not associated with a specific user context but is associated with a specific package.

GlblVol_sftfs_v1_<SID>.pkgcontains application-specific files that are modified by any user process in the virtual environment.  The SID of the user is appended to the volume name to uniquely identify it.

GlblVol_sftfs_v1_S-1-5-20.pkg contains any application-specific data that is modified by a system process.  The well-known SID for system is appended to the volume.  In SoftGrid 4.0 and 4.1, this volume was used for all modified application data; in 4.2 and 4.5 modifications are separated into those made by system processes such as the Listener, and those made by user application processes.  User modifications go instead to the Application Data Isolation Volume.  The global package volume also contains the virtual environment configuration for system processes.

Will packages created in App-V 4.x work on App-V 5.0?

No. Packages have to be converted into the new format.

Disadvantages of PerUser installation

There are several common scenarios that an arise when the choice of “Per-User” versus “Per-Machine” is given to the user:

1. Major Upgrades can Fail
   If you use the Upgrade code feature of Windows Installer to perform a major upgrade the detection of the existing software will fail if: (a) the original software was installed with ALLUSERS=”" and the new software has ALLUSERS=1 in its Property table or passed on the command line or (b) the original software was installed with ALLUSERS=1 and the new software has ALLUSERS=”" or ALLUSERS is not defined in the Property table or on the command line.
2. Uninstall Problems
   If two different users on the system install the software with ALLUSERS=”" they will both have their own shortcuts and Add/Remove Programs entries made (which is fine and is by design). However, if some of the files are installed to a shared location (such as ProgramFilesFolder) and one of the users uninstalls the software, the other user will not be able to use the software even though their shortcuts and Add/Remove Programs entries are still intact. In other words, the two installed instances of the software will not “know” about each other.
3. Support Issues

• Installing to locations the user has the ability to alter might reduce the confidence the package producer has for the integrity of the install. This can affect support costs as well as computational correctness under a regulatory environment (lawyers, accounts, food and drug companies, government agencies, etc)
• Multiple instances of an install means there is duplicate copies of binaries on the machine which wastes disk space. A “Per-Machine” install creates a single copy of common binaries for all users thus saving space.
• Software is less secure because updating behavior has to be done for each user on the machine. In other words, the occasional user on the machine can made the machine vulnerable because they are not on the machine often enough to keep the software they use up to date.
• IT departments want programs in locations users can’t tamper with. User tampering is a major source of support costs.
• Centralized install, servicing, and uninstall from a central IT department are all more challenging when the apps are just in the users profile. There are numerous conditions where it is known not to work at all