Posts Tagged ‘connection groups’

App-V 5: On the Catalog and Catalog Caching

October 4, 2014 2 comments

The App-V 5 catalog is the client collection of package information and package group (Connection Groups) information organized by GUID containing downloaded package manifests and dynamic configuration. The metadata stored in the catalog governs the overall behavior of the application with regards to virtual operations and operating system integration. The catalogs are divided up by the global machine catalog (packages deployed machine-wide – globally published) and the user catalog (targeted to the user.)

Catalog Locations

The catalog locations are as follows:

Machine Catalog:

  • Packages: %ProgramData%MicrosoftAppVClientCatalogPackages
  • Connection Groups: %ProgramData%MicrosoftAppVClientCatalogPackageGroups

User Catalog:

  • Packages: %AppData%MicrosoftAppVClientCatalogPackages
  • Connection Groups: %AppData%MicrosoftAppVClientCatalogPackageGroups

Unlike options with integration and VFS folders which has both local romaing AppData settings, the Catalog is always set to roam with AppData for user-published packages.

Catalog Components

XML components vary between user and machine catalogs.

Machine Catalog

The default location of the machine catalog is in %ProgramData%MicrosoftAppVClientCatalog. For each package there is a:

  • Manifest.xml – This will be here regardless of publishing target.
  • DeploymentConfiguration.xml – This will also be here regardless of publishing target.
  • UserManifest.xml – This will be present if the package is globally published.
  • UserDeploymentConfiguration.xml – This will also be present if the package is globally published.

For each connection group, there is a:

  • PackageGroupDescriptor.xml – This will be here regardless of connection group target. It is created upon Add/Configure operation. This is a copy of the Connection Group descriptor document. It come either manually or delivered via the management system (App-V publishing server or Configuration Manager.)
  • UserPackageGroupDescriptor.xml – This will be present if the connection group is globally published.

User Catalog

The default location of the user catalog is in %AppData%MicrosoftAppVClientCatalog. For each package, in the user catalog, there is a:

  • UserManifest.xml – Always present and generated from the base manifest within the machine catalog but not identical.
  • DynamicConfiguration.xml – If additional dynamic user configuration has been supplied. If not then there will be a default UserDeploymentConfiguration.xml

For each connection group, there is a:

  • UserPackageGroupDescriptor.xml – A copy of the connection group descriptor document.

One way to tell if the packages and or connection groups have been properly published, will be the presence of the Dynamic Configuration or descriptor documents.

Catalog Operations on Package Add/Configure

When a package is added or Configured, a deployment configuration file and a package manifest are created for each package and package version regardless of how the package will be published. The manifest in the machine catalog is copied out of the immutable package cache location. There will always be a Dynamic Configuration document in the Catalog, even if one is not specified manually (through PowerShell Add-AppVClientPackage) or through the delivery system.

Catalog Operations on Package Publish

The UserManifest.xml, UserDeploymentConfiguration.xml, and UserPackageGroupDescriptor.xml documents are created in the catalog during the publishing operations for packages and connection groups. For all of the documents that are generated by the App-V publishing server, these will have time stamps that correlate to the time stamps on the publishing metadata contained on the server.

Registry Storage

Catalog registrations are stored as follows:

  • Global Packages: HKLMSOFTWAREMicrosoftAppVClientPackage<GUID><GUID>Catalog
  • Global Connection Groups: HKLMSOFTWAREMicrosoftAppVClientPackageGroups<GUID><GUID>Catalog
  • User Packages: HKCUSOFTWAREMicrosoftAppVClientPackageGroups<GUID><GUID>Catalog
  • User Connection Groups: HKCUSOFTWAREMicrosoftAppVClientPackageGroups<GUID><GUID>Catalog

The machine catalog registrations contain the local package store folder and the publishing source. The user catalog only contains the publishing source. All registrations contain policy file timestamp.

Catalog Caching

There are two registry values that govern the behavior of client catalog caching found in HKLMSOFTWAREMicrosoftAppVClientCatalog

  • CacheMachineData: DWORD value defaults to 1 – enabled.
  • CacheUserData: DWORD value defaults to 0 – disabled.

