How do citrix zones work

We have 2 Zones, one Primary default and one Secondary. When the Citrix VDAs in the primary zone goes down, we want to failover to the secondary zone. If there are no issues in the primary zone, then users should not be allowed to connect to the VDAs in the secondary zone — as the secondary zone is on a slower WAN link. We basically want an Active Passive setup. Each machine catalog belongs to the same Delivery Group. Only users that are part of this AD group can have access the secondary zone resources.

The MCS master image is replicated to the secondary zone by Veeam. The replica is then used to create MCS nodes for the machine catalog in the secondary zone. They are able to talk to the delivery controllers in the secondary zone just fine, however, they also pickup the delivery controllers from the primary zone as well unsure if this is an issue or not. This works fine. Every time we perform a test, we make sure to logout and login of storefront.

If you are publishing applications not desktop , then you can split your Catalogs into separate Delivery Groups and publish the app to both Delivery Groups.

We are also in similar issue. If we split into multiple farms or sites, then how we should be able to configure the UPM via gpo. Hopefully that would be given as a same profile path across both sites..

Any insights!! It is not supported to do any multi-master replication of user profiles. After a failover, you can manually change the DFS Namespace configuration. Hi Carl, in 7. These servers have the Nutanix AHV plugin. For full clones, is there a difference when using mcs full clone option or another service or technology?

You might have to contact Nutanix since they wrote the plug-in. The third option is for manually built machines that were not created using MCS. Spin up a catalog from a template machine, note the mac addresses , reserve IPs for these macs and then boot? Secondly if I want to create a site across two datacenters for active -active DR. Is it best practice to create two host connections -one for each datacenter- and then create a machine catalog for each connection, then create one delivery group with half its machines from each of those catalogs?

I assume connections will be balanced across all servers but if I lose a DC I am still up? My preferred multi-datacenter design is separate farms in each datacenter with StoreFront aggregating icons from both farms.

This gives me maximum control over how users connect. Your method might be OK for multiple datacenters in the same metro. We use a LAPS technology to reset local admin password, should there be a issue with full clone or xenapp? Is it worth excluding laps for these desktops? We are using a MCS persistent machine catalog. The issue is that we have machines that fail their domain trust from time to time. The fix is to log on locally and add it back to the domain. Any help would be appreciated.

MCS manages the machine accounts and their passwords. Password changing should not be disabled for deployed machines, but it is not a bad idea to disable it for the golden image to avoid issues when bouncing between snapshots. Make sure nothing else is touching these computer accounts. You could turn on auditing for the specific accounts or containing OU to track what else could be affecuaff this. We are having the same issue with persistent machines, using the current release 7.

MBR will certainly work. HI Carl — regarding the 16MB identity disks Citrix does this by design right and poses no impact at all? Are you asking if Windows will somehow fill up the drive? The drive is mounted without a drive letter. Hi Carl, you mention the rewrite action for the zone preference and have the screenshot for the action what about the rewrite policy what should that look like?

Then you have to add them to a Catalog in the DR site. Hi Carl, do you know if we can set a prefered zone for a published desktop like for applications? Appreciate your help. I am trying to find a solution to this exact same customer requirement. They want Active Active but want to fill up Zone 1 first, then if no desktops left only then send them to Zone 2.

Dual Site same as you Ben. I havent yet found a solutions to this!. Any ideas anyone or did you find a solution Ben? I have tried configuring 2 Catalogs in seperate zones, but of course you have to then have 2 Delivery groups as you cant have desktops from 2 different catalogs in the same delivery group?. The customer wants to see only 1 desktop published but where they go is seemless to them and ONLY if site 1 has no more desktops!.

Ignore this I managed to find a solution to their problem. You need to create the Delivery Group first, then go back in and select. Silly really you would think it would allow you to select from both while creating. So X2 2 Create a single delivery group add machines from 1 of your catalogs 3 Go back into said delivery group and add the remaining machines from your catalogs 4 Setup Zones reflective of primary and secondary sites 5 Add your user group to the Primary Zone Done.

Your desktops will now be selected for those users from the Primary Zone until there are none left, then routes them to the secondary zone VDIs. We have a standard Published desktop that all users have access to These are in 2 worker groups. Users in a particular security group are load balanced to WG2 — unless thats full — then it Fails over to WG1 all other users are load balanced to WG1. Desktops are limited to a single Delivery Group. You can call Citrix Support and ask them to add that feature again.

Been able to fake it to a degree with zones, security groups and dedicated machine catalogues. There are many considerations, including the following: Machine type — single user virtual desktop , or multi-user Remote Desktop Session Host.

