Compartilhar via

How to Move All Exchange Virtual Servers from a Production Exchange 2003 Cluster to a Standby Exchange 2003 Cluster

  • Artigo

 

Tópico modificado em: 2006-01-16

A standby Microsoft® Exchange cluster is a Microsoft Windows Server™ cluster that:

  • Matches the production Exchange cluster in terms of hardware and software configuration, including Microsoft Windows® and Exchange versions and software updates.
  • Has Exchange program files installed on it, but is not yet configured with any Exchange Virtual Servers.
  • Can be used only when all Exchange Virtual Servers on the production cluster are offline.

This topic describes how to move all of the Exchange Virtual Servers from a production Exchange 2003 cluster to a standby Exchange 2003 cluster. This process can be used when recovering from the loss of the entire production cluster, or as a site resilience solution for Exchange 2003 clusters. This topic assumes that you are familiar with Windows clustering concepts, as well as how Microsoft Exchange Server 2003 works in a Windows cluster environment.

A Windows Server 2003 cluster can host multiple Exchange Virtual Servers. It is possible to move all the Exchange Virtual Servers from one Windows cluster to another Windows cluster.

When transferring Exchange Virtual Servers from a production cluster to a standby cluster, all of the Exchange Virtual Servers in the production cluster must be moved. No Exchange Virtual Server(s) should be running on the production cluster.

Dica

This process is only supported for Exchange Server 2003 clusters running on Windows Server 2003. The process described in this topic cannot be applied to, and is not supported for, Exchange 2000 Server or Exchange Server 5.5.

When the Exchange System Attendant resource is deleted on an Exchange 2000 cluster using Cluster Administrator, all Active Directory® directory service objects associated with the Exchange Virtual Server are deleted, and the Exchange Virtual Server is removed.

With Exchange 2003 clusters, deleting the System Attendant resource does not delete or affect the Active Directory objects associated with the Exchange Virtual Server. To completely remove the Exchange 2003 Virtual Server, you must right-click the Exchange System Attendant cluster resource or Exchange resource group and then select Remove Exchange Virtual Server.

This change in behavior from Exchange 2000 can be used to transfer an Exchange Virtual Server from a production Exchange 2003 cluster to a standby Exchange 2003 cluster.

This topic is limited to explaining how to transfer Exchange Virtual Servers from a production cluster to a standby cluster. Strategies for replicating or restoring existing user data to the standby cluster are not covered in detail in this topic.

Exchange 2003 Standby Cluster Requirements

Because the standby cluster will reuse the information already stored in Active Directory, the following requirements must be met to configure an Exchange standby cluster:

  • The standby cluster hardware configuration should be listed in the Cluster Solutions category in the Windows Server Catalog.

  • The public network interface on the standby cluster should reside in the same IP subnet as the production cluster.

    Dica

    It is possible to have the standby cluster installed in a different IP subnet; however, you should review “Implications of Changing the IP Address of the Exchange Virtual Server” later in this topic for more information about changing IP subnets.

  • The standby cluster cannot host any Exchange Virtual Servers from any other clusters.

  • The operating system version is Windows Server™ 2003 Enterprise Edition.

  • The operating system service pack and hotfixes installed on the standby cluster should be at the same versions as those installed on the production cluster.

  • Exchange Server 2003 binaries, service pack, and hotfixes should be pre-installed on all nodes of the standby cluster and match the versions installed on the production cluster.

  • The standby cluster node(s) IP address(es) and computer name(s) must not conflict with any other IP address or computer name on the network.

  • The standby Cluster IP address and Cluster Network Name resources must not conflict with the Cluster IP address or Cluster Network Name of any other cluster on the network.

  • The standby cluster physical disk resources configuration must match the same drive letters in use by Exchange on the production cluster.

    Dica

    The standby cluster can be configured as a single-node cluster only if the production cluster is a two-node active/passive cluster that hosts one Exchange Virtual Server. If the production cluster hosts more than one Exchange Virtual Server, the standby cluster must have at least one passive node to respect the N+1 rule.

All Exchange Virtual Servers hosted on the production cluster must be moved together to the standby cluster. Microsoft does not support dispersing multiple Exchange Virtual Servers from one cluster to multiple, separate standby clusters.

Procedure

To install the standby cluster

  1. You should install the standby cluster with the same configuration as the production cluster and ensure that it meets the requirements listed earlier.

  2. Although the hardware for the standby cluster does not necessarily need to be the same as the production cluster, it is recommended that the standby cluster have the same general capabilities to preserve the performance and reliability levels of the production cluster.

  3. Ensure that the standby cluster is configured with an appropriate resource group to host the Exchange cluster resources.

  4. Ensure that the Exchange resource groups on the standby cluster contain physical disk resources representing the same drive letters in use by Exchange on the production cluster. These drives must not contain any previous Exchange data.

  5. For more information about installing Exchange Server 2003 in a cluster, see the Exchange Server 2003 Deployment Guide.