When a value is enabled, the catalog is cached and remains even after the package is unpublished. In the case of machine catalog information, this is the behavior on default. In the case of user catalog data, it is removed when a user-targeted package is unpublished or a user-targeted connection group is disabled. When a package is removed, the machine catalog information is also removed regardless of these settings.

Lingering Catalogs

Lingering Catalogs can prove problematic if they persist past a system reset in those non-persistent environments where the App-V catalog may reside on a persistent disk. You may find errors in the App-V Client service failing to start. The quick solution to this is to either ensure that the catalog root is located on a non-persistent disk, or simply remove the dead catalog upon system reset.

App-V 5: More on Connection Groups

March 12, 2014 3 comments

Update 12/5/2014: There have been significant improvements to the behavior of Connection Groups including mixed targeting, optional membership, and version relaxation. Please refer to this document: after reading this article for the updates.

To continue my obsession with Connection Groups, I wanted to talk about some technical specifics that apply to Connection Groups and will help you determine your Connection Group deployment strategy.

Connection Group Priority

The concept of priority with regards to Connection Groups relate to what will occur when a package published belongs to more than one connection group. Group priority is specified as an attribute (Priority) of the AppConnectionGroup element in the Connection Group descriptor document. When an application is launched from such a package, the application will belong to the virtual environment of the connection group with the lower-numbered priority. It’s like Golf.

In the following example, we have three applications that have been published to a user:

  • Office 2010
  • Adobe Reader
  • Hyperion Add-in

In this same scenario, we also have two connection groups also enabled for that user:

  • Connection Group 1: Office 2010 and Adobe Reader – Enabled with Priority 2
  • Connection Group 2: Office 2010 and Hyperion – Enabled with Priority 1

Here is how the priority will have effect: When Office 2010 is launched, it will launch within the connection group #2


Connection Groups are not transitive

If you have ideas for “SuperBubbles” or AppClouds where default applications are assigned to everyone and these apps have add-ins that are provisioned in a second group. If both CG’s are assigned to a user containing an overlapping application, the CG with the highest priority wins.


Application User State in Connection Groups

If you currently have an application published and you would like to have that application added to a connection group, it is important to understand that package settings and user state will not be migrated to a connection group. Also, when a connection group is disabled, group settings and user state will not be migrated back to the individual package.

For example, let’s say you have published a web browser package (Chrome, Firefox, etc.) The user uses the package and sets their preferences. Then you publish additional add-in packages (Flash, Skype Click-to-call, etc.) If you then create and enable a connection group for that user containing the browser and these plug-in packages, you will notice that when you re-launch the browser, you will be presented with the default settings again. Connection Groups maintain different user states from individually published packages. This works the same in reverse if you remove the Connection Group but keep the packages enabled for that user.

It is recommended to use a user environment management tool (such as UE-V, RES, or AppSense) as a possible alternative for managing user state.

Beware of Disjointed Subsystem Configuration

Disjointed Subsystem Configuration will prevent Connection Groups from getting published properly. Virtual Subsystem settings must match (vCOM vObjects) otherwise, you will see an error. Applications that require conflicting COM settings could potentially be problematic.


Beware of Hard-Coded Paths insides INI files

You have to balance two things concerning App-v and Connection Groups when you encounter applications that rely on text-based configuration (INI files) that contain hard-coded paths:

1.)    App-V 5.0 does not tokenize the paths inside the files. This means that even though a correct path would be placed in the INI file by the application installation when sequencing, the application may not work when the Connection Group is deployed on the client machine.

2.)    Non-tokenized, non-VFS paths beneath the Root folder will not be merged in a connection group.

To resolve this, you will need to ensure that the Sequencer and Client machines for all applications in the connection group:

All 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. This will not work for all paths.

The sequencer and client machine must match bitness otherwise you may get bit with paths that are impacted by bitness. For example, if you sequence an application on a 32-bit machine and it installs to C:Program Files, that will get translated as C:Program Files (x86) if you deploy it on a 64-bit machine.

