Packaging Skype with Auto Update disabled

EDITED: I have edited this post on 30-Aug-2013 after some users comments that the given solution is not working. I have studied in depth the skype update process and created this solution for all. Please check below (Edited Section) for more information.

Recently while packaging Skype for enterprise version, I could not disable the Auto Updates and finally found a way to get rid of it.

You can get the latest version of Skype setup in MSI format from the following URL: http://download.skype.com/msi/SkypeSetup.msi or
http://www.skype.com/go/getskype-msi

There is no registry, file which can disable the Auto Update functionality of Skype. I searched in lots of forums and all said that it automatically prompts for update. So finally I decided to look in the MSI and find why and how it is doing it.

What I found was that Skype has an Updater.exe in the installation folder and it also creates a Skype Update service which points to this exe.

I just removed this service and updater.exe file from the skype msi package and it worked.

No need to do anything else. Just do this small part and you are done with removing the Auto Update in Skype.

Edited:
I have been asked and told by a lot of users that this is not working so I am adding a further solution which will definitely work without a doubt. I have mass deployed this and it has worked fine. For all the users who were getting the pop ups, this has fixed it.

You need to create a dummy SetupSkype.exe file and a Skypefix.vbs as below and add it to your INSTALLDIR (C:\Program Files\Skype\Phone\) of the package.

SkypeFix.vbs:
'==============================================
dim filesys, oShell
Set filesys = CreateObject("Scripting.FileSystemObject")
Set oShell = CreateObject("WScript.Shell")

des1 = oShell.ExpandEnvironmentStrings ("%Temp%")
sup = oShell.ExpandEnvironmentStrings ("%ProgramFiles%")
windir = oShell.ExpandEnvironmentStrings ("%Windir%")

destfile1= des1 & "\SkypeSetup.exe"
sourcefile1= sup & "\Skype\Phone\SkypeSetup.exe"

'Copy files

If filesys.FileExists(sourcefile1) Then

 a= filesys.CopyFile (sourcefile1, destfile1,True)

End If

oShell.Run windir & "\System32\Icacls.exe " & destfile1 & " /deny Everyone:D"

'=================================================

After this you need to create an Active Setup registry key which will run this vbs file for every user who logs off and logs in. After this there will be no upgrade issue.

This script works on the fact that SkypeSetup.exe gets downloaded from internet to %temp% folder of user and when it is downloaded, it starts prompting up for upgrade. I have created this file before hand in %temp% folder or replace the already existing one with this dummy file and then put a deny restriction to all the users on this file. So now a file cannot be downloaded to %temp% folder because there is already a file which cannot be deleted/replaced. Hence no more upgrade prompts.
I have created this solution by deeper understanding of Skype setup and upgrade.

Hope this tip will be helpful to you and let me know if it still does not work.

App-V with Java/JRE/JDK

It is very critical to understand how to handle installation of Java related applications in App-V environment.
While some are of the view that the application should be installed along with Java in the same bubble while some say that the Java version installed on the base machine can be used.

Here is how you can do both of these in a proper way:

1) Java installed locally on the machine: If Java is locally installed on the machine and you capture the App-V application, then you will see a hard coded entry in the registry. This basically points the App-V application to look for Java in this local machine location. If you upgrade your Java version from say 1.6.21 to 1.6.24, then you do not need to worry, however, if you do a major upgrade from 1.6.21 to 1.7.xx then you need to upgrade your App-V Application as well. You need to maintain the software library for all these applications and then upgrade them as part of Java Upgrade in the organization.

2) Java is installed as local copy inside App-V bubble: Java can also be installed as a local copy with your App-V application. There can be various reasons for doing this:
 a) Application is compatible only with a certain version of Java
 b) Application uses a higher version which is not locally installed.
 c) If Software manager do not want to upgrade the application every time Java gets updated.

In these cases a private copy of Java can be captured with App-V. However, there is a procedure for achieving this.
These steps will be helpful in doing this:

http://packagingguide.blogspot.com.au/2011/11/app-v-for-java-runtime-environment.html

Creating a Device driver based package in Installshield

It is very easy and simle to create a device driver based application from Installshield.
I am using Installshield 2012.

You need to make sure that the driver is a signed driver. If the driver is not signed, then you need to sign the driver first. It is good to have your driver signed, but you can install and unsigned driver as well. Check an option later.

Go to Installshield Wizard in Installation Designer and click on Project button on top an then Device Driver wizard.

Click Next ->

Select the path to your .inf file on your machine. Choose the system architecture. I am choosing x64 as I am packaging for 64 bit machines.

Click Next-> Next->

Select the options as per your requirement. I have chosen the above ones.

Click Next->

Click Next->

You will get the summary and then click on Finish.

It will add the settings in your component of INF file.

Hope this helps you create device driver easily with Installshield.

Packaging Google Chrome for Enterprise deployment

Many times it is an issue with the Administrators to deploy Google Chrome enterprise wide as there are lots of issues like:

1) Many people would have already installed various other versions of Chrome either through MSI or through exe.
2) How to customize Google chrome for enterprise wide deployment.

*Edited: The new version has a few differences, please see the end of post on how to tackle this.*

First, I would like to mention here that Google Chrome Enterprise version can be downloaded from the following location:
http://www.google.com/intl/en/chrome/business/browser/

This site contains an MSI, which is already customized for business as in there are no desktop/Taskbar shortcuts and the application automatically goes to Program files folder.
If you need to customize this, it is best to capture this MSI as it runs a Setup.exe from within.
I would say that, this MSI is good enough to go like this too so not recommended to waste your time in capturing the MSI unless specifically required.

You can add master_preferences file in the Google\Chrome\Application folder with following contents:

