MSI - Registry Tables Group

The installer has specific tables for the different types of registry entries. When populating the registry tables group it is important to try to minimize the number of entries put into the Registry table and maximize the use of the other, specific, registry tables. This is because the installer cannot distinguish between different types of registry entries in the Registry table and cannot use the internal logic necessary to take full advantage of all of the installer features, such as advertising. Authoring COM and shell-related registry entries in this way also provides a more logical organization and can help minimize erroneous registration of COM server information.


The registry entry group contains the following tables of specific registry entries.

• The Extension table contains all of the filename extensions your application uses along with their associated features and components.
• The Verb table associates command-verb information with the file extensions listed in the Extension table. This provides an indirect link between the Verb and Feature table that is needed for feature advertisement.
• The TypeLib table provides information that the installer places in the registry for the registration of type libraries. Type library entries are not written at the time of advertisement. The installer writes the type library entries at the time the components associated with the library are installed.
• The MIME table associates a MIME context type with a CLSID or a file extension. This provides a path between the MIME and Feature Table that is needed for feature advertisement.
• The SelfReg table provides information needed to self-register modules. Self-registration is provided by the installer only for backward compatibility and it is not recommended as a method for populating the registry, however if there are any modules in your application that must register themselves, use the SelfReg table.
• The Class table is used to register Class IDs and other information for COM objects. This table contains COM server-related information that must be generated as a part of the product advertisement.
• The ProgId table associates program IDs with class IDs.
• The AppId table is used to register common security and configuration settings for DCOM objects.
• The Environment table is used to set the values of environment variables, and in Windows NT/Windows 2000 the Environment table writes to registry as well.
• The Registry table holds any other information that the application needs to put into the system registry. This would include default settings, user information or data, or COM registration not supported by the above tables.
• The RemoveRegistry table contains the registry information the application needs to delete from the system registry at installation time.      

MSI - File Tables Group

An installer package developer should consider populating the file table group of tables after breaking the application into components and features and after populating the core tables group. The file table group contains all of the files belonging to the installation and most of these files are listed in the File table. The Directory table is not listed in this group, but is closely related to the file table group. The Directory table gives the directory structure of the installation.


The file group of tables contains all of the tables that are related to files.

• The File table lists files belonging to the installation. Files that are not listed in the File table include disk files, which are listed in Media table. Because every file belongs to a component, the File table has an external key into the Component table.
• The RemoveFile table contains a list of files to be removed by the RemoveFiles action.
• The Font table lists font files to be registered with the system.
• The SelfReg table lists module files of the installation that are self-registered.
• The Media table lists the source media and disks belonging to the installation.
• The BindImage table lists files that are bound to DLLs imported by executables.
• The MoveFile table specifies which files are moved during the installation.
• The DuplicateFile table specifies which files are duplicated during the installation.
• The IniFile table lists the .ini files and the information that the application needs to set in the file.
• The RemoveIniFile table contains the information an application needs to delete from a .ini file.
• The Environment table is used to set the values of environment variables and in Windows 95, the Environment table lists changes that will be made to the autoexec.bat file.
• The Icon table provides icon information that is copied to a file as a part of product advertisement.

MSI Core Tables Group

The core group consists of tables describing the fundamental features and components of the application and the installer package. Developers of install packages should therefore consider how to populate these tables first because the organization of much of the database will become apparent from the content of this group.

• The Feature table lists all features belonging to the application.
• The Condition table contains the conditional expressions that determine whether or not a particular feature will be installed.
• The FeatureComponents table describes which components belong to each feature.
• The Component table lists all components belonging to the installation.
• The Directory table lists the directories that are needed during the installation. Because each component must be associated with one and only one directory, the Component table is closely related to this table and has an external key to the Directory table.
• The PublishComponent table lists the features and components that are published for use by other applications. Components and Features are the two types of feature advertisement. 

Enable MSI logging

Set following registry to enable MSI logging




The new log's file name is random, but begins with the letters "MSI" and end with a .log extension will be created in %temp% folder

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

