MSI Validation - Feature and Component ICEs

ICE02 checks to make sure that you’ve got the relations right between the Component, File, and Registry tables for KeyPath columns. You’ll recall that the KeyPath column in the Component table points to either an entry in the File table or an entry in the Registry table. The corresponding entry in those tables must point back to the same record in the Component table that points to it. ICE02 verifies that this circular relationship has been properly set up.


ICE08 makes sure that there are no duplicate GUIDs in the Component table.


ICE09 checks that any component being installed into the SystemFolder folder
has its permanent bit set. It’s a violation of the Installer guidelines to install nonpermanent components to this folder.


ICE10 looks at feature hierarchies and advertisement. If a parent feature is set to favor advertisement, all of its child features must be set to favor advertisement as well. If a parent feature is set to disallow advertisement, then all of its child features must be set to disallow advertisement.


ICE14 makes two checks in the Feature table. First, it verifies that the root feature is not set to “follow parent” status, because it has no parent. Second, it makes sure that no feature is its own parent.


ICE18 verifies that any empty directories used as the KeyPath column for a component are listed in the CreateFolder table.


ICE19 checks that advertised components use a file as their key path, rather than a folder or a Registry key.

ICE21 uses the FeatureComponent table to verify that every component in the
Component table is assigned to at least one feature.


ICE22 validates that the FeatureComponent and PublishComponent tables do
not conflict. The FeatureComponent table assigns components to features, and the PublishComponent does the same. The two assignments must be the same in all cases.


ICE35 checks components that are stored in compressed fashion in CAB files. In particular, it makes sure that these components are not set to run from source.


ICE38 checks components that are installed to a particular user’s profile (for
example, to the predefined StartMenuFolder or DesktopFolder). Such components must use a Registry key as their key path, and this Registry key must be located in the HKEY_CURRENT_USER Registry hive.


ICE47 looks at the Feature and FeatureComponents tables to locate features that refer to more than 800 components. Such features will cause trouble on Windows 9x systems. It also checks that no feature has more than 1600 components, which is the absolute limit on Windows NT and Windows 2000 systems.


ICE54 looks for components whose key path files are companion files (that is,
whose key path files reference another file for version information). Key path files must have explicit version information in the File table.


ICE57 makes sure that components do not mix per-machine and per-user data.
It checks the Component, File, Registry, and Directory tables. For example, a component that installs files to the DesktopFolder and Registry keys to the
HKEY_LOCAL_MACHINE hive would fail this ICE.

MSI Validation - Base ICEs

ICE01 tests to make sure the ICE mechanism is functioning. All it does is return the time that it was invoked. ICE01 should never fail. If it does, something is wrong with the Installer Service on the computer where you’re running validation.

ICE03 check the basic items that internal validation should check during editing. It can detect a variety of conditions, including the following: 

• • Duplicate primary keys
• • Nulls in Non-nullable columns
• • Foreign keys that reference nonexistent rows
• • Values outside of acceptable ranges
• • Invalid GUIDs
• • Improperly formatted Condition columns
• • Mistakes in the _Validation table itself

ICE06 performs a sanity check on the .cub file itself. It checks to make sure that the database being validated contains every column that is being checked by any of the ICEs. If this ICE fails, it most likely means that you’re using a new version .cub file with an older version of the Installer database.

ICE32 looks at Foreign Key columns and makes sure that they are the same size and data type as the Primary Key columns that they’re referencing. As long as you’re only using the standard tables in your Installer database this ICE should never fail.

MSi Sequence Column Values of Sequence Tables

Values for the Sequence Column of InstallUISequence, InstallExecuteSequence Tables

• Positive number  Run the action in this sequence.
• Zero Don’t run this action.
• Null Don’t run this action.
• -1 Run this action when an installation is successfully completed.
• -2 Run this action when the user cancels during an installation.
• -3 Run this action in case of a fatal error.
• -4 Run this action when the installation is suspended.
• Other negative numbers Don’t run this action.

Transitive components - MSI

Transitive components are regular components that are arranged in mutually-exclusive groups. The simplest example of a transitive component is a library that has different versions for Windows 95 and Windows NT. When you install the product, it installs either the Windows 95 or the Windows NT version, depending on the current operating system, but not both.

What are Secure Transforms

Secure transforms are simply transforms that are kept in a place where the user does not have write access. This might be the root of the location where an administrative installation of the package has been performed (Secure-at-Source transforms). It might also be a share or full path elsewhere on the network (Secure-Full-Path transforms).


You can indicate that the Installer should use secure transforms by special
characters in the TRANSFORMS property (discussed in the next section) or by setting the TransformsSecure or TransformsAtSource properties within the Installer database to 1.


When the Installer uses a secure transform, it will cache a copy of that transform locally. If the local copy becomes lost or damaged, it will restore it only from the original location.

Check if a Machine is Laptop - VBScript

dim l_objService
dim l_objEnum
dim l_boolIsLaptopNotebookOrTablet : l_boolIsLaptopNotebookOrTablet = false


set l_objService = getObject("winmgmts:root\cimv2")
set l_objEnum = l_objService.ExecQuery("select __relpath, chassisTypes from Win32_SystemEnclosure")


for each l_objChassis in l_objEnum


if IsArray(l_objChassis.ChassisTypes) then
for l_intItem = lbound(l_objChassis.ChassisTypes) to ubound(l_objChassis.ChassisTypes)
l_intType = l_objChassis.ChassisTypes(l_intItem)
if l_intType = 8 or l_intType = 9 or l_intType = 10 then
l_boolIsLaptopNotebookOrTablet = true
msgbox l_boolIsLaptopNotebookOrTablet
end if
next
end if
next


if IsObject(l_objService) then
set l_objService = nothing
end if


if l_boolIsLaptopNotebookOrTablet = true then
wscript.quit 1
else
wscript.quit 0 ' not a computer system that we are concerned about in this package
end if

Append Binary value in Registry - VBScript

const HKEY_LOCAL_MACHINE = &H80000002
strKeyPath = "SOFTWARE\Microsoft\Driver Signing"
strComputer = "."
iValues = Array(&H00,&H00,&H00,&H00)
Set oReg=GetObject( _ 
    "winmgmts:{impersonationLevel=impersonate}!\\" & _
   strComputer & "\root\default:StdRegProv")
oReg.CreateKey HKEY_LOCAL_MACHINE,strKeyPath
strKeyPath = "SOFTWARE\Microsoft\Driver Signing"
BinaryValueName = "Policy"


oReg.SetBinaryValue HKEY_LOCAL_MACHINE,strKeyPath,_
    BinaryValueName,iValues
Set oReg = Nothing