Although the new 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…
Although 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. Of course similar functionality does exists but is handled by different components and services.
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 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 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. I guess some things never change.
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.
That’s all I have for now, I think this should give you a good idea on how things work / interact with regards to the newly introduced Server VDA as shipped with the FMA. Like last time I would like to thank Mick Glover (@XDtipster) on helping me out on this one, I know how busy he is, thanks again Mick!