Zones

Introduction

Citrix DaaS (formerly Citrix Virtual Apps and Desktops service) deployments that span widely dispersed locations connected by a WAN can face challenges from network latency and reliability. Using zones can help users in remote regions connect to resources without necessarily forcing their connections to traverse large segments of the WAN. In Citrix DaaS environment, each resource location is considered a zone.

Zones can be helpful in deployments of all sizes. You can use zones to keep applications and desktops closer to users, which improves performance. Zones can be used for disaster recovery, geographically distant data centers, branch offices, a cloud, or an availability zone in a cloud.

Throughout this article, the term local refers to the zone being discussed. For example, “A VDA registers with a local Cloud Connector” means that a VDA registers with a Cloud Connector in the zone where the VDA is located.

Differences from zones in on-premises Citrix Virtual Apps and Desktops environments

Zones in Citrix DaaS environment are similar, but not identical to zones in an on-premises Citrix Virtual Apps and Desktops deployment.

• In Citrix DaaS, zones are created automatically when you create a resource location and add a Cloud Connector to it. Unlike an on-premises deployment, Citrix DaaS environment does not classify zones as primary or satellite.
• In XenApp version 6.5 and earlier, zones included data collectors. Citrix DaaS does not use data collectors for zones. Also, failover and preferred zones work differently.

What’s in a zone

A zone is equivalent to a resource location. When you create a resource location and install a Cloud Connector, a zone is automatically created for you. Each zone can have a different set of resources, based on your unique needs and environment.

Each zone must always have at least one Cloud Connector, and preferably two or more, for redundancy.

You can place machine catalogs, hypervisors, host connections, users, and applications in a zone. A zone can also contain Citrix Gateway and StoreFront servers. To use the Local Host Cache feature, a zone must have a StoreFront server.

Zones support workspace and the Citrix Gateway service.

Placing items in a zone affects how Citrix DaaS interacts with them and with other objects related to them.

• When a hypervisor connection is placed in a zone, it is assumed that all the hypervisors managed through that connection also reside in that zone.
• When a machine catalog is placed in a zone, it is assumed that all VDAs in the catalog are in the zone.
• Citrix Gateway instances can be added to zones. When you create a resource location, you are offered the option to add a Citrix Gateway. When a Citrix Gateway is associated with a zone, it is preferred for use when connections to VDAs in that zone are used.
• Ideally, Citrix Gateway in a zone is used for user connections coming into that zone from other zones or external locations. You can also use it for connections within the zone.
• After you create more resource locations and install Cloud Connectors in them (which automatically creates more zones), you can move resources between zones. This flexibility comes with the risk of separating items that work best in close proximity. For example, moving a catalog to a different zone than the connection (host) that creates the machines in the catalog, can affect performance. So, consider potential unintended effects before moving items between zones. Keep a catalog and the host connection it uses in the same zone.

If the connection between a zone and Citrix Cloud fails, the Local Host Cache feature enables a Cloud Connector in the zone to continue brokering connections to VDAs in that zone. (The zone must have StoreFront installed.) For example, this is effective in an office where workers use the local StoreFront site to access their local resources, even if the WAN link connecting their office to the corporate network fails. For more information, see Local Host Cache.

Where VDAs register

VDAs must be minimum version 7.7 to use these zone registration features:

• A VDA in a zone registers with a local Cloud Connector.
  • As long as that Cloud Connector can communicate with Citrix Cloud, normal operations continue.
  • If that Cloud Connector is operational but cannot communicate with Citrix Cloud (and that zone has a local StoreFront), it enters Local Host Cache outage mode.
  • If a Cloud Connector fails, VDAs in that zone attempt to register with other local Cloud Connectors. A VDA in one zone never attempts to register with a Cloud Connector in another zone.
• If you add or remove a Cloud Connector in a zone (using the Citrix Cloud management console), and auto-update is enabled, VDAs in that zone receive updated lists of available local Cloud Connectors, so they know with whom they can register and accept connections from.
• If you move a machine catalog to another zone (using the Full Configuration management interface), the VDAs in that catalog re-register with Cloud Connectors in the zone where you moved the catalog. When you move a catalog, ensure you also move any associated host connection to the same zone.
• During an outage (when Cloud Connectors in a zone cannot communicate with Citrix Cloud), only the resources associated with machines that are registered in that zone are available.

Zone preference

In a multi-zone Site, the zone preference feature offers the administrator more flexibility to control which VDA is used to launch an application or desktop.

How zone preference works

There are three forms of zone preference. You might prefer to use a VDA in a particular zone, based on:

