This document covers maintenance issues that might be encountered while administering a Presentation Server farm. This document is a supplement to the Administrator’s Guide and Advanced Concepts Guide. Consult the Administrator’s Guide and Advanced Concepts Guide for updated information pertaining to any of the below strategies before implementing them.
Backup and Recovery Strategies
This section discusses methods for maintaining the server farm’s data store.
MSDE Databases
Use DSMAINT BACKUP to backup the MSDE database. Specify a local path for the location of the database backup files. Essentially, this command uses a default OSQL script to backup the database. Use DSMAINT RECOVER to restore a previously backed up copy of the MSDE database for use as the IMA data store.
If you wish to create customized OSQL scripts for backup, refer to the following Microsoft article for further details: http://support.microsoft.com/default.aspx?scid=241397
To move an MSDE Database from one server to another follow CTX104941 - How to Move a Microsoft SQL Server Desktop Engine Data Store From One Server to Another
Access Databases
While there is no built-in backup scheduler with Access, Presentation Server includes the DSMAINT BACKUP command for backing up the Access data store. Citrix recommends that this command be executed daily using a scheduler script.
WARNING! Do not use DSMAINT BACKUP to back up Microsoft SQL Server or Oracle databases.
To move or restore an Access data store
Follow this procedure to install a backup of the data store or move an original data store to a new host server in the event of a hardware failure or upgrade:
1. Copy the backup database or the original database to the server that is to become the new host server.
2. On the new host server, create a new “File DSN” pointing to the new local database from Step 1.
3. On all servers in the farm, execute dsmaint failover to point to the new host server.
Note: The IMA Service must be running on these servers for the command to execute properly. You must do this before executing dsmaint config on the new host server as specified in the next step; otherwise the other servers in the farm cannot write to the database.
4. On the new host server, execute dsmaint config to point the IMA Service to the newly created DSN file from Step 2. If no security was set on the Access database, use the default user account and password information (citrix/citrix).
Note: Include the full path (in quotes) in the /dsn: switch to the file dsn. For example, /dsn:"C:\Program Files\Citrix\Independent Management Architecture\MF20.dsn"
WARNING! This fix requires you to edit the registry. Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
5. Change the original host server to its new role as an indirect server (it will now access the data store indirectly through the new host server) by running the Registry Editor (Regedt32.exe) and changing the value of the following registry key from Imaaccess.dll to Imaodbc.dll:
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\DatabaseDri ver
Note: If you are performing these steps with a MetaFrame XP Feature Release 3 farm, the previous step is no longer necessary. With a MetaFrame XP Feature Release 3 server, running the command dsmaint failover new_direct_servername on the original host server removes the value in the registry. Feature Release 3 no longer uses the value Imaodbc.dll for indirect servers.
6. Stop and restart the IMA Service on the new host server.
7. When the IMA Service on the new host server is running, stop and restart the IMA Service on all of the other servers in the farm.
Important: Restarting the IMA Service instead of restarting the server might cause the SNMP service to Dr. Watson if SNMP is enabled. This error is benign.
Microsoft SQL Server and Oracle Databases
When using a Microsoft SQL Server or Oracle data store, consult the database documentation for scheduling automated backups of the data store. In most cases, daily backup is sufficient to prevent loss of farm data.
In a situation where a backup must be restored to a new database server, each farm server requires a new DSN file and updated registry information for the new database.
Tip: The following procedure can also be used to change DSN files whenever the IMA Service connection information changes.
Use the following steps to restore a backup database. For the best performance, execute this procedure on the data collectors after all other servers are reconfigured:
1. Restore the database.
2. Create a new DSN file that points to the restored database.
3. Execute the dsmaint config command on the server with the new DSN file.
4. Stop and restart the IMA Service.
Important: Restarting the IMA Service instead of restarting the server might cause the SNMP service to Dr. Watson if SNMP is enabled.
5. Verify that the server is using the correct DSN by checking at the following registry setting:
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\DataSourceN ame
6. If the IMA Service started successfully, copy the DSN file created in Step 2 to all servers in the farm.
7. Execute the dsmaint config command to change the IMA service configuration on all servers in the farm.
8. Stop and restart the IMA service on all servers in the farm.
Compacting Access Databases
Servers hosting the data store have both a local host cache database file (Imalhc.mdb) and a data store database file (Mf20.mdb). Use dsmaint compactdb on both these files on a regular basis. Citrix recommends creating a script that executes nightly to compact both databases and back up Mf20.mdb.
Servers not hosting the data store have only the local host cache database file (Imalhc.mdb) that can be compacted occasionally to improve performance.
Note: You can execute the dsmaint compactdb command while the server is running.
Cycle Booting Presentation Servers
Presentation Server does not require regular cycle booting to run effectively. However, if cycle booting is required for some other reason, follow the guidelines below.
When the IMA Service starts after restarting the server, it establishes a connection to the data store and performs various reads to update the local host cache. These reads can vary from a few hundred kilobytes of data to several megabytes of data, depending on the size and configuration of the farm.
To reduce the load on the data store and to reduce the IMA Service start time, Citrix recommends maintaining cycle boot groups of no more than 100 servers. In large farms with hundreds of servers, or when the database hardware is not sufficient, restart servers in groups of approximately 50, with at least 10 minute intervals between groups.
Note: If the Service Control Manager reports that the IMA Service could not be started during a cycle boot of a Presentation Server but the service eventually starts, ignore this message. The Service Control Manager has a time-out of six minutes. The IMA Service can take longer than six minutes to start because the load on the database exceeds the capabilities of the database hardware. To eliminate this message, try rebooting fewer servers at one time.
Changing Farm Membership of Servers
Presentation servers require the use of the chfarm command to change farm membership. The correct use of the chfarm command that ships with Presentation Server is discussed below.
WARNING! Misuse of chfarm can corrupt the data store.
CTX736659 - How to Change Farm Using the "chfarm" Utility
CTX101787 - Installation Manager concerns when executing CHFARM
CTX124833 - Feature Release 2 Features do not Appear in the Citrix Management Console After Running chfarm
CTX101877 - An error occurred while attempting to start the IMA Service. Event ID 3612, 3609, 3601, 7024, 2147483670
Using chfarm
The chfarm command requires the use of the Presentation Server installation files; therefore, you can execute it only from the installation CD-ROM or a network image of the CD-ROM. Use the Chfarm.exe file in the Presentation Server subdirectory in the directory for your operating system (W2K for Windows 2000, TSE for Windows NT 4.0, Terminal Services Edition).
WARNING! If chfarm reports any error, continuing the process can corrupt the data store. Instead, use the process for restoring an unresponsive server to change farms.
Executing chfarm
Executing chfarm does the following on the host server:
• Attempts to remove the server from the farm.
• Stops the IMA Service.
• Uninstalls the IMA Service and removes the local IMA settings.
• Executes the IMA installation component of the Presentation Server installation program. Setup is a wizard that gathers farm configuration information:

