Microsoft Exchange 2000 Database Recovery Mike Lee Support Professional Product Support Services Microsoft Corporation

1. Microsoft Exchange 2000 Database RecoveryMike LeeSupport ProfessionalProduct Support ServicesMicrosoft Corporation

2. What We Will Cover • Important differences between Exchange 5.5 and Exchange 2000 • Fundamental principles of Exchange 2000 data preservation and recovery • Offline recovery • Highlights: SRS, KMS, Active Directory™, IIS metabase recovery

3. Differences • Windows® 2000 global Active Directory replaces the Exchange 5.5 server-centric directory database. • Mailboxes are attributes, not objects. • Public folder and other permissions are granted through Windows ACLs, not Exchange DNs.

4. Differences • Administrative Groups instead of Sites • Storage Groups (4 x 5 = 20 databases) • General purpose public folders • Database mounting • Streaming database

5. Fundamental Principles • System-centric versus server-centric view. • A problem in Active Directory can bring down the Exchange system. • Exchange disaster recovery and Active Directory disaster recovery teams should be closely integrated. • An unrecoverable disaster to your Certification Authority or Active Directory will render KMS unusable.

6. Exchange Data Storage • In Exchange 5.5, you can reconstruct an entire server from: • Database backups • A few registry settings (sometimes not even needed) • In transit queued messages

7. Exchange Data Storage (2) • In Exchange 2000, you may need all this to get your server going again (worst case): • Replacement hardware, installation disks, system configuration logs. • Full drive backups • System state backup (including metabase and system certificates) • Active Directory backup • Exchange database backups (IS, KMS, SRS) • Certification Authority backup • or . . . .

8. Exchange Data Storage (3) • If only the local server is involved in the disaster: • Run SETUP /disasterrecovery • Restore databases • SETUP /disasterrecovery reinstalls the server based on the configuration information in Active Directory. • If only the Exchange server is involved in the disaster, recovery is often simpler than in Exchange 5.5.

9. New Backup Capabilities and Differences • KMS and SRS databases can be backed up online. • No directory backups (AD is the directory). • Concurrent backup of different storage groups.

10. New Restore Capabilities and Differences • Services must be started, but databases not mounted to restore. • Restore in Progress registry key replaced with Restore.env file. • Hard recovery is manually triggered, not automatic. Select the Last Backup Set check box before restoring. • Restored log and patch files are restored to a Temp directory, not the running log directory.

11. Offline Database Recoveries • You can restore Exchange information store databases from one server to another server. • The usual reason for doing this is to recover a single mailbox after a user has inadvertently purged an important item. • It is also great recovery practice, because it is the same thing as having to recover after losing everything except the information store backups.

12. Recovery Server Setup in Exchange 5.5 • Install Exchange on a separate server (but can be on the same network). • Use the same Organization and Site names as the production site, but don’t join the real site during setup. • Service Accounts do not have to match.

13. Recovery Server Setup in Exchange 2000 • Install a new Active Directory forest (but it can be on the same network). • Set up DNS (if necessary). • Install Exchange 2000, using the same Organization name as the production organization.

14. Information Store Recovery in Exchange 5.5 • Restore databases to the offline recovery server. • Run DS/IS consistency adjustor to populate the directory from the mailbox tables. • Use a client application, such as Outlook® or Exmerge to access mailbox data.

15. Information Store Recovery in Exchange 2000 • Change the Administrative Group name to match the production Administrative Group • Change or add logical database and storage group names to match too. • Fix legacyExchangeDN values as necessary. • Restore databases. • Generate Active Directory user accounts and connect mailboxes to them. • Use a client application, such as Outlook or Exmerge to access mailbox data.

16. Setting Up DNS on a Recovery Server • Install DNS from the Windows 2000 CD. • Run IPCONFIG /ALL and write down your current DNS server and your own IP address. • In your Network and Dial-up Connection properties, change your DNS server to your own IP address.

17. Setting Up DNS on a Recovery Server (2) • Run the DNS management console (Dnsmgmt.msc) • Configure a standard primary forward lookup zone for your domain. The zone name should be the same as your recovery server domain name. • On the zone’s properties, set Allow Dynamic Updates to Yes. • On the server properties in Dnsmgmt, configure your previous DNS server as a forwarder.

18. Setting Up DNS on a Recovery Server (3) • Run IPCONFIG /ALL to be sure changes have taken effect. • Cycle the Netlogon service to speed up registry of the SRV records. • Inspect the forward lookup zone to be sure SRV records have actually been registered.

19. Changing the Administrative Group Name • Switch the recovery server to Native mode, on the properties of the organization object. • Right-click the Administrative Group object, and click Rename. • Remember—this doesn’t change the legacyExchangeDN!

20. The legacyExchangeDN • Maps Active Directory objects to corresponding Exchange 5.5 objects. • Looks like: /o=Organization/ou=Site/cn=Recipients… • Never changes after it is set, even if you change the Administrative Group or Organization names. • Databases cannot start unless legacyExchangeDN values are correct.

21. legacyExchangeDN Value Generation • Install new Exchange 2000 organization, legacyExchangeDN is: /o=Organization/ou=First Administrative Group • Upgrade Exchange 5.5 organization, legacyExchangeDN is: /o=Organization/ou=5.5 Site Name • Install recovery server, legacyExchangeDN is: /o=Organization/ou=First Administrative Group

