Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Multiple Exchange Servers
- Thread starter vic102482
- Start date
During a migration that involves multiple servers, you should alway have a recovery plan.
1. Prior to upgrading from 5.5, you should have a full online backup of both the Information Store and DS.
2. Record connector and other configuration information.
3. If the source domain is pure NT 4, Create a new BDC, even if just in VMware or virtual PC, then take it off line.
With this, you could construct a 5.5 recovery environment to roll back if the migration goes south.
What you do next depend on the type of migration.
If the domain is mixed mode, you'll want at least a system state backup of the W2K/W2K3 domain controllers. This will allow a future authoritative restore if that becomes necessary. It also helps with recovery of non-clustered E2K and E2K3 servers. Do a full online backup of each E2K/E2K3 server.
With the information stored in the system state backups and your Exchange full online backups, it's easy to quickly rebuild and recover a single server. In E2K/E2K3 configuration information is stored in Active directory, Simply reset the old computer account in ADUC, Build a new box with the same name and rejoin the domain, then install Exchange with the /disasterrecovery switch. After it installs, restore your databases.
Falure of a single cluster node is very simple. Evict the failed node, reset the computer account, rebuild, rejoin the domain, rejoin the cluster, then load Exchange and supporting software.
In situations where all cluster nodes fail, you can still recover. You reset the computer accounts, in adsiedit remove the server object for the EVS in the administrative group, rebuild your cluster, reload exchange with the same EVS name, recreate your storage groups and stores with the same names, and restore the databases. You'll need to strip the mail attributes off all users that were on the cluster, but this can easily be done by searching based on Home server. If it's E2K you'll use mbconn to reconnect the mailboxes, or if it's E2K3 you can simply use the built-in mailbox recovery center.
I spent a few days after a recent migration walking a customer though each of these scenarios. Even the total cluster rebuild took only restore time plus three hours. The single server scenarios were under restore time plus two hours. The key lesson learned were:
1. Size your databases to meet your SLA time for restores.
2. On clusters, when in doubt kick it out. Evicting and rebuilding a single node was by far the fastest.
1. Prior to upgrading from 5.5, you should have a full online backup of both the Information Store and DS.
2. Record connector and other configuration information.
3. If the source domain is pure NT 4, Create a new BDC, even if just in VMware or virtual PC, then take it off line.
With this, you could construct a 5.5 recovery environment to roll back if the migration goes south.
What you do next depend on the type of migration.
If the domain is mixed mode, you'll want at least a system state backup of the W2K/W2K3 domain controllers. This will allow a future authoritative restore if that becomes necessary. It also helps with recovery of non-clustered E2K and E2K3 servers. Do a full online backup of each E2K/E2K3 server.
With the information stored in the system state backups and your Exchange full online backups, it's easy to quickly rebuild and recover a single server. In E2K/E2K3 configuration information is stored in Active directory, Simply reset the old computer account in ADUC, Build a new box with the same name and rejoin the domain, then install Exchange with the /disasterrecovery switch. After it installs, restore your databases.
Falure of a single cluster node is very simple. Evict the failed node, reset the computer account, rebuild, rejoin the domain, rejoin the cluster, then load Exchange and supporting software.
In situations where all cluster nodes fail, you can still recover. You reset the computer accounts, in adsiedit remove the server object for the EVS in the administrative group, rebuild your cluster, reload exchange with the same EVS name, recreate your storage groups and stores with the same names, and restore the databases. You'll need to strip the mail attributes off all users that were on the cluster, but this can easily be done by searching based on Home server. If it's E2K you'll use mbconn to reconnect the mailboxes, or if it's E2K3 you can simply use the built-in mailbox recovery center.
I spent a few days after a recent migration walking a customer though each of these scenarios. Even the total cluster rebuild took only restore time plus three hours. The single server scenarios were under restore time plus two hours. The key lesson learned were:
1. Size your databases to meet your SLA time for restores.
2. On clusters, when in doubt kick it out. Evicting and rebuilding a single node was by far the fastest.
- Status
Similar threads
- Locked
- Helpful tip
- Locked
- Question
