FAQ Microsoft Windows Installer, Application Compatibility and Deployments

Windows Installer FAQ – Part 3

As you guys are aware, I am writing a series of posts which covers some key discussions, topics and FAQs in the stream of application packaging. In this third post, we will look at some questions on key OS components and Installation sequences.

Q11. What is the difference between a Task, Process and a Service  
A process is an instance of a computer program, consisting of one or more threads, that is being sequentially executed by a computer system that has the ability to run several computer programs concurrently. A task is “an execution path through address space”. In other words, a set of program instructions that are loaded in memory.
Windows service is a long-running executable that performs specific functions and which is designed not to require user intervention. (Thanks to Wiki for the answers)

Q12. How do you determine the installer Version in a machine

Option 1: In a command window, type msiexec, the window displayed will tell you the version number.

Windows Installer Version - Detection Method 1



Option 2: Check the file attributes of Msi.dll in the folder C:\Windows\System32

Windows Installer Version - Detection Method 2


Q13. Explain Advertising Phenomenon / On Demand Installation  
The availability of an application to a user without actually installing the application is called Advertisement, In this technique, only the interfaces required for loading and launching the applications are presented to the User. Windows Installer does not install the necessary components until a user or application attempts to activate the advertised program. This is usually done by launching the advertised shortcut. This concept is called install-on-demand.

There are 2 types of Advertisment, “Publish” and “Assign”.
Publish – In this type, the application’s advertising entry point will be visible for the user (usually a shortcut) – Generally used.
Assign – In this type, the application will be available only in Add remove program. The application is installed from here. (this option is used for only advanced users (or) when the application size is huge and they do not want a normal user to install it accidently by launching the shortcut, when he doenst need it)

An application can be tested for advertisement by using the /j switch. (/ju and /jm for user and machine respectively)
For eg: msiexec /jm ABC10.msi /qb

Q14. What are the various Installation sequences? / What are the differences between execute immediate and deferred? / When do you choose a CA to be written in Deferred?  
The various installation sequences are listed below.,
User Interface: The User Interface sequence, which is executed at the beginning of installation, gathers system information, displays dialogs to the end user, and records end user choices. It is suppressed during silent installations.
Execute Immediate: In this mode the installer creates an internal script and run then to make some system changes.
Execute Deferred: It encompasses all the actions between InstallInitialize and InstallFinalize.


Difference Between Execute Immediate and Deferred

Q15. What is the difference between the AdminUser and Privileged properties?
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. In many cases, it is recommended that launch conditions or similar conditions use Privileged instead of AdminUser to allow for installation of applications assigned by administrators.

I would recommend, You read the other parts too – Part 1 , Part 2 , Part 3 , Part 4, Part 5 (Coming Soon)

FAQ Microsoft Windows Installer, Application Compatibility and Deployments

Windows Installer FAQ – Part 2

As you guys are aware, I am writing a series of posts which covers some key discussions, topics and FAQs in the stream of application packaging. In this second post, we will look at some questions, which involve deployment privileges and types of Installations.

Q6. What is a MSI product made up of?
A package contains everything that the windows installer service needs to install a particular product. This includes the appropriate MSI files and any external files(such as CAB files) that the setup needs. Packages, too, are identified by GUIDs. If you make any change to a package, you must assign a new package code.

A feature is a piece of functionality that makes sense to the end user of the software. The help system could be a feature, or spell-checking, or wizards. If you have ever installed software that displays a tree view of things that you can choose to install or leave out, those are individual features. Features are identified by strings that must be unique within a particular package.

A component is a unit of software that the installer can install. Components can include files, registry keys, shortcuts, resources, and other things. Each component is identified by a GUID, the component ID, which must be unique across all packages, regardless of product.

Q7. What are the Different types of Privileges during the installations can be given?

• The users doesn’t have the full admin rights to install the application
• The users doesn’t have WRITE-ACCESS to the Program Files folder of their computers or to the HKEY_LOCAL_MACHINE registry location
• 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
• An account or process that is operating or logged into the computer that has full administrator rights or permissions.(User can install the application but doesn’t have rights to set Group policies ).
Administrative Rights
• Highest level of permissions that can be granted to an account in Windows NT User Manager. An administrator can set permissions for other users and create groups and accounts within the domain. These rights are required to install the System Files Update.

