So I finally got Internet connected at a record speed of 8 weeks (go iiNet, nothing like a bit of free publicity from another happy customer). Now I'm doing this one due to the massive number of requests we get on this through the multiple forums I frequent.

Windows Installer supports application upgrades. An upgrade is essentially the removal of an older product which is replaced by a newer product. The upgrade solution has two different upgrade methods.

Method 1:

• Initiate installation of new product
• Detect and Complete removal of an older product
• Completion of installation for new product

This method is considerably easier and requires less knowledge of Windows Installer to achieve a successful result. Most application repackager's tend to use this method.

Method 2:

• Initiate installation of new product
• Check matching component codes, installation of new non matching component from new product.
• Uninstallation of non matching components leaving matched components on the machine.

Method 2 is considered to be the better process as it improves installation speeds due as only small portions of an application need to be installed and uninstalled. This process is however considerably more complex to build into a package and requires in depth knowledge of Windows Installer to complete successfully. Its pretty common place for people to attempt method 2 first as this is generally how the default schemas for most packaging tools are setup.

This can easily be summarised in a quick table.

The different process types are controlled by two Windows Installer Standard actions. These are:

FindRelatedProducts

RemoveExistingProducts

The FindRelatedProducts uses upgrade codes and application versions to identify windows installer applications and then determines what should be done with the applications it finds. The action to be performed when a product is detected is determined by the value of the attribute column of the respective upgrade table row. In addition to this the FindRelatedProducts action adds the ProductCode of found application to the Property specified in the ActionProperty column of the upgrade table.

The RemoveExistingProducts action does the actual removal of products found by the FindRelatedProducts action. The list of features to be removed is determined from the Remove column of the upgrade table. An blank entry or a value of "ALL" deems the entire application feature set should be removed. The location of the FindRelatedProducts and RemoveExistingProducts actions in relation to each other viewed from the Installation sequences determines which of the above methods of upgrade are performed.

Method 1 action locations:

FindRelatedProducts

RemoveExistingProducts

All actions making up installation of new product

Method 2 action locations:

FindRelatedProducts

All actions making up installation of new product

RemoveExistingProducts

Note: Method 2 is considerably more complex and it is not recommended for inexperienced packagers. It requires an in depth knowledge of application sociability, conflict management, component rules, installation sequencing.

I will cover component rules in another post, for now to cut a rather long story short you need to match component GUID's on application which are intended to be upgraded with method 2 (that is if you want it to work properly). For those of you using Wise Package Studio there is a tool named UpgradeSync which is designed to aid with configuration of this type of upgrade method. To throw a little more complexity in the mix (such an unusual thing for Windows Installer) the MigrateFeatureStates action can be used to determine whether features should or shouldn't be removed, but wait there is more you didn't seriously think it was over there did you. There is another property called PreSelected which toggles whether the MigrateFeatureStates action runs.

There are 3 types of upgrade which are Small, Minor and Major updates. All updates require changing of the Package Code.

A small update is typically a small number of files, a small update cannot rearrange the feature component structure.

A minor update can add files and features however cannot manipulate the current feature/component structure. A minor update also requires the ProductVersion property to be changed. Minor updates can be shipped as full product installers or MSP patch files.

A major update can add files / features and also manipulate the feature component tree. The major upgrade requires that new ProductCode, PackageCode, and ProductVersion's are set.

The following table summarises the changes required for each update type.

When people are beginning to use Windows Installer the first look at the logs is often so daunting they tend to never look at them again. I find that the most common reason people avoid the logs is they don't understand the sequencing. Funnily enough the sequences and the logs tend to correspond with each other (I'm not sure why that is)

Anyway if you take Windows Installer and break it down you would know that the Installer basically consists of a service and a database that processes table's then sequences and actions. The installer service records everything that happens in sequential logic. The end result is a transactional record of the actions that are run during the installation. The beauty of this is as its transactional its quite simple to apply the reverse logic to handle the uninstall.

Now the trusty old log files record this process in its entirety, basically what I am getting at here is if you take the time to actually read the logs you would also understand the sequencing logic as well because they are one in the same. Alternatively if you work out the sequences you also workout the logs.

So first things first with the logs. How do we enable Windows Installer logging ?

Before we enable logging there is a number of available logging options which you need to know, there are:

Note: Each letter corresponds to a different setting. Adding a collection of all letters increases logging capabilities.

Logging via Registry

System Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
Value Name: Logging
Data Type: REG_SZ (String Value)

Note: A common acronym of VOICEWARMUP is used as its a word that contains all available settings (prior to V3.0)

Debugging via Registry

By enabling the debug key you can monitor the installation using debugview

Install script logging

System Key: [HKEY_CURRENT_USER\Software\InstallShield\ISWI\3.0\SetupExeLog]
Value Name: VerboseLogFileName
Data Type: REG_SZ