To move the Exchange Virtual Servers to the standby cluster

  1. Ensure that all Exchange Virtual Servers are offline on the production cluster.

  2. Ensure that the physical disk resources that will be used by Exchange on the standby cluster do not contain any previous Exchange data.

  3. On the standby cluster, create the Exchange IP address resource and bring it online. The Exchange IP address resource should be created with the same IP address configured for the Exchange Virtual Server on the production cluster. See “Implications of Changing the IP Address of the Exchange Virtual Server” later for more information.

  4. On the standby cluster, create an Exchange Network Name resource. The Exchange Network Name resource must match the Exchange Network Name of the production cluster, and the “DNS Registration must succeed” and “Enable Kerberos” check boxes must be selected.

  5. Bring the Exchange Network Name resource online.

  6. Verify that you can ping the Exchange Network Name by name.

  7. On the standby cluster, create the Exchange System Attendant resource.

    Dica

    Since the Exchange Virtual Server name already exists in Active Directory, the options to specify Path, Administrative Group, and Routing Group will be unavailable.

  8. After you successfully create the Exchange System Attendant resource, bring all Exchange resources online. Due to Active Directory replication latency, all resources may not come online in the first attempt. In this case, wait for replication to occur, and then attempt to bring the resources online again.

    Dica

    At this point, if the Exchange databases are not present, the Exchange Information Store cluster resource will start successfully; however, the databases will remain dismounted. If the databases are present in their configured locations, they will be mounted automatically.

  9. Implement your data restoration or recovery strategy, and then bring databases online. For general information about data recovery strategies, see “Recovering User Data” later in this topic.

To move the Exchange Virtual Servers from the standby cluster back to the production cluster

  1. Take the Exchange Network Name resource offline. This action will take all Exchange resources offline, as well.

  2. Delete the Exchange System Attendant cluster resource. This action will also delete all Exchange resources, but it will not remove the Exchange Virtual Server object from Active Directory.

  3. Delete the Exchange Network Name resource.

  4. Delete the Exchange IP address resource.

  5. Depending on the state of the production cluster, proceed with the following scenarios:

    1. If the production cluster needs to be rebuilt, follow the procedure "To rebuild the production cluster" later in this topic.
    2. If the production cluster is offline, but it does not need to be rebuilt, follow the procedure "To move the Exchange Virtual Servers back to the production cluster" later in this topic.

To rebuild the production cluster

  1. Rebuild the production cluster on the same or on new hardware.

  2. Restore or reconnect the storage hardware to the cluster ensuring that the same physical disk resources, drive letters, and paths are presented to the cluster.

  3. Install Exchange Server 2003, service packs, and hotfixes on all nodes.

  4. Follow the procedure below "To move the Exchange Virtual Servers back to the production cluster" later in this topic to complete the process.

To move the Exchange Virtual Servers back to the production cluster

  1. Bring only the Exchange IP Address resource online on the production cluster.

  2. Reset the Exchange computer account by opening the properties of the Exchange Network Name resource, clearing the Enable Kerberos check box and clicking Apply.

  3. Next, check Enable Kerberos and then click OK. This action will cause a reset on the Active Directory computer account used by the Exchange Virtual Server name.

  4. Bring the Exchange resources online.

Dica

Steps 2 and 3 can also be accomplished by using the following cluster.exe commands on the active cluster node, with the Exchange Network Name resource offline:
cluster res <Exchange Network Name> /priv RequireKerberos=0
cluster res <Exchange Network Name> /priv RequireKerberos=1

Implications of Changing the IP Address of the Exchange Virtual Server

Although it is strongly recommended that the standby cluster reside on the same IP subnet as the production cluster, some situations may require that the standby cluster be installed on a different IP subnet.

If the IP address for an Exchange Virtual Server changes, this change may delay bringing the server back online and cause temporary client connectivity issues because of latencies in Active Directory, WINS, and DNS replication, as well as client-side name cache updates.

After you change the IP address, the original Exchange Virtual Server IP address may remain in several places. In this scenario, the original values are read by the server cluster. Therefore, the cluster resources fail the IsAlive check and cannot remain online. For more information, see Microsoft Knowledge Base article 315691, “Events are logged after an IP address change on an Exchange cluster,” (https://go.microsoft.com/fwlink/?linkid=3052&kbid=315691).

Recovering User Data

This section focuses on transferring the logical configuration for an Exchange Virtual Server from a production Exchange 2003 cluster to a standby Exchange 2003 cluster. It does not discuss transferring existing mailbox data and folders. There are multiple strategies that can be used for replicating or restoring Exchange databases. This section provides an overview of these strategies, but it is not intended to provide detailed recommendations or procedures.

The most basic recovery strategy is to restore database backups to the standby cluster before bringing the cluster online. Restoring all data before users log on to the standby server is a relatively simple strategy from the perspective of the administrator. When the server comes online, it is in the same state as it was before the move, or at least all data that will be recovered has already been recovered.

A disadvantage of this strategy is that it can take a long time to restore large amounts of data, especially if the data must be transported across lengthy geographical distances. However, newer technologies such as Volume Shadow Copy Service (VSS) backups and storage-based replication can be used to reduce restoration time.

Dial tone recovery is a strategy that is somewhat more complex to administer, but it also has several advantages over a “restore first” strategy. Dial tone recovery is based on restoring e-mail send-and-receive service quickly while recovery efforts for previously existing data are done in parallel.

In a dial tone recovery, there is no immediate attempt to restore previous data. Instead, new Exchange databases are brought online in the standby cluster. Users are able to log on to Exchange and to send and receive new mail, even though their previous mailbox contents are currently unavailable.

Exchange provides facilities for merging the contents of two mailbox databases together. After previously existing databases have been restored and recovered, you can merge the new data from the dial tone database with the production database, and provide users with a single mailbox containing data from before and after the disaster. The merge operation can be done while Exchange is online.

For More Information

For more information about installing Exchange Server 2003 in a cluster, see the Exchange Server 2003 Deployment Guide.

For more information on the dial tone recovery strategy and merging mailboxes, see Using Exchange Server 2003 Recovery Storage Groups.