12 services that make up the Citrix XenDesktop Flex Management Architecture!

The Flex Management Architecture is a service-orientated architecture, it consists out of ten, or twelve depending on your point of view, primary services in total. Let me explain, when administering a Virtual Desktop Infrastructure (VDI) for example, the Broker Service, a.k.a. the Desktop service, and the PortICA service both live on your desktop OS based VM’s, which are then part of the FMA as well, making it twelve services in total. Here I’ll provide you with a rundown of all services that make up the FMA including their responsibilities and some background information. I’ve included some artwork as well.

Let’s just call it FMA from now on and use the product technology stacks, XenApp (HSD or SBC) and XenDesktop (VDI), to indicate what will be delivered to our users.

The overview

The Delivery Controller as part of XenDesktop is the hart of your FMA. It communicates with Studio, Director, the central Site database and the VDA’s installed on the virtual and physical machines in our datacenter. Once installed and set up it consists out of ten primary services on our DC, and twelve services in total when running a virtual desktop infrastructure (VDI), with two additional services running on each of your desktop OS based VM’s. These FMA services combined will communicate with the underlying Hypervisor, the virtual machines, the DC, and be responsible for the creation of new machines, delegated administration, configuration logging, services interaction and more. An overview…

1. Broker (XML) service (a.k.a. the Desktop service) – Probably the best known one. From a Delivery Controller point of view it brokers new sessions, handles resource enumeration, the creation and verification of STA tickets, user validation, it handles disconnected sessions and so on and so forth. From a Desktop OS VDA point of view (Desktop service) it handles all communication from and to the Delivery Controller.
2. Configuration service – All FMA services need to register with the configuration service on startup so that it knows they are all good to go. This is one of the main reasons why the Configuration service is such an important one, it handles all inter service communication. One we can’t do without.
3. ID Identity service – It handles all Active Directory computer accounts related to XenApp / XenDesktop virtual and physical machines.
4. Configuration Logging service – It monitors and logs all configuration changes made within a XenDesktop Site, including all Administrator activity. Depending on its configuration, no Site changes are possible when its database is unreachable. The data itself can be stored as part of, or within, the central site database or a separate database can be created.
5. Delegated Administration service – This one manages the configuration and administration of all delegated administrative permissions. If this service becomes unresponsive or unavailable it won’t mean that Site management isn’t possible, it just means that no new, or existing, administrative accounts can be created or re-configured.
6. Machine Creation service – Handles the creation of new virtual machines. When this service is unavailable no additional virtual machines can be created. Also note that MCS is only capable of creating virtual machines, not physical. If you need to service physical machines you will need to implement Provisioning Services.
7. Host service – Manages all connections between the physical hosts, the Delivery Controllers, and the underlying Hypervisor. This can be either vSphere, XenServer or Hyper-V. This is where your virtual Server and/or Desktop VM’s live. Physical machines are still optional as well, but again, you’ll use PVS instead of MCS.
8. Environment Test service – Manages tests within your XenDesktop Site, can be initiated from Studio for example.
9. Monitor service – Monitors the overall FMA architecture and produces alerts and warnings when it finds something is potentially wrong. These will pop up in Studio or Director for example. Due note however, that although these alerts will tell us that something is potentially wrong, with regards to one of our primary FMA services for example, they won’t tell us what is wrong or where to look for answers. Therefore FMA services are best checked using PowerShell.
10. StoreFront service – Manages your StoreFront deployment which can be managed from Studio as well.
11. The Desktop service (a.k.a. the Broker service) – This is the first of the two Desktop OS based FMA services. It communicates with the PortICA service and the Delivery Controller exchanging ‘pre logon’ ticket data and user credentials as part of the user authentication en verification process within a virtual desktop infrastructure.
12. The PortICA service – Here’s number two. The PortICA service has been renamed to PicaSvc2.exe as of XenDesktop version 7.x and is also referred to as the ICA service. It will accept the initial connection, lock the workstation, it will communicate with the display manager to change the display mode to remote ICA, this request will be forwarded to the Thinwire driver. To finally communicate with the Desktop service, see bullet 11.

7.1 They are all independent

All FMA services run completely independent of each other, so if one goes offline it won’t directly affect any of the other services. Although each service points to the central Site database, they all have an independent location in the registry, meaning that their connection strings to the database are all stored separately from each other, eliminating any single point of failures.

All FMA services run under the NT AUTHORITY\Network service account. Also, when authenticating to the central Site database, all services use the local computer account of the machine that they are currently running on.

There is always a but…

Of course there is a but… If one, or multiple, of the FMA services experience some kind of issue Director will popup an alert telling you that something is wrong. It will tell you which service is affected and at what time it happened, but it won’t tell you what is wrong or where to look for answers. If you use PowerShell to check up on theses services, not only will it tell you that something is wrong, but it will also tell you what is wrong, or at least point you in the right direction. And also, Director doesn’t monitor all FMA services by default, using PowerShell you easily can!

Here are a few examples to check some of the more important FMA services:

• Get-BrokerServiceStatus
• Get-ConfigServiceStatus
• Get-HypServiceStatus
• Get-AcctServiceStatus
• Get-ProvServiceStatus

When using a central management server, I would suggest to create a personal PowerShell profile, including some of these basic Get- FMA service checks. This way, every time you open PowerShell these checks will be done on all, or a subset, of the primary FMA service before you continue, depending on how many and which commands you include of course. If you look at Director for example, on the main administrator dashboard, there you will also see your Delivery Controllers listed at the bottom of the screen. If all is well, green checkmarks pop up next to them. This is also PowerShell issuing Get- commands in the background.

A few more things…

Although the above will probably be more than sufficient, another option would be to make these Get- Commend-lets part of your SCOM environment, using a custom script, and let them execute every two to five minutes for example. But this might be considered an overkill.

Another thing to mention is that both Studio and Director run on top of the PowerShell SDK as well. Everything you can do within Studio can also be done through PowerShell and vice versa. In fact, using PowerShell gives you a whole bunch of extra configuration options not available using ‘just’ Studio. But more on that in a future post.

When using PowerShell I suggest that you use the PowerShell management console build into Citrix Studio. This has the added advantage of not needing to load any specific CTX snap-ins and/or modules before you start. Assuming you don’t already have a PowerShell profile configured of course.

When you check your Delivery Controllers in Studio, you’ll see a number in minutes next to each Controller that indicates when the Delivery Controller has last registered itself with the central Site database. This number should always be 0. By default the Controller checks in every 20 seconds, which will then be valid for another 40 seconds.

Part of the -1000 blog series.

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.