Group Policy Logging

To enable logging from active directory or GPO you can find the settings here.

Windows Installer 4.0 +

So then we got Windows Installer 4.0 from which came two new Windows Installer properties.

MSILogging property hosts the same values listed in the above table.

MSILogFileLocation property has the path to where the logs should be created.

Command Line Logging

So last but not least command line logging, probably the one you will most often use.

msiexec.exe /i <path to msi> /l*v <path to logfile>

msiexec.exe /i <path to msi> /l*vx <path to logfile> (version 3.0 on Windows 2003 + OS's)

Reading the logs

Ok so now you have the logs how do we interpret the garbage that it generates. Well for those of you who always like to take the easy road. Get your hands on this little utility WILOGUTL.EXE it makes pretty it all a little more legible and takes the guess work out of things.

However for all of you hard core propeller heads here's how to really understand the seemingly difficult mess that arrive after setting some of the above options to log.

As you are aware the Installer Service on WindowsNT based platforms offers a client and server based process. The first section depicted in the following log excerpt in blue identifies the process is running client or server side.

MSI (S) is server side

MSI (C) is client side

MSI (N) is a nested action

The next items depicted above in the red text is the ProcessID:ThreadID that generated the entry. Only the last 2 (hexadecimal) digits of the process and thread IDs are given. If the process ID was 2DC and thread ID 2D8 the Hex item show in the log would be (DC:D8).

The green section following is the date time stamp the action occurred.

Product State

The ProductState property can be any one of these values

Feature Component State

So every feature and component is checked for state prior to it being marked as something that needs to be installed. So selecting different features "usually" changes the feature state and subsequently all the components within that feature (of course there are exceptions to every rule, the condition table and feature / component conditions all have effect here also.).

The first item here, show the feature name as Complete and it is currently Absent. So the requested action is to install it Local. So the components follow the same pattern. This one is a little tricky so more detail here

MSI (s) (94:28) [20:46:12:390]: Feature: Complete; Absent: Local;   Request: Local;   Action: Local
MSI (s) (94:28) [20:46:12:390]: Component: Registry; Installed: Absent;   Request: Local;   Action: Local
MSI (s) (94:28) [20:46:12:390]: Component: VersionRegistry; Installed: Local;   Request: Local;   Action: Local
MSI (s) (94:28) [20:46:12:390]: Component: slupExecutable; Installed: Absent;   Request: Local;   Action: Local
MSI (s) (94:28) [20:46:12:390]: Component: CoreLibrary; Installed: Absent;   Request: Local;   Action: Local
MSI (s) (94:28) [20:46:12:390]: Component: CtrlLibrary; Installed: Absent;   Request: Local;   Action: Local

Reading Actions and return codes

Action start 1:18:02: INSTALL.
MSI (c) (A1:6A): UI Sequence table 'InstallUISequence' is 
present and populated.
MSI (c) (A1:6A): Running UISequence
MSI (c) (A1:6A): Skipping action: ResumeInstall (condition is false)
MSI (c) (A1:6A): Doing action: CheckOSandSPAction
Action start 1:18:02: CheckOSandSPAction.
MSI (c) (A1:6A): Creating MSIHANDLE (1) of type 790542 for thread 110
Action ended 1:18:02: CheckOSandSPAction. Return value 1.

The valid return codes are: 

Shell32 API calls

Where you see one of these there is a good chance a directory is being resolved for the current target platform.

MSI (s) (94:28) [20:46:11:843]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Templates

Old hands tips for log reading

1) Start at the bottom and work up

2) If your install fails with dialogs open. Leave dialogs on screen and goto log whilst error message is still visible

3) Use WiLogUtl.exe

4) Don't forget the newest extended logging options /l*vx (most of you are still using /l*v)

5) Keep the sequences in mind when reading a logfile (strangely enough they coincide nicely)

6) Enable GPO logging or policy registry option if you need to log repairs

7) Now you have this information take a 30 minutes out of your day and read an entire log you'll be surprised what you learn.

Now all that being said, I'm not getting a lot of feedback about these blogs so its hard to gauge if anyone is really reading or even interested in this stuff or not.

Post some comments if you want more info otherwise I may just find other things to do with my spare time.

