Before we dive into the details of what it takes to integrate MetaFrame XP with MetaFrame 1.8, let's study some basic concepts relating to the interaction of MetaFrame XP and MetaFrame 1.8.
First, we'll look at the three levels of MetaFrame XP and how they compare to MetaFrame 1.8's add-on packages. Then, we'll see how MetaFrame XP servers can be configured for various levels of interaction with MetaFrame 1.8 servers. We'll also review some of the key MetaFrame 1.8 architectural components-components that you'll need to understand to successfully build an environment consisting of MetaFrame 1.8 and XP servers.
MetaFrame 1.8 and XP Product Level Correlations
Unlike the multiple product levels available with MetaFrame XP, MetaFrame 1.8 came in one version-MetaFrame 1.8. (Technically, there were two different packages, MetaFrame 1.8 for Windows NT 4 Terminal Server Edition, and MetaFrame 1.8 for Windows 2000. However, these two packages were 100% identical from a features standpoint.) Additionally, there were several option packs that could be purchased a la cart to extend MetaFrame 1.8's basic functionality. Those options are detailed in Figure 13.1 (facing page).
Option Pack: Function
- Load Balancing: Publish applications across servers
- Resource Management Services: Performance management
- Installation Management Services: Automate the installation of applications across multiple servers.
- SecureICA: Encrypt ICA sessions.
- Feature Release 1: Added functionality that is now standard in MetaFrame XP. Replaced the Secure ICA add on.
Figure 13.1: MetaFrame 1.8 add-on management services
With MetaFrame XP, there are different levels with different features that roughly correspond to versions of MetaFrame 1.8. Of course, MetaFrame XP has dozens of other benefits over MetaFrame 1.8, but Figure 13.2 shows the basic equivalencies.
XP Level: Old Rough Equivalent
- MetaFrame XPs: MetaFrame 1.8
- MetaFrame XPa: MetaFrame 1.8 + Load Balancing Pack
- MetaFrame XPe: MetaFrame 1.8 + Load Balancing Pack + Resource Management Services + Installation Management Services
Figure 13.2: Correlations between MetaFrame 1.8 and XP products
MetaFrame XP Interaction with MetaFrame 1.8
MetaFrame XP servers must be configured to enable or disable interaction with older MetaFrame 1.8 servers. This configuration, set for an entire MetaFrame XP server farm, is known as the "mode of operation." MetaFrame XP server farms can be configured for one of two modes of operation: native mode or mixed mode. Native mode is used when no MetaFrame 1.8 servers exist and MetaFrame XP servers are operating "natively" in their own language and only with their own kind. Mixed mode is used when MetaFrame XP servers will be in "mixed" environments, communicating with other MetaFrame XP and MetaFrame 1.8 servers. Some other aspects of each mode of operation are shown below.
Native Mode (MetaFrame XP server farms operating in Native Mode)
- MetaFrame XP servers communicate with only other MetaFrame XP servers.
- No interoperability with MetaFrame 1.8 servers. (They don't even know that they exist.)
- Designed for the final state, for organizations after all MetaFrame 1.8 servers have been migrated to XP and no more MetaFrame 1.8 servers exist.
Mixed Mode (MetaFrame XP server farms operating in Mixed Mode)
- Server farms may contain both MetaFrame 1.8 and XP servers.
- MetaFrame XP servers communicate with XP and 1.8 servers.
- MetaFrame 1.8 and XP servers appear to ICA clients as one unified farm. Clients do not know (or care) to which platform they actually connect.
- Designed for periods of migration, this mode allows MetaFrame 1.8 and XP servers to be integrated with each other while the migration is taking place.
- MetaFrame XP Feature Releases cannot be used.
The "mode of operation" for a MetaFrame XP server is a farm-wide setting. Changing the mode of the server farm changes the operating mode of all the MetaFrame XP servers in the farm. There is no way to set the mode on a server-by-server basis (unless each server is its own farm). The mode of a MetaFrame XP server farm can be changed at any time, and changed in any direction (native-to-mixed and mixed-to-native). There is no limit to the number of times that a farm can change modes. The server farm's mode is configured via the Citrix Management Console (CMC | Farm Properties).
You can only set the mode of operation for MetaFrame XP server farms. MetaFrame 1.8 server farms do not have a mode of operation-they are always operating with other MetaFrame 1.8 servers only or mixed-mode MetaFrame XP servers.
MetaFrame 1.8 Technical Components
Before we progress too far into looking at the details of integrating MetaFrame XP server farms with MetaFrame 1.8 server farms, let's review the technical components of a MetaFrame 1.8 environment to ensure we have a full, fresh understanding of how they work. For this review, we will only focus on the MetaFrame 1.8 components relevant to integration with MetaFrame XP servers: the ICA Browser and the Program Neighborhood services.
Last century, MetaFrame 1.8 servers ran a service known as the "ICA Browser Service." This service performed many of the tasks that the IMA service and data store handle for MetaFrame XP servers today.
When multiple MetaFrame 1.8 servers exist on the same subnet, they collectively appoint one of them to become the "ICA Master Browser" through an election process similar to the zone data collector elections that take place in MetaFrame XP. The ICA master browser is responsible for maintaining information about user connections, published applications, ICA licenses, and server load. An ICA client can request information about the MetaFrame environment by sending out a broadcast on UDP Port 1604 requesting the information. The elected ICA master browser responds to the ICA client with the appropriate information. If something happens to the ICA master browser causing it to become unavailable, a new election is held to appoint a new ICA master browser.
One ICA Master Browser must exist on each subnet on which MetaFrame 1.8 runs. If MetaFrame 1.8 server farms span multiple subnets, then "ICA Gateways" must be defined to relay ICA browser information from one subnet to the other.
The ICA browser architecture of MetaFrame 1.8 is inefficient, a far cry from the IMA architecture of MetaFrame XP. But, when it comes to the integration of MetaFrame 1.8 servers with MetaFrame XP servers, the ICA browser service is the lowest common denominator. It is the only method of information sharing that MetaFrame 1.8 servers understand, and so we have no choice but to work with it.
Program Neighborhood Service
In addition to the ICA browser service, the Program Neighborhood service plays a big role in MetaFrame 1.8 server farms. It too has been replaced by the IMA service in MetaFrame XP.
The Program Neighborhood service is responsible for building application lists and keeping track of those applications which are available on MetaFrame 1.8 servers. A web of persistent server connections is created, as every MetaFrame 1.8 server creates a connection with every other MetaFrame 1.8 server in the farm. For example, ten MetaFrame 1.8 servers will have 45 connections between them, as shown in the following formula:
Be careful not to confuse the Program Neighborhood service with the Program Neighborhood client. The two are not the same. The latter is an ICA client executable that displays the results of the former.
Mixed Mode Server Farms
Setting a MetaFrame XP server farm to mixed mode will enable the XP servers to communicate and integrate with 1.8 servers. You can then publish and load-balance applications across both platforms. Users will see one unified server farm that consists of MetaFrame 1.8 and XP servers.
Mixed mode is designed to be a temporary solution-to only be used for integration between MetaFrame 1.8 and XP servers. Citrix is very adamant about this. Of course, they have a vested interest (from the revenue standpoint) in moving everyone to XP. Rather than making a recommendation, let's look at all the aspects of mixed mode operation. You can be the judge as to whether this is something you want to support in your environment for an extended period of time.
For mixed mode farm operation, we will look at the following technical components:
- IMA Service
- Server Farm Design
- Administration Tools
- ICA Browser Service
- ICA Client to MetaFrame Server Communication
- Network Ports and Protocols
- Published Applications
- Load Balancing
In order for a MetaFrame XP server farm to interoperate and communicate with MetaFrame 1.8 servers, it is necessary for the MetaFrame XP servers to fully emulate the MetaFrame 1.8 environment. Remember that MetaFrame XP completely replaced the Program Neighborhood service and ICA browser service with the new IMA service and architecture. This is great for pure (native) MetaFrame XP environments, but MetaFrame 1.8 servers are not able to communicate with or understand the IMA service. As a result, MetaFrame XP servers operating in mixed mode must run the legacy ICA browser and Program Neighborhood services in addition to the IMA service and all of its components (zones, IMA data store, etc.). Running these services might seem like a high price to pay for simple interoperability, but it is absolutely necessary since the architecture changed so drastically from MetaFrame 1.8 to MetaFrame XP.
The following chart details the differences in the IMA service between MetaFrame XP servers running in native mode and mixed mode.
When a MetaFrame XP server farm is set for mixed mode operation, a flag is set in the IMA data store. All MetaFrame XP servers check that flag to see which mode of operation they should be set to, and their IMA services are configured accordingly. MetaFrame XP servers check for the mode setting flag when the IMA service is started and periodically after that. Because of this, MetaFrame XP servers do not need to be rebooted in order to switch from native to mixed mode or vice versa. When the MetaFrame XP servers notice that the flag has been modified, they modify their configuration of the IMA service as outlined in Figure 13.3.
Figure 13.3: IMA mixed and native mode differences
Server Farm Design
Contrary to everything discussed so far, it is not technically possible to create one server farm that includes both MetaFrame 1.8 and MetaFrame XP servers. However, you can create two separate server farms (one for each platform) that have identical names.
Once both farms have the same name, the ICA browsers from each platform will share information-enabling the mixed mode, multi-platform integration.
From the management perspective, the MetaFrame 1.8 and MetaFrame XP mixed mode farms are two different farms. They must each be managed with their own versions of the management tools. Naming them identically does not allow them to be managed as one farm.
MetaFrame XP and MetaFrame 1.8 farms must each be managed by its native administration tools. In addition to the Citrix Management Console for managing MetaFrame XP servers, the MetaFrame XP CD contains updated versions of the MetaFrame 1.8 administration tools that should be used to manage MetaFrame 1.8 servers that are participating in mixed mode XP server farms.
Let's look at some specific features of the updated administration tools for MetaFrame 1.8, included on the MetaFrame XP CD:
- Citrix Server Administration Utility. The version of Citrix Server Administration that is included with MetaFrame XP has been modified to allow configuration of MetaFrame 1.8 and MetaFrame XP servers, as long as the MetaFrame XP servers are operating in mixed mode.
- Published Application Manager. Published Application Manager should not be used to manage applications that have been migrated to MetaFrame XP servers. It can be used to manage published applications on MetaFrame 1.8 servers in mixed mode farms. See the published applications section of this chapter for more details.
- Shadow Taskbar. In native mode, the shadow taskbar only displays MetaFrame XP servers. Mixed mode farms allow the Shadow Taskbar to be used for MetaFrame 1.8 and MetaFrame XP servers.
- License Manager. The Citrix License Manager will continue to manage licenses for MetaFrame 1.8 servers, even in mixed mode farms. MetaFrame XP licenses, regardless of the server farm mode, are managed through the Citrix Management Console. See Chapter 14 for more information.
- Citrix Connection Configuration. Citrix server connections are basically the same on MetaFrame 1.8 and MetaFrame XP servers. Because this information is server specific, connection configurations are stored in the local server's registry. Use this tool to configure connections on MetaFrame 1.8 or XP servers, operating in farms that are native or mixed mode.
ICA Browser Service
The real reason ICA clients can view MetaFrame 1.8 and MetaFrame XP servers as a unified farm in mixed mode environments is that both server platforms join information to form one unified ICA browser service. The unified ICA browser maintains information about applications and servers across both platforms.
Any MetaFrame XP server that is part of a server farm operating in mixed mode will automatically participate in ICA master browser elections. Thinking back to Citrix classes from a few years ago, you undoubtedly remember that the number one ICA master browser election criterion is the version of the ICA browser software. Since MetaFrame XP is newer than MetaFrame 1.8, if there is a MetaFrame XP server on the same subnet as a MetaFrame 1.8 server, the XP server will always win the ICA master browser election, regardless of its configured election preference.
If a single MetaFrame 1.8 server farm spans multiple subnets, ICA gateways are used to pass ICA browser information between the subnets. Because mixed mode MetaFrame XP farms fully emulate the ICA browser service of MetaFrame 1.8 farms, ICA gateways can exist in XP mixed farms.
Two servers are needed to form an ICA gateway, one to initiate the gateway and one to receive. These gateway servers can be configured with Citrix Server Administration (All Servers | ICA Gateways). Any MetaFrame 1.8 servers that are migrated to MetaFrame XP will retain their ICA gateway role.
ICA Client to MetaFrame Server Communication
Let's look at how ICA clients interact with MetaFrame servers in mixed mode farms. An ICA client will contact a MetaFrame server for the following reasons:
- Application Launch. The client needs to get the address of the server to run the application.
- Find New Application Set. The client needs to get the list of applications that are available in the server farm.
An ICA client always uses one of the two high-level methods described below to contact MetaFrame servers. Refer to Chapter 10 for more.
- Default Server Location. The ICA client is preconfigured with known addresses of MetaFrame servers. The client systematically steps through the list, trying individual addresses, until a server responds.
- Auto-Locate. The ICA client has no idea where the server is. It sends out a generic broadcast request or tries to connect to a generic address. If this fails, the client request fails.
If a MetaFrame XP server farm is operating in mixed mode, XP servers will respond to ICA client "auto-locate" broadcasts. In a mixed mode environment, it really doesn't matter whether a 1.8 or an XP server responds because it doesn't matter which platform the ICA client successfully contacts. Because the servers of both platforms share information via the communal ICA browser service, the ICA client can receive information about applications on both platforms by contacting a server from either platform.
In reality, the ICA clients don't ever know (or care) to which platform they connect. The Default Server Location configuration on ICA clients can point to MetaFrame 1.8, XP, or a mixture of both.
Network Ports and Protocols
MetaFrame XP servers operating in mixed mode will require the ports and protocols of MetaFrame XP servers and MetaFrame 1.8 servers.
For interaction with MetaFrame 1.8 servers, ICA browser communication will take place via UDP Port 1604. The standard IMA communication for MetaFrame XP will also take place over TCP port 2512.
Full port communication and usage information for both modes of operation can be found in the Appendix.
When a MetaFrame 1.8 server is migrated to MetaFrame XP, any published applications on that server are automatically upgraded, regardless of whether the target server farm is running in mixed mode or native mode. These applications are immediately accessible to end users, and you can begin administering the applications via the Citrix Management Console. A log file created in the %systemroot%\system32\ directory contains details regarding published applications that were migrated.
Complications arise in environments in which applications are published in a load-balanced fashion across multiple servers. If all of the servers to which an application is published are upgraded to MetaFrame XP at the same time, then there are no problems. The challenges occur when you need to make changes to a published application that is published to multiple servers after some of those servers have been upgraded to MetaFrame XP and some of them are still MetaFrame 1.8.
In order to understand the complications that could arise, let's take a look at the differences in how MetaFrame 1.8 and MetaFrame XP servers store configuration information for published applications.
First, consider the many components required of applications published to multiple MetaFrame platforms, including:
- MetaFrame 1.8 Servers
- MetaFrame XP Servers
- Citrix Management Console (for managing published applications on MetaFrame XP)
- Published Application Manager (for managing published applications on MetaFrame 1.8)
Each of the components plays specific roles, as outlined below.
Citrix Management Console (CMC)
- Connects to the IMA data store.
- Reads / writes published application configuration to the IMA data store.
- Capable of configuring XP servers only.
Published Application Manager (PAM)
- When launched, it systematically connects to the registry of every server in the farm, including XP and 1.8 servers. (It gets the server list from the ICA master browser via UDP port 1604.)
- Reads / writes published application configuration to the registries of each server.
MetaFrame XP Servers Operating in Mixed Mode
- Maintain published application configuration in the IMA data store.
- Because they are in mixed mode, they also maintain published application configuration in their local registries, for the purposes of backward compatibility with MetaFrame 1.8 servers and PAM.
MetaFrame 1.8 Servers
- Maintain published application configuration in their local registries.
Now that we've outlined how the components relate to each other when working with applications published across MetaFrame 1.8 and MetaFrame XP servers, let's take a look at the troubles that could arise. There are actually five different scenarios that could cause problems in this situation:
Potential Trouble Scenario 1
If you publish an application to the MetaFrame XP servers by using the CMC, you will not be able to publish that application to the MetaFrame 1.8 servers.
Why does this Happen?
When you use the CMC to publish an application to the MetaFrame XP servers, the servers write the published application information to the IMA data store. But, because the servers are operating in mixed mode, they also write the published application information to their local registries. Then, when you open Published Application Manager (PAM) to publish the application to the MetaFrame 1.8 servers, PAM connects to the registries of all the servers in the server farm, including the MetaFrame XP servers operating in mixed mode. When you try to add your application to the MetaFrame 1.8 servers, you will receive an error indicating that the application name is already in use, because PAM knows that the application is published on the MetaFrame XP servers from when it connected to their registries. If, as a work-around, you decide to publish the application under a different name on the MetaFrame 1.8 servers, it will not be load-balanced with the MetaFrame XP version of the application.
If you want to publish a new application to both platforms, you must publish it with Published Application Manager to the MetaFrame 1.8 servers first, and then publish it with the CMC to the MetaFrame XP servers.
Potential Trouble Scenario 2
If there is an application that is published across MetaFrame 1.8 and XP servers, the application's icon disappears when the Published Application Manager that ships with MetaFrame 1.8 is refreshed. It will reappear after PAM is closed and opened again.
Why does this Happen?
When you launch the version of Published Application Manager that ships with MetaFrame 1.8, it reads the registry of every single MetaFrame server in the server farm (in this case, both MetaFrame 1.8 servers and MetaFrame XP servers in mixed mode). From these servers, it builds a list of all the published applications in the farm. When you refresh the application list from within PAM, it only reads the registry of the MetaFrame XP servers. (Call it a "bug.") The registries of the MetaFrame XP servers (operating in mixed mode) list only the applications that are published locally. They do not list all of the servers that have the applications published, which is unlike the registries of MetaFrame 1.8 servers. With MetaFrame XP, the list of all servers that have an application published is stored in the IMA data store, not the local server's registry.
The MetaFrame XP CD includes an updated version of Published Application Manager. The above problem will only occur if you are using the version of PAM that ships with MetaFrame 1.8.
Potential Trouble Scenario 3
If a published application is modified with the version of Published Application Manager that ships with MetaFrame XP, that same application cannot be later modified with the version of PAM that ships with MetaFrame 1.8.
Why does this Happen?
The version of Published Application Manager included with MetaFrame XP has been modified and recognizes applications differently than previous versions.
Ideally, you should not modify any published application properties while your server farm is operating in mixed mode. (Remember that mixed mode is a "temporary" solution.) If this is absolutely necessary, the best method is to use the new version of Published Application Manager included on the MetaFrame XP CD.
Potential Trouble Scenario 4
When mixed mode farms are being created, many administrators choose to automatically migrate the published applications on the MetaFrame 1.8 servers that they are migrating to XP. However, if circumstances force you to add or modify a published application on both platforms before all of your 1.8 servers have been migrated to XP, then you should not migrate any published applications on the remaining 1.8 servers when you migrate them to XP.
Why does this Happen?
When the first server in a MetaFrame 1.8 server farm is migrated to a MetaFrame XP server in a mixed mode farm, a snapshot is taken of all published applications that are automatically migrated during the upgrade process. Any applications that are modified or added during the migration (i.e. after the first but before the last server has been migrated) cause inconsistencies, because these modifications or additions are not reflected in the snapshot that was taken. If you attempt to migrate any of these published applications that have been modified or added, it will have a random eight character suffix appended to the end of its name in the new environment to ensure that it is not integrated with a previously migrated version.
Migrate the MetaFrame 1.8 server to XP without migrating any published applications. Then, use the Citrix Management Console to manually add the recently migrated server to the configured server list for the published application.
Alternately, you could choose not to modify the properties of any published applications until after your migration from MetaFrame 1.8 to XP is complete.
Potential Trouble Scenario 5
After a published application has been automatically migrated from MetaFrame 1.8 to XP, the new XP server will still show up in the configured server list from within Published Application Manager. However, if you use PAM to remove the XP server from the configured server list, you will not be able to use PAM to add the XP server back.
Why does this Happen?
Published applications on MetaFrame XP servers can only be managed with the Citrix Management Console, not Published Application Manager.
Manage the application with the Citrix Management Console.
Published Application Migration Summary
In summary, given all the goofy things that can happen with published applications in mixed environments, there are two golden rules for working with published applications in mixed mode:
- Do not make changes to or add published applications after they have been migrated to MetaFrame XP on some servers and not migrated on others.
- When administering mixed mode farms, always use the updated versions of the MetaFrame 1.8 tools that shipped on the MetaFrame XP CD.
Now, let's continue progressing through our list of topics that you need to understand for mixed mode environments. Load balancing next.
Most real world environments have published applications load balanced across multiple servers. In a mixed mode server farm, it is possible to load balance published applications across MetaFrame 1.8 and MetaFrame XP servers.
As previously discussed, when publishing applications that are to be load balanced across both MetaFrame 1.8 and XP platforms, there are a few quirks that must be considered. Because you can only use the native tools to work with each platform, you must publish an application to MetaFrame 1.8 servers in the farm using Published Application Manager and publish the same application to MetaFrame XP servers using the Citrix Management Console. The published application must have the same name (case sensitive) on both platforms or MetaFrame won't realize that it's the same application.
After the application is published to both platforms, you can use each platform's native tools to configure load balancing. Let's look at what happens when an ICA client launches a published application that is load balanced across MetaFrame 1.8 and mixed mode MetaFrame XP servers:
- The user clicks an icon to launch the published application.
- The ICA client requests the address for the least loaded server from the ICA master browser. In this case, the ICA master browser will be a MetaFrame XP server.
- The ICA master browser looks at the load of all the MetaFrame XP servers and chooses the least loaded.
- The ICA master browser then looks at the load of all the MetaFrame 1.8 servers and chooses the least loaded.
- The ICA master browser compares the two semifinalist servers (one XP and one 1.8) by looking at number of active sessions. The address of the server with the least number of active sessions wins and is sent to the ICA client. If there is a tie, XP wins.
This approach is needed because the load balancing algorithms used in MetaFrame 1.8 and MetaFrame XP are totally different. You should not be surprised if the server load is not "perfectly" balanced across platforms.
In mixed farm environments, any Load Evaluators attached to applications on MetaFrame XP servers (see Chapter 4) are ignored, because those evaluators could not apply to the instances of the applications on the MetaFrame 1.8 servers. When configuring Load Evaluators for XP servers that have published applications shared across platforms, you should only use the default load evaluators.
In mixed mode environments, you can use two different command-line tools to get information about load balanced applications-qfarm and qserver. The qserver tool has been around since before MetaFrame XP. Using qserver will display information obtained from the ICA master browser. Qfarm is the new tool for use with MetaFrame XP. It queries the zone data collector. If you want accurate information about applications load balanced across MetaFrame 1.8 and XP platforms, you should always use qserver.
MetaFrame 1.8 ICA licenses can be pooled between XP and 1.8 servers. However, because the licensing models for MetaFrame 1.8 and MetaFrame XP are so different, there are several requirements that must be met:
- The MetaFrame servers must reside on same subnet for license pooling to work.
- The MetaFrame XP ICA master browsers convert MetaFrame 1.8 license gateways to regular ICA gateways.
- MetaFrame XP ICA connection licenses are statically assigned to subnets that contain other XP farm servers. This means that XP connection licenses cannot be pooled across subnets (just like 1.8 licenses).
Basically, in mixed mode farms, MetaFrame XP will break the license gateway and you will only be able to pool licenses on local subnets, though you will be able to combine 1.8 and XP licenses for that local subnet pool. More MetaFrame licensing details are discussed in Chapter 14.