Restoring a Broken Exchange Cluster

Rebuild a two-node MSCS with the same configuration (i.e., NT domain role and network name) as the broken cluster.

Update each cluster node to the same NT service pack you were running when you made the last backup.

If you use backup software other than NT Backup, install the backup software on each node and apply any fixes that were present when you made the backup.

Install Exchange on this cluster with the same organization name, site name, server name, and Exchange service NT account SID as the broken Exchange Server. (Using these same names and SID account is essential for successfully restoring the cluster, but these elements aren't related to the cluster technology.)

Install any additional Exchange services (e.g., Event Service, Outlook Web Access—OWA) you had on your broken cluster. (Note that clusters don't officially support OWA, although some administrators have been able to implement it.)

Install the connectors (e.g., X.400, the Internet Mail Service—IMS) that were on the broken Exchange cluster. You don't need to configure these connectors exactly as they were on the broken server.

If the broken Exchange cluster had cluster-aware antivirus software, install and configure it as it was on the broken server.

Update the Exchange cluster server to the Exchange service pack that was running when you made the last backup.

Select one resource (e.g., the Microsoft Exchange System Attendant) in the Exchange cluster group. Select the resource properties, enter the active node in the Possible owners box, and delete the inactive node from the list. This setting, which Screen 1 shows, will eliminate the possibility that the Exchange cluster group will fail over to the inactive node, in case a problem (e.g., a power outage) occurs while you're restoring Exchange on the active node.

From the Cluster Administrator program, select the option to take all Exchange services offline.

Using Cluster Administrator, bring the Exchange System Attendant online. Select System Attendant, right-click, and select Bring online.

Catalog the backup sets on your backup tape, and select the Directory Service (DS) and IS databases that you want to restore.

Select the options not to overwrite the DS and IS transaction logs and not to restart services after the restore has completed.

When the restore has completed, check that the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeDSRestore in Progress Registry key is present on the active node. During an online restore, the backup program adds this key, which the process requires to recover from an online restore.

Reset the Registry checkpoint for the Microsoft Exchange Directory Service. Registry checkpointing is a procedure that provides consistency between the Registry setting for both nodes. When you change a Registry key that is replicated between nodes, that change is replicated to the inactive node.

Delete all existing data in the DSADATA and MDBDATA directories.

Restore the offline version of dir.edb to the DSADATA folder and priv.edb and pub.edb to the MDBDATA folder. If you're putting logs and the database on separate volumes, you'll have two folders with the same name, so be sure you put the files in the database folder. Also, restore only the files you need to replace the files you're having problems with; for example, you don't want to overwrite a good priv.edb.

Using Cluster Administrator, bring the DS online.

Open a command window, and set the _CLUSTER_NETWORK_NAME_ environment variable to the network server name that Exchange uses. For example, if your cluster name is ExcClu1, you run the command

C:> set _cluster_network_name_=excclu1

From the exchsrvrbin directory run the isinteg ­patch command by executing the code

exchsrvrbin> isinteg ­patch

The isinteg patch command ensures that new objects you create in the IS don't have the same GUID as other objects in your organization.

Reset the Registry checkpoint for the IS resource. (Step 5 in the previous section explains this procedure.)

Using Cluster Administrator, bring the IS back online.

Now you can restart all other Exchange services.

Reinstall NTS/E on the second node with the same NT configuration (i.e., NT domain) that you had before the disaster. The second server doesn't have the Clusterdisk driver installed because it doesn't have MSCS yet. This driver controls access to the disk shared between cluster nodes. While you're rebuilding the second node and before you've installed MSCS, you can access the shared disk even if the other node is accessing the disk and performing I/O on the shared volumes. In MSCS, only one node can access a shared physical disk at a time. The cluster disk driver, which you install with the cluster software, regulates access to the shared disk. Because the inactive node doesn't have the Clusterdisk driver yet, it can access the disk and seriously damage the logical configuration. If this access happens, you must run Chkdsk/f on the active node to correct the problem. Therefore, when you're installing NT, you must choose the correct system drive (i.e., the local hard disk) on which to install the system files, without disturbing the shared disk with any kind of I/O.

The safest way to protect the shared drives in this special and temporary configuration is to disconnect the shared disk array's cables from the second node, if the hardware configuration permits. (The MSCS documentation on the second NTS/E CD-ROM provides more information.) If you can't disconnect the cables, turn off the active node and the shared disk array while you're installing NT and the appropriate service packs on this server.

Install the MSCS on this node (choose Join to existing cluster in the Cluster Setup program), and install the last NT service pack that was running on the active node.

Run Cluster Administrator, and choose a cluster resource (e.g., the Microsoft Exchange System Attendant resource) that belongs to the Exchange group resource. (Exchange must run in a resource pool called a group, which contains at least an IP address, a disk, and a network name.) Set the active node as possible owner for this resource. This setting is useful for avoiding cluster failover to the second node during all the next steps; a failover at this time would be unsuccessful because you haven't installed Exchange services locally yet.

Install Exchange on the second node, selecting Update node in the Exchange Setup program.

Install the last Exchange service pack that you were using for the Exchange cluster server.

Remove the Possible owner setting you selected in step 3, and verify that all resources have both the first and the second node as possible owners.

Configure the failover/failback setting on the Exchange resource group.

If you use additional cluster services (e.g, antivirus, backup tools), install them on this node.