RDSH is more hardware efficient. Application integration — locally installed, App-V, Layering, Virtual Apps or XenApp published, leave on local endpoint machine, cloud apps, etc. User Profiles — roaming, mandatory, home directories Group Policies — session lockdown, automation Disaster Recovery — replication.

VDAs running in a warm site. DR for profiles and home directories too. Non-persistence — Non-persistent VDAs revert at every reboot. To update non-persistent VDAs, simply update your master image, and push it out. Layering — The VDA VMs can be composed of multiple layers that are combined during machine boot, or when the user logs in. Citrix App Layering is an example of this technology. A single layer can be shared by multiple VDAs. See the Reddit thread Citrix at scale. The more master images you have, the more effort is required to maintain them.

Same apps in multiple images — Some apps are common to multiple images. For example, Office and Adobe Reader. How do you update these common apps identically on multiple master images? Multi-datacenter — how do you perform the same master image updates in multiple datacenters?

Replicate the master images? Perform the same change multiple times? Automation complicates the simple management you were hoping to achieve. Master Images must be designed — Which apps go on which master image? Do you install the same app on multiple master images? How do you know which apps a user needs? How are One-off apps handled? Do you create a new master image? Do you publish it from Virtual Apps or XenApp double hop?

Do you stream it using App-V? Layering is another option. Application Licensing — for licensed apps, do you install the licensed app into the master image and try to hide it from non-licensed users? Or do you create a new master image for the licensed users? Patching multiple images — when a new OS patch needs to be deployed, you have to update every master image running that OS version.

Thus Citrix admins usually try to limit the number of master images, which makes image design more complicated. How do you manage an app that is installed on multiple master images? Who manages the master images? Desktop team? Does the Citrix admin team have the staff to take on this responsibility? Would the desktop management team be willing to perform this new process? Politically feasible? Would this new process interfere with existing desktop management requirements?

Responsibility — if the Citrix admins are not maintaining the master images, and if a Catalog update causes user problems, who is responsible? Compliance — template machines usually go through a security and licensing compliance process. If the Citrix team is managing the master images, who checks them for compliance?

Does the desktop team have the skills to perform the additional RDSH testing? Roaming Profiles — some apps e. Office save user settings in user profiles. Since the machines are non-persistent, the profiles would be lost on every reboot unless roaming profiles are implemented. This adds a dependency on roaming profile configuration, and the roaming profile file share.

How is the Outlook OST file handled? OST files are large multiple gigabytes. One option is to use group policy to minimize the size of the OST file. How is the large OST file roamed? If you leave the OST in the default location, then the OST is copied back and forth every time the user logs on and logs off.

Search indexes are rebuilt every time the user starts a new session. This takes time and performance. Citrix Profile Management 7. IT Applications e. Antivirus in particular has a huge impact on VDA performance.

The special antivirus instructions for non-persistent VDAs are in addition to normal antivirus configuration. Application Integration Technologies — Additional technologies can be used to overcome some of the drawbacks of non-persistent machines: Microsoft App-V — this technology can dynamically stream apps to a non-persistent image.

Different users get different apps. And the apps run in isolated bubbles. However: App-V is an additional infrastructure that must be built and maintained. App-V requires additional skills for the people packaging the apps, and the people troubleshooting the apps.

Since the apps are isolated, app interaction is configured manually. Because of application isolation, not every app can run in App-V. Layering — each application is a different layer VHD file. The layering tool combines multiple layers into a single unified image. Layers are updated in one place, and all images using the layer are updated, which solves the issue of a single app in multiple images. Citrix has an App Layering feature. Notes: Citrix App Layering is a separate infrastructure that must be built and maintained.

Somebody has to create the layers. This is an additional task on top of normal desktop management packaging duties. It takes time to update a layer and publish it to multiple images. Here are some advantages of full-clone, persistent virtual desktops as opposed to non-persistent VDAs: Skills and Processes — No new skills to learn.

No new desktop management processes. Use existing desktop management tools e. The existing desktop management team can manage the persistent virtual desktops, which reduces the workload of the Citrix admins. Just treat the persistent virtual desktops like that are more PCs.

The persistent virtual desktops are usually powered on and in the datacenter, thus improving the success rate of package deployment. There are only about 20 VDAs in Azure with max about users. This is an interim phase to basically upgrade what they have to 7. Thanks again. Hello George I am reading about zone and trying to find out what happenes to vda in primary zone when primary zone goes offline.

According to citix documents it says connection will degraded but it does not mention about if vda will go to unregistered state or will it still be registered. Will it keep trying to register with DDC in primary zone or stay unregistered until primary zone comes online. Thanks for your help. If all the DDCs have failed then it will ultimately become unregistered. How does a client know to connect to the local storefront if WAN connectivity fails?

