Microsoft application virtualization: managing Dynamic Suite Composition

With Dynamic Suite Composition, you get the chance to avoid large-sized packages or redundant sets of components, virtualized separately in different applications. You can virtualize one application normally, like Microsoft Office, and on a different package a Microsoft Offce plugin that will only be streamed down to the clients whenever it is required

Having separate environments not only reduces the chance of getting application components captured more than once in different packages but also gives us control of these dependencies and lets you distribute the applications with more accuracy to users, achieving a one-to-many strategy on applications. For example, having several web applications packages but only one Java Runtime Environment (JRE) used by all these web applications. The dependencies mentioned in DSC are nothing but parameters in the virtual environment of each application.

Manually editing the OSD file represents the main task in DSC preparation, but, of course, the risks increase as editing some of these parameters could end up causing erratic functionality in the App-V packages. Fortunately, Microsoft provides the Dynamic Suite Composition tool with which you can easily establish the necessary communication channels between applications.

How Dynamic Suite Composition works

Dynamic Suite Composition represents the way in which administrators can define dependencies between App-V packages and guarantee final users transparent operability in applications.

In normal use of the operating system, you can find several applications which are dependent on other applications. Probably the best example are web applications interacting, from a browser of course, constantly with Java Runtime Environment, Silverlight, and other applications like a PDF reader. DSC is also suitable in any plugin scenario for other large applications like Microsoft Office.

Dynamic Suite Composition always identifies two types of applications:

• Primary application: This is the main application and is usually the full software product. This should be identified as the application users execute primarily before needing a second application.
• Secondary application: This is usually a plugin attached to the primary application. It can be streamed in the normal way and does not need to be fully cached to run.

An important note is that a primary application can have more than one secondary application but only one level of dependency is supported. You cannot define a secondary package as dependent on another secondary package.

Here is an example from the App-V Sequencing Guide by Microsoft, showing the “many-to-one” and “one-to-many” relationship in Dynamic Suite Composition. These

These application dependencies are customizable in the App-V configuration file for virtual applications, the OSD, where you are going to use the <DEPENDENCIES> tag in the primary application, adding the identifiers of the secondary application(s). So every time the main application needs a secondary application (like a plugin), it can find the right path and execute it without any additional user intervention.

In some environments you can find secondary applications that could be a requirement for normal use of a primary application. With DSC, you can also use the variable MANDATORY=TRUE in the primary application OSD file. This value is added at the end of the secondary application reference.

DSC does not control the interaction

When you discuss implementing Dynamic Suite Composition in your organization you must always remember that DSC does not control the interaction between the two applications, and is only in charge of sharing the virtual environment between the App-V packages.

The SystemGuard, the virtual environment created by each App-V application, is stored in one file, OSGuard.cp (you can find it in the OSD file description using the name SYSGUARDFILE). Once the application is distributed, every change made by the operating system’s client and/or user changes, are stored in Settings.cp.

DSC represents by sharing, between primary and secondary application, the Settings.cp file, while always maintaining the OSGuard.cp. This task will guarantee the interaction between the two applications, but Dynamic Suite Composition does not control how this interaction is occurring and which components are involved.

The reason for this is that when you find yourself in a complex DSC scenario, where you have a primary application with several secondary applications that use the same shared environment as well, some conflicts may appear in the virtual environment; secondary applications overriding DLLs or registry keys, which were already being used by another secondary application in the same environment.

If a conflict occurs, the last application to load wins. So, for example, the user data, which is saved in PKG files, will be kept within the secondary application package.

Dynamic Suite Composition was designed to be used on simple dependencies situations and not when you want full and large software packages interacting as secondary packages. Microsoft Office is a good example of software that must be used as a “primary application” but never as a “secondary application”.

Configuring DSC manually

Now you are going to take a closer look at configuring Dynamic Suite Composition.

When you are working with DSC, using virtual machine snapshots is highly recommended as both applications, the primary and secondary, must be captured separately.

This example will use a familiar environment for most, integrating an Internet browser with another program; Mozilla Firefox 3.6 with Adobe Reader 9.

The scenario is very well known to most users as most find themselves with a PDF file that needs to be opened from within the browser while you are surfing around (or receiving an attachment via web mail). If a PDF reader is not a requirement on the client machines you will be obligated to capture and deliver one to all possible users, even though they only use it when a PDF files appears in their browsing session.

Using Dynamic Suite Composition you can easily configure the browser, Mozilla Firefox, with a secondary application, Adobe Reader, which will only be streamed down to clients if the browser accesses a PDF file.

These are the steps to follow:

1. Log on to the sequencer machine using a clean image, install and capture the primary application.
2. Import the primary application in the App-V Management Server. Set the permissions needed for the selected users.
3. Restore the sequencer operating system to the base clean image.
4. Install the primary application locally again; do not capture this installation.
5. Install and capture the secondary application with App-V Sequencer.
6. Import the secondary application in the App-V Management Server. Set the permissions needed for the selected users.
7. Modify the dependencies on the OSD file from the primary application.

Here is a detailed look at this process.

1. Install and capture the primary application, Mozilla Firefox.This example is using an already captured application; you can review the process of sequencing Mozilla Firefox in the previous chapter. Here’s a quick look at the procedure:
   1. Start the App-V Sequencer Application and begin the capture.
   2. Start the Mozilla Firefox installation (if using Windows 7 you may need to use compatibility mode for the installer).
   3. Select the installation folder in Q: using an 8.3 name in the folder.

      

   4. Complete the installation.
   5. Stop the capturing process and launch the application. It is recommended to remove automatic updates from the Mozilla Firefox options.

      

   6. Complete the package customization and save the App-V project.