FMA vs IMA: Do You Know The Difference?

Written by Jas Singh in citrix

In the world of Citrix technologies, the terms FMA (FlexCast Management Architecture) and IMA (Independent Management Architecture) are foundational, and understanding the difference between them is essential. These two architectures represent Citrix’s shift from legacy systems to modern management solutions, with significant implications for how Citrix environments are configured, managed, and scaled.

What Is FMA?

FMA is the current management architecture used by Citrix products like XenApp and XenDesktop. It stands for FlexCast Management Architecture and is now the core architecture for all Citrix Virtual Desktop Infrastructure (VDI) products. FMA was introduced in XenDesktop 5.0 (for VDI environments) and became the standard for XenApp in XenDesktop 7 App Edition.

FMA’s evolution was designed to provide a more scalable and flexible architecture that integrates better with modern data center requirements.

What Was IMA?

IMA, or Independent Management Architecture, was the management framework used in older versions of XenApp (up to XenApp 6.5) and its predecessors like Presentation Server and MetaFrame. IMA used a different structure for database management, high availability, and handling user sessions compared to FMA.

Key Differences Between FMA and IMA

1. Database Management

  • IMA: In IMA, a central database called the IMA Data Store housed all persistent configuration information. This could be stored on Microsoft SQL, Microsoft Access, or Oracle databases. Each XenApp server also had a Local Host Cache (LHC) that contained a copy of the IMA Data Store relevant to that server.
  • FMA: FMA also uses a central database, but it is hosted on a Microsoft SQL server and is critical for storing persistent configuration data. Unlike IMA, FMA relies on Connection Leasing to allow limited operation when the database is unavailable.

2. Boundary Concept

  • IMA: In IMA, the concept of a Farm was key. Each farm could be divided into Zones, and each zone had a Zone Data Collector responsible for managing dynamic data like server loads, session statuses, and published application details. The Zone Data Collector made decisions about which XenApp server users would be directed to.
  • FMA: In FMA, the boundary concept is a Site rather than a farm. Controllers in an FMA site maintain dynamic information similar to IMA’s Data Collectors, but there is no concept of zones. FMA uses Site Controllers to pull configuration data from the SQL database and make session routing decisions.

3. High Availability

  • IMA: High availability in IMA was managed through the Local Host Cache (LHC). If the IMA Data Store became unavailable, XenApp servers would rely on their LHC to provide connection information to the Zone Data Collector, ensuring that users could still access published applications. However, while in this mode, administrators couldn’t make changes to the configuration.
  • FMA: In FMA, high availability is managed through Connection Leasing. This feature caches user connection information for up to two weeks, allowing users to access recently used applications and desktops if the SQL database goes offline. However, like IMA, configuration changes are not possible while operating in this mode.

4. Controllers and Collectors

  • IMA: In IMA, Zone Data Collectors were responsible for collecting information from the IMA Data Store and managing user connections based on server loads and availability. Every XenApp server also relied on its Local Host Cache to provide connection data in the event of a database failure.
  • FMA: In FMA, Controllers pull information from the central SQL database and use it to direct user connections to the appropriate XenApp or XenDesktop server. When the SQL database is unavailable, Connection Leasing steps in to handle user connections for recently used applications.

5. Local Host Cache (LHC) vs. Connection Leasing

  • IMA: In IMA, each XenApp server had a Local Host Cache (LHC) that stored configuration data locally. This was updated every 30 minutes and used if the central database became unavailable. The LHC was essentially a local Microsoft Access database that allowed servers to continue functioning without access to the IMA Data Store.
  • FMA: In FMA, the Local Host Cache was replaced by Connection Leasing. Instead of storing a complete local copy of the database, the Site Controllers cache user connection details for the last two weeks of user activity. This allows users to reconnect to recently used applications and desktops even if the SQL database is temporarily unavailable.

6. Scalability and Flexibility

  • IMA: The IMA architecture, while powerful for its time, had limitations in terms of scalability. Adding more users and applications could lead to issues with the Zone Data Collectors, and managing large environments could be complex.
  • FMA: FMA was designed to address these scalability concerns, providing a more modern, cloud-ready, and scalable architecture. It integrates well with cloud environments, supports higher numbers of users, and offers improved management tools through Citrix Studio.

Key Features of IMA Architecture

  • IMA Data Store: Central repository for configuration data.
  • Farm and Zones: Boundary for XenApp servers, further divided into zones.
  • Zone Data Collector: Managed dynamic information for user sessions.
  • Local Host Cache (LHC): Local database for high availability.
  • High Availability: Relied on LHC when the IMA Data Store was unavailable.

Key Features of FMA Architecture

  • SQL Database: Centralized management database on Microsoft SQL Server.
  • Site: The new boundary concept replacing the farm and zone model.
  • Controllers: Manage user sessions and dynamic information.
  • Connection Leasing: Caches user connection data for high availability.
  • High Availability: Provides access to recent apps and desktops when the SQL database is down.

Conclusion

The transition from IMA to FMA represents Citrix’s response to modern enterprise needs for scalability, cloud integration, and simplified management. FMA brings enhanced features like Connection Leasing, centralized management via SQL, and more efficient handling of resources, making it the architecture of choice for today’s XenApp and XenDesktop environments. Understanding the difference between these architectures is essential for Citrix administrators managing legacy systems or migrating to newer Citrix solutions.

Recent Posts