XenDesktop^? 2.0 and Independent Management Architecture (IMA)

It's very important for the XenDesktop masters to know how XenDesktop worked in its previous versions and the pros and cons that led to the changes in its architectural design. We'll go through an overview of the IMA and discuss the data points on how it was before IMA, since it's closely related to XenApp.

In 2008, the initial version of XenDesktop 2.0 was built on Citrix's pre-existing flagship technologies, including the networking protocol and architecture. It featured the following:

• The PortICA (now HDX) extended the ICA protocol for client to server communication. The ICA protocol for Windows was introduced in 1990. The PortICA allows only a single ICA session at a time whereas ICA protocol supports multiple concurrent ICA sessions to RDSH in XenApp.
• The IMA was introduced with Citrix MetaFrame XP (now called XenApp) for internal server management in 2001.

Prior to IMA, in the versions before MetaFrame XP, the server configuration settings were saved in the registry. They have been replicated across the MetaFrame servers by the ICA Browser Service (installed on each server locally) through the UDP broadcasts and remote calls. The MetaFrame XP was launched with IMA in which IMA replaced the ICA browser service. It had features such as:

• Data store: An ODBC compliant database, which contained the configuration settings of all the MetaFrame servers, including licenses, zone configurations, printers and drivers, published apps, load evaluators, trust relationships, and so on. These are accessible to all MetaFrame servers.
• A protocol: It is a TCP-based event-driven messaging bus, and it is used for transferring the ever-changing background information among the MetaFrame servers, and these include the server load, the current users and connections, and the licenses that are in use. It uses port 2512 for server to server communication and port 2513 for management console communication with the data store.

The IMA for XenDesktop had the following scalability limitations:

• Single Farm Master: the IMA constitutes a master desktop delivery controller for the zone, and it is referred to as the Farm Master. It has specific duties that only it can perform. The duties include handling all the connection requests from the users, performing desktop resolution operations during desktop startup, managing the backend hosting infrastructure, and so on. This has caused Farm Master to become a bottleneck in large enterprise deployments, as the desktop groups grow. Furthermore, a Farm Master can't be scaled out by adding more servers. It can only be scaled up by upgrading to a system with higher processing power.
• Proprietary database: the IMA data store was built on the proprietary database structure, that is, it has evolved from its legacy, the MetaFrame technology, which was based on encrypted LDAP. It was not built on the SQL features or capabilities though it supports the SQL database as a container. The IMA data store has not been designed for scaling thousands of desktops and for holding a huge configuration data. IMA caches the data store locally on every XenDesktop server as Local Host Cache (LHC). As the desktop count grows, the data that has to be replicated for each member controller server LHC increases, thus affecting performance and scalability.

The following figure is an architectural diagram of XenDesktop with IMA: