How Citrix MetaFrame XP Works

In order to understand how MetaFrame XP really works, we need to look at the components that make up a MetaFrame XP server.

In order to understand how MetaFrame XP really works, we need to look at the components that make up a MetaFrame XP server. Because MetaFrame XP is an add-on product to Microsoft's Terminal Services (the required multi-user operating system), we need to understand how Terminal Services works and interacts with MetaFrame XP before we can examine the actual MetaFrame XP components.

How Microsoft Windows Terminal Server Works

We mentioned in Chapter 1 that MetaFrame XP is an add-on product to either Microsoft Windows NT Server 4.0 Terminal Server Edition or Windows 2000 Server with Terminal Services running in Application Mode. (Throughout this book, we will refer to these two operating systems as "Terminal Server." This term is used to generically describe either platform.) MetaFrame XP is really no different than any standard Windows application because it requires an operating system to be installed in order to function.

Terminal Server is basically the same as the regular Windows Server operating system except that in Terminal Server, key components have been added or modified to provide support for multiple simultaneous users.

In case you're wondering, Microsoft Windows has always been a "multi-user" operating system in the sense that multiple users could be connected to a single server at any given time. However, these users were connected to file services or printer services on the servers. They ran their local Windows interfaces on their local computers. The server only supported one single desktop interface via the local keyboard, mouse, and monitor. The main difference with Terminal Server is that multiple users can each run their own Windows desktop sessions on the server, so Terminal Server is "multi-user" in the sense that it supports multiple desktop interfaces. Some people like to think of this as a "remote control" environment, except that the Terminal Server can support many different users "remote controlling" it at the same time with each user doing something different. Conceptually, this is similar to UNIX X.11 servers.

In order for Terminal Server to support multiple user sessions, some changes had to be made to it from the regular Microsoft Windows server software. There are two fundamental differences between Terminal Server and regular Windows Server:

  • Certain core components of the Windows operating system have been modified in Terminal Server to support multiple simultaneous user interfaces. For example, the virtual memory manager and the object manager have been modified so that they can support multiple simultaneous desktop interfaces without getting confused.
  • New services and components have been added that allow Terminal Server to support the multiple user "sessions." The most important new component is the "Terminal Server" service. This service, which runs deep inside the server, is responsible for interfacing the multiple user sessions with the operating system. The Terminal Server service is responsible for functions such as creating sessions, receiving users, and ending sessions.