{
"homepage" : "http://msiworld.blogspot.com",
"homepage_is_newtabpage" : false,
"browser" : {
"show_home_button" : true,
 "check_default_browser" : false,
 "window_placement": {
 "bottom": 1000,
 "left": 10,
 "maximized": false,
 "right": 904,
 "top": 10,
 "work_area_bottom": 1010,
 "work_area_left": 0,
 "work_area_right": 1680,
 "work_area_top": 0
 }
 },
 "bookmark_bar" : {
"show_on_all_tabs" : true
},
"distribution" : {
"skip_first_run_ui" : true,
"show_welcome_page" : false,
"import_search_engine" : false,
"import_history" : false,
"create_all_shortcuts" : true,
"do_not_launch_chrome" : true,
"make_chrome_default" : false
}
}

If you add this, change the install sequence of Custom Actions which are already there in the MSI to run before InstallFiles action. That is, move InstallFiles Action after DoInstall. This will make sure your master_preferences file is retained till end.
*Edited
There are are 3 Custom Actions by the name starting from : CallUninstaller
Change their condition to REMOVE="ALL"
This will enable for a clean upgrade else you will face issues while upgrading the application.
*
Uninstall Any Previous Version of Chrome:

To Uninstall any previous version of Chrome, I have written this VBScript which can be run before the installation of your MSI.

'==============================================================
'Lines to get the computer Name
Const HKEY_LOCAL_MACHINE = &H80000002
 Set wshShell = WScript.CreateObject( "WScript.Shell" )
 strComputerName = wshShell.ExpandEnvironmentStrings( "%COMPUTERNAME%" )
 dim folder, MyProperties, arrMyProperties, Exe, Param, oReg, strKeyPath, strValueName

'==============================================================
 'To check whether the OS is 32 bit or 64 bit of Windows 7
'==============================================================
'Lines to detect whether the OS is 32 bit or 64 bit of Windows 7
 Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputerName & "\root\default:StdRegProv")
   strKeyPath = "HARDWARE\DESCRIPTION\System\CentralProcessor\0"
   strValueName = "Identifier"

 oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue
'==============================================================
'Checking Condition whether the build is 64bit or 32 bit
   if (instr(strValue,"64")) then
 folder = "C:\Program Files (x86)\Google\Chrome"
 RegVal = ReadReg ("HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome\UninstallString")
 End If
if (instr(strValue,"x86")) then
 folder = "C:\Program Files\Google\Chrome"
 RegVal = ReadReg ("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome\UninstallString")
End If
'==============================================================

MyProperties = RegVal
arrMyProperties = Split(MyProperties, "-")
Exe = arrMyProperties(0)
Param = "--uninstall --multi-install --chrome --system-level --force-uninstall"
'Uninstall Previous version Chrome
'==============================================================
wshShell.run Exe & Param, 1, True
'Delete leftover folder and files from Previous version Chrome
'==============================================================
dim filesys
Set filesys = CreateObject("Scripting.FileSystemObject")
If filesys.FolderExists(folder & "\") Then 
   filesys.DeleteFolder folder
End If
Function ReadReg(RegPath)
      Dim objRegistry, Key
      Set objRegistry = CreateObject("Wscript.shell")
      Key = objRegistry.RegRead(RegPath)
      ReadReg = Key
 End Function


Hope these steps will reduce your efforts in deployment of Chrome.

*
With the New version 26.0.1410.64, Google has changed the install sequence. do the following:

1) In InstallExecuteSequence Table move InstallFiles action after DoInstall Custom Action. This DoInstall Custom Action is actually installing the Google Chrome from an exe. So if the MSI already had copied the master_preferences file, this exe will replace it with its own. If you place the InstallFile Action after DoInstall, then the file which you have added in your package will overwrite the one which Google provides.
2) You might have to write a small script to delete the shortcut from C:\Users\Public\Desktop, if you do not want a desktop shortcut.
Place this CA at the end just before InstallFinalize.

Definition of Application Re-Packaging

I have been often asked about the proper definition of Application Re-Packaging. This is the best I could find:

Application Re-packaging solution offers customized application configuration and repackaging of third-party or internally-developed applications to standardize the installation routine, reduce deployment errors, and minimize support costs.

Frequently asked Questions about COM and Windows installer (MSI) / Application Packaging

What does the common language runtime do?
The common language runtime manages the execution of code and provides services such as cross-language integration, code access security, object lifetime management, and debugging and profiling support. Search for "Common Language Runtime" in the MSDN Library (msdn.microsoft.com/library/).


What's the difference between managed and unmanaged code?
Code developed with a language compiler that targets the common language runtime is called managed code. All code based on Microsoft intermediate language (MSIL) executes as managed code. Managed code is self-describing; it contains metadata that describes every element managed by the common language runtime. The runtime uses the metadata to provide services.
Code that runs outside the runtime and does not contain metadata is called unmanaged code. Examples of unmanaged code are COM components, ActiveX interfaces, and Win32 API functions. Unmanaged code executes in the common language runtime environment with minimal services.


Can I add managed code to an existing application?
Few developers are able to rewrite existing applications completely as managed (.NET) code. Instead, you can combine managed and unmanaged components in one installation. Code that contains a mix of managed and unmanaged elements is called interoperable code.
The common language runtime supports COM interoperability (interop). For backward compatibility, COM interop provides access to existing COM components without requiring you to modify the original components. COM interop also enables your COM clients to access managed code as easily as they access other COM objects. This is accomplished by adding information to the system registry so .NET components are called as though they were COM components. At runtime, the common language runtime marshals data between COM objects and managed objects as needed.
Search for "Interoperating with Unmanaged Code" in the MSDN Library (msdn.microsoft.com/library/).


What is an assembly?
An assembly is the primary building block of a .NET application. An assembly contains its own naming, binding, versioning, deployment, and configuration information. It consists of 2 elements: a manifest, which is the meta data that describes information about the assembly and any resources it depends on; and a set of instructions in the form of Microsoft Intermediate Language (MSIL) code that is executed when the assembly is referenced.
You can group assembly elements into a single file assembly, which incorporates the manifest into a portable executable (PE) file, which can be an .EXE or .DLL, with the source code. You also can create a multifile assembly consisting of modules of compiled code, resources, or other files required by the application. In a multifile assembly, the manifest can be a standalone file or it can be incorporated into one of the PE files in the assembly.