Q8. What are the Functions and capabilities MSI has?
These are the following functions which an MSI provides,
• Transactional Operations: For each operation that an MSI performs It can undo and rollback hence System will not contain unwanted FILES /Registries and will be more clean if uninstallation fails.
• Self Healing: MSI can detect common installation problems at launch, like missing Files and Registries and automatically repairs them.
• Install On Demand: It supports on demand installation of application features { like Spell Check in Words}
• Installation On Locked Down Environments (this is done using Elevated Privilages also)
• State Management: Windows installer provides a set of WiN32 API which allows querying the current state, verification of the existing state, repair of corrupted state and transition from one state to another.
• Consistent Installation Rules: Windows Installer uses consistent and reliable version rules, which provide consistent and reliable installations for all applications and prevent newer files from being overwritten by older files.

Q9. How advertised installation (on demand Installation) is different from a normal installation?
An advertisement installation places entry points, such as shortcuts, on the destination computer without actually installing the application. When an installation is opened in advertising mode, only the Execute sequences are run because it does not have a User Interface sequence, and therefore no dialogs appear
Command line /JU (User) and /JM (machine) is used for that.

Q10. Should users with user-level privileges be able to install MSI applications?
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.

I would recommend, You read the other parts too – Part 1 , Part 2 , Part 3 , Part 4, Part 5 (Coming Soon)

FAQ Microsoft Windows Installer, Application Compatibility and Deployments

Windows Installer FAQ – Part 1

I am planning to write a series of posts covering some key discussions, topics and FAQs in the stream of application packaging. I reckon this post would help, when some of you look at a change in your careers or when stuck up with an issue. This would be my first post of the series. For few of the questions, I will post the answers as well. I would also post in questions, for which I do not know the answer. I would expect you guys to answer that for me 🙂

Well, I shall make a point clear, this is just an FAQ for Application Packagers. Please do use this FAQ ethically. Let me start from the Basics in this first Post.

Q1. What is Application Packaging and why is it needed?
Application packaging bundles applications and operating systems into a single file called a distribution unit (.msi), which makes it easier to deploy and install them on user’s computers. Packaging reduces the total cost of ownership for the customers by enabling them to efficiently install and configure the applications. This results in an application package, which provides the product with new capabilities like advertise features without installing them, installs products on demand, add user customizations etc. Read more on the Application Deployment and Compatibility tools here.

Q2. What process is generally followed while re-packaging applications?
These are the stages of the application packaging life-cycle:
1. Package request is received
2. Technical Evaluation of the Application Source is done.
3. Packaging
3.1 Capture
3.2 Editing
3.3 Testing
4. Quality Assurance (QA)
5. Deployment Testing (if Any)
6. User Acceptance Testing (UAT)

Q3. Why do we need Windows Installer Technology? How does it work?
Windows Installer is used to handle Application Installations on Windows Platform. Installer technology is made up of these three below elements which work together.
Windows Installer client – Any application that calls Windows Installer to perform a task (Example SMS distribution, Add Remove Program, Windows-based shell..etc. )
Windows Installer service – a System service “Msiexec.exe” for installing and managing applications.
Windows Installer package (an .msi file.) – A database file which is used to manage the various states of the application like adding, changing, or removing it from a computer.
A MSI file is a database, which contains information on which files/ registries needs to be installed. As its a database, the installer knows, what all gets into the machine. Hence, it takes care that, only the necessary components are removed while un-installation.

Q4. How does an MSi Install in a machine?
When an MSI is triggered for Installation, the msiexec service starts the installation and it follows these 3 phases.
Acquisition – In this phase, the MSI collects all the data and inputs from the user and generates the installation scripts. (When the user presses the cancel button, the installation rollbacks)
Execution – In this phase, the generated Installation script, gets executed and all the necessary files and registries are all set to get copied and the installation starts. (When the user presses the cancel button, the installation rollbacks)
Commit – In this phase, the MSI marks a footprint in the machine and goes towards a point of no-return. Means, in this phase, the installation cannot roll-back.

