Citrix will shortly be introducing a feature for cloud deployments which causes zones in a XenDesktop site to be automatically synchronized with the Cloud Resource Locations associated with the site.

Zones are used to arrange the site resources (catalogs, hypervisor connections, application and user home zones, etc.) so users connecting to the site from one location get access to ‘local’ applications. Performance is much better when connecting to apps hosted on the same side of the country, or even the same side of the world.

A zone needs at least one Cloud Connector, sometimes called an Edge Server, to communicate between the Citrix managed Controllers (DDCs) in the cloud and the customer managed and owned servers and desktops located on premise or in a private cloud. When multiple Resource Locations and Connectors are involved the site must be configured correctly in order to behave as intended.

Unfortunately, because there has been no restrictions when moving Connectors between zones, we are aware that some sites have Connectors from more than one Resource Location placed together in the same zone. When more than one Connector is present in a zone, any of the Connectors can be used when the DDC needs to perform an operation on a resource or when a session is being launched on a VDA. If the Connectors in the zone belong to different Resource Locations this can result in unpredictable (and unwanted!) behaviour.  A Connector may be used which cannot access the resources in the zone due to firewalls or for example a user in New York launches a session which happens to pick a Connector in Australia to get to an application back in New York – not the most efficient path…

What are we trying to achieve?
A well-configured Cloud managed site should have nothing in the Primary (or Initial) Zone except the Controller(s). All resources should live in secondary zones with one (or more) connectors in each zone, each Connector being associated with the same Resource Location so whichever connector is selected we get the expected behaviour – no launch failures or poor performance due to network traffic being routed round the world.
The diagram below shows a well-configured site – the Primary Zone is empty apart from the DDC, each zone has one or more Connectors from the same Resource Location, shown in this case by the naming convention CC‑<zone#><Connector#>, though in real life more meaningful zone and Connector names may obviously be preferred!

If additional zones are required they would be configured the in same way – “My Zone 3” having one or more Connectors (CC-‑3a, CC‑3b, …) and whatever Catalogs, Hypervisor Connections, etc., are required in the zone.
 

---

Instructions

Many customers have no need of multiple zones and have not changed the default configuration. The site for these customers would currently look like this:

There may be additional connectors for redundancy, but everything currently lives in the primary zone. Although this works well, assuming all resources are located in the same geographic area, it does not align with the model described above where only DDCs reside in the Primary Zone. In this case when the Zone Syncing feature is enabled the Connector(s) and Resources will be moved to a new secondary zone, created with the same name as the Resource Location and will look something like this:

The Secondary zone has been created called “My Resource Location” to match the Resource Location and the Connectors and resources have been moved into it. This is essentially the equivalent of the initial site, but organized into a “zone friendly” structure, allowing new zones to be added to the site if required without disturbing the existing setup. If the Resource Location name is changed in the cloud portal the zone name will automatically be named (or renamed) to match the new name of the Resource Location.

The above situation is a common one with customers who have had no need to create additional zones and their sites will automatically be restructured when the feature is enabled. This will happen automatically without requiring any action from the customer and without requiring any down-time to the Site.

However, there are situations where the site can’t automatically be restructured. If multiple Resource Locations are in use and Connectors from more than one are placed together in a secondary zone (or in the primary zone) then resources in the zone could use any of the Connectors (possibly with the issues mentioned earlier). In this case the Site will need to be re-organised so there is one zone per Resource Location and the Connectors moved into the appropriate zone. Any resources that should use those Connectors will need to be moved into the same zone. An example of such a site is below:

 

In this diagram, CC-1x represent connectors from Resource Location 1, CC-2x those from Resource Location 2. This site has two issues:

• The Primary Zone has objects other than the DDC
• Connectors are in the wrong zone – CC-2a is in the Primary Zone and CC-1a is in the zone associated with Resource Location 2.

The desired configuration could be achieved in a number of ways depending on how the site was intended to be set up.
For example, if these Connectors were just incorrectly placed then this is easy enough to restructure:

• Move the Connectors to the correct zone – CC-1a into “My Zone 1” and CC-2a into “My Zone 2”.
• This leaves the resources in the Primary Zone which should be moved into one of the secondary zones. “My Zone 2” is probably the correct choice as CC-2a would have been used for these resources.

