Sequencing for Connection Groups
written by – Naveed Ahmad, Senior SDE
Connection Group is comprised of two or more individual packages. Which means those packages are Sequenced individually, they are edited individually, and they are upgraded individually. This poses a challenge as how to ensure that individually sequenced packages would work together seamlessly when put together in a Connection Group, and when they don’t work seamlessly together how and what to troubleshoot. This blog touches on these challenges and provides a guide to troubleshooting issues that can be taken care of while sequencing these packages.
App-V 5.0 Sequencer is the least intrusive Sequencer of all App-V versions. When an application is installed during sequencing, the Sequencer components passively monitor the installation without any intrusion. So application installation during sequencing is as good as an installation without sequencing. When application is launched on a Sequencer machine it works and behaves the same as installed and launched on a machine without the Sequencer. So if the app works fine after installation on the Sequencer machine, it should work the same when launched on the App-V Client in the virtual environment. However if the app doesn’t work as expected on the Sequencer machine, the issue is likely with the app or the installer or the app configuration.
While WYSIWYG provides a great ease in troubleshooting applications for individual packages on the Sequencer machine, WYSIWYG is not so true for Connection Groups.
The key for understanding this statement is to understand how Connection Groups work on the client.. The client makes the virtual assets of individual packages in a Connection Group available to each other by merging them together. This way files and registry entries from one package are visible to the apps in the other package. The client, however, doesn’t do the same for the root folders of the packages in the Connection Group. Only the VFS folders are merged.
This limitation may cause issues for certain applications to work seamlessly in a Connection Group. How it may affect the Connection Group entirely depends on the internal working of the application.
The nature of Connection Groups in App-V and how App-V works overall poses some issues while grouping applications in a Connection Group. In the following, we discuss those issues and suggest workarounds that may solve the issues.
The packages being combined in a connection groups may have files with the same file paths but different contents. They may also have registry key and values with the same names but different contents. While only one item among the conflicting items prevails, you may find that you wanted the item from the other package to prevail.
4.1.1 Workaround: Change the order of Packages in the Connection Group
The file/registry item from the Package listed higher in the Connection Group prevails among the Packages with the conflicting items. Changing the order of the packages would work as long as you don’t want one item from one package and another item from another package to prevail in the Connection Group.
4.1.2 Workaround: Dummy Package with the prevailing items put at the top position
If the required file/registry item cannot be preserved by mutually changing the order of the Packages in the Connection Groups, you can create a dummy package with just the required file/registry items in it, and put this package at the top location in the Connection Group. Such a dummy package can be created by performing a custom installation as show in Figure 4‑1, and then either creating the required registry entry and copying the required file at the intended path manually while in the Monitoring phase of sequencing, or adding them to the package later through “Virtual Registry” and “Package Files” tabs using the package editor option as shown in Figure 4‑2.
4.2 Problem: Failure to Load Add-Ins because of Root Folder Dependency
Say, you are sequencing an application and its plug-ins in individual packages to be grouped as a Connection Group. While sequencing, say the plug-in installer installs the plugins to the same root folder as the primary application. The apps and the plugins will work fine on the Sequencer machine, but when published to the client in a Connection Group, since the root folders of the two individual packages are not merged in the Virtual Environment, the app may not find the plugins if its internal working depends on looking up the add-ins in the same folder as the app itself, or if the app depends on a relative path from the same folder as the app itself. This demonstrates that WYSIWYG is not a valid statement for Connection Groups.
One solution for such case would be to fully VFS the packages, that is, provide incorrect ‘Primary Virtual Application Path’ (PVAD) while sequencing the packages. This puts all the files of the package under VFS folder and nothing ends up in the root folder. Since VFS folders are merged in the Connection Group, the app would avoid the above mentioned problem.
Some applications may depend on a path in some INI file to know about an add-in or middleware configuration. When add-in or middleware is sequenced in a separate package, the INI file that goes with the primary application package may not have the required info. Even if INI file is updated, some apps may require the full path of the add-in. Though a correct path would be placed in the INI file by the app/add-in installer for the Sequencer machine environment and things would work fine on the Sequencer machine, App-V 5.0 does not tokenize the paths inside the files to decouple the path/configuration from Sequencer machine environment. Hence the app may not work when the Connection Group is deployed on the client machine. Manually tokenizing the paths in the INI file will not help because App-V 5.0 does not have a component supporting INI file virtualization hooking INI file APIs and auto expanding the tokens to the correct paths when configuration is read from the INI file through INI file APIs.
Sequencing the app + add-in/middleware together in a single package is a brute force solution that may work for some apps, albeit losing the benefits of Connection Groups. This would solve the problem where add-ins or middleware installation is updating the INI file that goes with the primary application. Having everything in a single package would ensure that the application gets the updated INI file with all the info about add-ins/middleware.
The lack of INI virtualization subsystem in App-V can be compensated by ensuring that Sequencer and Client machines have the same configuration with matching drive letters. This bypasses the need for tokens whose sole purpose is to accommodate the differences in Sequencer and Client environments.
Note that this will not take care of the user specific paths which contain user login id, like:
Paths which are impacted by OS bit-ness are also not going to work, unless if the OS bit-ness is the same for Sequencer and Client. For example:
C:\Program Fiiles\AppInstallFolder vs. C:\Program Files (x86)\AppInstallFolder
Paths like C:\AppInstallationFolder are more likely to be resolved by this workaround.
Identifying why applications in individual packages don’t work when combined in a Connection Group often requires understanding how these applications work internally. This may be an easy to know for the devs who developed these applications, but it is certainly not easy for App-V Support and Sustained Engineering teams who do not know the internal working of the application.
App-V Engineering team has used Process Explorer from Sysinternals for troubleshooting Connection Groups issues. We usually compare Process Explorer trace from a native installation (installation on Sequencer machine is as native as any other machine) where the apps are working correctly, to the Process Explorer trace on the Client machine where the apps don’t work correctly inside the Connection Group.
Note that file/registry I/O operation from the app in the virtual environment will result in multiple calls with the altered paths as virtual file/registry subsystems divert the call to the altered path.
Many applications load the add-ins at the start up, but some may load the add-in on some user action. Process Explorer traces are huge and should be captured when you think the app is loading the add-ins.
Once the traces are captured, try to identify where the two traces (successful and un-successful) deviate from each other, taking into account the I/O call from the app in the Virtual Environment translating to multiple calls with altered paths by virtual subsystems. We acknowledge that this is not a trivial task, but this is what has helped us troubleshooting some Connection Group issues.
Tags: App-V 5.0