Installation paths like C:InstallationDirectory will work better (Just make sure it is different from the PVAD.)

Update 12/5/2014: There have been significant improvements to the behavior of Connection Groups including mixed targeting, optional membership, and version relaxation. Please refer to this document: after reading this article for the updates.

Connection Group Case Study: Notepad++

February 22, 2014 Leave a comment

Notepad++ uses plug-ins that register through a configuration file. This is one of the most common methods used by applications. Too often people run into problems because they order the primary application too high in the packages list inside the connection group. As a result, the configurations conflict with the one from the main package were overriding the one from the plug-in package. So to avoid this problem, and to allow more flexibility of deployment and connection group interaction, I will show you how I recommend you sequence these types of applications. I will be using Notepad++ as an example as it can fall into this same problem. My hope is that you can avoid this problem in the future with Notepad++ (and subsequently those applications that load plug-ins in the same style.)

For this example, I will be using Notepad ++ version 6.5.3 downloaded (from Please bear in mind that Notepad updates very frequently although I do not think there will be drastic changes forthcoming in how the application manages its plug-ins. For the plug-ins, I will be using the following examples:

These plug-ins differ as one of them actually requires overlays to the Notepad++ program files.

The Sequencing Process

Notepad++ uses a normal installation procedure. The installation is almost straight forward so the only adjustments I will make are:

1.)    Sequence to a fake PVAD.

2.)    I will then install Notepad to the %PROGRAMFILES% directory to get a tokenized VFS installation (using the VFSProgramFilesx86 directory.

3.)    When I get to the “Components” dialog page, I disable updaters and for demonstration purposes, I do not select any plugins except the plug-in manager as I want to do all of this through connection groups.

4.)    On the next page, I leave everything blank. If you check the box to “Don’t use %APPDATA%” you will run into problems with Notepad as it will try to open immutable assets for modification once virtualized. I will also be converging the main program directories for the plug-ins and I do not want to be loading plug-ins from the %AppData% folder.

5.)    I will then sequence the application as normal opting to provide advanced customization so I can get to the tabbed, advanced package editor. Here, I will verify that the paths in the registry for Notepad are properly tokenized.

6.)    Then I will go to the “Package Files” tab to perform two very important tasks.

7.)    I will be changing the convergence settings for the ProgramFilesx86Notepad++plugins directory from “Override Local Directory” to “Merge with Local Directory.” This will change the color to grey.

8.)    I will then save the package, copy it off, and then revert my sequencing machine. (PLEASE NOTE – I only mentioned particulars here that go outside the norm of sequencing. I am making an assumption that the reader is familiar with the basics of sequencing.)

Sequencing the Plug-in Package

Now that the primary application has been virtualized, I will need to reuse this package on the sequencer when it comes time to virtualize the plugins for Notepad++. I will copy the parent package to the reverted clean sequencer. In the case of these plug-ins – since they are DLL’s I have downloaded and extracted them into a staging directory on the sequencer as well.

Sequence as an Add-In

You will need to use the “Add-in or Plug-in” workflow as it will give you the opportunity to expand the virtualized package (Devirtualize) to the local machine so you can launch the parent application during sequencing to ensure that the plug-ins load and that the configuration will get registered properly and then stored inside the plug-in package.

In this example, I am pointing to my previous package I just sequenced and will be selecting this package as the primary parent application.

I then ensure that I do a custom installation so I can name my plugin package properly AND I will also use a fake PVAD to ensure that everything that gets captured goes to a VFS or tokenized path.

Once all of that is completed, I can proceed to install my plugins while the sequencer is monitoring. When I click the “run” button to proceed with the installation, I choose a command prompt (C:WindowsSystem32cmd.exe.)


Since these plug-ins are DLL’s I use xcopy to copy them over to the C:Program FilesNotepad++ directory.