This leaves us with a site looking like the one in the first diagram – two secondary zones with 2 connectors in each associated with the correct Resource Location, resources all in the correct zones using the correct Connectors. When the feature is enabled for the site in this state the only changes might be the zone names being changed to match the Resource Locations.
If however CC-1a and CC-2b are really paired Connectors (say CC-1a was assigned to the wrong Resource Location when it was installed and really should be in Resource Location 2) and CC-2a is really from a third location half way round the world which has no corresponding Resource Location then it would break the current site setup if we followed the above steps. Fixing the site in this case is more involved:

• Add a new Resource Location and Connector for the resources in the primary zone
  • Create Resource Location 3 in the cloud portal add a new Connector, CC-3a to it
  • Wait a few minutes or run Reset-ConfigEdgeServers to sync the Connectors
  • Create a new zone “Zone 3” in Studio and connect it to the new Resource Location 3
  • Move the resources from the primary zone to “Zone 3”
• Remove incorrectly located Connectors. Connectors can’t be moved between Resource Locations so this is a matter of removing the Connector in the cloud portal and uninstalling the software on the connector (or deleting the Connector if it’s a virtual machine)
  • Remove CC-1a in the cloud portal – it belongs in Resource Location 1 but is used in the zone corresponding to Resource Location 2 (and uninstall the software on the Connector).
  • Remove CC-2a in the cloud portal – it’s been replaced by CC-3a in My Zone 3

Following these steps we should end up with a site looking like:

As recommended by best practice, additional Connectors should be added to each Resource Location to allow for redundancy.

As can be seen from the above, it would be difficult if not impossible for Citrix to attempt to automatically ‘fix’ such a site – the customer will need to be involved in moving resources around and creating/removing Resource Locations and Connectors to suit the intended site configuration.

Guidelines When Restructuring Incorrectly Configured Sites
The aim of the restructuring is:

• to have a one to one mapping between Resource Locations in the cloud portal and zones in the XenDesktop/XenApp site
• all connectors should be placed in the zone corresponding to the Resource Location they were assigned to when installed
• all resources (Catalogs, Hypervisor Connections, etc.) are moved into the appropriate secondary zone(s) so the Primary/Initial zone is empty apart from the DDC(s).

For some sites this will be as simple as the first example above – simply move Connectors to the right zones and move resources as appropriate. For others a bit of planning may be required.
Consider how many true Resource Locations/zones are actually required, creating new Resource Locations as required.

Note: If restructuring the site requires more than simply moving Connectors to the correct zone (e.g., additional zones required, new Connectors to replace ones placed in the wrong Resource Location) it may be easier and less disruptive to the end users to create brand new Resource Locations (with Connectors) first to match the intended site configuration, with the existing zones/resource locations being deleted after the restructuring is complete.

Once synced with the site, create corresponding zones in the site and associate with the appropriate Resource Locations then move the resources to the new zones before finally deleting the old Connectors, zones and resource locations.

Before starting the restructuring, ensure all long running tasks are complete and none are due to be started – moving a hypervisor connection while creating a catalog or provisioning machines may cause issues!

• Create any new Resource Locations needed and ensure each has at least one Connector (others can be added later for redundancy) and has a suitable name.
• Wait a few minutes or run the “Reset-ConfigEdgeServers” cmdlet to sync the new Edge Servers (Connectors) to the site.
• Start Studio and click on the Zones node (or Refresh the view if already there). Ensure all the Connectors are present.
• Create any new zones required, associate them with the corresponding Resource Locations and move any new Connectors into the new zones. Wait for a few minutes to allow time for the various services to recognise the new zones and connectors.
• Move resources to the correct secondary zones

The Primary zone should now be empty (apart from the DDCs) and all Connectors and resources should be in secondary zones. Any zones with resources but no Connectors should be cleared – without a Connector the resources can’t be used so delete them or move them to the appropriate zones. Any empty zones should be deleted.
Once the site is in this restructured state Citrix can safely enable the new feature for the site and the only effect should be zones being renamed if they don’t already match the resource location name. Once enabled all zone and Connector operations will be managed through the cloud portal – it won’t be possible to create, rename or delete zones through Studio, nor move Connectors between zones which should prevent the site being configured incorrectly going forward.

Additional Notes
When the zone syncing feature is enabled, zones linked to Resource Locations will be renamed to the Resource Location name and any new Resource Locations will have a new zone created with the same name. If there are any name clashes with existing zones which are not linked to a Resource Location (effectively an unusable zone as there will be no connectors in it either) the old zone will be renamed to a Guid to solve the name clash, though if the zone is empty it will subsequently get deleted. Such zones should have any resources moved into an appropriate zone linked with a Resource Location.