Ever since the introduction of XenDesktop 7, where the FMA took over and XenApp was integrated, a lot has been written with regards to its components, services, agents and so on. What surprises me though, is that the Server VDA is (almost) never mentioned, while this is, or at least was a brand new component. Never before was it optional to install a (relatively) lightweight agent onto a XenApp server, it was basically all or nothing.
Although the (new(ish) FMA based Server VDA has been built from the ground up it still has a lot of similarities when compared to the ‘old’ ICA protocol stack deployed with XenApp 6.5 and earlier versions. However, unlike XenApp, the VDA (Virtual Delivery Agent) directly communicates with the Delivery Controller, it does this through the Broker Agent, basically the same way as we are used to with the desktop VDA (PortICA).
Before we move on…
While not directly related, the PortICA service, now referred to as PicaSvc2.exe as of XenDesktop 7, does not represent the whole ICA stack within a Desktop VDA, it ‘just’ controls it. The ICA stack, and this goes for the RDP protocol stack as well, is made up out of a whole bunch of different components all running and interacting within kernel mode.
As opposed to the Desktop VDA, which has been around for a couple of years now, there is no PortICA service within a Server VDA, it simply doesn’t exist.
VDA vs. VDA
One of the biggest differences between the Server and the Desktop VDA is its ability to accept and manage multiple users sessions at once, hence the RDSH (XenApp) model. Where the Desktop VDA, also referred to as PortICA, can only handle one ICA session at a time. Server VDA’s communicate directly, and exclusively with the Delivery Controller and as such they do not need access to the Central Site (SQL) Database or license server.
Also, the underlying OS of a RDSH / XenApp server does not have to be the same as that of the Delivery Controller. And of course we can use multiple Operating Systems throughout our Site if needed or desired. As mentioned, for server machines Citrix now includes a multi-user ICA stack, which extends the 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 XenDesktop 7.x controllers.
An overview
Although I won’t go over all the components and services listed in the below image, at least not today, it does give you a nice overview of the FMA in it’s current (2015) state. For the sake of this article I only included the Server VDA. The orange RDS / Termsrv square corresponds to the XenDesktop / FMA image, which you will find if you scroll down just a few inches.
This is what happens during installation
During Server VDA installation one of the things it will do is register the Broker Agent Service (used for direct communication with the Delivery Controller), which is similar to the Desktop VDA process. Next it will install the multi-user ICA stack, as it does with earlier XenApp versions, which will then become part of Termsrv creating the so called ICA stack listener waiting for new ICA connections (kernel mode).
The ICA stack itself has changed very little with the introduction of the FMA, one of its biggest changes is to be found in its communication interface, which is now better known as the earlier mentioned Broker Agent.
Last but not least it will install and configure the Citrix Stack Control Service, this is its display name within the Windows services overview. As you will see in the graphical overview below, the above mentioned (Citrix) StackControlService, a.k.a. SCService64, will act as an interface between the Broker Agent (a.k.a. BrokerAgent.exe and part of the new FMA) and the ICA stack running in Termsrv, mapping a direct COM interface between the two.
So to a certain extent you could say that the SCService64.exe takes on a few of the responsibilities, which are similar to those of the PortICA service in a Desktop VDA. Obviously this is new behavior and was first introduced with XenDesktop 7 (FMA 2.0). The same can be said for the PortICAsvc.exe as part of XenDesktop 5.x, as of XenDesktop 7 it has been slightly altered and renamed to PicaSvc2.exe.
Each Terminal Server protocol (like Citrix’s ICA) will have a protocol stack instance loaded (a listener stack awaiting a connection request). When installed, the Server VDA basically extends Microsoft’s RDS protocol with the HDX feature set / protocol.
To make life a bit easier with regards to troubleshooting these services I would suggest you have a look at Scout, which is installed as part of your Delivery Controller by default. Check out this post to get started.
Although similar, still different
Although the above might show a lot of similarities to the way the ICA stack and communications functioned with earlier XA versions, the Server VDA is much more simplified and light weight when compared to earlier XA/ICA installations (although I believe it’s still over 300 MB in total).
It now solely consists out of the components needed to host sessions and as such it doesn’t share any of the other components and services installed on the Delivery Controllers, which wasn’t the case with 6.5 and before.
Let’s round things up with a Server to Desktop VDA comparison / recap overview.
Disclaimer
This article is based on one of my earlier posts on the Server VDA and has been re-written. It now also falls under the FAM Internals Co-Op flag. As always, a big thank you to Mick Glover for filing in some of the blanks.
One response to “An in-depth look at the Citrix FMA Server VDA… The one that (almost) got away!”
Nice Article Bas!