Since I am still in the monitoring phase, I now want to ensure that the plug-ins get loaded and registered to automatically load through Notepad++’s plug-in manager. From that same command prompt, I launch the NOTEPAD++ application and verify the plug-ins are there from the plug-in manager. I see they are there:


I can now close Notepad, stop the command prompt and stop monitoring by checking that I have finished installing and clicking next. I will then click through and select the customize screens until I get to the final editing tabbed mode. You will notice that this way when you view the advanced editing Files tab the files are already set to merge and they are in the tokenized path. If they are not set to merge, you will want to make that adjustment.

Then save the Plug-in package and move it to a staging area with the parent application. You can now being testing. First add and publish both packages. Target should not matter so long as the connection group you create and enable matches the target of the packages it contains.

Once the packages are published you can create the CG XML document. The order in which you do this does not matter. If you wanted to create the document in advance of publishing, that is fine. I just use the published GUID paths in explorer easier for copying and pasting when I test. But your methods may differ according to your preferences.

In the CG XML document, you will notice that I have my plug-in package at the top of the package order. I then add and enable the connection group.

Once the connection group is enabled, I then launch Notepad++ and navigate to the plug-in manager where I find my plug-ins loaded properly.

More case studies to come.

On the Design of (and Sequencing for) Connection Groups

February 21, 2014 1 comment

Update 12/5/2014: There have been significant improvements to the behavior of Connection Groups including mixed targeting, optional membership, and version relaxation. Please refer to this document: after reading this article for the updates.

I constantly stress to my customers that significant assessment and planning revolving around the design and implementation of connection groups is essential to a successful lifecycle for virtual environments. One of the primary challenges with connection groups is that while understanding the mechanics of setting them up is quite easy; it is the sequencing thereof (as well as the understanding of how applications are affected by them) that is challenging.

I approach connection groups from a packaging and integration perspective. With that approach, I must plan out my strategy PRIOR to sequencing as retrofitting previous sequenced applications for connection groups can be quite risky and I recommend avoiding it.

Connection Group Architecture

I am not going to do too much diving into this point because there is already good information available. But a connection group is a virtual environment that contains more than one virtual package. All of the packages share the same virtual environment where the VFS and tokenized paths merge and the registries are converged. This gives sequencing engineers the flexibility to maintain packages independently and removes the redundancy of adding the same application several times onto a machine. Simple Concept. How about Execution?


The first thing you need to reconcile will be targeting. Connection groups, like packages, can be targeted to users or to machines (globally published.) But targeting cannot overlap. All packages within a connection group must align. If a connection group target is per user, member packages must be published per user. If a connection group target is machine, member packages must be published to the machine.

Test Strategy

A connection group needs to be tested operationally and functionally by incorporating the connection group and package publishing life cycle into your QAUAT application testing. Creating Connection groups in stand-alone mode allows for more seamless testing. It can also be automated using PowerShell. The general flow for this is as follows:

  • Add and Publish packages
  • If possible, test the functionality of the individual applications.
  • Manually create the connection group XML descriptor document (to be used in stand-alone testing to verify functionality independent of delivery system.)
  • Add and Enable connection group
  • Test applications
  • Disable and Remove connection group
  • Unpublish and Remove packages


The Easy Part – the CG Descriptor

Creating connection group descriptor documents is a pretty easy process. All you need to do is supply a unique GUID for the connection groups VersionID and AppConnectionGroupId. The packages PackageId and VersionId fields come from the packages themselves. You then list the individual packages under the <appv:Packages> element in order of convergence priority. When you create connection groups using the management server or through SCCM, you are simply automating this very process. For more detail on this descriptor document and the format, please refer to the following Technet article:

The Hard Part: Actual Sequencing for Connection Groups

The Technet article above also mentions supported scenarios for using connection groups. Connection Groups are great in that they facilitate the use of primary applications virtualized separately from plug-in or add-in applications to be brought together. You can also use connection groups to leverage run-times or middleware without having to package everything together creating a servicing nightmare. The use of converging primary applications with add-ins and plug-ins is one of the most desired use cases of connection groups – HOWEVER, they can be the most difficult to implement if you do not understand how the add-in is loaded and used by the application. This is important information because it will govern how you sequence the application.

