First Time Self Healing

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.

ARP related Properties in MSI

Add/Remove Programs related MSI Properties

Property name	Brief description of property
ARPAUTHORIZEDCDFPREFIX	URL of the update channel for the application. The value the installer writes under the Uninstall Registry Key.
ARPCOMMENTS	Provides Comments for the Add/Remove Programs in the Control Panel. The value the installer writes under the Uninstall Registry Key.
ARPCONTACT	Provides the Contact for Add/Remove Programs in the Control Panel. The value the installer writes under the Uninstall Registry Key.
ARPINSTALLLOCATION	Fully qualified path to the application's primary folder. The value the installer writes under the Uninstall Registry Key.
ARPHELPLINK	Internet address, or URL, for technical support. The value the installer writes under the Uninstall Registry Key.
ARPHELPTELEPHONE	Technical support phone numbers. The value the installer writes under the Uninstall Registry Key.
ARPNOMODIFY	Prevents display of a Change button for the product in Add/Remove Programs in the Control Panel. Note   This only affects the display in the ARP. The Windows Installer is still capable of repairing, installing-on-demand, and uninstalling applications through a command line or the programming interface. Windows NT 4.0 and Windows 98/95:  Clicking on Add/Remove for the product uninstalls the product after prompting the user to confirm the uninstallation.
ARPNOREMOVE	Prevents display of a Remove button for the product in the Add/Remove Programs in the Control Panel. The product can still be removed by selecting the Change button if the installation package has been authored with a user interface that provides product removal as an option. Note   This only affects the display in the ARP. The Windows Installer is still capable of repairing, installing-on-demand, and uninstalling applications through a command line or the programming interface. Windows NT 4.0 and Windows 98/95:   This property prevents display of the application in the Programs List of the Add/Remove Programs in the Control Panel.
ARPNOREPAIR	Disables the Repair button in the Add/Remove Programs in the Control Panel. Note   This only affects the display in the ARP. The Windows Installer is still capable of repairing, installing-on-demand, and uninstalling applications through a command line or the programming interface.
ARPPRODUCTICON	Identifies the icon displayed in Add/Remove Programs. If this property is not defined, Add/Remove Programs specifies the display icon.
ARPREADME	Provides the ReadMe for Add/Remove Programs in Control Panel. The value the installer writes under the Uninstall Registry Key.
ARPSIZE	Estimated size of the application in kilobytes.
ARPSYSTEMCOMPONENT	Prevents display of the application in the Programs List of the Add/Remove Programs in the Control Panel. Note   This only affects the display in the ARP. The Windows Installer is still capable of repairing, installing-on-demand, and uninstalling applications through a command line or the programming interface. Windows NT 4.0 and Windows 98/95:  This property has no effect.
ARPURLINFOABOUT	URL for application's home page. The value the installer writes under the Uninstall Registry Key.
ARPURLUPDATEINFO	URL for application updates information. The value the installer writes under the Uninstall Registry Key.

How to make an MSI unattended by default

By default, when you double-click on an MSI file it prompts you to click Next until you finish installing the application. You can run the MSI unattended from the command line using the /QN switch but that requires typing. What if you need/want to be able to double-click on the MSI file and have it run the MSI unattended? 

Here's how:

-Go to the Setup Editor view:

-Click the Dialogs tab and un-select the following:

-Install Dialogs -> Welcome Dialog Wizard

-Install Dialogs -> Exit Dialog

-Maintenance Dialogs -> Exit Dialog

how to get MSI property value from within a deferred custom action

Background

A Basic MSI installation program does not use an explicit script to drive the installation, but instead uses sequences of actions to determine the dialog boxes and operations the installation program should display and perform. In this sense, MSI actions are analogous to function calls in a typical programming language.

There are two sequences used by a typical installation program: the User Interface sequence and the Execute sequence. The User Interface sequence displays dialog boxes and queries the target system, but does not make any system changes. The Execute sequence performs system changes, but does not display a user interface.

