Publishing Applications in a Server Farm

Citrix MetaFrame 1.8 provides the new Program Neighborhood feature, a terrific service that displays applications that you publish from a server farm. This new feature works with servers running Windows NT Server 4.0, Terminal Server Edition with the MetaFrame 1.8 add-on or Citrix WinFrame 1.8. To make the most of the Program Neighborhood feature, you need to know what server farms are and why MetaFrame users should care about them. Next, you'll need to know how to set up a server farm, how to publish applications in it, how to manage the servers in a server farm, and how to get applications to the client.

What Is a Server Farm?
Citrix originally called a collection of load-balanced terminal servers a server farm. With MetaFrame 1.8, Citrix expanded the meaning to a management concept. From the administrator's perspective, a server farm is an organization of Terminal Servers running MetaFrame 1.8 or servers that are running WinFrame 1.8 and that you can manage from one console. From the user's perspective, a server farm makes applications published from terminal servers in a network accessible from what seems to be one server.

If you're thinking, "Wait a minute! A server running MetaFrame 1.0 can publish individual applications!" you're right. In a sense, Terminal Server also can publish individual applications because you can cause a Terminal Server session to display an application alone and terminate the session when the user closes the application. To connect to an application published from a server running MetaFrame 1.0 or Terminal Server, however, a user must establish an explicit connection to the server providing the application.

Using server farms to publish applications is different from using either MetaFrame 1.0 or Terminal Server. MetaFrame 1.8 provides access to all the applications in a server farm from one interface, without any reference to the terminal server that has the application loaded. To run applications published from a server farm, a user connects to the server farm, not to a specific server. The server in the server farm providing that application picks up the user request for a connection and runs the application. Users who connect to multiple applications served from different servers in the server farm will have active sessions on more than one server without knowing or needing to know which server is providing the applications.

From the user's perspective, the difference between publishing applications from unassociated servers in a domain and publishing applications from a server farm corresponds to the difference between a workgroup and a domain. In a workgroup, individual servers share resources, but you need to explicitly log on to each server to use those resources. In a domain, you can log on to one server and gain access to all shared resources. Like domains, server farms let administrators manage network resources from one location. But unlike domains, server farms don't offer one-stop authentication. If the application requires authentication for access, you have to provide your name and password for each application in the server farm. Still, the logical grouping is domainlike.

Why Use Server Farms?
The main reason to use server farms is to simplify published-application management and use. Server farms make life easier for administrators and users.

Server farms make network administration easier because, from one server, you can manage all the applications that the servers in a server farm publish, and switch the focus from server to server. Unless you're lucky enough to have all your terminal servers plugged into a keyboard/video/mouse (KVM) switch, you'll appreciate not having to wander from server to server to twiddle published-application settings. Also, the domain-centric model of MetaFrame 1.0 lets you designate application access to users and groups from only one domain, whereas publishing applications in a server farm lets you grant access to members of other domains without having to publish the application twice.

Server farms provide easier application access for users because the application distribution is transparent. Server farms let you push applications to users in the form of an application set. After users install an Independent Computing Architecture (ICA) client that supports MetaFrame 1.8, they can connect to the application set from the desktop's Program Neighborhood. Users will see the applications (including the same application icons that display for locally installed applications) that they have access to use. The only catch is that the Program Neighborhood is available for only Win32 clients (unless you create an ICA Passthrough Session); so other clients can't benefit from server farming.

Creating a Server Farm
Before you set up the server farm, you need to keep a couple of things in mind. First, you can simplify your life if you keep the server farm servers in the same domain and subnet. The servers don't need to be otherwise logically or physically grouped to cooperate. With support from WinFrame's ICA Gateway feature, you can configure the servers to be in different domains and on different subnets. Because server farms depend on one source of authentication (e.g., the domain controller if you organize the servers in a domain), server farms with more than one server must be organized into domains, and workgroup-based server farms can contain only one server.