Ok so a lot of people wonder why I bother with doing this. Well the simple facts are this is an easy way to make a package more dynamic without needing repackaging to modify the package. A rather beneficial side affect is that allows updates to be made to properties without having to uninstall a package and reinstall it. (this is a really nice feature if you don't want to uninstall but perhaps have a server name update to perform on a registry key or something similar.)

The reason I am posting this is that Kim has linked to it on my previous blog so I guess I may as well explain what it is all about.

Lets take a simple scenario into account. Perhaps you have an application which writes the path to a database into the registry can't think of one ? Probably most of you use one each day. Wise is one application I can think of off the top of my head that does this.

Anyway back to the point lets say you have written a database path to the registry in a location such as.

HKLM\Software\MyApplication\DatabasePath = MyServer\SQL01

A smart packager would do something like this instead.

HKLM\Software\MyApplication\DatabasePath = [SQLSERVERPATH]

In the MSI Property table add the property

SQLSERVERPATH = MyServer\SQL01

This of course has the effect that you can now with a TRANSFORM and or COMMANDLINE change the path to that SQL Server. Using a Transform is often the way ahead. But this can lead to other issues down the track. Lets assume in 6 months time the SQL Server gets upgraded and with that upgrade it gets a new Server\Instance path. Using a TRANSFORM you would have to perform the following steps.

1) uninstall the app

2) create a new transform with new property

3) reinstall the app.

Using my custom xml solution you could simply do this.

Create the Registry in a dynamic sense as shown above.

HKLM\Software\MyApplication\DatabasePath = [SQLSERVERPATH]

Then create an XML File such as.

<Properties>

  <SQLSERVERPATH>MyServer\SQL01</SQLSERVERPATH>

</Properties>