Analogous to variables in a programming language are Windows Installer properties. Windows Installer defines dozens of predefined properties, and an installation author can define custom properties to store any extra data needed at run time. A property can, for example, be set by the user in a dialog box, and then later be written to the registry.

Property names are case sensitive. Two classes of MSI properties are public properties, which have names containing only uppercase letters (examples are USERNAME and INSTALLDIR); and private properties, whose names contain at least one lowercase letter (as in AdminUser and ProgramFilesFolder). The values of public properties can be set at the command line, and their values are preserved when execution switches from the User Interface sequence to the Execute sequence. Private properties, on the other hand, cannot have their values set at the command line, and are reset to their default values when execution switches from the User Interface sequence to the Execute sequence.

During installation, the Execute sequence runs in two stages, immediate mode and deferred mode. Immediate mode walks through the actions in the Execute sequence, generating an internal, hidden installation script; this script contains, for example, instructions for what files, registry data, shortcuts, and so forth, to install. Immediate mode does not touch the target system. Note that the User Interface sequence runs only in immediate mode.

The second stage of the Execute sequence, deferred mode, carries out the system changes described by this internal installation script. (Strictly speaking, deferred mode is performed only for actions between the built-in actions InstallInitialize and InstallFinalize.) During deferred execution, MSI property values are fixed and cannot be changed. Moreover, the values of only a handful of MSI properties can explicitly be read during deferred execution.

Getting Property Values in Custom Actions

When you need to extend the behavior of an installation program, you can write one or more custom actions. MSI supports custom actions that launch executables, set MSI property values, and call various types of DLL and script functions.

During immediate execution, a VBScript custom action can read the value of an MSI property using the Property property of the Session object. For example:

' get a property value during immediate mode
MsgBox "Right now, USERNAME is: " & Session.Property("USERNAME")

Similarly, a C or C++ DLL or an InstallScript custom action can call the MsiGetProperty API function to read the value of a property.

As mentioned above, however, getting the value of an MSI property during deferred execution is somewhat more difficult, as deferred actions have access to only a very few built-in properties: ProductCode, UserSID, and CustomActionData. (Note that this statement is untrue for built-in types of actions that use property values as arguments. For example, a deferred launch-an-EXE action that uses "[INSTALLDIR]Readme.txt" as its argument will have the INSTALLDIR property resolved during immediate mode and fixed during deferred mode. It is only custom actions that explicitly read a property value using Session.Property or MsiGetProperty that need to use the technique described here.)

It is this last property, CustomActionData, that is used to read a property value in a script during deferred mode. For an example, suppose you have a deferred VBScript custom action called "ReadPropDeferred", in which you want to read the value of the USERNAME property. The steps involved in populating this property are the following:

1. Create an immediate-mode set-a-property custom action that sets a property called ReadPropDeferred to the value of the USERNAME property. That is, in the Custom Actions view, create a set-a-property action with property nameReadPropDeferred and value [USERNAME], and schedule the action somewhere before the ReadPropDeferred action. The main idea is that the property name here is the same as your deferred action name.
   
2. In the deferred VBScript code of the ReadPropDeferred action, use Session.Property("CustomActionData") to read the desired value:
   
   ' get property value during deferred mode
   MsgBox "Right now, USERNAME is: " & Session.Property("CustomActionData")

At run time, the immediate action that sets the ReadPropDeferred property populates CustomActionData for that specific deferred action; and the deferred ReadPropDeferred action reads CustomActionData (instead of USERNAME) to determine the desired data. Of course, this same technique can be used with DLL custom actions that use MsiGetProperty to read property values.

As mentioned above, during deferred execution the installation script is fixed, and therefore property values cannot be set from within a deferred custom action.

Disadvantages of PerUser installation

There are several common scenarios that an arise when the choice of “Per-User” versus “Per-Machine” is given to the user:

