Hardware

Configure IT Quick: Lay the groundwork for a successful MetaFrame XP installation

Prepare and plan for MetaFrame installation.


When you’ve decided to use MetaFrame XP in your organization, you can’t just buy a copy, put it in your server, run Setup, and hope everything will work properly. With the exception of Terminal Services, MetaFrame XP is unlike any other network service you’ve deployed. You must do a lot of planning and preparation before installing it. I’ll show you what you must do before reaching for the MetaFrame XP installation CD-ROM.

What’s MetaFrame XP?
Citrix MetaFrame installs on top of Windows 2000’s Terminal Services, extending its functionality and broadening its features. Although Terminal Services is a new feature for Windows 2000 and MetaFrame is a new product from Citrix Systems, both products have a long, intertwined history. For more information about MetaFrame XP, see the Daily Feature "Save money and gain flexibility with MetaFrame."

Create a project plan
A successful MetaFrame XP implementation starts with a doable plan. The more you plan, the less likely you are to encounter problems during implementation that could cause setbacks to your original implementation timeline. Take your time in the planning stage and don’t promise more than you can deliver.

Good documentation may be the most crucial part of any implementation and project plan. It’s easy to fool yourself into believing that documentation isn’t necessary. It may seem inconvenient to write down everything you want to do and track what you’re doing along the way, but when problems arise, you'll thank yourself for doing it. Also, documentation can play an important role in training users to work with MetaFrame and will help you deploy any future upgrades you plan to make to MetaFrame or your servers efficiently.

With a MetaFrame implementation, you should document all the tweaking you make to your server in terms of registry hacks and group policy configurations. You can add Visio drawings that include registry hacks you implemented, any custom scripts you wrote, file server location, and the purpose of the servers. If you do so, other network administrators can use your documentation when building additional servers.

Don’t postpone documentation until after you've completed the project. Chances are you’ll be concentrating on a different project by then and you may forget important things you should have included in the documentation. Of course, you may prefer to document as you are building the server.

Because not all applications work well in a MetaFrame environment, as part of your planning process, you should carefully study application migration issues. Determine which applications you want to migrate to a Citrix MetaFrame implementation. Keep in mind that implementing MetaFrame is not an all or nothing deal. The purpose is to migrate those applications that have the highest maintenance and support costs. To make a difference in the total cost of ownership (TCO), only those applications that require frequent updates and that generate the highest number of support calls should be migrated to a MetaFrame environment.

Check your network infrastructure
The physical environment in which you’re installing MetaFrame is also important. Networks that are spread out over several locations may require special considerations.

Also, implementing MetaFrame XP into an environment where branch offices exist or where a WAN exists can create a single point of failure. If the communication links go down between the remote sites and the MetaFrame servers, your remote site will be completely cut off. You'll need to take some extra steps to eliminate such a single point of failure. Make sure you have a redundant communications link, such as a backup ISDN line to each remote site, which could temporarily replace the main communication link.

You can also get around a single point of failure by implementing Citrix’s NFuse, which allows you to make your published applications accessible from the Internet via a Web browser. In the event that a WAN failure occurs, you can set up your users with a local ISP to get them up and running until you've fixed the problem.

To add redundancy, you can also enable and configure MetaFrame to accept dial-up access directly to the server. I don’t recommend this, however, because of the extra load it puts on the server. If you want to provide dial-up access, you should plan to install RAS and RRAS on your network. Your Citrix users can dial in to RRAS to access the MetaFrame servers.

One of the weakest areas of thin client implementations—Citrix implementations in particular—is printing. Network printing can cause problems because of the variety of print drivers available for every operating system. For printer autocreation to occur, the client print driver should match the server printer driver.

MetaFrame XP includes a new feature that gives you the ability to remap print drivers without having to reinstall the client print driver to match the server. However, when clients actually print a document, the spooling of the document occurs on the server side and is then sent to the print device for actual physical printing. The transfer of this spooled print job from the server to the physical printer can be problematic if your network is overwhelmed and the network drops or corrupts packets. Such packet issues can cause the printer to hang, prompting you to stop and start the print spooler after deleting the queued jobs. This is a big inconvenience to the user because if the print spooler hangs, no one can print.

To solve this problem, you should use the Citrix Universal print driver. This eliminates the need to install printer drivers for a bunch of printers on the print server. Citrix uses the driver installed on the client computer to print the document rather than one from the MetaFrame session, which could conflict with the client operating system. The job is actually spooled on the client computer and printed using the locally installed driver to the physical printer.

