FlexCast Management Architecture

Or FMA in short. Did you hear? Citrix officially launched XenDesktop 7 just a few weeks ago. One of the biggest releases in years! Of-course I’m just kidding, who could have missed that?! Citrix also announced XenApp 6.5 FP 2 which will be released in June, once again enhancing and extending XenApp’s life, a good thing if you ask me. Although it seems that the Independent Management Architecture (IMA) will probably be around for many more years to come, it’s all FMA from now on when it comes to future developments. I thought it might be a good idea (and time) to have a closer look at FMA. Is it new technology? No. Is it improved? Definitely! Detailed overview? Scroll down!

During this Blog I will primarily focus on the FMA, for more information on the other components and technologies used in XenDesktop 7 check out some of my other Blogs. Although they’re partly based on the Excalibur Tech Preview the information is still valid as it applies to basic infrastructure components and concepts which were already announced and ‘known’ a few months ago and haven’t changed since and probably won’t for years to come.

The general idea

The FMA is primarily made up out of Delivery Controllers and Agents. Delivery Agents are installed on all virtual and or physical machines provisioned by XenDesktop 7, they communicate (and register themselves) with the Delivery Controller(s) and the license server. The Controllers on their turn communicate with a central (SQL) database. This database is very important, next to things like XenDesktop Site policies, Machine Catalogs, Delivery Groups and published applications and or (hosted) desktops, it also contains all live dynamic ‘runtime’ data like: who is connected to which resource, on which server, server load and connection statuses used to make load balance decisions and so forth. Make sure you implement some kind of database redundancy like SQL replication or clustering of some sort. If the database isn’t reachable for some reason running sessions will keep working but new sessions cannot be established and configuration changes aren’t possible, keep that in mind. More on the overall architecture and its components in a minute. The picture below, owned by Citrix, isn’t new but it does still provides us with a clear overview on the overall XD7 architecture.

A quote from Citrix: “Unlike XenApp, the Delivery Agent communicates only with the controllers in the site and does not need to access the site database or license server directly” Having quoted that, XenApp workers (session host only servers) offer the same sort of benefit. As they only host user sessions and will (or can) never be  ‘elected’ as an Data Collector for their zone they won’t get all the IMA store (database) information pushed into their LHC enhancing overall performance. However, these workers still consist of the same bits and bytes as installed on a Data Collector compared to ‘just’ a Delivery Agent which are lighter weight, as Citrix puts it.

FMA vs IMA

With the introduction of XenDesktop 7 IMA is gone! But what does this tell us? Well… It basically means that Zones together with their Zone Data Collectors are gone (it’s now one big Site) so no more Zone preference policies and Load Balance policies are now applied at Site level instead of Zones. No more IMA protocol and Service, these are replaced by the XD7 Virtual Agents that get installed on all Virtual and or Physical machines provisioned through XenDesktop 7. Since Data Collectors (and thus Zones) are no longer part of the overall architecture and all virtual and or physical servers in XD7 basically function as ‘Workers’ or ‘Session only Mode’ (as far as the former XenApp servers are concerned anyway) this also means that most of our old XenApp designs don’t apply anymore and it might be time to re-think and re-design them. Data flow has changed and in some designs different rules now apply.

LHC

XD7 Delivery Controllers don’t have a Local Host Cache (LHC) this means that user authentication, application enumeration (and requests) and user connection requests, plus a few more :-) all need to come from the central SQL DB, including server Load Balance information. XenDesktop has been doing it this way for a while now so it should be ok.

Improved

In XenDesktop 7 the FMA now combines provisioning and personalization tools for both desktops and applications. New and improved features include: Windows 8 and Windows Server 2012 support, Application publishing, XenApp is merged into XD or FMA if you will, allowing you to publish applications and or hosted shared desktops from Server OS’s. As of this release Machine Creation Services can also be used to provision virtual server machines (also called Workloads) not just desktops, a big step forward! Note that Citrix Provisioning Services (PVS) can still be used, no real changes there.

The best thing is, all Agents communicate with the same controller no matter which OS is installed! This is what makes the diversity in operating systems possible especially for XenApp. For example, you can have one Delivery Group (again, we already had these in previous versions of XD, the same goes for Machine Catalogs as well) applied to multiple different Machine Catalogs. See below and as opposed to XenApp, the Delivery Controller (former Data Collector) no longer needs to have Terminal Services installed.

Machine Creation Services

Big part of the overall FMA. As you know MCS within XD7 and earlier version takes care of the provisioning of virtual machines, multiple (tens, hundreds, thousands even) at once  on your underlying Host Infrastructure (your Hypervisor of choice) which in the case of XD7 can either be desktop or server workloads, Windows 8 and Server 2012 included. Some cool new features have been announced recently, I picked them up during one of Citrix’s Master Classes, read on below.

With the introduction of Hyper-V 3.0 in Server 2012 new features have become available. MCS as well as PVS can now both leverage SMB 3.0 shared folders on file servers with clustered shared volumes and SAN’s and use them as shared storage.

