Connection Groups group one or more App-V packages to enable member applications in these packages to interact with one another while maintaining isolation from the rest of the system. This gives sequencing engineers the flexibility to maintain packages independently and removes the redundancy of adding the same application several times onto a machine.
Connection groups can be deployed using the App-V management/publishing servers, or by using the PowerShell Cmdlets on the client machine.
The APP-V Management server’s console provides a user friendly UI for defining Connection Groups.
1. Click “Add Connection Group”
2. Rename the Connection Group appropriately.
3. Add Packages to the Connection Group.
Click on “Edit” for “Connected packages” and add packages needed to the Connection Group.
Note: The order of packages in the connection group is important. This determines the order in which the package contents are merged. So, in the following case, if there was a conflict (example: same registry value), the content of the “App1” package would be used.
4. Entitle the Connection Group.
Click on “Edit” for AD (Active Directory) Access and entitle the group appropriately.
5. Publish the Connection Group.
6. On the client machine, sync to the Publishing Server using the Sync-AppvPublishingServer PowerShell Cmdlet. The Publishing Server takes care of adding and publishing packages before the Connection Group is enabled on the client machine.
Deploying Connection groups on the client machine requires authoring the Connection Group Descriptor document. The path to this document is passed as an argument to the PowerShell Cmdlet for enabling the Connection Group.
Lists Connection Groups
Adds a Connection Group to the machine. Needs admin privileges. Requires the Connection Group Descriptor document as a parameter.
Enables the Connection Group to a user or to the machine. Like the Publish-AppvClientPackage Cmdlet, the Connection Group can be enabled for a user or for the machine.
Disables the Connection Group for the user or from the machine. Reverses the action of Enable-AppvClientConnectionGroup.
Removes a Connection Group to the machine. Needs admin privileges. Reverses the action of Add-AppvClientConnectionGroup
Shuts down the Virtual Environment of the Connection Group. This involves shutting down processes running in the Virtual Environment and freeing up resources being utilized by it.
Removes user settings: Copy-on-write data
A Connection Group Descriptor document is an XML document that specifies Connection group information including the packages in the connection group.
<?xml version="1.0" encoding="Unicode" ?>
<appv:Package DisplayName="Package1" PackageId="adb95ae5-d1d3-4900-96f5-81c1167d1341" VersionId="8b9ae62c-798b-459f-b150-7629fa9d87a8"/>
<appv:Package DisplayName="Package2" PackageId="82a41841-ae79-4cb9-b895-4285159c214c" VersionId="788226fb-f8a6-4773-b492-5f1c964fd716"/>
<appv:Package DisplayName="Package3" PackageId="dcadee8d-bbf0-4f31-98a7-b3fc45464851" VersionId="44e1d5ef-8e7b-4605-8f6d-caad78381f01"/>
- The order of packages that appear in the Connection Group descriptor document is important as it defines the merge order of package contents.
- The Priority attribute of the “AppConnectionGroup” element determines the Virtual Environment in which an application will be launched in if the package containing the application belongs to more than one Connection Group. So if Package1 belonged to Connection Groups: Group1 (Priority Value: 1) and Group2 (Priority Value: 2), an app from Package1 will be launched in the Virtual environment of Group 1.
Before a Connection Group can be enabled for a user or machine, all member packages should be published to the user or machine. It is important to note that the target of Connection Group Enabling should match the target of member package publishing. Therefore, if a Connection Group is to be enabled for a user, all member packages should be published to the user and vice-versa (If the Connection Group is to be enabled for the machine all member packages should be published to the machine).
The Connection Group needs to be disabled before the member packages can be unpublished.
Before a Connection Group is enabled, application launches from member packages will be launched in the Virtual Environment of the member package. Similarly once the Connection Group is disabled, the applications will be launched in the Virtual Environment of the member packages.
* Publish Member packages*
Add-AppvClientConnectionGroup .\MyGroup.xml | Enable-AppvClientConnectionGroup
Disable-AppvClientConnectionGroup -Name MyConnectionGroup | Remove-AppvClientConnectionGroup
User settings from member packages will not be propagated to Connection Groups. Similarly, once the Connection Group is disabled, user settings from the Connection Group will not be propagated to the member packages.
Example: Consider a Connection Group with Firefox, Silverlight and Adobe Flash as member packages. Add/Publish the Firefox package. Start Firefox and set www.bing.com as the homepage. Add/Publish Silverlight and Adobe Flash packages and enable a connection group containing Firefox, Silverlight and Adobe packages. When you start Firefox again, www.bing.com will not be the home page unless it was set during sequencing. Set www.Microsoft.com as the new homepage. After disabling the connection group and re-launching Firefox, the home page will be www.bing.com.
Connection Groups, like packages have versions (specified in the Connection Group Descriptor Document). Upgrading a group involves adding and enabling the new connection group with a new Connection Group Descriptor Document.
Connection Group Upgrades are required when:
- Add/Remove packages in the group.
- Upgrade any package in the group. Each group is specific to package versions. Hence a group becomes unusable if a member package was upgraded. Resolve this by upgrading the group.
- Changing fields such as Priority in the Connection Group.
Yash Harsha Kumar | SDET | Microsoft
Get the latest System Center news on Facebook and Twitter:
App-V Team blog: http://blogs.technet.com/appv/ ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ DPM Team blog: http://blogs.technet.com/dpm/ MED-V Team blog: http://blogs.technet.com/medv/ Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ Operations Manager Team blog: http://blogs.technet.com/momteam/ SCVMM Team blog: http://blogs.technet.com/scvmm Server App-V Team blog: http://blogs.technet.com/b/serverappv Service Manager Team blog: http://blogs.technet.com/b/servicemanager System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials WSUS Support Team blog: http://blogs.technet.com/sus/
The Forefront Server Protection blog: http://blogs.technet.com/b/fss/ The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/ The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/ The Forefront TMG blog: http://blogs.technet.com/b/isablog/ The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
Great stuff here, one note or clarification. Make sure when creating connection group files that the AppConnectionGroupId has a unique GUID for each connection group.
Brilliant article. Plenty of detail. Very helpful.
Why i can find this xml file when ik make a connection group on the management server ?
I learned the hard way that when publishing a connection group (say with 2 member packages) the userconfig.xml seems to be ignored. Basically each member package has a vbs script to run under "userscripts", the script runs every time the packages are published without a connection group but as soon as I want to use a connection group, it's evident that the script is not run (even I would see the black DOS window from the cscript command if it had run) did the exercise several times to be sure. Is that a bug or per design ?.
Not sure what the statement "User settings from member packages will not be propagated to Connection Groups. " means concretely, whether it means exactly what I am describing here or something else.