XenApp/XenDesktop 7.11 introduced a new feature called Zone Preference. This allows application or desktop session launch requests to take into account preferences for where the selected VDA should be located geographically. In this article, I’ll add some detail to the already available technical documentation for this feature and describe how the VDA selection works at a low level.
Some Basics
Since XenApp/XenDesktop 7.7, it’s been possible to associate a catalog with a zone where the zone is assumed to represent, for example, a data center or geographical region of significance to your site’s deployment. When a catalog is placed in a zone, so are all the VDAs in that catalog.
VDAs from multiple catalogs can be placed into the same delivery group, and because there’s no restriction that the catalogs’ zones must be the same, a single delivery group can contain VDAs from multiple zones.
The Zone Preference feature adds the following concepts:
- Each application can have an associated ‘home zone’, that is, a preferred zone in which its sessions should be launched. Application home zones can be configured using Citrix Studio, or using the Broker SDK’s New-/Set-BrokerApplication cmdlets.
- Each user can have an associated ‘home zone’ that is a preferred zone in which their sessions should be launched. User home zones can be configured using Citrix Studio, or using the Broker SDK’s New-/Set-BrokerUserZonePreference cmdlets.
- When a desktop or application is launched through StoreFront, the zone that best matches the user’s location can optionally be supplied to the launch process. For this user ‘location’ zone to be available their connection must be through a suitably configured NetScaler gateway.
These types of zone preference have differing uses, for example:
An application home zone might be used for applications that work best when ‘close’ to a required resource (for example, Outlook works best when close to its Exchange database):
A user home zone might be used when the users’ files are present on a file server and their best experience is obtained when their session runs on a VDA ‘close’ to that server:
A user location zone might be used when an application, such as a browser, is published that does not interact with local resources and the best user experience is obtained simply by having the application run ‘close’ to their location:
The zone preference feature only applies to shared desktops or applications, not to private/assigned ones.
We’ll first go through the process used to select a VDA to satisfy a session launch with the basic zone preference defaults, then mention some more advanced options that can be used to fine tune the behaviour.
Basic Session Launch
Selection of Preferred Zone
When a launch request for a desktop or application is received by a DDC it must determine a ‘preferred’ zone to use when finding a VDA to satisfy the request. There are up to three zones that might be available at this point:
- If it’s an application launch then the application may have a home zone.
- The user may have a home zone.
- The launch request itself may include a zone corresponding to the user’s location.
For a given launch request any of these zones (including none or all) may be available.
A preference order is now used to select a single zone from those available. The default order is first application home zone, then user home zone, then user location zone. So, the selection of the preferred zone is:
- For application launches, if the application has a home zone then this is the preferred zone.
- Otherwise, if the user has a home zone then this is the preferred zone.
- Otherwise, if a user location zone is provided then this is the preferred zone.
At this point the DDC has determined a single preferred zone for the launch. If no zones are available then there’s no preferred zone and the launch would continue exactly as it did prior to the advent of Zone Preference.
It’s important to note that even if multiple zones are available (for example both an application and user home zone) only the selected preferred zone plays a part in the launch, any other zones are now ignored.
Zone Preference Launch Logic
Where a preferred zone exists, the launch logic tries to reconnect/launch a session for the user as follows:
- If there’s an existing session in the preferred zone suitable for re-connection it’s used.
- If there’s a disconnected session in any zone suitable for re-connection it’s used
- If there’s an available VDA in the preferred zone a new session is launched on it.
- If there’s a connected session in any zone suitable for re-connection it’s used (this would typically involve stealing the session and moving to the user’s current endpoint).
- If there’s an available VDA in any zone a new session is launched on it.
The intent is to always prefer reconnecting sessions if possible, and to avoid the possibility of being unable to reconnect to a session previously launched from another zone (this might otherwise become an issue for users who routinely travel between offices in different zones).
Where sessions are considered for re-connection they must also adhere to existing constraints such as roaming restrictions. For example, even if a disconnected session is available in a non-preferred zone in step 2 above, it won’t be used if it has a roaming constraint of SameEndpointOnly (assuming the current launch request is from a different endpoint – which is likely here); in this case the launch logic ignores the session and continues with step 3.
Advanced Options
Preferred Zone Selection Order
Earlier I mentioned there’s a preference order for selecting the preferred zone. This order can actually be changed at a per-delivery group level using the Broker SDK’s New-/Set-BrokerDesktopGroup cmdlets. The order is set using the ZonePreferences property, and defaults to {ApplicationHome, UserHome, UserLocation}.
This order can be altered, for example to prefer the user’s location over their home zone, as in {ApplicationHome, UserLocation, UserHome}. It can also exclude some choices, or even be empty to disable zone preference for that delivery group. For example, a setting of {UserHome} always uses the user’s home zone if available and disregards application home or user location zones even if available.
This preference order cannot be changed using Citrix Studio. You should also note that changing the order may prevent some of the options mentioned later from working.
Application Home Zone Options
In addition to a home zone, an application has two further zone preference options. When set these behave as follows:
- HomeZoneOnly
- If, and only if, the preferred zone for a launch is the application’s home zone, then the launch must be satisfied from that zone (or fail). This amounts to having only steps 1 and 3 in the launch logic sequence described earlier.
- IgnoreUserHomeZone
- If the user has a home zone then it is ignored when selecting the preferred zone for the launch. This can only be specified if the application does not itself have a home zone. It is intended to support the browser use case mentioned earlier when you want the user’s location zone to be used even though they may have a home zone.
- This option only works if the delivery group’s zone preference list has the default order of {ApplicationHome, UserHome, UserLocation}.
User Home Zone Options
In the same way that an Application’s HomeZoneOnly option says that the launch must be satisfied from its home zone, the same can be done for users.
However, in this case the option is set at the delivery group level as part of the zone preference list. In addition to the default options, there’s also UserHomeOnly used instead of UserHome to indicate that if, and only if, the preferred zone for a launch is the user’s home zone, then the launch must be satisfied from that zone (or fail).
Only one of UserHome or UserHomeOnly can appear in the zone preference list for a delivery group.
User Group Home Zones
A user home zone can be set for individual user accounts, or for group accounts (for example DOMAIN\Users). If a user account has a home zone then it is always considered to be their home zone even if one or more groups of which they are a member also have home zones.
Where a user account does not have a home zone but exactly one of the groups of which they are a member does, then that is considered to be their home zone.
However, where they are a member of multiple groups having different home zones, the user’s home zone is taken from one of those groups, but the choice is not deterministic.
Applications Published from Multiple Delivery Groups
An application can be published from multiple delivery groups. Where a preferred zone also exists for a launch of such an application, the same 5 steps are used to find a session/VDA to satisfy the launch as described earlier. However, each step is attempted in each delivery group in turn – according to the group’s priority order, so if an application were published from two delivery groups, the launch logic would start:
1a. If there’s an existing session in the preferred zone in the highest priority group suitable for re-connection it’s used.
1b. If there’s an existing session in the preferred zone in the lower priority group suitable for re-connection it’s used.
2a. If there’s a disconnected session in any zone in the highest priority group suitable for re-connection it’s used.
2b. If there’s a disconnected session in any zone in the lower priority group suitable for re-connection it’s used.
3a. …and so on…