Reg_SZ: Logging

Value: voicewarmup 

Why Windows Installer prompting for a reboot

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.

Processing Options in the Custom Actions

1. Synchronous:
 Windows Installer runs the custom action synchronously to the main installation. It waits for the custom   action to complete successfully before continuing the main installation.


2. Synchronous, ignore exit code 


Windows Installer runs the custom action synchronously to the main installation. It waits for the custom action to complete before continuing the main installation; the action can be either success or fail.


 3. Asynch, wait at end of sequence 


Windows Installer runs the custom action simultaneously with the main installation. At the end it waits for the exit code from the custom action before continuing.


 4. Asynch, no wait 


Windows Installer runs the custom action simultaneously with the main installation. It doesn’t wait for completion of the custom action and doesn’t check the exit code also.

Limitations of App-V

1. Device Driver: Microsoft Application Virtualization does not support sequencing of device drivers thus any application which install device driver should not be sequenced.

2. Application Size: If the maximum client cache size is set for 2 GB (The max can be 64 GB), then the maximum size of application (sft file) which can be streamed on that machine is 2 GB. All applications which have the installed footprint greater than or equal to the max client size, set by the client, should not be sequenced. Also the Max application size App-V can handle is 4GB, [Q: drive has FAT file type and the max file size FAT can handle is 4GB]. 

3. Shortcuts: Application should have minimum of one shortcut. If no shortcuts are present then the application should be sequenced in a suite along with the application which needs it. For example if Macromedia Flash is the application in question to be sequenced then the shortcut should be pointing to the locally installed Internet Explorer

4. Middleware: Middleware applications are not a good candidate for sequencing as they can be used as a prerequisite by multiple applications, thus should be installed locally. but if multiple version of it are needed then they should be sequenced along with the application which needs them. It is always advised to have only one version of any application/middleware in the organization thus conditions for multiple versions should be avoided With Version 4.5 most of the middle-wares can be sequenced and used as secondary packages.

5. Path hard coding: The application should not have folder/file path hard coding in the application itself. Some application hard code the path of files in registry or ini file or executable. In these cases it has been found that they can be sequenced most of the time using VFS sequencing method, but extreme care should be taken while sequencing & testing these applications. Also Configuration files such as ini, conf, txt, registries etc are good places to look for the hard coding

6. Base Build Applications: Applications which are already part of base build should not be sequenced. One can sequence them but they are of no real value as they will already be present on the client machines

7. Auto Update: Application with automatic updates should not be sequenced. Sequenced application most of the time fails to properly update itself. Also allowing auto update leads to non compliance of application version. These types of applications should only be sequenced if the auto update feature can be disabled during sequencing procedure

8. Services: Services which can be started when application starts and shuts down when application main executable shuts down can be included in sequence. Services that run as their own (like boot-time services do but there are others also) are not suitable for sequencing since under App-V all application starting happens under user’s session context.  Also applications which install services which run using specific user credentials cannot be sequenced

9. COM+: Some application which uses COM+ might not work properly in virtual environment, thus this type of applications needs be tested properly

10. COM DLL: Few application which uses COM DLL surrogate virtualization, i.e. DLL’s that run in Dllhost.exe, does not work properly in App-V Environment. Thus this type of applications needs be tested properly

11. Licensing Policies: Applications with licensing enforcement tied to machine, e.g. the license is tied to the system’s MAC address, username etc. It should not be sequenced if activation cannot be done by the user at the first launch 2009 c Mayank Johri Microsoft Application Virtualization - An Introduction to Sequencing Source Files Validation 10 of sequenced application

12. Internet Explorer & Service Packs: Internet Explorer, Windows service patches and service packs cannot & should not be sequenced

13. Network Share Application: It is not a good practice the run applications from network share as they tend to violate the enterprise desktop integrity and thus known to cause integration issues. It is advised to have to entire application inside of App-V package

14. Hosts file located in “%windir%\system32\etc” cannot be sequenced and should be updated on local machine before the sequenced application is launched