When you add a .NET assembly to an installation, Windows Installer Editor creates entries in the MsiAssembly and MsiAssemblyName tables.
See Assemblies in the Windows Installer SDK Help.


How does .NET reduce file sharing conflicts?
An important benefit of .NET installations is the reduction of file sharing conflicts. With the common language runtime, the assembly is described by a manifest; the registry is no longer relied upon for storing and accessing the COM activation data. This allows components to be fully isolated from each other.
Assembly sharing is accomplished in several ways:
a) Global Assembly Cache
To install .NET assemblies that are intended to be shared by many applications on the computer, make sure they are strongly named and install them into the Global Assembly Cache, which is a machine-wide code cache. Do not install assemblies into the Global Assembly Cache unless they specifically need to be shared. The Global Assembly Cache is available only if the .NET Framework is installed on the destination computer.
b) Side-by-side
To safely share COM or Win32 assemblies among multiple applications and to minimize .DLL conflicts, use side-by-side assembly sharing. Instead of having a single version of an assembly that assumes backward compatibility with all applications, side-by-side assembly sharing enables multiple versions of a COM or Win32 assembly to run simultaneously on the destination computer. Side-by-side assembly sharing is available only on Windows XP or later. See Side-by-Side Assemblies in the Windows Installer SDK Help.
c) Private assembly
To reserve a Win32 assembly for the exclusive use of one application, install it in a directory that is private to the application, typically the application directory. This is called a private assembly. The dependency of the application on the private assembly is specified in an application manifest file. On operating systems earlier than Windows XP, a copy of the private assembly and a .local file is installed into a private directory for the exclusive use of the application. A version of the assembly is also globally registered on the system and made available for any application that binds to it. The global version of the assembly can be the version installed with the application or an earlier version.


I thought .NET meant I could use XCOPY to install applications without registration. Why do I need to build a Windows Installer installation?
For a .NET application that uses only managed code and private assemblies, the installation process can be as simple as copying files to the destination computer. Most developers, however, still need to create a compressed, single-file installation that is easy to deploy and that provides a friendly interface to the end user.
.NET applications that use shared assemblies, or that have a mix of managed and unmanaged code, cannot be installed via XCOPY. You should use the Windows Installer service for installations that do any of the following:
a)Install COM files
b)Install assemblies to the Global Assembly Cache
c)Require user information during the installation
d)Require security
e)Create a shortcut
f)Require elevated privileges to install on a locked-down computer

By creating a Windows Installer installation for your .NET applications, you can take advantage of the services Windows Installer provides: installation, repair, and removal of assemblies; roll back; install-on-demand; patching; and advertisement.


How does Windows Installer Editor support .NET installations?
Windows Installer Editor lets you install .NET assemblies into the Global Assembly Cache, or as side-by-side or private assemblies. It also lets you create mixed installations by registering .NET assemblies with COM.
If the .NET Framework is installed on your computer, Windows Installer Editor can automate the process as follows:
a) Find all files in multifile assemblies and add them to the installation.
b) Scan for assembly dependencies and add them to the installation.
c) Determine attributes for registering the assembly files and add them to the MsiAssemblyName table.
d) Add registry keys for COM interop.

Different Ways of Giving Permissions in Your Windows Installer

Windows XP/Windows 7 works under a locked down environment in most organisations. The MSI authors generally have to provide permissions to the installation directory, so that the users without admin rights are able to access and write data into the installation directory.
When you set permissions, you are specifying what level of access the user has to the folder and its files and what users can do within that folder such as save, delete, or read files.
If you would like to know how to set permissions through Powershell Script, then I would recommend you to read my new blog entry here:
http://msiworld.blogspot.com/2012/01/my-first-powershell-script.html

There are six standard permission types which apply to files and folders in Windows XP/Windows 7:

Full Control

Modify

Read & Execute

List Folder Contents

Read

Write

Each level represents a different set of actions users can perform. See the table below for more information.

For folders you can also set your own unique permissions or create a variation of any of the standard permission levels. Within each of the permission levels are many possible variations.

The following table represents the available standard permission types with their descriptions:

Full Control - Permits the user(s) to:

view file name and subfolders

navigate to subfolders

view data in the folder's files

add files and subfolders to the folder

change the folder's files

delete the folder and its files

change permissions

take ownership of the folder and its files

Modify - Permits the user(s) to:

view the file names and subfolders

navigate to subfolders

view data in the folder's files

add files and subfolders to the folder

change the folder's files

delete the folder and its files

Read & Execute - Permits the user(s) to:

view file names and subfolder names

navigate to subfolders

view data in the folder's files

add files and subfolders to the folder

List Folder Contents - Permits the user(s) to:

view folders

navigate to subfolders

view folders

does not permit access to the folder's files

Read - Permits the user(s) to:

view the file names and subfolder names

navigate to subfolders

run applications

open files

copy and view data in the folder's files

Write - The Read permissions, plus permits the user(s) to:

create folders

add new files

open and change files

delete files

You can set permission to folders in following ways:

Secedit

XCACLS/ICACLS

LockPermission table.

Full Control - Permits the user(s) to:

view file name and subfolders

navigate to subfolders

view data in the folder's files

add files and subfolders to the folder

change the folder's files

delete the folder and its files

change permissions

take ownership of the folder and its files

Modify - Permits the user(s) to:

view the file names and subfolders

navigate to subfolders

view data in the folder's files

add files and subfolders to the folder

change the folder's files

delete the folder and its files

Read & Execute - Permits the user(s) to:

view file names and subfolder names

navigate to subfolders

view data in the folder's files

add files and subfolders to the folder

