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.
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.
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.
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 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.
That’s it, I hope this has been somewhat informative. If you have any doubt, send mail to email@example.com
Reference materials used: Citrix.com, Google.com and the E-Docs website.