When Hyper-V 3.0 is used as the underlying Hypervisor MCS supports the VHDX format. Secondary disks attached to the virtual machine destined for PVS Write cache for example will also automatically leverage the ‘new’ VHDX format, the same goes for PVS Personal vDisks. PVS disks that are accessed and managed directly from the Provisioning Server itself will continue to use the VHD format since PVS is and can still be used on Windows Server 2008 R2 as well.

MCS can take advantage of another Hyper-V 3.0 feature called: Clustered Shared Volume Read Caching. I got this from one of the Citrix Blogs: XenDesktop 7 can take advantage of this capability to reduce storage IO for MCS catalogs during boot and logon storms.  The effect is similar to that of the caching that takes place on PVS hosts, except that the blocks are delivered once to each Hyper-V host and then shared among the VMs on that host. CSV cashing makes use of host RAM for this cache so there will be some tradeoff between cache size and the amount of RAM available to VM’s.

MCS now also supports KMS during the image creation process. It enables the KMS system to record each VM as a separate machine. Each machine created provides unique activation for Windows as well as Office 2010 installations.

When creating a master image and Personal vDisks are involved, it’s no longer necessary to manually run an inventory at the end of the image creation process. Also, during the image preparation process DHCP is now automatically enabled.

Storage Superseding. A new concept to MCS, you can configure certain storage in a way so that existing virtual machines on there will keep functioning but new provisioned virtual machines won’t be created on that specific storage. A nice feature to use when your storage is almost full.

PVS and MCS go hand in hand: you can create a Delivery Group containing both PVS and MCS provisioned machines. Perhaps not something you will implement in ‘real life’ but it shows you just how flexible the product is. Could be nice for POC’s though.

Catalogs

As far as XenDesktop goes a Catalog is still a catalog, you can have a Windows 7 catalog, a Windows 8 catalog etc… For XenApp however, things are different. From a XenApp point of view you can compare a Catalog with a Worker group with a few exceptions… As you probably know, in a XenApp Farm all the server systems need to have the same operating system installed, no exceptions. So if you have 2 or more Worker groups then all the systems within those groups will have the same OS installed. In XD7 things work different, for example, you can create two different Catalogs (Worker groups) for use with XenApp in which you can have one Catalog with Windows Server 2008R2 installed and another with Windows Server 2012 and publish two separate hosted shared desktops, all within the same infrastructure, a big change!

Delivery Groups

Delivery groups are not a new concept just a name change, used to be called Desktop groups in XenDesktop, they are still created from, or applied to, Catalogs and pretty much fulfill the same tasks. There is a big change though… In earlier versions of XenDesktop you assigned a Desktop Group to a Catalog or multiple Catalogs if needed, but the Catalogs all needed to be exactly the same, meaning that they all shared the same common image, 2008R2 for example. Now, in XD7 it is possible to assign a single Delivery group to multiple different Catalogs, as mentioned earlier. Think back to the example above, two Catalogs with two different operating systems installed same here but with just one Delivery group assigned to them. Simplified management! The same goes for XenApp, two different Catalogs: 2008R2 and 2012 (which already is a big new feature on its self), one Delivery group.

A quick note one the above, I haven’t got the chance to look at the final product yet, but during one of Citrix’s Masterclasses it showed that Delivery Groups can be used to either publish applications or (VDI) desktop or both from the same Delivery Group. This process is slightly different from the App publishing feature in the Excalibur Tech Preview release where Delivery Groups get added during the application publishing process. So I’m not sure if both options are still in there.

All under one roof

No more separate infrastructures for desktops and applications, it’s one install, architecture and console (Citrix Studio) to meet all your delivery needs. It includes several workflows which simplify and speed up the process of delivering desktops and applications to users. Delivery Agents in XD7 are configured via policies.  Any combination of Active Directory GPOs, the Studio console (HDX Policy), and Local GPO settings can be used.

This comes from one of the Citrix Blogs regarding FMA: The biggest difference between the two Delivery Agents (there are desktop and server DA’s) is the ICA protocol stack used.  For desktop machines, Citrix ships a single-user ICA stack (internally known as PortICA) which allows only one ICA session at a time.  This version connects users to the machine’s console session, similar GoToMyPC or other Remote Access products for a Desktop OS.  It also includes additional HDX features such as USB and Aero redirection, which are only available on a single-user machine.  For server machines, Citrix includes a multi-user ICA stack, which extends Windows Remote Desktop Services with the HDX protocol.  This is the same ICA protocol stack developed for Citrix XenApp, just with a different management interface to make it compatible with Excalibur controllers. I couldn’t have said it any better :-)

Other high level FMA changes

Some new services are introduced # The delegated admin service providing the Roles and Scopes # Configuration Logging # Monitor Service # Environment Tests # StoreFront integration # Machine Creation Services has been reduced to two services in total.

Some more changes:

There is a secondary database specifically for Configuration Logging and the Monitor Service # Remote PC is fully integrated into the Catalogs and Delivery Groups # Load Balancing is controlled via Group Policy, on Site level that is # Applications are now associated with Delivery Groups and application attributes like color depth and audio are also configured through Delivery Groups.

FlexCast Delivery Technology