Well there is nothing in Zones that needs configured when it comes to StoreFront. If you have a secondary Zone that represent a remote datacentre, install StoreFront servers inside the datacentre, and configure them to speak to Delivery Controllers in the same datacentre. Hello, very interesting article.

I have a question about that…As we have the problem like the principal zone could down and we would have problem to access when the new users are trying logon.. Similar like a lot of architectures of Active directory, a domain for control and other domains for resources.. Thanks Juan. You could have a Primary zone spanning multiple PODs. Just keep in mind the latency between each of these PODs. This SQL instance will have to reside in the primary zone. If it goes down, your users should continue to have access to their applications and desktops as VDAs maintain a registration to the DDCs in their respective Secondary zone, and Local Host Cache mode would be initiated.

Thanks George! No problem Juan. Just be sure to at least double-up on your Delivery Controllers at each secondary zone. They can launch from either AZ1 or 2. Only when Both AZ goes down Az3 should take the load. Do you think this approach to use Citrix Zones is correct? In an Application Properties, in Group section I have delivery groups of Primary and secondary zone with Primary taking priority zero and DR taking priority 1.

Does this mean always primary DG is prefered when an application is launched? Yes given the latency I think that is OK.

Hello George, We are in the process of setting up Citrix remote PC delivery model physical desktop residing at LAN network all branches are having connectivity with DC and DR simultaneously requirement is to set up disaster recovery environment for Physical desktop when all the management component failed at DC my physical desktop should be able to register at DR DDC without any manual intervention can Zones fulfill my requirement what is the best approach with less manual intervention since all are physical VDA also what all management component I should place at DR i.

Notify me of follow-up comments by email. Notify me of new posts by email. Picture from Citrix. Specify a name and the components you want to move to the zone. Click Save. Tags: citrix , zones. Any help is appriciated. Any help is appreciated. George Spiers June 7, Pavan Ayyagari July 13, Sessions are also related to the zone where the VM catalog belongs whether it is a desktop or an application server. Because not every kind of broker farm supports zones, and additional zones apart from the primary might not be defined, the "Zone" column is not visible by default in the Sessions list, but you can add the column by using the column chooser.

A zone preference can also be set for Active Directory users or groups, so when a user opens its desktop or applications, the session will be preferably open in a VM in that zone. The zones defined in a Citrix Virtual Apps and Desktops site are displayed in the Broker farm detail view:.

The primary zone is displayed in bold characters its name could not indicate that it is the primary zone, for example, it could be "Corporate". Note: the zones in the "Zones" tab can't be added, removed or renamed from Flexxible SUITE, since the layout of zones is considered a Citrix Virtual Apps and Desktops site administrative task and it is expected to be managed from the Citrix Studio console.

However, by clicking a zone, the zone's detail view is displayed and memberships for catalogs, published applications and users or groups can be managed from Flexxible SUITE. The "Broker farm nodes" tab and the "Hosting units" tab display read-only lists of Citrix delivery controllers and hosting units respectively. This tab shows the list of catalogs assigned to the zone.

In this list, you can link other catalogs to the zone by using the "Link" button and searching for the catalogs to add. There is no "Unlink" option since a catalog must always be assigned to a zone. If you wish to move a catalog to another zone, simply link the catalog from the new zone. Please note that the column "Hosting unit zone" will be displayed in red if the zone is different than the zone assigned to the catalog, as it could create a performance problem.

Note: when moving a catalog to another zone, the open sessions for VMs in the catalog might not display the new zone in Flexxible SUITE unless the user disconnects and re-connects. This tab shows the list of published applications that have this zone as its preferred zone. You can change an application's preferred zone by using the "Link" button and searching for the application.

The "Unlink" button allows to clear the zone preference for published applications, so they will be opened in an available application server, prioritizing those in the user's preferred zone, if specified. The "Is template" column indicates if the published application is published only for template designers. Remember that applications published in an Application template definition are published once in the template itself with the "Is template" check marked, intended for testing by the template designers and in the Application, Server Farm configured to automatically propagate applications from the template.

This tab shows the list of Active Directory users and groups that have this zone as its zone preference for this broker farm.

To set this zone as the preference for a user or group, use the "Link" button and search for the users or groups among the domains defined in the Flexxible SUITE "Domains" list. Note that the same domain user or group could have different zone preferences for different broker farms. This tab is displayed for broker farms of a kind "Citrix cloud", and lists the cloud connector machines associated to the zone. It is recommended to have at least two cloud connectors per zone for high availability.

The set-up and association of Citrix Cloud connectors must be performed through the Citrix Cloud console.