Q5. What are the advantages we get by packaging applications? / What are the advantages by using Windows Installer MSIs?
1. Customize Applications to suit the user needs.
2. Simplify the Installation and Un-installation Procedures.
3. Saves Time in both Installation and Un-installation.
4. Once packaged, applications can be quickly installed on a range of desktops in multiple locations, saving administrative costs, simplifying the licensing fees management and minimizing support and repair expenditures.
5. Saves Space of the product by doing apt modifications to applications.
6. Has a great flexibility of obtaining the lost files through a phenomenon called Self Heal, this reduces the down time of application. If a critical file (a .DLL or .EXE file, for example) that is part of the distribution is corrupt or is deleted, the user can be prompted to repair the installation by presenting the original .MSI distribution. Additionally, if the installation media is available (for example, on a network share), the repair simply happens automatically.
7. Can be advertised. So that on demand installation could take place.
8. Application upgrading can be done with ease
9. Clean installation and Un-Installation is achieved by a process called Roll-Back.
10. Simplifies management of new user set-up along with the revision and distribution of software repairs and new applications to existing users. Application recovery can also be improved.
11. Helps eliminate uncontrolled software downloads and installation, enables applications to be safely removed and reduces non-business traffic on a corporate network.
12. Using .MSI format, can automate software distribution process and ensure that the installation doesn’t break other applications that have already been installed.
13. Application is installed via an OS service.
14. State management is maintained. In the past, it’s been difficult to know whether an application is installed on a machine. You would have to query for a .DLL with a specific version number or determine whether an .EXE file with a specific name was present. Windows Installer provides an application programming interface (API) that lets programmers and administrators see whether a specific application is installed on a machine.
15. Scriptable API. This whips together a VBScript to help us with the MSI file manipulations. The API to manipulate MSI files is so powerful that it can create, validate and update packages, trigger installs and uninstalls, examine the MSI repository data on computers, and perform some custom actions.
16. Served installs. Because MSI files can be housed in a share point and delivered via a server, we can keep our installation files all in one place or move them around — closer to the users if necessary.

I would recommend, You read the other parts too – Part 1 , Part 2 , Part 3 , Part 4

Microsoft Windows Installer, Application Compatibility and Deployments

Enhanced Service Configuration for Windows Installer 5.0

Windows Installer 5.0 provides enhanced native support for setup authors to configure services which are a part of an application install MSI. The new MsiServiceCofig and MsiServiceConfigFailureActions tables will provide options to Configure a service with enhanced options. Windows Vista brought in some significant changes to the services model to improve performance, reliability, security, management, and administration of services.

  • Delayed Auto-Start – These services starts shortly after the system has started to improve the system startup performance.
  • Failure Detection and Recovery – Automatic Service restart by the service control manager (SCM) on failure.
  • Preshutdown Notifications- This provides services with a lengthy shutdown procedure more time to shut down gracefully.
  • Restricted Network Access
  • Running with Least Privilege – Services can run under any account that contains the required privileges (LocalService, NetworkService, LocalSystem, a domain account, or a local account).
  • Service Isolation – Isolate objects, such as files or registry keys for its exclusive use by securing them with an access control entry.
  • Service State Change Notifications
  • Session 0 Isolation- Session 0 is reserved exclusively for services and other applications not associated with an interactive user session. Session 0 does not support processes that interact with the user. This change means that a service cannot post or send a message to an application and an application cannot send or post a message to a service. In addition, services cannot display a user interface item such as a dialog box directly.For Reading more on Session 0 Isolation – Click here.


The services in the MSI packages are handled using ServiceControl and ServiceInstall tables. The ServiceInstall table is used to install a service to the machine, ServiceControl table is used to start, stop or delete a service from your machine during an installation or un-installation. Going forward in Windows 7 (Windows Installer 5.0), we will have new MsiServiceCofig / MsiServiceConfigFailureActions tables which configure a service with enhanced service configuration options.

MsiServiceConfig table provides options for configuring a service that is being installed or one that already exists on the machine by specifying the type of configuration as well as the parameters needed for that configuration.

MsiServiceConfigFailureActions table is used to document failure actions that need to be invoked in the event of a service failure. This change takes effect the next time the system is started. Both these tables will be processed during the MsiConfigureServices action.

The MsiConfigureServices standard action should be scheduled in the following order:

  1. StopServices – From ServiceControl table
  2. DeleteServices – From ServiceControl table
  3. InstallServices – From ServiceInstall table
  4. MsiConfigureServices – From MsiServiceConfig and MsiServiceConfigFailureActions tables
  5. StartServices – From ServiceControl table

Note: the standard action MsiConfigureServices is introduced only in Windows 7 and will not be re-distributable for Vista/Xp.

Windows Installer Team Blog
Service Model Enhancements in Windows Vista

How-to Windows Installer, Application Compatibility and Deployments

Access MSI Database in Deffered Context through Custom Actions

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.

“How-to” make this work??

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

How-to Windows Installer, Application Compatibility and Deployments

Merge – Merge Module Contents to an MSI

There is always a need for a merging tool when we want to add the components in a merge module to our Installation Package(MSI). All the major packaging tools offer this functionality. There’s also an utility called MsiMerg.exe that ships as part of the Windows Installer SDK. 

The syntax for using this utility – msimerg.exe {base db} {ref db}

It turns out that the base database is the Installer package that we’re merging to, and the reference database is the merge module that we want to add to the package. 