FlexCast delivery technology… Desktop virtualization for everyone. One of the many marketing term out there. FlexCast offers you several delivery models, one solution to meet al use cases. It is designed to support all type of workers (as Citrix likes to call them) out there. For example, Task Workers access a small set of applications but at the same time they interact with customers, partners and employees. As a result they have access to critical data. A local Virtual Machine might be the best solution, here’s where FlexCast comes in. Another example, so called Road Warriors need access to their desktop from anywhere, here a Hosted VDI of Hosted Shared desktop might do the trick, again… FlexCast! Of-course it’s all up to you, you decide which model best suites the use case at hand! FlexCast offers you the following desktop delivery models:

• Local Virtual Machine
• Streamed VHD
• Hosted VDI
• Hosted Shared
• On-Demand Apps

Here’s a nice quote from one of the Citrix Blogs written almost four years ago but still valid “I find that it helps me to think of FlexCast more as a strategy for delivering desktops, than as a specific technology. It’s about thinking of all your virtual desktop and application delivery methods as a toolbox that enable you to directly address the different performance, security, personalization and mobility requirements of all your users” Nice one right?! Below is a  graphical overview, well… of FlexCast Delivery in combination with the ICA / HDX protocol.

Detailed overview

Below I’ll try and give you an complete overview on all components used within a XenDesktop 7 architecture as we know it today and discuss the data flow throughout, protocols and port numbers included. As always, if you feel I’m leaving anything out, give me a shout. Click to enlarge, make sure you extend it to its fullest! Please… don’t be to hard on me, I don’t use Visio that much ;-)

Walkthrough

It took me a while to draw this, mainly because my Visio skills aren’t that good. I didn’t include all port numbers of all management consoles and there are also some connections missing, it’s crowded enough in there already. I think I got the most important components, ports and protocols. It may seem a bit chaotic at first but take your time, follow the arrows and eventually it will all become clear to you… I hope :-)  Let me know what you think.

So what happens when a user logs in? First… data flows through the Firewall and If implemented NetScaler will load balance incoming traffic accordingly # Next StoreFront needs to authenticate the user logging in. It does this, in most cases anyway, through Active Directory # How this process is handled in detail depends on your NetScaler / StoreFront configuration.

Also note that I don’t have a DMZ set up here, not even a single hop. For demonstration purposes just imagine it’s there :-) Depending on your DMZ configuration (single or multiple hop) combined with your NetScaler / StoreFront server placement, authentication might take place on the NetScaler in DMZ 1. For example, if your StoreFront server is located on your internal network, which is most often the case when you implement an single hop DMZ with two firewalls configured, hence DMZ 1. Otherwise unauthenticated ‘traffic’ will enter your internal network which would be a security risk. In a double hop DMZ scenario your StoreFront server will most likely be placed in the second ‘hop’ or DMZ 2, where authentication will take place before getting access to you internal network. Of-course there multiple configuration possible.

Once authenticated, either in DMZ 1 or DMZ 2 as explained above, StoreFront forwards the credentials to the Delivery Controller # Here the Secure Ticket Authority (STA) as part of the Citrix XML (Broker) Service generates a ‘Secure Ticket’ # Next the Delivery Controller queries the SQL database for the users resources (no more LHC) once known (XML file) StoreFront will generate a webpage based on this information, finally displaying all resources available to the user. That’s step one.

Step two. The user clicks a resource # Again, StoreFront communicates with the STA / XML Broker Service on the Delivery Controller asking for a system that can provide the resource # Next the Delivery Controller contacts and queries the SQL database for connection information. As mentioned earlier the database contains all configuration information of the XenDesktop Site (no more LHC) so it know which system(s) can offer the requested resource. It also holds all live runtime data used for load balance decision making # Based on this (combined) data it returns the connection information back to the Delivery Controller forwarding it to StoreFront # Based on this information StoreFront generates a default.ica file including the STA / XML server address, the secure ticket and server IP address to connect to containing the resource # The user / client uses this ica file to connect to NetScaler which will contact the STA / XML service to verify if the secure ticket is valid # The STA / XML service validates the secure ticket from memory and the connection is established based on the IP address given in the default.ica file finishing the connection process # This is the first ‘phase’ the system goes through, next is the so called ICA Handshake were the client’s ‘capabilities’ are passed through followed by TS licensing, virtual channels negotiation, Citrix’s licenses and so on. Of-course this is all high level but still gives you an good idea on what’s actually going on.

Final Connection

The final connections are highlighted as thick(er) dotted red lines within the detailed overview above. The connection can either be external using HTTPS / 443 carrying the ICA / HDX protocol (NetScaler) or internal through a direct ICA / HDX connection from the workstation to the (physical or Virtual) server IP address connecting you to your virtual (hosted) desktop or application(s). But…  there is one other possibility. if for whatever reason the client can’t or won’t install Receiver then StoreFront will take over and make the connection for you, still using HDX and all other optimizations features available just like any other connection out there!

Conclusion

That’s it, I hope this has been somewhat informative. If you have any questions and or remarks just drop me line. I’m off to the French Alps next week to take on the Alpe D’Huez slopes (multiple times) so it might take me a while to answer but I always do.

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.