• Where the application’s data is stored. This is referred to as the application home.
• The location of the user’s home data, such as a profile or home share. This is referred to as the user home.
• The user’s current location (where the Citrix Workspace app is running). This is referred to as the user location. User location requires minimum StoreFront 3.7 and Citrix Gateway (formerly NetScaler Gateway) 11.0-65.x.

The following graphic shows an example multi-zone configuration.

In this example, VDAs are spread among three zones, but they are all in the same delivery group. Therefore, Citrix DaaS broker might have a choice which VDA to use for a user launch request. This example illustrates that users can be running their Citrix Workspace app endpoints at different locations. User A is using a device with Citrix Workspace app in zone 1. User B is using a device in zone 2. Similarly, a user’s documents can be stored in different locations. Users A and B use a share located in zone 1. User C uses a share in zone 3. Also, one of the published applications uses a database located in zone 1.

You associate a user or application with a zone by configuring a home zone for the user or application. The broker then uses those associations to help select the zone where a session will be launched, if resources are available. You:

• Configure the home zone for a user by adding a user to a zone.
• Configure the home zone for an application by editing the application’s properties.

A user or an application can have only one home zone at a time. (An exception for users can occur when multiple zone memberships occur because of user group membership. However, even in this case, the broker uses only one home zone.)

Although zone preferences for users and applications can be configured, the broker selects only one preferred zone for a launch. The default priority order for selecting the preferred zone is: application home > user home > user location. When a user launches an application:

• If that application has a configured zone association (an application home), then the preferred zone is the home zone for that application.
• If the application does not have a configured zone association, but the user does (a user home), then the preferred zone is the home zone for that user.
• If neither the application nor the user has a configured zone association, then the preferred zone is the zone where the user is running a Citrix Workspace app instance (the user location). If that zone is not defined, a random VDA and zone selection is used. Load balancing is applied to all VDAs in the preferred zone. If there is no preferred zone, load balancing is applied to all VDAs in the delivery group.

Tailoring zone preference

When you configure (or remove) a home zone for a user or an application, you can also further restrict how zone preference is (or is not) used.

• Mandatory user home zone use: In a delivery group, you can specify “Launch the session in the user’s home zone (if the user has a home zone), with no failover to a different zone if resources are not available in the home zone.” This restriction is helpful if you want to avoid the risk of copying large profiles or data files between zones. In other words, you would rather deny a session launch than launch the session in a different zone.
• Mandatory application home zone use: Similarly, when you configure a home zone for an application, you can specify “launch the application only in that zone, with no failover to a different zone if resources are not available in the application’s home zone.”
• No application home zone, and ignore configured user home zone: If you do not specify a home zone for an application, you can also specify “do not consider any configured user zones when launching that application.” For example, use the user location zone preference if you want users to run a specific application on a VDA close to their machine, even though some users might have a different home zone.

How preferred zones affect session use

When a user launches an application or desktop, the broker prefers using the preferred zone rather than using an existing session.

If the user launching an application or desktop already has a session that is suitable for the resource being launched (for example, can use session sharing for an application, or a session already running the resource being launched), but that session is on a VDA in a zone other than the preferred zone for the user/application, then the system might create a new session. This action satisfies launching in the correct zone (if it has available capacity), ahead of reconnecting to a session in a less-preferred zone for that user’s session requirements.

To prevent an orphan session that can no longer be reached, reconnection is allowed to existing disconnected sessions, even if they are in a non-preferred zone.

The order of desirability for sessions to satisfy a launch is:

1. Reconnect to an existing session in the preferred zone.
2. Reconnect to an existing disconnected session in a non-preferred zone.
3. Start a new session in the preferred zone.
4. Reconnect to a connected existing session in a non-preferred zone.
5. Start a new session in a non-preferred zone.

Other zone preference considerations

• If you configure a home zone for a user group (such as a security group), that group’s users (through direct or indirect membership) are associated with the specified zone. However, a user can be a member of multiple security groups, and therefore might have a different home zone configured through other group membership. In such cases, determination of that user’s home zone can be ambiguous.

  If a user has a configured home zone that was not acquired through group membership, that zone is used for zone preference. Any zone associations acquired through group membership are ignored.

  If the user has multiple different zone associations acquired solely through group membership, the broker chooses among the zones randomly. After the broker makes this choice, that zone is used for subsequent session launches, until the user’s group membership changes.

• The user location zone preference requires detection of Citrix Workspace app on the endpoint device by the Citrix Gateway through which that device is connecting. The Citrix must be configured to associate ranges of IP addresses with particular zones. Discovered zone identity must be passed through StoreFront to Citrix DaaS.