Eg: msimerg ABC10EN.msi comcat.msm 

This will add the information from the comcat merge module to the ABC10EN Installer package. If there are any errors during the merge, it will create a table named _MergeErrors for our further inspection.

Windows Installer, Application Compatibility and Deployments

Admin Installation feature for Workgroup Users

Windows Installer can also perform an administrative installation of an application orproduct to a network for use by a workgroup.

An administrative installation installs a source image of the application onto the network that is similar to a source image on a CD-ROM. Users in a workgroup who have access to this administrative image can then install the product from this source. A user must first install the product from the network to run the application. The user can choose to run-from-source when he installs and the installer uses most of the product’s file directly from the network.

An administrative installation is invoked by running the installation from the command line with the /a option. You then select a network share point where a copy of the installation is posted as an administrative image. Users who have access to this administrative image can then install the product from this source. If users choose to run from source during the installation, then most of the application files will be used from the network.

Following is an example of a command line statement that runs an .MSI in administrative mode:
msiexec /a “C:\Files\Abc10EN.msi”

Microsoft Windows Installer, Application Compatibility and Deployments

Multi Package Chained Installers in Windows 7

Currently Windows Installer does not provide a mechanism for installing multiple packages in a single transaction. If one or more of the packages do not install as expected in the chained installation, the transaction script will just try to un-install all the previously installed packages.

The newer version of Windows Installer is shipped with a feature which handles Multi Package Chained Installers effectively. In this scenario, the Windows Installer handles the entire installation as a single transaction and If one or more of the packages do not install as expected, it roll backs the entire installation. This is a built-in feature of Windows Installer 5.0 for Windows 7. This is also available with Windows Installer 4.5, which can be installed on Windows Vista.

Windows Installer Multi Package Transaction

You can find a ”How-to” here : Click here to View

How-to Microsoft

How to add WinSxS assemblies into a MSI package?

If you need to install Win32 side by side assemblies globally, you should use the MsiAssembly and MsiAssemblyName tables to do so. Your InstallExecuteSequence table should also include the MsiPublishAssemblies and MsiUnpublishAssemblies standard actions. There is more information on these tables in MSDN and the sample sequence.msi package provided with the Windows Installer SDK (of the Windows SDK) provides a recommended sequence number for those standard actions.

You can refer this article to get the basics of Assemblies

A win32 assembly is an unmanaged assembly (native code). An assembly that is installed to the GAC is actually a managed assembly or otherwise known as a .NET assembly. While the concept of the assembly unit is the same, there are quite a few differences between the two. Typically .NET assemblies are contained within a single module that includes an embedded manifest. For Win32 assemblies, the manifest and catalog file are separate from the binary itself.

You can review the assembly structure yourself by taking a look at the following folders on a Windows Vista machine:

.NET assemblies

Win32 assemblies

A good starting point on MSDN is

How-to Windows Installer, Application Compatibility and Deployments

Best Practices and Guidelines: Packaging .NET Assemblies

This is a MSDN extract; I have still posted it because many of us do not follow these rules while packaging .NET applications. The Installer can install, remove and update Win32 and .NET assemblies, including side-by-side and private assemblies in Windows XP. To avoid common problems, follow these rules when using assemblies:


  • A component should contain no more than one assembly.
  • All of the files in an assembly should be in a single component.
  • Each component that contains an assembly should have an entry in the MsiAssembly table.
  • The strong assembly cache name of each assembly should be authored into the MsiAssemblyName table.
  • Use the Registry table instead of the Class table when you register COM Interop for an assembly.
  • Assemblies that have the same strong name are the same assembly. When the same assembly is installed by different applications, the components that contain the assembly should use the same value for the ComponentId in their Component tables.

Win32 Assemblies:

  • Do not use the manifest file or the catalogue file as the KeyPath in the Component table for the component containing the Win32 assembly.
  • The KeyPath value in the Component table for a component that contains a Win32 policy assembly should be Null.
  • Add a row to the MsiAssemblyName table for each name and value pair that are listed in the <assemblyIdentity> section of the Win32 assembly’s manifest.

.NET Assemblies:

  • The KeyPath value in the Component table for a component that contains the assembly should not be Null.
    When you install an assembly used by the common language runtime to the global assembly cache, the value in the File_Application column of the MsiAssembly table must be Null.
  • Add a row to the MsiAssemblyName table for each attribute of the assembly’s strong name. All assemblies must have the Name, Version, and Culture attributes that are specified in the MsiAssemblyName table. A publicKeyToken attribute is required for a global assembly.