Not Every Application Loads an Add-in the same way.

Each type of load method will govern how we sequence. In earlier blog posts, we even learned that Office Add-ins are even registered or loaded differently depending on the addin.

(See the following: )

Most add-ins load because they are registered to load. Some add-ins load because there’s a variable or a search path. In some cases, they load because the add-in simply exists in a special directory. Understanding how the plug-in or add-in loads (and it’s format) will affect how you engineer your connection groups.

File Convergence

Only VFS Folders and tokenized paths merge. Pure and simple. If you suspect you will use an application or a plug-in within a connection group, you will need to sequence your application a specific way when it comes to selecting a PVAD (Primary Virtual Application Directory) and an installation directory. Unlike the former DSC (Dynamic Suite Composition) where the opposite was true, non-VFS folders do NOT merge. You will need 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.  For example, use C:<PACKAGE_NAME> as the PVAD and install to its regular tokenized path (i.e. C:Program Files, etc.) If the application does not normally install to a tokenized path, make sure you install to a different folder then the PVAD.

Registry Behavior across Connection Groups

Registry keys will merge across connection groups however the data and value overlap will be ruled by order within the connection group. To clear up potential issues with conflicts due to registry opacity configuration where key information may not resolve properly, I would consider placing virtualized plug-in/add-in information (where the add-ins were registered) ahead in the list inside the connection group descriptor document to ensure the right configuration wins out. This is especially important not only when it comes to add-ins but when it comes to VFS file convergence where you may have duplicate directories across multiple packages.

In the next few posts, I will discuss case studies on different types of applications.

Update 12/5/2014: There have been significant improvements to the behavior of Connection Groups including mixed targeting, optional membership, and version relaxation. Please refer to this document: after reading this article for the updates.

App-V: On that Failed Office Add-in

July 25, 2013 5 comments

Troubleshooting virtualized Office add-ins are always fun. Correction: troubleshooting Office add-ins are always fun for people like me – not necessarily normal human beings. Whether you are using add-ins with a local instance of Office or are packaging add-ins with virtualized Office, you need to be to understand how Office knows which add-ins to load and how these will be loaded.

There are generally three ways to virtualize add-ins for Office:

1.)    Where Office is installed locally and the Add-in is virtualized – The Office application must have a shortcut/OSD file provisioned in order to be brought into the virtual environment. Starting with App-V 4.6 SP2, the App-V Sequencer has a specific workflow that allows for this.

Be advised that when you do this, you will be bringing in the local instance of Office into the virtual environment in order to load the add-in. What this can lead to is other add-ins which may not be virtualized not loading if the configuration is not set properly for this. Having a clear understanding of your Office add-in ecosystem will help in developing a strategy in advance to avoid this.

2.)    Through Connection Groups or Dynamic Suite Composition (Depending on the Version) –  You can also take advantage of both the Add-in/Plug-in workflow and the “Expand Package to Local Disk” feature of the sequencer in order to package Office and Add-in applications separately but still connect them into a common virtual environment.

This method works best (in my opinion) when your strategy is to virtualize both Office and the add-ins. This is also the only way I use Add-ins with Office 2013.

3.)    Office and add-ins packaged together into one package (often sequenced using a single pass.) This way is the least common and not always recommended as it may require you to deploy multiple Office packages.

Verify the Add-in Registry Keys

When an add-in is installed, it can be registered to either the user or to the whole machine. When an add-in is sequenced, it will also be virtualized and depending on the registry opacity configuration, will override whatever is locally present. User-registered add-ins go to HKEY_CURRENT_USER while add-ins registered to the entire machine go to HKEY_LOCAL_MACHINE. Whether Office is local and being brought into the virtual environment or Office is virtualized with the Add-in, Office needs to be able to understand the “Load Behavior” of the add-in. This will be found under