In order to understand how the various Terminal Server components work together in the real world, let's look at what happens as a Terminal Server is booted and a user connects.

  1. The Terminal Server boots like a normal server, except that many of the core components are "multi-user aware."
  2. The Terminal Server service (termserv.exe) is started. This service immediately begins waiting for user session connections. Every single user session that connects to a Terminal Server is given a "session ID" which is an integer appended to every process that the session runs. Each Terminal Server tracks its own Session IDs, and the session ID numbers start over at zero whenever the server is rebooted. The unique session IDs are what allow two different users to run the same application at the same time without the Terminal Server getting confused. Session IDs also allow the server to keep all processes and memory separate for each user's session.
  3. The server console (the local keyboard, mouse, and monitor) session starts and connects automatically. The console session is always the first one, so it always has the session ID "0." Once the console session connects, its display, mouse, and keyboard drivers are loaded.
  4. Next, the Terminal Server service calls a component called the "Session Manager" (smss.exe). The Session Manager is responsible for managing user sessions (which are all the sessions other than the server console with session ID "0."
  5. The Session Manager invokes the process csrss.exe to create two new user sessions (session ID "1" and session ID "2") that remain idle on the server. Whenever a user connects to the Terminal Server to establish a session, the Session Manager connects them to one of these "idle" sessions, and a new idle session is created. The idea behind this is that idle sessions have the memory space, session IDs, and interface drivers all set up and loaded so that when a user connects, all they have to do is grab one of these idle sessions. This shaves a bit of time off of the user session connection process.
  6. After the Session Manager completes its startup tasks, the Terminal Server creates connection listeners that watch certain network cards and protocols for new user session connection requests. When a new session connection request is received, the session listener passes the request over to the Session Manager, and then the connection listener goes back to listening for more connections.
  7. Once the Session Manager receives a new session request from the connection listener, the Session Manager negotiates with the requesting client for the security encryption for the session.
  8. Next, the Microsoft licenses are verified. The server client access license is verified first, and then the Terminal Server client access license is verified. (Licensing is covered in detail in Chapter 14.)
  9. At this point, the user session is ready to begin. If there is an existing disconnected session for that user, that session stack is loaded. Otherwise, the server maps one of the idle sessions to the user's account, and the user is ready to go.

In environments where MetaFrame XP is not used, Terminal Server provides its own thin client protocol, called RDP, which allows other Windows clients to connect to the server and run remote sessions. However, the server startup and session connection processes are the same regardless of whether MetaFrame XP is used.

MetaFrame XP Interaction with Terminal Server

MetaFrame XP is an add-on product to Terminal Server. It uses the existing Terminal Server core components and services. In MetaFrame XP environments, Terminal Server is responsible for uncoupling the user interface from the application execution. All MetaFrame XP does is package that user interface in a protocol (the ICA protocol) and send it to the end users.

MetaFrame XP also plays a role in helping the end users find and connect to servers. However, after a user connects, they run a regular Terminal Services session with the Citrix ICA protocol.

Because MetaFrame XP is just an add-on product that provides the interface to end users, it is essentially nothing more than a set of services and management tools. MetaFrame XP does not break any of the existing Terminal Services components or interfaces. In fact, even though MetaFrame XP users connect via the Citrix ICA protocol, other Terminal Server users can still connect to the same server at the same time via the Microsoft RDP protocol.

Figure 2.1 shows how the MetaFrame XP software and Terminal Server operating system interact on a single server. As you can see, while the core multi-user operating system is based on Terminal Server, both user connection subsystems operate in a parallel fashion, allowing users to connect to MetaFrame XP or Terminal Server sessions.

Figure 2.1: MetaFrame XP and Terminal Server Interaction

MetaFrame XP Components

As we mentioned previously, MetaFrame XP is really nothing more than a middleware software application. Fundamentally, MetaFrame XP only does two things:

  • It provides a method for users to locate and connect to servers.
  • It provides a protocol (ICA) for users to run their remote sessions.

The diagram we looked at on the previous page (Figure 2.1) shows MetaFrame XP as a self-contained box. Of course in the real world, nothing is quite that simple. Even though it only does two things, MetaFrame XP is made up of several different components, subsystems, and interfaces. A more complete diagram of the MetaFrame XP components is shown in Figure 2.2. Refer to that diagram as you read through the next few sections describing each of the components that make up MetaFrame XP.

Figure 2.2: The MetaFrame XP components, services, and interfaces

Component 1. The IMA Service

As you can see by its placement in Figure 2.2, the IMA Service is the central nervous system of MetaFrame XP. This service is responsible for just about everything MetaFrame-related, including tracking users, sessions, applications, licenses, and server load. It also communicates with other MetaFrame XP servers and administrators, and knows which users have permissions to access which applications. The IMA service runs on every MetaFrame XP server in your environment. If that service stops then your server is out of commission. The IMA service itself is made up of many components and subsystems. As you read this book, you will become more familiar with these various components.

Component 2. The Citrix XML Service

The Citrix XML Service is the primary interface between the MetaFrame XP server and anything else in the world that wants to get information about what services, applications, and content are available on it. The Citrix XML Service does not figure out anything on its own. Rather, it gets its information from the server's IMA Service and sends that information to whomever requested it.

As its name implies, the Citrix XML Service transmits this information via XML. Remember that XML is a language, not a protocol. The Citrix XML Service sends XML files to client devices that need information about the services offered. These XML files are generated by the XML Service dynamically and contain the information that the clients need. The XML service transmits XML files via standard protocols, usually HTTP running on TCP/IP.

Component 3. The ICA Protocol

Chapter 1 mentionedthat the Citrix ICA protocol is the protocol used for the remote application sessions between users and MetaFrame XP servers. The ICA protocol is a high-level protocol, and it can run on top of TCP/IP, NetBIOS, or IPX/SPX. While Terminal Server is technically responsible for separating an application's execution logic from its user interface, the ICA protocol is responsible for transmitting the user interface elements (screen updates, mouse movements, and keystrokes) between ICA client devices and MetaFrame XP servers. Also, the Citrix ICA protocol is responsible for transmitting background information between the ICA clients and the MetaFrame XP servers, including the port mappings, drive mappings, print jobs, and sound.

Component 4. Citrix Connection Listeners

Every MetaFrame XP server allows users to connect via explicitly defined ICA connection listeners. These listeners are similar to the Terminal Services listeners, except that MetaFrame XP listeners listen for connections based on the Citrix ICA protocol instead of the Microsoft RDP protocol. One connection listener is required for each network card / protocol combination. For example, an ICA connection listener waiting for connections on TCP/IP via NIC #1 would be a separate connection listener from one waiting for ICA connections over SPX via NIC #1, and so on. In the real world, these connection listeners and all of their related configuration properties are simply referred to as "connections."

If no connections were defined on a server, then no users would be able to connect, because there would be nothing to listen for and receive the user session connections. By default, the MetaFrame XP installation program automatically creates a connection for each protocol that is installed on the server when MetaFrame XP is installed.

Because each defined connection only supports one unique combination of a network protocol (TCP, IPX, async), a thin client protocol (ICA, RDP), and a network card, you can get very creative when you define connections. Imagine the following scenario:

Figure 2.3 shows a MetaFrame XP server running TCP/IP and IPX/SPX with two network cards. When MetaFrame XP was installed, a connection called "ica-tcp" was automatically created and applied to both network cards. This connection is used by all users connecting via the ICA protocol running on TCP/IP via either of the two network cards. This connection was created in addition to the "rdp-tcp" connection that was automatically created when Terminal Services was installed. The "rdp-tcp" connection allows users to connect via the Microsoft RDP protocol over TCP/IP, via either network card. On the server shown in Figure 2.3, the administrator previously removed NIC #2 from the configured list for the RDP protocol. This means that only users connecting via NIC #1 can use the "rdp-tcp" connection.

Figure 2.3: A MetaFrame XP server with multiple NICs

When users connect to MetaFrame XP servers, they do not choose which connection they use. In fact, just the opposite happens. The user connects via a certain network card and protocol combination, and the appropriate connection receives them. For example, in Figure 2.3, if a user tries to establish an ICA session via the IP address of NIC #1, they will be picked up by the "ica-tcp" connection. If a user tries to establish an ICA session via the IP address of NIC #2, they will also be picked up by that same "ica-tcp" connection. However, if they try to establish an RDP session via the IP address of NIC #2, their session will not connect, because no RDP connection is configured for NIC #2.

As you will see throughout this book, almost everything that you configure in MetaFrame XP environments is configured via the Citrix Management Console. However, the connections and their associated listeners are configured via a different utility called "Citrix Connection Configuration" (CCC). You can use CCC to configure options for Citrix ICA connections and Microsoft RDP connections, such as settings, permissions, and over what network card a connection is valid. Full connection details are available in Chapter 17.

In case you're wondering, the reason why connection settings are configured with their own utility instead of the Citrix Management Console is because each MetaFrame XP server maintains its own settings in its Windows registry. This is different from all other MetaFrame XP settings, which are maintained in a central database. This database (the "IMA Data Store") will be introduced in Chapter 3.

Anyway, you can only create one connection for each unique thin client protocol / network protocol / network card combination. This is because if you created multiple connections, each connection could have different properties, and the server wouldn't know which properties applied to user sessions that connected via the ambiguous connections.

The properties that you configure for a connection affect all of the users for that connection, regardless of whether the users have conflicting options configured somewhere else, such as in their user account properties. For example, if you set the properties of a connection that is ICA on TCP/IP, bound to all network adapters to "disable" client drive mappings, then every user that connects via that protocol / network card combination (i.e. that connection) will be bound by those settings, even if the user has different settings in his profile or is an administrator.

In the real world, you can use the power of multiple connections to customize parameters for different users that connect in various methods. For example, if you are using asynchronous ICA dial-in capabilities, then you can customize that specific connection to disable sound support in an effort to save precious dial-in bandwidth. In this situation, your LAN users would use a separate connection (maybe ICA on TCP/IP or ICA on SPX) that did not have the same restrictions. This is detailed in Figure 2.4.

Figure 2.4: Multiple connections with different parameters

At this point, it's important to note that there are several different ways to restrict user access. One of the problems with setting access at the connection layer is that whatever restrictions you configure are in place for all users on the connection. This could present a problem if, for example, you have users that you want to restrict that are coming from one subnet and users without restrictions coming from another. From the connection standpoint all would be using the same connection because all would connect via ICA on TCP/IP.

Of course you could install two network cards in your MetaFrame XP server and set up two different connections-one for each network card-each with different settings and restrictions. This is not always practical because you would then need two network cards and two IP addresses for each server. Fortunately, there are other ways to address needed security, as detailed in Chapter 15 of this book.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.