Advanced FMA - the XenDesktop^? architecture in detail

So far, we have learned about the FMA components, concepts, and features. We'll now pe into FMA, representing the positioning and functioning of its components and their communications, which deliver the virtual desktops to the end users.

FMA exhibits elasticity and expandability by design. It supports the components across the varying infrastructures. These features reflect in its layered/modular architecture by grouping the common components to ease the understanding of the overall communication flow. The modular architecture consists of the five layers that cover all the key design decisions. This makes it easier for the architects to focus on the technologies involved in each layer of the overall architecture, it also helps in streamlining their assessment and design decisions. In the image shown later, you can see a high level description of FMA, its five layers, and their importance.

The five layers of FMA

We'll start with the conceptual diagram of FMA representing all the five layers along with the respective components, as shown in the following figure. This will help you in understanding the positioning of the FMA components within the scope of the FMA layers that we will be discussing in this section:

The following image shows the logical representation of the five layers of FMA at a high level:

The following is a quick description of each layer of FMA:

• User layer: It is the top layer that defines the recommended strategies for the end-point devices and the Citrix receiver for them. The assessment criteria used in this layer primarily assesses the business priorities and the user group requirements. The decisions made in this layer impact the flexibility and functionality of each user group.
• Access layer: Defines user's access to the virtual desktops. It handles the user validation, and orchestrates access across all the components involved in establishing a secure virtual desktop session. Decisions in this layer are based on the mobility requirements and the end-points used across the user groups. Decisions include choosing between options, such as local versus remote access, the firewall and the SSL secured access.
• Desktop/resource layer: Defines the user's virtual desktop. This layer is pided into three sections, and these are personalization, application, and the overall desktop image. These include the FlexCast model, the application requirements, the user policy, and the profile requirements. These decisions play a key role in the user acceptance of the chosen virtual desktop.
• Control layer: In this layer, all the decisions related to the management and the maintenance of the overall solution are defined. The control layer components include the access controllers, the desktop controllers, and the infrastructural controllers. The access controllers support the access layer, the desktop controllers support the desktop layer, and the infrastructural controllers provide the underlying support for each component within the architecture. Determining the capacity, the configuration, the topology, and the redundancy for the respective components creates a control environment capable of supporting user requirements.
• Hardware layer: This is the last layer and it comprises of the physical devices required for supporting the overall solution, including the servers, the processors, the memory, and the storage devices. The devices are grouped and they are classified into three groups for allocating the resources to specific parts of the entire solution, such as the first group of servers for XenApp and its components, the second group for the XenDesktop components, and the third group for supporting the underlying infrastructure of the control layer components.

The first three layers are defined for each user group. They specify the user's virtual desktop characteristics, and how they access them. This is derived by assessing the business user group's requirements. The architects should thoroughly understand the various factors of the user requirements, including the type of applications, their compatibility, the criticality of the data, nature of employment, access locations, performance requirements, and so on. Then, decide the respective type of desktop that would be appropriate for them.

Based upon the decisions made in the first three layers, the back end foundational layers are designed for the entire solution. The aforementioned defined layered process streamlines the design thinking such that the decisions made in the first three higher level layers impact the design decision made in the two lower level layers.

Working of FMA components to deliver virtual desktops

The following is a sequence of steps that takes place at the high level for delivering a virtual desktop session to the end user, in single site XenDesktop deployment. For starting a XenDesktop session, a two phase process takes place in the background.

Phase 1 - User authentication and resources enumeration

The sequence of actions shown here take place during phase 1:

1. The user logs into the StoreFront web store URL.
2. StoreFront validates the user credentials with the help of the Active Directory domain controller.

   Tip

   This is a new step in this process and it was introduced in StoreFront. This step was not performed in the web interface.

3. Upon successful authentication, StoreFront will check the application subscription data store for the existing user subscriptions and then store those in the memory.
4. StoreFront will forward the user credentials, as a part of the XML query, to the controller.

   Tip

   To secure this sensitive information over the network, it's recommended that you configure the StoreFront site to use the secure SSL connections so that the user credentials are encrypted, while they reach StoreFront from their device.

5. The controller will query Microsoft Active Directory with the end user's credentials to verify the user authorization. That is, the controller will fetch the user security group memberships to find the resources that the user had access to.

   Tip

   Active Directory validates the credentials and issues a Kerberos authentication token for the user. This token will be valid for a defined period of time and it can be re-used across any of the Active Directory domain resources for authenticating the user against. For further reading on the Kerberos authentication in Windows, please refer to the topic, How the Kerberos Version 5 Authentication Protocol Works, which can be found at https://technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx.

6. Upon successful validation, the controller will query the user security group memberships.
7. The controller will then query the site database and then determine which applications and desktops the user will be allowed to access.
8. The controller sends an XML response to the StoreFront site, which contains the enumerated list of all the resources (desktops or apps) that are available for the user within that XenDesktop site.
9. The StoreFront web store pages display the desktops and the applications, which the user can access.

Phase 2 - Virtual Desktop allocation and connection establishment

The following image displays the sequence of actions that takes place during phase 2:

1. The user selects an application or a desktop from the list.
2. StoreFront passes the user resource selection to the controller.
3. The controller queries the status of the desktops within that group. It determines the proper VDA for hosting a specific application or a specific desktop. Then, it communicates the user credentials and all the data about the user and the connection to the VDA.
4. The VDA of the selected desktop accepts the connection and then sends all the information that is needed for establishing the session back to the controller.
5. The controller forwards this connection information to the StoreFront site.
6. StoreFront delivers this information to the receiver.
7. The receiver combines all the connection information generated in the session request and saves it in the Independent Computing Architecture (.ICA) file on the user's device. If the receiver is not available on the client's device, then the receiver for the web will handle this activity.
8. Using the saved connection settings in the.ICA file, the receiver establishes a direct connection between the user's device and the ICA stack which runs on the VDA. This connection bypasses the entire management infrastructure, including StoreFront and the controller. This connection takes place over the ICA port 1494 on the virtual desktop. It will take place over the Citrix Gateway Protocol (CGP) port 2598, if the session reliability is enabled.
9. Once the user connects to the VDA, the VDA will notify the controller about the logged in user.
10. The controller will write this connection information into the site's database and then it will start logging the data into the monitoring database.