Different GUIDs present in MSI

ProductCode
PackageCode
ComponentCode
UpgradeCode

Why multiple MSIExec.exe processes run during an installation?

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.

Suppress reboot in WiseScript

Set Variable RESTART to NULL (dont give any value and its considered as NULL)

VBScript to Delete User folders or files on Windows 7

Following script deletes folder by searching each user profile on windows7





Dim FSfolder 
Dim subfolder 
Dim i 


set objshell = CreateObject("Wscript.shell") 
Set FSO = CreateObject("Scripting.FileSystemObject")
Profile = strSysDrive & "C:\Users"
Set FSfolder = FSO.GetFolder(Profile) 'getting the user profile folders




'starting of the loop to delete the HKCUs


For Each subfolder In FSfolder.SubFolders


   If (subfolder.Name <> "All Users" And  subfolder.Name <> "Default User"_
   and subfolder.Name <> "LocalService" and subfolder.Name <> "NetworkService") Then


folder1=Profile & "\" & subfolder.Name & "\AppData\Local\TechSmith\Snagit"




DeleteThisFolder(folder1)




   end if


Next 


'*******************************************************************************************************


Function DeleteThisFolder(FolderName)


    If FSO.FolderExists(FolderName) Then
    objshell.Run "CMD.EXE /C RD /S /Q """ & FolderName & """",0,True 
    End If


End Function

How do disable a feature in MSI

In Feature Table, Goto Level of the particular feature which as to be disabled and  set it to 0

Another way to disable feature is set the feature level to above the value of INSTALLEVEL property value.

If INSTALLLEVEL property value is 100, then feature level has to be any value above 100.

File Versioning Rules

At the core of any installer is the actual installation of files. Determining whether to install a file is a complex process. At the highest level, this determination depends on whether the component to which a file belongs is marked for installation. Once determined that a file should be copied, the process is complicated if another file with the same name exists in the target folder. In such situations, making the determination requires a set of rules involving the following properties:

• Version
• Date
• Language

The installer only uses these rules when trying to install a file to a location that already contains a file with the same name. In this case, the Windows Installer uses the following rules, all other things being equal, to determine whether to install.

Highest Version Wins—All other things being equal, the file with the highest version wins, even if the file on the computer has the highest version.

Versioned Files Win—A versioned file gets installed over a nonversioned file.

Favor Product Language—If the file being installed has a different language than the file on the computer, favor the file with the language that matches the product being installed. Language-neutral files are treated as just another language so the product being installed is favored again.

Mismatched Multiple Languages—After factoring out any common languages between the file being installed and the file on the computer, any remaining languages are favored according to what is needed by the product being installed.

Preserve Superset Languages—Preserve the file that supports multiple languages regardless of whether it is already on the computer or is being installed.

Nonversioned Files are User Data—If the Modified date is later than the Create date for the file on the computer, do not install the file because user customizations would be deleted. If the Modified and Create dates are the same, install the file. If the Create date is later than the Modified date, the file is considered unmodified, install the file.

The installation of a Companion File depends not on its own file versioning information, but on the versioning of its companion parent. In the case of Companion Files, the installation is skipped only if the parent file has a higher version. Note that a file that is the key path for its component must not be a companion file because this results in the versioning logic of the key path file being determined by the companion parent file.

Nonversioned Files Using Companion Files-A nonversioned file that is associated with a versioned file using the companion mechanism abides by the rules for the versioned file. The only exception is if the versioned file on the computer and the versioned file being installed have the same version and language but the companion file is missing on the computer. In this case the companion file being installed is used even though the versioned file on the computer is used. Additionally, a nonversioned file using a companion file is installed if the REINSTALLMODE property includes the overwrite older versions options ("o" or "e") and the companion file's version is equal to a file already on the machine.

Source Resiliency

Applications that rely on network resources for installation-on-demand are susceptible to source failures if the source location should change for any reason or become damaged. The Windows Installer provides source resiliency for features that are installed on-demand by using a source list. The source list contains the locations searched by the installer for installation packages. The entries in this list can be network locations, Uniform Resource Locators (URLs), or compact discs. If one of these sources fails, the installer can quickly and seamlessly try the next.

The application developer does not need to incorporate any special information into the installer package to ensure source resiliency. Once the application is installed, the installer has the behavior of adding the last successfully used source as an entry in the source list. By default, this source is the location from which the installer package is initially installed, and is the same as the SourceDir property.

A system administrator can change the source list by applying a transform or by changing the SOURCELIST property from the command line or in the Property table.