Using this code each item under the Properties node gets enumerated and converted to a property name and value. This is really old code and could be written considerably easier (I wouldn't write it like this any longer this was well before I understood XML Dom to the degree I do now)

Now why would you do this, well the benefits are defined by who, how and why your doing your packaging. In most instances this leaves my clients in a situation where they do not need a packager to update the package. A simple edit of the text node in the XML is all that's needed to repackage this app. The unplanned side effect of this was that instead of needing to uninstall your app and reinstall it a simple forced heal would update the path.

As I mentioned earlier this is really old code I'm just posting this to explain the code Kim linked to. There's plenty of nicer ways to code the same result.

'******************************************************************************
' Filename: XMLCONFIG.VBS
'
' Description: MSI XML configuration script.
'
' Function: Reads XML Configuration and modifies MSI's to suit
'
' Modification History:
' Author Date Version Changes
' ----------------- ----------- ------- ---------------------------------------
' Installpac Pty Ltd
' John McFadyen 20/04/2006 1.00 Created Script
'
'
'******************************************************************************
strSourcePath = Session.Property("SourceDir") 'reads msi filename and path
strSourcePath = Mid(strSourcePath, 1, InstrRev(strSourcePath, "\")) 'strips filename leaving msipath
Set objWshShell = CreateObject("WScript.Shell")
set objNetwork = CreateObject("Wscript.Network") 'Create network object
Set objXMLDocument = CreateObject("Msxml2.DOMDocument") 'Creates XML document
Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem", "WQL")
objXMLDocument.Async = False
objXMLDocument.resolveExternals = False
objXMLDocument.Load(strSourcePath & "scripts\Environment.xml") 'Loads XML file
strUserDomain = objNetwork.UserDomain 'Determines users domain
For Each objItem In colItems
sstrFQDN = objItem.Domain
Next
strItem = GetXMLChildNodes(objXMLDocument, "PROPERTIES")
'********************************************************************************
' Function: GetXMLAttribute (Reads attributes from XML)
'
' John McFadyen
Function GetXMLAttribute (byref objXMLDocument, strNode, strAttributeName)
'On Error Resume Next
Dim objDocumentElements, objNode, strAttributeResult
Set objDocumentElements = objXMLDocument.documentElement
Set objNode = objDocumentElements.selectSingleNode(strNode)
GetXMLAttribute = objNode.GetAttribute(strAttributeName)
Session.Property(strAttributeName) = GetXMLAttribute
' msgbox strAttributeName & " " & session.Property(strAttributeName)
End Function
'********************************************************************************
' Function: GetXMLChildNodes (Enumerates child nodes from XML parent)
'
' John McFadyen
Function GetXMLChildNodes (byref objXMLDocument, strNode)
'On Error Resume Next
Dim objDocumentElements, objNode, strAttributeResult
Set objDocumentElements = objXMLDocument.documentElement
Set objParentNode = objDocumentElements.selectSingleNode(strNode)
For Each objNode in objParentNode.childNodes
' msgbox "NodeName: " & objNode.NodeName & " " & "NodeText: " & objNode.Text
Session.Property(objNode.NodeName) = objNode.Text
' msgbox objNode.NodeName & " value " & session.Property(objNode.Nodename)
Next
End Function

Ok well this is probably one of the harder topics to try and explain on paper. Its considerably easier to do with a whiteboard and a room full of people. But I will have a shot at it no doubt Kim (AngelD) will assist with any problem areas. Throughout this document try to keep this diagram in your head.

So in order to understand windows installer you really need to get your head around the installation sequences sooner rather than later. I often hear people throwing around the terms of Immediate and Deferred custom actions and completely misunderstanding the context of what this really means. So here I will try to explain how and why this is so important.

Windows Installer has 6 tables which control the order and flow of when and where all other tables are read (as above). Of these 6 installation sequence tables only 2 of them are executed during a typical execution. Tables are to be executed are determined by the installation command line. The tables and their respective command lines are :

What this means is that when you run msiexec.exe /i <Path to msi> which is a typical installation command line you will be executing the two tables of InstallExecuteSequence and InstallUISequence.

Additional to each pair of tables a User Interface Level (UILEVEL) is thrown into the mix by additional switches to the previous command line.

Windows Installer supports four user interface levels:

By utilising these extra command line switches items within the UI Tables as shown in the table above are conditionally loaded.

For example:

When user interface level is Full or Reduced, Windows Installer engine will start with processing actions from the UI sequence table and continue with Execute sequence table's actions.

When user interface level is Basic or None, UI sequence table will be skipped and installation will be started with executing actions from the Execute sequence table.

Note: Actions can be in both tables and may or may not be executed in both of the respective tables. When custom actions are involved this can be toggled by custom action attributes (as specified from the type column of the custom action table)

Installation Phases

Each installation is broken down into a series of phases those phases each have different attributes and more importantly occur at staged times throughout the installation. The first of the phases is the Acquisition phase.

Acquisition Phase (Immediate)

The acquisition phase consists of all actions from the appropriate UI Sequence table (as controlled from the selected command line options) and all actions from the Install Sequence table (as controlled from the selected command line options). Generally during the acquisition phase items should not be installed to the target platform it should be used purely as a data gathering phase. The data gathered is then used to conditionally control the actions which happen in the later phases.

During this phase some of the main items performed are:

• Checking prerequisites (optional):

  • Installation is started up on the correct version of operating system, platform, etc (Launch Conditions).

  • Competitive upgrade is being installed on the system with competing product installed (Application Search).

  • License for licensed product is valid (Product Validation)

• Selecting features to install (either through user interface or properties in the command line).

• File Costing - making sure that target system has enough of available hard disk space to install the product.

• Generating the installation script for the next phase.

To gain some real appreciation of what is happening during this phase and in particular from when the action InstallInitialize is reached. The InstallInitialize action is important as this action signifies that start of the Installation script generation. As I have tried to depict with the main diagram at the top of this page the first parse of the actions between InstallInitialize and InstallFinalize are parsed and their conditions are evaluated, where a condition is met the action is written into the Installation script. (Note: this script does not exist prior to installation). This process is repeated until the InstallFinalize action is reached.

Now to throw a little confusion into the mix where an action is a custom action the custom actions type is evaluated and if the custom action has an Immediate attribute and the condition is evaluated as true then that custom action is executed Immediately hence the name. Where a custom action has an attribute of Deferred and the condition is evaluated as true that custom action is written into the installation script.

Note: Immediate phase when it comes to custom actions.  All Immediate custom actions are running in the context of the user performing the installation.  Immediate custom actions must not change the system.

Execution Phase

The execution phase is split into two separate phases known as Deferred and Commit/Rollback.

Deferred Phase

This phase is performed by InstallFinalize action in the Execute sequence table.  During this phase the installation script, generated during acquisition phase, is passed to a process which runs with elevated privileges.  This process executes all actions from the script.  This is where the actual installation takes place, files are copied registry is written and the application is installed. When an action is a custom action the custom actions attributes are evaluated and if it is deemed to be a Deferred - Commit that action is moved across into the 2nd installation script. Where a custom action is a standard deferred custom action is it simply executed at that point.

Depending on success or failure of the running installation script, the Execution phase will be completed by:

• Rollback installation:  If installation is unsuccessful, the installer restores the original state of the system.

• Commit phase:  If installation is successful, installer will run all Commit custom actions.

Some important items to note here are as we switch from the immediate phase into a generated installation script, it is at this point that we lose contact with the Windows Installer Session which in turn means that we lose access to a number of properties that were available during the immediate phase.

Note: Deferred custom actions usually run with elevated privileges unless they are not impersonated.  Impersonated deferred custom actions are running in the context of the user performing the installation.

Commit Phase

Once the Deferred phase reaches the InstallFinalize action and all actions are successfully run the Commit phase runs. During this phase only Deferred custom actions with a Commit / Rollback attribute will be present in the 2nd installation script. As such this is where Deferred Commit / Rollback actions are run. Actions in this phase a custom actions which deploy a item which needs an opposing uninstall action to perform removal. (a poor example as I can't think of one quickly is if you installed a service using a custom action call as opposed to the service tables)

Once the commit phase reaches InstallFinalize it hands back to the immediate phase which is generally where typical cleanup of application installation data will occur. Note at this point you again have access to all the session which means properties are again accessible.

Ok so that wraps up the Beginners guide to Installation sequences from here I will move onto an Advanced guide which will target all of the MSI Function calls and actual attributes etc. (Might need your help here AngelD)

Basic understanding of the com DLL

A COM class is code which is capable of instantiating or creating an object, or multiple objects for that matter. These objects can have methods and properties which allow manipulation of the object and or its contents. An example COM object which could be used with everyday use is the “FileSystemObject”. Instantiation of a “FileSystemObject” will allow you to manipulate the file system using methods and properties of the “FileSystemObject”.

The following example is how you could use an VBS API call to a COM class to instantiate the “FileSystemObject”

Set objFSO = CreateObject(“Scripting.FileSystemObject”)

Method

A method is a function or piece of code which performs an action against an object created from a COM class. A common example of a method which is easy to relate to an everyday task is creating a folder.

Using the same “FileSystemObject” we can manipulate the file system or perform an action on that file system object using one of its methods.

Based on this using the object previous created objFSO we can now utilize a method to perform the required action in this case creating a folder. The method name is CreateFolder.

objFSO.CreateFolder(“Your folder path would go here”)

i.e.

objFSO.CreateFolder(“c:\test”)

Property

A property is a little simpler and acts simply like a variable would in any other coding language. A property can be set or retrieved using a syntax similar to the following.

To set a property a syntax similar to the following would be used.

objTest.Property = “Your New Value”

To retrieve a property a syntax similar to the following would be used.

strPropertyValue = objTest.Property

What is an API

An Application Programming Interface (API). The API made it easier for applications to integrate with the Operating System and also allowed for a scriptable interface to the application. Windows Installer has a very comprehensive API or COM class which allows accessibility to the entire Windows Installer Service and its applications via a scriptable interface. This will be covered heavily in a future blog or (my advanced courses).

To understand how an API works it is necessary to break down more of the components of a COM class and how they are written to the registry.

Programmatic Identifiers

What is a Programmatic Identifier (ProgID). A ProgID acts in a very similar way to that which DNS acts with an IP address. Where DNS will resolve a DNS name to an IP address and vice versa. The ProgID can be likened to that of the DNS name.

The ProgID is a friendly name which relates to a ClassID (a value which is significantly harder to remember than a ProgID)

The ProgID is stored in the Windows Registry in the HKEY_CLASSES_ROOT hive.

An example of such a key is. [HKEY_CLASSES_ROOT\WindowsInstaller.Installer]

As mentioned previously the ProgID relates directly to a ClassID in the same way as DNS does an IP address. The diagram above shows a child key with the name CLSID. Selecting this item as shown in the following diagram will expose the CLSID entry which is related to the WindowsInstaller.Installer ProgID.

Class Identifier

A ClassID is a unique descriptor which identifies a COM class. These descriptors use a common naming structure known as a GUID in the case of a COM dll the GUID is a 32 bit Hexadecimal GUID.. A 32 bit GUID looks similar to the following item:

{000C1090-0000-0000-C000-000000000046}

It is thought to be extremely rare if not impossible to randomly create two GUID’s with the same details. The ClassID is stored in the Windows Registry in the hive HKEY_CLASSES_ROOT.

The following example shows the subkey's present for this particular ClassID.

A COM class has a few subkey's of particular interest to a packager and his associated support teams. One of these attributes in particular is: InProcServer32

InprocServer32

These items are of particular interest as they are core in understanding a common problem often referred to as DLL Hell. The InProcServer32 key contains the path to the actual DLL itself, or to confuse things a little more can also contain a Windows Installer Darwin Descriptor.

As such the ProgID, ClassID and InprocServer32 keys are all heavily related. In this example we have learnt the following items about this particular COM class.

The COM class has a ProgID of:

WindowsInstaller.Installer.

That ProgID is related to this ClassID.

{000C1090-0000-0000-C000-000000000046}

This ClassID has an InprocServer32 value of:

C:\WindowsSystem32\msi.dll  as shown in the following table.

As such when an API call is made the following items occur.

Where an application or script uses an API call such as:

Set objWindowsInstaller = CreateObject(“WindowsInstaller.Installer”)

The operating system will first lookup the ProgID in the Windows registry, it will then cross reference the ProgID with its associated ClassID which will in turn look for an InProcServer32 value which will contain the path to the actual DLL which contains the COM class.

A simpler model of this is depicted in the following diagram.

TypeLibs

A typelib file is used to assist with understanding the content within an unknown DLL. For example if a vendor write a COM class but doesn't want to disclose the source code they can generate a typelib file. The typelib identifies the content of the DLL without exposing the source. In lamens terms it sort of documents the content of DLL. Tools such as Visual Studios, Microsoft Basic editor leverage functionality in the typelib to expose methods and properties within the script editors.

How does this information get into the registry

One may ask how does this registry information get into the registry and what is its importance. Most of you are likely to of heard of a tool called REGSVR32.EXE maybe some of you have even used it yet not understood what it was actually doing behind the scenes.

REGSVR32.EXE

REGSVR32.EXE is relatively simple to use, its purpose is to populate the HEY_CLASSES_ROOT registry hive with the information shown in the previous descriptions. In actual fact it can input considerably more information into the registry however that is best left for another lesson.

To run REGSVR32 you can use one of the following two command lines.

To register a DLL

REGSVR32.EXE /R <path to your dll that requires registration>

To unregister a DLL

REGSVR32.EXE /U <path to your dll that requires unregistered>

The only downside to the REGSVR32.EXE tool is it give very little information away as to what it is actually doing. There is however a solution to this mystery and that solution is WISECOMCAPTURE.EXE (only available to licensed Wise users)

WISECOMCAPTURE.EXE

WISECOMCAPTURE.EXE is a tool developed by Altiris / Wise which mimics that of REGSVR32.EXE and in addition it also creates a .REG file which can be used for the purpose of examining what happened during your registration process. This tool is really useful when troubleshooting specific DLL hell issues.

To run WISECOMCAPTURE.EXE you can use one of the following two command lines.

To register a DLL

WISECOMCAPTURE.EXE /R <path to dll> <path to output file .REG>

To unregister a DLL

WISECOMCAPTURE.EXE /U <path to dll> <path to output file .REG>

Why is all of this information important.

The importance of this information is heavily dependant on your role. For an application packager it is very important to know when a dll should be registered and even more importantly when it should not be registered.

A specific example of when not to register a DLL is when a DLL is present in System or System32 folder and another copy of the same DLL for some reason is delivered to the application directory. Such as “c:\program files\Your application”

Using this example lets trace back a few steps, registering a dll will add the following entries.

When registered in System32

If you registered the same dll into "c:\program files\myApplication\msi.dll"

Did anyone spot the similarities ? The only change in both instances the InProcServer32 entry has changed. This becomes problematic as the last registration of a DLL will rewrite the location of the InProcServer32 keys. Although initial inspection one would think this is not an issue. As both the file and its registration will be present. So what's the big deal ?

The big deal actually doesn’t rare its very ugly head until you uninstall the application which last registered the dll. Uninstalling the application is likely to remove the files from the program files location as its is highly unlikely a reference count exists. If it removes the file and any other application was reliant on it being present you now have a broken COM object. Or worse still if it removes the file and its registration you have even less information about that COM object.

So from a packagers perspective its very important to know when you should and shouldn’t register a DLL.

If the file remained in System32 it is far less likely to be removed from a machine for a few reasons such as:

MSI Component Reference counting, Shared dll Reference counting.

What else should a packager be aware of ? Upgrading and downgrading DLL’s is particularly problematic also. With old installation technologies such as SETUP.EXE an installer would simply drop a DLL with little or no regard to the version of such a DLL. These installers could cause al kinds of havoc particularly if a DLL was downgraded. As this would mean the DLL may have methods and properties which were simply no longer present within the dll. The upgrade on the other hand should support backwards compatibility particularly if the DLL is made by the same vendor, as such upgrade are often less problematic than downgrades.

With the advent of Windows Installer the downgrade of DLL’s is considerably more controllable. As Windows Installer can be told to only allow upgrades of files and never allow a downgrade. (check out the REINSTALLMODE property in the SDK)

So what does all of this mean for a support person. A support person needs to know that older installation technologies can downgrade DLL’s without warning. Where Windows Installer is concerned it is important a support person know how to control and suspend downgrading of a DLL.

Knowing how a DLL lookup is performed can allow reverse engineering and tracking of problematic and hidden DLL issues.

Ok im getting tired so moving on from here I will cover Isolation topics etc..

Packed GUID's

All the Windows Installer registry keys and settings are held under these locations:

[HKEY_CLASSES_ROOT\Installer]
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Installer]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer] a Per-User / Per-Machine installation affects the content that is written under these keys.

Under these keys, you will find details of all the Windows Installer products and components that have been installed onto the workstation. These Product Codes and Component IDs are stored as packed GUIDS, the packing is done as it takes up less space and allows faster access. The curly braces and hyphens are discarded, saving 6 bytes per GUID, and then related back to original data in the following way:

Original Product Code:
{12345678-ABCD-WXYZ-1234-ABCDEFGHIJKL}

String manipulation steps:

Recombine characters without any curly braces or hyphens to see your packed GUID:
87654321DCBAZYXW2134BADCFEHGJILK

In summary:

To use Microsoft's term on the different "globally unique identifier (GUID)" the following would apply:
Uncompressed GUID (standard): {12345678-ABCD-WXYZ-1234-ABCDEFGHIJKL}
Compressed GUID: 87654321DCBAZYXW2134BADCFEHGJILK

Reference Counting

Often when I refer to reference counting I have noticed that a number of people confuse Windows Installer reference counting with Windows reference counting (more commonly referred to as Shared DLL reference counting by application packagers). So here make the distinction we are talking about "Windows Installer reference counts".  

Another common item I hear is that reference counting is a count of the number of times a component is installed, however I think it is more appropriate to refer to it as the number of products which have installed a particular component.

The information is written to the registry by the ProcessComponents action. Under the components subkey (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components) you will find a list of Per-Machine Windows Installer components. The components will be identified by another subkey which is the Compressed Guid of the respective component. (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\<CompressedComponentGuid>. Per-User entries are written to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\<UserSID>\Components\<CompressedComponentGuid>).

Under each of these <CompressedComponentGuid> subkey's will be an undetermined list of REG_SZ registry strings. These REG_SZ strings are actually packed GUID's of the ProductCode of the application which installed the component. Such as:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\<CompressedComponentGuid>\<CompressedProductGuid> = <ComponentKeypath>

For those of you who are interested the <ComponentKeyPath> entry is enumerated by a function call to MsiGetComponentPath.

Based on this installing two applications which share the same Component you will find something similar to the following in the registry.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\<CompressedComponentGuidA>\<CompressedProductGuidA> = <ComponentKeypathA>

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\<CompressedComponentGuidA>\<CompressedProductGuidB> = <ComponentKeypathA>

If you find a REG_SZ string which is all 0's. Then the respective component is set not to be uninstalled during uninstall. This means that the component attribute contains a binary bitmask value of 16 or msidbComponentAttributesPermanent.

Some of you may at this point be asking so what does all this mean ? Well to make a very long story short it allows multiple applications to play nicely together particularly during uninstall. At some point I am sure many of you have tried to uninstall an older style application and been prompted with the infamous "This application is using shared DLL's do you want to uninstall these files" or you have uninstalled an application only to realise your machine is now completely non functional. Well reference counting is an attempt to make this a thing of the past. Enter Conflict Management (I will cover this in another blog)

Darwin Descriptors

I'm sure most of you have heard the tales not to repackage an MSI, well these little babies are one of the main reasons why NOT to repackage an MSI. "Darwin Descriptor" is actually an encrypted representation of a specific product, component, and feature. If these values exist, Windows Installer will decrypt the data, and use it to perform checks against the respective product and component. Refer to the previous blog on self healing for more detail about this action.

The problem encountered when capturing an MSI is this. When you install PRODUCT-A on your capture machine you write 'x' number of Darwin descriptors to the registry. Your snapshot tool will capture these darwin descriptors as registry information and incorporate them into PRODUCT-B. Remember these captured "darwin's" will have the PRODUCTCODE of PRODUCT-A encrypted into them.

As such if we install the captured PRODUCT-B onto a fresh machine you will still have "darwin's" pointing at PRODUCT-A which is no longer installed. It doesn't take a brain surgeon to work out the issue here.

If you want to get into the registry to see where all of this is stored go check out this location.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\<CompressedProductCode>\Features

Well that about wraps it up for another blog, as I am a little new to this if you guys see any room for improvement feel free to speak up. I may take the whole "darwin descriptor" feature even deeper in a future blog. 

One of the main features of Microsoft's Windows Installer technology is self healing. Self healing leverages the windows installer database to allow a full or partial reinstallation of a managed product under certain conditions.

For example lets assume you install a custom MSI of Winzip, and then proceeded to delete the files that made up Winzip. You could then run an advertised Windows Installer shortcut which acts as a proxy back to the Installer database and while you watch Winzip would be reinstalled. This feature is known as self healing, not to be confused with Self repair.

So in order to understand self healing you need to get a grasp on a few basics of Windows Installer.

The activation of the self healing process is triggered by the user accessing an advertised entry point when attempting to start an application. It is very important to understand that an application can consist of multiple entry points, as such it is vital to know the location of the entry point within the MSI feature structure. For example if there is 3 features in your application called FEATURE1 FEATURE2 and FEATURE3 if your entry point is located in FEATURE1 then self healing will start in FEATURE1. If your entry point is located in FEATURE3 then healing will start respectively in FEATURE3.

It is common with self healing to use the shortcut as an entry point, this is not a hard and fast rule, it simply stands to reason that the user is likely to run a shortcut to activate an application. Therefore a shortcut is a likely place to initiate the healing process. Shortcuts can be both advertised and non advertised. The target column of the shortcut table dictates whether a shortcut is advertised or not. If you wish to utilise self healing then the use of advertised shortcuts is advised.

Once an entry point has been accessed the installer services queries the entry point to find which feature it belongs to. Once obtained it then queries that feature for all of the components it contains. There are a number of important component attributes which are gathered during this process. These items are: Component Name, Component Install State, Component code and Component Keypath. Most of this information can be viewed via the Component Table of any Windows Installer MSI.

The Keypath being one of the more important attributes will reference one of the items contained within component (note a component can contain multiple items only one of which can be a keypath); The keypath will represent a file or registry key which should be present on the machine if the Component State is set to be installed. If Component state is set to be installed a check will be made on the target machine to determine if that file or registry key is present on the target. Where a keypath is not present the installer service initiates self repair in one of the two modes explained in the next paragraph.

There are two types of healing modes "Feature Level healing" and "Component Level healing". Feature level healing is performed when the broken keypath is located in the same feature as the entry point. A feature level heal will heal all items contained within a feature, this means that when a single component is broken in a feature which contains multiple components all components are healed regardless of whether they are broken or not whilst taking into consideration each components install state. A component level heal will only heal an individual component other components within that feature will not be affected.

Now something which always catches people out when this is explained is what happens after checking the first feature. This is probably the most misunderstood part of self healing. So bear with me, please make a distinction between checking and healing in the next paragraph. (added for you Bruce.)

If the feature containing the accessed entry point does not have any broken components identified by missing keypath references, then a check will be made for any parent features of that initial feature. If a parent feature is found the healing mode is switched from Feature level healing to Component level healing and process begins again on the new feature. If there are no parents then self healing stops the checking functionality at that point. (Note: Child or sibling features are NOT checked.)

Now if the entry point feature did have broken components identified by missing keypath references that feature would be healed at Feature level and the remaining MSI feature set would then be enumerated and subsequently checked. Where a feature did have a parent feature and that parent contained broken components all remaining features would be checked regardless of location within the MSI feature structure. (Note: this means all features are checked regardless of location when any broken component is found)

Another common misconception is when attempting to disable self healing within a component, as self healing is triggered when Keypath are missing assumptions are made to delete the keypath to stop self healing. In actual fact if you wish to stop self healing on a single component the correct method is to remove the components component GUID from the component table. (this will be explained in more detail in the section on packed GUID's)

It is also useful to note that when running add/remove programs and selecting the repair option a full heal is performed on the application in a similar manner to that of the initial installation.

Taking this a step further a feature commonly referred to as "user profile fixup" leverages the self healing functionality to repair items deployed into a users profile. An example being when you install applications logged in as USERA then log off and log back in as USERB items that were deployed to the user profile of USERA may not be accessible for USERB. By marking items within the users profile as a keypath each user will get the profile specific data deployed when launching the advertised shortcut (entry point) of the application through standard self healing techniques. I have written a post on how to exploit this functionality a few years back on http://www.myitforum.com labelled as:

Current User healing and Current User healing II.

Both documents are very old and need to be rewritten as they contain a few minor errors (I will endeavour to do this ASAP), however the technique is still very valid and widely practiced around the world.

Windows Installer Caching

Each time a Windows Installer MSI is installed a partial copy of the Windows Installer MSI is copied to the target machine usually in this location %windir%\installer. Binary files are included within the cache, however embedded cabinets are removed (from the _Streams table) before the package is cached. Generally they are smaller than the original source MSI.

When a broken application is found and self healing occurs a determination is made where the corresponding item will be repaired from. If it is just registry or ini file data then this can be done by the locally cached MSI. If the item is a file it will not be contained within the cache and as such an attempt will be made to access the original install media. I'm sure many of you have seen office prompting for a CD on a few occasions.

(Note: For this reason it is not considered smart to install an MSI from a CD, as attempts will be made to access that media for the remainder of the time the application is installed on the target)

As described above a way to counter this is to populate the SOURCELIST property prior to installation. A semi colon delimited list of servers can be added to the sourcelist to allow alternate heal points. Such as:

\\MySourceServer\Apps;\\%AppServer%Apps;x:\apps;\\DFS\Apps

If however you have made the mistake of deploying from CD and need to change a SOURCELIST after deployment. Darwin Sanoy of www.desktopengineer.com has written a script to change the sourcelist of pre Windows Installer 3.0 systems. When 3.0 is installed this can be used.

Dim objInstaller

Set objInstaller = CreateObject("WindowsInstaller.Installer")

objInstaller.AddSource "{00000ABC-ABE1-11D2-B60F-006097C998E7}", "", "\\MySourceServer\apps"

The next few topics of Darwin Descriptors and Packed Guids will cover this in even more detail.