Before we talk about FMA, let’s have a bit of a review on IMA first. If you’ve worked with any of the Citrix products before, I am sure you’d be familiar with IMA(Independent Management Architecture) and ICA (Independent Computing Architecture). ICA being the protocol used by the end points and IMA, the framework used for management and communication between the XenApp hosts.
Just like with any framework, there are a set of components that make up the IMA architecture, those components are:
Data store – contains configuration information about the farm
Local Host Cache – locally stored cache on each of the XenApp hosts
Data Collectors – A database, typically within the memory of the hosts that dynamically keeps track of data about the servers in its zone, such as sessions, published apps, connected users, etc
Personally, I think the IMA over complicated certain aspect of XenApp, but at the same time, I do have to admit, that with the later version of XenApp, such as XenApp 6.5, the installation, configuration, and even troubleshooting became a lot easier. The XenApp 6.5 environment was also the most stable, at least from my experience. You surely be interested in this site. I will also point out, that being a XenApp administrator is a lot more than just knowing each of the components that make up the framework, you also have to be very comfortable with GPOs and easily maneuver around Windows Operating System so that you could provide your users a very pleasant working environment.
Now, let’s talk about FMA.
FlexCast Management Architecture Overview
FMA is not new, it was actually used by earlier version of XenDesktop, but going forward with the release of XenApp / XenDesktop 7.x, FMA was the chosen architecture for both platforms. In fact, if you’ve installed the most recent versions of XenApp / XenDesktop, you’ve probably noticed that it’s basically the same thing which, in essence is great because that means that the applications and virtual desktops can be coupled together to provide a better user experience.
So what is FMA? How’s it different?
Well, the main difference comes from how we manage the two products. We are no longer working with Zones and Zone data collectors, instead the focus is now on sites. Every location can be a site. Let’s say for example, the company headquarters and their respective DR location. We would deploy a site in HQ and a site in DR and use StoreFront to aggregate the two, in other words, StoreFront will be aware of the two sites and service users accordingly.
With FMA, we are also changing the way we deploy applications. We now deploy VDAs (Virtual Delivery Agents) on to the servers that will be either a virtual desktop or host applications. What I love about this, is that we can use different version of Windows, for example Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 and they all can be part of the XenApp/XenDesktop application farm. So, if you have applications that can only be hosted on Windows Server 2008 R2 due to comparability or other reasons, no biggie, just deploy a VDA on to a Windows Server 2008 R2 and publish your apps.
The other interesting aspect of FMA, is MCS (Machine Creation Services) which allows us to provision a large amounts of virtual machines on the fly. Of course, there’s a better product, or should I say a more robust product from Citrix called Provisioning Services, which in essence does the same thing, but with a lot more control, performance, and options. We’re going to be talking about PVS later in the series.
Here’s a reference architecture of FMA from Citrix