Planning your server
Because all of the applications your users run actually run on the server using MetaFrame XP and not on their workstations, you must make sure your servers can handle the extra work. When sizing your server, consider the minimum resources the operating system needs and the minimum resources that Citrix MetaFrame XP needs to function properly.

MetaFrame XP runs on top of Windows 2000 Server, which requires a minimum of 256 MB of RAM, a Pentium 133 class processor and 2 GB of hard disk space, of which a minimum of 1 GB must be free. Citrix MetaFrame XP and the Citrix Management Console (CMC) need another 100 MB of free disk space and about 128 MB of additional RAM.

Any server you use will require a minimum of 2.1 GB of hard disk space, at least 384 MB of RAM, and a minimum of a Pentium 133 processor to run. Even though this configuration may work, it won’t necessarily work well. You'll need a faster processor, more RAM, and a bigger hard drive for it to work efficiently. To figure out exactly what you'll need, you must consider additional factors, including:
  • The number of concurrent users logging in to an individual server.
  • The type of user (i.e., power user vs. average user).
  • The type of applications that will be deployed.
  • How much memory and CPU these applications will need to function properly.

Let’s start by clearly defining average users and power users. Average users do normal tasks, such as entering data into an application. Applications that fit into this category may include Word, Excel, and maybe even JDEdwards One World, which is enterprise-scale accounting software. A power user utilizes more server resources to launch and use more powerful and graphical applications such as Adobe Photoshop or any other application that requires a lot of mathematical operations to run. As a rule of thumb, your server should have a minimum of 4 MB of RAM for every average user in MetaFrame XP and 8 MB of RAM for each power user. These resources are above the minimum requirements to run the applications themselves.

You must then look at the applications you intend to deploy and measure how much memory and CPU speed each application needs. A good way to do this is to simply log in as an average user, launch an application, and run it while you use built-in performance monitoring tools to record statistics related to memory and CPU utilization. Carefully analyzing these results should give you a clear idea of what the application needs (in terms of resources) to run properly. Then, add those resource requirements to your server plan.

You should also include some type of hardware redundancy. You can start with hot-swappable devices and expensive RAID controllers, but experience has taught me that the best possible redundancy solution in a thin client environment is more servers. If you're concerned about the cost of running multiple servers, I’ve learned that by the time you implement a hardware RAID solution to your existing server and some hot-swappable devices, you’ll wind up paying about 90 percent of the cost of a new server with no RAID solution or hot-swappable devices.

Furthermore, the addition of more servers means fewer users on each server, which translates to better performance and availability. If a server goes down and you have multiple servers, MetaFrame XP uses its farm capacity to adjust and absorb the extra number of users dropped.

Deciding about a database for MetaFrame XP
Once you have an idea of the hardware specifications for your server, you should decide what database to use for the Citrix Independent Management Architecture (IMA) Store. The IMA Store, new to MetaFrame XP, acts as a repository database that holds information related to your Citrix MetaFrame XP server farm. As of this writing, Citrix IMA supports three databases: Microsoft Access, Microsoft SQL Server, and Oracle. I recommend Microsoft Access for small environments of one to 50 servers and about 100 users. Microsoft SQL Server and Oracle are recommended for larger environments, but work equally well in any size organization. SQL Server and Oracle cost more than Access.

There are two methods of accessing this data store: Direct mode and Indirect mode. In Direct mode, the server has direct access to the data store database, which makes data access very fast. This option is only supported in Microsoft SQL and Oracle databases.

In Indirect mode, the Access database resides on one of the MetaFrame servers and all the other MetaFrame servers communicate with this host server. The host server consolidates the information and passes the information exclusively to the Access database that resides on it. However, this approach is slower.

Based on experience, I recommend using Microsoft SQL Server in Direct mode. SQL Server doesn’t require a dedicated server, and if you’re already running SQL Server, you can leverage any existing server in your organization and create your IMA Store database on it. The database will probably never grow beyond 50 MB.

Ready? Set? Go!
To successfully install MetaFrame XP, you must make a few preparations. Remember that the most important step is to document the process. Keep careful records of what you want MetaFrame XP to do along with the hardware and software combinations you’ll be using. Doing so will help you solve problems that may later occur with your MetaFrame XP deployment.

Editor's Picks