What are MergeModules

Merge modules provide a standard method by which developers deliver shared Microsoft® Windows® Installer components and setup logic to their applications. Merge modules are used to deliver shared code, files, resources, Registry entries, and setup logic to applications as a single compound file. Developers authoring new merge modules, or using existing merge modules, should follow the standard outlined in this section.


A merge module is similar in structure to a simplified Windows Installer .msi file. However, a merge module cannot be installed alone, it must be merged into an installation package using a merge tool. Developers wanting to use merge modules must obtain one of the freely distributed merge tools, such as Mergemod.dll, or purchase a merge tool from an independent software vendor. Developers can create new merge modules by using many of the same software tools used to create a Windows Installer installation package, such as the database table editor Orca provided with the Windows Installer SDK.


When a merge module is merged into the .msi file of an application, all the information and resources required to install the components delivered by the merge module are incorporated into the application's .msi file. The merge module is then no longer required to install these components and the merge module does not need to be accessible to a user. Because all the information needed to install the components is delivered as a single file, the use of merge modules can eliminate many instances of version conflicts, missing Registry entries, and improperly installed files.

Advantages of MSI Packaging

Following are the advantages over legacy setup


Transaction based operation: 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.





Managed Application: 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.

ActiveSetup Implementation

If you are using Windows Installer for per-machine-based installations, it could be the case that your setup contains components with user-related resources that have no entry-points to initiate the install-on-demand/self healing function of MSI. This, of course, will mean that when deployed the package will not install the user resources required to run the application properly.


But wait, don’t lose hope! In such a case you can use the Active Setup for a self healing on demand. It needs just one registry key in your msi file.







This registry key can be assigned to any Component that installs per-machine resources or you can create one component just for this key.


How it works:
The value in the StubPath key will be executed at a special time during which the Active Setup tasks are running and no other Windows Installer processes are running in the background that could cause the repair not to run (which would be the case if you attempted to run this command in the Run-Once registry key).
The command will thereby perform a repair for HKCU registry keys and missing files.


If this command runs successfully, it will create a registry key in HKCU and the command will not run again. However, if you wish to trigger this command again, because of a small update, then use the Version Key and increment its value each time you wish to run this command again when a user logs in.


Important Note:
Remember to use this command only if your setup does not contain any entry-point that would not allow the repair on demand, because this repair will run when a user on the target workstation logs in after the installation has been run. That means, even if the user doesn’t use the installed application, it will run the repair. And as you may already know, those repairs can take some time depending on the workstation’s hardware configuration and the size of the package.

SetACL Permissions Examples

Using SetACL to provide permissions

Command1: Providing registry permissions to Authenticated Users group


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

Why multiple MSIExec.exe processes running on machine during aninstallation

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.

Difference Between Execute Immediate and Execute Deferred

• Deferred custom actions can only be sequenced between the InstallInitialize and InstallFinalize actions in execute sequence tables. Immediate custom actions, on the other hand, can be sequenced anywhere within any of the sequence tables.

• Deferred custom actions cannot access the installation database. In fact, deferred custom actions have very limited access to the installation session because an installation script can be executed outside of the installation session that created it. Immediate custom actions have access to the installation database and can read and set installation properties, modify feature and component states, and add temporary columns, rows, and tables among other things.

• While both deferred and immediate custom actions can run in the context of the user initiating the installation, only deferred custom actions can run elevated using the system context.

• Deferred custom actions are not executed immediately. Instead they are scheduled to run later during the execution script. The execution script isn't processed until the InstallExecute, InstallExecuteAgain, or InstallFinalize action is run.

SCCM 2007 Ceritification Dumps

Please visit following link to get latest dumps on SCCM 2007 Certification 70-401

http://www.examcollection.com/70-401.html