List Folder Contents - Permits the user(s) to:

view folders

navigate to subfolders

view folders

does not permit access to the folder's files

Read - Permits the user(s) to:

view the file names and subfolder names

navigate to subfolders

run applications

open files

copy and view data in the folder's files

Write - The Read permissions, plus permits the user(s) to:

create folders

add new files

open and change files

delete files

You can set permission to folders in following ways:

Secedit

XCACLS/ICACLS

LockPermission table.

SECEDIT:

SECEDIT command-line tool can be used to impose group policy object settings upon a target workstation immediately.
To use Secedit to give permission in your package, perform the following steps:
Go to Run and type MMC.
A Console will open up as shown in the below picture.
Go to File -> and click on Add / Remove Snap in.



The Add / Remove Snap in window opens up as shown in the below picture.



After this Click on Add...
Add standalone Snap in console opens up as shown in the below picture.



Choose Security Template from the list of Snap in, and click on Add.
The Security template will be added to the console.
You can see the File System, with all the listed directories on the right. This is shown in below picture.



Now, delete all files on right.
Right click and click on Add File, browse and select the required directory to give permission to.
Similarly you can give permission to registry too.



Now, delete all files on right.
Right click and click on Add File, browse and select the required directory to give permission to.
Similarly you can give permission to registry too.



Click on OK and save this template as .inf (such as {PackageName}.inf) file.
Now we have to include this file in the package.
Add this file to %Windir%\security\templates folder.
Use the following Custom Action in your package to implement Secedit.

Use Execute Program from Destination Custom Action.

Give Custom Action name as per your standards

Working Directory to be set is Templates folder (where we have placed the .inf file.

In exe and Command line give the following command:

secedit /configure /db "[security]Database\{PackageName}.sdb" /cfg "[security]templates\{PackageName}.inf" /log "[security]logs\{PackageName}.log" /quiet

Here [security] refers to the security folder is C:\Windows or %Windir%\Security. It is always good to use directory instead of hardcoded paths.

{PackageName} refers to the name you would like to give to your .inf file, to your log file you create and to the .sdb file you create.

Note that this will create .sdb file in %windir%\security\Database folder and .log file in %windir%\security\logs folder. So while un-installation of package you need to remember to delete these files from the folder. You can do that by using remove file table.

The location of the Custom action should be just before install finalize.

The Condition for launch of Custom Action should be "NOT REMOVE"

The Custom action can be run in deferred mode in system context.

XCACLS/ICACLS:

XCACLS or Extended Change Access Control List tool, is an advanced version of CACLS, the difference being that we do not have to answer Yes/No prompts in XCACLS. CACLS and XCACLS are tools which are used to modify the ACLs (Access Control Lists), by which in turn we are modifying the folder permissions for users in windows. ICACLS is another tool like XCACLS.

CACLS is installed in all users machine in System32 folder.

XCACLS ships with the Windows NT Resource Kit or can be easily downloaded from net. XCACLS allows you to set permissions to the same granular level of control that you have with the GUI.

CACLS Syntax

CACLS filename [/T] [/E] [/C] [/G user:perm] [/R user [...]] [/P user:perm [...]] [/D user [...]]

filename	Displays ACLs.
/T	Changes ACLs of specified files in the current directory and all subdirectories.
/E	Edit ACL instead of replacing it.
/C	Continue on access denied errors.
/G user:perm	Grant specified user access rights. Perm can be: R Read C Change (write) F Full control
/R user	Revoke specified user's access rights (only valid with /E).
/P user:perm	Replace specified user's access rights. Perm can be: N None R Read C Change (write) F Full control
/D user	Deny specified user access.

Wildcards can be used to specify more that one file in a command.
You can specify more than one user in a command.

XCACLS Syntax

XCACLS filename [/T] [/E] [/C] [/G user:perm;spec] [/R user [...]][/P user:perm;spec [...]] [/D user [...]] [/Y]

filename	Displays ACLs.
/T	Changes ACLs of specified files in the current directory and all subdirectories.
/E	Edit ACL instead of replacing it.
/C	Continue on access denied errors.
/G user:perm;spec	Grant specified user access rights. Perm can be: R Read C Change (write) F Full control P Change Permissions (Special access) O Take Ownership (Special access) X EXecute (Special access) E REad (Special access) W Write (Special access) D Delete (Special access) Spec can be the same as perm and will only be applied to a directory. In this case, Perm will be used for file inheritence in this directory. If not omitted: Spec=Perm. Special values for Spec only: T NoT Specified (for file inherit, only for dirs valid) At least one access right has to follow! Entries between ';' and T will be ignored!
/R user	Revoke specified user's access rights.
/P user:perm;spec	Replace specified user's access rights. for access right specification see /G option
/D user	Deny specified user access.
/Y	Replace user's rights without verify

Wildcards can be used to specify more that one file in a command.
You can specify more than one user in a command.
You can combine access rights.

Example of XCACLS can be:

xcacls "[INSTALLDIR]FOLDER" /e /g users:ewxd;ewx

Usage for ICACLS

ICACLS "[INSTALLDIR]FOLDER" /T /grant USERS:M

LockPermission table:

LockPermission table can be also used to give permission to files, folders and registries.
With the help of Lockpermission table you can give permission to only those users who already exist on the computer or domain.
For giving permission through LockPermission table follow the below procedure:
On the File section in Installation expert (You can do the same with Registry too) , Either go to file or the directory (depending on to which you want to give permission) and click on Details. There will be a permission tab there. For giving permission to file you will get the below screen where there will be a permissions tab among other tabs as shown in the picture. If you have chosen directory then there will only be a permissions tab. Click on Add. In the domain, you can mention the domain of the user for which permissions are to be set. You can either give a standalone machine or a domain name. I have used an environment variable here [%USERDOMAIN] which will pick the domain at run time for the user for which the package is being installed. The user which you can set can be Administrator, Everyone or Logged on User. I have selected every one here.



After that you can select the permissions from below what all permissions you want to give to the user. Click ok and the permissions work is over.

Now when you go to the LockPermissions table in Tables section, you can see the following columns there:

Lock Object, Table, Domain, User and permission.

Lock Object and Table column together specify the file, directory or registry key to be given permission to. Lock Object contains the name of the file, directory or the registry name. Table column can be filled with File, Create Folder or Registry. Lock Object is the foreign key to the primary key of Table mentioned by Table column.

Domain as I have mentioned earlier is the domain of the user.
User too as I have mentioned earlier is the User to whom we want to give the permission.
Permission is the Generic number to the permissions we have specified.

Every file, registry key, or directory that is listed in the LockPermissions Table receives an explicit security descriptor, whether it replaces an existing object or not. The Windows Installer attempts to preserve the security on objects that already exist on the system. If an object is not listed in the LockPermissions Table, and replaces an existing object, the replacement gets the security settings of the object that it replaces.

If an object is not listed in the LockPermissions Table, and does not replace an existing object, it receives no explicit security descriptor. The access to the new object is based on the attributes of its parent or container object. If an object is not listed in the table, and replaces an object with no explicit security descriptor, the access to the new object is based on the attributes of its parent or container object.

Hope this article helps you to builds up your knowledge on how to give permissions to your files, folders and registries.

Required Properties in MSI

There are five properties which are required by every Microsoft installer to identify itself from other MSI.

These properties are required to be present in every MSI.

These are the five properties:

1) Product Name: It is the name of the application you mention in your MSI.
2) Product version: This is the version of the product which you give.. like 1.0.0 etc..
3) Product code: It is the unique GUID for your MSI.
4) Product language: This is the numeric value of product and should be one of those entries mentioned in Template summary property in Summary information stream.
5) Manufacturer: This is the name of the manufacturer of the product.
For future upgrades, it is recommended to add Upgrade code property in the package.