• o Data store setup includes the choices Create a new server farm or Join an existing server farm.
  o To create a new server farm, the Data Store Configuration page presents options for the data store database.
  o To join an existing server farm, the Data Store Type page presents options for direct or indirect connection to the data store.
  o When creating a new server farm, you enter the farm name. When joining an existing server farm, you enter the information necessary to connect to the farm’s data store.
  o The wizard asks for the name of the zone in which to install the server.

• Reinstalls and starts the IMA Service.
• Initializes the license database.
Warning! Do not cancel the chfarm setup process after the IMA installation process begins. Complete the entire process and then rerun it if necessary. Failing to complete this process corrupts the data store and leaves Presentation Server only partially installed without the option to uninstall using Add/Remove Programs.
Chfarm Usage Notes
Be aware of the following important issues and procedures when using chfarm:
• Because chfarm deletes the current data store database, do not use chfarm on the server hosting the Access database until all other servers in that farm are moved to a new farm. Failure to follow this process causes errors when attempting to execute chfarm on those servers that no longer have a valid data store.
• Use chfarm to change the farm for the server that will host the new data store first (if using an Access database). Then execute chfarm on all other servers to join them to the newly created farm.
• Close all connections to the Citrix Management Console on the local server before executing the chfarm command.
• Execute chfarm only on a fully functioning Presentation server. Do not execute chfarm on a server that was removed from a farm (either through Citrix Management Console or with chfarm).
Note: Using chfarm does not migrate published applications or any server settings to the new server farm.
Replacing Presentation Servers
Sometimes it is necessary to take a Presentation server offline for routine maintenance or emergency hardware repairs, for example.
Any Presentation server that does not host the data store can be easily replaced with a similarly configured replacement server. Change the name of the replacement server to the same name as the offline server and then start the replacement server.
Warning! When both the offline and replacement servers have the same server name, only one of the servers can be running on the network.
A replacement server must have Presentation Server installed and must have the same configuration as the offline server, including drive mappings and applications, to ensure a seamless transition.
Use the qfarm command to verify that the correct IP address is being reported for the replacement server. If it is not correct, restart the replacement server.
Note: You use the same process when replacing a server from a cloned image.
Migrating Server Farms and the Data Store
Use the dsmaint command to migrate a Presentation Server farm to a different type of data store (for example, from Access to Microsoft SQL Server, or from Microsoft SQL Server to Oracle).
Database Migration Between Different Versions
Consult the appropriate Presentation Server Administrator’s Guide and Advanced Concepts Guide.
The following is an excerpt from the current Presentation Server 4.0 Administrator’s Guide, page 58:
Migration of a farm data store to Microsoft SQL Server is supported for the database versions listed in the following table. For information about data store migration, see “DSMAINT” on page 368.