1. Major Upgrades can Fail
   If you use the Upgrade code feature of Windows Installer to perform a major upgrade the detection of the existing software will fail if: (a) the original software was installed with ALLUSERS=”" and the new software has ALLUSERS=1 in its Property table or passed on the command line or (b) the original software was installed with ALLUSERS=1 and the new software has ALLUSERS=”" or ALLUSERS is not defined in the Property table or on the command line.
2. Uninstall Problems
   If two different users on the system install the software with ALLUSERS=”" they will both have their own shortcuts and Add/Remove Programs entries made (which is fine and is by design). However, if some of the files are installed to a shared location (such as ProgramFilesFolder) and one of the users uninstalls the software, the other user will not be able to use the software even though their shortcuts and Add/Remove Programs entries are still intact. In other words, the two installed instances of the software will not “know” about each other.
3. Support Issues

• Installing to locations the user has the ability to alter might reduce the confidence the package producer has for the integrity of the install. This can affect support costs as well as computational correctness under a regulatory environment (lawyers, accounts, food and drug companies, government agencies, etc)
• Multiple instances of an install means there is duplicate copies of binaries on the machine which wastes disk space. A “Per-Machine” install creates a single copy of common binaries for all users thus saving space.
• Software is less secure because updating behavior has to be done for each user on the machine. In other words, the occasional user on the machine can made the machine vulnerable because they are not on the machine often enough to keep the software they use up to date.
• IT departments want programs in locations users can’t tamper with. User tampering is a major source of support costs.
• Centralized install, servicing, and uninstall from a central IT department are all more challenging when the apps are just in the users profile. There are numerous conditions where it is known not to work at all

PerUser vs PerMachine Installation

There is a MSI property that can be placed within the application package that allows the application setup to announce to Windows Installer that it wants to be installed “Per-User”.

Windows XP