Each Add-in appears as a subkey beneath this key. The LoadBehavior DWORD value determines how it will load. This key is the #1 culprit when it comes to Add-ins not working right whether it is a “1st launch-only” issue or an “always-launch” issue. It is a DWORD value. By default, this entry is set to 3, which specifies that the add-in is loaded at startup but an many cases, especially if the add-in was launched during sequencing, you may run into a situation where the value may be set to something else depending on what was done during sequencing. If the value is 0, then the add-in will have to be enabled once the user launches the application. If the package is repaired it will have to be enabled again. The value 1 can be misleading and I encounter this a lot in virtual add-in troubleshooting. Add-ins dialog box indicates that the add-in is loaded after the application starts, the add-in isn’t actually loaded. If the application successfully loads the add-in, the LoadBehavior value changes to 0, and remains at 0 after the application closes. The value 2 means If the application successfully loads the add-in, the LoadBehavior value changes to 3, and remains at 3 after the application closes. With App-V this means potential issues in prompts including annoying “success messages.”

LoadBehavior at 3 is good for App-V

Hey, I made a rhyme!  If the LoadBehavior value is set to 3, it will always try to load the add-in and if the add-in fails, will set it back to 2. This is what we want in the virtual registry of our App-V package most of the time. You can usually verify/set this in the Virtual Registry tab after sequencing prior to saving the package.

Should I Verify Registry Opacity?

Yes. While you are there you may want to verify your registry opacity settings. Are those Add-in keys set to “override” or “merge” with the local key. If you have local add-ins that you will use alongside of these virtual add-ins, you will want to ensure that the Addin key is set to merge.

What about Outlook Add-Ins?

For Outlook, you will most assuredly need to manually import/add these virtual registry entries during sequencing (or package upgrade) since you do not want to be launching Outlook during sequencing.

Check the Event Logs when Troubleshooting

While the event logs may not have the event handlers registered for office (since it is virtual, you will still see unregistered event ID’s of Outlook (Event ID 45) which will list all of the add-ins loaded and their subsequent load times.

Event ID: 45

Outlook loaded the following add-in(s)

Office 2013 and Mismatched Virtual Subsystem Settings

If you are using Virtual Office 2013 with App-V 5, this is the #1 issue. Given all of the changes with Office 2013 virtualization, one would think the Add-in story would become complicated. It is not. The recommended practices are pretty straight-forward:

On the Sequencing Machine:

1.)    Install the App-V 5 Sequencer.

2.)    Install Office 2013.

3.)    Start a new package.

4.)    On the “Type of Application” page, select “Add-on or Plug-in.”

5.)    Select the installer for the plugin.

6.)    In the “Install Primary” page, select “I have installed the primary parent program” and continue.

7.)    Install the plugin and save the package.

8.)    Depending on the add-in, you may need to run it during sequencing.


Client Configuration

1.)    Copy your Office 2013 to the client machine

2.)    Copy the sequenced add-in to the client machine

3.)    Modify the add-in’s DeploymentConfig.xml file and modify the following:

4.)    Search for:

“<COM Mode=”Isolated”>”

modify to

“<COM Mode=”Integrated”>”

5.)    Search for:

“<Objects Enabled=”true” />”

modify to

“<Objects Enabled=”false” />”

The Connection Group will fail if the above changes are not made.

6.)    Build a Connection Group document for both Office 2013 and the Add-In. You can do this with stand-alone testing by using the following resource on creating a Connection Group XML document:

7.)    Enable Package Scripts

Set-AppvClientConfiguration -EnablePackageScripts 1

8.)    Add the Office 2013 package; publish it Globally

Add-AppvClientPackage –path <path_to_office_package_>.APPV | Publish-AppvClientPackage –Global

9.)    Add the Add-In package; publish it Global

Add-AppvClientPackage –path <path_to_office_addin>.APPV | Publish-AppvClientPackage –Global

10.) Add the Connection Group pointing to the Connection Group document you created earlier. Enable it Globally

Add-AppvClientConnectionGroup –path <PATH_TO_CG_DOC>.xml |Enable-AppvClientConnectionGroup –Global

 11.) Launch the Office application the add-in uses.