22. legacyExchangeDN Mismatches • If restoring a database from an upgraded organization to a recovery server. • If restoring a database from a second Administrative Group in a “pure” Exchange 2000 organization. • Recovery server legacyExchangeDN value will always be /ou=First Administrative Group, no matter what the “real” legacyExchangeDN is. • If legacyExchangeDNs do not match, databases will not start.

23. Getting Around the legacyExchangeDN Problem • Install a second recovery server with the correct naming. • Install Exchange 5.5 on the recovery server with the correct naming, and then upgrade. • Change the legacyExchangeDN values to the correct naming.

24. What Is the legacyExchangeDN Stem in Your Organization? • In your production organization, run this command: LDIFDE –f CON –d "CN=Headquarters, CN=Administrative Groups,CN=Corp1, CN=Microsoft Exchange,CN=Services, CN=Configuration,DC=mycorp,DC=com" –l legacyExchangeDN –p Base

25. What Is the legacyExchangeDN Stem in your Organization? (2) • You will get output that looks like this: dn: CN=Headquarters,CN=Administrative Groups,CN=Corp1,CN=Microsoft Exchange, CN=Services,CN=Configuration,dc=mycorp,dc=com changetype: add legacyExchangeDN: /O=Microsoft/OU=Headquarters

26. Fixing the legacyExchangeDN • On the recovery server, run this command: ldifde -f e:\legacy.ldf -p subtree -l legacyexchangedn -d "CN=Microsoft Exchange, CN=Services,CN=Configuration,DC=mycorp,DC=com" -r "(legacyexchangedn=*First*)"

27. Fixing the legacyExchangeDN (2) Output from the previous command will be in the file Legacy.ldf, and each record will look like this: dn: distinguished name of the object changetype: add legacyExchangeDN: current value <blank line>

28. Fixing the legacyExchangeDN (3) • You must rework each record so that it can be imported. • Use Word or a plain text editor that supports across line break find and replace.

29. Fixing the legacyExchangeDN (4) • Find/ou=First Administrative Groupand replace with:/ou=right administrative group name

30. Fixing the legacyExchangeDN (5) • Find<line break><line break>and replace with:<line break><dash><line break><line break> • Hint: In Word, search for ^p^p and replace with ^p-^p^p

31. Fixing the legacyExchangeDN (6) • Find:Changetype: add<linebreak>and replace with:Changetype: modify<linebreak>replace: legacyExchangeDN<linebreak>

32. Fixing the legacyExchangeDN (7) • If editing the file in Microsoft Word, don’t forget to save it as plain text. • After editing, each record in the file should look like this: dn: distinguished name of the object to be modified changetype: modify replace: legacyExchangeDN legacyExchangeDN: new value - <blank line>

33. Fixing the legacyExchangeDN (8) • Import the modified Legacy.ldf file using this command: ldifde –i –f legacy.ldf • Investigate any import errors: all modifications must succeed!

34. Restoring Databases • Restart all Exchange services. Existing databases will fail to mount if the legacyExchangeDN has been changed. • Before restoring databases from your production system, you must select the check box for “This database can be overwritten by a restore” on each database’s properties.

35. Accessing Mailboxes • Create an Active Directory account for each mailbox you wish to open. • In Exchange System Manager (ESM) console, right-click the Mailboxes object and run the Cleanup Agent. • Right-click a mailbox with an X next to it, and click Reconnect. • Access the mailbox contents with a client application or save contents to a .pst file with Exmerge.

36. SRS and KMS Database Recovery • Semi-running mode. • Similar to Information Store recovery. • Must also select the “Last Backup Set” check box to run hard recovery.

37. SRS Recovery If the SRS Database Is Lost • Install another Exchange 2000 server in the site/administrative group or go to another Exchange 2000 server in the same admin group. • Run ESM from the console of the new server. • In Tools, right-click Site Replication Services, and install an SRS on the new server. • Delete the original SRS. • Re-create the original SRS (if needed). • Delete the other SRS, and then remove the other server (if needed).

38. IIS Metabase Recovery • Metabase contains virtual server and other Exchange protocol configuration information. • Most of the information in the metabase is duplicated in Active Directory, and is re-created automatically during /disasterrecovery setup. • Exception: NNTP information.

39. IIS Metabase Recovery (2) • The metabase can’t be transported to a different server and recovered. • If security/certificate information for the server installation is lost, the metabase can’t be restored. • Back up the metabase along with system state information on the server. • Additional backups of just the metabase file can be made in the IIS Administrator console.

40. Active Directory Recovery • Each domain controller in a given domain serves as a real-time backup of the others. • Have three domain controllers per domain for disaster recovery redundancy. • It may be easier to rebuild a single domain controller than to restore it. • Coordinate with Active Directory administrators on disaster recovery plans. • Make sure Exchange disaster recovery administrators have appropriate AD permissions.

41. KMS Recovery Requirements • Must have .P12 file backup of the root certificate for the Certification Authorities, and know the password to the file. • Must have KMS database backup. • Must know KMS database startup password. • Must know KMS administrator passwords. • Must have access to AD accounts for KMS administrators.

42. KMS Best Practices • Before deploying KMS, think very hard about your Public Key Infrastructure (PKI) requirements. Backing out and doing it over is very difficult. • Make sure that your administrative framework for PKI and KMS can survive changes in personnel, and that backups are very secure. • Have thorough and expert knowledge of PKI before deploying KMS. Never just wing it.

43. Questions?