The ALLUSERS MSI property can be set so that the application package will be run in the “Per-User” context. Both by the absence of the ALLUSERS property or the property is present but the value is set to NULL (ALLUSERS=”") will force the installation package to be run in the “Per-User” context.

Vista

On Vista, you could still force the installation package to be run as “Per-User” as we have discussed. Note that the user’s privileges are immaterial when running in the “Per-User” context – but once the decision is made that the install will be run in the “Per-User” context (By setting the ALLUSERS=”" or not having the property), the User rights issue makes no difference. But remember, the install starts but it WILL FAILif the user doesn’t have Admin rights and the install tries to write to any machine-wide resources.

If a user has Admin rights, but the install is run in the “Per-User” context, with the Admin rights, any accidental writing to machine-wide resources will be allowed.

Windows 7

On Windows 7, the ability to run as “Per-User” is constrained by the specifics of the package. Essentially these points are important for an application setup to be eligible for a “Per-User” installation context:

• All files are installed to Per-User folders, such as
  • “C:\Documents and Settings\$User\Local Settings\Application Data” on WinXP
  • “C:\Users\$User\AppData\Roaming” on Windows 7
• All Shortcuts and the Add/Remove Control Panel entry are only seen by that user
• All registry entries (Application data and registration) are made to HKEY_CURRENT_USER hive.
• No registry entries are made to machine-wide registry keys, such as HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT hives
• The installation package cannot allow the user performing the installation package to select destination directories that are machine-wide, such as “c:\Program Files”
• All application binary file (EXE, DLL) need to be digitally signed to be allowed to be installed by “Per-User” for Windows 7.

On Windows 7, if any of the above constraints are not met, the package will be installed “Per-Machine” – this means that a “Per-User” will not be allowed!

Self Healing Explanation

XCACLS Command line syntax

Xcacls.exe syntax


xcacls file name [/T] [/E] [/C] [/G user:perm;spec] [/R user] [/P user:perm;spec [...]] [/D user [...]] [/Y]
where file name indicates the name of the file or folder to which the ACL or access control entry (ACE) is typically applied. All standard wildcard characters can be used.

/T recursively walks through the current folder and all of its subfolders, applying the chosen access rights to the matching files or folders.

/E edits the ACL instead of replacing it. For example, only the administrator will have access to the Test.dat file if you run the XCACLS test.dat /G Administrator:F command. All ACEs applied earlier are lost.

/C causes Xcacls.exe to continue if an "access denied" error message occurs. If /C is not specified, Xcacls.exe stops on this error.

/G user:perm;spec grants a user access to the matching file or folder.
·       The perm (permission) variable applies the specified access right to files and represents the special file-access-right mask for folders. The perm variable accepts the following values:
o       R Read
o       C Change (write)
o       F Full Control
o       P Change Permissions (special access)
o       O Take Ownership (special access)
o       X EXecute (special access)
o       E REad (Special access)
o       W Write (Special access)
o       D Delete (Special access)
·       The spec (special access) variable applies only to folders and accepts the same values as perm, with the addition of the following special value:
o       T Not Specified. Sets an ACE for the directory itself without specifying an ACE that is applied to new files created in that directory. At least one access right has to follow. Entries between a semicolon (;) and T are ignored.

Notes
§       The access options for files (for folders, special file and folder access) are identical. For detailed explanations of these options, see the Windows 2000 operating system documentation.
§       All other options, which can also be set in Windows Explorer, are subsets of all possible combinations of the basic access rights. Because of this, there are no special options for folder access rights, such as LIST or READ.

/R user revokes all access rights for the specified user.

/P user:perm;spec replaces access rights for user. The rules for specifying perm and spec are the same as for the /G option. See the "Xcacls.exe examples" section.

/D user denies user access to the file or directory.

/Y disables confirmation when replacing user access rights. By default, CACLS asks for confirmation. Because of this feature, when CACLS is used in a batch routine, the routine stops responding until the right answer is entered. The /Y option was introduced to avoid this confirmation, so that Xcacls.exe can be used in batch mode.

Setup.exe Silent Switches

Perhaps there is some undocumented process you can uncover. Below are some command lines found to work, try "setup.exe /?" first then go through the list below- you may get lucky!

• setup.exe /q
• setup.exe /qn
• setup.exe /silent
• setup.exe /s
• setup.exe /NoUserInput
• setup.exe /unattended
• setup.exe /CreateAnswerFile
• setup.exe /quiet
• setup.exe /passive
• setup.exe /NoUI
• setup.exe -s
• setup.exe -silent
• setup.exe /VerySilent
• setup.exe -r      (Creates response file in Windows directory with name setup.iss)

App-V Client Offline Mode Settings

Following registries needs to be changed on App-V Client systems to run AppV client in Standalone/Offline modde

On 32bit machines the registry path is HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Client


On 64bit machines the registry parth is
HKLM\SOFTWARE\Wow3264Node\Microsoft\SoftGrid\4.5\Client


The settings required are:


HKLM\...\Configuration AllowIndependentFileStreaming 1
HKLM\...\Configuration RequireAuthorizationIfCached 0
HKLM\...\Network AllowDisconnectedOperation         1
HKLM\...\Network LimitedDisconnectedOperation 0

Custom Action Conditions in MSI

You can execute a custom action or make the component install using conditions as per the requirement.

1. Condition for Action to run only during Installation
   Condition: NOT Installed
2. Condition for Action to run only during Uninstallation/Removal of MSI
   Condition: REMOVE="ALL"
3. Condition for Action to run during Install and repair
   Condition: NOT REMOVE
4. Condition for Action to run only during Upgrade

       Condition: NOT UPGRADINGPRODUCTCODE

Append Entries to Hosts file

Following script can be used to append entries in HOSTS file.

A text file containing the entry to be appended should be placed in INPUT location as in below script

Const ForReading = 1, ForWriting = 2, ForAppending = 8
Dim TargetFile,objWshShell,objFSO, Input, ProgramFiles, WinDir
Dim objTextFile, Target

Set objWshShell = CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")

ProgramFiles = ObjWshShell.ExpandEnvironmentStrings("%ProgramFiles%")
WinDir = ObjWshShell.ExpandEnvironmentStrings("%WinDir%")

Set Targetfile = objFSO.GetFile(WinDir & "\system32\drivers\etc\hosts")
Set Input = objFSO.GetFile(ProgramFiles & "\Input.txt")

Set objTextFile = objFSO.OpenTextFile (Input, ForReading)
Set Target = CreateObject("Scripting.FileSystemObject")
Set TargetFile = Target.OpenTextFile (TargetFile, ForAppending, True)

Do Until objTextFile.AtEndOfStream
Input = objTextFile.ReadLine
TargetFile.WriteLine(Input)
Loop

TargetFile.Close
ObjTextFile.Close
objFSO.DeleteFile(ProgramFiles & "\Input.txt")

Set Permissions using SetACL

Using SetACL to provide permissions

Command1: Providing registry permissions to Authenticated Users group

setacl.exe "MACHINE\SOFTWARE\AHouse\GEPUIS ORBIX" /registry /grant "Authenticated Users" /full /i:cont_obj_inh /p:yes /r:cont_obj /silent

OR using S-ID

"MACHINE\SOFTWARE\AHouse\GEPUIS ORBIX" /registry /set "S-1-5-11" /full /sid /silent

Command2: Providing Folder permissions to Authenticated Users group

setacl.exe "c:\AudioTools\GIMP" /dir /set "S-1-5-11" /change /sid /silent

Change the group name / S-ID according to your requirement

Resolve ICE38 Error

ERROR: Component DesktopFolder installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file.

Solution: In the Components Tab, find the CurrentUser component, which holds all the user's information. Pick one of the registry keys (except the one set as a keypath), right click on it and select the option 'Move'. Move that key to the component referred on the ICE error message. Go to that component, open it and find the 'new key'. Right click on the entry and select 'Set as Key' option.

Create Minor Upgrade MSI

Steps to create Minor Upgrade:

1. Change the Package code and Product Version to create a minor upgrade
2. Add feature / component by following the guide lines in Section: Requirement for Minor upgrade
3. Add Remove or Modify files, registry keys and shortcuts.
4. Add minor upgrade item in upgrades view (this is optional).
5. Build and use the installer for upgrade.

Resolve ICE18 Error

Error: KeyPath for Component “…” is Directory “…”. The Directory is not listed in the CreateFolders table

Solution: Create a new row in the table “CreateFolder”, select the mentioned Directory and the mentioned Component.

Resolve ICE43 Error

Error: Component “…” has non-advertised shortcuts. It Should use a registry key under HKCU as its KeyPath, not a file.

Solution: Put one Current_User registry key under the mentioned component and set that registry key as the keypath

Resolve ICE57 Errors

Error: Component has both per user and per machine data with a per machine keypath

Solution: Create a new component (with a new GUID), move all of the per user data from the component that kicks up the error to the new one. Set one of the files/reg keys as it’s keypath.

MsiLockPermissionsEx Table

MsiLockPermissionsEx Table enhances the functionality over LockPermissions Table. With MsiLockPermissionsEx table, users now have the ability to set access permissions on objects impacted by the application install that previously required using custom actions or other methods outside of Windows Installer

·Expanding the set of permissions that can be applied to a resource by incorporating the Security Descriptor Definition Language(SDDL) in Windows Installer. This allows the security settings for an object to be more flexible, including;

o Ability to apply Deny ACLs to objects

o Indicate inheritance properties for permissions

o Expand the set of well-known SIDs

o Ability to set Owner, Group, and SACLs to the objects in addition to the regular access permissions

·Security settings can be applied to services as well in addition to Files, Folders, Registry keys

·Ability to apply permissions specific to user accounts – including accounts that are newly created on the system during the course of installation
Read more about this in Windows installer team blog

http://blogs.msdn.com/windows_installer_team/archive/2009/03/05/enhanced-permissions-setting-with-windows-installer-5-0.aspx

Shared DLLS vs Merge Modules

Merge modules are similar in structure to a simplified Windows Installer, which helps to integrate shared code, files (DLLs / OCXs), resources, registry entries, and setup logic to applications as a single compound file.

Drawback of using downloadable Merge Modules while re-packaging: Most of the merge modules are present in their respective shared location, if not; it’s downloaded from the web. As the files integrated with the installer is from merge modules, it does not require isolation.
When you don’t find the proper network for the Share location on web during installation, then the application / installation fails to function. This is the main drawback of the Merge Modules. Shared DLL concept can be used to overcome this issue.
During the re-packaging process usually we don’t include the merge modules, that has to be downloaded during installation, in the WSI/MSI; this is to avoid the above mentioned network issues. The following screen shot shows how the merge modules will be excluded in the package:

In this case the DLL/ OCX files will be included directly within the WSI/ MSI.

Shared DLLs:
All the DLLs captured in the WSI/ MSI will be a shared DLL. When a DLL is already present in the machine and if we install the application, the DLL of the same version increments its DLL counter. Since the DLLs from the MSI are shared DLLs, any new application that would be installed on the same machine in future will increment the corresponding DLL count. All the Shared DLL counts can be viewed from the following registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls When there is a DLL conflict found using Wise Conflict Manager, we go for Isolation. This is named as DLL Redirection.

What is DLL Redirection?Since an executable imports API functions from DLL files, DLL redirection allows us to tell a program that the DLLs it needs are located in a different directory than the originals; in this way we can create a DLL with the same name as the original, which exports the same function names as the original, but each function can contain the code of developer’s choice.

There are two ways to achieve DLL redirection;

1. “dot local” redirection:
   “Applications can depend on a specific version of a shared DLL and start to fail if another application is installed with a newer or older version of the same DLL. There are two ways to ensure that your application uses the correct DLL: DLL redirection and side-by-side components. Developers and administrators should use DLL redirection for existing applications, because it does not require any changes to the application. “
   In other words, dot local DLL redirection affords developers the ability to force an application to use a different version of a particular DLL file than that used by the rest of the system. For example, if an application called oldapp.exe only worked with an outdated version of user32.dll, then instead of replacing the user32.dll file in the system32 directory (potentially causing many other applications to break), you could tell it to load the older version of user32.dll from the program's current directory by creating an appropriate dot local file. All other applications will still load the newer DLL from system32 and remain unaffected. All that is needed is to create a dot local file (which is simply an empty file whose name contains the name of the target application followed by a .local extension; in this case it would be oldapp.exe.local), and place it and the older version of user32.dll in the same directory as oldapp.exe.
   Limitations with “dot local” redirection:
   Most notably, according to MSDN, certain DLL files (called 'Known DLLs') cannot be redirected in Windows XP (this restriction does not apply to Windows 2000). A list of all Known DLLs can be found in the
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs key; included in the list of known DLLs are kernel32.dll, user32.dll and gdi32.dll. However, this is not true - it seems that under Windows XP, an application will either allow you to redirect any DLL, or none at all. As such, if targeting a program running on the Windows XP platform, dot local redirection is an unreliable method, and should be used only on Windows 2000 machines.
2. Using Manifest Files:Manifest files use the same naming convention as dot local files (i.e., oldapp.exe.manifest), but are not empty files. They must contain certain XML-formatted information in order to function properly, or else the target application will fail to load. In addition, manifest files are only supported on Windows XP and Vista; however, they are far more reliable than using dot local redirection, and allow us to redirect any DLL file. (NOTE: The testing was done under Windows XP only; it is possible that some restrictions/changes may be applied to Windows Vista).