Although written for on-premises use of zones, the Zone Preference Internals blog post contains relevant technical details.

Permissions to manage zones

A Full Administrator can perform all supported zone management tasks. Moving items between zones does not require zone-related permissions (except zone read permission). However, you must have edit permission for the items you are moving. For example, to move a machine catalog from one zone to another, you must have edit permission for that catalog.

If you use Citrix Provisioning: The current Citrix Provisioning console is not aware of zones, so Citrix recommends using the Manage > Full Configuration interface to create machine catalogs that you want to place in specific zones. After you create the catalog, you can use the Citrix Provisioning console to provision machines in that catalog.

Zone creation

When you create a resource location in Citrix Cloud and then add a Cloud Connector to that resource location, Citrix DaaS automatically creates and names a zone. You can optionally add a description later.

After you create more than one resource location (and the zones are created automatically), you can move resources from one zone to another.

Resource locations and zones are synchronized periodically, typically and approximately every five minutes. So, if you change a resource location’s name in Citrix Cloud, that change is propagated to the associated zone within five minutes.

Add or change a zone description

Although you cannot change a zone’s name, you can add or change its description.

1. From Manage > Full Configuration, select Zones in the left pane.
2. Select a zone in the middle pane and then select Edit Zone in the action bar.
3. Add or change the zone description.
4. Select OK or Apply.

Move resources from one zone to another zone

1. From Manage > Full Configuration, select Zones in the left pane.
2. Select a zone in the middle pane, and then select one or more items.
3. Either drag the items to the destination zone or select Move Items in the action bar, and then specify which zone to move them to. (Although you can select Cloud Connectors, you cannot actually move them to a different zone.)

A confirmation message lists the items you selected and asks if you are sure that you want to move all of them.

Remember: When a machine catalog uses a host connection to a hypervisor or cloud service, ensure that the catalog and the connection are in the same zone. Otherwise, performance can be affected. If you move one, move the other, too.

Zone deletion

You cannot delete a zone. However, you can delete a resource location (after removing its Cloud Connectors). Deleting the resource location automatically deletes the zone.

• If the zone does not contain any items (such as catalogs, connections, applications, or users), the zone is deleted during the next synchronization between zones and resource locations. Synchronization occurs every five minutes.
• If the zone contains items, the zone is automatically deleted after all items are removed.

Add a home zone for a user

Configuring a home zone for a user is also known as adding a user to a zone.

1. From Manage > Full Configuration, select Zones in the left pane.
2. Select a zone in the middle pane and then select Add Users to Zone in the action bar.
3. In the Add Users to Zone dialog box, select Add, and then select the users and user groups to add to the zone. If you specify users who already have a home zone, a message offers two choices: Yes = add only those users you specified who do not have a home zone; No = return to the user selection dialog.
4. Select OK.

For users with a configured home zone, you can require that sessions launch only from their home zone:

1. Create or edit a delivery group.
2. On the Users page, select the Sessions must launch in a user’s home zone, if configured check box.

All sessions launched by a user in that delivery group must launch from machines in that user’s home zone. If a user in the delivery group does not have a configured home zone, this setting has no effect.

Remove a home zone for a user

This procedure is also known as removing a user from a zone.

1. From Manage > Full Configuration, select Zones in the left pane.
2. Select a zone in the middle pane and then select Remove Users from Zone in the action bar.
3. In the Add Users to Zone dialog box, select Remove, and then select the users and groups to remove from the zone. This action removes the users only from the zone. Those users remain in the delivery groups to which they belong.
4. Confirm the removal when prompted.

Manage home zones for applications

Configuring a home zone for an application is also known as adding an application to a zone. By default, in a multi-zone environment, an application does not have a home zone.

An application’s home zone is specified in the application’s properties. You can configure application properties when you add the application to a group or later.

• When creating a delivery group or adding applications to existing groups, select Properties on the Applications page of the wizard.
• To change an application’s properties after the application is added, select Zones in the left pane. Select an application and then select Properties in the action bar.

On the Zones page of the application’s properties/settings:

• If you want the application to have a home zone:
  • Select the Use the selected zone to decide radio button and then select the zone.
  • If you want the application to launch only from the selected zone (and not from any other zone), select the check box under the zone selection.
• If you do not want the application to have a home zone:
  • Select the Do not configure a home zone radio button.
  • If you do not want the broker to consider any configured user zones when launching this application, select the check box under the radio button. In this case, neither application nor user home zones are used to determine where to launch this application.

Other actions that include specifying zones

If you have more than one zone, you can specify a zone when you add a host connection or create a catalog. Zones are listed alphabetically in selection lists. By default, the first alphabetical name is selected.