Friday 22 June 2012
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. - Run the JRE installation
bundle with the additional flags
-a -r -f1"<path><filename.iss>
", wherepath
is the path tofilename.iss
andfilename.iss
is the name you want to use for yoursetup.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>"
- 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
Here is an example of a response file: setup.iss file
. This
response file can be used later for the silent installation. [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>"
-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
"
-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:
- 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.
- 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.
Thursday 21 June 2012
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.
Subscribe to:
Posts (Atom)