Difference Between Self Heal and Repair

Self Heal and Repair are two different concepts in Windows Installer which people many times consider to be the same thing, however there is difference in these two.

Self Heal is triggered by advertised shortcuts, or other advertising information in the package which eventually Repairs the application.

When the application is launched by advertised shortcut, it checks for all the key paths of the Current Feature, if any of the key paths is missing it will launch Repair.

Note that if there are multiple features then it will not check the missing key paths of the other features, but only the feature of which the advertised shortcut is launched.

Repair of an MSI can be triggered by

Repair button in Add/Remove programs
Giving the command line msiexec /f{other option} {MSI name}
Self Heal by advertised shortcut or other advertising information.
Active setup
Once the repair of the package is triggered, even with Self Heal, then the whole of the MSI is reinstalled. Then it does not see that only the feature which triggered the self heal should be repaired, but the whole MSI, by which I mean, all its features are reinstalled.

Hope this clarifies the difference between two.

How REINSTALLMODE=amus Works

In any of these installation transactions, viz. initial installation, repair, reinstallation, on-demand installation or patching an MSI, The REINSTALLMODE has an affect on it.

Here is what "amus" means:

* a - Force all files to be reinstalled, regardless of version
* m - Rewrite all registry keys that go to HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT
* u - Rewrite all registry keys that go to HKEY_CURRENT_USER or HKEY_USERS
* s - Reinstall shortcuts and icons

The mentioning of "a" in amus forces the reinstallation of files on your machine irrespective of the file version rules. Every file updated by REINSTALL property will be updated in this case.

The sequence of events which happen actually depend on the authoring of your patch.

If your patch contains the full file, the installer will not access the source to reinstall that file, but if your file is the delta of the file, like an update to say ini file, then the patch will access first the machine file and update it, and if machine file is not accessible to the patch, then in that case, the installer will go and grab the file from the original source location and will work from there.

REINSTALLMODE=amus is not the recommended solution, but sometimes situations become inevitable and we need to use them.

Using SOURCEDIR Property in Package

SOURCEDIR property in MSI package refers to the location from where the MSI is installed in the machine. How do we use this property in our package.

If you want to use a file which is kept in the source folder (next to where your MSI is placed), through Custom Action then you need to follow this procedure.

The SOURCEDIR cannot be directly used in the package. If you read the logs then SOURCEDIR property is created and correctly pointed to the directory. But later the log shows that: Deleting SOURCEDIR... So the value of this property is deleted and the MSI does not get access to it. If you display message with [SOURCEDIR] property then it will be empty.

The work around for this is that we can put an Action in the sequence called: "ResolveSource" after CostFinalize action. Then if you place your Custom Action after this action which refers to SOURCEDIR property then you will get the correct value of SOURCEDIR.

Acknowledgement: I would like to thank my friend, Anurag, here who helped me to figure this out.... :)

Isolation of a File: Two Ways in One MSI

Generally you would have read that after isolation is done, we should not modify the MSI. So how to do .local and .manifest in the same MSI. Actually you would be thinking: "What is the need to do both types in the same MSI?" This is because, recently, I came across a situation in which we needed to do isolation of a file for installation of application in Windows 2000 through .local method and for installation in Windows XP and Vista through .manifest method. This was needed to be done through same MSI.

This is the solution. Create a .msi file with .local isolation method for windows 2000. Then create another .msi file with .manifest isolation. Note the visual difference of .manifest isolation file and the base MSI. Make all the differences seen in this to the .msi which was created with .local isolation. Then compile it. This will not get corrupted. Only the ones with .manifest isolation if recompiled again get corrupted. So take care of this and you can then conditionalize the components to be installed for 2000, XP or Vista...

How to Create Packages with a Size Greater Than 2 GB

Packages which need to include or which capture files with a total size exceeding 2 GB, it's necessary to use some tricks. Usually the MSI with cabs compressed outside the MSI allows the maximum size of cab files to be 2 GB. If the cab size file tries to exceed 2 GB, then the WISE package compilation throws an error.

