Académique Documents
Professionnel Documents
Culture Documents
4. What are the Different types of Privileges during the installations can be
given?
Locked-down
o The users doesn’t have the full admin rights to install the application
o The users doesn’t have WRITE-ACCESS to the Program Files folder of
their computers or to the HKEY_LOCAL_MACHINE registry location
o Installation can be done in this environment by the approval of the
Administrator by means of GPO or Active directories, the administrator
can assign or publish the application.
Elevated rights
Administrative Rights
The AdminUser property is set when the user performing the installation is an
administrator; the Privileged property is set when the user is allowed to install
with elevated privileges. A user can install with elevated privileges if the user is
an administrator, both the per-user and per-machine AlwaysInstallElevated
policies are set or the application has been assigned by the system administrator.
If the user is an administrator, then both the AdminUser and Privileged properties
are set. If the user is not an administrator, then AdminUser is never set. In that
case, privileged is only set if the user has been given permission by the
administrator through assignment or policy to install the application as elevated.
A user with user-level privileges can install managed applications if the system
administrator has enabled the installation. Otherwise, the user will only be able to
install MSI applications provided the user has permission to write files, create
directories, and write registry keys in the locations where the installation typically
writes those resources. If the user cannot write to a location, then the installer will
only be able to write to that location if the administrator has given permission for
the installer to do so.
8. What are the differences between Execute Deferred and Execute Immediate?
File associations are a type of advertising and are stored in the registry.
Example:
If your application uses special file extensions, you might want to register them so
that the application gets started when the file gets double clicked, and that there is
an icon associated with the file. There are special tables for this in the msi
structure (Extension and ProgId) their contents are also used for advertising. In
Wise 3.5 there is even a GUI for editing the Contents of the Extensions table. No
GUI though for the ProgId table which sets up icons for file extensions.
You can also make your own registry entries to create application to file extension
relations. The example shows how to register the .dvi extensions to be opened
with the yap.exe program.
Key: HKLM\SOFTWARE\Classes\.dvi
Key: HKLM\SOFTWARE\Classes\DVI.Document
Key: HKLM\SOFTWARE\Classes\DVI.Document\shell\open\command
13. Determine all the values of the ALLUSERS property set in the MSI file?
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. You can ensure the ALLUSERS property has not been set by setting its
value to an empty string (""), ALLUSERS="".
The best practice is to set the ALLUSER property =1 because if the application
is to be installed to per machine and a user without admin access try to install
that it will prompt an error but in the other cases it will be a peruser installation
without any prompts.
Default Value: If ALLUSERS is not set, the installer does a per-user installation.
Remarks
It is strongly recommended that developers do not author packages that set the
ALLUSERS property using a dialog or custom action on Windows 95 or
Windows 98. An upgrade may fail on Windows 95/98 if the ALLUSERS property
is set using a dialog or a custom action. On Windows 95/98, the installer ignores
any attempt to set ALLUSERS by either the command line or by the
SNAPSHOT SMARTMON
ITOR
It records all the changes which happen after and before It monitors and
installation and put in the Repackaged File records the
installation
operations as
they happen
u…………………………………………………………… SMARTMONI
…..lkoiu8ikokl876uiol/jhu80-[jhlku= TOR captures
.n0=] all the
,mnjh/.lkju8 changes,
Replacing files
even if they
are the same
size,
modification
date, and
version.
,Setting or
deleting a
registry value,
creating or
deleting a
registry
key.
,Overwriting
existing
registry keys
with the same
value
INI file Handling: If it is Windows Directory, changes to it INI file
are recorded as an .INI file change Handling:
Can add as INI
Outside windows Directory: the entire .INI file is added file entry
instead of just editing the file irrespective of
the location
It takes more time as it requires scanning of the computer Since it is a
states after and before installation monitoring
process it takes
less time in
comparison
with
Snapshot.
It cannot
monitors the
application
designed for
Windows -16
Bit
FEATURE COMPONENT
A part of the applications total Basic building Block of a MSI
functionality that a user may decide to which is a collection of Files,
INSTALL independently. registries, Advertising info..etc..
It doesn’t have a unique GUID It has a unique COMPONENET
GUID
Examples:SPELL Checker, Shared piece of code, DAO, MFC,
Thesaurus, CLIP ART COM objects
Windows Installer does not install the necessary components until a user or
application attempts to activate the advertised program. This concept is called
install-on-demand.
A transform is a .mst FILE which encapsulates all the changes to a base msi and hence it
enables to maintain a SINGLE installation FILE and changes separately in the
TRANSFORM file
24) What are the ways to make the changes in an MSI during installation?
25) What is the command line option for applying two or more TRANSOFMS to a
Single MSI?
26) What are the reasons for self healing in an Application? An Application Keeps
on Reinstalling every time you click the shortcut. How to resolve.
.Go to eventviewer and check for Component ID. It may be missing or some error related
to that....fix it. Other options are….
PUBLIC PROPERTY:
OR TRANSFORM
PRIVATE PROPERTY:
3) These are used internally by the installer and their values must be entered into
the database by the author of the installation package or set by the installer during
the installation to values determined by the operating environment.
REQUIRED PROPERTIES:
There are certain conditions where SystemAdmin can exert control over the
PUBLIC properties so that a user with an elevated privileges can’t modify or access
them so as to maintain secure systems these properties are know as Restricted
PUBLIC PROPETIES
28) What changes (PROPERTIES) u will make to ensure that a particular feature
should be installed in the system during installation?
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 you set the REINSTALL property, you must also set the
REINSTALLMODE property, to indicate the type of
reinstall you want. When the REINSTALLMODE property is
not set, all files currently installed are reinstalled, but only if
the file on the computer is an earlier version or is not present.
By default, no registry entries are rewritten if REINSTALL is
set to ALL, only features already installed are reinstalled
Thus, if REINSTALL is set for a product that is yet to be
installed, no installation takes place. REINSTALL is a vital
property for performing such important tasks such as patching
and upgrading software
REBOOT Suppresses certain prompts for a restart of the system
Force: Always prompt for a computer restart at the end of the
installation. The UI prompts the user to restart at the end. If
there is no user interface, the system restarts at the end of the
installation
Internal consistency evaluators, also called ICEs, are custom actions written in
VBScript, Script, or as a DLL or EXE. When these custom actions are executed, they
scan the database for entries in database records and check the MICROSOFT
STANDARDS and indirectly predict the application stability in an MICROSOFT
ENVIRONMENT
31) What is LaunchConditions Action and How will you check whether an
operating system is an WINDOWS XP or not before installing the application ?
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.
Both MST and MSP are used to make changes in MSI package But main differences
between both of them
MST MSP
1) This is a File which contains the changes 1) It is basically the FILE from which
in a BASE MSI changes to an already installed application is
done
UPDATE UGRADE
1) This is a minor enhancement or BUG in 1) IT is removing the older application
a SOFTWARE which can make few completely and installing a NEW one
changes of FILES or Registries
2) The Overall functionality of the 2) The functionality is modified and New
application remains almost the same features may be added and higher File
except few changes versions are generally added to the
application
3) Hot Fixes, new Driver application 3) Wise package studio 5.0 and Wise
related to printers are examples of updates package studio 6.0 are the examples of
upgrades
A small update or a minor upgrade can affect applications in the following ways:
• Enlarge or reduce the feature component tree, without reorganizing the existing
hierarchy of features and components described in the table of feature
components.
• Add a new feature to the existing feature component tree.
• Remove a parent feature, including all the child features of each parent feature.
• Add a new component if the component is associated with a new feature.
• Change the tables, custom actions, and dialogs in the .msi file without changing
the file name. (Renaming the *.msi modifies the package, which also changes the
package code.)
• Add, modify, or remove files, registry keys, or shortcuts for components that are
not shared among features.
• Follow the components rules: Dont mix user and machine specific entries in a
single component. Ensure that only one .exe exists in each component. Ensure
that components are UNIQUE i.e. dont have a .dll that exists in more than one
component.
• Dont use Custom Actions to make any critical system changes. Anything done
in a custom action doesnt have any rollback capability, so if your install goes 'pear
shaped' you cant roll back changes made during a custom action.
• Generate Merge Modules (MSM's), for any common components, and use the
Merge Module in any application that requires the component. Try to source and
use commercially produced Merge Modules if you can. If you can't (and you wont
be able to for most things...) then produce your own....
• Ensure that all user specific parts of the install i.e. all HKEY_CURRENT
_USER registry entries, are contained in a separate component. When a new
user logs into a machine, the self-heal functionality of MSI will detect a missing
component in the users profile, and will populate the users registy with the
settings for the application in question
• Ensure that any INI file changes are recorded in the INI file table, rather than
just as files in the file table. This will ensure that INI files are edited if they exist
already, rather than replaced with the version within the MSI Package
• Make custom configuration changes using Transforms (MST's), rather than by
editing the MSI itself. This will make it easier to produce 'generic' packages that
can be modified for several environments.
• Set the Property ALLUSERS = 1 in the property table. This will force the
application to install for all users, if installed under an Admin account, and to
Current User, if using a non-admin account...
• Set the Property ROOTDRIVE = C:\ in the property table - This will force
applications to install to drive C:\. Otherwise, if you have more than one drive in
the target machine, MSI will look for the one with most free space. this means
you cant always guarantee when your applications will install to.
• Be sure to generate a new Product ID for each application - otherwise you will
encounter installation problems when trying to install more than on MSI
application on a single machine.
• Set the property REBOOT = Force in the property table to force a reboot at the
end of the installation - if one is required.
• In the registry table, anything enclosed in square brackets [ ] is assumed to be an
MSI property, and Windows Installer will attempt to resolve it. Whilst this is
often quite useful, sometime you WANT to have square brackets in a registry
value. To acheive this use the following syntax: [\[[<mystring>[\]]
We can be give the permission to a USER using the following : Using cacls
CACLS filename [/T] [/E] [/C] [/G user: perm] [/R user [...]]
W Write
C Change (write)
F Full control
/R user Revoke specified user's access rights (only valid with /E).
R Read
W Write
C Change (write)
F Full control
36) How do we create images using a ghost image which is for a particular System,
for Eg : for Dell pc, but need to install on different Hardware configuration like
IBM pc or some thing, how do we install the drivers et....
1) Create the perfect XP image on ANY hardware. (We used a Dell Optiplex GX240).
2) Dump the image to the imaging server.
3) Image a different computer using that same image(Dell) even though the target is a
different computer with different HAL driver( We used an IBM 300GL). At this time you
would normally restart the computer and find out there is a different HAL and hard drive
drivers, video drivers and images are not compatible on computers that use a different
hal.
4) Turn on CD-ROM boot capability on your PC if it is not already active.
5) Reboot the computer with your Windows XP PRO CD inside it.
6) At the first prompt when it asks you if you want to repair or new install select new
install.
7) When it detects an XP installation has already occurred, it asks again if you want to
repair it or do a fresh install. CHOSE REPAIR.
The second repair scans the hardware information and recopies the files
ACCORDING TO THE
HARDWARE SCAN not the image that you sent down. All sound, video, HAL, hard
drive, chipset are
copied into the correct place.
8) enter a valid license, and restarting the machine this is what we saw:
Network loaded up perfectly on the first boot with Novell client even though the NIC
card was completely different than the image we put on, Auto Login still worked,
application launcher worked, Client trust and internet worked. Even the user's profiles
were still 100% intact. Everything about the image worked as if it was a perfect clone
including video, sound, USB, everything! . Only a few extra shortcuts were on the start
bar. We are now looking into weather or not we need to reapply Windows XP SP1a and
some other windows updates( I imagine we will). All software that was installed and
configured in the previous image loaded without problems. It was a dream come true and
only took us 40 minutes to complete.
9) check over XP and make sure everything is ok and dump the new image.
We haven't checked all of the registry hacks we had in the original image, but we know
some took fine through the repair.
We are deploying XP by using ghost to clone 600 workstations with 7 different computer
hardware configurations with a clean image. With this method we will only make 1
image, load it to another computer, repair it, then dump it back to the server to load to the
other workstations. It will save us from making 7 separate images from scratch when all
of the workstations need to have the same look, feel, and base software.
If you have a different way of doing this I would love to hear about it. I'm always looking
for better ways of doing things. I tried messing with Hal drives and device drives between
images and never got it running right. This way, it is automatic and nearly 100%
accurate.
Note:
1)
HKLM\SOFTWARE\MICROSOFT\WINDOWSNT\CURRENTVERSION\WINLOGO
N
2) Sysprep is a great tool to reduce the number of images. However, at the time Sysprep
is run, all drivers including INF files must be present on the machine. When the
Sysprep'd image is restored, the Sysprep mini-setup will perform a hardware discovery
and will only discover drivers that were present on the machine when Sysprep was
originally run. This means that as new hardware is purchased or new drivers are required,
the base image must be recreated, drivers added, Sysprep run and every platform using
the base image must be tested.
An application that has been installed using the 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.
Benefits of using 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
• Skip actions associated with specific tables that are unmodified by the patch. This
can significantly reduce the time required to install the patch
• Create and install patches that can be uninstalled singly, and in any order, without
having to uninstall and reinstall the entire application and other patches.
it will not patch an existing installation. It will only update the locally cached copy of
the MSI database. Use this command line instead:
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."
HKEY_USERS Contains all the actively loaded user profiles on the
computer. HKEY_CURRENT_USER is a subkey
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 subkey of
HKEY_LOCAL_MACHINE\Software. The
information 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." Starting with Windows
2000, this information is stored under both the
HKEY_LOCAL_MACHINE and
HKEY_CURRENT_USER keys. The
HKEY_LOCAL_MACHINE\Software\Classes key
contains default settings that can apply to all users
on the local computer. The
HKEY_CURRENT_USER\Software\Classes key
contains settings that override the default settings
and apply only to the interactive user. The
HKEY_CLASSES_ROOT key provides a view of
the registry that merges the information from these
two sources. HKEY_CLASSES_ROOT also
provides this merged view for programs designed
for earlier versions of Windows. To change the
settings for the interactive user, changes must be
made under
HKEY_CURRENT_USER\Software\Classes
instead of under HKEY_CLASSES_ROOT. To
change the default settings, changes must be made
under
HKEY_LOCAL_MACHINE\Software\Classes. If
you write keys to a key under
HKEY_CLASSES_ROOT, the system stores the
information under
HKEY_LOCAL_MACHINE\Software\Classes. If
you write values to a key under
HKEY_CLASSES_ROOT, and the key already
exists under
HKEY_CURRENT_USER\Software\Classes, the
system will store the information there instead of
under
HKEY_LOCAL_MACHINE\Software\Classes.
HKEY_CURRENT_CONFIG Contains information about the hardware profile
that is used by the local computer at system startup
New Request
Technical Review
Application packaging
Quality Analysis
UAT
41) You just need to make some changes to a MSI, you have to save it not compile
it.Which tool will you use?
43) What is dll cache and what is its use and what you mean by WFP (Windows File
Protection) ?
WFP : The windows file protection service is an "invisible" service that is enabled by
default and runs constantly in the background after a successful logon. (It does not load in
safe mode.) . It helps in retaining the Critical files of the system by restoring them when
they are Overwritten or deleted from special folder called dllcache. The location of this
file is:
%SYSTEMROOT%\system32\dllcache .
It is no feasible to replace the protected File through package, currently the only
applications capable of updating WFP files are:
Windows updates
45) How do I create a shortcut that uninstalls my .MSI based application and
include it in my installation?
Create a command line shortcut to uninstall the application and include the the shortcut in
your installation (command Line)
Systemfolder: It is an installer property it set s the path to the system folder For
example, on 32-bit Windows the value may be C:\Windows\System32. On 64-bit
Windows, the value may be C:\Windows\SysWow64
46) How you can detect between an admin installed(Uncompressed msi) MSI and a
compressed one ?
47) What are the file versioning rules for Microsoft installer?
The Windows Installer uses an even more complex algorithm when deciding
Whether to keep an existing file or install a new copy. It takes into account not just
the file dates and the version, but the languages involved as well. Here’s the set of
Highest version wins. All other things being equal, the file with the highest
version number wins, whether that’s the file on the hard drive or the file in the
source media.
Any version is higher than no version at all. If the copy in the source media
Contains version information, and the copy on the hard drive has no version
Information, Windows Installer chooses the one with the version information.
Favor the new language. All other things being equal, if the file being
installed is localized for a different language than the file on the computer, Windows
Installer uses the copy with the language that matches the product being
Installed.
Meet the product’s needs for multiple languages. If both copies support
Multiple languages, Windows Installer ignores the common languages and uses
the copy that supports the most languages out of the set of languages that the
Product uses.
Keep the maximum number of languages. If the copies differ in the number
of languages they support and both support all the languages that the product
needs, Windows Installer keeps the copy that supports the most languages.
either copy, Windows Installer compares the file creation date and the last modification
Date for the file on the computer. If the modification date is later than
the creation date, Windows Installer assumes this file has been customized by
the user and does not overwrite it. Otherwise, it installs a new copy.
Companion files go along with the versioned file. It’s possible to mark a
file within the Installer database that does not include version information as a
companion file to a file that does include version information. In this case, the
companion file is installed if the other file is installed. There is one exception to
this rule, though. If the companion file is not present on the target machine, it’s
48) How will you change the MSI default icon to some other ICON?
Active setup is a process that runs automatically when a user logs in.
Registry keys at
and
are compared, and if the HKCU registry entries don't exist, or the Version number of
HKCU is less than HKLM, then the specified application is executed for the current user.
To implement Active Setup, you need to package your entire user Installation
requirements into an EXE preferably, using SMS Installer, or Wise Installation System
for example, and place the EXE on the client workstation during the main application
installation process.
In addition, populate the following registry key with two ( REG_SZ ) values:
KEY:
VALUE1:
VALUE2:
Version=1
When each new user logs on, the operating system compares Active Setup keys between
HKLM and HKCU, and runs the nominated executable if the HKCU entry is missing or
the version in HKCU is less than HKLM.So if you ever need to update the ActiveSetup
executable, just install a new version, and increment the Version registry key (VALUE2
above) in HKLM. Next time the user logs on, the active setup will run again for that user
51) What are the command line switches are supported in MSI?
/f p,o,e,d,c,a,u,m,s,v
• c - Reinstalls a product when a file is missing or the stored checksum value doesn’t
match the calculated value
• v - This switch forces the installation to ignore the cached MSI package on the machine
and recache the new package being run. This should only be used in an upgrade and not
with a first-time installation.
/l i,w,e,a,r,u,c,m,p,v,+,![log file]
• i - Status messages
• w - Non-fatal warnings
• a - Action startups
• r - Action-specific records
• u - User requests
Parameters
• m - Out-of-memory
• p - Terminal properties
• v - Verbose output
the use of the v option isn''t included. To include the v option, type "/l*v"
/p [patch] Applies a patch. To patch an installed Administrator image, you should also
use the /a switch
/q n,n+,b,b+,b!,r,f
• n = No UI
• b = Basic UI
• r = Reduced UI
• f = Full UI
1. All the information required to install a shared file is delivered to the installer in a
single, standardized .msm file,
2. Eliminate many instances of version clashing, missing registry entries, and improperly
installed files.
3. If shared files are installed from .msm files, the Windows installer can keep a correct
reference list of applications that use those shared files.
4. Windows can better avoid deleting shared resources used by any application until the
last application using them is uninstalled.
There are several files type that can be created for the Windows Installer technology:
A .MSP is a Windows Installer patch file used to distribute small updates of .MSIs.
A .MST is a Windows Installer transform file that makes changes to a pre-existing .MSI.
A .IDT is an Exported Windows Installer database table which can be removed from one
database and imported to another database.
A .CUB is a Validation Module that contains Internal Consistency Evaluators in a
database which in turn evaluates databases.
A .PCP file is a Windows Installer patch creation file that contains the configuration
information that patchwiz.dll requires to create a patch.
The different types of UPGRADES are: small update, Minor upgrade and Major Upgrade
and the following Changes are done during the upgrades
2. Ensure that the UpgradeCode Property value of new package is the same as the
previous versions
Upgrade Code : Same as the previous version . The UpgradeCode property in this
column specifies the upgrade code of all products that are to be detected by the
FindRelatedProducts action.
Version Max: The version of the new package. VersionMax must be a valid product
version as described for the ProductVersion property. 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.
Attributes : This column contains bit flags specifying attributes of the Upgrade table.
Usually 261.To cause uninstall to occur, the msidbUpgradeAttributesOnlyDetect bit in
the Attributes column of the Upgrade table for that product version must be off.
If you want a custom action to run during an uninstallation of the product, but not during
the removal of the product by a major upgrade, use this condition.
REMOVE="ALL" AND NOT UPGRADINGPRODUCTCODE
SelfReg Table
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.
56) How will you register a file without including the SelfReg table entries?
With the help of WiseCom capture tool we can capture the entries and merge the
same in the application
57) Whish File is used BY ORCA Tool to validate the custom actions? HP- question
ICEs are stored in a special file with the same structure as any other Installer database.
By default, this file uses the extension .cub
darice.cub
logo.cub
mergemod.cub, open the .cub file in ORCA and view the details
A .cub file contains only the ICEs and their required tables. A .cub file cannot be
installed and is used only to store and provide access to ICE custom actions.
Orca or the validation tool msival2 uses the Logo.cub, Darice.cub, and
Mergemod.cub files. The set of ICEs in the Logo.cub file is a subset of those in the
Darice.cub file. If your package passes validation using Darice.cub, it will pas
pass with Logo.cub. Mergemod.cub contains a set of ICEs used to validate merge
modules.
The Windows Installer SDK includes 71 standard ICEs, numbered from ICE01
Through ICE73 (for some reason there is no ICE37, and ICE11 appears to be
undocumented and uncalled).
59) What are the ICE errors you have resolved during packaging?
A. 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.)
• None of the components to which these files belong have component GUIDs. (The
value for the component in the ComponentId column of the Component table is NULL).
Components without GUIDs are not managed by Windows Installer.
• If the keypath of the component has a shared DLL refcount, 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 refcount for any one file in the component, then the component
will not be uninstalled.
61) How can u enable the VERBOSE logging file for an USER?
To generate a detailed verbose log file through policy, use the following registry key:
• HKLM\Software\Policies\Microsoft\Windows\Installer
Log files generated through the policy key will be of the form msiXXXXX.log in the
user's %temp% folder.
62) In Which conditions you can update a custom action via a patch?
Yes, you can update a custom action using a patch. If the custom action is included in the
Binary table, then simply update the custom action in the update installation image.
When you generate the patch between the original and update installation images, the
patch will contain a database transform that will transform the old binary data stream to
the new binary data stream
63) How do I create a second transform that includes different files than the original
transform without overwriting the .cab file from the original transform?
Follow these steps to create multiple transforms with different cabinet files:
1. After compiling the first transform, Wise will create a cabinet file with a system-
generated name, such as "WISETRFM_2.cab". Rename the file to a name you specify,
such as "mycab1.cab".
2. In the Setup Editor, select the Tables tab, then select the Media table to modify the
name of the cabinet file that was created when you compiled (WISETRFM_2.cab). In the
Cabinet column, rename the cab file to the name you specified - "mycab1.cab".
3. After you have renamed the cabinet file associated with transform in the Media table,
recompile the transform.
Using unique names for your cab files, complete these same 3 steps each time you add a
new transform for the same MSI to ensure that cabinet files will not be overwritten.
DLL is an acronym for dynamic link library. A DLL is a library, or collection of files,
that contains executable functions or data needed to run the application it is associated
with. DLL files usually end with the .dll, .exe., .drv, or .fon extensions. The application
links to the file as needed, or dynamically, to use the functions or data in the file.
Often DLLs are linked to multiple applications or can be used by various applications on
your computer. These types of DLLs are called shared DLLs or shared components.
Many of the DLLs provided by Microsoft are shared DLLs and can be found in the
Common Files or the Windows System folders.
If during installation a needed DLL file is missing or inaccessible, an error may occur
that prevents the application from being installed. To complete the installation, the
missing DLL file must be provided. Some DLLs are provided by Microsoft with the
Windows operating system. Other DLLs are written for a particular application and are
loaded with the application. If the DLL is one provided with the standard Windows
operating system, it can be restored to your hard disk from the Windows installation disk.
If the DLL was created specifically for that application, the software vendor needs to
provide the missing DLL.
Setup.exe is the "package" used to install an application onto your computer. The primary
task of setup.exe is to transfer the application files from the source media, such as a CD,
to your computer. Setup.exe installs installation engines, if necessary, and then
decompresses the application files and installs them into the appropriate folders.
Setup.exe starts the installation and cleans your computer of unnecessary files once the
application is installed.
The Windows Installer engine (also called the MSI engine) drives the installation of your
application. It is a part of the Windows Installer Service, a technology developed by
Microsoft to standardize installations on the Windows platform. Without the Windows
Installer engine, installations using the Windows Installer technology cannot be installed.
The Windows Installer engine is already installed on Windows XP. For other operating
systems, the Windows Installer engine must be installed by the installation or by the
home user. Most installations based on the Windows Installer Service automatically
install the Windows Installer engine on the computer prior to running the installation. In
case of an error or other unexpected behavior, you may need to install the engine
manually.
A shared file is a file that can be used by more than one application. The Windows
operating system provides a number of shared files that can be used by any application
installed. Software developers can also create shared files for their own applications.
Shared files allow for the creation of more efficient applications and save time because
the same code does not have to be created for each application. It is created once and
used by many applications.
During installation, files identified as shared are registered in the Windows registry. Each
time the shared file is installed, the registry increments the registry value associated with
it. This registry value is also known as the ref count or the shared reference count. So if
two applications install the same shared file, the registry value (ref count) is 2. During
uninstallation, a shared file's registry value is decremented. When the registry value
reaches 0, you will receive a message asking if you want to remove the shared file, which
means there is no application using the shared file. In almost all cases, you can click Yes
and remove the shared file. The shared file is permanently deleted, and the hard disk
space freed. If you choose No, it will not harm your computer. If you are unsure whether
or not to remove the shared file, click No.
Registry
The registry is a central database used by the Windows operating system to track your
personal settings and the software and hardware installed on your computer. When you
install an application, installation choices are written to the registry. The registry contains
5 major branches:
Important: Modifications to the Windows registry, if not done correctly, can cause
serious problems to a Windows system. Before editing the registry.
self-registering file
A self-registering file is a file that can enter information about itself in the Windows
registry and remove that information upon uninstallation. Other types of files can be used
without entering information into the registry.
The installation of a self-registering file consists of installing the file to its desired
location and then registering the file on your computer. Sometimes. because of system
specific issues, self-registeration may fail, causing an error message to appear, for
example, "Unable to register the file xyz.dll". When an installation is unable to register a
file, you may need to register it manually to make sure that the application works.
Files that are created as self-registering have information that need to be stored in the
Windows registry in order for the file to be available and useable to applications on the
machine. Usually DLLs, OCXs, and EXEs are self-registering and require to be
registered on the machine.
regsvr32 "C:\Windows\System32\Mydll.dll"
3. Press Enter.
4. If the file registers successfully, the following message appears on the screen:
3. Press Enter.
Most executables do not display any message boxes when registered. It depends on how
the application is created. Some applications when registered may open on your
computer.
The Windows System folder contains core operating system files. The files contained in
the System folder are necessary to keep your computer running properly. Errors
occurring during installation may be a result of missing or corrupt files contained in the
System folder.
Windows API
user profile
A user profile is a record of an individual user's settings, such as shortcuts, favorites, and
application, display, and hardware settings. User profiles allow multiple users to share a
single computer but maintain their own preferences.
Temp directory
The Temp directory is a folder on your hard disk where the operating system or
applications can temporarily store files while they are in use. When the application exits,
the temporary files are deleted. It may be necessary to manually clean, or delete files
from, the Temp directory.
run-time error
A run-time error is an error that occurs when a program is executed, or run. In the case of
an installation, it is from the time an installation starts through the completion of the
installation. Errors occur during installation for many different reasons, including your
home computer settings, the way the software vendor made the installation, conflicts with
other software, missing files, bugs in the software, etc. Because there are so many
possible causes, it is often hard to determine the exact cause of a run-time error.
path
The path is the route to a file on a computer. In the Windows operating system, the path
is the drive plus the location in the folder system. For example, C:\Program
Files\Microsoft Office\Office\WINWORD.exe, is the path for Microsoft Word.
isscript.msi
Isscript.msi is the InstallScript engine installer. Isscript.msi installs the required files to
run an installation. The InstallScript engine is also known as the InstallShield Scripting
Runtime. InstallScript is the programming language used to create installations. Some
error messages may reference the InstallShield Scripting Runtime or Isscript.msi.
IDriver.exe
Environment variable
An environment variable represents some aspect of your computer environment, that is,
the configuration of hardware and software on your computer. Environment variables can
be used to represent drives, program paths, directory names, and other items associated
with your computer environment as well as information such as the date, time, and your
default printer and text editor. Installation programs use environment variables to provide
information to the installation and to store information for later use by the application you
are installing.
A shared code-base file containing functions that can be called from other applications.
DCOM
COM
cache
A cache, pronounced cash, is a temporary storage area for frequently accessed data. The
purpose of caching is to store frequently used information in a location that is easy to
access, resulting in a faster running computer.
There are two types of cache: memory cache and disk cache. Memory cache stores the
data and the address of where the data is stored in main memory. Memory caching is
useful because most applications access the same data repeatedly. Disk caching uses the
main memory. It is used to hold information that has recently been requested from the
hard disk or has previously been written to the hard disk. In general, installations usually
use the disk cache. When data is read from or written to main memory, a copy is also
saved in the memory cache. When data is called for, the computer first checks the
memory cache, then the disk cache, and finally main memory.
cabinet file
A cabinet, or CAB, file is single file that holds a number of compressed files. During
installation of an application, the compressed files are decompressed and copied to your
computer. Cabinet files are efficient because they save space and time when distributing
software. A cabinet file usually has the file extension .cab. Missing or corrupt files may
prevent installations from completing. It may be necessary to replace missing or corrupt
operating system files or InstallShield files by extracting them from a cabinet file.
administrative privileges
Administrative privileges are the highest level of permission that can be granted to a
computer user. Levels of permissions are necessary in networked environments to ensure
system security and prevent damage to computer hardware and software. A user with
administrative privileges can perform tasks such as install and uninstall software and
change a computer's configurations. Administrative privileges usually pertain to
Windows NT 4.0, 2000, or XP machines as opposed to Windows 95, 98, or ME
machines.
In most cases, home users are automatically the administrators of their home computers.
If a home computer user is not the administrator some installations may fail
.NET Framework
The .NET infrastructure was created by Microsoft to allow users to connect and share
data more efficiently using a variety of devices, such as a personal computer, cell phone,
or handheld device. The .NET Framework is an environment for building, deploying, and
running .NET applications. Some applications may be .NET applications and require
the .NET framework to be installed to run.
Q1. What is Windows Installer?
Installer performs, it generates an equivalent undo operation that would undo the change
made to the
system. If a failure occurs during the middle of an installation, Windows Installer can roll
back the
common installation problems at launch, like missing files or registry keys, and
automatically repair
themselves.
For example, the spelling checker in Microsoft Office Word may not be installed by
default, but a user can
interfaces (APIs) and automation interfaces for applications and administrators to use for
querying the
installation state on the machine. The APIs allow querying of the current state,
verification of the existing
state, repair of a corrupted state, and transition from one state to another.
Q1. Windows Installer version 2.0 is the latest released version. What new features
and improvements are provided in version 2.0?
• Ability to conceal personal information. Windows Installer provides authors with a way
to hide information, such as passwords, from appearing in log files.
• Multiple user isolation. Modifications to Windows Installer architecture allow for true
isolation of per-user installations since a product's per-user configuration information is
no longer shared among users.
• Digital signature support. Digital signature support is included for Windows Installer-
related files, such as packages (.msi), patches (.msp), and transforms (.mst). Windows
Installer also supports digital signature verification of external cabinet files (.cab)
associated with an installation.
• More robust patching. Numerous patching issues were fixed in version 2.0.
• Simplified patch authoring. Patch conflict resolution in version 2.0 eliminates some of
the burden of authoring patches. Setup authors targeting version 2.0 no longer need to
keep track of every disk ID and last sequence number used by previous patches.
• Improved patch and update installation. Version 2.0 reduces unnecessary source
resolution attempts. In the majority of cases, the user is no longer required to have access
to the original source location when applying a patch unless specifically required by the
package author. Additionally, more efficient updates result from removal of unnecessary
un-versioned file copies.
• Support for transforms and patches from URL sources. Windows Installer version 2.0
now supports using transforms and patches from a source referenced by a Uniform
Resource Locator (URL).
• 64-bit service on 64-bit Windows. Windows Installer is a native 64-bit service for the
installation of 64-bit applications on 64-bit versions of Windows.
• Enhanced logging. Event logging has been greatly improved in order to aid
troubleshooting installation issues. This includes ensuring that different errors have
unique event IDs.
A. This table details the operating systems that each released version of Windows
Installer supports.
A. You can obtain the latest Windows Installer redistributable from the Microsoft
Platform SDK Redistributables site. There are two different versions of the Windows
Installer redistributable: one for Windows 95, Windows 98, and Windows Me; and one
for Windows NT and Windows 2000.
Q6. Where can I obtain merge modules for Microsoft technologies I need to
redistribute in my setup?
A. Microsoft merge modules are provided with Microsoft Visual Studio .NET. Their
default installation location is [ProgramFilesFolder]\Common Files\Merge Modules.
Note that not all Microsoft redistributable components have merge modules available.
How-To Guide
Q8. After repeated edits of my .msi package in Orca, the size of the package has
grown considerably. How can I reduce the size of my .msi file?
A. The .msi package database format is based upon OLE structured storage. Frequent
editing of the database over time can result in fragmentation and wasting of space. You
can reduce the size of the .msi package by using the SaveAs command in Orca or
alternatively by exporting all of your tables with msidb.exe from your package and then
re-importing them into a newly created database.
Both the Orca and msidb.exe tools are available in Windows Installer SDK.
A. Beginning with Windows Installer 2.0, there is a command-line option, that makes it
possible to hide the Cancel button during basic user interface (UI) installations. The
following command-line script demonstrates how to use the new option:
You can also hide the Cancel button by using the MsiSetInternalUI Win32 API to
combine INSTALLUILEVEL_HIDECANCEL with INSTALLUILEVEL_BASIC.
Alternatively, the same can be accomplished through Windows Installer automation by
combining msiUILevelHideCancel with msiUILevelBasic when using the read-write
UILevel property of the Windows Installer object.
During an installation, the presence of the Cancel button can be changed through a DLL
or script custom action that sends an INSTALLMESSAGE_COMMONDATA message.
DLL custom actions would use the MsiProcessMessage Win32 API to send an
INSTALLMESSAGE_COMMONDATA message where field 1 of the record is set to 2
and field 2 of the record is set to 0. To unhide the Cancel button, the same message would
be sent, but with field 2 set to a value of 1. Script custom actions would use the
equivalent Message method of the Session object.
The following command-line script would advertise the "Sports" feature and install the
"News" feature to run from source.
Q11. How do I force-update an unversioned file during an upgrade, even if the user
has modified it?
A. Directory property values end with a directory separator. Authoring a path string
therefore does not require the use of the directory separator.
Incorrect: [DirectoryProperty]\someLocation
Correct: [DirectoryProperty]someLocation
A. For products with different versions, either due to language or other differences
between products, use different product codes. To indicate a direct, familiar relationship
among the products, have the products share the same upgrade code.
Security
Q15. What is the difference between the AdminUser and Privileged properties?
A. The AdminUser property is set when the user performing the installation is an
administrator; the Privileged property is set when the user is allowed to install with
elevated privileges. A user can install with elevated privileges if the user is an
administrator, both the per-user and per-machine AlwaysInstallElevated policies are set,
or the application has been assigned by the system administrator.
If the user is an administrator, then both the AdminUser and Privileged properties are set.
If the user is not an administrator, then AdminUser is never set. In that case, Privileged is
only set if the user has been given permission by the administrator through assignment or
policy to install the application as elevated.
Q16. Should users with user-level privileges be able to install MSI applications?
A. Those with user-level privileges can install managed applications if the system
administrator has enabled the installation. Otherwise, the user will only be able to install
MSI applications provided the user has permission to write files, create directories, and
write registry keys in the locations where the installation typically writes those resources.
If the user cannot write to a location, then the installer will only be able to write to that
location if the administrator has given permission for the installer to do so.
Custom Actions
Q17. What are the differences between a 'deferred' custom action and an
'immediate' custom action?
A. • Deferred custom actions can only be sequenced between the InstallInitialize and
InstallFinalize actions in execute sequence tables. Immediate custom actions, on the other
hand, can be sequencd anywhere within any of the sequence tables.
• Deferred custom actions cannot access the installation database. In fact, deferred custom
actions have very limited access to the installation session because an installation script
can be executed outside of the installation session that created it. Immediate custom
actions have access to the installation database and can read and set installation
properties, modify feature and component states, and add temporary columns, rows, and
tables among other things.
• While both deferred and immediate custom actions can run in the context of the user
initiating the installation, only deferred custom actions can run elevated using the system
context.
• 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.
Q18. When should I use a deferred custom action instead of an immediate custom
action?
A. Deferred custom actions should be used when the custom action must make a change
to the system or call another system service. Additionally, only deferred custom actions
can run in an elevated context. If your custom action requires elevated privileges in order
to run, your custom action needs to be marked as deferred.
Additionally, when making a change to the system by means of a custom action, you
should also include a rollback custom action that can undo the change.
A. Deferred custom actions have limited access to the installation session. If your
deferred custom action requires information about the installation that it cannot obtain
through its limited access, then you can provide that information to the deferred custom
action through the CustomActionData property. This method is only available to script
and DLL deferred custom actions. This is how it works:
1.An immediate custom action that executes before the deferred custom action sets a
property with the same name as the deferred custom action to the value that is needed by
the deferred custom action. So, if the primary key for a deferred custom action is called
"DeferredCA," then the immediate custom action would set a property called
"DeferredCA" to the value that was needed. A type 51 custom action would be an easy
way to set this property. Another method would be an immediate custom action that calls
MsiSetProperty with the szName parameter equal to "DeferredCA." Note: The action
name is case-sensitive.
2.When the deferred custom action is queued into the installation script, the installer will
write the value of the property "DeferredCA" into the installation script as the value of
the property CustomActionData.
3.Upon execution, the deferred custom action retrieves the value by making a
MsiGetProperty call with the szName parameter equal to "CustomActionData."
Alternatively, a script custom action would use the Property property of the Session
object.
A. An immediate custom action can trigger a reboot by calling MsiSetMode with a run
mode of MSIRUNMODE_REBOOTATEND or MSIRUNMODE_REBOOT and a state
value of TRUE. Since MsiSetMode requires an hInstall handle, only DLL and script
custom actions can trigger a reboot. Script custom actions would use the Mode property
of the Session object. Alternatively, an immediate custom action can call MsiDoAction
with szAction equal to "ScheduleReboot."
Deferred custom actions cannot call MsiSetMode. A deferred custom action would need
to set a value in a location in the registry that an immediate custom action, sequenced
after InstallFinalize would read. That immediate custom action could then schedule the
reboot using MsiSetMode. If this method is required, a rollback custom action should
also be provided that will delete the registry value that triggers the reboot if the
installation is cancelled.
Q21. How can my custom action add information to the verbose log file?
A. DLL and script custom actions can add information to the verbose log file by sending
INSTALLMESSAGE_INFO messages using the MsiProcessMessage API. Script custom
actions would use the Message method of the Session object.
A. A number of MSIExec 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
processes can be the client process. Another MSIExec process is Windows Installer
service. Any remaining MSIExec processes are usually sandbox processes for hosting
custom actions. The determination as to which MSIExec 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.
Patching and Upgrades
Q23. What are the differences between small, minor, and major updates?
A. A small update is a product update that changes a few files or possibly adds some new
content. A minor update is a product update that makes enough changes to warrant
changing the product version for the product, whereas a major update is a product update
with a large number of changes that warrants a change in the product code. This table
summarizes what changes in each update and the possible distribution vehicles for each.
It's sometimes easier to think of a small update as a "hotfix" or Quick Fix Engineering
(QFE) update, a minor update as a service pack, and a major update as a product
upgrade.
Small and minor updates can be considered almost equal in that the only real difference is
that a minor update has a change to the ProductVersion whereas a small update does not.
The rules that they follow and application of the patch are the same. Application of small
and minor update patches requires explicit reinstallations. Major updates are not subject
to that limitation and a reinstallation is not required for patch application. Additionally
small and minor update patches are limited in the changes that can be made to the
feature-component structure for the package. Significant changes can be made to the
feature-component structure in the scope of a major update.
• The patch applies to a feature that is currently run from source. In this case, the feature
is transitioned from the run-from-source state to the local state.
• The patch applies to a file in a component that also contains unversioned files with no
MsiFileHash entries. A populated MsiFileHash table is required to prevent unnecessary
recopying of unversioned files from the source location.
• The patch was applied with a REINSTALLMODE of amus. The a option is dangerous
in that it will perform file copies regardless of file version. This can lead to revision of
earlier files and will almost always require the source. The recommendd
REINSTALLMODE value is omus.
• The cached package for the product is missing. The cached package is needed for
application of the patch. The cached package is stored in the %windir%\Installer folder.
• The package is authored to make a call to the ResolveSource action. This action should
generally either be avoided or conditionalized appropriately because its execution will
always result in an access of the source.
• The package has a custom action that attempts to access the source in some manner.
• The patch package consists of binary patches that won't apply to the current version of
the file on the machine. Consider the following example:
• Install RTM version of product Example. This puts version 1.0 of Example.dll on the
machine.
• Apply patch qfe1.msp to the machine. This patch patches version 1.0 of Example.dll to
version 1.1.
• A new patch, qfe2.msp is provided which updates Example.dll to version 1.2. However,
the patch was only created to target version 1.0 of Example.dll because it was generated
using the RTM version of the product. Example.dll version 1.2 includes the fix that is in
Example.dll version 1.1, but the MSP was generated between the RTM and QFE2
images. So, when qfe2.msp is applied to the machine, Windows Installer will need to
access the original source. The binary patch for example.dll cannot apply to version 1.1;
it can only apply to version 1.0. This results in the installer re-copying version 1.0 of
example.dll from the original source location so that the patch can be applied
successfully.
A. At this point, you can't completely prevent a patch from requiring the source.
However, the following steps could help eliminate a number of those instances:
• Use whole-file only patches. This saves the patch creator from having to create binary
patches for every previously released patch plus the RTM version. You can easily set a
patch to be a whole-file only patch by authoring the IncludeWholeFilesOnly property
with a value of 1 in the Properties table of the Patch Creation Properties file (PCP).
• Ensure that none of your custom actions access the original source location.
Q26. Why was my patch successfully applied but no files were updated?
A. Most likely you simply double-clicked a small or minor update patch. Application of a
small or minor update patch requires an explicit reinstallation to be performed for the
files to be updated. This can be accomplished using the MSIExec command line and
including the REINSTALL and REINSTALLMODE properties (that is: msiexec /p {path
to my patch.msp} REINSTALL=ALL REINSTALLMODE=omus). Another option
would be to include a custom action in the patch that will set the REINSTALL and
REINSTALLMODE properties appropriately. You should make sure that you
conditionalize this custom action appropriately so that it only runs on first application of
the patch. Subsequent reinstalls of the product should not result in execution of the
custom action, otherwise your product may no longer be uninstallable. Other options
include using a bootstrap executable that calls MsiApplyPatch with the appropriate
property settings or using Windows Installer automation object to script the patch
application.
A. Yes, you can update a custom action using a patch. If the custom action is included in
the Binary table, then simply update the custom action in the update installation image.
When you generate the patch between the original and update installation images, the
patch will contain a database transform that will transform the old binary data stream to
the new binary data stream.
Troubleshooting
A. There are three good troubleshooting methods for tracking down package installation
problems. The first method is to ensure that your package is valid by running validation.
Validation helps catch common installation authoring problems by identifying errors and
warnings. Two tools can be used for validating an installation package, both are available
in the Windows Installer SDK: MsiVal2 and Orca. MsiVal2 is a command line utility for
validating a package. Orca provides a graphical user interface for validation and will also
highlight invalid entries in the package.
The second method is to use the application event log. Windows Installer will record
successful and failed installation information in the application event log.
The final method is to generate a verbose log file, and then analyze the verbose log file
looking for the source of the error. A helpful utility for analyzing verbose log files is the
WILogUtl.exe tool provided in the Windows Installer SDK. Logging can be enabled via
Windows Installer logging policy or by appending "/L*v path to logfile" to your
MSIExec command line.
To generate a detailed verbose log file through policy, use the following registry key:
• HKLM\Software\Policies\Microsoft\Windows\Installer
Log files generated through the policy key will be of the form msiXXXXX.log in the
user's %temp% folder.
Note: Logging through the command line overrides any logging policy settings.
Description:
Description:
The first message (with event ID 1001) states which component was being installed. The
component listed here is the component named in the Component_ column of the
Shortcut table for the particular shortcut.
The second message (with event ID 1004) indicates which component failed detection.
Improved event logging in Windows Installer 2.0 has updated the message so that in most
cases, the message identifies the actual resource that resulted in the failed detection. The
component with the missing or damaged keypath is the component that is triggering the
reinstallation.
In the example above, the reinstallation is triggered because the resource 'c:\Program
Files\example\example.exe' does not exist. You would then need to find out why the
keypath does not exist—in this case, the user deleted it.
MSI (s) (5C:F4): Feature: Example; Installed: Absent; Request: Local; Action: Local
MSI (s) (5C:F4): Component: Example; Installed: Absent; Request: Local; Action: Local
A. 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.)
• None of the components to which these files belong have component GUIDs. (The
value for the component in the ComponentId column of the Component table is NULL).
Components without GUIDs are not managed by Windows Installer.
• If the keypath of the component has a shared DLL refcount, 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 refcount for any one file in the component, then the component
will not be uninstalled.
A. Folders are not removed during uninstallation because of one of the following
reasons:
• 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.
Q32. Why are my registry keys not being removed during uninstallation?
A. The most common causes for leaving behind registry keys during uninstallation are:
1.The Registry table contains entries marked with the '+' sign. This directs the installer to
leave behind those registry keys during uninstallation.
Q33. Why is the disk space consumed by the installation so much larger than the
actual sizes of the files I am installing?
A. Windows Installer calculates two types of space consumption: the space consumed
with rollback, and the space consumed without rollback. The space consumed without
rollback is the actual disk space consumed by the installation. The space consumed with
rollback will include the space of the backup files necessary for supporting rollback
during the installation. Additionally, Windows Installer calculates some of the overhead
required for performing the installation. Included in the overhead is the space required for
the installation script and the space requirements of the cached package. Furthermore, the
installer runs from a temporary copy of the installation package during the installation.
Both the space requirements of the installation script and the space requirements of the
running copy of the package are temporary. These files are cleaned up after installation.
Consider the following example where your installation package is around 80 kilobytes
(KB) in size and you are installing a 4 KB file (Note: your numbers may vary depending
on the cluster size of your hard drive):
89120 bytes (temporary working copy of MSI)8192 bytes (estimated script size)
----------------------
A. Windows Installer may prompt for a reboot if it installs over a file that is in use or the
package explicitly requests that the installer reboot. It is easy to determine if Windows
Installer prompts for a reboot because it installed over a file that is in use. The first step is
to generate a verbose log file. In the verbose log file, look for the presence of the
ReplacedInUseFiles property in the property dump. If this property is present with a
value of 1, then the Installer will require a reboot because it overwrote an in-use file.
To determine which file was in-use, scan the log file for "Info 1603" and "Info 1903"
messages. The 1603 message will be logged by the InstallValidate action. For example:
Info 1603. The file d:\test\sample.exe is being held in use by the following process:
Name: sample.exe, Id: 4068, Window Title: 'Sample'. Close that application and retry.
Normally, this messag;e coincides with the presentation of the FilesInUse dialog box. In
silent UI cases, this dialog box will not be presented. Additionally, not all files that are in
use will show up in the FilesInUse dialog box. The FilesInUse dialog box may not be
displayed if the files in use are not executables, the process holding the files is the
process invoking the installation, or the process holding those files is one that does not
have a window title associated with it.
The FileCopy opcode in the install script can also log the 1603 info message. In the
above example, the log file contains:
Info 1603. The file D:\test\sample.exe is being held in use. Close that application and
retry.
At the end of the script during cleanup, the following log file message identifies the
culprit for the reboot:
While the file is named 12544a31.rbf, it is the Sample.exe file. In order to install the file,
the in-use file was renamed to the .rbf file and will be deleted upon reboot.
Q36. When launching an installation from a system account, I receive error 2103.
Why?
A. Launching an installation from a system account, like the scheduler service, may result
in the 2103 error. This can occur if you are initiating a per-user installation. Only per-
machine installations are permitted from the system account because the system account
does not have all of the necessary per-user profile folders.
Q37. Why do I receive error 2755 when launching an installation from a mapped
drive letter on a terminal server?
A. Windows 2000 and earlier operating systems do not support passing mapped drive
letter information between terminal server sessions. Since Windows Installer service runs
as a service in the console session, mapped drive letters established in remote sessions are
not visible to Windows Installer service, resulting in this error. This only applies when
running the service in Application Server mode, not Remote Admin mode.
Note that this limitation no longer exists in Windows XP and later operating systems.
Q38. Why do I receive a security warning dialog box with the message 'An error
occurred while accessing online revocation server' when installing a package using
the Web download bootstrap?
A. The security warning dialog is presented because of a problem in the way the Web
download bootstrap (Setup.exe) performs the digital signature verification. This problem
has been fixed in the latest available sample code provided with the Windows Installer
SDK available in the Microsoft Download Center. Simply re-build the Setup.exe using
the PSDK build environment and the provided sample code. Then re-configure the
Setup.exe using the MSIStuff.exe utility. You can download the fixed sample code from
the SDK Update site.
Question 41
Answer
If you only install to locations where non-admins users have privileges, then the answer
is easy: yes.
If you install to locations such as program files or HKLM, then the answer is -- they can
with MSI if the package has been blessed by an admin to run elevated. Otherwise
attempts by the non-admin to write to program files are going to fail. And additionally, a
package can't self-elevate -- that would be a security issue.
For the latter case, consult the documentation on MSDN: Installing a Package with
Elevated Privileges for a Non-Admin. This is basically what Group Policy and SMS are
for.
Question 42
What will happen if the per-user install is followed by an install running with
administrator privileges (i.e. one triggered by the IT administrator)?
Answer
Say the admin installs the same app per machine. After this setup is done, User1 still sees
the per-user installed app in ARP, and User1 cannot use the full functionalities in the per-
machine installed app. But other users could use the per-machine installed app. So when
MSI does a per-machine install, it does not uninstall the same app installed per-user for
some particular user context.
If you’d like ensure the full functionalities of your app are available to all users, and
some of them require admin privilege to install, please condition your setup to run for
admin (see LaunchCondition Table and Privledged Property)
Question 43
Does Windows Installer remember at uninstall the value of a property set during install?
Answer
Question 44
How can I retain the value of a Property between install and uninstall?
Background
The best option is to not require persistence. For example, if you are substituting into file
or registry paths, that likely means you are violating component rules. One strategy is to
attach actions to components and let the component uninstall trigger the reverse action.
The component rules stipulate that component definitions (file sets & registry) should be
consistent across all definitions of that component (products, versions) and be exclusive
of other components so that the installer’s reference counting of components and use of a
product-specific definition ensures that the component gets added and removed properly.
These rules aren’t as interesting unless (1) you have multiple products or versions that
may coexist and (2) you care about getting a clean uninstall. Those may not apply in your
case. If that component is always installing the same UDL file to the same location, then
the oddity would come if there were a way to install it again with different substitutions.
1. Write the values to the registry and use RegLocators to scan them back.
2. Write a custom action to read the property values from a custom storage file.
3. Install the pre-processed file to one location and substitute to the final location.
Do this on install only, and add a RemoveFile to remove that file on uninstall.
That would prevent any repairs from replacing the original file.
For 1, the preferable way to do this is by dynamically adding the values to a component,
however the Component Rules must be honored for compositional integrity of that
component.
Answer
Most of the Windows Installer adopters inside and outside of Microsoft use the registry
method when they need to persist property value(s) since we don’t have an out of box
solution for them yet.
Future
A common question I have been receiving lately is about the Windows Installer 3.1 (v2)
Redistributable and what version of the Windows Installer is actually the "latest". Well,
let's hope that this posting clears up any confusion on the topic. :)
There are actually three versions of Windows Installer 3.1 that have been released:
3.1.4000.1823 This version is installed with the original Windows Installer 3.1 (v1)
redistributable.
3.1.4000.1830 This version is the version that shipped with Windows Server 2003
Service Pack 1.
3.1.4000.2435 This is the latest version and contains a fix to address the issue in
KB898628.
It's important to note that 3.1.4000.1823 and 3.1.4000.1830 are functionally identical.
The reason why the version numbers are different is because the final build of Windows
Server 2003 Service Pack 1 was made a few days later than the final build of our original
redistributable package.
Now that you know all the version information, let's discuss how you can ensure that you
have the latest version:
Both the original version of Windows Installer 3.1 (3.1.4000.1823) as well as the updated
version (3.1.4000.2435) were sent out through Windows Update as critical updates. If
you use Windows Update to automatically update your machine, you should already have
the latest version.
If you want to check the version of the Windows Installer on your system, check the
version of MSI.DLL in the Windows\System 32 folder. If the version is 3.1.4000.2435,
you have the latest version.
One common point of confusion is that even if you have the latest version of Windows
Installer 3.1 on your system and you type in msiexec.exe /? from a command-window,
you will still be told that you are on version 3.1.4000.1823 or 3.1.4000.1830. This is
because msiexec.exe /? will only give you the version of msiexec on the system -- not the
other Windows Installer-related dll's. (The version of msiexec was not updated to
3.1.4000.2435 with the (v2) redistributable, just msi.dll was updated.)
If you find that the version of MSI.DLL on your system is not 3.1.4000.2435, the easiest
way to get to the newest version is to go to Windows Update and download the update. If
you need to manually download the update, you can visit KB898715 for Windows Server
2003 SP1 and 64-bit Windows XP systems or KB893803 for other supported platforms.
Question 45
What considerations are there for obfuscating my .MSI file with say a .DAT file name?
Background
I've seen this choice pursued when folks have a bootstrapper, usually setup.exe, that they
always want to call the .MSI file. The justification here is that a Right-Click -> Install
operation on the MSI file itself will not work from some technical reason in the package.
Design Consideration
Yes, other folks have used the hiding ‘msi with different file extension’ approach. Over
the lifespan of software, the information I’ve received back on this approach is that
modifying the file extension just complicates the support and admin scenarios without the
targeted benefit of preventing motivated folks from messing with the package. If the bar
is ‘keeping honest people honest’ then a LaunchCondition with a good error message is
usually enough.
Question 46
Solution
Please have a look at the MSDN topic: Using a Custom Action to Launch an Installed
File at the End of the Installation
Key Custom Action Snippit from Tutorial.cpp from Windows Installer Section of
Platform SDK
//////////////////////////////////////////////////////////////////////////////
// LaunchTutorial
//
//
if ( !hRecTutorial
|| ERROR_SUCCESS != MsiRecordSetString(hRecTutorial, 0,
szTutorialFileKey))
return ERROR_INSTALL_FAILURE;
DWORD cchPath = 0;
if (ERROR_MORE_DATA == MsiFormatRecord(hInstall, hRecTutorial, TEXT(""),
&cchPath))
Question 47
Where can I get some help parsing the Windows Installer logs?
Answer
Question 48
Answer
You can check if the REINSTALL property is set. If you want to detect if a patch
operation is happening (which also sets the REINSTALL property), you can check if the
PATCH property is set (or the MsiPatchRemovalList property for patch uninstall).
Question 49
Is there a way to surgically update the MSI with the signed binaries without having to
repackage the MSI?
Answer
You can use MsiFiler.exe tool to update File table and MsiFileHash table.
If you are looking for fully verified signed installation, then check out Authoring a Fully
Verified Signed Installation and Msicert.exe
Question 50
Answer
No.
DCOM will strip privileges from the token that are not explicitly enabled. That's a
DCOM design -- not MSI and since custom actions are 3rd party code, they are not
hosted in-proc but rather in a sandbox process. You'll find that MSI actually worked
around this design limitation of DCOM in MSI 3.0 itself.
If that privilege is not already enabled within the token, then it will not be available due
to the DCOM behavior.
Problem 51
I’m trying to build a customized cub file to run against my MSI using msival2.exe. I built
a DLL with some customized ICE errors and inserted it into the cub file. When I run
msival2, it keeps complaining the DLL cannot be run. The detail error is following.
Product: -- Error 1723. There is a problem with this Windows Installer package. A DLL
required for this install to complete could not be run. Contact your support personnel or
package vendor. Action MyCustomICE, entry: MyCustomICE, library:
C:\DOCUME~1\<emailname>\LOCALS~1\Temp\MSI121.tmp
Solution
The most likely problem is the custom action entry points are not properly exported from
the DLL. Did you use a .def file or linker /export switch to prevent the exported function
names from being decorated?
Problem 52
Design Considerations
Pragmatically
Product Support and Administrators need the capacity to operate MSIs from the
command line so there’s never been a need for MSI users to exclusively tie an MSI to a
wrapper. One should observe that any manipulation done in the package can be altered by
a savvy person and removed.
Solution
Typically this is solved with a simple LaunchCondition. Here's how one can add this
using the tools in the Windows Installer SDK. Third-party package tools may have other
solutions so check with your package vendor (of course, that is if you are using one ;^).
Note: this is intended to allow the installation if launched from the wrapper, or if it has
already been installed - thus allowing maintenance (modify, repair, update, uninstall)
operations without having to use the wrapper.
Task 1: Open the Windows Installer File by Using the Orca Editor
To open the MyApp.msi file and to add a launch condition by using Orca, follow these
steps:
1. Start Orca.
Note To download and to install Platform SDK (including Orca), visit the
following Microsoft Web site:
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
(http://www.microsoft.com/msdownload/platformsdk/sdkupdate/)
After you install Platform SDK, install Orca. To do this, double-click the
Orca.msi file that is located in the Bin subfolder of the Platform SDK
installation folder.
2. On the File menu, click Open.
3. In the Open dialog box, locate the MyApp.msi file, and then click Open.
To add new tables such as the LaunchCondition table to the MyApp.msi file, follow these
steps:
1. Under Tables in the left pane, the LaunchCondition table exists. If this tables does not
exist, perform step 2 and step 3.
2. On the Tables menu, click Add Table.
3. In the Add Tables dialog box, click to select the check boxes for LaunchCondition,
and then click OK.
You can establish the launch condition based on a property. To set the launch condition
in your MyApp.msi file, follow these steps:
1. Under Tables in the left pane, click LaunchCondition, and then click Add Row on the
Tables menu.
2. In the Add Row dialog box, click Condition in the Name column, and then
type WRAPPERCALLEDME OR Installed in the Condition - String[255], Required
text box.
3. In the Name column, click Description, and then type Please launch [ProductName]
through the wrapper. in the Description - Localizable String[255], Required text
box.
4. In the Add Row dialog box, click OK.
5. On the File menu, click Save, and then close Orca.
Task 4: Verify That Your LaunchCondition Works
Now all you have left to do is add the WRAPPERCALLEDME=1 command line value
the invocation of MyApp.msi from your wrapper.
Question 53
What are some sources of: Error 1606: Could Not Access Network Location?
Answer
Generally, the installer will validate the existence of directories listed in the directory
table -- if you don't install to that directory, then don't list it in the table.
On rare occasions, this can be sourced to the issue described in You receive an "Error
1606" error message when you try to install or remove a Microsoft program
Question 54
I went to the Microsoft download site and could not find a entry for the Windows
Installer SDK. Where is the Windows Installer SDK?
Answer
The Windows Installer documentation on MSDN always lists the download page for the
Installer SDK. It's the same location as the platform SDK. Our parent MSDN
documentation page that provides links is: Other Sources of Windows Installer
Information
Another way of locating the SDK is to look in the MSDN topics for the individual tools.
For example, you'll find that the Orca.exe MSDN topic provides you with the link to the
download location. Note: by traversing through Windows Installer documentation, it will
always be direct to the latest Platform SDK site. As of now (Windows Installer 3.1
release), the latest for Windows Installer for the Server SP1 SDK.
Question 55
Troubleshooting
Start by noticing that features that should be installed are actually listed as Advertised
MSI (s) <process info>: Feature: AdminTools; Installed: Advertise; Request: Reinstall;
Action: Reinstall
This is the root cause of why the files weren't updated -- the features showed up as
advertised.
The next question to ask yourself is why are the features showing up as advertised?
Question 56
Why does the Windows Installer log list apparently duplicate components prepended
with double underscore and appended with 65? Example:
MSI (s) <process info>: Feature: Simple; Installed: Absent; Request: Local; Action:
Local
Answer
Windows Installer performs disk costing to determine the amount of space required for
the setup. It associates cost at the component level. The cost associated to an individual
component is based upon the files that it installs and the Directory_ reference. However,
there are cases where a component can actuall install resources into locations other than
the Directory_ reference. In order to account for that, and to more accurately adjust
costing when a Directory location changes (such as when the user alters the
InstallLocation), the Installer uses a mechansim called cost-linking. For each alternate
directory for the component, the Installer creates a new temporary component, called a
subcomponent. The format of the component is a double under bar prefix (__) followed
by the first 40 characters of the component name followed by a number.
• Shortcut
• RemoveFile
• MoveFile (both source and destination folders)
• DuplicateFile
• Registry
• IniFile
• ReserveCost
Cost-linking is also used for all global/shared assembly components (both urt and win32)
and for the new MSI 3.X baseline cache management for patched files (only when a new
patch is applied).
So, for example, let's look again at the InstallValidate action dump from above for an
example setup where the component installs both a file and a registry key:
MSI (s) <process info>: Feature: Simple; Installed: Absent; Request: Local; Action:
Local
Note the subcomponent highlighted in red. That component was created to account for
cost associated with the registry key. It's a cost-linked component for the component +
WindowsFolder directory. The component's current cost (for the parent) is associated
with the SimpleDir directory which is the authored directory for the component in the
Component table. At this point, the component doesn't have any previously created child
components so it starts with a suffix of 65. Also, only the first 40 characters were used of
the component name (which had 55 characters).
Question 57
Background
For background on subcomponents, see Why does the Windows Installer log list
apparently duplicate components prepended with double underscore and appended with
65?
A careful reader will notice a problem with the subcomponent generation algorithm. See
it? It's the component name is based off the first 40 characters of the component. What
happens if the the first 40 characters of all the components in a package are identical?
The Windows Installer has code to look for collisions and increment an index until one is
not found. Turns out there's a arbritary limit of 100 iterations of that loop.
Troubleshooting Package
Here's why the simplified repro package suffers from the problem
Starting with the IniFile table: There are 35 components of the 70 that are listed in the
table. Each component ends up being cost-linked to two directories. That means that two
temp components are created for each component in the table. So, we have cost-linking
of the component to the CRC directory and cost-linking of the Component to the
WindowsFolder directory. Even with the child component account, you'll still start to hit
a problem. (Each component will end up with 1 child component after the first run of
cost-linking the CRC component).
By the end of this, we've used up 70 cost-link names. We only have about 100 available
because of the MaxTries amount and the fact that only the first 40 characters are chosen.
So we have temp components:
__PUBLIC_HIDEAPP_OAK_LIB_MIPSIV_FP_RETAIL_65
__PUBLIC_HIDEAPP_OAK_LIB_MIPSIV_FP_RETAIL_66
...
__PUBLIC_HIDEAPP_OAK_LIB_MIPSIV_FP_RETAIL_135
Now we move on to the MoveFile table. There's a possibility of two cost-linked
components created per row. However, the source and destination folders in this package
authoring are the same, so there'll only be one cost-linked component per row. Note that
the directory used here was not one that was used in the IniFile table (if it was, we
wouldn't need to create a new cost-linked component for it). There are 35 rows reprsented
in the MoveFile table for these 70 components. That makes 35 more temporary
components that have to be created since all of the rows represent unique components
and new directories.
Well, now we've hit the 100 limit. 70 + 35 = 105 so we bomb out for the temp component
creation. This cost-linking starts at:
__PUBLIC_DIRECTX_OAK_LIB_MIPSIV_FP_RETAIL_136
...
__PUBLIC_DIRECTX_OAK_LIB_MIPSIV_FP_RETAIL_165
__PUBLIC_DIRECTX_OAK_LIB_MIPSIV_FP_RETAIL_166 // FAILURE!
It fails at suffix 166 because it's already exhausted the max tries value.
Normally this isn't a problem because you don't usually hit the subcomponent name
limitation. Most component names differ within the first 40 characters, and even if not,
there aren't enough similarities to hit the iMaxTries upper limit. It just so happens that
this is the case with the way these packages are built. If you guarantee uniqueness within
the first 40 characters of all components, you won't have any issues.
What you'd normally expect to see would be something like the following if your
components didn't include that same 41 character prefix:
...
MoveFileTable results:
...
But because you have the same 40 characters in your package (actually 41), you end up
with all of the collissions and end up maxing out because you hit the upper limit for
subcomponent name generation.
If you want to make your packages work, you'll need to alter your component name
generation. In particular, ensure that the first 40 characters are unique.
Question 58
I’ve got a report of error 2356 "Could not locate cabinet in stream: [2]." which says a
cabinet is missing from the stream. How can I see the streams that are in the MSI and
once I know the names, how can I extract them?
Answer
Wistream.vbs can list the streams in the database. You can use msidb.exe to extract them
(msidb.exe /?)
The full suite of scripts, including Wistream.vbs is available in the Windows Installer
SDK which is a portion of the Windows Platform SDK.
Question 59
We’re trying to install our MSI without having it listed in Add/Remove Control Panel
using (as per documentation I found in the MSDN):
ARPSYSTEMCOMPONENT=1
Answer
You should specify the ProductCode – not the product.msi itself – as the parameter. Look
at some ARP entries for other MSI products installed on the system for some examples.
Question 60
When I uninstall with our application running, the folder that contained the app is not
removed after reboot. Now I know the documentation for the RemoveFolders action says
that if the folder is not empty it won’t remove the folder. However after the reboot, the
folder is empty, shouldn’t it be scheduled for deletion after reboot as well?
Answer
There is a known issue when a folder held in use (that is empty) and not deleted during
uninstall.
• Carolyn, MSI Team Dev Lead. You can get other Carolyn insights about
developing for Windows Installer from the Windows Installer Chat Archives
This posting is provided "AS IS" with no warranties, and confers no rights. Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.
Comments
# re: Folder not removed after reboot when files are in use?
This obviously doesn't happen all the time, what triggers it? A process is holding the
empty directory? Or is it one of those "sometimes it happens sometimes it doesn't" kind
of things? Is it planned to be fixed in a future release of the installer engine?
Question 61
I am presently trying to automate patch builds for my product code, and I am using
msimsp.exe with the following command-line
Msimsp.exe –s -p -l
Target ProductVersion is greater than the Upgraded Image; do you want to proceed
anyway?
I need to know-
Answer
Question 62
How can I pass the installation directory info to the custom action exe?
Answer
This posting is provided "AS IS" with no warranties, and confers no rights. Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.
# re: How can I pass the installation directory info to the custom action exe?
Is this the same for if you are wishing to deploy through group policy? I have an
application which runs a number of custom actions to create and copy files depending on
the values entered at install. These values are not being carried through and the files are
not being created. Does the installation directory need to be physically set for the files to
be installed in the right place ?
# re: How can I pass the installation directory info to the custom action exe?
Is this the same for if you are wishing to deploy through group policy? I have an
application which runs a number of custom actions to create and copy files depending on
the values entered at install. These values are not being carried through and the files are
not being created. Does the installation directory need to be physically set for the files to
be installed in the right place ?
Question 62
FormatText :
Hex(err)= 80004005
Err.description= "OpenView,Sql"
Answer
There are two contexts here: Windows Installer errors and messages from the layer(s)
under us
For the underlying layer, the way I look up eight digit errors that start with 8 is
This posting is provided "AS IS" with no warranties, and confers no rights. Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.
Comments
# re: How do I translate the error reported in the Windows Installer log?
It appears that the errlook utility requires that values entered as hexadecimal values
include the '0x' qualifier. So, for the given example, entering "0x80004005" produces the
the message "Unspecified error". However, entering "80004005" produces an error dialog
with the message "Message not found".
Question 63
Answer
• Aaron, Windows Media Center PM. You can get other Aaron insights about
developing for Windows Installer from Aaron's Blog
This posting is provided "AS IS" with no warranties, and confers no rights. Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.
Comments
Actually, the NDP version is in there (implied by the statement "because the version will
conitnue to change" so the path is more like ...\NDP\v1.1.4322\@Install=1 for .NET 1.1.
Also note that these values don't exist for .NET 1.0 on Tablet PC and eHome (Media
Center) and you have to use an alternative means to determine if .NET is installed. See
http://blogs.msdn.com/astebner/archive/2004/09/14/229802.aspx for details.
Heath is correct. The full path to the registry value to use to detect the presence of the
.NET Framework 1.1 is HKLM\Software\Microsoft\NET Framework
Setup\NDP\v1.1.4322\@Install=1
The major/minor version for the .NET Framework 2.0 has been locked down now too. So
the detection for that will use HKLM\Software\Microsoft\NET Framework
Setup\NDP\v2.0.50727\@Install=1 once 2.0 ships.
Also, I have posted sample code that might be useful in this problem space. It can be used
by a bootstrapping program to detect the presence or absence of the .NET Framework 1.0
or 1.1 and service pack level for each. You can find more info about that at
http://blogs.msdn.com/astebner/archive/2004/09/18/231253.aspx.
What am I missing here? Why would you AppSearch for the framework when there's the
MsiNetAssemblySupport property to tell you if it's installed? I can't think of a scenario
where AppSearch would be useful when there's a property for presence of the framework.
Question 64
In my case, I want a RegLocator to check for a path out of the registry and then I want
Signature.Parent to use the path results of the RegLocator. Here's my implementation in
tables...
AppSearch
Property Signature_
INSTALLDIR TeleFormIni
CSCORE FileSearchCsCore
DrLocator
IniLocator
Signature
With this authoring INSTALLDIR (resolved by the IniLocator) does not resolve by the
time I need to use it in the DrLocator.Path
Answer
Unless the order is explicitly specified in the table via an "order" column or guaranteed
through some method explained in the documentation, you should NOT rely on or
assume any particular ordering within a table.
The concept of "order" in an MSI table is specious. MSIs are relational databases with no
inherent order. Maintaining order in a table is not a guarantee of the MSI file format, and
therefore any operation that touches the MSI file is perfectly within its rights to
completely reorder the rows in the table inside the file. Simply opening and closing the
MSI file could reorder the rows, as could "save as...", or poking the summary info, to say
nothing of any operation that actually updates table data such as patch application or
transform customization. Even then, nothing in the MSI SQL engine guarantees a
particular retrieval order unless the SQL statement includes an ORDER BY clause. And
nothing says Orca has to show the rows in a particular order either, unless you've sorted
on a column and even that is merely a UI change. In fact there are scenarios where Orca
does NOT show things in the order retrieved from the database.
Do not try to reverse engineer the behavior of the table processing. It could work fine by
pure luck for months or years and then your third patch causes things to go crazy - you'll
never know.
Off-line it was suggested to me that if there was specific sequencing required, one should
use custom actions explicitly sequenced in the appropriate sequence table.
Editorial Clarification
MSI MVP Stefan Krueger pointed out that the original post (without the tables) did not
make sense in the light of MSDN article Searching for a Directory and a File in the
Directory. After reading through the original query, the code and the SDK, I believe
pinpointed the problem in the authoring. One can't use the value of the Property but one
can connect the dots using the Parent column and pointing it to the earlier Signature_.
DrLocator
• Chris, Microsoft Dev and former MSI Dev. You can get other Chris insights
about developing for Windows Installer from the old Windows Installer Chat
Archives
Comments
Hi,
I'm hoping the Windows Installer team look further into problems similar to the above.
Each request is a need that Windows Installer is not currently meeting. It would be nice
(where possible) for Windows Installer to be updated to support more ordering. For
example I doubt it would be very hard to add an ordering column to the "SelfReg" table
(a common issue in posts).
My 2 cents worth,
Dennis Bareis
Question 65
Any tips on troubleshooting Error 2259: Database: foo.msi Table(s) Update failed?
1: 2259 2: foo.msi 3: 4:
Answer
You're trying to update a primary key column. You can't do that with an update. You
have to delete the existing row and then add a new row.
• Carolyn, MSI Team Dev Lead. You can get other Carolyn insights about
developing for Windows Installer from the Windows Installer Chat Archives
This posting is provided "AS IS" with no warranties, and confers no rights. Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.
Comments
# re: Any tips on troubleshooting Error 2259: Database: foo.msi Table(s) Update
failed
I will delete the row and insert again. This is ok for normal case.
I have one problem on inserting this data to condition column.'REMOVE=""'
I use wnrunsql.vbs for inserting. my problem is - "" (double quotes is not show in orca).
How can I solve this problem?
# re: Any tips on troubleshooting Error 2259: Database: foo.msi Table(s) Update
failed
i was not able to update the Display Column (it is not a primary key) of the feature table
from vb script and it gave me the same 2259 error
Question 66
Is there a way to set ACLs for a service using MSI standard actions or is a custom action
required? If this can only be done through a custom action, does someone have an
existing CA that sets service ACLs that I could use?
Answer
No, there is no standard action to support this. The WiX toolset has custom action
support for this. The CustomAction is very self-contained. The custom action you’ll be
looking for is called SecureObj or Secure Objects.
Question 67
Can someone comment on what consequences would there be if the following ICE27
exceptions were left as is?
Answer
These ICE errors indicate wrong sequences of standard actions. You need to correct
them. SetODBCFolders action needs to come before InstallValidate action, otherwise the
target directory for ODBC driver will not be set correctly. ValidateProductID action
needs to come before RegisterUser action.
Question 68
How can I use a custom action to dynamically populate rows in the table?
Answer
Immediate custom actions have full access to the Windows Installer database. All you
need to do is use the database API to open a view and execute the view. The rest is the
SQL query you create that performs an insert of a temporary row in the database. All of
this, the APIs + SQL queries, are documented on MSDN in the Windows Installer
documentation. If the table needs to be around in memory so that your changes aren't lost
when dropped from view, then add a hold count to it (and release the hold count at the
end after the requisite action runs).
• MsiGetActiveDatabase
• MsiDatabaseOpenView
• MsiViewExecute
Question 69
Can anyone tell me how to make a universal transform or a template transform that will
work on all msi's?
Answer
The following validation conditions are available for a transform (these are stored in the
transform's summary information stream):
MSITRANSFORM_VALIDATE_LANGUAGE
MSITRANSFORM_VALIDATE_PRODUCT
MSITRANFORM_VALIDATE_UPGRADECODE
Any one of the following version specifications (which would also have a validation
equality flag as well)
MSITRANSFORM_VALIDATE_MAJORVERSION
MSITRANSFORM_VALIDATE_MINORVERSION
MSITRANSFORM_VALIDATE_UPDATEVERSION
You would basically want to not validate any of the transform validation conditions that
ensure product code, upgrade code, product version, and product language matching.
Depending on the types of changes you are making, you may want to suppress all of the
error conditions as well to ensure that the transform can be applied without failure.
More specifics on the transform summary information stream can be found in the
MsiCreateTransformSummaryInfo API documentation.
You can easily accomplish this using the msitran.exe tool provided in the Windows
Installer SDK development tools section.
A no validation suppress all error transform would be generated using something similar
to:
Question 70
OS: Windows XP Home SP2 with Automatic updates every day at 3AM; Machine:
Toshiba Satellite M35X-S311; 80% of hard drive free.
My trial version of Office 2003 expired 1/31/06 (no warning messages received prior). I
couldn't access Control Panel (system32/CoPM.cpl error). No System Restore points
prior to 1/31/06.
Ever since 1/31/06, windows installer pops up on every application (explorer, print,
office). "Preparing to Install just hangs there for a couple of minutes -- for everything.
Spyware, adware and malware has been scanned and removed. I've also had my machine
scanned by Hijack this, Norton SystemWorks and Registry Mechanic, and no problem
can be found.
I can't begin to tell you how much this affects my work. I've lost 5 days of writing --
which is how I earn my living -- and I'm obsessed with getting my computer back the
way it used to be.
Please tell me how to fix this -- this is a major disaster for me.
Answer
I'm sorry to hear you're having these problems. It sounds like it's quite frustrating and
you've run out of options. If the following information doesn't allow you to unblock
yourself, I encourage you to call Microsoft Product Support Services.
Creating stable corporate computing platforms was a pillar for the Total Cost of
Ownership initiative for the Windows 2000 generation of releases. Part of that
effort was the Windows Installer Resiliency features. In the controlled
environment of corporate computing, these errors do not occur because the
accompanying infrastructure is maintained to automatically respond to these
issues thereby reducing total cost of ownership for the corporate customer.
Generally, home computers are subject to much less supervisory oversight and
assistance. Without the help of a professional administrator, the quality of the
application experience on Windows is at the discretion of the software vendor.
Software vendor do make mistakes with the Windows Installer Resiliency
features and thus you have this experience.
The Windows Installer Frequently Asked Questions has FAQ items titled:
o Every time I launch my application, Windows Installer performs an
installation. How can I determine the cause of the on-demand installation?
o How can I figure out why my package fails to install?
These entries will allow you to turn on Windows event logging and Windows
Installer package logging which enable you to determine the which executable
(client) and application (package) are providing misinformation to the Windows
Installer service.
Generally, start by contacting the Software Vendor(s) that is (are) causing the
problem. The event and install logs enabled by the above should allow you to find
the offending combination. As a PC is actually a commons, there may be more
than one Software Vendor involved. The Software Vendor should be able to tell
you how to repair their applications. This is a well traveled troubleshooting route
traveled by corporate administrators.
Some home users will give up at this point because they don't have the time or
geek-like persistence to work through all the details. Other home users will say
they don't have media any more, the software company does not exist any more,
or that was an unofficial copy of the application. Still others find their software
provider unable to help them due to lack of knowledge, lack of experience, or a
propensity to blame the other software provider.
Boiler plate suggestions from an ISV may include (in no particular order)
As one will note in the "Stop Installation Idiocy" PCWorld's Hassle Free PC
article, MSIZap is a choice user assistance columnists choose to call out.
This posting is provided "AS IS" with no warranties, and confers no rights. Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.
Comment Notification
If you would like to receive an email when updates are made to this post, please register
here
You can also stay up to date using your favorite aggregator by subscribing to the
CommentRss Feed
Comments
To figure out which installer is failing you have to look in your windows "Event Log".
This is a log of activity on your windows NT based OS. To get to the event log right
click on "My Computer" and select manage. In the list on the left you'll see "Event
Viewer" Select that and then select "Application". If you sort by "Source" You'll see a
huge number of MsiInstaller entries. Looking through those entries will tell you who the
culprit is. If you either uninstall and re-install the offending software or MsiZap the
offending software you'll probably be back in buisiness.
Note that MsiZap can leave your computer in a weird state so that you'll have problems
installing new versions of the software that you've zapped so this should only be used as
a last resort.
Unless you are a person who works at MS, email the team....
=================================================
Windows NT-based operating systems include two utilities for editing the registry,
Regedit.exe and Regedt32.exe
Regedit.exe
Regedit.exe is the configuration editor for Windows XP and Windows Server 2003.
Regedit.exe is used to modify the Windows NT configuration database, or the Windows
NT registry. This editor allows you to view or modify the Windows NT registry. It
supports setting security on registry keys, viewing and editing REG_EXPAND_SZ and
REG_MULTI_SZ, and saving and restoring hive files. On the left side, there are folders
that represent registry keys. On the right side, there are the values associated with the
selected registry key. Regedit is a powerful tool. You must use extreme caution when you
use it to change registry values. Missing or incorrect values in the registry can make the
Windows installation unusable.
Regedt32.exe
3) What is a SERVICE and what are the basic services which open when we start an
log in?
A program, routine or process that performs specific function to support other programs
particularly at low level (Close to Hardware Level).
It’s a program that runs invisibly in the background. Services load and start running
whether or not anyone logs into the computer.
Svchost
Svchost.exe is a generic host process name for services that run from dynamic-link
libraries (DLLs).
Explorer.exe
Svchost.exe
Taskmgr.exe
Note: Application files that can be installed as a service are: .EXE, .VXD, .SYS, or .386
====================================================
1. What is a GPO?
GPO stands for Group Policy object and GPO is an active directory object and using
GPO we can publish and assign packages to users or computers. Apart from that GPO is
also used to control the user and computer con
Publishing will install the application when user invoke the program will get install
locally.
3. On Which container you find the GPO in active directory?
4. What is DFS?
5. Do create two separate MSI for windows 2000 and windows XP and why?
Yes we will create the different MSI for windows 2000 and XP
Because windows 2000 and XP will have different type kernal, dll version, and Cab file.
6. What is WSH?
.VBS
Network object
Shell object
CreateObject
GetObject
SetObject
Err Object
RegExp
The Err object is an intrinsic object with global scope — there is no need to create an
instance of it in your code. The properties of the Err object are set by the generator of an
error — Visual Basic, an Automation object, or the VBScript programmer.
Use the GetObject function to access an Automation object from a file and assign the
object to an object variable. Use the Set statement to assign the object returned by
GetObject to the object variable. For example:
Network object: Provides access to common networking tasks, for example. connecting
a network drive.
Shell object: General purpose object that provides useful methods for manipulating
Windows OS that lets you access all the main features of the OS's GUI. information —
for example, registry access
Dim <Variable>
The simple statement - Option Explicit - tightens up your scripts. What Option Explicit
says is this: if a variable is not declared, then you cannot use it. The use of Option
Explicit is twofold, to make sure that you declare variables, and to troubleshoot by
generating errors to highlight mistakes if variable names are mistyped later in the script.
18 What is ADSI?
Using the .MST, and using ORK tool (Office Resources kit)
What do you means by Default feature and what if the default feature is removed from
the application and the MSI is installed , will it install or not
A user launches a shortcut an it gives an error message “ you don’t have the sufficient
previlages “ what may be the reason for that ?( The exe of the shortcut may be
generating a runtime file during launch and the user doesn’t have the write acess to that
particular folder location)
http://support.microsoft.com/default.aspx?scid=fh;EN-US;KBHOWTO
http://blogs.msdn.com/windows_installer_team/archive/category/10544.aspx
http://www.wise.com/KBSearch.aspx
unique Package Code, which is a GUID. You must change this to a different
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/odc_xl2003_ta/html/odc_super.asp …EXCEL MACRO writing website
ICEERRORS
ICE01
ICE01 validates that the ICE mechanism is working. It does not test anything.
This ICE uses the Time property to get the time and returns either the system
time or None.
Unless there is a problem with the ICE mechanism, ICE01 should never return
an error.
ICE02
ICE02 validates that certain references between the Component, File, and
Registry tables are reciprocal. These references must to be reciprocal for the
installer to correctly determine the installation state of components.
Key path value used for a component in the Component table must be the
primary key of a record in the Registry or File tables depending on the type of
key path. In addition, the value used under Component_ column of File or
Registry tables must be the primary key of the corresponding record in the
Component table. Hence, the references must be reciprocal.
You will need to modify the record so that the reference can be reciprocal.
ICE03
What does ICE03 check?
ICE03 checks the data types and foreign keys based on the _Validation table
and the database tables in the .msi file. The _Validation table is a system table
that contains the column names and the data types for all of the tables in the
database. It is used during the database validation process to ensure that all
columns are accounted for and have the correct values.
ICE03 typically posts an error if a data value is not permitted based on the data
type and table information stored in _Validation Table.
Invalid identifier
The Identifier data type is a text string. Identifiers may contain the ASCII
characters A-Z (a-z), digits, underscores (_), or periods (.). However, every
identifier must begin with either a letter or an underscore.
Invalid Language Id
The database contains an invalid numeric Language Identifier (LANGID). The
Language data type is a text string containing one or more valid numeric
language IDs. If there are two or more language IDs, they must be separated by
commas.
See the platform SDK for a current list of Language Identifiers used by Windows.
For example, 1033 for the U.S. and 0 for language neutral.
Invalid Filename
The Filename data type is a text string containing a file name or folder. By
default, the file name is assumed to use short file name syntax; that is, eight-
character name, period (.), and 3-character extension. To include a long file
name with the short file name, separate it from the short file name with a vertical
bar (|).
Short and long file names must not contain the following characters:
\?|><:/*"
In addition, short file names must not contain the following characters:
+,;=[]
No space is allowed preceding the vertical bar (|) separator for the short file
name/long file name syntax. Short file names may not include a space, although
a long file name may. A space can exist after the separator only if the long file
name of the file name begins with the space. No full-path syntax is allowed.
The Formatted data type is a text string that is processed to resolve embedded
property names, table keys, environment variable references, and other special
substrings. The following conventions are recognized to resolve the string
If a substring of the form [!filekey] is found, it is replaced by the full short path of
the file, with the value filekey used as a key into the File table. This syntax is
valid only when used in the Value column of the Registry or the IniFile tables.
When used in other columns this syntax is treated the same as [#filekey].
Undefined error
Unknown error
You will need to correct the data found in the specified table based on the data
type information stored in _Validation table.
ICE04
ICE04 validates that the sequence number of every file in the File table is less
than or equal to the largest sequence number in the LastSequence column of the
of the Media table.
ICE04 posts an error message if there is a file with a sequence number greater
than the largest LastSequence number for the source media.
ICE05
ICE05 validates that certain database tables contain required entries. The
following properties (i.e. Windows Installer variables) have to be present in the
Property table of any MSI file: ProductName, ProductLanguage, ProductVersion,
ProductCode, and Manufacturer.
You will need to add the required entry or entries to your installation database.
ICE06
ICE06 checks every table to validate that all the columns listed in the _Validation
table are present in the table. The _Validation table is a system table that
contains the column names and the data types for all of the tables in the
database. It is used during the database validation process to ensure that all
columns are accounted for and have the correct values. If a table does not exist,
any _Validation entries for that table are ignored.
ICE06 posts an error if it detects instances in which an author tries to use a new
_Validation table that reflects a schema change with an old database that has not
been updated. ICE06 also detects the reverse case of an old _Validation table
being used with an altered database. Essentially, ICE06 will show up when there
is a table column defined in the _Validation table that is not listed in the
_Columns table.
You will need to update your _Validation table or alter your MSI database
schema.
ICE07
ICE07 checks to see if the installation package is set to install fonts into the
FontsFolder (FontsFolder is a property which gets resolved to the full path of the
system Fonts folder.). If a font is installed to a folder other than the FontsFolder
the installer creates a shortcut rather than actually installing the font.
ICE07 posts an error if the font file is being installed into a folder other than the
FontsFolder.
You will need to specify your fonts files to be installed into the FontsFolder.
ICE08
ICE08 validates that the Component table contains no duplicate GUIDs (i.e.
Globally Unique Identifiers). Every component must have a unique GUID.
Components are storage units for application resources. They are also registered
on the target system for application maintenance. The only way for Windows
Installer to identify which resource belongs to which component is through these
unique identifiers. Components should never ever use the same GUID.
You will need to specify/generate unique GUIDs for each component you have in
your installation database.
ICE09
ICE09 checks to see if a file is set to be installed as a permanent resource (to be left on
the system during uninstall) under SystemFolder (SystemFolder is the property which
gets resolved to the full path of the System folder). Technically, ICE09 validates that the
permanent bit is set for every component marked for installation into the SystemFolder.
ICE09 posts a warning if a file that is set to be installed under System folder is NOT
marked as a permanent resource. Installation authors should avoid installing non-
permanent system components to the SystemFolder.
To prevent this warning, you should mark your files that are set to be installed under
System folder as permanent resources. Technically, you need to set the Permanent bit in
the Attributes column of the Component table for every component that is marked for
installation into the SystemFolder.
ICE10
Child feature should not be set to disallow advertisement, which conflicts with the
allow advertisement state of its parent. So, you should either change the feature
state of the child or the parent. Note that it is valid to set the state of a feature to
0 and have its parent or child set to favor or disallow advertisement.
ICE11
ICE11 validates that a nested MSI installation custom action has a valid identifier
for the source. Technically, ICE11 checks the Source column of the
CustomAction table for Nested Installation custom actions. The Source column
must contain a valid GUID (MSI product code).
ICE11 posts an error if the Source column of the CustomAction table is authored
incorrectly for nested installation custom actions.
The source of a Nested Installation custom action must contain a valid GUID. So,
you should update the source value so that it can represent a valid MSI product
code.
ICE12
Note: ICE12 does not validate the formatted text in the Target column of the
CustomAction table.
ICE12 posts an error message if validation of the custom actions that set a
directory property fails.
Since ICE12 checks more than one thing, you will need to fix your MSI based on
the specific error message returned from ICE12. You may need to do one of the
following to fix ICE12:
• Change the custom action entry in the Source column of CustomAction
table to an existing entry in the Directory table or add the new directory to
the Directory table.
• Change the custom action location in the InstallExecuteSequence table
such that it comes after the CostFinalize action.
• Change the custom action location in the InstallExecuteSequence table
such that it comes before the CostFinalize action.
ICE13
ICE13 checks if any of your installation user interface dialogs in your MSI
database are placed in ExecuteSequence tables. Technically, ICE13 validates
that dialogs in sequence tables appear ONLY in the AdminUISequence, or
InstallUISequence tables. Dialogs must not be listed in the ExecuteSequence
tables (i.e. InstallExecuteSequence, AdminExecuteSequence, and
AdvtExecuteSequence tables).
You should either completely remove the specified dialog from the execute
sequence or cut & paste it to a UISequence table (i.e. AdminUISequence, or
InstallUISequence)
ICE14
ICE14 posts an error message if it finds a root feature with the “Follow Parent”
(i.e., msidbFeatureAttributesFollowParent) bit set or a feature with identical
entries in the Feature and Feature_Parent columns of the Feature table.
Depending on the ICE14 error details, you will need to do one of the following:
ICE15
ICE15 validates that content type and extension references in the MIME and
Extension tables are reciprocal. The MIME table must reference a content type to
an extension that the Extension table references back to the same content type.
Multiple extensions can reference the same MIME type, as long as the MIME
type references back to one of the extensions. Multiple MIME types can
reference the same extension, as long as the extension references back to one
of the MIME types.
ICE15 posts an error if the content type and extension references are not
reciprocal.
ICE16
ICE16 validates that the value of the ProductName property in the Property table
is no greater than 63 characters in length.
ICE16 posts an error message if the ProductName set in the Property table is
longer than 63 characters.
You need to make your Product Name string less than or equal to 63 characters
in length.
ICE17
ICE17 checks more than one situation related to the user interface controls used
on dialogs (if your setup contains dialogs).
When does ICE17 show up?
ICE17 displays an error or warning message if the following rules are not
followed:
ICE18
ICE18 checks if the installation package specifies an empty directory as the key
path of a component that is not listed in the CreateFolder table.
If the KeyPath column of the Component table is Null, this means that directory
listed in the Directory_ column is the key path for that component. Because
folders created by the installer are deleted when they become empty, this folder
must be listed in the CreateFolder table to prevent the installer from attempting to
install every time.
When performing a validation ICE18 first checks whether the following are all
true:
• That the Component_ column of the CreateFolder table has the same
value as the Component column of the Component table.
• That the Directory_ column of the CreateFolder table has the same value
as the Directory_ column of the Component table.
Empty directory used as a key path for a component in the installation package
must be specified in the CreateFolder table.
ICE19
ICE20
ICE20 validates the standard dialogs (i.e. FilesInUse, Error, Exit, UserExit,
FatalError dialogs) and dialog requirements of an installation package having an
authored user interface. Installation packages with an authored user interface
have a Dialog table and the LIMITUI property is not set.
ICE20 posts an error message if it cannot validate that the standard dialogs and
requirements are present in the installation package.
If you use commercial MSI setup development tools, standard dialogs should
already be part of a base MSI template. In other words, ICE20 should never
show up if you create packages based on a base MSI template which contains
these standard dialogs.
ICE21
ICE22
ICE22 posts an error message if the features and components are mapped
incorrectly in the PublishComponent table.
ICE23
ICE23 validates the control tab order for each dialog box. ICE23 verifies that the
tab order forms a single, closed, loop that comes back to the initial control.
Hence, at run-time if you tab from one control to another in the end you should
come back to the control which you started with.
You will need to create a single, closed loop for the tab order. You may need to
modify the data under Control_First column of dialog record found in Dialog table
or data under Control_next column of control record found in Control table.
ICE24
• That the ProductCode Property is a valid GUID data type. The valid format
for a GUID is {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} where
X is a hex digit (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F).
• That the ProductVersion Property is a valid Version data type. The
Version data type is a text string containing a valid version string. A
version string has the format xxxxx.xxxxx.xxxxx.xxxxx where x is a digit.
The maximum acceptable version string is 65535.65535.65535.65535.
• That the ProductLanguage Property is a valid Language data type. The
Language data type is a text string containing one or more valid numeric
language IDs.
ICE24 posts an error message if any of these properties are not in the form of a
valid data type.
ICE25
ICE25 posts an error message if .msi file has previously been merged with an
incompatible merge module or if it has not been merged with a necessary merge
module.
ICE26
ICE26 posts an error message if the installation package has a sequence table
that lacks a required action or that contains an action that is disallowed for the
table.
If a required action is missing from the sequence table, you must add the missing
action to the indicated sequence table. If an action cannot be in the indicated
sequence table, you must remove the action from the sequence table.
ICE27
What does ICE27 check?
• That the actions listed in the Action column of the sequence tables are
standard actions, a custom action listed in the CustomAction table, or a
dialog box listed in the Dialog table.
• That actions subject to sequencing restrictions are in the correct relative
order to each other in the action sequence. Sequencing restrictions result
when one action is dependent on another.
• That actions restricted to a particular section of the sequence are located
where they belong.
ICE27 posts an error message if there are sequence tables in the package with
invalid action sequencing or organization.
If there is an action that is in wrong place in the sequence table, you must
change the sequence number of the action to place it to the correct location in
the sequence.
ICE28
ICE29
MSI file is designed as a Win32 OLE structured storage and handling of streams
by the Win32 OLE structured storage implementation limits stream names. The
installer can compress stream names up to 62 characters in length. Names
longer than this are truncated. ICE29 validates that truncated stream names
remain unique. Any table having a Binary or Object column is validated.
You must change the truncated stream name to a unique name to fix this error.
ICE30
ICE30 validates that the installation of components containing the same file
never installs the file more than once in the same directory. ICE30 checks both
long file names (LFN) and short file names (SFN).
ICE30 can detect file collisions due to directories with the same property in their
paths, but does not detect collisions resulting from two properties having the
same value due to possible change of a property value at run-time.
ICE30 posts an error message for each pair of components that installs the same
file to the same directory.
Unless two (or more) components have mutually exclusive conditions, they must
not install the same file to the same location. Doing so will break the component
reference counting system.
In order to fix ICE30, you should either conditionalize both components or make
sure that components install the file to different targets.
ICE31
Controls can have a predefined font style. To set the font and font style of a text
string, you need to prefix the string of displayed characters with {\style} or
{&style}. Where style is an identifier listed in the TextStyle column of the
TextStyle table. If neither of these are present, but the DefaultUIFont property is
defined as a valid text style, that font will be used.
ICE31 checks the Text column for each control in the Control Table to verifies
that a valid entry exist in the TextStyle table.
ICE31 posts an error message for undefined styles, style names that are too
long, a missing TextStyle table, and style tags with no closing brace.
ICE31 posts a warning if the style tag is not at the beginning of the line, or if a
control has multiple style tags
If the error is due to a long style name, you will need to shorten the name so that
it can contain less than 72 characters. A style that is over 72 chars and therefore
cannot possibly be a style even if somehow you did manage to get it in the
TextStyle table.
If the error is because of the missing TextStyle table, it has to be added to the
MSI and then style records have to be added to the table.
If the error is due to a style tag with no closing brace, a closing brace has to be
added to the Text column of the control record in Control table.
If ICE31 posts a warning because of a style tag not at the beginning of the line,
the tag has to be replaced to the beginning of the line under the Text column of
the control record in Control table.
If ICE31 posts a warning due to multiple style tags, only one of the tags have to
be left by removing the others from the Text column of the control record in
Control table.
ICE32
ICE32 validates that keys and foreign keys in the .msi file are of the same size
and column definition types. This ICE custom action makes the comparison using
the _Validation table and using the definition types that are returned by
MsiViewGetColumnInfo.
ICE32 posts errors if the .msi file contains any foreign keys to keys of a different
column length or column data type.
If the foreign key and key defined differ in size, you should change the data type
length to match.
If there is a foreign key and key defined that differ in their definition types, the
foreign key and key pairs must be defined so that their data types match.
Note: As long as you use a good MSI template to start with and do not manually
add any extra custom tables to the database, you should never see any ICE32
errors.
ICE33
ICE33 validates that the all the entries in the Registry table belong in that table.
Even though Registry table is used to create/edit registry keys on the target
machine, it is not the only table used to do this task. Registry keys that register
Classes, Filename Extensions, ProgIDs, Shell Verbs, Remote Server AppIDs,
MIME types, or Typelibs are considered as special keys because they can be
used as advertised entry points to the application. Maximizing the number of
advertised entry points to the application increases the chances that the
application can trigger self-repair in a situation where the application is expected
to fail. Technically entering these special registry keys to Registry table does not
create any problems as far as the application functionalities and the setup are
concerned. These special keys will still be registered by means of Registry table.
However, Windows Installer service will not consider these keys as advertised
entry points to the application. Hence, they will not be able to trigger self-repair if
needed. Use of Extension, ProgId, Verb, MIME, Class, Typelib and AppId tables
provides the extra benefit by maximizing your potential for self-healing.
The other disadvantage of keeping ICE33 warnings in your MSI package is the
fact that you will not be able to fully advertise your product if you want to utilize
advertising features of Windows Installer. That means, installation-on-demand
will be limited to only advertised shortcuts but not other entry points such as file
extensions or MIME types. That is because advertising simply puts down the
advertised entry points to the target machine and postpones the rest of the
installation to a time that the application is somehow triggered by an advertised
entry point. If Registry table is used to store those entry points such as file
extensions, they will not show up during advertisement. They will only show up
when the application is fully installed.
ICE33 issues a warning for each Registry table entry that should be moved and
suggests the appropriate table. ICE33 posts warnings for any entries that register
Classes, Filename Extensions, ProgIDs, Shell Verbs, Remote Server AppIDs,
MIME types, or Typelibs.
The fix is to move those special registry entries to the table(s) suggested by the
warning. However, unless you are very familiar with registry as well as the
application, it is not recommended to move them especially in a repackaging
situation. Taking such an action without much familiarity with registry and the
application can cause more problems with your MSI package.
Extensions, ProgIds, Verbs, and MIME types must be registered through their
respective Extension, ProgId, Verb, MIME tables to support advertisement and
install-on-demand. Entries in the Registry table are not written to the registry until
the component controlling the value is installed to run Locally or to Run From
Source. This precludes the advertisement of components registered through the
Registry table. It also precludes install-on-demand for any feature or product
requiring the component because advertisement is the only way install-on-
demand is available through the Windows Shell.
For Windows 2000, COM Classes must be registered through the Class table to
advertise CLSID Contexts and for install-on-demand.
Note that the tables available cannot handle all possible COM registration. In
these cases an author should enter as much information as possible into to the
individual tables and the remaining information into the Registry table. A common
authoring error that must be avoided in this case is that of duplicating an entry in
both a COM table and in the Registry table.
It is easier to manage registry keys if they are listed in the appropriate tables
rather than being mixed together into the Registry tables. The values in the
Typelib and AppId tables are registered when the component controlling the
value is installed to run Locally or From Source. These tables are provided for
the convenience of setup authors.
ICE34
o Every RadioButton
control entry without the
indirect attribute set has a
property listed in the Property
column.
o Every such property
has at least one
corresponding entry in the
RadioButton table.
o Every such property is
defined in the Property table,
with a value that is one of the
choices from the RadioButton
table.
o Every property
referenced in the Property
column of a RadioButton
control with the indirect
attribute set is defined in the
Property table.
ICE35
ICE35 queries the Cabinet column of the Media table to determine which files are
compressed and stored in a cabinet file. It queries the File table to determine
which components contain these files. Finally, it checks the Component table to
determine whether the run-from-source bits are set in the Attributes column.
To fix this error/warning you must change the bit set in the Attributes column of
the Component table so that it will be set to run locally, or remove the file from
the CAB file.
ICE36 checks if the package contains unused icons that reduces the installer
performance. ICE36 validates that every icon in the Icon table is listed at least
once in the ARPPRODUCTICON property or the Class, ProgId, or Shortcut
tables.
During advertisement, the installer installs all the icons listed in the Icon table on
the user's computer. Having unused icons in the Icon table does not prevent the
installation from running, however it does unnecessarily increase the size of
the .msi file and the time and space required to advertise a feature.
ICE36 posts a message if there is an icon in the Icon table that is not referenced
in the Class, ProgId, or Shortcut tables and if there is no UI provided to create
such a reference at run time.
ICE38
ICE38 validates that every component being installed under the current user's
profile also specifies a registry key under the HKEY_CURRENT_USER root in
the KeyPath column of the Component table.
ICE38 posts an error if a component installed under the user's profile does not
specify a HKCU registry key.
• If a component with a file key path, installs to user profile, it must use a
registry key under HKCU as its Key Path, not a file. To fix this error on the
component, change the component key path type to registry key path and
set the key path to a HKCU key.
• If a component with a key path value set to NULL, installs to user profile, it
must use a registry key under HKCU as its Key Path, not NULL. To fix this
error on the component, change the component key path type to registry
key path and set the key path to a HKCU key.
• If a component with a registry key path value set to a HKLM registry key,
installs to user profile, it must use a registry key under HKCU as its Key
Path, not a HKLM registry key. To fix this error on the component, set the
key path to a HKCU key.
• If a component with a registry key path value set as NULL, installs to user
profile, it must use a registry key under HKCU as its Key Path, not NULL.
To fix this error on the component, set the key path to a HKCU key.
• If the Registry entry referenced in the KeyPath column of the component
was found and lies under the HKCU tree, but the registry entry's
Component_ column does not refer back to the same component that
listed it as the KeyPath, this means that the registry entry used as the
KeyPath of the component would only be created when some other
component was installed. To fix this error change the KeyPath value to
refer to a registry entry that belongs to the component, or change the
registry entry to belong to the component using it as a KeyPath.
ICE39
ICE40
• ICE40 checks if the .msi file is missing the Error table and the Page Count
Summary Property is less than or equal to 100. This means that the
installer is only capable of displaying numeric error codes to the user at
run time. The Error table is only required in packages having a schema
that is less than or equal to 100. Windows Installer versions 1.1 and later
do not require the package to have an Error table because the error
messages can also be retrieved using Msimsg.dll. Packages with a
schema greater than 100 cannot be installed by Windows Installer version
1.0.
• ICE40 checks if the REINSTALLMODE property has been overridden.
• ICE40 also checks if the RemoveIniFile table has a Delete Tag entry with
no value.
• ICE40 posts an error if the .msi file is missing the Error table and the Page
Count Summary Property is less than or equal to 100.
• ICE40 posts an error if REINSTALLMODE property is defined in the
Property table.
• ICE40 posts an error if there is a Delete Tag action in the in the
RemoveIniFile column of the RemoveIniFile table without specifying a tag
to delete in the Value column.
• If the .msi file is missing the Error table and the Page Count Summary
Property is less than or equal to 100, add an Error table to the installation
package and author formatting templates in the Message column for error
messages.
• If REINSTALLMODE property is defined in the Property table, remove it
from the Property table. Defining the REINSTALLMODE property in .msi
file can lead to unexpected behavior.
• If there is a Delete Tag action in the in the RemoveIniFile column of the
RemoveIniFile table without specifying a tag to delete in the Value column,
add a tag to delete in the Value column of RemoveIniFile table for that
specific record.
ICE41
ICE41 checks if the package contains any feature that does not contain the
component implementing the class object or extension. If the package contains
such a feature, the installer does not install the component with the feature and
that advertising may not work as expected.
ICE41 validates that the entries in the Class and Extension tables refer to entries
in the Component table that implement the class object or extension of the
component.
ICE41 posts an error if there is a feature that does not contain the component
implementing the class object or extension.
ICE42
ICE42 also validates that only LocalServer and LocalServer32 classes have
arguments and DefInProc values.
ICE42 posts an error if there are InProc servers linked to EXE files in the Class
table.
ICE43
ICE43 validates that shortcuts that do not reference a feature as their Target
(non-advertised shortcuts) are in components having a HKCU registry entry as
their key path.
ICE44
ICE44 posts an error message if there is a dialog control event that does not
reference a dialog box listed in the Dialog table.
ICE45 validates that bit field columns in the database do not set any reserved
bits to 1.
ICE45 posts an error message if any of the following tables contains a bit field
with a reserved bit set to a value of 1.
• BBControl table
• Dialog table
• Feature table
• File table
• MoveFile table
• ModuleConfiguration table
• ODBCDataSource table
• Patch table
• RemoveFile table
• ServiceControl table
• ServiceInstall table
• TextStyle table
ICE45 posts one of two warning messages if the Control Table contains a bit field
with a reserved bit set to a value of 1.
To avoid ICE45, do not set any reserved bits to 1 for bit field columns in the
database.
ICE46
If you receive ICE46, verify that those two properties mentioned in the
informational message are NOT the same. Since properties are case sensitive, a
property name with lower case characters is different than the same property
name with upper case characters (even if the difference is only one character
being upper case or lower case).
ICE47
ICE47 checks the Feature and FeatureComponents tables for features with 1600
or more components.
ICE47 posts an error message if a feature exceeds the maximum limit of 1600
components per feature on Windows NT, Windows 2000, Windows XP and 800
components per feature on Windows 95, Windows 98, Windows Millennium
Edition (Windows Me).
To fix this warning, try splitting the feature into several features.
ICE48 checks for directories that are hard-coded to local paths in the Property
table.
Do NOT hard-code directory paths to local drives because computers differ in the
setup of the local drive. This practice may be acceptable if deploying an
application to a large number of computers on which the relevant portions of the
drives are all the same.
ICE49
ICE49 checks for default registry entries that are not a REG_SZ type.
ICE49 posts an error if there is a default registry entry that is not a REG_SZ type.
To fix this error, make installation of the component conditional upon the target
not being a Windows 95 computer, or change the value to type REG_SZ.
Where can I get more information?
ICE50
ICE50 checks that shortcut icons are specified to display correctly and match
their target file's extension.
ICE50 posts an error message if the extension of the icon and target files do not
match. ICE50 posts a warning if icons are stored in files that do not have an .exe
or .ico extension.
• If the extensions of the icon and the target file do not match, the shortcut
will not have the correct context menu when the component is advertised.
To fix this error, rename the icon to match the extension of the target file.
• Some versions of the shell incorrectly display icons stored in files that do
not have extensions of "exe" or "ico". To fix this warning, rename the icon
have an extension of "exe" or "ico".
ICE51
ICE51 checks for TTC/TTF fonts that have titles and other fonts that are missing
titles.
ICE51 posts an error or warning if there are any TTC/TTF fonts with titles or
other fonts missing titles.
You must specify a title for fonts that do not have embedded names.
TTF/TTC fonts have the title of the font embedded in the file itself. Do not specify
a title for these fonts because the font is then registered twice, once under the
supplied name and again under the embedded name.
ICE52
The AppSearch table contains properties needed to search for a file having a
particular file signature. The AppSearch table can also be used to set a property
to the existing value of a registry or .ini file entry.
When using Windows 2000 all properties set in the Property column of the
AppSearch table must be public properties.
Note: Private property names must include lowercase letters. However, public
property names cannot contain lowercase letters.
To fix this warning change the private property found in the AppSearch table to a
custom public property.
ICE53
ICE53 checks for entries in the Registry table that write private installer
information or policy values to the system registry.
The package should not specify any system policy value in the registry. System
policies should be configured without an installer package.
Note: Windows Installer specific system policy values can be found under
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer
ICE54
ICE54 checks for components that use a companion file as their key path.
ICE54 posts a warning if any component has a key path file that derives its
version from another file.
The key path file of a component must not derive its version from a different file.
This can cause some files to fail to install. To fix this warning, change the key
path of the component to another file whose version is not derived from a
different file and found in the same component.
Note: For companion files, the Version field of the File table can be set to contain
the primary key of another record in the File table. The referenced file then
determines the versioning logic for this file.
ICE55
ICE55 post an error if a LockObject listed in the LockPermissions table does not
exist or if no privilege level is specified in the Permission column.
ICE56
ICE56 validates that the directory structure of the .msi file has a single root
directory, that the root is the TARGETDIR property, and that the SourceDir
property value is in the DefaultDir column of the Directory table.
If a .msi file has multiple roots or specifies a root other than TARGETDIR, an
administrative installation does not create a correct administrative image.
Note: Empty directories are not checked by ICE56. The directory structure
passes validation with multiple root directories if the extra directories are empty.
ICE56 posts an error if the .msi does not have a single root, TARGETDIR, or if
SourceDir is not specified in the DefaultDir column of the Directory table.
ICE57
ICE57 validates that individual components do not mix per-machine and per-user
data. This ICE custom action checks registry entries, files, directory key paths,
and non-advertised shortcuts.
Mixing per-user and per-machine data in the same component could result in
only partial installation of the component for some users in a multi-user
environment. For example, after the installation for everyone on the same
machine, a new user may not be able to get per-user data due to the poor design
of components. This can lead to application run-time problems.
ICE57 posts an error if it finds any component that contains both a per-machine
and per-user registry entries, files, directory key paths, or non-advertised
shortcuts.
To fix ICE57 errors, reorganize the application such that each component
contains only per-user or per-machine resources, and not both.
ICE58
ICE58 checks that your Media table does not have more than 80 rows.
When does ICE58 show up?
ICE58 posts a warning if the package contains more than 80 rows in the Media
table and the package's Page Count Summary Property is less than 150.
Warnings reported by ICE58 cause the installation to FAIL unless the package is
installed with Windows Installer version 2.0 or later. Beginning with Windows
Installer version 2.0, the restriction to more than 80 media table entries is
removed. No warning is issued if the package's Page Count Summary Property
is greater than or equal to 150. Packages of schema 200 or higher can only be
installed by Windows Installer version 2.0 or later.
To fix this error, eliminate any unused media table entries, consolidate media
table entries that refer to the same media, and repackage your application to
reduce the media required.
Note: If the target machines are known to have Windows Installer version 2.0 or
later, ICE58 can be safely ignored.
ICE59
ICE59 checks that advertised shortcuts belong to components that are installed
by the target feature of the shortcut.
Target of an advertised shortcut must point to a valid feature and the component
it refers to must be part of the target feature.
The advertised shortcut will launch the Windows Installer to install the feature
listed in the Target column. But because the FeatureComponents table does not
map the target feature to the component containing the shortcut, the keyfile of
the component (which is activated by the shortcut) is not installed. Therefore the
shortcut is broken and will not do anything.
ICE60
ICE60 checks that files in the File table meet the following condition:
• If the file is not a font and has a version, then it must have a language.
• ICE60 checks that no versioned files are listed in the MsiFileHash table.
• ICE60 posts a warning or an error if a file in the File table that is not a font
and has a version, does not have a language.
• ICE60 posts an error if a file listed in the MsiFileHash table is versioned.
ICE61
ICE61 checks the upgrade table to ensure that the following conditions are true:
ICE61 posts a warning or error if any of the above conditions are not true.
• If the VersionMax value in the Upgrade table is NOT less than the product
version in the Property table (i.e., ProductVersion), the installer will try to
remove the product of the same version or higher. To fix this error, use a
version in the VersionMax column lower than the current version specified
in the Property table. Remove the “Include maximum version” option if
Maximum Version is equal to the current version. If the intent is only to
detect the product and not remove it, specifying “Detect Only” will also fix
this error.
• If the ActionProperty is not listed in the SecureCustomProperties property,
the property is not passed to the server side of the install when the
property is found. To fix this error, add the property to
SecureCustomProperties (i.e., make it a restricted public property).
• If the ActionProperty contains lowercase letters, edit the property name to
have all uppercase letters. Upgrade properties must be public properties
for the result to be passed to the server side of the installation.
• If the same ActionProperty is used for more than one record of the
Upgrade table, use a different property for the second record. A property
can only be used in one row of the Upgrade table.
• If Upgrade.VersionMax is less than Upgrade.VersionMin, update the
VersionMax value to be higher than VersionMin. The minimum version
must be less than the maximum version.
ICE62
ICE62 performs extensive checks on the IsolatedComponent table for data that
may cause unexpected behavior.
IsolatedComponents table is used to specify that the installer copy the shared
files (commonly shared DLLs) of an application into that application's folder
rather than to a shared location. This private set of files (DLLs) are then used
only by the application. Isolating the application together with its shared
components in this manner has the following advantages:
• The application always uses the versions of the shared files with which it
was deployed.
• Installing the application does not overwrite other versions of the shared
files by other applications.
• Subsequent installations of other applications using different versions of
the shared files cannot overwrite the files used by this application.
Failure to fix an error reported by ICE62 can result in a failure of the isolated
component system in a wide variety of ways. For example, if the shared DLL
reference counter is not incremented for a shared component, the registration for
the component could be removed when another application uses that
ComponentId and is uninstalled.
ICE62 posts a warning or error when it finds data in the IsolatedComponent table
that may produce unexpected behavior.
ICE63
Note: The RemoveExistingProducts action goes through the product codes listed
in the Upgrade column of the Upgrade table and removes the products in
sequence by invoking nested installations. For each nested installation the
installer sets the ProductCode property to the product code and sets the
REMOVE property to the value in the Remove field of the Upgrade table. If the
Remove field is blank, its value defaults to ALL and the installer removes the
entire product.
Failure to fix a warning or error reported by ICE63 leads to failure of the upgrade.
ICE64
ICE64 checks that new directories in the user profile are removed correctly in
roaming scenarios.
ICE65
ICE65 checks that the Environment table does not have invalid prefix or append
values.
Note: The Environment table is used to set the values of environment variables.
Failure to fix a warning or error reported by ICE65 generally leads to problems in
install, uninstall, or repair of the environment variable. For example, only some
values of a particular variable may be removed if one or more of the values for
that variable have a trailing separator.
The following is the list of valid prefixes for environment variable names:
• “=” Create the environment variable if it does not exist, and then set it
during installation. If the environment variable exists, set it during the
installation.
• “+” Create the environment variable if it does not exist, then set it during
installation. This has no effect on the value of the environment variable if it
already exists.
• “-“ Remove the environment variable when the component is removed.
This symbol can be combined with any prefix.
• “!” Remove the environment variable during an installation. The installer
only removes an environment variable during an installation if the name
and value of the variable match the entries in the Name and Value fields
of the Environment table. If you want to remove an environment variable,
regardless of its value, use the '!' syntax, and leave the Value field empty.
• “*” This prefix is used with Microsoft Windows NT/Windows 2000 to
indicate that the name refers to a system environment variable. If no
asterisk is present, the installer writes the variable to the user's
environment. Microsoft Windows 95/98 ignores the asterisk and add the
environment variable to autoexec.bat. This symbol can be combined with
any prefix. A package that is used for per-machine installations should
write environment variables to the machine's environment by including * in
the Name column. For more information, see Remarks.
• “=-“ The environment variable is set on install and removed on uninstall.
This is the usual behavior.
• “!-“ Removes an environment variable during an install or uninstall.
ICE65 posts a warning or an error if the environment table has invalid prefix or
append values.
To fix ICE65, use valid prefix and/or append values based on Environment table
guidelines mentioned above.
ICE66
ICE66 uses the tables in the database to determine which schema your database
should use.
ICE67
ICE67 checks that the target of a non-advertised shortcut belongs to the same
component as the shortcut itself, or that the attributes of the target component
ensure that it does not change installation locations.
Failure to fix a warning or error reported by ICE67 can cause the shortcut to be
invalid if the target component changes state and the source component does
not. For example, when the target file's component is set to run from source, a
reinstallation that changes the component to local results in the component
containing the shortcut not being reinstalled. Thus the shortcut points to an
invalid location.
ICE68
ICE68 checks that all custom action types needed for an installation are valid.
Failure to fix the error reported by ICE68 causes an installation that attempts to
execute the action to fail.
ICE68 issues a warning if the action is set to run in system context without
specifying it as a deferred execution custom action.
ICE69
To fix this error, do not cross-reference components. You must change the
[$componentkey] to match its own component instead of another component.
ICE70
ICE70 verifies that integer values for registry entries are specified correctly.
Values of the form ##str, #%unexpanded str are not validated. Values of the form
#xhex, #Xhex, #integer, and #[property] are validated. ICE70 checks for valid hex
characters (0-9,a-f,A-F). and for valid numeric characters (0-9).
ICE70 reports an error if integer and/or hex values for registry entries are not
specified correctly.
To fix ICE70, use valid values for numeric and/or hex values for registry entries.
ICE71
What does ICE71 check?
ICE71 verifies that the Media table contains an entry with DiskId equal to 1.
(Windows Installer assumes that the .msi package is on disk 1.)
ICE71 returns an error if the Media table does not contain an entry with DiskId
equal to 1.
To fix this error, change the DiskId of the entry where the package is stored to 1.
ICE72
ICE72 verifies that non-built-in custom actions are not used in the
AdvtExecuteSequence table. Specifically, only type 19 (i.e., Cancel Installation),
type 35 (i.e., Set Directory), and type 51 (i.e., Set Property) custom actions are
allowed in the AdvtExecuteSequence table. If other custom actions are used,
advertisement may not behave as expected.
To fix the error, remove custom actions other than type 35, type 51, and type 19
from the AdvtExecuteSequence table.
ICE73
What does ICE73 check?
ICE73 verifies that your package does not reuse package codes, upgrade codes,
or product codes of the Windows Installer SDK samples. Packages should never
reuse the package, upgrade, or product codes of another product.
To fix ICE73 errors, generate a new unique GUID for your package's product,
package and upgrade codes.
ICE74
ICE74 verifies that the FASTOEM property has not been authored into the
Property table.
The FASTOEM property enables OEMs to reduce the time required to install
Windows Installer applications for the first time. It cannot be used after the first
install. The FASTOEM property must not be authored in the Property table
because this interferes with subsequent installations for the maintenance,
removal, or repair of the application.
ICE74 also verifies that the UpgradeCode property is authored into the Property
table, and that its value is not a null GUID, {00000000-0000-0000-0000-
000000000000}.
• ICE74 posts error if the FASTOEM property has been set in the Property
table.
• ICE74 also posts error if UpgradeCode is not found in the Property table
or set to a NULL GUID.
ICE75
ICE75 verifies that all Custom Action Type 17 (DLL), Custom Action Type 18
(EXE), Custom Action type 21 (JScript), and Custom Action Type 22 (VBScript)
custom actions are sequenced after the CostFinalize action. These types of
custom action use an installed file as their source. ICE75 checks the
InstallUISequence Table, InstallExecuteSequence Table, AdminUISequence
Table, and AdminExecuteSequence Table.
This ICE75 custom action is only available for Windows Installer version 2.0 or
later.
ICE75 posts an error if it finds a custom action using an installed file as a source
file that is not sequenced after the CostFinalize action.
To fix ICE75 errors, sequence the custom actions after the CostFinalize action.
ICE76
ICE76 verifies the use of the SFP (i.e., System File Protection or WFP - Windows
File Protection) catalog within Windows Installer packages for Windows Me.
ICE76 also verifies that no files in the BindImage table reference SFP catalogs.
Note: The BindImage table contains information about each executable or DLL
that needs to be bound to the DLLs imported by it.
Windows File Protection requires an exact match between the file and the
signature embedded in the catalog file. Files that reference a SFP catalog must
not be listed in the BindImage table because the effect of the BindImage action
on these files differs between computers. Files referenced by SFP catalogs must
be in components that are permanent or installed locally.
ICE76 posts an error for each file in the BindImage table that is also in the
FileSFPCatalog table.
If a file references a SFP catalog, it can not be in the BindImage table. To fix
ICE76, do not enter any files that reference SFP catalogs into the BindImage
table.
ICE77
ICE77 verifies that deferred custom actions are sequenced after the
InstallInitialize action and before the InstallFinalize action. ICE77 checks the
sequence in the InstallExecuteSequence table and AdminExecuteSequence
table.
To fix ICE77 errors, sequence the in-script (deferred) custom actions after the
InstallInitialize action and before the InstallFinalize action. The InstallInitialize and
InstallFinalize actions must be present in the InstallExecuteSequence table and
the AdminExecuteSequence table.
ICE78
ICE78 verifies that the AdvtUISequence table either does not exist or is empty.
This is required because no user interface is allowed during advertising.
ICE78 posts an error if the AdvtUISequence table exists and is not empty.
To fix ICE78 error, either remove the action from the AdvtUISequence table, or
remove the AdvtUISequence table from the package.
ICE79
Note: The Condition data type is a text string containing a valid conditional
statement that can be evaluated as true or false.
When does ICE79 show up?
• To fix ICE79 error, enter valid records for conditions of feature and
conditions in the Feature and the Condition table.
• To fix ICE79 warning, add the _Validation table (if missing) in the
database.
ICE80
ICE80 checks the Component Table for any 64-bit components and checks the
CustomAction Table for any 64-bit scripts.
ICE80 verifies that a package with "Intel64" in its Template Summary Property
also has a Page Count Summary Property (PID_PAGECOUNT) of at least 150
(i.e., Windows Installer version 1.1).
ICE81
• ICE81 posts warning if all or some Digital Certificate records are unused in
the installation database.
• ICE81 posts error the Media table does not exist but MsiDigitalSignature
has entries.
• ICE81 posts error if the Media table exists, but the entry in
MsiDigitalSignature is not present in Media table.
• ICE81 posts error if a signed object's cabinet does not point to external
data.
ICE82
Note: Not having all these actions prevents the application from being listed in
Add/Remove in the control panel and prevents the advertisement of the
application. Removing all of these actions prevents the application from being
registered with the Windows Installer configuration data. This means that you will
no longer be able to remove, repair, or reinstall the application using the
Windows Installer Command Line Options or the Windows Installer application
programming interface.
ICE83
This ICE custom action posts an error if the key path for a component containing
a Win32 assembly is set to the manifest file. Explicitly the error is posted if the
value entered in the KeyPath field of the Component table equals the value
entered in the File_Manifest field of the MsiAssembly table. This ICE custom
action posts an error if there is at least one record in the MsiAssembly table and
the InstallExecuteSequence table does not contain both the
MsiPublishAssemblies Action and MsiUnpublishAssemblies Action.
• ICE83 posts an error when the KeyPath field for a Win32 Assembly is set
to its manifest file.
• ICE83 posts an error when there is at least one entry in the MsiAssembly
table but the InstallExecuteSequence table does not contain both the
MsiAssemblyPublish action and the MsiAssemblyUnpublish action.
ICE84
• CostInitialize action
• CostFinalize action
• FileCost action
• InstallValidate action
• InstallInitialize action
• InstallFinalize action
• ProcessComponents action
• PublishFeatures action
• PublishProduct action
• RegisterProduct action
• UnpublishFeatures action
ICE84 posts a warning if a required action has been authored with a condition.
To fix ICE84, remove the conditions around required actions listed above.
ICE85
ICE85 validates that the SourceName column of the MoveFile table is a valid
long file name. This field may contain wildcard characters (* and ?).
ICE85 posts an error if the SourceName field in the MoveFile table is not a valid
long file name.
ICE86
ICE86 issues a warning if the package uses the AdminUser property in database
column of the Condition type. Package authors should use the Privileged
property in conditional statements.
Note: The installer sets the AdminUser property on Windows NT/Windows 2000
if the user has administrator privileges. This property is always set on Windows
95 and Windows 98.
Note: The installer only sets the AdminUser property if the user is an
administrator. The installer sets the Privileged property if the user is an
administrator or if policy enables the user to install with elevated privileges.
ICE87
ICE87 posts a warning if one of the properties listed above is authored into the
Property table. Doing so might cause the product to not be uninstalled correctly.
To fix ICE87 warning, set the property on a command line instead of the Property
table. For example, msiexec /I setup.msi ADDLOCAL=Feature1,Feature2
ICE88 validates that the directory referenced in the DirProperty column of the
IniFile table exists in the Windows Installer package.
ICE88 issues a warning if the DirProperty value does not represent a property in
the Directory, AppSearch, or Property tables, certain system folder properties, or
a property set by a type 51 custom action.
• Directory Table
• AppSearch Table
• Property Table
• CustomAction Table, where the custom action is a Custom Action Type 51
(i.e., Set Property)
• ProgramFilesFolder Property
• CommonFilesFolder Property
• SystemFolder Property
• ProgramFiles64Folder Property
• CommonFiles64Folder Property
• System64Folder Property
To fix ICE88 warning, make the directory property referenced in the DirProperty
column of the IniFile table available by means of one of the alternative methods
listed above.
ICE89
Note: The ProgId table contains information for program IDs and version
independent program IDs that must be generated as a part of the product
advertisement.
ICE89 posts an error if a ProgId_Parent value in the ProgId table is not a valid
ProgId.
To fix ICE89 error, add a new record for the parent ProgId in the ProgId table.
ICE90
ICE90 validates the Shortcut table and uses the Directory table. It checks if a
shortcut’s directory is specified as a public property and is under user profile
directory.
ICE90 posts a warning if it finds that a shortcut's directory has been specified as
a public property and is under user profile directory.
To fix this warning, change your property name to become a private property
(i.e., use at least one lowercase letter in the name). If a private property is used,
you should NOT give any “Select Shortcut Folder” or “Program Group” type of
option on the user interface of your installer.
Note: On Windows XP, Windows 2000, and Windows NT, you cannot set a
private property in the user interface phase of the installation and then pass the
value to the execution phase. On earlier systems, this is possible because the
user interface and execution sequences run in the same process.
ICE91
ICE91 checks if a file, .ini file, or shortcut file is installed into a per-user only
directory. ICE91 warnings are harmless if the package is only used for per-user
installations and never used for per-machine installations.
Files, .ini files, or shortcuts in per-user only directories are installed into a
particular user's profile. Even if the user sets the ALLUSERS property for a per-
machine installation, files, .ini files, or shortcuts in per-user only directories are
not copied in to the "All Users" profile and are not available to other users. The
per-user only directories do not vary with the ALLUSERS property. The following
is a list of the per-user only directories:
• AppDataFolder
• FavoritesFolder
• NetHoodFolder
• PersonalFolder
• PrintHoodFolder
• RecentFolder
• SendToFolder
• MyPicturesFolder
• LocalAppDataFolder
If a file or .ini file, or shortcut is set to be installed to the per user directory that
doesn't vary based on ALLUSERS value, this specific resource won't be copied
to each user's profile even if a per machine installation is desired.
ICE 91 warning message means that the MSI will only install the resource into
the user profile for the user account that executes the MSI, but not for any other
user accounts on the same machine.
If the resource must be copied to each user’s profile, then add functionality to
your package to do this. To achieve this, add a current user registry key (i.e., just
a dummy registry key) and make this registry key the key path of the component
which contains the resource. This means that the resource will be copied to the
next user’s profile as part of the MSI self healing mechanism, provided that
advertised entry points exist for the product.
ICE92
ICE92 checks the Component Table for components without a GUID specified in
the ComponentId field and verifies that they are not specified as permanent
components. Permanent components are left behind after uninstalling the
application.
If the ComponentId column is null, the installer does not register the component
and the component cannot be removed or repaired by the installer.
To fix ICE92, assign a GUID to the component or remove the permanent mark
from the component.
ICE93
ICE93 checks if a custom action uses the same name as a standard action.
ICE93 issues a warning if a custom action uses the same name as a standard
action.
To fix ICE93, rename your custom action to a name other than standard action
names.
ICE94
ICE94 checks the Shortcut table, Feature table, and MsiAssembly table and
posts a warning if there are any unadvertised shortcuts pointing to an assembly
file in the global assembly cache.
Note: If the entry in the Target field of the Shortcut table is not a feature in the
Feature table, the shortcut is unadvertised. If the entry in the Component_ field of
the Shortcut table is also listed in the MsiAssembly table, the shortcut points to
an assembly file. If the entry in the File_Application field in the MsiAssembly table
is empty, the assembly file is in the global assembly cache.
ICE95
ICE95 checks the Control table and BBControl table to verify that the billboard
controls fit onto all the billboards.
Note: The BBControl table lists the controls to be displayed on each billboard.
The Control table defines the controls that appear on each dialog box.
To fix ICE95, resize and/or reposition the billboard to fit on the billboard.
ICE96
ICE96 verifies that the PublishFeatures action and the PublishProduct action are
entered in the AdvtExecuteSequence table. A package cannot be advertised
without these actions.
Note: The PublishFeatures action writes each feature's state into the system
registry.
Note: The PublishProduct action manages the advertisement of the product
information with the system. It publishes the product if the product is in advertise
mode or if any feature is being installed or reinstalled.
ICE98
ICE98 verifies that data source names (DSN) that use the ODBCDataSource
Table do not contain invalid characters and do not exceed the maximum length
of SQL_MAX_DSN_LENGTH (32 characters).
To fix ICE98, use a valid data source name which is less than 32 characters.
ICE99
ICE99 verifies that that no property name entered in the Directory table
duplicates a name reserved for the public or private use of the Windows Installer.
When does ICE99 show up?
ICE99 posts a warning if a directory name used in the package is the same as
one of the MSI Public Properties.
To fix ICE99 warning, change the value in the Directory column of the Directory
table so that it does not duplicate a property name reserved by the Windows
Installer.