Yes, Zones are back! This seems to be a very popular quote on Twitter and Linked-In ever since Citrix released XenApp/XenDesktop 7.7 last week. And to honest, I’m exited as well. Are these the zones we were, or are used to in XenApp 6.5? No. But they’re close. After I installed XenDesktop 7.7 the morning after its release, I had 3 zones up and running within 5 minutes, and that’s only because I didn’t read the ‘manual’ up front. Let’s have a look and see what we come up with along the way. I took the bullet approach on this one. Scroll down for some screenshots on how to configure XenDesktop / XenApp zones.
- When dealing with multiple (geographically separated) locations it normally means we would set up and configure multiple Sites, which then need to be managed separately from each other.
- When Sites need be equally configured this can be (very) challenging depending on the number of Sites.
- Also, each Site will need its own highly available SQL central Site database.
- If an organization has multiple locations within different countries and on various continents for example, this type of setup (multiple Sites including a SQL HA setup) is still recommended. Which is basically no different as we were, or are used with the IMA.
- With (satellite) zones each zone is basically a sub Site but without the need for highly available SQL central Site database.
- You will (always) have one Primary Site (it’s named Primary by default but this can easily be changed) and optionally multiple zones.
- You can name the zones anything you like.
- You can setup delegated administration, restricting specific tasks on a per zone basis.
- Citrix Studio is configured only in the primary Site and from there you will be able to manage each zone independently from each other, policies included.
- When needed you can publish Citrix Studio from the Primary Site to other zones.
- This also applies to Citrix Director by the way.
- Each zone will have (at least) its own Delivery Controller, StoreFront server, NetScaler (optional) and of course one or multiple VDA’s, desktop or server machines.
- Zones enable us to connect users to resources, which are closest to them, keeping traffic ‘local’.
- Traffic flows as usual (resource enumeration and launch) with the Delivery Controllers in the zones directly communicating with the central Site database and the license server in the primary zone. No specific configuration details have been released with regards to StoreFront. Won’t be long now I’m sure.
- So while you don’t need a HA SQL setup within each zone, as we would have with separate Sites, we still need to have at least one additional Delivery Controller and StoreFront server. Yes, one is enough, not recommended though.
- This setup also means we still depend on Connection Leasing once the central Site database becomes unresponsive or unavailable all together. And although Connection Leasing might be a ‘nice to have’ feature up to this point, something tells me this will soon change.
- Delivery Controllers in the Primary Site will store leasing information for all zones including the Primary zone while Delivery controllers in the (satellite) zones will only store leasing information for the Primary Site and their own zone, not for any additional zones.
- Zones were already available within CWC (Citrix Workspace Cloud). This is because new features and functionality, with regards to XenApp and XenDesktop, or the FMA will first find their way into CWC (which includes both XenApp and XenDesktop) before they will be build into the on-premises products like we know them.
- VDA’s within a zone automatically register with a Delivery Controller in their own zone (preferred Controller). If none are available they will attempt to register with a Controller in the Primary zone. When successful they will stay registered even if a Controller in the zone it originated from becomes available again. No fallback mechanism, at least not today. I assume this has something to do with the fact that Delivery Controllers do not communicate with each other (unlike Data Collectors in XenApp 6.5) so there is no way for a Controller in the Primary Site to know when a zone Controller comes back online. Although they (delivery Controllers) do show en register in Studio. When a machine catalog is moved from one zone to another all the registered VDA’s will re-register with the ‘new’ Delivery Controller of that zone.
- VDA’s in the Primary zone can and will only register with a Controller in the Primary Site.
- When a zone Delivery Controller fails, another one in the same zone will take over. If none are available, it will auto failover to a Controller in the primary Site. Which makes sense since zone VDA’s will also register themselves in the Primary zones when no local (preferred) controllers are available.
- Make sure to keep your machine catalogs close to any host connection it might be using. You can add one or multiple host connections per zone if needed / desired.
- Provisioning services is not ‘zone aware’. Configure the Machine Catalogs by hand using Citrix Studio. If you let PVS handle this, the catalog(s) will be created in the Primary zone by default.
- While zones might not be the zones we had, or have with XenApp 6.5, we now have zones for XenDesktop as well, which we didn’t had before!
- It would be nice if they could somehow bring back some of the worker group functionality like failover load balancing and apply it to machine catalogs for example. This way the so-called, and earlier mentioned preferred Controllers could be matched to a preferred zone and so on.
- As soon as StoreFront 3.1 makes GA this will make a killer combination, assuming that most multi-site configuration options will be available from the GUI, for real this time :)
Also make sure to check out the E-Docs page on XenDesktop / XenApp zones for some additional information.
Here’s how Zones are configured from Citrix Studio:
Configure XenDesktop / XenApp as usual by adding in your Host Connection for example. Have a look at the pic below, on the left hand side you can see the Zones section displayed.
Next we configure our Machine Catalogs, again business as usual.
After that it’s time to configure some Delivery Groups. I won’t take you through each and every step since that isn’t the focus of this article.
Ok, let’s get into the ‘Zone’. Click Zones on the left hand side of your screen. As you can see I currently have three Delivery Controllers set up, combined with two Machine Catalogs (with two XenApp server in total spread among them), two Delivery Groups and one Host Connection, the one we started out with. You might also notice the Site View with the Primary Site right beneath it, by default it will hold all Site components. Also note that after installing XenDesktop / XenApp you will have to configure and set up your XenDesktop / XenApp 7.7 Site first before you will be able to use / configure any Zones.
As soon as I clicked Create Zone I was able to name my Zone, give it a description and select the components that I wanted to add to, in this case Zone 1. As you can see, there isn’t much to it. Click Save and you are good to go, or wait…
When I clicked Save it gave me this, see below. It tells me that my Host Connection (which will stay behind in the Primary Zone in this case) and the Delivery Controller I selected for Zone 1 are, or will be in different Zones based on this configuration. I clicked No since I wanted DELIVERYCTRL1 to be placed in Zone 1, just for demonstration purposes. I really like this approach.
After creating Zone 1 (and Zone 2 as you can see in the screenshot below) I decided to find out what happens when I want to move something from Zone 1 to another Zone. So first I selected a component from Zone 1 simply by clicking on it so it is highlighted in Studio (you can select multiple just as easy), next I clicked Move Item on the right hand side in Studio, and ended up with the below screen. Again, here you can also see the warning with regards to the Host Connect. It is simply a matter of selecting the preferred Zone to move your component to and hit Yes.
Below you see the Primary Site including both Zones, 1 and 2 I created using the steps mentioned above.
When the primary Zone is selected, as you can see on the right hand side of Studio it can’t be deleted (shown in the corresponding image on the right here as well). It also shows, since I have DELIVERYCTRL1 selected in Studio (again, see the above image) I can choose to either move it or to create a completely new Zone which will then include DELIVERYCTRL1, meaning it will automatically be moved from its current Zone, the Primary Zone in this case. If you select any of the other (Satellite) Zones, like Zone 1 for example, you do have the option to delete it, as shown in the image (on the left) below.
If you decide you want to delete a Zone (by first highlighting a Zone in Studio and then select Delete Zone from the menu as shown in the image on the left, or simply by right clicking on the Zone itself) but the Zone itself is not empty, as is the case with Zone 1 (as shown in the image below) not only will you be warned, you will also have the option to move those items to another Zone of choice.
Wrap up
That’s it for now as far as Zones are concerned. You might need a minute to get your head around the concept, especially when you are familiar with the ‘old’ Zone approach as well. In the short movie released by Citrix earlier they already mentioned that this was going to be a phased release, so more to come. I think they’re of to a good start and I can’t wait to see what they have in store for us. Looking froward to Summit as well, although I won’t be attending it is still good fun to experience these types of events from a distance, literally in my case. Regards, Bas.