As it stands today, I think most of you know that both XenDesktop and XenApp are built on top of the FlexCast Management Architecture, or FMA in short. And if not, you do now. Of course, this didn’t happen overnight. XenApp became part of the FMA back in June 2013, the 26thto be exact when Citrix launched XenDesktop 7.0 (previously known under the code name Excalibur).
It marked the date that Citrix decided XenApp would no longer be sold as a separate product and would from then on be part of XenDesktop. Although this might have come as a surprise to some, the FMA was always known to be the next generation architecture, providing enhanced scalability, robustness and manageability over the IMA. And while in its early days the FMA was a VDI only platform it has slowly but surely evolved to now also support RDSH(hosted shared desktops) as well as hosted/published applications and tons of other enhancements and features.
The idea behind this project? Before commenting, read the introduction blog post here
This change also meant that any further developments around XenApp 6.5 (and the IMA) would stop as well: no more additional feature packs (with one exception) or other types of enhancements going forward. As a final gesture, together with XenDesktop 7 they also released Feature Pack 2 for XenApp 6.5. Of course, this announcement got a LOT of attention and unfortunately for Citrix not in a good way, I’m sure most of you can remember.
On the other hand, it did help in getting the FMA a lot more attention: suddenly Citrix-minded IT folks were aware that there was more than just the IMA, though they probably knew already. And I don’t mean this in a bad way. As you might or might not know, the FMA originated with the second big XenDesktop release, which was version 5.0 back in December 2010, the 17th, and stayed with XenDesktop until the 7.0 release – and forward – as mentioned. XenDesktop 4.0 (and previous versions) released earlier in 2009 was still primarily based on the IMA.
As a side note, while the Citrix archives do not mention any of this–at least I wasn’t able to find any related information–the true birth of XenDesktop actually started with ‘Citrix Desktop Server’, which back then wasn’t considered to be enterprise-worthy by most and only provided some basic VDI features. It was quickly replaced by Citrix XenDesktop 2.0 (IMA-based technology), introducing Citrix’s PortICA technology, a huge leap forward. This was around 2008.
At that time (around the release of XenDesktop 7.0) if you were a diehard XenApp administrator who had nothing to do with XenDesktop, the FMA was unknown territory. And now that XenApp was suddenly a part of the FMA as well, some learning had to be done. As you probably know by now, configuring and administering XenApp in 6.5 was, or is, completely different from XenApp as part of XenDesktop in 7.x, and thus the FMA.
No matter if XenApp would stay part of XenDesktop or might become available as a separate product in the future, it was now based on the FMA instead of the IMA, period. So, you could say that technically, at least for some, there was a challenge no matter what. But the transition from IMA to FMA was just the first hurdle; unfortunately, more would follow.
Made possible with the support of my sponsor IGEL
Citrix is known to change its product names from time to time: I’m not telling you anything new here (even in 2018 this holds (very) true). What is particularly hard and annoying about this is explaining these (constant) changes to our customers. The same thing happened here. What? No more XenApp? Why? What do we do now? What about support? I’m sure we can all laugh about it now but that wasn’t the case not too long ago.
XenApp is now part of the FMA: great. And if you want to be able to leverage, let’s say Windows Server 2012,you will need to upgrade to at least XenDesktop App edition (more on this in a minute) which is fine as well, but what about session Pre-Launch, Lingering, SSO, Power and Capacity Management, Smart Auditor, Zones, Failover policies, Shadowing users and a whole bunch of other features that we (can) currently use in our XenApp deployment? 2018 update: today XenApp 7.x is fully on par with, and beyond 6.5.
When compared to XenApp 6.5 there were a ton of features missing, something that Citrix addressed with a phased approach where every new XenDesktop / XenApp edition introduced new features into the FMA, which in some cases were already there in XenApp 6.5. Again, it’s ok now, but back then most people weren’t too happy about all this.
Having said that, let’s not forget that the FMA was designed with VDI in mind, period. Technologies and concepts like RDSH (XenApp) and application publishing needed to be built in from scratch. And looking at XenDesktop / XenApp 7.8 (2018 update: 7.18) today I think they did a good job.
With the introduction of XenDesktop 7.0 (and the disappearance of XenApp) Citrix introduced a new type of license under the name XenDesktop App Edition (in addition to the XenDesktop VDI, Enterprise and Platinum licenses). This replaced the ‘old’ XenApp 6.5 licenses and would offer XenApp features exclusively, or at least that was the general thought behind it. And while this sounds great on paper, in practice it didn’t go down very well. In one of their earlier announcements regarding XenDesktop 7.0 licensing, Citrix told us:
XenApp Enterprise and Platinum customers with active Subscription Advantage can update to this (XenDesktop app) edition at no additional charge and migrate their environments at their own pace.
What they were basically saying was: if you have an active Subscription Advantage but are running XenApp Advanced edition you are out of luck and need to purchase new (XenDesktop Enterprise or Platinum) licenses.
Otherwise, these customers would be stuck with IMA, not able to use Windows Server 2012 R2, including some of the other advantages that the FMA brought to the table, a bad marketing move to say the least. Customers, most anyway, couldn’t care less about the underlying architecture. All they wanted was, or is, a cost-effective and robust solution that just works.
Luckily Citrix paid attention and listened. First, they assured customers who were running XenApp 6.5 Advanced edition that a separate license Trade-Up Program would be established. Although I never found any specifics on this, soon after I didn’t really care because, as if it had never left, they brought back XenApp!
Later that year on March the 26th2014, Citrix reinstated and officially released XenApp and XenDesktop 7.5 as separate products and downloads, including support for Web Interface! Still based on the FMA and some features missing, but at least now most were happy. To be honest, this was more marketing than anything else: technically nothing changed.
You still download the same bits and bytes and depending on your license you eitherinstallXenApp or XenDesktop, which would then include everything from RDSH to VDI. What about our customers? Now that they finally understood that XenApp was (supposed to be) gone and that its functionality and features were part of XenDesktop, we had to start all over again. At least now we knew this would be the last time. Right, Citrix?
In fact, they even did one better during Citrix Synergy back in May 2015. It was there that they announced extended support for XenApp 6.5. This meant that the end of maintenance for XenApp 6.5 was moved from February 24, 2016, to December 31, 2017, and the actual end of life moved from August 24, 2016, to June 30, 2018. But only for customers who deploy Feature Pack 3 for XenApp 6.5, which was announced as well. A great applause followed.
Below you will find a recap of some of the most important dates regarding the FMA evolution until now, followed by a brief overview highlighting some of the biggest and main differences that come with the introduction of the FMA compared to the IMA.
- November the 16th Citrix officially releases XenDesktop 4.0. Still IMA-based.
- December the 17th Citrix officially releases XenDesktop 5.0. FMA 1.0.
- June the 26th Citrix officially releases XenDesktop 7.0, including XenApp. FMA 2.0.
- March the 26th Citrix officially releases XenDesktop and XenApp 7.5 again, as separate products. FMA 2.0.
- September 30th Citrix officially releases XenDesktop and XenApp 7.6. FMA 3.0.
- December 28th Citrix officially releases XenDesktop and XenApp 7.7. FMA 3.0.
- February 25th Citrix officially releases XenDesktop and XenApp 7.8. FMA 3.0.
- May 2018. Citrix officially releases XenDesktop and XenApp 7.18.
The FlexCast Management Architecture is a .NET-based services-orientated architecture built upon the WCF (Windows Communication Foundation) framework, which is used for building service-orientated applications consisting of a deployment model built up of controllers (and agents) running multiple highly available stateless services, as you will soon find out. As mentioned, the FMA as we know it today was first introduced with XenDesktop 5; before that, XenDesktop was still primarily based on the IMA. Over time the FMA has evolved from 6 services in its first release back in 2010 to 13 services today (2018) all of which we will have a closer look at throughout the next chapters.
Please note. Although I do mention several components and concepts related to the IMA (Independent Management Architecture), I won’t go into any further detail. I assume you have at least a basic understanding of the IMA and how it operates. If you are still somewhat unfamiliar with some of the FMA jargon used in the upcoming section and perhaps previous sections, don’t worry: during the next chapters, I will go over each component, service, technology, and concept in more detail.
Next to the earlier mentioned services, the FlexCast Management Architecture is primarily made up of Delivery Controllers and Agents (Virtual Delivery Agents) or VDAs. Delivery Agents are installed on all virtual and/or physical machines managed/provisioned by XenDesktop and/or XenApp 7.x. They directly communicate (and register themselves) with the Delivery Controller(s) and the license server.
The Delivery Controllers in their turn communicate with the Central Site database (Microsoft SQL only), StoreFront, Studio and the underlying Host Connection (your Hypervisor or cloud-based platform of choice, you can configure multiple). With the transition from the IMA to the FMA, the database has become more important.
Next to static information 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 including current server load and connection statistics used to make load-balance decisions.
Although Connection Leasing (which will be discussed in more detail) does a reasonable job in connecting users to their last-used resources (during the last two weeks by default) when the Central Site Database is down, implementing anHA SQL set-up is still recommended. 2018 update: Local Host Cache has been re-added and will be discussed in one of the upcoming chapters.
Without Connection Leasing in place, when the Central Site database becomes unresponsive or unreachable altogether, existing connections will continue to work but new sessions cannot be established/brokered. And like with the IMA, no Site-wide configuration changes are possible.
Initially, when XenApp was released (2013) as part of the FMA, some significant and fundamental changes took place on the underlying architecture: some permanent, some not. To name a few, up to XenDesktop / XenApp 7.6 Zones were no longer optional, in fact, they were gone altogether. All we had were separate (complete) Sites including a mandatory HA SQL set-up per Site: not ideal.
This also meant no more Zone preference (failover) policies, Local Host Cache (LHC) and Load Balance policies were now applied at Site level. Oh, and did I mention that Worker Groups were taken from us as well? Luckily with the release of version 7.7 Zones were reintroduced (no Worker Groups and LHC, though). However, note that these new types of Zones work differently from what we are used to with XenApp 6.5.
Another example would be power management, especially from a XenApp perspective; this is still far from ideal even within 7.8. Other fundamental and permanent changes include more IMA protocol and service: these are now replaced by the earlier mentioned VDAs (Virtual Delivery Agents), which are installed on Session Hosts’physical and virtual servers and desktops. A much more lightweight approach as opposed to the IMA (where XenApp was basically installed on each system)even when compared to the former ‘Session only mode’ in XenApp 6.5, more on this as we progress.
The FMA supports multiple Operating Systems like Windows Server 2012 R2andWindows 8, 8.1 and 10, and the best thing is you can configure multiple Machine Catalogs with different Operating Systems. Which is different from XenApp 6.5 where the whole Farm needed to run the same server OS. Also, the Delivery Controller can run a different OS to the Session Hosts / VDAs it will communicate with. 2018 update: Server 2016 and multiple versions of Windows 10 are also supported.
While most of these changes primarily impacted XenApp, some impacted XenDesktop as well–positively, I might add. The FMA was always designed with VDI in mind so when XenApp was added, as mentioned some fundamental architectural changes were needed.
Today this means that, depending on your license, you will install either XenApp and/or XenDesktop, with XenDesktop giving us the full suite of options including hosted shared desktops, published applications and the ability to auto-provision server machines using MCS and/or PVS, things we couldn’t do before. And of course, the same applies to Zones, a first for XenDesktop.
No more separate infrastructures for desktops and applications, it is one install, architecture and console (Citrix Studio) to meet all of your delivery needs. It includes several workflows, which simplify and speed up the process of delivering (virtual) desktops, hosted shared desktops and applications to users. Delivery Agents in XenDesktop / XenApp 7.x are configured via policies. Any combination of Active Directory GPOs, the Studio console (HDX Policies) and local GPO settings can be used.
Citrix also had to come up with a new type of VDA, one for server Operating Systems. The one they had now was exclusively designed for desktop machines. The biggest difference between the two VDAs is the underlying ICA protocol stack. For desktop machines, a single-user ICA stack (a.k.a. PortICA) is used which allows only one ICA session at a time. It includes additional HDX features such as USB and Aero redirection, which are only available on a single-user machine. For server machines, Citrix now includes a multi-user ICA stack extending the Windows Remote Desktop Services with the HDX/ICA protocol. This is basically the same ICA protocol stack as developed for Citrix XenApp (6.5 and earlier releases) with some technical adjustments to make it compatible with XenDesktop / XenApp FMA Delivery Controllers. Both will be discussed in more detail at a later stage.
FMA fact: There is also a Linux-based VDA.
While the FMA is under constant development, bringing back XenApp specific features and extending the reach of XenDesktop, this also helps in making the FMA the most flexible and robust platform known today: everybody wins.
FlexCast, a core part of the FMA, offers you several delivery models (methods to deliver an application or desktop to your users). It is designed to support all types 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: this is where FlexCast comes in.
Another example, so-called Road Warriors, need access to their desktop from anywhere. Here a hosted VDI or hosted shared desktop might do the trick, again… FlexCast! Of course, it’s all up to you: you decide which model best suits the use case at hand! It is more of a strategy for delivering desktop and applications than anything else. FlexCast offers you the following desktop delivery models:
- Hosted shared desktops, non-persistent.
- Hosted VDI, random non-persistent, static non-persistent and static persistent.
- Remote PC (physical PCs only).
- Streamed VHD, PVS.
- Local (existing) virtual machines.
- On-demand (published) applications.
To finalize I’ll include an overview (see next page) of all major components available within the IMA vs. the FMA. Be aware that not every component and/or concept delivers the same features and/or functionalities as its counterpart.
Note: To avoid any further confusion, as of now where I say XenDesktop I also mean XenApp and vice versa as part of the same FlexCast Management Architecture.
IMA vs. FMA
- Both XenApp and XenDesktop are built and based on the FlexCast Management Architecture(FMA). And I am pretty sure it will stay like this for many more years to come. 2018 update: even Citrix Cloud is primarily based on what we know from on-prem as well.
- The FMA was first introduced with XenDesktop version 5.0 back in December 2010. Before that, XenDesktop was also based on the Independent Management Architecture (IMA).
- XenApp became part of the FMA on June 26, 2013, which was the official GA date of XenDesktop 7.0.
- The FMA was initially built with VDI in mind.
- This also meant that XenApp was no longer available as a separate product and that they (Citrix) also decided to stop any further development regarding 6.5.
- Luckily, Citrix listened and reintroduced XenApp and XenDesktop as separate products with the release of version 7.5. I don’t think they will make a mistake like that again.
- With the addition of XenApp to the FMA, a new (server) VDA was needed.
- The FMA was always meant to be the next generation architecture, providing enhanced scalability, robustness, flexibility and manageability over the IMA.