Second, load balancing and server farming aren't synonymous. You can easily confuse using server farms and load balancing because of Citrix's previous references to load-balanced terminal servers as a server farm. But MetaFrame 1.8 server farms don't automatically provide load-balancing services, which send user application or logon requests to the least busy terminal server. You can incorporate Citrix's Load Balancing Services, which is sold separately, into a server farm. Later, I'll point out where load balancing can be a useful supplement to a server farm. If you want to use load balancing in a server farm, the servers need to be in one domain because server farms rely on a single user-authentication database for the entire farm.

You need to complete the following tasks to create a server farm:

• Install NT 4.0, Terminal Server Edition (server farms don't require Service Pack 4—SP4—but do support it).
• Install MetaFrame 1.8.
• Install the applications that each server in the server farm will publish.
• Group the terminal servers into the server farm.

The first task is straightforward. To install MetaFrame 1.8, follow the wizard and provide the licensing information. The trick to installing applications for a multiuser environment is installing them from Control Panel's Add/Remove Applications dialog box to make sure that the applications install for all users.

Now, let's concentrate on what you need to do to complete the fourth task. To create the server farm, start the Published Application Manager from the Citrix Administration Tools program group. When you run the Published Application Manager for the first time, it will be empty for a moment, then the server farm wizard will start automatically. If you exit the wizard, you can still publish applications, but you will publish them from the domain-centric model (i.e., individually) instead of the server-farm-centric model.

If this server farm is the network's first server farm, you need to choose a default name (the default name for servers in a domain is domainname Farm and for servers in a workgroup is servername Farm) or create a new name for the server farm. If the domain already has a server farm, the server farm's name will appear in a drop-down server list; you can either pick that name or add a new name. You can revoke this decision later because you can use the Published Application Manager to switch the server farm or leave the server farm and use the domain model to publish applications as single-server applications.

Next, the wizard helps you publish applications for the server farm. Go ahead and publish every application that anyone with server farm access will need, even if all users don't need access to all applications. When users connect to the farm, their group memberships determine the applications in the application set. The wizard walks you through the following five steps to publish applications for a server farm.

1. Choose a name and description for the application. The application name must be unique within the domain even if the application isn't. Although you can have two instances of Microsoft Word 97 published under different names, you can't have two applications published as Word 97.
2. Provide a path to the application. Enter the application name and the path to its working directory on the local terminal server. The Browse option makes it easy to search for the executable file of the application you're publishing.
3. Specify whether everyone (i.e., anonymous users) or only users with a logon password will have access to the application. Applications available for anonymous use will appear in the application set of everyone connecting to the server farm. If you're requiring logon access to the application, you'll need to specify the users and groups that can see the application in their application set. Although the server farm displays only one domain at a time, if you click the Select option that Screen 1 shows, you'll be able to choose from a list of trusted domains. If you need to publish the application for people in more than one domain, grant access to the users or groups in the displayed domain first, pick another domain, and add the users or groups from that domain, as Screen 1 shows.
4. Name the servers that will publish the application. This step is important if you want to set up your servers for load balancing. As Screen 2 shows, the selected server will be the default server to publish the application. However, you can specify that another server publish the application—this capability is one of the things that makes using server farms so convenient. You can switch from server to server at this point. Alternatively, if you have load balancing set up, you can name another server to provide access to the application when the main server is unavailable. If you add a second server, be sure to edit the application's path information to show the correct directory for both servers. To do so, highlight the server in the Configured pane, which Screen 2 shows, click Edit Configuration, and edit the server's path information. You need two load-balanced servers to set up the application on both servers. These servers provide load balancing, not failover, which clustering provides. If one terminal server dies, the partner terminal server doesn't automatically take over the user session. Rather, the failing server disconnects the user and the partner server accepts the user's request to reconnect.
5. Use the Filter Servers option. If you click Filter Servers By, you'll see a set of options that lets you pick the servers to display. Displaying servers doesn't affect the membership of servers in the server farm but helps ensure that you include only the servers you want. For example, if you filter for load balancing, only the server farm's load-balanced servers will appear Available. If you want to pick from MetaFrame servers only, select either or both of the MetaFrame check boxes that Screen 3 shows.

Completing these five steps publishes an application in the server farm. Repeat the process for each application that you want to publish in the server farm.

Managing Servers in the Server Farm
From the console of any terminal server in the server farm, you can edit application settings. If you have more than one server farm in your network, you can move servers to other server farms. To edit an application's settings, you first have to determine which server published the application. Screen 4, page 114, shows the Citrix Server Administration, which you can use to find an application. After you locate the application, go to the Program Application Manager, click View, click Select Server, and pick the server that has the application you want to edit. The published applications will display. (If you have many servers with different settings, you can apply the Filter Servers By option to show a subset of only the servers in the server farm.) You can use the Application menu's Properties to edit an application's properties (e.g., path, icon, name, description).

If you don't have load balancing software installed, you might want to create multiple server farms to set up manual load balancing. When you have multiple server farms, each group of users will connect to its designated server farm. Because needs change, server farms let you easily move servers to other server farms. Choose the server you want to move to the Server Farm, and select the Program Application Manager's Configure menu option. Here, a screen will prompt you to change the server farm. Click the Change option, then click through to the next screen. Screen 5 shows the Choose a New Server Farm screen. Enter the name of the new server farm in the Server Farm Name text box. After you've moved the server to the new server farm, the change takes place immediately without requiring a reboot.

You can use a similar technique to add a server to a server farm. From the View menu, choose Scope, then choose to move from a domain server to a server farm. From this screen, you can join a server to the server farm. This kind of management works only when you move servers to a server farm.

Getting Applications to the Client
The MetaFrame 1.0's ICA client will connect to MetaFrame 1.8 servers without difficulty, but it doesn't support Program Neighborhood. To access appli- cations via Program Neighborhood, you'll need an ICA client that supports MetaFrame 1.8. If a client that doesn't support the Program Neighborhood attempts to connect to a MetaFrame 1.8 server, a dialog box informs the user that a new client is available and asks whether the user wants to update the client. Alternatively, you can set up the terminal server to automatically update without asking the user. Although ICA clients that support MetaFrame 1.0 don't require the user to reboot the client-side computer, the ICA clients that support MetaFrame 1.8 require a reboot regardless of whether you're pushing or pulling applications to the user desktop. Keep this reboot in mind when you plan client distribution. Also, you can download client protocols from the Citrix Web site at http://download.citrix.com. This Web site has a key that provides the release date for each client so that you can easily determine whether you have the most recent version.

To configure the client to work with the server farm, follow these steps:

1. Run the MetaFrame 1.8 client setup. Make sure that you have a MetaFrame 1.8-compatible client installed on the client side. You can run the setup from the server or client disks made from the server, or you can download the client from the Web.
2. Set up the application set. Open the Citrix Program Neighborhood on the client side. Click the Application Set Manager, then connect to the server farm. Follow the Find New Application Set wizard to supply the network connection type, server farm name, and color and sound support.

After you click the wizard's Finish option, the application set will be available from the client side and will display the applications to which the user has access (based on any group or user restrictions the server imposes).

The only catch to changing the application set is that the set doesn't immediately refresh on the client end when you change the configuration on the server end. To refresh the application set, users will need to reauthenticate themselves with the farm. To perform reauthentication, users can restart the computer, log off the domain, and log back on or reconnect to the server farm.

Now you know how to make the most of the Program Neighborhood feature by using server farms. You can try your hand at setting up a server farm, publishing applications in it, managing the servers in the server farm, and getting applications to the client. After you get used to the concepts and know which tools to use, server farms provide a surprisingly easy way to manage published applications in a terminal server environment and to manage the servers providing them.