Following on from my post about Connection Groups in App-V 5.0 Full Infrastructure and how far we have come from DSC in App-V 4.x, let’s take a look at Connection Groups cousin in Configuration Manager (CM) 2012 SP1, Virtual Environments!
Virtual Environments in CM 2012 SP1 allows us to take full benefit of the connection group functionality the App-V Client has, letting us share a virtual environment between a set of packages, giving that direct visibility and interaction that is so vital in certain scenarios.
To setup a Virtual Environment all we do is chose to Create Virtual Environment:
We then name our Virtual Environment:
This particular Virtual Environment (VE) will be used for applications that utilise JDK 7 Update 11. Now we need to add deployments, how you handle this all depends on what logic you want to use in in your VE, AND or OR; more on that later.
In this case I’m going to add in Java JDK into its own group.
So now we have Java JDK in:
Now it’s time to add whatever applications are dependent on Java being present:
Here we have another group containing the Java dependants. Notice the resultant logic that has been created:
IF Java JDK AND (Netbeans OR NetBeans Plugin) are published to the user then create a Connection Group for them.
The simple rule that dictates the logic is packages that are in the same group (like NetBeans and NetBeans plugin) will be linked by OR logic and separate groups will be linked via AND logic (Java JDK and Java Dependants).
Now the VE is created, CM will update is policy and then on the next evaluation cycle on the client, we will see the Connection Group get created.
You may have observed the Virtual Environment model in CM 2012 SP1 is much more flexible than Connection Groups in App-V 5.0 Full Infrastructure. This is for two reasons:
- They are not directly linked with the publishing of a package. In Full Infrastructure, Connection Groups are a list of packages that will be published as a connection group. In CM 2012 SP1 App-V packages are delivered independently and then Virtual Environments overlay to specify if certain packages are present we should dynamically create a Connection Group.
- AND/OR logic allows us to be more dynamic in how we specify these relationships. Instead of the static lists we have with Full Infrastructure Connection Groups, Virtual Environments allow us to be much more relaxed in how we create these relationships because the rule based delivery will analyse the currently available applications to assess whether we need the Connection Group or not.
There is one downside to Virtual Environments however which concerns Connection Group Conflicts whereby one application is in multiple connection groups. As you may have noticed above the priority for my connection group is a whopping 4.2 Billion!
This is the default for all CM Virtual Environment delivered Connection Groups which means there is no way to resolve any priority conflicts as we discussed with Full Infrastructure in a previous post. So while Virtual Environments are very flexible, for the time being at least, we need to be careful not to have applications in more than one Virtual Environment delivered to the same user/machine.