Udostępnij za pośrednictwem

App-V 5: More on Connection Groups

  • Artykuł

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: https://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_cg_improvements 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: https://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_cg_improvements after reading this article for the updates.

Comments

  • Anonymous
    January 01, 2003
    Correct - All file paths must be VFS - which means they fall under tokenized paths. In essence, the folders are Grey within the sequencer. Your feedback on CG publishing has been received.
  • Anonymous
    March 17, 2014
    Steve,

    Good article, a lot of great information! Can you elaborate a little on 2 under hard coded paths? What it sounds like is if this is your folder structure-

    Package 1
    PVAD (Root)
    subfolder1
    subfolder 2

    That both subfolder1 and subfolder2 will NOT be visible by another package (Package 2) inside the CG? Am I understanding it correctly? This may shed some light on an issue we had, but I want to make sure I understand this properly. I really wish we could just sequence to the VFS, but without unenforced security descriptors we are left with the PVAD.

    One major problem we have had with CGs is due to how long the client takes to publish. It appears that all packages publish first, and then CGs are published last. What this means is that in the 3-4 mins it takes to publish all the apps and the CGs, any user state changes to a package belonging to that CG are lost once the CG is enabled.
    I understand that this is by design, but it would be great if you could publish the group as 1 block, or somehow deny access to the apps until the CG is established.
    We have a few apps in a CG where 1 app needs to run a very small config (think 2 files, or 1 file and 1 registry). What happens is you can't perform this config until publishing is finished and the CG is applied, even if the app you need to configure is available. Its hard to communicate to a user to wait for publishing to complete when the app they need is available and staring them in the face - especially when this can be a few extra minutes.
    Being able to do something like publish a CG as a block of apps, or similar would help a lot.

    One last gripe: management server. Its VERY limiting to not be able to import/export CG XMLs the same way you can the deployment.XML. It makes a gap between testing manually and then providing the working, manually tested code to be published. Since you can't import the CG XML, you are doing it by hand, which is a bad idea. And then once you move from a test environment to a production environment you have to do it again! Stuff like that makes me nervous.
  • Anonymous
    June 30, 2015
    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like