Original platform
Target platform
Microsoft Access
SQL Server 7 with SP3
Microsoft Access
SQL Server 2000
Microsoft Access
SQL Server 2000 with SP1
MSDE
SQL Server 2000
Oracle 8.1.6
SQL Server 2000 with SP1
Oracle 8.1.7
SQL Server 2000 with SP1
Oracle9i
SQL Server 2000 with SP1
IBM DB2 with FixPak 5
SQL Server 2000 with SP1
SQL Server 7 with SP4
SQL Server 2000 with SP3
The dsmaint command can migrate farm data between databases (dsmaint migrate) and reconfigure servers to use the new database (dsmaint config).
The syntax for the dsmaint migrate and dsmaint config commands is shown below (type the respective command as one continuous string at a command prompt):
EX: dsmaint migrate /srcdsn:dsnfilename /srcuser:username /srcpwdassword /dstdsn:dsnfilename /dstuser:username /dstpwdassword
EX: dsmaint config /user:username /pwdassword /dsn:dsnfilename
Where:
dsnfilename = The DSN file for the database, including the full path.
username = The user name for the database.
password = The password for the database.
Migration can be performed with users logged on to the farm. Stopping and restarting the IMA Service does not affect currently connected sessions. However, no new connections are allowed until the IMA Service is completely restarted.
Important: Restarting the IMA Service on more than 10 servers simultaneously can cause the database server to become a bottleneck, resulting in startup delays.
Use the following steps to migrate from Access to Microsoft SQL Server or Oracle:
Note: Migration from an Access indirect database to a Microsoft SQL Server 2000 direct database using the dsmaint migrate command is supported only with MDAC 2.5.
1. Create a new database on Oracle or Microsoft SQL server.
2. Create a new Mf20.dsn file pointing to the new database created in Step 1. By default, the DSN file is located in the following directory: %ProgramFiles%\Citrix\Independent Management Architecture.
3. On the host server, execute the dsmaint migrate command, entering the current DSN file as the source and the new DSN file created in Step 2 as the destination. If the password for the old database is not changed, the default user name/password is citrix/citrix.
Tip: Enter the complete path (inside quotation marks if the path contains spaces) of the DSN file when required as a parameter for the dsmaint migrate command.
4. Execute dsmaint config on the original host server to point to the new DSN file.
5. Stop and restart the IMA Service on the host server. When the IMA Service on the host server is restarted, the remaining indirect servers begin accessing the new data store indirectly through the host server.
Important: Restarting the IMA Service instead of restarting the server might cause the SNMP service to Dr. Watson if SNMP is enabled. This error is benign.
6. Copy the DSN file created in Step 2 to all remaining indirect servers in the farm.
7. Execute dsmaint config on all remaining indirect servers to establish a direct connection to the new database through the DSN copied in Step 6.
8. Stop and restart the IMA Service on all remaining indirect servers in the farm.
Tip: You can execute Steps 6 through 8 on all the servers from a simple batch file placed in a central location.
Migrating from Microsoft SQL Server or Oracle
This section discusses migrating data store information between versions of Microsoft SQL Server and Oracle.
To migrate the database, use the following steps. For the best performance, execute this procedure on the data collectors after all other servers are reconfigured.
1. Create a new database on the destination server (Oracle or Microsoft SQL Server).
2. Create a new DSN file that points to the database created in Step 1.
3. Execute the dsmaint migrate command on the server with the new DSN file created in Step 2.
4. Execute the dsmaint config command on the server from Step 3.
5. Stop and restart the IMA Service on the server from Step 4.
Important: Restarting the IMA Service instead of restarting the server might cause the SNMP service to Dr. Watson if SNMP is enabled. This error is benign.
6. Verify that the server is using the correct DSN by checking at the following registry settings:
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\DatabaseDri ver
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\DataSourceN ame
7. If the IMA Service started successfully, copy the DSN file from Step 2 to all servers in the farm.
8. Execute the dsmaint config command to change the IMA Service configuration on all servers in the farm.
9. Stop and restart the IMA Service on all servers in the farm.
Tip: You can execute Steps 7 through 9 on all the servers from a simple batch file placed in a central location.
Migrating the Database to the Same Version
Migrating from one database version to the same database version might be necessary to move the data store to a more powerful server, for example. The best method for migrating between same-version databases is to back up and restore the database using the utilities provided by the database software vendor.
Use the following steps to point a Presentation Server farm to a new database. For the best performance, execute this procedure on the data collectors after all other servers are reconfigured.
1. Back up the existing farm database and restore the database to the new server.
2. Create a new DSN file that points to the database restored in Step 1.
3. Execute the dsmaint config command on the server with the new DSN file from Step 2.
4. Stop and restart the IMA Service.
Important: Restarting the IMA Service instead of restarting the server might cause the SNMP service to Dr. Watson if SNMP is enabled. This error is benign.
5. Verify that the server is pointing to the new data store by looking at the following registry setting:
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\DataSourceN ame
6. If the IMA Service started successfully, copy the DSN file created in Step 2 to all servers in the farm.
7. Execute the dsmaint config command to change the IMA Service configuration on all remaining servers in the farm.
8. Stop and restart the IMA Service on all servers in the farm.
Tip: You can execute Steps 6 through 8 on all the servers from a simple batch file placed in a central location.
An alternative method for migrating between same version databases is to use the export/import process instead of a backup and restore process. Microsoft SQL Server 7 uses OLE for the export/import functions, which truncates any binary data greater than 256 bytes. As such, using export/import on Microsoft SQL Server requires that the following steps replace Step 1 above:
1. Export data from the original (source) database and import data into the new (destination) database using the standard export/import procedures described in the database vendor’s documentation.
2. In the destination database, delete the table DATATABLE. This table contains the truncated data as described above.
3. Execute the following SQL command (on one line) in the destination database context to re-create the DATATABLE table with non-truncated data:
SELECT * INTO DATATABLE FROM [SourceServerName].[SourceDBName].dbo.DATATABLE;
Note: The brackets in the above SQL command are required if the name contains a space or special character. In addition, you must register the source server with the new database server as a linked server and the source server must be running when the SQL command is executed.
4. Re-create the following indexes on DATATABLE:
DATATABLEINDEX cluster index on nodeid DATACONSISTENT unique index on (nodeid and partno)
Note: You can re-create the index by choosing Run a Wizard > Database > Create Index Wizard from the Enterprise Manager Console.
5. Follow Steps 2 through 8 above to complete the database migration process.
Migrating to Access
Migration from Microsoft SQL Server or Oracle to Access is not supported at this time.
Uninstalling Presentation Server
Best Practices and TroubleShooting Downgrade / Uninstall Issues With MetaFrame 1.8/XP
The uninstallation sequence is designed to remove all Presentation Server registry keys on the server, all Presentation Server files on the server, and all references to that server in the data store, including published applications, load management rules, trust relationships, and so on. Therefore, the best practice for removing a server from a farm is to uninstall the server while it still has a connection to the farm.
Important: If uninstalling an entire Presentation Server farm that uses Access for its data store, uninstall the server that hosts the data store last. Failure to do so prevents the uninstallation process from completing successfully on the other farm servers.
If the uninstallation fails, it might be necessary to perform a forced uninstallation using the rmvica command.
Uninstalling Presentation Server from a server that was upgraded removes all previous MetaFrame installations. However, if Feature Release 1 for MetaFrame 1.8 was installed before the upgrade to MetaFrame XP, some files and registry keys are left after uninstalling MetaFrame XP. To easily remove these components, uninstall Feature Release 1 through Add/Remove Programs in the Control Panel.
Do not uninstall Presentation Server on the server hosting the Access database for a server farm until all other servers are removed from the farm or the farm database is moved to a different host server.

Source

__________________
PSP

>> Advanced Concepts - Farm Maintenance