Today, we’ll explore the access control mechanism in Isolation Groups that allows Isolation groups to be either partially realized for some users while fully realized for others.
Packages can be added to an Isolation Group as either Explicit or Automatic (see Part 1)
Explicit packages provide a means of controlling access to App-V packages in Isolation Groups and, indeed, the effectiveness on the VDA of the Isolation Group itself. If the launching application’s delivery group doesn’t have a required explicit package published, the isolation group will not contain it. Other delivery groups that meet all the packages’ criteria will have those packages isolation groups. This becomes an effective way to manage Isolation Group access control.
A good example of setting a package to “explicit” is when it’s licensable or restricted to certain users (or a delivery group), meaning you want it only up for inclusion in an isolation group if it’s been given access to the launching user (i.e. it’s been published to that user).
Users that don’t have this package published (in the delivery group) to them will not have the package in the isolation group. Any other package in that Isolation group—to which the user’s delivery group has access or that is automatic—will be included in the isolation group.
This way, some delivery groups may have a partial isolation group (i.e. having only a few packages within it, say without the licensable packages, while another’s who has access to explicitly defined packages will have a fuller isolation group). Either way, an isolation group is created on the VDA – it just depends how much access that VDA’s delivery group has that will determine what’s in that Isolation group.
As explained earlier, this mechanism also extends to the fact that every isolation group policy that is created as a result of creating an isolation group in Citrix Desktop Studio, is pushed down to all VDAs.
Figure 4: AppV subsystem on the VDA
Here—pictorially—is a how an isolation group’s effectiveness is determined by examining the delivery groups published applications.
Figure 5: Explicit/Automatic package Isolation Group Access Control
In orange, these represent separate App-V packages. Most have a dependency on Java (another package) and one that needs to collaborate with a plugin (Free plane Plugin). These are candidates for inclusion in an isolation group.
Blue represents two separate delivery groups, each with associated users and published (explicit) applications.
An isolation group definition will be created globally in Citrix Desktop Studio, along with its package requirements (Explicit/Automatic) and only those delivery groups (and thus machine catalogues/VDAs associated) that meet the isolation group’s package requirements will have those packages in the isolation group.
You can see which packages make it into the isolation group, by virtue of their delivery group meeting or not meeting the package’s requirements.
From the launching user’s perspective (i.e. from Receiver or storefront), they aren’t aware that Isolation groups are in place or have been defined. It’s only the underlying launching application which may or may not be affected by any defined isolation groups (e.g. it may have a plugin loaded now or can now open a file type associated with another application defined in the same isolation group as the launching application). In both cases above, the resulting application has java made available to it automatically and thus it can launch successfully.
Automatic packages do not show up in receiver –they just influence the launching application internally on the VDA.
That’s all for this installment, hope this provides some useful perspective into how Automatic and explicit work and why they were designed the way they were.