Add-on Management Services from 1.8 to XP - Citrix MetaFrame XP

Each of the MetaFrame add-on services (NFuse, Resource Management, and Installation Management) interacts with MetaFrame XP in a unique way.

Each of the MetaFrame add-on services (NFuse, Resource Management, and Installation Management) interacts with MetaFrame XP in a unique way. For the purpose of these services' interactions, we are concerned only with the interaction that occurs when MetaFrame XP server farms operate in mixed mode. Native mode XP server farms do not interact in any way with MetaFrame 1.8 server farms. The add-on management features of XP and 1.8 do not have anything to do with each other.

Let's take a look at each of the following add-on services:

  • NFuse Classic
  • Installation Manager
  • Resource Manager

We are not looking at the Network Manager add-on for MetaFrame XPe because there is no equivalent service in the MetaFrame 1.8 product line.

NFuse Classic

NFuse provides a means of accessing MetaFrame environments through exposed Java objects. NFuse itself is not actually part of MetaFrame 1.8 or XP. It does not need to run on a MetaFrame server. The current version of NFuse can communicate with both MetaFrame 1.8 and MetaFrame XP platforms.

Using NFuse in Mixed Environments

Not only does NFuse work well in mixed environments, it is the highly recommended method of simultaneously accessing multiple environments. NFuse web pages can be configured to build single lists of applications from multiple server farms, including servers that are MetaFrame 1.8 and MetaFrame XP. In fact, NFuse can be used to build application lists that contain published applications from native mode XP farms and 1.8 farms. Refer to Chapter 11 for more details.

Migrating NFuse from 1.8 to XP

NFuse will seamlessly plug into both platforms. In migration scenarios, NFuse is a preferred method of access. When end users access MetaFrame servers through NFuse, the NFuse server holds the configuration information for the ICA client. The end user only needs to know one configuration parameter-the NFuse web server's URL. Everything else is maintained on the NFuse server. This makes "cutovers" from 1.8 to XP simple. For example, you can configure an NFuse server to point to an old MetaFrame 1.8 server farm one day and a new MetaFrame XP server farm the next. Even with thousands of end users accessing the environment, everything is changed by the one NFuse parameter. This is not possible with traditional ICA clients.

Installation Manager

