Server Farm Mainenance - Citrix MetaFrame XP

Throughout the life of your MetaFrame XP implementation, you will most likely need to change some of the configuration parameters of your server farm.

Throughout the life of your MetaFrame XP implementation, you will most likely need to change some of the configuration parameters of your server farm. Let's look at the following fairly common maintenance tasks:

  • Changing zones.
  • Changing farm membership.
  • Changing the IMA data store.
  • Replacing servers.
  • Renaming servers.

Changing Zones

Moving a server between zones is very common in the real world. This is especially true for new MetaFrame XP environments that are growing and changing rapidly. Fortunately, changing a MetaFrame XP server's zone is easy to do via the Citrix Management Console (CMC | Server | Properties | Zones Tab). From here, zones can be created, deleted, and renamed.

At installation time, all MetaFrame XP servers on the same subnet are automatically configured to be members of the same zone.

Changing Farm Membership

As your MetaFrame XP environment grows, it may become necessary to move servers from one MetaFrame XP server farm to another. Fortunately, this is a simple process, automated by the "chfarm" utility which is included on the MetaFrame XP CD. CHFARM is located in the W2K\MF or TSE\MF directory. With FR-2/SP-2, it's is located in the MF\Program Files\Citrix \System32\Citrix\IMA directory.

Remember that each MetaFrame XP server farm has its own IMA data store. If you change the farm membership of a server, you are really removing it from one data store and adding it to another.

CHFARM is a GUI application that leads you through the process of changing a server's farm membership. The CHFARM utility requires the MetaFrame XP installation files in order to work properly because it essentially reruns the MetaFrame XP setup program beginning with the farm membership questions.

The CHFARM utility performs several tasks:

  1. CHFARM removes the server from the current farm. To do this, it:
    1. Stops the local IMA service.
    2. Uninstalls the IMA service.
    3. Removes all local IMA settings.
  2. CHFARM installs the server into the new farm. To do this, it:
    1. Launches the MetaFrame setup program, starting with the farm setup screen. From here, you can choose to create a new farm or to add the server to an existing farm.
    2. Installs the IMA service.
    3. Starts the IMA service.
    4. Reinitializes the licensing database.

If you decide to use the CHFARM utility, there are some factors that you should be aware of:

  • If you cancel part way through the CHFARM process, you run the risk of breaking everything without the ability to recover.
  • CHFARM deletes the old local IMA Data Store. If the server you are changing is a host to other MetaFrame XP servers, those servers will no longer work. If you would like to migrate many servers that use an Access IMA data store, migrate the server that hosts the data store last.
  • Close any CMC connections before you use the CHFARM utility. If you do not close them, they will be dropped when the CHFARM utility stops the IMA service.
  • You cannot use CHFARM if a server was removed from a farm through the CMC. Removing a server from a farm through the CMC deletes all of the server's information from the IMA data store. The CHFARM utility will not be able to locate that server's information.
  • CHFARM does not migrate any published applications or configuration settings. If these settings are different in the new farm, you will need to manually reconfigure them on the server.

Migrating to a New IMA Data Store

Often it's necessary to migrate the IMA data store from one database platform to another. This is usually the case when MetaFrame XP environments start out small with an Access IMA data store. After some growth, administrators choose to migrate the data store to a more robust platform, such as SQL Server, Oracle, or DB-2.

The DSMAINT utility is used to configure parameters and data relating to the IMA data store. The DSMAINT utility serves two purposes:

  • To migrate data from an old data store to a new data store during IMA data store platform migrations.
  • To reconfigure MetaFrame XP servers to point to new data stores (without changing their farm membership).

Migrating IMA Data

The DSMAINT command-line utility can be used to migrate from Access to SQL, Oracle, or DB-2. It can also be used to migrate from between SQL, Oracle, and DB-2. DSMAINT cannot be used to migrate data from Oracle, SQL, or DB-2 to Access.

