ForestPrep is only required to prepare the forest for Exchange. Likewise, DomainPrep prepares the domain for Exchange....
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
If your Exchange server is not installed on a domain controller, then you do not need to run either.
If your Exchange server is a domain controller, but it is not the only domain controller in your forest, you will not need to run ForestPrep. Likewise, if it's not the only domain controller in your domain, you will not need to run DomainPrep again. If it is the last domain controller in the domain or in the forest, then you'll need to restore Active Directory first.
To reinstall Windows on the Exchange server:
- Back up the stores and the System State.
- Copy the folder(s) that holds your Exchange databases and logs -- by default \EXCHSRVR\MDBDATA -- to an alternate location.
- Reinstall the operating system and service packs to bring it up to the same level as the previous installation.
Now you can reinstall Microsoft Exchange using the /disasterrecovery switch:
- Go to a command prompt window.
- Type the path of the Exchange setup executable (if installing from the CD, this is
:\setup\i386\setup.exe) followed by "\disasterrecovery."
- When you see the component selection window, verify all the components that were installed previously are set to disaster recovery.
If you do not use the /disasterrecovery switch, setup will run in Reinstall mode, which may cause data loss.
This process uses the configuration information stored in Active Directory to rebuild your server.
If your previous Exchange installation had Exchange Server 2003 Service Pack 1, you will also need to apply the Service Pack using the /disasterrecovery switch. Install any Exchange updates that were installed earlier.
Finally, copy the stores you backed up earlier to their original location and mount them.
I read your answer and I must say it is pretty good. I have a few questions related to this that have probably been asked a million times:
- Do these steps also apply if you uninstall Exchange from one DC and then install it on a different DC (in an Exchange 2003/Windows 2003 server environment)?
- Does the /disasterrecovery switch work in the scenario above? Does it restore the system state from backup and move the mailbox stores to the other server?
In my head it seems a bit awkward, but I have not done an uninstall and re-install on a completely different server before.
No, that is not the course of action you would follow to move an Exchange installation from one domain controller to another, nor is it the intended purpose of the /disasterrecovery switch.
These are the recommended steps:
- Install Exchange Server on the second or new domain controller.
- Move mailboxes to the new Exchange server.
- Replicate public folders to the new server. (The pfmigrate.wsf script does a great job of this.)
- If the Exchange installation on the first domain controller is the first Exchange server in the administrative group (or the only one), make sure you designate the new server as the site folder server, rehome any connectors, and follow the instructions in Microsoft KBA 822931: How to remove the first Exchange Server 2003 computer from the administrative group.
- If the new Exchange server will receive inbound Internet mail, make the necessary firewall changes to make the new server accessible on the Internet. This generally involves creating a Network Address Translation (NAT) rule on the firewall to map the internal IP address of the new server to an external IP address provided by your ISP, and creating an access rule to allow inbound SMTP traffic to that server. Test the firewall changes by telnetting to the SMTP port using the server's external IP address: telnet x.x.x.x 25
- Set up external DNS:
- Create an A record to map the new server's external fully-qualified domain name (FQDN) to the external IP address. Test the new A record from outside: nslookup servername.yourdomain.com
- Create a new MX record with a higher preference value and test: nslookup -type=MX yourdomain.com
- You can shut down SMTP service on the old Exchange server, to determine if Internet mailflow works through the new server. This is optional.)
- If the above works, switch the priority values in both MX records so the new server has the lowest value.
- If the old server provided access to any other services like HTTP/HTTPS (for Outlook Web Access, Exchange ActiveSync, Outlook Mobile Access, RPC over HTTP, etc.), IMAP4 and POP3, then make sure the new server is accessible on those ports from the Internet. This will require creating access rules on your firewall for those ports. In case of HTTPS, you may have to either export the certificate with the private key (if using the same external FQDN) from the old server, and installing it on the new server. Or if using a different FQDN, request and install a new SSL certificate on the new server with the appropriate name.
- Shut down Exchange services on the old Exchange server for a day or two.
- If all looks good, uninstall Exchange Server from the old Exchange server.
- Remove the MX record (and A record, if not required any more) pointing to the old server from the external DNS.
Do you have comments on this Ask the Expert Q&A? Let us know.
Related information from SearchExchange.com:
Dig Deeper on Microsoft Exchange Server Backup and Disaster Recovery
Related Q&A from Bharat Suneja
Find out how to troubleshoot problems scripting Exchange Server email disclaimers and signatures.continue reading
Learn how to bulk modify alternate recipients and other Active Directory objects in Exchange Server 2003.continue reading
Discover tools and methods to globally disable IMAP and POP in Microsoft Exchange Server 2003.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.