For this you need to create separate features. In these separate features, distribute the files in the package so that the feature has a total file size of less than 2 GB.

After this you need to go to Media option in Installation expert and choose option one cab file per feature.

This will give you the MSI along with cab files which have size less than 2 GB.

Since the total package size will be very big, the downloading of cab files while deploying and then uncompressing them, will take lots of time. So the other solution is to choose the option of Uncompressed Files outside MSI in the media option. This will save time during installation.

Using VBScript to Set Properties in MSI

We can easily use Set Property Custom Action to set Windows Installer Property, but sometimes we wish to set the property directly in VbScript, specially if we are taking an input from a user through VBScript. Hope this tip helps.

To set property through VBScript we can use "Session" object like:

Session.Property("ALLUSERS")="1"

or we can directly use Property keyword like:

Property("REBOOT")="ReallySuppress"

The only catch here is that we cannot set INSTALLDIR property through the above method as the package uses Directory table to store the value of INSTALLDIR. We need to write the below VBScript to set INSTALLDIR:

dim instpath

instpath = "C:\newpath\newfolder"

Session.TargetPath("INSTALLDIR")=instpath

Remember to place this Custom Action after CostFinalize if you are changing the value of INSTALLDIR property in UI Sequence.

Exclusion List

Exclusion List

• Manual Checks: Exclude (delete) any unwanted files and folders. Some common file extensions that should usually be excluded are listed below. If the resource you are deleting is a keypath (indicated by the key symbol) you must ensure the related component has been assigned a new keypath. If the component is now empty it can be deleted.

Common Items:

HKEY_USER_SELECTABLE\Software\Shortcuts
Event log registries.
All VCache Entries
Shutdown Entries
Uninstall Entries
Your Username if Captured
*.log-app specific
services / hosts – These must be handled appropriately
Folders/ Files referring to Wise
Folders/ Files referring to InstallShield
Any cookies
Any file from the dependency applications that has got captured must be excluded.
Cache
Temp
Tmp
Bag
Log – Examine in notepad to see if they are relevant or not.

• Files

*.REG files
_isreg32.dll
setup.exe
install.log
install.exe
install.ini
unwise.exe
Uninstall.xml
Upgrade.exe
Update.exe
uninstall.cif
uninstall.cfg / uninstall.cgf
uninstall.dat
uninstall.dll
uninstall.ini
uninst.exe
uninstall.exe
deinstall.exe
Remove.exe / remove*.exe / *remove.exe
Regsvr16.exe
Regsvr32.exe
services.msc
*.ora files
*.oem files
Hosts File
C:\Temp
Pagefile.sys
C:\Winnt\Recent
Ntuser.ini
Ntuser.dat
Ntuser.dat.log
\Favourites\Desktop.ini
\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat.log
\Application Data\Desktop.ini
\Application Data\Microsoft\Internet Explorer\brndlog.txt
\Application Data\Microsoft\Internet Explorer\brndlog.txt.log
\Application Data\Microsoft\Internet Explorer\Quick Launch\desktop.ini
\Cookies\index.dat
\NetworkService\LocalSetting\Desktop.ini
Boot.ini
Hiberfil.sys
Ntldr
SchedLgU.txt
C:\RECYCLER
C:\System Volume Information

Local Settings\History\History.IE5
C:\Program Files\Common Files\InstallShield\Engine
C:\Program Files\Common Files\InstallShield\ISCRIPT
C:\Program Files\Common Files\Wise Installation Wizard
C:\Program Files\WindowsUpdate
C:\Program Files\InstallShield Installation Information
C:\Program Files\Sophos SWEEP for NT
C:\Program Files\Uninstall Information
C:\WINDOWS\Debug
C:\WINDOWS\Tasks
C:\WINDOWS\Prefetch
C:\WINDOWS\repair
C:\WINDOWS\CSC
C:\WINDOWS\System32\appmgmt
C:\WINDOWS\System32\CatRoot
C:\WINDOWS\System32\Config
C:\WINDOWS\System32\dllcache
C:\WINDOWS\System32\wbem
Lmscript.pif
Ttfcache
Ffastlog?.*
SMSCFG.ini
Any Cookies
TNSNAMES.ORA If Oracle package, then should be handled carefully. Should be deleted but entries to be appended through CA. Same for SQL.ORA and services file

• Registry:

HKEY_CLASSES_ROOT\Interface - all keys under ‘Interface’ can be deleted as they will be recreated automatically

HKEY_LOCAL_MACHINE\CLONE
HKEY_LOCAL_MACHINE\SAM
HKEY_LOCAL_MACHINE\Security
HKEY_LOCAL_MACHINE\Enum
HKEY_LOCAL_MACHINE\Hardware\

HKEY_LOCAL_MACHINE\Software\Novell
HKEY_LOCAL_MACHINE\Software\Program Groups\
HKEY_LOCAL_MACHINE\Software\Classes\
HKEY_LOCAL_MACHINE\Software\Description\Microsoft\Rpc\UuidPersistentData\
HKEY_LOCAL_MACHINE\Software\Description\Microsoft\Rpc\UuidTemporaryData\
HKEY_LOCAL_MACHINE\Software\Description\Microsoft\Rpc\UuidSequenceNumber\
HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography
HKEY_LOCAL_MACHINE\Software\Microsoft\Driver Signing
HKEY_LOCAL_MACHINE\Software\Microsoft\DRM
HKEY_LOCAL_MACHINE\Software\Microsoft\EVENTSYSTEM
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS
HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates
HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing
HKEY_LOCAL_MACHINE\Software\Microsoft\Mounted Devices
HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Reliability
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Management
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Controls Folder
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Runonce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run = Synchronization Manager
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\SharedDLLs
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Syncmgr
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Syncmgr\Autosync
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Windowsupdate
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\GroupPolicy\
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon
HKEY_LOCAL_MACHINE\Software\Microsoft\PCHealth\PchSvc
HKEY_LOCAL_MACHINE\Software\Microsoft\Dfrg\BootOptimizeFunction

