Freigeben über

App-V 5: More on Connection Groups

  • Artikel

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