XenDesktop 7.x Controller Services

There are overall 11 core FMA services in every citrix site. Note: Citrix Analytics has been introduced with XenApp and XenDesktop 7.6 (Customer Experience Improvement Program - CEIP).

All services run independently of each other, so a failure of one service will not cause a disruption in the functionality of any other service(s). But not all services are equal – we can logically divide services into three different groups:

• Core Services – These services are essential for functionality of an FMA site.
  • CCS – Central Configuration Service acts as a centralized directory of all FMA services.
  • CLS – Configuration Logging Service is critical, because it needs to be involved in all changes to the environment to make sure that they’re recorded in central database.
  • DAS – Delegated Administration Service is also crucial, because it needs to determine if current user has required privileges for every call he is making.
• Desktops\Apps Services – MCS, brokering, hypervisor (host) and AD identity services are all required for provisioning of desktops or applications.
• Support Services – Analytics, StoreFront, Environment Testing and Monitoring services are considered supporting services.

Each of the FMA services has a set of accompanying cmdlets that you can use. You can use the following table to get list of cmdlets (use Get-Command to display all exported cmdlets). This table is one of the job aids that we’re providing with CXD-302 (quick fact sheets or reminders).

FMA Services	PowerShell prefix	Description
Broker Service	Broker	Brokers new session requests, handles disconnected sessions and resource enumeration, processes STA ticket verification and user validation. Additionally, it handles all communication to and from the VDA desktop.
Machine Creation Service	Prov	Handles the creation of new virtual machines (not physical machines).
Configuration Service	Config	Handles all inter-service communication between FMA services.
AD Identity Service	Acct	Handles all Active Directory accounts related to any XenDesktop virtual or physical machines.
Hosting Service	Hyp	Manages all connections XDC, and the Hypervisor; supporting vSphere, XenServer or SCVMM. Responsible for power management.
Delegated Administration Service	Admin	Manages the creation, configuration and administration of all delegated administrative permissions.
Monitoring Service	Monitoring	Monitors the overall FMA architecture and produces alerts and warnings when it finds something is potentially wrong, such as a failing service.
Environment Test Service	EnvTest	Manages tests for evaluating the state of XenDesktop infrastructure.
Configuration Logging Service	Log	Monitors and logs all configuration changes made within a XenDesktop site, to include all administrator activity.
Analytics Service	Analytics	Collects analytical data from Citrix products.
StoreFront Service	Sf	Manages the StoreFront deployment.

CCS configuration information is stored in central site database and is pulled by FMA servies every 5 mins. As you can imagine, this could generate a lot of traffic, so each of the FMA services will keep a cache of CCS directory for five minutes. Quick tip – if you ever need to refresh the cache, just restart the Windows service, as cache is retrieved during the startup of the service.

All FMA services need to register with the configuration service on start-up so that it knows they are all good to go. This is one of the main reasons why the CCS has such a prominent role, it handles all inter service communication within the FMA. Located at the center of the FlexCast Management Architecture it holds and manages a list of all FMA services, allowing them to advertise their WCF addresses, or endpoints including the functionality that they provide. Only after a service successfully registers with the configuration service, when adding in additional Controllers, after a reboot or during Site creation for example, will it become active and able to communicate with other FMA Site services. Once done, the configuration service will share a listing of all active and registered services as being active Site members.

As soon as an individual service successfully queries the listing, this information will be cached for five minutes. As a side note, the Machine Creation Service and the Machine Identity service both communicate through the Host service to find out about the configuration, and connections of the hypervisor, including the storage and network configurations needed for virtual machine provisioning. This information will be stored for one minute as opposed to the five minutes mentioned earlier. Each FMA service can query the CCS to look up other services using the listing mentioned earlier, including their functionalities that they require to use. In short, service registration and communication are all relying on :the configuration service. As a side note, it will also store configuration meta-data for all services.

Services communication:

All the services are independent with each other i.e., if one service is down, others still work. Every service communicates directly with the site database using database connection string and updates the database with the info from that service.

Configuration logging and monitoring databases contact their own databases to update the info from their services.

FMA services communicate using WCF i.e., each service contacts other using URL endpoints for each service. Configuration service maintains WCF addresses that is centrally managed and maintained.

Central configuration instance is stored in site database. Each delivery controller in a site maintains local cache of configuration service instance. This cache is updated every 5 mins or at service startup. This cache prevents configuration service on each delivery controller having constantly query the site database.  When a service need to contact other, the initiating service queries the configuration service for WCF address of target service. Configuration service checks the local cache copy of configuration service directory and provides the target address to initiating service. Each service maintains its own local cache of WCF address which reduces no of calls made to configuration service.

Let’s see this with an example:

Let’s say broker service need to contact host service to know the status of a vda. Broker service contacts configuration service to get the WCF address of host service. Configuration service validates if broker service is registered with the directory (i.e., if it is within the site). Once validated, configuration service returns host service WCF address to broker service. Then broker service contacts the host service.

If you want to reset CCS, you can use powershell script given here: Download

Note: Please use this script at your own risk.