HKEY_LOCAL_MACHINE\System\Clone
HKEY_LOCAL_MACHINE\System\Mounteddevices
HKEY_LOCAL_MACHINE\System\Select
HKEY_LOCAL_MACHINE\System\Setup
HKEY_LOCAL_MACHINE\System\ControlSet000\
HKEY_LOCAL_MACHINE\System\ControlSet001\
HKEY_LOCAL_MACHINE\System\ControlSet002\
HKEY_LOCAL_MACHINE\System\ControlSet003\
HKEY_LOCAL_MACHINE\System\ControlSet004\
HKEY_LOCAL_MACHINE\System\ControlSet005\
HKEY_LOCAL_MACHINE\System\ControlSet006\

HKEY_LOCAL_MACHINE\System\CurrentControlSet\SessionManager\Environment\
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\
HKEY_LOCAL_MACHINE\System\CurrentControlSet\hardwareProfiles\
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DHCP
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ E100b1\Parameters\Tcpip
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Security
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\System
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IDISW2KM\Enum
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Kmixer
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NMSCFG\Security
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NWCWorkstation
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TRKWKS
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{8AAE3FAA-E935-4AB3-B74C-55E12729E3DA}
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VCACHE

HKEY_CURRENT_USER\SessionInformation
HKEY_CURRENT_USER\Volatile Environment
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\GRPCONV
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Applets
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\SessionInfo
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\StreamMRU
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\MountPoints
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\StartPage
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Prefetcher
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\IME\China\IMEPY\TIPMIG
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Syncmgr\Handlers
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Toolbar\Shellbrowser
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Toolbar\Explorer
HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell
HKEY_CURRENT_USER\Software\Policies\Microsoft\SystemCertificates
HKEY_CURRENT_USER\Control Panel\Desktop
HKEY_CURRENT_USER\Control Panel\Keyboard\InitialKeyboardIndicators

HKEY_USERS\Software\Microsoft\SystemCertificates

Troubleshooting Unnecessary Repairs

Sometimes you may encounter the problem of unnecessary repairs of MSI while launching the shortcut in the same logged in user. Here is the way to troubleshoot this problem.
You can go to eventviewr (by typing eventvwr in Run command) then to applications and check the latest error message after repair. It will tell you which component is missing and because of which MSI went for self heal.
You can now check out this component in your package and see what the problem is. Maybe your keypath is a moving target for that component.

There are other methods too which can be used in case the above does not work. These are Logs/Gap capture.

More on this later.

Why Custom Action Type 51 is Required

If you have always wondered why we need to anSet Property Custom action when there is already a Property table to handle it, then this is for you.
Suppose we have to create a property based on the value of another property - in that case we cannot use the Property table to handle this. There will be a circular reference in which one property would be based on the other.
In this scenario we use Set Property Custom Action. To affect a property used in a condition on a component or feature, the custom action must come before the CostFinalize action in the action sequence.

Order of Precedence for Properties

The installer sets properties using the following order of precedence. A property value in this list can override a value that comes after it and be overridden by a value coming before it in the list.
1) Properties specified by the operating environment.
2)Public properties set on the command line.
3)Public properties listed by the AdminProperties property set during an administrative installation.
4)Public or private properties set during the application of a transform.
5)Public or private property that set by authoring the Property table of the .MSI file.

ICE Errors

Hi All,

My this post details about what ICE errors, how to check them and how to correct them. Many of you might be facing this problem.

What are ICE Errors

ICEs - Internal Consistency Evaluators

Internal consistency evaluators, also called ICEs, are custom actions written in VBScript, JScript, or as a DLL or EXE. When these custom actions are executed, they scan the database for entries in database records that are valid when examined individually but that may cause incorrect behavior in the context of the whole database.
For example, the Component table may list several components that are all valid when tested individually with MsiViewModify. However, MsiViewModify would not catch the error when two components use the same GUID as their component code. The custom action ICE08 is designed to validate that the Component table does not contain duplicate component code GUIDs.
ICE custom actions return four kinds of messages:
Errors: Error messages report database authoring that cause incorrect behavior. For example, duplicate component GUIDs cause the installer to incorrectly register components.
Warnings Warning messages report database authoring that causes incorrect behavior in certain cases. Warnings can also report unexpected side-effects of database authoring. For example, entering the same property name in two conditions that differ only by the case of letters in the name. Because the installer is case-sensitive, the installer treats these as different properties.
Failures Failure messages report the failure of the ICE custom action. Failure is commonly caused by a database with such severe problems that the ICE cannot even run.
Informational Informational messages provide information from the ICE and do not indicate a problem with the database. Often they are information about the ICE itself, such as a brief description. They can also provide progress information as the ICE runs.

(Source: MSDN)

How to get ICE Error report

The most easy way of getting the ICE error report is by using ORCA tool.
You can download it from the net and can install it to your PC. When you right click on any MSI then you will get an option: Edit with ORCA. Once you have clicked on that, The MSI will open and you can see all the tables present in the MSI. MSI is nothing but a relational database. This will be proved to you when you see all these tables.

CAUTION: Be careful of doing any changes to these tables. Any wrong entry or modification can crash your system or your MSI.

How to Correct ICE Errors

ICE Errors are easy to remove, once you get a hands on experience on them.

Try this link below from MSDN, where you can find the description of lots of ICE Errors.

http://msdn.microsoft.com/en-us/library/aa369206(VS.85).aspx

You can directly make changes in the Tables through ORCA and can save the MSI. There is no need to again recompile the WSI then. If you recompile the WSI then you need to recheck the ICE Errors.

Point to note: The removal of ICE error is the best practise in creation of MSI. You should always remove all the ICE Errors from your package.

So all the best for ICE Errors....