Installation Management Services (IMS) for MetaFrame 1.8 was released as an add-on management option. All IMS versions were variations of IMS 1.0x, with the most recent being 1.0b. Installation Manager is included with MetaFrame XP in the XPe product. This Installation Manager is essentially an upgraded version of IMS 1.0, and is known internally as IM 2.0. (IM 2.0 comes with MetaFrame XPe. Feature Release 1 updates MetaFrame XPe's IM to 2.1, and Feature Release 2 updates it to 2.2.)

Throughout this chapter, we will use three acronyms to differentiate the multiple versions of Installation Manager:

  • IMS 1.0x - Installation Management Services 1.0x for MetaFrame 1.8.
  • IM 2.0 - The Installation Manager component of MetaFrame XPe that is used without any XPe Feature Releases. This version of IM can be used in mixed mode farms.
  • IM 2.x - This refers generically to all versions of IM for MetaFrame XPe, regardless of the Feature Release level. Since MetaFrame XPe with any Feature Release cannot operate in mixed mode server farms, IM 2.x in this chapter is used to describe the upgrade path from IMS 1.0x to IM 2.x.

For the purposes of working with Installation Manager, it's important to remember that there is a difference between "packages" and "applications published via Installation Manager."

  • A package is the compiled scripted installation procedure that is created by the application packager portion of the Installation Manager software. These packages are then deployed to MetaFrame servers.
  • An application published via Installation Manager is the actual published application that is maintained on the MetaFrame servers. Users launching these published applications invoke the "packages" that were previously created with the application packager and deployed to multiple MetaFrame servers.

Installation Manager Technical Background

Installation Manager 2.x for MetaFrame XPe is covered in detail in Chapter 12. Even so, we'll take a brief look here at its technical components and the technical components of IMS 1.0x for MetaFrame 1.8. Though IM 2.x is essentially an upgraded version of IMS 1.0x, there are several changes that you must understand to be able to design an Installation Manager environment that works in both MetaFrame 1.8 and XP environments.

Installation Manager (across both platforms) consists of two components-the application packager and application installer.

IMS 1.0x and IM 2.x each have different versions of the application packager. IM 2.x can read IMS 1.0x packages, but IMS 1.0x cannot read IM 2.x packages.

The application installer and the associated IM service that runs on the MetaFrame servers has also changed from IMS 1.0x to IM 2.x. IM 2.x cannot read published applications that were created with IMS 1.0x.

This incompatibility occurs because IMS 1.0x packages use a "player" to run the published applications on MetaFrame 1.8 servers. In these environments, the published application path is not the executable of the application. The published application path is actually the IMS 1.0x package player (player.exe) and the package script (with the ".wfs" file extension). As long as the IMS 1.0x service is running on that server, the WFS script launches the IMS 1.0x player that reads the script, ultimately launching the published application. For example, if Microsoft Word is published with IMS 1.0x, the path for the published application in the MetaFrame 1.8 server's registry would be:

C:\Program Files\Citrix\Citrix Installer\player.exe word.wfs

In IM 2.x, this player no longer exists. The published application path for IM 2.x applications is the actual path, such as:

C:\Program Files\Microsoft Office\Office\winword.exe

Using Installation Manager in Mixed Environments

There are some cases, particularly in large environments, where a mix of MetaFrame 1.8 and MetaFrame XP servers will exist together. If Installation Manager is to exist in these environments, then it too must be a mixed environment, containing IMS 1.0x services for MetaFrame 1.8 and IM 2.0 services for MetaFrame XP. The two Installation Manager environments are able to partially interoperate with each other.

Application Packages

IMS 1.0x packages can be used by IM 2.0. To do this, you must manually add the package to the IM 2.0 system through the CMC. At this point, you don't technically have to make any changes to the package itself, although the packager that ships with IM 2.0 has many advanced packaging features that were not part of IMS 1.0x's packager.

If you would like to create new packages that are to be deployed to both IMS 1.0x and IM 2.0 servers, you may do so using the IMS 1.0x version of the application packager. Any packages created with the IM 2.0 packager will work without issues in mixed environments, but they will not be available to the IMS 1.0x environment.

Installation Manager Published Applications

When you introduce MetaFrame XP servers with IM 2.0 into your environment, there is no need to make any changes to your MetaFrame 1.8 servers running IMS 1.0x. The two platforms will not affect each other in any way. In fact, each platform's Installation Manager configuration components will continue to work independently of each other in mixed IMS 1.0x and IM 2.0 environments. To manage the IMS 1.0x environment, you must use the Published Application Manager that shipped with IMS 1.0x. To manage the IM 2.0 environment, use the Citrix Management Console. There is no way to use one tool for Installation Manager on both platforms (just as with regular published applications that must be managed separately in mixed environments).

In most organizations, this mixed mode scenario is a temporary solution, as old MetaFrame 1.8 servers are being upgraded to MetaFrame XP.

Migrating Installation Manager from 1.8 to XP

As servers are migrated from MetaFrame 1.8 to MetaFrame XP, you will most likely encounter servers using IMS 1.0x that will need to be migrated to IM 2.x. Fortunately, the migration process is automatic, with the installation of IM 2.x cleanly removing IMS 1.0x.

One migration task must be completed outside of the automatic setup of IM 2.x. Because IM 2.x does not use the "player" to launch IM published applications, the launch path of those published applications must be changed (from the player and WFS script to the actual executable location) before IM 2.x is installed. Citrix provides a utility that does this automatically. The utility, called IM_App_Upgrd.exe is located in the \support\debug\i386\ directory of the "Application Packaging & Delivery" CD included with MetaFrame XPe. This utility needs to be run on each MetaFrame 1.8 server with IMS 1.0x before it is migrated to MetaFrame XP.

After the IM_App_Upgrd.exe utility is used, published applications will still work on MetaFrame 1.8 servers. It's just that IMS 1.0x will no longer recognize them as an IMS 1.0x applications.

In an Installation Manager environment, the following steps must be taken to upgrade a server from MetaFrame 1.8 to MetaFrame XP:

  1. Run the IM_App_Upgrd.exe application migration utility.
  2. Migrate the MetaFrame 1.8 server to MetaFrame XPe.
  3. Install MetaFrame XPe's Installation Manager. The IM 2.x setup utility will detect the legacy version of IMS 1.0x, remove it, and install IM 2.x. Any published application settings associated with IMS 1.0x will be retained.

If a MetaFrame 1.8 server with IMS 1.0x is upgraded to MetaFrame XP and IM 2.x without first running the Im_App_Upgrd.exe utility, it is possible to manually migrate the applications. From the CMC, change the properties of each published application from the WFS script to the actual executable.

Regardless of how an IMS 1.0x application was migrated (with the utility or manually), you will not be able to use IM 2.x to automatically remove the application.

Resource Manager

Resource Management Services (RMS) for MetaFrame 1.8 was released as an add-on management option. All RMS versions were variations of RMS 1.0x, with the final version being RMS 1.0b. At the XPe level, MetaFrame XPe Resource Management is installed as the functional component of the System Monitoring & Analysis add-on.

Throughout this chapter, we will use two acronyms to differentiate between the two versions of Resource Management:

  • RMS 1.0x - Resource Management Services 1.0x for MetaFrame 1.8.
  • RM 2.x - The Resource Manager component of MetaFrame XPe. (RM 2.0 comes with MetaFrame XP. Feature Release 1 updates it to RM 2.1 and Feature Release 2 updates it to RM 2.2.)

Using Resource Manager in Mixed Environments

The Resource Manager 2.x software that ships with MetaFrame XPe is tightly integrated with MetaFrame XP. It requires MetaFrame XPe, both from a licensing and a technical standpoint. However, RMS 1.0x is not tightly integrated with MetaFrame. (In fact, it can be used on non-MetaFrame servers, or even workstations.) If you need to use a common resource management interface across both MetaFrame 1.8 and MetaFrame XP servers, use RMS 1.0x.

RMS 1.0x can be installed on MetaFrame XP servers. However, it must be installed after MetaFrame XP is installed. If you install RMS 1.0x before you install or upgrade to MetaFrame XP, you must manually reinstall the old Citrix licensing service (%systemroot%\system32\ctxlic\setup.exe). The MetaFrame XP installation will destroy the licensing engine used by RMS 1.0x. As an interesting side note, RMS 1.0x can be used with any version of MetaFrame XP, not just XPe.

Migrating Resource Management from 1.8 to XP

Because RMS 1.0x is very different from RM 2.x, there is no automatic upgrade path from RMS to RM 2.x. With the vastly increased functionality of RM 2.x, most organizations choose to redesign their Resource Management environments when migrating to MetaFrame XP.

 

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close