Pages

Tuesday, 6 September 2011

VFS Sequencing


In VFS sequencing the application and its supporting applications are installed in there default location. VFS sequencing is recommended process for sequencing DSC Sequencing.

Benefits
  • Applications with hard-coded path entries can only be sequenced using this method.
  • This is the best solution for sequencing DSC based applications which copy files in sub-folder of base applications.
Drawbacks
  • Sequenced applications run slightly slower then Q Drive based sequence
  • Some applications might not work properly, especially apps which try to evaluate the launch location at the launch time.

Dynamic Suite Composition (DSC) in App-V

Generally Middleware apps are dependency for most of the apps, so we virtualize both the apps separately and add HREF attributes of dependency appl to main appl.


Process: Sequence this dependency first and revert it to clean machine. Then before starting main applications sequencing, install dependency and start sequencing process. At the end of sequencing, open OSD in notepad, add HREF attributes of middle ware appl to main appl also add one more tag MANDATORY=”TRUE” True – Interacts with middleware appl, False – does not interact with middleware

How to resolve ICE38 Error

ICE38 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 thatcomponent, open it and find the 'new key'. Right click on the entry and select'Set as Key' option.

Windows File Versioning Rules

At the core of any installer is the actual installation of files. But determining whether to install a file is a complex process. At the highest level, making the determination depends on whether the component to which a file belongs is marked for installation. Once the determination is made 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 Microsoft® Windows® Installer uses the following rules 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 machine has the highest version.


Versioned Files Win — All other things being equal, a versioned file gets installed over a non-versioned file.


Favor Product Language — All other things being equal, if the file being installed has a different language than the file on the machine, 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 — All other things being equal, after factoring out any common languages between the file being installed and the file on the machine, any remaining languages are favored according to what is needed by the product being installed.


Preserve Superset Languages — All other things being equal, preserve the file that supports multiple languages regardless of whether it is already on the machine or is being installed.


Non-versioned Files Are User Data — All other things being equal, if the Modified date is later than the Create date for the file on the machine, do not install the file because user customizations would be wiped out. 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.


Non-versioned Files Using Companion — All other things being equal, a non-versioned 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 machine and the versioned file being installed have the same version and language but the companion file is missing on the machine. In this case the companion file being installed is used even though the versioned file on the machine is used.


Rules Are Global — The rules for determining when to install a file reside in one place within the installer and are global, meaning they apply to all files equally.

Windows File Protection

A common problem in the history of the Microsoft Windows operating systems has been the ability for shared system files to be overwritten by non-operating system installation programs. After such changes are made, the user may experience unpredictable system performance, ranging from application errors to operating system crashes. This problem affects several types of files--most commonly dynamic link libraries (.dll) and executable files (.exe).


In Windows 2000 and Windows XP, the Windows File Protection (WFP) feature prevents overwriting or replacement of certain system files. Overwriting shared system files can result in unpredictable system performance that ranges from application errors to operating system crashes. System instability caused by non-standard replacement of system files has been a common problem. By preventing the replacement of these essential system files, file version mismatches are avoided, and the overall stability of the system is improved.

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.