Citrix - 2.4 IMA

IMA, which stands for Independent Management Architecture, is the framework that XenApp historically relied on for server-to-server communication. Understanding IMA matters because XenDesktop 7.6 represents the convergence of XenApp and XenDesktop, switching from IMA on the XenApp side to FMA (Flexcast Management Architecture) on the XenDesktop side. Many XenApp administrators have been using IMA for more than ten years, so seeing what it does and where its limits are makes the transition much clearer.

At its core, IMA provides a framework for communication between XenApp servers so they can act as a group. It is not only server-to-server; you can also plug subsystems into the IMA base to handle exceptions, security and privacy concerns. If a XenApp server does something, the other XenApp servers know about it. By default IMA runs on TCP port 2512, and members exchange messages over that channel.

The problem with IMA

• IMA must be installed on every XenApp server, so every server is also a controller.
• Among all controllers, one is elected as the data collector, holding slightly more information than the others.
• If one server fails, another takes over as primary controller for that zone.
• Because the framework lives on every server, mixing versions (XenApp 5, 6 and 6.5) inside the same farm is hard: a full upgrade is required to move forward.
• There is no clear separation of roles: every server is both a worker and a controller.

This is why Citrix replaced IMA with FMA, which is much more flexible: with FMA you have a Delivery Controller role separated from the workers, infrastructure servers can be plugged in without installing everything on every box, and multiple versions can coexist more easily. We will cover FMA in the next video.