Frequently Asked Questions about Windows Installer (MSI) Packaging.

These are the most Frequestly asked queries, which I have compiled from lots of places and have put together.

I have added more questions in other post which can be accessed by below link.

http://msiworld.blogspot.com/2011/11/frequently-asked-questions-about-com.html

Q. What is Windows Installer?

A. Windows Installer is a system service for installing and managing applications. It provides a standard method for developing, customizing, installing, and updating applications.

Q. What basic functionality is provided by Windows Installer?

A. Windows Installer provides the following basic functions:

• Transactional operations. All installation operations are transactional. For each operation that Windows 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 machine to its original state.
• Self-healing. Windows Installer supports "self-healing" abilities for applications. Applications can detect common installation problems at launch, like missing files or registry keys, and automatically repair themselves.
• Installation on demand. Windows Installer supports on-demand installations of application features. For example, the spelling checker in Microsoft Office Word may not be installed by default, but a user can trigger an on-demand installation of this feature.
• Installation in locked-down environments. In fully locked-down environments, users don't generally have permission or the ability to install applications. In most cases, they don't have write-access to the Program Files folder of their computers or to the HKEY_LOCAL_MACHINE registry location. If an administrator approves an installation package by means of Group Policy, for instance, Windows Installer can perform an installation on the user's behalf.
• State management. Windows Installer provides a set of standard Win32® application programming 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.

Q. What versions of Windows include Windows Installer?

A. Microsoft Windows 2000, Windows Millennium Edition (Windows Me), and Windows XP include Windows Installer. Windows 2000 includes version 1.1 of Windows Installer, Windows Me includes version 1.2, and Windows XP includes version 2.0. Windows 2000 SP3 also contains version 2.0 of Windows Installer.

Q. Why are multiple MSIExec.exe processes running on my machine during an installation?

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.

Q. What is an MST, and why it is used?

A. Whenever there is a vendor supplied MSI, then it is not recommended to do capture the MSI, hence all the changes need to be done in the MSI are done is a Microsoft Transform. Then this MST file is applied on the MSI with the following command line.

MSIEXEC /I {path}\file.msi TRANSFORMS={path}\file.mst /q

Where {path} is the location of the folder where MSI and MST are kept.

Q. 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.

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.

Q. What is the Logical structure of package?

A. A package describes the installation of a full product (Windows Installer does not handle dependencies between products) and is universally identified by a GUID. A product is made up of components, grouped into features.

Components

A component is the minimal part of a product—each component is treated by Windows Installer as a unit: the install developer cannot, for example, use a condition to specify to install just part of a component. Components can contain files, groups of files, directories, COM components, registry keys, shortcuts, and other data. The end user does not directly interact with components.

Components are identified globally by GUIDs, thus the same component can be shared among several features of the same package or multiple packages, ideally through the use of merge modules (although, for this to work correctly, different components should not share any sub-components).

Key paths

A key path is a specific file, registry key, or ODBC data source that the package author specifies as critical for a given component. Because a file is the most common type of key path, the term key file is commonly used. A component can contain at most one key path; if a component has no explicit key path, the component's destination directory is taken to be the key path. When an MSI-based application is launched, Windows Installer checks the existence of these critical files or registry keys (that is, the key paths). If there is a mismatch between the current system state and the value specified in the MSI package (e.g., a key file is missing), then the related feature is re-installed. This process is also known as self-healing or self-repair. No two components should use the same key path.

Features

A feature is a hierarchical group of components—a feature can contain any number of components and other features (a feature contained in another feature is called a "subfeature"). Most installation programs display a "custom setup" dialog box at run time, from which the end user can select which features to install or remove.

The package author defines the product features. A word-processing program, for example, might provide features for the main program executable, the program's help files, and optional spelling checker and stationery modules.

Q. What is Advertisement?

A. Windows Installer can advertise a product rather than actually installing it. The product will appear installed to the user, but it will not actually be installed until it is run for the first time (by means of a Start menu shortcut, by opening a document that the product is configured to handle, or by invoking an advertised COM class).

Q. What is Installation on demand?

A. Similar to advertisement, it consists in the installation of features as soon as the user tries to use them.

Q. How to do Diagnostic Logging?

A. Windows Installer supports detailed logging as a powerful diagnostic tool. Logging can be enabled in the following four ways:

Command-line: If installing an MSI package from the command-line, the /L switch can be used to enable logging. For example, the following command installs Package.msi and outputs verbose logging to c:\Package.log:

msiexec /i Package.msi /l*v c:\package.log

Windows Registry: The following registry value can be used to enable verbose logging:

Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

Value Name: Logging

Type: REG_SZ

Data: voicewarmup

The resulting log is named MSI###.log (where "###" is a unique random identifier) and is placed in the system's Temp directory.

Group Policy: The following Group Policy setting can be used to manage logging on multiple systems:

Computer Configuration -> Administrative Templates -> Windows Components -> Windows Installer -> Logging.

Windows Installer API: If installing an MSI package programmatically, the MsiEnableLog function call can be used to create a log file and determine the logging level for the life of the calling process.

Although verbose logs are very useful for diagnosing Windows Installer problems, they can be very long and difficult to read without practice. A quick way to find the location of a problem in the log is to open it in a text editor (such as Notepad) and search for the phrase "Return Value 3". This entry commonly appears in logs close to the point where a critical error has occurred. The Windows Installer SDK provides a tool called WiLogUtl, which parses and annotates Windows Installer log files.

Q. Why does the package go for Self Healing first time the user launches the Application?

A. If the package is containing some HKCU entries then the package will always go for self healing for the first time. This happens because the HKCU keys are only installed for the current user present while installing the package and not all the users as it is the property of the HKCU. So, if other user logs in then there is a mismatch between the current system state and the value specified in the MSI package (e.g., a key file is missing), then the related feature is re-installed. This is called the Self Healing.

Q. How do detect the MSI version on the computer?

A. 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.