MetaFrame XP: A Guided Tour

Take a look at the new and improved MetaFrame

Citrix MetaFrame’s extensive features make it a popular add-on to Windows 2000 Server Terminal Services and Windows NT Server 4.0, Terminal Server Edition (WTS—the sidebar "Why MetaFrame?" describes a few of MetaFrame’s advantages). The product’s most recent version, MetaFrame XP—formerly known as MetaFrame 2.0 (and no relation to Windows XP, according to Citrix)—has all the features and add-ons of MetaFrame 1.8 Feature Release 1, as well as enhanced server-management features. MetaFrame XP for Windows comes in three versions, follows a new organizational model, uses a new consolidated management console, increases load-balancing capabilities, simplifies client-side printing, offers new licensing schemes, and provides a mixed-mode setting to ease upgrades from MetaFrame 1.8. Step right up for an overview of the new and improved MetaFrame. (Since the time of this writing, Citrix has released Feature Release 1 for MetaFrame XP. For information about that release, see the sidebar "MetaFrame XP Feature Release 1.)

A New Package
MetaFrame 1.8 was a basic package to which you could add Load Balancing Services, Resource Management Services, and Installation Management Services—each of which came as a separate product. MetaFrame XP is packaged differently. Rather than buy the base product and one or more add-ons, you choose one of three MetaFrame XP versions: XPs, XPa, or XPe.

MetaFrame XPs is the base product. MetaFrame XPs supports application publishing, new printer-driver and print bandwidth–management capabilities, read access to Win2K Active Directory (AD), centralized license management, Web application publishing (using Citrix NFuse 1.5), advanced session shadowing, and client time zones (i.e., user clocks depend on client locations rather than the terminal server’s location). MetaFrame XPa includes all those features plus load balancing. MetaFrame XPe, the product’s enterprise edition, supports all the features available in MetaFrame XPa and adds system monitoring, resource-management services, application installation–management services, and interaction with network-management tools (i.e., IBM’s Tivoli and Hewlett-Packard’s HP OpenView). Although all versions of MetaFrame XP include recognized MetaFrame 1.8 Feature Release 1 features (e.g., panning and scaling applications, high-color support, an updated SpeedScreen), certain aspects of the product’s server-management and -communication, licensing, printer driver–management, and load-balancing features have changed significantly.

All MetaFrame XP versions work with either Terminal Services or WTS (independent of service packs), but Citrix recommends you use Terminal Services or .NET Server. Although MetaFrame XP isn’t dependent on any Win2K-specific features, it can use some of them (e.g., it can read—though not write—to AD), so the product’s functionality varies depending on the underlying platform.

A Stronger Organizational Model
One of MetaFrame 1.8’s weaknesses is its organizational model: Servers communicate through the connectionless UDP broadcast protocol, so you can deal with servers as a group only when they are all in the same subnet. Otherwise, you must deal with gateways—a messy and awkward (and sometimes downright impossible) requirement when you’re trying to pool licenses or applications.

MetaFrame XP uses a different model. When you configure MetaFrame XP servers to interact in a MetaFrame XP–only farm (i.e., operate MetaFrame XP in native mode), the servers communicate with one another through a directed Citrix protocol—Independent Management Architecture (IMA)—that works over TCP ports. (Clients can still use UDP to find published applications.)

Like MetaFrame 1.8, MetaFrame XP uses farms as organizational units. But whereas MetaFrame 1.8 farms usually comprise a group of servers in one physical location (to avoid the need to use gateways for intrafarm-server communications), a MetaFrame XP farm represents all the servers that you manage as a unit, regardless of their locations. You can create as many farms as you want, but the only reason to do so is to isolate certain sets of servers (e.g., an application service provider—ASP—might maintain one farm for its customer servers and one for its inhouse servers). MetaFrame XP doesn’t support interfarm communication.

In addition to its logical grouping of farms, MetaFrame XP recognizes zones, which are physical groupings of servers. Every farm has at least one zone; by default, the ratio of zones to farms is 1 to 1, but you can create more than one zone in a farm. Zones don’t need to relate to a subnet, but should relate to a server’s physical location. For example, you can place servers in two states (e.g., Colorado and Florida) in the same farm, but you should place such widely spaced servers in different zones. When you set up MetaFrame XP, you create or join a zone. You can also create and delete zones or move a server from one zone to another within a farm.

Grouping farm servers into zones is an important step because it can cut down on replication traffic. All servers in a farm share one data store (which you can maintain as an Oracle, Microsoft SQL Server, or Microsoft Access database) that keeps all static farmwide information (e.g., licensing, available applications). When a farm is widely dispersed physically, populating this data store so that it remains up-to-date requires a lot of bandwidth. Each zone in a multizone farm has a separate data collector, which replaces MetaFrame 1.8’s master browser (i.e., a server that contains a master list of Citrix servers, pooled licenses, and published applications). The zone’s data collector is the means through which each zone communicates zone-specific information (e.g., applications currently in use) to the other zones in the farm. You can also use this data collector as a source of information for the zone. The use of data collectors for cross-zone communication makes geographically spread farms possible.

You must back up the data store—if you lose it, you lose all the farm’s static information—but data collectors are expendable. If one collector goes offline, the zone finds the server with the most recent version of the MetaFrame XP software and makes this server a new data collector. You can specify a set of preferred data collectors much in the same way as you set a preferred master browser in MetaFrame 1.8.

Consolidated Management
The biggest news in MetaFrame XP is its consolidated server management. You can now manage servers, applications, and printers from one Java-based console: the Citrix Management Console, which Figure 1 shows.

The console uses a familiar Windows Explorer–like interface. However, the console doesn’t operate as part of Microsoft Management Console (MMC). Citrix also makes MetaFrame for UNIX (although MetaFrame XP for UNIX wasn’t yet available at the time of this writing). Therefore, to ensure that you can use the console to interact in the same way with all terminal servers regardless of their underlying OS, the Citrix Management Console is independent of both MMC and Windows.

In addition to platform independence, another key console benefit is that you can run it from any Windows computer that can access the server farm—even a system that isn’t the terminal server or any type of server. The MetaFrame XP installation CD-ROM offers the option to install MetaFrame XP or to install the console. (Technically, you can install MetaFrame XP without installing the Citrix Management Console, but Citrix doesn’t recommend doing so. If for some reason you can’t manage your terminal server across the network, you need to have local access to the console so that you can locally manage the terminal server.) When you install the console on a computer, you can then manage terminal servers from that computer—even when the computer you're using to do the managing doesn’t have a terminal services client access license (TSCAL) or an ICA license. You aren’t managing the server from a terminal session, so the system doesn’t require a license. This remote management capability has limits. Only the tools in the Citrix Management Console are accessible through the console; you can’t use the console to access ICA tuning tools or Terminal Services management tools.

The console installation process is simple: Run setup.exe from the MetaFrame XP installation CD-ROM, agree to the End User License Agreement (EULA), specify the desired location for support files (by default, Setup places those files in C:program filescitrixadministration), and wait for Setup to copy the files. You don’t need to reboot the computer. When you run Setup on a Windows 9x computer, the program assumes that you want to install only the Citrix Management Console. (The Citrix documentation doesn’t specifically state that the console works on Win9x machines, but I successfully installed and used the console on a Win98 computer.) When you run Setup on a non–terminal server Win2K computer, the option to install MetaFrame XP appears to be available but doesn’t actually function. The Java Runtime Environment (JRE) must be installed on the system for the console to work; if it isn’t, Setup offers an option to install JRE during console installation.

The setup routine also prompts you to enter a user account that will be authorized to log on to the console. (The account defaults to whoever is currently logged on. You can add more authorized accounts to the list after you install the console.) Don’t forget whom you have—and haven't—authorized to use the console. To use the console, you must log on, so only explicitly authorized console users can open the console. Even the Administrator account will be shut out unless you add it to the list of authorized accounts. This requirement is inconvenient, but it lets you safely install the console on client machines without giving every person who uses that computer access to MetaFrame’s server-management capabilities.

To connect to a server farm, start the Citrix Management Console from the Programs, Citrix submenu. This action opens a dialog box that displays a drop-down list of servers and a place to enter a username, domain, and password. Choose a server from the farm you want to manage,then enter the information for an account that’s authorized to manage that farm. Connecting to a server in a farm logs you on to the entire farm, so you have access to all the resources in the farm, not just the resources on the server you’ve connected to. After you've logged on to the console, you can use MetaFrame XP's new features.

More Load-Balancing Options
MetaFrame 1.8’s load-balancing capabilities are more flexible than those that come with Terminal Services or WTS, but MetaFrame XP has even more load-balancing options—and they’re better designed. (For example, previous versions’ slider bars are gone; you now type in percentages or absolute numbers.) MetaFrame XP uses load evaluators, or collections of load-balancing rules, to calculate load and help you tackle bottlenecks on a server.

MetaFrame XP comes with two prebuilt load evaluators. When you install MetaFrame XP in native mode, it uses the Advanced evaluator, which uses a combination of rules to measure a server’s stress according to the number of page swaps per second as well as memory and CPU utilization. When you install MetaFrame XP in mixed mode (i.e., when you configure MetaFrame XP servers to interact with MetaFrame 1.8 servers), the program uses the Default evaluator, which uses rules that simply measure current connections to the server.

Application User Load. The Application User Load rule limits how many instances of a particular application can run on the server. You can use this rule to limit the use of resource-intensive applications. When you implement this rule as part of an evaluator, the console presents a list of published applications from which you select one application to limit.

Context Switches. Win2K can run in user mode or kernel mode. In user mode, all processes are protected from one another; in kernel mode, all processes use the same memory space. A context switch occurs each time Win2K changes processing from one mode to another. (Context switching is different from task switching, which is the CPU time allotted to each running application’s instructions before the CPU is devoted to another application.) Context switching takes time and system resources, so you can use the Context Switches rule to calculate and control load according to the number of context switches that a terminal server performs each second. (Don’t set this number too low; Win2K is designed to perform a lot of context switches. I suggest that you accept the defaults for this rule or use a different rule.)

CPU Utilization. When you apply the CPU Utilization rule, MetaFrame XP refuses to accept logons when the CPU is busy more than 90 percent of the time. Conversely, the program reports the server as free when the CPU is busy less than 10 percent of the time.

Disk Data I/O. You can use the Disk Data I/O rule to measure load according to how often the disk is reading or writing data. This rule applies to all the disks on the server.

Disk Operations. You can use the Disk Operations rule to measure load according to how many reads and writes a disk performs per second. As with Disk Data I/O, this rule applies to all the disks on the terminal server.

IP Range. The IP Range rule permits or refuses connections to servers or applications from a specified range of IP addresses. You can use this rule to ensure that users in a particular zone use local servers.

License Threshold. The License Threshold rule keeps track of the number of assigned and pooled licenses that clients are using on a particular server. (Assigned licenses are specific to a server; pooled licenses are shared among all the servers in a farm.)

Memory Usage. The Memory Usage rule reports the percentage of memory in use on the server. By default, when 90 percent of the memory is in use, the rule will prevent the server from accepting connections until usage levels drop.

Page Fault. The Page Fault rule keeps track of the rate at which the server performs page faults. (In other words, the rule tracks the rate at which the server accesses data that it’s swapped from memory to hard disk.)

Page Swap. The Page Swap rule is somewhat similar to the Page Fault rule. However, this rule keeps track of the rate at which the server swaps data from memory to hard disk.

Scheduling. You can use the Scheduling rule to specify the times of day or the days of the week during which a server or application is unavailable. This rule isn’t meant to be used in isolation and won’t kick out users who are using the specified server or application when it enters the blackout period.

Server User Load. The Server User Load rule tracks the number of connections to the server. The rule lets you set an upper threshold for that number, then refuses new connections when the server reaches the limit.

You can also build customized evaluators. Select the Load Evaluators node in the Citrix Management Console, then select Actions, New from the console’s menu bar to open the New Evaluator dialog box, which Figure 2 shows. (The console also offers a menu icon that opens this dialog box. The icons aren’t particularly intuitive, but they do use tooltips.) Alternatively, you can copy an existing load evaluator, then edit that copy. You can apply only one load evaluator at a time to a server. MetaFrame XP provides a variety of rules that determine load in different ways.

Enhanced Printing Options
Let’s not mince words: Printing in a terminal-server environment that supports client-side printers is a royal pain. Modern versions of both RDP and ICA automatically map client-side printers to terminal sessions. When an application running on the terminal server sends a print job to a client-side printer, the terminal server uses locally stored printer drivers to generate a spool file for that print job. The print processor then sends the print job to the client-side printer. This process sounds simple enough, but it means that the printer drivers must exist on both the client and the terminal server—and that the server-side printer drivers must work without crashing the terminal server. Also, spool files are big—much bigger than the files that you’re printing. Sending a print job to a client-side printer can take a long time (especially if the client is reaching the server through a slow WAN connection) and can also slow the performance of the terminal session by taking up all the bandwidth. MetaFrame XP doesn’t resolve all the problems associated with printing from a terminal session, but it does tackle two of them: printer-driver management and bandwidth throttling.

Printer-driver management. To help you keep a handle on printer drivers, MetaFrame XP supports driver replication across the servers in a farm. This ability lets you install all the drivers on one terminal server, then replicate them to the other servers so that the drivers are available regardless of which server a user connects to.

First, install the drivers on one server, and test them to make sure they don’t crash the terminal server. Then, open the Citrix Management Console, log on to that server’s farm, and select the Printer Management node. Go to the Drivers tab in the console’s right-hand pane; this tab displays a drop-down list of all the servers in the farm and a list of installed drivers on the currently selected server. The default server selection is Any, which displays a corresponding list of all drivers on all servers in the farm. Select the server on which you just installed the appropriate drivers. (Don’t leave the server selection as Any. You might accidentally replicate other, possibly buggy, drivers from servers other than the one on which you installed the good drivers.) Use the Ctrl or Shift key to select all the drivers you want to replicate, then either double-click or right-click the selected drivers and choose Replicate Drivers from the context menu to open the Replicate Driver dialog box. In this dialog box, you can specify whether you want to copy the drivers to all MetaFrame XP servers in the farm or to selected servers. You can also select a check box to overwrite existing drivers on the target servers (if you choose this option, be sure you’ve chosen the proper server to replicate from).

Bandwidth throttling. Terminal sessions don’t use much bandwidth, but print jobs do. A print job sent over a slow or crowded link can bring terminal sessions to a standstill if traffic is heavy enough, so bandwidth management is a useful capability. By default, MetaFrame XP doesn’t limit the amount of bandwidth that a print job can consume, but you can set such a limit. In the Citrix Management Console, select the Printer Management node and go to the Bandwidth tab in the console’s right-hand pane; this tab displays the servers in the farm as well as any bandwidth restrictions you’ve set. Double-click a server to open the Edit Bandwidth Limit dialog box, which Figure 3 shows. Specify the limit you want to set for that server, and click OK. Repeat the process to set limits on other servers, or right-click a server and choose Copy from the context menu to copy the bandwidth limitations to other servers.

This server-by-server solution isn’t perfect. MetaFrame XP doesn’t include a mechanism for throttling bandwidth on a per-user basis or on only low-speed connections. And because you must specify the limit in kilobits per second rather than as a percentage, you definitely need to bear in mind which servers support slow network connections.

Simplified Licensing
Citrix has greatly simplified MetaFrame's licensing structure. You can install MetaFrame XP on as many servers as you want; you pay only for concurrent connections. The retail cost per connection depends on which package you buy: MetaFrame XPs costs $250 per connection, MetaFrame XPa costs $300 per connection, and MetaFrame XPe costs $350 per connection. Purchase of Subscription Advantage (a program that provides updates to the product) adds $50 to each package. You must buy a license for at least 20 connections; you then can buy more licenses in quantities of 5, 10, or 20. If you already use MetaFrame 1.8 and Subscription Advantage, migration to the package most similar to your current MetaFrame 1.8 configuration is free. The match might not be perfect, but Citrix tells me that it will do its best to make sure that customers are happy with the upgrade program.

You still need TSCALs to access the terminal server, even if you use ICA for the display protocol. This requirement shows another benefit of the Citrix Management Console—you can manage multiple terminal servers without eating up a TSCAL.

You must activate licenses within one day of installing them, or the terminal server stops accepting connections. To activate an installed license pack (which you can install when you install MetaFrame XP), open the Citrix Management Console and select the Licenses node. Go to the License Numbers tab in the console’s right-hand pane. Right-click the license you want to activate, and choose Activate from the context menu to open a dialog box that provides the license number. (You can copy this number to the clipboard so that you won't need to type it during subsequent steps.) Either from the terminal server or another system, go to http://citrix.com/activate/login.htm to log on to the Citrix Activation System (CAS).

You need to provide a logon ID and a password when you log on to CAS. If you don't already have an ID and password or can’t remember them, you can create new ones. Fill in the appropriate reseller and contact information, if necessary. CAS will return an activation code; enter that code in the appropriate text box on the Citrix Management Console, and click OK to complete activation.

What About MetaFrame 1.8?
If you aren’t ready to immediately rush out and replace all your MetaFrame 1.8 servers with MetaFrame XP servers, you can use MetaFrame XP in mixed mode (as opposed to native mode). You can choose the mode during MetaFrame XP installation, or you can use the Citrix Management Console to change the mode at any time after installation. To change a farm’s mode, right-click the farm, then choose Properties from the context menu. Go to the Interoperability tab and select (or clear) the Work with MetaFrame 1.8 servers in the farm check box. Changing this option restarts the ICA service and Program Neighborhood service on all MetaFrame XP servers in the farm; the servers can switch modes without rebooting.

In mixed mode, MetaFrame XP servers work like MetaFrame 1.8 servers, so you don’t get many of the new version’s manageability benefits (e.g., IMA communication, zones, data collectors). Running MetaFrame XP in mixed mode with MetaFrame 1.8 servers shouldn’t be considered a permanent scenario, but it can get you through the process of upgrading your MetaFrame servers without taking servers offline. After you upgrade all your servers, you should switch them to native mode.

Worth a Look
As you can see by this quick tour of MetaFrame XP, the product differs significantly from earlier versions. MetaFrame has historically had problems with scalability—especially when dealing with farms with many servers. MetaFrame XP attempts to resolve those problems through a new server-farm architecture, new management console, new load-balancing options, and new printer-server management. If you use MetaFrame or need more server-side management tools than Terminal Services can provide, the new version of this product is definitely worth a look.