Verify permissions. As I explain in Part 1, you must have Exchange Full Administrator permissions to upgrade an Exchange 2000 cluster. Applying service packs, however, can cause permissions to be reset to their default values. Before and after you apply a service pack, verify permissions on the administrative group in which your EVS resides. (By default, Exchange System Manager—ESM—doesn't show security settings. To enable the Security tab, add the REG_DWORD entry ShowSecurityPage to the HKEY_CURRENT_USER\Software\Microsoft\Exchange\ExAdmin registry subkey and set the entry's value to 1.)
Test upgrades. Create a parallel test environment so that you can try out service packs, hotfixes, and third-party products before deploying them in production. (Many third-party products aren't supported on clusters and might require some customization to work properly.) Exactly replicating your production configuration might not be cost-effective, but consider implementing a test cluster that uses virtual server technology, such as VMware, to test third-party products. Cluster-aware third-party applications create cluster resources in Cluster Administrator; you can move these resources between nodes as failover operations are performed. For third-party products that don't create cluster resources, however, be sure that you can automatically shut down and start the products on cluster nodes during failover and failback operations.
One benefit of using clusters with Exchange is the ability to perform rolling service pack upgrades to minimize downtime for end users. A rolling upgrade entails moving the EVS to one node and performing the installation on the passive node, then failing back the cluster and upgrading the other node. For example, suppose you have a two-node cluster in which node 1 is the active node with one EVS (EVS1) and node 2 is the passive node with no active cluster resources. First, back up node 2, apply the Exchange service pack to node 2, then move EVS1 to node 2. Check the Application log for errors and verify that Exchange starts correctly on node 2. Assuming that everything is working as it should, back up node 1 and apply the service pack to that node. Move EVS1 back to node 1, check the Application log for errors, and verify that Exchange starts correctly on node 1. Take a full backup of the cluster, including the system state on each node and the Exchange databases.
Better Clusters
The guidelines in this two-part article series can help you achieve success when deploying Exchange 2003 or Exchange 2000 clusters. One last bit of advice for improving performance on Exchange 2000 clusters: Take a look at the improvements in Windows 2003 and Exchange 2003 clusters. (For more information, see "Exchange Server 2003 Clusters," November 2003, InstantDoc ID 40457.)