In order to use DSMAINT, you must have the necessary parameters for your old data store (source) and your new data store (destination). Those parameters include the DSN, the username, and the password. Once you have these parameters, use the following syntax at the command-line to use DSMAINT. The DSMAINT utility is located in the %systemroot%\system32\ Citrix\IMA\ directory, but MetaFrame XP adds this folder to your PATH statement when it's installed so you should be able to execute this command from any location.

dsmaint migrate /srcdsn:dsnfilename /srcuser:username
/srcpwd:password /dstdsn:dsnfilename /dstuser:username
/dstpwd:password

The "migrate" option of the DSMAINT command does not reconfigure the local server to use the new database. It simply copies all of the information from the old database into the new database. It is possible to run the DSMAINT migration command with users logged into the MetaFrame XP server.

Reconfiguring a Server's IMA Data Store Connection

The DSMAINT utility can also reconfigure MetaFrame XP servers to point to new data stores. This is most often used to point all farm servers to the new database just after a database migration. Using DSMAINT to reconfigure the IMA data store connection requires three parameters for the new connection: the DSN to be used, the username, and the password. Use the following syntax to connect to a new data store:

dsmaint config /user:username /pwd:password /
dsn:dsnfilename

After the server is reconfigured for the new data store, you should stop and start the IMA service so that it connects to the proper data store. You can perform this IMA data store reconfiguration with users logged in because stopping and starting the IMA service does not kick off current users-it only prevents new users from logging in (while the IMA service is stopped).

Replacing MetaFrame XP Servers

Every so often, it will become necessary for you to replace MetaFrame XP servers. This may be because a server had a hardware failure or because a server is being upgraded to a more powerful server.

In traditional environments, it was necessary to remove the old server and all of its related configuration information and to install a new server and manually reconfigure it as needed.

Fortunately, there is a shortcut when replacing MetaFrame XP servers. All of the information stored in the IMA data store is based on each server's computer name. There is no unique serial number or SID. One MetaFrame XP server can be removed and another server with the same computer name can be installed and the new server will get all of the settings and configurations of the old server. The IMA data store will not realize that the server ever changed.

To replace a MetaFrame XP server:

  1. Turn off the old server. Do not use any tools to remove this server from the farm. If you do, all of the server's information will be removed from the IMA data store and the entire automatic replacement will be pointless.
  2. Turn on the new server. Make sure that the computer name of the new server is identical to the computer name of the old server that it is replacing.
  3. Run "dsmaint config" to point the new server to the proper IMA data store.
  4. Stop and start the IMA service. This will ensure that the new server points to the proper data store and that it is initialized with the current information in the new data store.
  5. Run "qfarm" to ensure that everything looks good.
  6. Verify the licensing information.

The only caveat to this is that only the information stored in the IMA data store is retained for the new server. This includes farm roles and published application information. Configuration elements that are local to the server are not retained, such as Citrix connections. Refer to the Appendix for a full list of all configuration information and where it is stored.

If you choose to replace a server in this manner, make sure that the applications that were published on the old server are located in the same paths on the new server. The IMA data store keeps a record of the applications that are published on each server, but it does not check to see whether the application paths are valid. If your old server had a published application called "Word" with the command line c:\Program Files\Office\Office10\winword.exe and the new server has Word in the path c:\office\winword.exe, you would need to change the properties of the published application for the new server. If you do not change the properties, users will not be able to access the published application on the new server.

Renaming a MetaFrame XP Server

It is possible to rename a MetaFrame XP server that is a member of a server farm. However, in doing so, you will lose any published application configuration information for that server. If your published applications are load balanced across multiple servers, this should not be a problem. You can just add the applications back to the server after it has been renamed. To rename a MetaFrame XP server:

  1. Remove the server from any lists of published applications. This does not mean that you have to physically uninstall any applications. It just means that you should use the CMC to remove the server from the application lists.
  2. Stop the IMA service.
  3. Delete the file wfcname.ini from the root directory of the system drive (if the file exists).
  4. Change the server name.
  5. Reboot the server.
  6. Once the IMA service starts after the server has been rebooted, the server's zone membership will be reset to the default zone. If this is not appropriate, change the zone membership via the CMC.
  7. Use the CMC to reconfigure any published applications that were removed in Step 1.

 

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close