Exchange 2000 Server Database Recovery
| Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
Updated : June 14, 2001
Microsoft Product Support Services White Paper
Written by Mike Lee
Additional contributions by Darin Roulston, Cliff Mattox, and Hugh Wilson
Published October 2000
On This Page
Abstract
Introduction
Overview
Where is Exchange 2000 Data Stored?
Disaster Recovery Strategy Fundamentals
Information Store Backup and Restoration Overview
Information Store Recovery Scenarios
Recovering the Site Replication Service Database
Internet Information Service Metabase Recovery
Active Directory Recovery
Key Management Service Database Recovery
Appendix A: Changing legacyExchangeDN Attribute Values
For More Information
Abstract
This white paper describes important differences between Microsoft® Exchange Server 5.5 and Microsoft Exchange 2000 Server with regard to database and server recovery. This white paper also describes several common recovery scenarios and provides step-by-step procedures for each scenario.
Introduction
Readers of this white paper should be thoroughly familiar with Exchange Server 5.5 backup and restoration procedures and should have a good conceptual understanding of how Exchange Server 5.5 databases work.
Overview
Database formats and functionality between Exchange Server 5.5 and Exchange 2000 have a great deal in common. The core knowledge that you have about Exchange Server 5.5 disaster recovery and data preservation is relevant to Exchange 2000. Transaction logging, setting checkpoints, and other fundamentals of the database remain basically the same. Exchange 2000 can support up to 20 databases on each server, which means that there is more information to keep track of. Also, some architectural changes were made to enable all these databases to coexist without interfering with each other. Database recovery troubleshooting principles and strategies remain very similar between the two products. This section provides an overview of important changes in Exchange 2000 that affect disaster recovery and planning.
A global directory (Microsoft Active DirectoryTM) replaces the server-centric Exchange Server directory.
In Exchange Server 5.5, each Exchange Server computer has its own directory database. This database is replicated automatically to other Exchange Server computers in the same Exchange Server site. In Exchange 2000, there is no Exchange Server directory. Instead, Exchange 2000 information is stored in Active Directory, and is replicated throughout an entire Active Directory forest.
In most cases, there is not even a copy of the Active Directory database on an Exchange 2000 computer. The server instead connects as a client to an Active Directory domain controller to read and write directory information.
This has the following important implications for disaster recovery:
The Exchange Server administrator no longer controls backup and restoration of the directory; the Microsoft Windows® 2000 Server administrator does.
Even if an Exchange Server computer is completely destroyed, in most cases all the configuration information is still stored safely elsewhere in Active Directory. A new Setup switch, /disasterrecovery, reinstalls an Exchange 2000 computer for which logical configuration information is still intact in Active Directory.
You can no longer join Exchange Server database recovery servers to production domains. To perform database recoveries, you must use a domain controller from a different Active Directory forest because the directory is now global, not server-based. However, the recovery server can be on the same network that the production forest is on.
This requirement is not as difficult as it may seem. Microsoft Windows NT® Server 4.0 requires complete reinstallation of the operating system to change a server to or from a domain controller. In Windows 2000 Server, the dcpromo command allows you to change the role of a server in minutes.
In most mailbox recovery scenarios in Exchange Server 5.5, you do not need to restore original directory information to recover database information, and this remains true in Exchange 2000. As in Exchange Server 5.5, in the rare cases in which you want to restore directory information, you must restore that directory information on a physically disconnected network.
A mailbox is an attribute of a user, not an Active Directory object in its own right.
In Exchange Server 5.5, an administrator creates a mailbox object in the Exchange Server directory database, and then links that object to a particular Windows NT account. In Exchange 2000, the administrator creates an Active Directory user object, and then mailbox-enables the user object, which makes the mailbox an attribute of another object, rather than an object in its own right. (To be more specific, an Exchange 2000 mailbox is represented in Active Directory as a set of attributes because more than one attribute is used to establish the link between a user account and the account's mailbox.)
There is a one-to-one relationship between each Active Directory user account and each Exchange 2000 Server mailbox, and a single user account cannot be the primary owner of more than one mailbox. Nevertheless, you can still assign multiple users access permissions to a mailbox, even though each user account is the primary owner of only one mailbox.
This change has important practical consequences. For example, groups can no longer be assigned primary ownership of mailboxes. For migration purposes, it is also important that a single Windows NT account not be assigned as the primary owner of multiple Exchange Server 5.5 mailboxes. There are various inspection and cleanup tools that are available to detect and rectify this condition. Strategies for using such tools and for migration planning are described in the documentation for the Active Directory Connector (ADC).
Mailboxes can be disconnected and reassigned to different users.
In Exchange Server 5.5, the distinguished name (DN) uniquely identifies every object in the Exchange Server directory. The distinguished name is analogous to the full pathname to a file. A typical distinguished name is in the following format:
/O=organization/OU=site/CN=container/CN=object
As an Exchange Server 5.5 mailbox is created, the distinguished name of the mailbox owner is stamped on the mailbox and can never be changed. In Exchange 2000, the value that identifies a mailbox is the mailbox globally unique identifier (GUID). A GUID is to a directory object what a hardware address is to a network interface card. All network card manufacturers assign each card a hardware media access control address, and the address on each card is different from every other card in the world.
Just as you can take a network card out of one computer and install that network card in another computer, you can disconnect a mailbox from one Active Directory user and assign that mailbox to a different user.
When you delete an Exchange 2000 mailbox, the mailbox contents are no longer immediately deleted from the information store database. By default, the physical mailbox is preserved for 30 days (an administrator can configure this interval). During the time that the deleted mailbox is on the disconnected list, you can connect that mailbox to another user:
Start Exchange System Manager.
Locate the database that contains the disconnected mailbox, and then click the Mailboxes object for the database.
If the mailbox is not already marked as disconnected, right-click the Mailboxes object, and then force the Mailbox Cleanup Agent to run.
Right-click the disconnected mailbox, and then click Reconnect. A dialog box is displayed in which you can choose the new mailbox owner.
All mailbox GUIDs must be unique in the Active Directory forest. This is why you must perform database recovery operations in a different forest.
Public folder and other permissions are granted by using access control lists (ACLs), not distinguished names.
In Exchange Server 5.5, Windows NT permissions are used to grant initial access to a mailbox or server. After that, permissions to gain access to public folders, distribution lists, and many other Exchange Server objects are granted on the basis of Exchange Server directory names, not Windows NT accounts. In Exchange 2000, all permissions are granted directly to Active Directory accounts. To maintain coexistence between Exchange Server 5.5 and Exchange 2000, permissions are mapped between the two permissions systems.
Administrative groups replace sites.
In Exchange Server 5.5, the unit of administration is the site. In a site, all servers share automatic directory replication and routing of messages between each other. To administer a multisite Exchange Server 5.5 organization, the administrator must connect in turn to a server in each individual site. Although you can configure sites to replicate each other's information, sites cannot alter objects that belong to one another.
In Exchange 2000, the administrative group has many of the same attributes as an Exchange Server 5.5 site, except that message routing is made substantially independent of administration, and is configured by routing groups.
You do not need to bind directly to servers in each administrative group to administer the entire Exchange 2000 organization. Instead, you just need appropriate Active Directory permissions for each administrative group. Logically separating Exchange 2000 into administrative groups makes it easy to separate and assign appropriate administrative permissions.
Each administrative group can contain multiple routing groups, and you can add and remove servers from routing groups at will. (After you switch your Exchange 2000 organization to native mode, routing groups can span administrative group boundaries. After you switch to native mode, Exchange 2000 can no longer coexist with Exchange Server 5.5 in the same organization.) Therefore, you can reconfigure your routing group architecture as your network topology changes without disturbing the logical administrative architecture.
The term site has been appropriated by Active Directory and no longer applies to Exchange 2000. In essence, a site is now a routing group for the purposes of Active Directory replication, and Active Directory sites can be as flexibly reconfigured as Exchange 2000 routing groups. The Active Directory site architecture has some impact on Exchange 2000 because Active Directory site architecture influences the choice of Active Directory global catalog servers and domain controllers that are used by Exchange 2000.
Storage groups are used.
Another important new term for Exchange 2000 is storage group. Storage groups exist in Exchange Server 5.5, but administrators did not have to understand or even know about storage groups because there is a maximum of one storage group for each Exchange Server 5.5 computer. A storage group is a set of Exchange Server databases that all share the same transaction log files. In Exchange Server 5.5, the single storage group on a server consists of up to two databases (the mailbox database and the public folder database). In Exchange 2000, you can configure up to four storage groups for each server, and each storage group can contain up to five databases.
If you want to, you can back up all databases individually, but usually it is most efficient to back up databases on a storage-group basis. You can back up multiple storage groups simultaneously to different tapes. You cannot back up individual databases in a storage group simultaneously to different tapes. All databases in a single storage group must be backed up in series, either in a single backup job, or in multiple jobs timed to run one after another.
Databases are mounted.
In Exchange Server 5.5, when you start the information store or other database services, the database is automatically mounted, which means that the database is started and made available to clients simply by starting the service.
In Exchange 2000, you can keep some databases running while other databases are stopped. Exchange System Manger (ESM) supports mounting and dismounting individual databases. All databases are set to mount on service startup by default, but you can change this behavior in the database properties.
Keep in mind that one result of this flexibility is that successful startup of a service does not necessarily mean that the database is running.
Services must be started to restore databases.
In Exchange Server 5.5, a database service must be stopped to restore a database. In Exchange 2000, the service must be running, but the particular databases that you want to restore must be dismounted.
This is also true for Exchange 2000 services other than the information store, such as the Site Replication Service (SRS) and Key Management Service (KMS). However, these other databases do not display a user interface to mount and dismount the databases and leave the service running.
Instead, these services start successfully, even when there is no database present, or the current database has been damaged and cannot be mounted. This semi-running state enables you to restore a replacement database and fulfills the requirement that the service be started but the database be stopped.
Be aware that because of this behavior, as with the information store, you cannot treat successful startup of the service as proof of successful startup of the database.
Streaming database files are used.
In Exchange Server 5.5, after a clean shutdown of the database service, the entire database is contained in a single file. Although the recommended method to back up an Exchange Server 5.5 database is to back up the database online, you can make an offline copy of the single database file (the Dir.edb, Priv.edb or Pub.edb file, depending on the database). If you only save the database files from a server, even if everything else is lost, you can restore all user information and most configuration information.
In Exchange 2000, there is no Dir.edb file because Active Directory replaces the Exchange Server directory. The Active Directory database is backed up online during a system state backup.
Instead of the Priv.edb and Pub.edb databases that you are familiar with in Exchange Server 5.5, you may have up to 20 Exchange 2000 information store databases, and the names of those databases are entirely up to you.
Each database file in Exchange 2000 has an accompanying streaming database file that usually shares the name of the .edb file, but with an .stm extension (for example, Priv1.edb and Priv1.stm). If you perform an offline backup, you must treat the .edb and .stm files as if they are a single file; you must copy and restore these files together.
The streaming file contains raw user data that comes into the information store by using protocols other than Messaging Application Programming Interface (MAPI). The .edb file contains "promoted" properties for such messages that include all of the identifying information that is necessary for clients to gain access to the messages. The relative sizes of the .edb and .stm files vary depending on the mix of client access protocols in use in your organization.
If a MAPI client alters a message that is stored in the streaming file in certain ways, the entire message may be promoted to the .edb file and removed from the .stm file. Exchange 2000 determines internally the most efficient time to perform this procedure. For example, messages that are replicated between public folders are promoted entirely to MAPI in the .edb file.
Where is Exchange 2000 Data Stored?
In Exchange Server 5.5, all the user and configuration data for a given server is stored on that server. In Exchange 2000, the majority of configuration data is probably stored on a different server: the Active Directory domain controller.
In Exchange Server 5.5, you can recover from almost any disaster to an Exchange Server computer if you have the following:
A backup of the databases on the server.
A backup of the registry settings for Exchange Server.
The contents of any queue folders for messages in transit.
In many cases, you can recover almost all data if you simply have backups of three files, the Dir.edb (directory database), Priv.edb (mailbox database), and Pub.edb (public folder database) files, because often registry settings for Exchange Server 5.5 are generic and queues are empty. It is often a simple task to re-create additional configuration information that is not captured in the Dir.edb file.
In Exchange 2000, the process to recover user information is similar in principle to the process to recover user information in Exchange Server 5.5, but configuration information is stored much differently. The primary difference is that most configuration information may not even be stored on the same server, but on Active Directory domain controllers. This change can potentially simplify or complicate recovery, depending on how you manage Active Directory.
Because most configuration information is generally safe on a different server, you can restore an Exchange 2000 installation with all or most of the configuration settings intact simply by reinstalling Exchange 2000 and using the /disasterrecovery switch with Setup.
However, an Exchange 2000 computer can be made non-functional if Active Directory is destroyed on a remote server. As an Exchange 2000 administrator, you must ensure that Active Directory is backed up and managed well.
If you use KMS, you also need to be sure that remote certification authority (CA) computers are backed up and well managed. Loss of the certification authority renders your KMS database unusable, and may result in the loss of all existing encrypted data.
Exchange 2000 stores less of the configuration information in the local system registry compared to Exchange Server 5.5. Even database file paths for the information store are in Active Directory instead of the registry. But some connectors still store critical configuration information in the local system registry for backward compatibility.
Because Exchange 2000 uses Simple Mail Transfer Protocol (SMTP) as the default message transport, every Exchange 2000 computer relies on the Microsoft Internet Information Service (IIS) metabase. Most of the Exchange 2000 information in the metabase is duplicated in Active Directory and is automatically re-created if you run Setup with the /disasterrecovery switch. Nevertheless, loss of the metabase prevents your Exchange 2000 computer from sending or receiving e-mail. As an Exchange 2000 administrator, you are also a local IIS administrator, and you are responsible for backing up and preserving your IIS configuration and information.
The information that you must take into account to preserve your entire Exchange 2000 system has increased in complexity over the information that you need for Exchange Server 5.5. However, you can still capture all the data that you need by using a relatively simple basic strategy, as described in the following "Disaster Recovery Strategy Fundamentals" section of this white paper.
Disaster Recovery Strategy Fundamentals
This section describes a worst-case scenario, in which the Exchange 2000 computer and Active Directory server have been completely destroyed by a catastrophic event. The only information that you have left is the backup tapes. Although such catastrophes are rare, if you consider such scenarios, it may help you design your backup and recovery strategies.
To fully recover from a total disaster, you need the following:
Replacement hardware.
Windows 2000 Server and Exchange 2000 Server installation disks, including any applicable service packs or fixes.
Full drive backups of the system drives and other logical drives where critical applications or data were installed.
System state backups. System state backup is a new type of backup that is available in Windows NT Backup for Windows 2000 Server. This backup captures Active Directory, registry, IIS metabase, and other types of data that are not usually backed up by ordinary file and drive backups. Full drive backups may or may not capture all system state information, depending on whether the backup method is able to capture files that are in use.
Exchange database backups. Along with backups of the information store database, you may also need backups of ancillary databases such as the SRS databases and KMS databases.
To summarize the recovery process, if you have all the preceding components, to recover from a worst-case disaster:
Reconfigure hardware that is similar to the original hardware.
Create logical drives that closely match the original configuration.
Although hardware does not always need to be identical, be aware that some drivers that are listed in the backup set may be incompatible with hardware on the new systems, and may require you to manually remove or install drivers in Safe mode. Test the system state restoration on replacement hardware before you actually need to perform a system state restoration.
Reinstall the operating system.
Install the same version of Windows 2000 Server (Windows 2000 Server, Microsoft Windows 2000 Advanced Server, or Microsoft Windows 2000 Datacenter Server) as a stand-alone server to the same drives and paths to which Windows 2000 Server was previously installed, and use the same server names that were used before.
Restore full drive backups.
In rare cases, you may need to restore a system state backup before you restore full drive backups. Perform a "drill" before an actual emergency occurs to determine if you have any applications with this requirement. If you have made disk image backups, if you restore those disk image backups, you may be able to skip reinstallation of the operating system and restoration of other backups.
Restore system state backups.
Restore and restart domain controllers first so that member servers have a logon server and access to Active Directory. By restoring the system state, you have restored Active Directory and the IIS metabase.
Reinstall Exchange 2000 by using the /disasterrecovery switch.
The disaster recovery mode in Setup reads Active Directory and restores as many previous settings as possible. For example, database paths are stored in Active Directory, and are set correctly, regardless of whether you install Exchange 2000 program files to the previous locations.
If you restore full drive backups and system state information, you may not need to run Setup with the /disasterrecovery switch. The local Exchange 2000 installation may be completely functional already.
When you use the /disasterrecovery switch, you must manually select all the components that were previously installed on the server.
Restore Exchange 2000 databases, including information store and ancillary databases, such as the SRS and KMS databases.
Follow these best practices as part of your disaster recovery strategy:
Make full drive backups whenever you install new software, including fixes or service packs.
Perform system state backups whenever you make configuration changes to existing applications or system settings. Back up Active Directory domain controllers on a regular basis because system state changes occur continually on Active Directory domain controllers.
Make backup requirements part of your change control procedures. Never install new software, fixes, or applications on a server unless you are certain that you can "roll back" the changes by restoring your backup sets if necessary. Perform Exchange 2000 database backups frequently, usually on a daily basis.
The following sections of this white paper focus primarily on strategies to restore user information from the information store, rather than on configuration information. If you use the information in the preceding sections of this white paper, you should be able to preserve configuration information successfully.
To reiterate: configuration information for Exchange 2000 is distributed in more locations and is more complicated than configuration information in Exchange Server 5.5. You are likely to find the process of re-creating configuration information in Exchange 2000 more difficult and time-consuming than the process of re-creating configuration information in Exchange Server 5.5. Therefore, include increased emphasis on preserving configuration information along with user data in your backup strategy. This applies not only to the Exchange 2000 computer, but also to other servers, such as Active Directory domain controllers and CA servers.
Information Store Backup and Restoration Overview
If you are experienced with information store recovery in Exchange Server 5.5, you are well on your way to being expert in restoration of the Exchange 2000 information store. The procedures in this section assume that you have practical expertise in Exchange Server 5.5 database recovery, and that you need to learn how to apply that expertise to Exchange 2000.
Backup Differences
The procedure to back up Exchange 2000 information store databases is very similar to the procedure to back up Exchange Server 5.5 databases. The primary difference is that you can have multiple databases and storage groups, which you can back up together or separately.
You can run separate backup jobs simultaneously against different storage groups, but you can run only one backup job at a time against the databases in a single storage group. You can select all databases in a storage group to back up those databases in a single job, but if you do, those databases are backed up in series to the same tape.
Therefore, size each storage group so that you can back up all of the databases in that storage group in series in the window of time in which your overnight backup occurs.
Restoration Differences
The following are several important differences between Exchange 2000 and Exchange Server 5.5 to keep in mind when you restore Exchange 2000 information store databases.
Before you begin restoration, the information store service must be started, but the databases that you want to restore must be dismounted. In Exchange Server 5.5, the restoration process for online backups communicates with the system attendant; in Exchange 2000, the restoration process communicates directly with the information store service.
There is no Restore in Progress registry key. In Exchange Server 5.5, this registry key is created at the end of a restoration. This key controls the hard recovery process, which ensures that the correct log files are replayed and that information from the patch (.pat) files is correctly applied to the restored database. In Exchange 2000, the functionality of the Restore in Progress key is implemented in the Restore.env file.
The Restore.env file is a binary file, but you can still view the file contents when necessary. To do so, open a command prompt in the folder that contains Restore.env, and then run the following command:
eseutil /cm
If you restore databases from the same storage group to the same temporary folder in series, the Restore.env file from the second restoration may overwrite the Restore.env file from the previous restoration and prevent hard recovery from running successfully against the first database.
Restored log and patch files are no longer mixed with logs in the running directory in Exchange 2000, as they are in Exchange Server 5.5. Instead, restored log and patch files are placed in a temporary folder that you define in Windows NT Backup just before restoration starts. The Restore.env file is placed in this folder as well.
In Exchange Server 5.5, restoration requires you to stop all the information store databases. In Exchange 2000, other databases, even in the same storage group, can be left running during restoration. Exchange 2000 uses the temporary folder to avoid possible conflicts between the restoration process and other operations, which include backups that may be running on one database while another backup is being restored.
Subfolders for each storage group that is being restored are automatically created under the temporary folder that you define; therefore, you can restore multiple storage groups simultaneously in the same temporary folder. As in Exchange Server 5.5, database files (.edb and .stm files) are still restored to the files' running locations, and restored copies of the database files overwrite any currently existing versions of those files.
In Exchange 2000, hard recovery starts when you select the Last Restore Set check box in Windows NT Backup, not when the presence of the Restore in Progress key is detected.
Hard recovery, as contrasted with soft recovery, applies information from database patch files to the database during log file replay. If you run soft recovery when hard recovery is necessary, you will likely damage the database, and you will need to restore the database again. In Exchange Server 5.5, administrators sometimes delete the Restore in Progress key before hard recovery finishes, and without the presence of that key, the database service runs normal soft recovery.
In Exchange 2000, additional safeguards prevent a database from running soft recovery when hard recovery is necessary. If you forget to select the Last Restore Set check box, you cannot mount a restored database until a hard recovery has been performed. In such a case, you can restore the database again, and take care to select the Last Restore Set check box, or you can use the Eseutil utility hard recovery option.
To use the Eseutil utility hard recovery option, open a command prompt in the temporary folder that contains the Restore.env file, and then run the following command:
eseutil /cc
To force hard recovery to replay only the logs in the temporary folder, add the /t switch to the eseutil /cc command as follows:
eseutil /cc /t
The /t switch defines the storage group in which log file replay continues after logs in the temporary folder have been replayed. The eseutil /cc command includes an implied
/t" storage_group_name_defined_in_Restore.env "
if you do not explicitly specify the /t switch. The /t switch alone (followed by nothing) signifies /t nothing .
You can simultaneously restore multiple backups of different storage groups, even to the same temporary folder, but if you simultaneously restore multiple full backups from the same storage group, you must restore each backup to a different temporary folder. If you do not, the Restore.env file for one restoration overwrites the Restore.env file for others and prevents hard recovery from succeeding, except for the last backup that you restore. Note that this principle applies to full backups, not incremental or differential backups. Restore incremental backups in series to the same temporary folder as the full backup to which the incremental backups belong.
It is recommended that you avoid performing parallel restorations of databases from the same storage group. As with backup, restoration is intended to work at the level of the storage group, not the single database. But if you do perform parallel restorations in a single storage group, do not select the Last Restore Set check box for any of the restorations. Instead, use the eseutil /cc command to perform hard recovery so that you do not run hard recovery at the same time on two different databases in the same storage group.
In Exchange 2000, every restoration from an online backup restores exactly one full backup and zero or more incremental backups. This is also true in Exchange Server 5.5. In Exchange Server 5.5, you can restore your backup sets in any order. In Exchange 2000, you must restore the full backup first so that the full backup can create the Restore.env file, and then you can restore incremental backups.
Information Store Recovery Scenarios
This section describes the following four information store restoration scenarios:
Basic information store recovery. An information store database must be restored, but all other configuration and files are intact.
Full server recovery. An entire Exchange 2000 computer has been lost, and must be rebuilt.
Active Directory recovery. Active Directory configuration for the Exchange 2000 computer has been lost, but the Exchange 2000 computer is intact.
Alternative server (single mailbox) recovery. Single mailbox or offline recovery of a database for salvage purposes.
Basic Information Store Recovery
Before you restore a backup from tape, it is recommended that you make copies of existing database files, even if you cannot start these files. Until tape restoration is finished, you cannot be completely sure that your tape is good, and that the existing database may be repairable, even though the database may be damaged.
Note: Always make sure that you never let your database drive become more than half full. This ensures that you can quickly save a copy of a database that "crashes." If you do let your database drive become more than half full, and you do not have sufficient space to move the database to another folder on the same logical drive, your recovery time is extended by the time that it takes to back up the existing files. Usually, recovery time is doubled.
If you keep at least half of your database drive free, you also have room for routine maintenance, such as offline defragmentation.
Before you restore the databases, you must start the information store service, but you need to dismount the databases that you want to restore. If you are restoring only a single backup set, do not forget to select the Last Restore Set check box in Windows NT Backup to trigger hard recovery after restoration. If you leave the Mount database after restore check box clear, you can examine Event Viewer to be sure that hard recovery finishes as expected before you mount the database in Exchange System Manager.
Full Server Recovery
Even if an Exchange 2000 computer is completely destroyed, you still have not lost the majority of your configuration information if an Active Directory replica is still available on another server. In all but the smallest organizations, Active Directory is always safe on a separate server.
Recovery works differently in Exchange 2000 than in Exchange Server 5.5. In Exchange Server 5.5, most configuration information is stored in the Dir.edb file on each server. As long as you preserve that file, you can reinstall Exchange Server with the same logical naming without joining the existing site, and then add the old Dir.edb file in the new installation to restore the server's place in the existing site.
In Exchange 2000, Active Directory almost always survives a disaster that occurs to an Exchange 2000 computer, and you cannot install an Exchange 2000 Server recovery computer in the Active Directory forest while also installing the recovery server outside the existing Exchange organization because there can be only one Exchange 2000 organization for each forest. Therefore, you cannot reinstall Exchange 2000 on a server without first removing that server from Active Directory. However, you do not want to remove the server from Active Directory because all of the configuration information will then be lost.
In Exchange 2000, the Setup utility /disasterrecovery switch solves this problem. In disaster recovery mode, Setup installs Exchange 2000 program files and local registry settings, but assumes that Active Directory information remains intact. Setup searches for the server in Active Directory, and reconfigures the local setup based on what Setup finds in Active Directory.
In disaster recovery mode, Setup only restores the components that you choose to restore. If you do not choose a component that was previously installed, that component is not restored. For example, if a particular connector was installed on the server, you need to manually select that connector in Setup before you begin restoration.
After Setup finishes, you can restore information store databases, and those information store databases are restored to the correct previous locations because information store database paths are stored in Active Directory.
Active Directory Recovery
The loss of all copies of Active Directory is a problem with consequences that reach beyond Exchange 2000. If you lose Active Directory, it is roughly as catastrophic as losing all of the copies of the Dir.edb file for a site. You need to rebuild all of the configuration information for your system, but if your information store databases are intact, you can recover all of the user data, although the recovery is a very labor-intensive project.
It is difficult to offer general advice about how to recover from an Active Directory disaster. However, the following "Alternative Server (Single Mailbox) Recovery" section of this white paper can help you recover from an Active Directory disaster because a single mailbox recovery is, in essence, a recovery without access to any previous Active Directory information.
Alternate Server (Single Mailbox) Recovery
Exchange2000 consolidates the contents of mailboxes into a small number of database files. This design provides excellent performance and operating efficiency, but to recover data from a single mailbox, you must restore an entire database.
Note: Several third-party backup utilities provide "brick" backup capabilities that extract the data from a single mailbox to a separate backup. The Exmerge utility can also run in a scheduled batch mode and copy single mailbox data to .pst file format.
In all versions of Exchange Server, you can restore an information store database that was created on one server to another server. You just need to make sure that you install Exchange Server on the recovery server with the correct logical naming. Because you have this capability, you do not need to shut down your live Exchange Server system to recover mailbox data; you can run two copies of a database at the same time.
This capability exists in all versions of Exchange Server. But in Exchange 2000, the requirements for configuring the recovery server are different than the requirements for earlier versions.
The following sections provide a conceptual overview of the recovery process for all versions of Exchange Server, and then the "Exchange 2000 Alternate Server Recovery" section provides the procedure to perform an Exchange 2000 offline recovery.
Exchange Server 4.0, 5.0, and 5.5 Alternate Server Recovery Overview
To start an Exchange Server 4.0, 5.0, or 5.5 database on a recovery server, the following conditions must exist:
The recovery server can be a member server or domain controller in any domain, including the domain in which the original Exchange Server computer is running.
The recovery server must have a different name than any server that exists or has existed in the original site. If you do not fulfill this requirement, the recovery server may begin to participate in directory replication with the existing site.
When you install Exchange Server, do not join the original organization or site. Therefore, the recovery server becomes the only server in its Exchange Server organization, although the recovery server will have the same logical naming as the original organization and site. To the existing Exchange Server organization, the recovery server does not exist (unless you have given the recovery server the same name as a server that was in the original site) because the organizations only replicate with each other if you configure them to do so during installation by joining the original organization. Install Exchange Server by using the same organization and site names that were used on the original server. The service account that you choose can be, but does not have to be, the same as the original service account.
After you restore the information store database and start the information store database on the recovery server, there are no recipients listed in the directory database. The directory on the recovery server has no information about anything from the original site, including the mailboxes that the information store database contains.
Before you can gain access to the mailboxes, you must create corresponding directory entries:
If you are recovering only a single mailbox, or a few mailboxes, you can simply create mailboxes in the directory that have the same distinguished name that the mailboxes in the original site had. The distinguished name is the only attribute that you must match to gain access to the mailbox. All other mailbox attributes can be different or unspecified.
An object's distinguished name uniquely identifies that object in the Exchange Server directory, and the distinguished name also contains the path to the object in the directory. For example
/o=organization/ou=site/cn=Recipients/cn=12345
can be the distinguished name of a mailbox that resides in the default Recipients container that has a directory name of 12345.
Note: The directory name does not necessarily need to match the mailbox alias. Check the advanced properties of the mailbox in the original system to verify the directory name. If two mailboxes are displayed for a single user after you create a mailbox in the Mailboxes table in the Exchange Server Administrator program, you probably used the wrong directory name.
If you are recovering many mailboxes, you can use the DS/IS Consistency Adjustor tool in the Administrator program to automatically create directory entries for all of the mailboxes that are found in the database. If the database contains hundreds or thousands of mailboxes, this tool may take at least several minutes to complete this procedure.
After you link mailboxes appropriately to directory entries, you can use ordinary client applications, such as Microsoft Outlook®, to gain access to mailbox data, or you can use mass recovery utilities, such as Exmerge, to extract data from all of the mailboxes.
Exchange 2000 Alternate Server Recovery Overview
The following Exchange 2000 requirements to build a recovery server are similar in principle to the requirements for earlier versions of Exchange Server, but you need to implement these requirements somewhat differently:
You must install the recovery server in a different Active Directory forest than the original server. The Exchange 2000 directory is Active Directory, and only one Exchange 2000 organization is allowed for each Active Directory forest. When you install a new Exchange 2000 computer, you have no choice but to join that Exchange 2000 computer to the current Exchange 2000 organization.
There are no special requirements to match the naming of the recovery forest to the live forest. Exchange 2000 recovery servers can exist in the same physical network that the original organization existed in, without interfering with either Active Directory or the Exchange 2000 organization.
You must install Exchange 2000 on the recovery server by using the same organization name that was used in the original system.
You must recover the database to an administrative group in which the legacyExchangeDN stem values match the legacyExchangeDN stem values for the administrative group that the database was originally taken from.
The storage group and logical database names to which you restore the database must match the original storage group and logical database names.
Just as in earlier versions of Exchange Server, you must populate the directory before you can gain access to mailboxes. But in Exchange 2000, you are working with Active Directory, and you must create user objects, not mailbox objects.
In earlier versions of Exchange Server, when you create a mailbox object with a matching distinguished name, the object is automatically linked to the mailbox in the database. In Exchange 2000, mailboxes are not so inextricably tied to distinguished names. In fact, you can disconnect and reconnect mailboxes to entirely different user objects, with entirely different distinguished names.
If you are recovering a small number of mailboxes, link the mailboxes to Active Directory accounts as follows:
Create an Active Directory user account, but do not mailbox-enable the user account. None of the naming for the account needs to match the account that was previously linked to the mailbox.
In Exchange System Manager, locate the Mailboxes object under the database object, and then right-click the Mailboxes object to run the Mailbox Cleanup Agent. In the Mailboxes list, make sure that a red X is displayed next to the mailbox that you want to recover. This indicates the mailbox is not connected to an Active Directory user.
Right-click the mailbox that you want to recover, and then click Reconnect. A list of Active Directory accounts is displayed, and you can connect the mailbox to the account that you just created for the mailbox.
If you are recovering a large number of mailboxes, the Mailbox Reconnect tool (Mbconn) on the Exchange 2000 Setup CD provides the mass reconnection capability that is provided by DS/IS Consistency Adjustor in Exchange Server 5.5:
Start the Mbconn tool, and view the list of disconnected mailboxes.
On the Actions menu, click Export Users to generate an LDIF import file. Each mailbox in the database is scanned to generate an Active Directory user import record that matches the mailbox. You can import this file to Active Directory to create user objects that you can link to each mailbox in the database.
Use the Mbconn tool's Preview and Save features to match and connect mailboxes to user objects.
As with earlier versions of Exchange Server, you can use various client applications, such as Outlook and Exmerge, to recover mailbox data after the mailboxes are accessible through the directory.
All About the legacyExchangeDN Attribute
In Exchange Server 5.5, the distinguished name of every object uniquely identifies that object and its place in the directory. The distinguished name indicates not just what the object is called, but where that object is located in the directory, for example:
/o=Microsoft/ou=Site1/cn=Recipients/cn=12345
Although this naming convention provides a lot of information to administrators and is very useful, it is also rigid. You cannot move an object in an Exchange Server 5.5 system to a different container without destroying the object because the path to the object is part of the object's fundamental name. This is why you cannot move mailboxes between sites in Exchange Server 5.5; the distinguished name for every mailbox contains the site name.
Active Directory also uses a hierarchical namespace, which makes it easy for administrators to organize and manage the directory, but does not use hierarchical naming on unchangeable object attributes. Instead, the fundamental name of an object exists in a flat namespace.
In Active Directory, the object globally unique identifier (GUID) performs the function that the distinguished name performs in Exchange Server 5.5. Specifically, the GUID uniquely identifies the object as itself, no matter what other attributes of the object are changed. The object GUID must be unique for every object in the Active Directory forest (the algorithm by which object GUIDs are generated makes it very likely the object GUID is unique in the world, much like a network card's media access control address).
Because the object GUID is not hierarchy-dependent, Active Directory provides great flexibility to move objects and reorganize your directory tree to meet changing needs.
Every object in Active Directory that has something to do with Exchange Server 5.5 has a legacyExchangeDN attribute. This attribute is, in essence, the "Exchange Server 5.5 name" of the object. The legacyExchangeDN attribute is critical to the coexistence of Exchange Server 5.5 with Exchange 2000 because the attribute maps Active Directory–style naming to Exchange Server 5.5–style naming. Even in a pure Exchange 2000 organization, all the Exchange 2000 objects and users still have legacyExchangeDN values. All Exchange 2000 system objects (such as the organization object or server objects) have legacyExchangeDN attributes, not just mailbox-enabled users and public folders.
What legacyExchangeDN Attributes Look Like
An Exchange Server 5.5 distinguished name begins with the organization and site to which the object belongs (/o=organization/ou=site). An Exchange 2000 legacyExchangeDN attribute is similar, except that the administrative group to which an object belongs is used instead of the site. An Exchange 2000 administrative group is similar in most respects to an Exchange Server 5.5 site.
The legacyExchangeDN attributes look just like Exchange Server 5.5 distinguished names, and Exchange Server 5.5 is therefore able to use and represent the Active Directory hierarchy when information is replicated between the two systems.
When an Exchange Server 5.5 database is first created, the names of the organization and site to which the database belongs are stamped on the database. From then on, this database can only be started on an Exchange Server installation that matches this naming. Similarly, when an Exchange 2000 database is first created, the organization and administrative group names are stamped on the database, and the database can only run on an installation that matches these names. The values that are stamped on the database are taken from the legacyExchangeDN attribute for the administrative group object.
You cannot change an Exchange Server 5.5 site's directory name after the installation of the first server in the site (although you can change the display name). You can change an Exchange 2000 administrative group directory name after you switch to native mode (in which there is no more coexistence with Exchange Server 5.5). If you change the name of an administrative group, the legacyExchangeDN attribute does not change. If the legacyExchangeDN attribute were to change, you would not be able to start existing databases in the administrative group. This situation has important implications for creating a recovery server. To understand these implications, you must understand how legacyExchangeDN values are assigned when Exchange 2000 is first installed.
How legacyExchangeDN Attributes Are Constructed
In Exchange 2000 Setup, you cannot create a new administrative group during installation. Instead, you must pick from a list of existing administrative groups. If no administrative groups exist at the time that you first install Exchange 2000, an administrative group with the name "First Administrative Group" is created. You cannot change this name during setup.
When you install the first Exchange 2000 computer without upgrading from Exchange Server 5.5, the legacyExchangeDN attribute for the first administrative group is set to the following:
o=organization/ou=First Administrative Group
Even if you change the name of the administrative group later, the legacyExchangeDN attribute name does not change.
If you upgrade an Exchange Server 5.5 site, rather than install a brand new Exchange 2000 computer, the legacyExchangeDN attribute stem is the following:
/o=organization/ou=Exchange_Server_5.5_site_name
The administrative group name is the same as the Exchange Server 5.5 site name.
If you generate a second administrative group in Exchange System Manager, the second administrative group's legacyExchangeDN attribute matches the name that you give the administrative group.
When you create an Exchange 2000 recovery server, that server is the first server in a new forest, and not an upgrade. Therefore, the legacyExchangeDN attribute stem is /o=organization/ou=First Administrative Group. This can be a problem because any database that was created with a different legacyExchangeDN attribute, such as an upgraded Exchange Server 5.5 database or a database from a second administrative group, does not start in this system, even if you change the name of the first administrative group to match the administrative group from which the database was originally taken. During database startup, the real name of the administrative group is whatever the legacyExchangeDN attribute contains.
Fortunately, there are several methods that you can use to get the correct legacyExchangeDN attributes into your recovery system. The following are two basic approaches you can take:
Get the correct naming in place before you install Exchange 2000.
Change the legacyExchangeDN values after you install Exchange 2000.
The advantage of the first method is simplicity. If the naming is correct from the beginning, all necessary system objects automatically get the correct legacyExchangeDN values. To change the values after installation, you have to find all the objects that you need to change in the directory, and then modify those objects.
However, one advantage of the second method is that you can recover databases from multiple administrative groups, and even from different organizations, without reinstalling Exchange 2000. Appendix A "Changing legacyExchangeDN Attribute Values" of this white paper describes this procedure. It takes a little practice to become proficient in this technique, but after you use this technique a few times, you can change your recovery server in just a minute or two, instead of reinstalling, which takes half an hour or more. For large organizations that configure dedicated Exchange 2000 recovery servers, it is worthwhile for administrators to learn this technique.
The recovery procedure in the following section describes how to ascertain the legacyExchangeDN attribute stem that you need, and how to determine the correct naming before you install Exchange 2000 on your recovery server.
Exchange 2000 Alternate Server Recovery
Get names.
Before you begin to set up your recovery server, you need to create a list of all the following essential naming scheme elements in your original organization:
The Exchange 2000 organization name.
The name of the administrative group to which the database belongs.
The name of the storage group to which the database belongs.
The logical database name itself.
The legacyExchangeDN value for the administrative group object that the database currently belongs to.
Except for the last item, you can easily obtain all of these names by using Exchange System Manager. You can view the legacyExchangeDN value by using various Lightweight Directory Access Protocol (LDAP) tools, such as the ADSI Edit, Ldp, or Ldifde tools. These tools enable you to view the raw attributes of Active Directory objects. ADSI Edit and Ldp are installed with the support tools on the Windows 2000 Setup CD. Ldifde is installed by default with Windows 2000 Server.
Ldifde is a bulk import and export utility for Active Directory. Ldifde uses the industry standard LDIF file format for import and export. For an Exchange 2000 administrator, Ldifde can be a very powerful tool for querying and managing the directory. The following procedure describes how to use Ldifde to obtain the legacyExchangeDN value:
To use Ldifde effectively, the first thing you need to determine is the LDAP path to the objects of interest in the directory. It is very important that you become comfortable with constructing LDAP paths to objects in Active Directory.
Exchange Server 5.5 administrators are used to directory paths that look like the following:
/o=organization/ou=site/cn=container/cn=container/cn=object
The following is the preceding directory path reworked as an LDAP path:
CN=object,CN=container,CN=container,OU=site,O=organization
An Exchange Server 5.5 directory path starts at the top of the tree, and works its way down, using slashes to delimit each component of the path. LDAP syntax starts at the bottom of the tree and works its way back up, using commas as delimiters.
In every Exchange 2000 organization, Exchange 2000 system objects are found in the same place, in the Configuration container in Active Directory. The Configuration container is always in the root domain for the forest. Child domains in a forest contain copies of the Configuration container, but child domains do not have a Configuration container of their own. The path to the Configuration container in every Active Directory forest is the following:
CN=Configuration, path_to_the_root_DNS_domain
If the Domain Name System (DNS) domain name for your root Windows 2000 Server domain is the following
corp.microsoft.com
you can translate this name into LDAP syntax as the following
DC=corp,DC=microsoft,DC=com
and the path to the Configuration container is therefore the following:
CN=Configuration,DC=corp,DC=microsoft,DC=com
In the Configuration container, Exchange 2000 administrative groups are located under the following:
CN=Administrative Groups,CN=organization_name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=corp,DC=microsoft,DC=com
After you determine the LDAP path, you are ready to construct an Ldifde command line that is similar to the following to display the legacyExchangeDN attribute for your administrative group:
ldifde -f con -d "CN= administrative_group_name ,CN=Administrative Groups,CN= organization_name ,CN=Corp1,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=corp,DC=microsoft,DC=com" –l legacyexchangedn –p base
In the preceding example:
The –f filename parameter specifies the file name to which output is written. If you enter con, results are output to the screen.
The –d baseDN parameter defines the object and the LDAP path to the object.
The –l LDAP_attribute_list parameter restricts the attribute output to the legacyExchangeDN value only and omits all other values. You can specify multiple attributes, separated by commas.
The –p scope parameter defines the scope of the search. By default, all objects in the subtree under the specified path are returned. If you specify base, only the exact object that you specify is returned.
The following is the output from the preceding Ldif command:
dn: CN=administrative_group_name,CN=Administrative Groups,CN=organization_name,CN=Microsoft Exchange,CN=Services,CN=Configuration,dc=corp,dc=microsoft,dc=com
changetype: add
legacyExchangeDN:
/O=organization_name/OU=original_administrative_group_nameThe last line displays the legacyExchangeDN attribute stem for the administrative group.
If you do not know and cannot find all of the names that you need, you can still restore the database successfully, but with some inconvenience. As you try to perform various steps of the recovery, you will receive various error messages. At each step, the error message indicates what is wrong with the current naming.
If you are restoring an online backup, the backup set itself contains the storage group and logical database names. Even if the other names are wrong, if you create a storage group and database on the recovery server with these names, you can restore, but not start, the database.
When you try to start a database that does not match the current legacyExchangeDN attribute naming, you receive an error message that is similar to the following:
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 1088
Date: 8/25/2000
Time: 12:00:55 PM
User: N/A
Computer: RECOVERY1
Description:
The information store could not be loaded because the distinguished name (DN) /O=MICROSOFT/OU=55SITE1/CN=RECIPIENTS/CN= of message database "First Storage Group\Public Folder Store (SERVER1)" does not match the DN of directory /O=MICROSOFT/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=.
The database may have been restored to a computer that is in an organization or site different than the original database.In the preceding error message, the legacyExchangeDN stem values are in bold type, and are red. The first path that is listed is the path that is actually inside the database. The second path is the path that is currently listed in Active Directory. To correct this problem, you must change the Active Directory path to match the path that is inside the database.
If the naming is wrong, you have the two following choices:
Start over again.
Use the methods that are described in Appendix A "Changing legacyExchangeDN Attribute Values" to change the names in the current installation to the correct names.
Create a new forest.
In Microsoft Windows NT Server 4.0, you need to completely reinstall a server to turn the server into a domain controller. In Windows 2000, you simply run the Dcpromo utility to either promote or demote a server as a domain controller. Therefore, you can use a member server from your production forest temporarily as a recovery server. After you are done with the recovery, demote the server, and then rejoin the server to the previous domain.
The process to start a public information store database is the same as the process to start a mailbox database. Public information store data recovery in Exchange 2000 is very similar to the process that is used in Exchange Server 5.5.
The naming of the recovery forest is entirely at your discretion. This naming does not affect your ability to restore Exchange 2000 databases.
When you create the new forest, you may be prompted to install DNS. If you install DNS at this time, you can ignore the prompts that warn you to establish a static Internet Protocol (IP) address for the server. A Dynamic Host Configuration Protocol (DHCP) assigned IP address is sufficient for a recovery server that will not be left intact permanently.
Install and configure DNS.
This step is necessary if your current DNS server does not allow you to dynamically register service location (SRV) records for your recovery server. In most cases, the DNS server that you use normally only allows secure updates, which means that you must be logged on with a trusted network account. The "rogue" domain that you just created probably does not have the permissions that are necessary to register records. Exchange 2000 cannot be installed in a forest unless SRV records for a domain controller in the forest can be found in DNS. Setup does not work, and error messages such as "Setup is unable to access the Windows 2000 Active Directory" or "Failed to look up the Windows 2000 Site to which this computer belongs" are displayed.
In Windows 2000 Server, installing DNS is a very simple process:
If DNS has not already been installed on the recovery server, install DNS from the Windows 2000 Server installation CD.
Use the Windows Components Wizard in the Add/Remove Programs tool in Control Panel to install DNS. The DNS service is located in the Details folder under Networking Services.
Important: Do not install DHCP. Although an extra DNS server on your network does no harm (because only clients who deliberately point to the service's IP address use this service), DHCP advertises itself on the network, and clients are redirected from the normal DHCP system to your server. In most cases, this causes widespread logon problems on your network for many computers.
At a command prompt, run the following command:
ipconfig /all
Write down your own primary IP address and the DNS servers' IP addresses.
Open the Network and Dial-up Connections folder for your computer, and then open the properties for your primary network connection (usually listed as Local Area Connection).
Open the properties for Transmission Control Protocol/Internet Protocol (TCP/IP). If your computer has been configured by DHCP, the properties usually have automatic settings. Change the DNS setting to Use the following DNS server addresses, and then type your own IP address as the preferred DNS server.
Run the ipconfig /all command again to make sure that the setting is applied.
Start the DNS Microsoft Management Console (MMC) snap-in (Dnsmgmt.msc). Right-click the server object, and then open the server properties. Click the Forwarders tab, and then add the IP address of your previous DNS server. When the local DNS database cannot resolve a name, your server queries your previous DNS server.
Note that if you configure your corporate DNS server as a secondary DNS server in the Internet Protocol properties, it does not have the same effect that configuring a forwarder does. The secondary DNS server is used only when the preferred one is unreachable, not when the preferred server is reachable but cannot resolve a name.
If Windows Internet Naming Service (WINS) name resolution is available on your network, you may not need to configure a forwarder to keep access to network resources. You may also need to specify the full DNS name of network resources (for example, server1.corp.microsoft.com, instead of server1) to resolve network names. Alternately, you can specify commonly used domain names as DNS suffixes in the advanced settings for TCP/IP in your network connection properties.
Create a forward lookup zone. This zone should be a standard primary-type zone, and the zone name needs to match the DNS domain name that you created for your forest.
For example, if your recovery domain controller is server1.recovery.corp.microsoft.com, the zone name needs to be recovery.corp.microsoft.com. The value needs to match the primary DNS suffix that you viewed by using the ipconfig /all command.
After you create the zone, right-click the zone object, click Properties, and then set Allow Dynamic Updates to Yes.
This is a critical step. Until you do this, your server cannot register SRV records in your DNS.
Verify that SRV records for your recovery domain controller have been registered in the zone. The SRV records are displayed under the zone object as a series of folders with names that begin with underscores:
_msdcs
_sites
_tcp
_udp
It may take several minutes before these records are automatically registered. You can also stop and restart the Netlogon service, which causes the records to be displayed more quickly.
Important: If you are remotely connected to the server and lose your connection while the Netlogon service is stopped, you cannot reconnect. Click Re-start Service in Services to stop and start the service in a single operation, or use the following compound command:
net stop netlogon & net start netlogon
Install Exchange 2000.
If the legacyExchangeDN value for your original administrative group includes /ou=First Administrative Group, you do not have to alter the legacyExchangeDN attributes on your recovery server. You can simply install Exchange 2000 by using the correct organization name.
However, if the legacyExchangeDN attribute is different, perform the following procedure:
Run Exchange 2000 Setup with the /forestprep switch.
The /forestprep switch causes Setup to make any Active Directory schema and permissions changes that are necessary for Exchange 2000, but Setup does not actually install Exchange 2000.
Run Exchange 2000 Setup again, and install only the system management tools. To do this, change the install Action next to Microsoft Exchange 2000 (the first selection) to Custom, and then click Install next to Microsoft Exchange System Management Tools.
Important: It is critical at this point that you do not install Microsoft Exchange Messaging and Collaboration Services.
In Exchange System Manager, click Display Administrative Groups on the General tab in the properties of the organization object.
Right-click the Administrative Groups object, click New, and then click Administrative Group. Type the name of the administrative group exactly as the name appears in the /ou= section of the original system's legacyExchangeDN attribute.
Start Exchange 2000 Setup, and install Microsoft Exchange Messaging and Collaboration Services. Join the newly created administrative group when you are prompted to do so during Setup.
Configure storage group and database names.
After Setup finishes, you must create storage group and database names on the server that match the database that you want to recover. If you want to, you can rename an existing storage group or database, or you can create a new storage group and database.
When you restore an online backup, the names of the database files (for example, Priv1.edb and Priv1.stm) do not have to match the names of the database files that are on tape. Only logical naming must be identical.
If you are restoring an offline backup, the situation is reversed; you must match the physical naming of the existing database files, but you do not need to match the logical naming of the storage group or database.
Note: An offline backup consists of the .edb and .stm files for a database, with no log files. If the database was shut down cleanly before these files were copied, you can start the files without the presence of the original log files, and these files generate new log files. If you are restoring an offline backup, delete all of the log and database files on the recovery server before you restore the .edb and .stm files.
An Exchange 2000 database records the names of the organization and administrative group to which the database belongs, but not the server, storage group, or logical database names. An Exchange 2000 database does not even "know" its own physical name. You can rename database files to match the file names that are already configured on the recovery server.
You must match storage group and database logical names only when you restore an online backup. This requirement is enforced by the restoration application programming interface (API) and is not an essential requirement in the databases themselves.
Restore the databases.
Before you can restore a backup of a database that was created on one server to a different server, you must click This database can be overwritten by a restore in the properties of the database object. This is true for both online and offline backups.
Before you restore a database, use Exchange System Manager to dismount the database, but leave the information store service running.
If you are restoring a single online backup, do not forget to change the server name in the Restore To box, specify the temporary location for log and patch files in the appropriate box, and select the Last Backup Set check box. If you select this check box, hard recovery is run immediately after restoration finishes. Hard recovery replays the transaction logs and patch files that were also stored on tape into the database. Until hard recovery finishes, you cannot mount a database.
If you do not click to select the Last Backup Set check box, you can run hard recovery manually by using the Eseutil utility. In the temporary folder that you defined, there is a subfolder that is named according to the storage group. The Restore.env file is in this subfolder, along with log and patch files. The Restore.env file configures the hard recovery process. At a command prompt in the Restore.env location, run the following command:
d:\program files\exchsrvr\bin\eseutil /cc
After hard recovery finishes, you can mount the database.
Reconnect mailboxes to Active Directory accounts.
As described in the "Exchange 2000 Alternate Server Recovery Overview" section of this white paper, you can manually create an Active Directory user account, and then use the Reconnect function in Exchange System Manager to link an account to a mailbox.
Note: When you delete a mailbox by using the Active Directory Users and Computers MMC snap-in, the mailbox is not actually deleted. Instead, the Active Directory attributes that link the user account to the mailbox are removed. Periodically, the Mailbox Cleanup Agent scans the database to make sure that each mailbox is connected to an Active Directory account. Mailboxes that are not connected to an Active Directory account are flagged as disconnected, and then are deleted after 30 days in this state.
Therefore, after you delete a mailbox, you have 30 days to reconnect that mailbox to the same user or to a different user before the mailbox contents are lost forever.
If you are recovering more than a few mailboxes, it can be tedious to create accounts and reconnect those accounts one by one. The Mailbox Reconnect tool (Mbconn.exe) enables you to automate both account creation and mailbox reconnection tasks. The Mbconn tool is located in the Support folder of the Exchange 2000 installation CD.
The Mbconn tool works by running the Mailbox Cleanup Agent and then displaying all disconnected mailboxes in a list. The Actions menu in the Mbconn tool contains an Export Users command. This command scans the list of disconnected mailboxes and generates an LDIF file that contains user account import entries for each disconnected mailbox. Each entry defines properties that enable you to easily reconnect each mailbox to the appropriate user.
You can import the LDIF file into Active Directory, and then generate a matching user account for each mailbox by using the following command:
ldifde –i –f filename.ldf
After you generate Active Directory user accounts, the Preview feature in the Mbconn tool tries to match each disconnected mailbox with an Active Directory account. A green check mark is displayed next to all matched mailboxes. If more than one possible match is discovered, a double check mark is displayed. For these mailboxes, you must choose the account that you want the mailbox to reconnect to. You can also remove suggested matches, or match accounts one at a time.
If you click Save, the Mbconn tool performs the actual reconnections. It may take several minutes for the Recipient Update Service to finish the connection process that the Mbconn tool begins.
Also be aware that immediately after restoration, in the Mailboxes table in Exchange System Manager, the mailboxes in the database are displayed as connected. This is because when the mailboxes were backed up, the mailboxes were connected. The Mailbox Cleanup Agent on the recovery server probably has not run yet and marked all the mailboxes as disconnected. You can run the Mailbox Cleanup Agent manually by right-clicking the Mailboxes object. Until a mailbox is displayed as disconnected, the mailbox cannot be reconnected to any user by any means.
After you reconnect mailboxes, you can gain access to the data in those mailboxes by using several methods. You can log on to the mailbox by using an ordinary e-mail client and salvage data by using the e-mail client's user interface. You can also use the Exmerge utility to automatically export data from multiple mailboxes to individual .pst files for each mailbox.
You may encounter logon problems when you attach to mailboxes even though you have full Exchange and Windows administrative permissions. These logon problems are, paradoxically, probably because you have administrator permissions.
By default, when Exchange 2000 is installed, the installation account and members of the Domain Administrators and Enterprise Administrators groups are explicitly denied Send As and Receive As permissions for all mailboxes in the organization. These permissions are necessary to gain access to a mailbox as a client. Although you can override this denial, the override can be audited. Do not assign yourself such permissions, except on a laboratory server, unless doing so is in compliance with your company's security and privacy policies. For additional information about granting yourself extra permissions, see the following article in the Microsoft Knowledge Base:
262054 XADM: How to Get "Service Account" Access to All Mailboxes in Exchange 2000
The Exmerge utility is located in the Support folder on the Exchange 2000 installation CD. This utility attaches to each mailbox in turn as a MAPI client (similar to the method that Outlook uses to gain access to a mailbox), and copies or moves data from the mailbox to a personal folders database. You can then distribute these databases to individual users, or you can automatically merge the databases back into the users' actual mailboxes in the production system by using the .pst files only as an intermediary storage. The Exmerge utility has many other functions, which include the ability to filter messages by time, date, folder, or other attributes. Exmerge avoids putting duplicate messages back into the production system, but single instance storage is not preserved for messages that you restore by using Exmerge.
Refer to the Exmerge documentation for details about the functions and filters of the Exmerge utility.
Recovering the Site Replication Service Database
Site Replication Service (SRS) is used for directory replication in a mixed site (a site that contains both Exchange Server 5.5 and Exchange 2000 computers). Typically, you configure SRS to run on a single Exchange 2000 computer in each mixed site, although it is possible to have multiple SRS servers.
The contents of an SRS database are very similar to the contents of a normal Exchange Server 5.5 directory database. In fact, Exchange Server 5.5 computers in a site treat the SRS server as just another Exchange Server 5.5 computer. Exchange Server 5.5 computers replicate information with the SRS database during normal replication cycles within a site. You can even connect to the SRS database by using the Exchange Server 5.5 Administrator program (however, avoid making administrative changes while you are connected to the SRS database with Exchange Server Administrator program).
Naming Contexts and Active Directory Connector Connection Agreements
Replication in Exchange Server 5.5 (and also in Active Directory) is based on naming contexts. A naming context is a logical partition in the directory that replicates as an independent unit. Naming contexts can also serve as security boundaries that block the inheritance of permissions. For example, in Exchange Server 5.5, although the Configuration container is under the site container, permissions that are granted for the site do not flow down to the Configuration container. (Similarly, in Active Directory, the Configuration container does not inherit permissions that are granted for the root domain naming context.)
In Exchange Server 5.5, there are five naming contexts, the most important of which are the site and configuration contexts. The site context includes all Recipients containers and mailboxes. The configuration context holds system configuration information. When servers replicate with each other, they replicate each context in separate operations. Replication can be unsuccessful between two servers for the site context, but can still work correctly at the same time for the configuration context.
The Active Directory Connector (ADC) supports replication between Exchange 2000 and Exchange Server 5.5 by replicating information between the Exchange Server 5.5 directory and Active Directory. Each ADC replication link that is defined between the two systems is called a Connection Agreement. The following are the three types of Connection Agreement:
User
Public Folder
Configuration
User Connection Agreements replicate Exchange Server 5.5 custom recipients, mailboxes, and distribution lists as Active Directory contacts, users, and groups. Public folder Connection Agreements replicate only public folders. Earlier versions of ADC enabled public folders to be replicated through normal user Connection Agreements. Although both public folder and user objects exist in the same naming context, some administrators had difficulty configuring public folder replication correctly, so the public folder Connection Agreement type was created for convenience and ease of use. Configuration Connection Agreements replicate information from the configuration naming context in Exchange Server 5.5 to the Configuration container in Active Directory.
The SRS acts as one endpoint for a configuration Connection Agreement. You can also configure user and public folder Connection Agreements to replicate with an SRS server, but those Connection Agreements may also point to actual Exchange Server 5.5 computers.
The following are several advantages to using an SRS server (instead of an actual Exchange Server 5.5 computer) for configuration Connection Agreements:
Because SRS runs on an Exchange 2000 computer, you do not have to reconfigure the Connection Agreement endpoint after you upgrade an Exchange Server 5.5 computer.
SRS can act as a directory replication bridgehead server between a pure Exchange 2000 site and a pure Exchange Server 5.5 site.
After all of the Exchange Server 5.5 sites in your organization have been upgraded with at least one Exchange 2000 computer, you can use "backbone" replication through Active Directory. Instead of the Exchange Server 5.5 sites creating a "daisy-chain" to perform replication between each other, each Exchange Server 5.5 site uploads information to Active Directory, and Active Directory downloads replication changes simultaneously to each Exchange Server 5.5 site. This can significantly reduce replication latency.
Note that before you install the first Exchange 2000 computer in an Exchange Server 5.5 site, you must first install an ADC and configure one user Connection Agreement that connects the Active Directory forest to the Exchange Server 5.5 site. This Connection Agreement is used to discover necessary installation and configuration information for SRS, by giving SRS access to Exchange Server 5.5 directory information. The process that occurs during the creation of an SRS server is very similar to the process that occurs when a new Exchange Server 5.5 computer joins an existing site.
SRS Backup Fundamentals
Like other Exchange 2000 data stores, you can back up the SRS database online by using Windows NT Backup. Although the contents of the SRS database are similar to the contents of an Exchange Server 5.5 directory database, the database itself is an Exchange 2000 database, and shares the same general backup and recovery characteristics as other Exchange 2000 databases.
The SRS database is a directory database; therefore, keep in mind the following two fundamental differences between backing up a directory and backing up an information store database:
In most organizations, there is more than one server with a copy of each directory database. These extra replicas serve as automatic backups to each other. Therefore, it is not critical that your backups be completely up to date. If you must restore an older backup of a directory database, other servers with up-to-date replicas of the database can backfill changes that have occurred after the time of the last backup. This principle applies to Exchange Server 5.5, Active Directory, and the SRS database.
It is critical that you have at least one good backup of each directory database. That backup must be recent enough that the backup contains sufficient configuration information for the database to re-establish communication with other replicas in the system. If a directory database is destroyed and there is no good backup, complete reinstallation of the server or service is usually required.
This is different than an information store database. When an information store database is completely lost, if you start the service with no database present, a new database is created. Although existing user information may be lost in this case, there is no effect on the configuration or functionality of the rest of the system.
The following two recovery scenarios for SRS are presented in the following sections:
Restoration of the SRS database from a good backup.
Re-creating an SRS database when no backup is available.
Restoration of the SRS Database from Good Backup
In Exchange Server 5.5, there is no distinction between starting a database service and mounting the database. Because you can have numerous databases in Exchange 2000, when you start the service and mount particular databases, you perform separate operations (although you can set individual databases to automatically mount on service startup). This is true not just for the information store, but also for all other Exchange 2000 databases.
In Exchange Server 5.5 and Exchange 2000, the database service must be running and the database must be mounted to perform an online backup.
To restore an online backup in Exchange Server 5.5, you need to stop the service, so that the database can be dismounted and overwritten. In Exchange 2000, the service must be started but the database must be dismounted to restore a backup.
When you start SRS, there is no option to mount the database; you start the service and mount the database in a single operation, as you do with an Exchange Server 5.5 database. However, you must somehow put the service in a state in which the service is running but the database is not mounted before you can restore the database.
To accomplish this, start the database in semi-running mode. If the SRS database is damaged or is not present, the service still starts, but the service does not attempt to mount the database or create a new database. This gives you the opportunity to restore from a backup.
This behavior is very different from the behavior that Exchange Server 5.5 administrators have come to expect. The Key Management Service (KMS) restoration process uses a similar mode that has differences that are described in the "Key Management Service Database Recovery" section of this white paper.
To start SRS in semi-running mode, either you must remove all the existing database, checkpoint, and log files from the Dsadata folders before you start the service, or the database must be so damaged that the database is not mountable. An event is logged in the application event log during SRS startup that confirms that SRS is indeed in semi-running mode.
The procedure in the Windows NT Backup user interface to restore the SRS is almost identical to the procedure to restore the information store. You specify a temporary folder, in which the Restore.env file, transaction logs, and patch files for the restoration are copied, and then you select the Last Restore Set check box to signal SRS to begin hard recovery after restoration. You can also use the eseutil /cc command to start hard recovery if you forget to click to select the Last Restore Set check box.
To perform a simple restoration of an SRS database:
Stop SRS, if the service is running, and then remove all files from the Dsadata folders.
Caution: Do not delete these existing SRS files; simply move the files to a safe location.
Start SRS.
You can verify that SRS is in semi-running mode by examining the application event log for an event that is similar to the following:
Event Type: Warning
Event Source: MSExchangeSRS
Event Category: Internal Processing
Event ID: 1400
Date: 3/23/2000
Time: 2:38:14 PM
User: N/A
Computer: EX2000-1
Description:
The Microsoft Exchange Site Replication Service could not initialize its Exchange database (EDB) and returned error 1. The Site Replication Service will wait in a semi-running state so the database can be restored from backup and the SRS can mount it.Restore an earlier backup of SRS, and click to select the Last Restore Set check box in Windows NT Backup.
You do not need to restore the most recent backup. As long as the organization topology has not changed so much that the restored database cannot find replication partners, the database is updated automatically by ordinary replication. In all cases, an SRS database will have other replication partners. In a pure Exchange 2000 site that still uses SRS as an Exchange Server 5.5 directory replication bridgehead server, the SRS database repopulates itself from both Active Directory and Exchange Server 5.5 computers in other sites. If SRS is used in a mixed Exchange 2000 and Exchange Server 5.5 site, the same is true.
Restoration of an Entire SRS Server
If you need to run Setup with the /disasterrecovery switch to recover from the complete loss of an Exchange 2000 computer, the SRS service is disabled after Setup finishes, and no SRS database is created. After you finish recovery of the information store and other databases, you can restore SRS.
Note: After you run setup /disasterrecovery, there are three files in the Srs folder: lconfig.map, Rconfig.map, and Srstempl.edb. These files are template files that are used to generate new SRS databases. If you inadvertently delete these files, you can get new copies of the files from the Setup\I386\Exchange\Srsdata folder on the Exchange 2000 installation CD. You need these files if you are configuring an SRS server at any time other than during an upgrade of an Exchange Server 5.5 computer.
This scenario assumes that all Active Directory information and Active Directory configuration information has survived the disaster intact; the only thing that is still missing is the SRS database itself. To restore the SRS database:
Enable SRS by using the Services MMC snap-in.
Remove any existing files from the Dsadata folder (except the three template files: lconfig.map, Rconfig.map, and Srstempl.edb).
Start SRS. The service should start in semi-running mode.
Start Windows NT Backup, restore a backup of the SRS database, and then click to select the Last Restore Set check box. You do not need to click to select the Mount database after restore check box; hard recovery automatically mounts the database for you.
Note: If you start Windows NT Backup before you start SRS, you may receive the following error message:
The specified computer is not a Microsoft Exchange server or its Microsoft Exchange services are not started.
Restart Windows NT Backup after you start SRS. If you start the service again in the same Windows NT Backup session, you still receive the preceding error message.
Verify that the database has started successfully by examining the application event log. Remember that SRS can start even if the SRS database does not mount. Successful startup of the service does not necessarily signify successful startup of the database.
If you restart SRS after restoration without first allowing hard recovery to run, you create transaction log and checkpoint files in the Dsadata folder that do not match the restored files in the temporary folder. You must remove these newly created files before hard recovery can succeed.
If you forget to select the Last Restore Set check box, and then try to start SRS before hard recovery succeeds, an error message that is similar to the following is logged in the application event log:
Event Type: Error
Event Source: ESE98
Event Category: Logging/Recovery
Event ID: 619
Date: 3/28/2000
Time: 7:15:53 PM
User: N/A
Computer: EX2000-1
Description:
MSExchangeSRS (1280) Attempted to attach database 'D:\Exchsrvr\DSADATA\srs.edb' but it is a database restored from a backup set on which hard recovery was not started or did not complete successfully.
If you force hard recovery with the eseutil /cc command when mismatched files exist, the command does not work, and you receive the following error message:
Operation terminated with error -107 (JET_errInternalError, Fatal internal error)
Either one or both of the following error messages is logged in the application event log, depending on whether a stray Edb.chk file or Edb.log file is present:
Event Type: Warning
Event Source: ESE98
Event Category: Logging/Recovery
Event ID: 457
Date: 3/28/2000
Time: 7:16:56 PM
User: N/A
Computer: PRIDE7
Description:
MSExchangeSRS (1280) The log signature of the existing logfile edb.log doesn't match the logfiles from the backup set. Logfile replay cannot succeed unless all signatures match.
Event Type: Error
Event Source: ESE98
Event Category: Logging/Recovery
Event ID: 454
Date: 3/28/2000
Time: 7:17:43 PM
User: N/A
Computer: PRIDE7
Description:
MSExchangeSRS (1280) Database recovery/restore failed with unexpected error -532.
(A –532 error means JET_errBadCheckpointSignature, and indicates a checkpoint file mismatch.)
After you remove the mismatched log or checkpoint files, hard recovery should finish successfully. If hard recovery does not finish successfully, start the restoration process again by removing Srsdata files, and restoring the database again from an online backup. This time, be sure that hard recovery has finished before you alter the state of SRS.
Re-Creating an SRS Database When No Backup Is Available
If you have no backup of SRS, you can delete and re-create the entire SRS service, as long as you have another Exchange 2000 computer in the site. If you have not yet installed a second Exchange 2000 computer, you can install one temporarily, and then remove the server after recovery is complete.
You need another Exchange 2000 computer because you are not permitted to delete the last SRS in a site until all of the servers in the site have been upgraded from Exchange Server 5.5 to Exchange 2000. This safeguard prevents you from severing the links between the Exchange Server 5.5 and Exchange 2000 computers in the site. However, if you want to start over with a new SRS database on a server, you first need to remove the existing service completely. To solve this dilemma, add a second Exchange 2000 computer to the site because you can delete any SRS that you want to if there is more than one SRS present in the site.
Important: This operation generates approximately the same replication traffic as installing two new Exchange Server 5.5 computers in the site.
To re-create an SRS:
Install a second Exchange 2000 computer in the site, if necessary.
Start Exchange System Manager from the other Exchange 2000 computer. You cannot run Exchange System Manager remotely when you create a new SRS database, although you can attach to the server by using a Terminal Services session, which has all the required characteristics of an actual local console session.
Click to expand Tools to display the Site Replication Services container.
Each SRS in your organization should be listed as Microsoft Exchange Site Replication Service (server_name). If, instead, Directory Replication Service (administrative_group_name) is displayed, click Site Replication Service View on the View menu.
Click the Site Replication Services container, click Action, click New, and then click Site Replication Service.
When you create a new SRS, directory updates are performed that are similar to the directory updates that are performed when you join a new server to a site. Be patient because it may take several minutes, or even longer, for the process to finish.
After you create the new SRS, you can delete the original SRS on the first server.
To move the SRS back to the original server, perform steps 2 through 5 again, but reverse the server on which each action is performed.
Offline Backup of SRS
SRS is not a critical Exchange 2000 service because end users are not affected if SRS is stopped for a short period of time. After you configure a new SRS, you may want to stop that SRS and make a file copy of the Srs.edb file. Because the SRS database can be backfilled from other directory databases, it may be an even simpler operation to restore an offline copy after a disaster than to restore from an online backup. To restore an offline copy of SRS, simply stop the service, remove all files from the Dsadata folder, copy the Srs.edb file to the Dsadata folder, and then restart SRS. Be sure to update the offline copy of the file if you make any topology changes that may affect the ability of the database to find replication partners for backfill after restoration.
Internet Information Service Metabase Recovery
Exchange 2000 uses Simple Mail Transfer Protocol (SMTP) as the native transport protocol, and the Exchange Server 5.5 message transfer agent (MTA) is based on the X.400 protocol. Exchange 2000 still supports X.400 communication for backward compatibility with Exchange Server 5.5 and interoperability with other X.400 systems.
The SMTP transport stack that Exchange 2000 uses is the native Windows 2000 Server stack that is included with the Internet Information Service (IIS). To install Exchange 2000 on a server, you must have already installed the IIS components of Windows 2000 Server, specifically, the Network News Transfer Protocol (NNTP) and SMTP protocols.
IIS stores most of the configuration information in the metabase. The metabase is a hierarchically organized configuration database for all the protocols that IIS manages. The preferred method to read from and write to the metabase is by using the various administrative consoles that are provided for each protocol. A Windows 2000 Resource Kit utility called Metaedit also provides raw access to the metabase, much the same way that Regedit provides raw access to the Windows registry.
In Exchange System Manager, when you make configuration changes for a server in the Protocols container, most of those changes are written to the metabase. Some of the same information is also kept in Active Directory. When you run Setup with the /disasterrecovery switch, and the previous metabase no longer exist.
ts, Exchange 2000 reconstructs, as much as possible, the settings that should be in the local metabase.
Not all information in the metabase is present in Active Directory; therefore, you cannot count on using Active Directory as a substitute for backing up the metabase. For example, NNTP configuration information is not replicated to Active Directory. There are two methods that you can use to back up the metabase. Perform both of the following types of backup because these backups are most useful for different purposes:
Back up the metabase alone by using the Internet Service Manager Microsoft Management Console (MMC) snap-in.
Right-click the server object in Internet Service Manager to display Backup/Restore Configuration. This command enables you to back up and restore the Metabase.bin file while IIS services are online. By default, this file is stored in the Winnt\System32\Inetsrv folder. Backups are stored in the Metaback folder under this file path.
Although a metabase backup occurs online, the metabase is not an Exchange 2000 database. There are no transaction logs, and there is no "roll forward" capability. The backup is an exact file copy of the Metabase.bin file at the time that the backup was taken. Store copies of metabase backups in a secure location off of the server.
Perform a metabase-only backup before and after you make significant configuration changes to any IIS protocols. For Exchange 2000, these protocols include Hypertext Transfer Protocol (HTTP), Post Office Protocol version 3 (POP3), Internet Message Access Protocol (IMAP), NNTP, and SMTP.
If the metabase is damaged or destroyed, you can restore the most recent backup. If the metabase is missing or damaged and there is no available backup, IIS protocol services cannot start.
Back up the server system state, which includes the metabase and installation-specific server security keys that are necessary to start the metabase.
If the entire server installation is destroyed, the metabase file alone cannot restore the system because the metabase is linked to security keys that are specific to the server installation.
If you restore the previous system state, the metabase and the necessary keys are restored together.
If a problem in the metabase prevents Exchange 2000 or IIS protocol services from starting and there is no backup available, you may need to perform the following procedure:
Uninstall and reinstall all IIS services; open the Add/Remove Programs tool in Control Panel, click Add/Remove Windows Components, and then follow the instructions in the Windows Components Wizard.
Run Exchange 2000 Setup with the /disasterrecovery switch to cause Exchange 2000 to read information from Active Directory that is used to reconstruct the previous metabase information as much as possible.
Reconfigure missing metabase settings manually. For example, you need to redo any NNTP virtual directory changes that you have made.
You can use the ADSI Edit or Ldp utilities to view the protocol information that is stored in Active Directory, or you can export all the protocol objects to a text file with an ldifde command that is similar to the following command:
ldifde -f protocols.ldf –p subtree
-d "cn=Protocols,cn=server,cn=Servers,cn=administrative_group,cn=Administrative Groups,cn=organization,cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=corp,dc=mycompany,d=com"
Active Directory Recovery
As an Exchange 2000 administrator, you have a vital interest in whether Active Directory is properly backed up and safeguarded. You need to know how to recover Exchange 2000 if Active Directory is completely lost.
A single mailbox recovery, as described in the "Alternate Server (Single Mailbox) Recovery" section of this white paper, is an Exchange recovery that you perform as if Active Directory has been completely lost. If you know how to perform single mailbox recoveries, you know how to recover from the destruction of Active Directory.
Detailed recommendations about how to back up and restore Active Directory are beyond the scope of this white paper. Nevertheless, there are some general principles that every Exchange 2000 administrator needs to understand about how to preserve Active Directory information. This section contrasts and compares Active Directory with Exchange Server 5.5 to illuminate those principles.
In an Exchange Server 5.5 site that contains more than one server, directory information is automatically replicated between all servers. When replication is up to date, most of the information on each server is identical. If the directory database on one server is destroyed, you can recover the system by using one of the following methods, depending on whether or not you have any backup copy of the directory:
If there is a backup copy, even one that is very out of date, you can restore that backup copy. Backfill replication from the other servers brings the database completely up to date.
If there is no backup copy, you must use the Exchange Server Administrator program to remove the server from the site. Then you can reinstall and rejoin the server to the site to generate a new directory database. When you remove the server from the site, all of the objects that are "owned" by the server are necessarily deleted. Therefore, before you remove the server, you need to connect to another server in the site and export all the directory information for mailboxes that belong to the damaged server. After reinstallation, you can reimport the mailbox data.
Therefore, Exchange Server 5.5 directory databases act as only partial backups for each other. If one database is destroyed, that database cannot be re-created in its entirety from another database in the site.
In Active Directory, each domain controller in the domain is a complete backup of all the others because no objects are owned by specific domain controllers. The domain or the forest as a whole owns objects. If you remove a replica of Active Directory, you do not remove any objects from the directory (unless the server is the last domain controller that exists for a domain).
Important: Replica placement is at least as important to an Active Directory disaster recovery strategy as your backup procedures on each domain controller are.
This does not mean that you should dispense altogether with making backups of Active Directory and rely on having several replicas instead. Replicas back each other up with up-to-date copies of directory information. However, there are times when you may need out-of-date information, for example, after you inadvertently delete an important container, or after you install a rogue application. If you do not have copies of Active Directory that were made before the time that the change that you want to undo was made, it may be difficult or impossible to back out of the problem. Both Exchange Server 5.5 and Active Directory have authoritative restoration capabilities that enable you to restore older information "on top of" newer information when necessary.
Even in the smallest organizations, it is recommended that you have at least two domain controllers to provide two replicas of the Active Directory database. It is recommended that larger organizations have no fewer than three domain controllers for each domain.
Store backup copies of Active Directory for each domain in a safe offsite location, especially if all domain controllers are geographically close to each other. As a minimum backup plan, perform at least one backup for each domain, both before and after you make significant changes to Active Directory.
If you have more than one replica of Active Directory, your disaster recovery efforts are greatly benefited in the following ways:
Service to clients is not interrupted by destruction of one of the directories; therefore, you do not have to treat the restoration process as an emergency.
You have more options to recover from the disaster. You can restore from a backup, you can rebuild the server and join the server to the domain again as a domain controller, or you can bring up a third server as a replacement domain controller.
In summary, it is critical to the survival of your network that you preserve Active Directory information. Because the directory is replicated, it is easy to provide online redundancy. If you have an intelligent replica topology and carry out sensible periodic backup procedures, you can recover a lost directory by using several methods without undue time pressure.
Key Management Service Database Recovery
Perhaps no other Exchange 2000 data is as critical to safeguard as your security certificate and Key Management Service (KMS) information because if you lose security information, the loss may affect not just one server, but may mean the loss of critical mail on every server in your organization. If you lose even one of the components that make up your security infrastructure, all the rest of the components become useless.
You must keep copies of all of the following items to recover Exchange 2000 keys and ensure that encrypted e-mail messages remain readable:
The certification authority (CA) certificates for each of your CA servers (.p12 files).
These certificates may exist in a chain that must be reconstructed in its entirety. Each certificate is linked to the server name; therefore, if you must reinstall entire servers, you must give those servers the same names that the servers previously used. The CAs are not inherently linked to any particular Active Directory installation.
The passwords that protect each .p12 certificate file.
The Active Directory database that contains user accounts that have been granted administrative permissions for the KMS database.
You can configure KMS to allow different administrators different privileges, and you can even require that two administrators log on at the same time to perform certain operations. You must have access to at least one "full" Administrator account. Note that although the account that is used to validate access to a KMS database is a Windows account, the password that is required is not the Windows account password. If you forget the KMS password, you cannot recover or reset the password.
The KMS database startup password.
You can store this in a plain text file to be read automatically when KMS starts, or you can type the password manually in the properties of the service during each startup.
The KMS database itself, which you can back up online by using Windows NT Backup. You must back up the KMS database to a local device; you cannot back up the database from a remote Windows NT Backup installation.
KMS and CA Overview
The Exchange KMS provides key escrow services for secure mail. KMS stores a copy of each Exchange user's private key (this key enables each user to read encrypted e-mail messages). The users' public keys are stored in the directory. If users lose their private keys, the KMS administrator can recover the private keys and restore access to encrypted e-mail messages.
Public and private encryption key pairs are generated by complex mathematical algorithms. An item that is encrypted with the public key from a given pair can only be decrypted by the private key from the same pair. An item that is encrypted with the private key can only be decrypted by the public key. It is very difficult to derive the private key from the public key, and it is highly unlikely that any other key pair could be used to decrypt or encrypt a given item. These characteristics make public key encryption technology very secure and attractive because there is no need for two users who want to communicate securely with each other to trust each other enough to create a "shared secret" or shared password.
If a user can decrypt a message from you with your public key, that is proof that the message actually came from you because nothing but your private key can encrypt the message that way. If that user wants to send you a message, the user can encrypt the message with your public key, and know that no one except you can read the message.
There is a weakness in this system; how can you know that the public key that you have obtained for a person actually belongs to that person? This is where certification authorities (CA) play a critical role.
A CA is an entity that vouches for the integrity and authenticity of public keys. Generally speaking, CAs do not keep copies of the private keys that they certify. As a matter of implementation and security, both public and private keys are usually generated by a client application, not by the CA. The client sends only its public key to the CA. The CA then signs the client public key with its own public key, bundling both keys into a tamper-proof package called a certificate. Recipients of this certificate can rely on its authenticity as much as they can rely on the trustworthiness of the CA that issued the certificate. CAs can be linked to each other in hierarchical chains of trust or in a peer-to-peer web of trust.
KMS archives private keys for a corporate e-mail environment where encrypted mail is the property of the business, not of the individual user. If a user loses private keys inadvertently, or leaves the organization, an administrator can recover the user's private keys and gain access to all encrypted e-mail messages.
In versions of Exchange Server earlier than Exchange Server 5.5 Service Pack 1, the Key Management server (KM server) acts as its own CA. As its own CA, KM server is a self-contained, independent unit in Exchange Server. Although KM server administration and maintenance is therefore very simple, this version of KM server cannot communicate with or establish trust with other CAs. Therefore, the practical use of this version of KM server is limited to exchanging secure e-mail messages between users in a single Exchange Server organization. Users in separate organizations can theoretically exchange mail and keys with each other, but cannot verify the validity of certificates that they exchange. In Exchange Server 5.5 Service Pack 1, KM server was modified to act as its own CA for X.509 version 1 certificates, or to rely on an external CA to generate X.509 version 3 certificates. With this new capability, KM server can establish chains of trust for cross-authentication with other organizations and mail systems.
In Exchange 2000, Key Management Service (KMS) can still generate X.509 v1 certificates for earlier version clients that do not support X.509 version 3 certificates. Nevertheless, a Windows 2000 root or subordinate enterprise CA must be available before you can install KMS for Exchange 2000. You must think of KMS in Exchange 2000 as a system that encompasses the CA server, the Active Directory database, and the KMS database.
A public key infrastructure (PKI) is an architectural system and set of processes and policies for issuing, validating, revoking, and otherwise managing encryption keys. If you have no PKI in place before you install KMS, the installation of KMS commits you to PKI architecture decisions that will have a long-term impact. It is still easy to install KMS and activate Advanced Security for your users, but it is difficult to abandon a bad or "stranded" PKI architecture and start over. Before you install KMS, you should answer the following questions:
Will you integrate your PKI with one of the commercial CAs?
How many CA servers will you have, and how will you logically and physically deploy those CA servers? In a web of trust? In a hierarchy?
Who will be in charge of the system, and how will you ensure both security and continuity for your private keys? How will you deal with personnel changes? Will your root servers be offline to protect those servers?
What will your policies be for key archival and recovery, not just of Exchange 2000 keys, but also of all the other key types that you can manage with the Windows CA? How will you manage help desk, education, and security issues for your user community?
Until you have very clear answers to these questions, it is premature to deploy KMS, unless you are willing to do so with the understanding that there is no guarantee that encrypted data will be preserved long term.
Usually, when an individual acquires encryption and signing keys from a commercial provider, only one public key and one private key is generated. The individual both signs and encrypts e-mail messages with the same key pair. Exchange 2000 generates two key pairs: one pair for encryption, and one pair for signing. Only the key pair for encryption is preserved in the KMS database. KMS does not archive signing keys, and signing keys cannot be recovered.
Signing keys are not archived to prevent forgery of a user's digital signature by an administrator. Although a corporate administrator may have a legitimate interest in recovering a user's e-mail messages, an administrator can have no legitimate interest in recovering a user's signing keys because the only reason to recover a user's signing keys is for the purposes of impersonation. All e-mail messages that were previously signed can still be verified as authentic as long as the user's public key is still published, even if the private key is lost. Exchange 2000 generates two key pairs deliberately to separate the encryption and signing functions.
If your organization has no interest in being able to recover encrypted e-mail messages administratively, you do not need KMS, and a better secure e-mail strategy may be to use a commercial service that provides individual encryption and signing keys, or even to use the Windows CA to generate Secure/Multipurpose Internet Mail Extension (S/MIME) keys for your users.
If you use the Web enrollment form (https://caserver/certsrv), you can enable users to generate their own user certificates. If you are just beginning to explore secure mail and PKI issues, you can even install a certificate server on a stand-alone Windows 2000 Server–based computer for laboratory and pilot purposes. Of course, certificates that are issued by this server are not widely trusted and therefore are of limited usefulness.
If users want to back up these certificates or make the certificates portable between workstations, the users must use the Advanced form and mark the private key as exportable. Keys that are generated by using this method are tied to the e-mail address that is defined for the user in Active Directory, and the ultimate user of the keys must be logged on to Windows to generate the keys.
After the keys are created, the keys are automatically stored in the certificate store on the user's workstation. You can use the Certificates Microsoft Management Console (MMC) snap-in to gain access to this store and to export keys. If you want to give the certificate to an intended recipient of encrypted e-mail messages, export only public keys for the certificate. If you want to make a backup of the certificate that you can transfer to another workstation or restore to this workstation, export both the private and public keys.
In Microsoft Outlook 98 or later, you can click Options on the Tools menu, click the Security tab, and then import keys to a workstation's local certificate store, as well as define the keys in the certificate store that you want to use to sign and seal e-mail messages (click Setup Secure E-Mail). To exchange secure e-mail messages with another Outlook user, each of you needs to send a signed message to the other. You can sign messages by clicking to select the Add digital signature to outgoing message check box in the Message Options dialog box for the message. Your public key is included with every signed message (unless you clear this default when you set up secure mail).
The recipient of a signed message can then import your public key into the recipient's own certificate store by right-clicking the sender's name in the From line, and adding the sender to the Contacts list.
Note: An Outlook Address Book service that is linked to the Contacts folder must be defined in the user's profile. If you are exchanging keys with a user who does not use Outlook, you can attach a copy of your public key to a message after you export the key from your certificate store. Methods to import such a file vary from e-mail client to e-mail client.
Preparing Your CA for the Installation of KMS
To use KMS, make sure that you have already installed an Active Directory–integrated enterprise CA. You must also enable the CA to issue the three certificate types that Exchange 2000 requires, as follows:
Start the Certification Authority MMC snap-in.
Right-click the Policy Settings object, click New, and then click Certificate to issue.
Add the following three certificate templates:
Enrollment agent (Computer)
Exchange User
Exchange Signature only
Make secure backups of your CA certificates for every CA. Is also strongly recommended that you back up the issued certificate database (also called the issued certificate log), although this is not absolutely essential to restore KMS. However, if you lose the database, that loss may cause other problems, including the loss of some or all of your certificate revocation list (CRL).
It is recommended that you back up a CA server by using Windows NT Backup to back up the entire server, including the system state. You can also back up only the most critical CA information from the Certification Authority MMC snap-in as follows:
Start the Certification Authority MMC snap-in.
On the Action menu, click All Tasks, and then click Backup CA to start the backup wizard.
Click Private key and CA certificate for backup. You must have a backup of the CA certificate that includes the certificate's private key to restore KMS.
Usually, it is recommended that you also back up the certificate log. The certificate log database is an Extensible Storage Engine (ESE) database and is backed up by using an online backup procedure that is similar to the procedure that is used for an Exchange Server information store.
When you are prompted to select a password for the backup, type a strong password, and safeguard the password well. If you forget the password, the backup is useless. Even more important, if an unauthorized person steals and restores the backup, your entire certification chain of trust is compromised. Your CA certificate private key is literally the key to everything in your certificate system.
After backup finishes, a small .p12 file and a Database subfolder that contains the certificate issue database are located in your backup folder. You can import the .p12 file to another CA, and after you do so, that CA can mimic signing certificates as if the CA is your own. Safeguard the .p12 file as one of your most valuable corporate assets.
Installing KMS
During installation of KMS, you are prompted to set a KMS password. This password is required every time that you start the KMS service and database. Without this password, the database can never be started again. You can have the password displayed and then write the password down, or you can have the password written to a plain-text Kmserver.pwd file in a location that you choose.
Without this password, a stolen copy of the encrypted KMS database cannot even be started, much less read. Even with the password, a thief would require access to several other passwords and pieces of information to retrieve keys from the database.
There are several different types of passwords that are required to administer KMS, and you need to know about them all. If you lose any one of these passwords, you are effectively locked out of the KMS system:
Passwords for the CA certificate backups for each of your CA servers.
Password to start the KMS database, either written down manually or stored in the Kmserver.pwd file.
Passwords for KMS administrators. You can allow KMS administrators to only perform certain tasks, and you can even require that two or more administrators enter passwords to perform sensitive tasks ("missile silo" security).
Important: You cannot reset or recover these passwords if you lose these passwords.
Although KMS administration privileges are granted by using Windows user accounts, the passwords to perform KMS tasks are not the same as the Windows logon passwords for those accounts. Keep the following items in mind:
Only another KMS administrator who has privileges to grant privileges to other accounts can help you if you forget your KMS password. Even if you have all Windows Active Directory privileges, that does not help you if you forget your KMS password.
Because administrative privileges are granted to Windows accounts, if all Windows accounts with administrative privileges in KMS are destroyed, you cannot assign new administrators to the KMS database. You are effectively locked out forever.
When KMS is first installed, the installation account is granted administration privileges with a default password of "password".
Caution: Be careful when you change defaults to require that multiple administrators must present passwords to perform certain system tasks on the Passwords tab because it is possible to create a situation in which the critical number of administrators that are necessary to change system policies are unavailable or have forgotten the passwords, which effectively disables at least some administrative actions.
Overview of Restoring KMS
If every server in your organization is destroyed, you need all of the following backups and passwords to restore KMS functionality:
CA root and subordinate certificates .p12 file backups and passwords.
Active Directory backup that contains KMS administrator accounts.
KMS database backup and database startup password.
KMS administrator passwords
This section describes a complete disaster recovery in detail. In summary, to perform a complete disaster recovery involves the following steps:
Restoring Active Directory.
Restoring the CA servers.
Restoring the KMS database.
Restoring Active Directory
To restore Active Directory, refer to the "Active Directory Recovery" section of this white paper.
Restoring the CA Servers
The only two pieces of information that are absolutely essential to restore a CA are the CA certificate and the original CA server name. You do not even need the previous Active Directory forest (but you do need Active Directory to restore KMS). You must restore a CA to a server that has the same name as the original CA server.
To restore the CA:
In Control Panel, double-click Add/Remove Programs, click Add/Remove Windows Components, and then click to select the Certificate Services check box for installation.
In the Setup wizard, select a CA type that matches the original CA type. If you are installing a subordinate CA, you must first install all of the upstream CAs in the chain.
Click to select the Advanced Options check box, and then click Next.
Click Import, and then import your .p12 backup of the CA certificate. You are prompted to supply the password. After you import the .p12 backup, click Next.
Verify that the CA Identifying Information dialog box displays the correct information for your previous CA, and then finish the rest of the wizard, modifying paths and other configuration information as necessary.
In the Certification Authority MMC snap-in, change the policy settings to issue the three additional certificates that are required by Exchange 2000 as described in the "Preparing Your Certification Authority for the Installation of KMS" section of this white paper.
After installation of the CA finishes, you can restore your issued certificates database by using the Certification Authority MMC snap-in.
Restoring the KMS Database
To restore a previous KMS database to a new KMS installation:
Install KMS from the Exchange 2000 Setup CD. You do not need to reinstall KMS to an Exchange 2000 computer that has the previous name, but you may prefer to do so.
If you put the KMS startup password in the Kmserver.pwd file, move this file to a safe location.
Stop the KMS service, and move all of the files in the Exchsrvr\Kmsdata folder to a safe location.
Copy the previous Kmserver.pwd file into place, if the previous Kmserver.pwd file exists.
Start the KMS service. If you do not use a Kmserver.pwd file, you must type the startup password in the Start Parameters box for the service.
As with the SRS service, if you start KMS with no database in place, the service starts in semi-running mode to await the restoration of a backup.
Use Windows NT Backup to restore the previous KMS database.
Stop and restart the KMS service.
It may take some time for the KMS service to receive the system certificates that KMS needs from the CA. Until this occurs, you may be unable to perform some administrative tasks. You may or may not need to recover keys for users, depending on whether Active Directory information was lost in the disaster, and whether any user workstations were involved.
Remote Offline Backup of the KMS Database
The KMS service is not involved in day-to-day security operations between users. If you stop the service or take the KMS server offline, this normally has no effect on users who are already enrolled in Advanced Security. The server is necessary only to enroll new users or to recover lost keys.
For security reasons, Windows NT Backup works only against a local KMS database. You cannot backup the KMS database online from across the network by using Windows NT Backup because the KMS database is invisible when you run Windows NT Backup remotely. This makes it more difficult for unauthorized personnel to discover the location of the server.
It is recommended that you secure your KMS server even against most Exchange 2000 and network administrative personnel, and you may even want to leave the KMS server offline most of the time if enrollment is not a task that you perform frequently in your environment.
Nevertheless, if you need to back up KMS from a remote location:
Install Terminal Services or another remote client on the KMS server.
Note: To accommodate multiple simultaneous administrative sessions, Terminal Services shrinks the pool of some memory resources that are allocated by default to the console session. Do not install Terminal Services on an Exchange 2000 computer that you expect to be under heavy memory pressure, such as a mailbox server that has several hundred users. Instead, use a more "lightweight" remote console client that provides access to only a single client session, such as Microsoft NetMeeting®.
Start Windows NT Backup in the remote console session, and then back up the KMS database to a file, instead of tape.
Remotely back up the .bkf file that you created to tape.
You can automate this process by scheduling Windows NT Backup to run under the Task Scheduler service on the KMS server.
Appendix A: Changing legacyExchangeDN Attribute Values
This appendix describes how to change legacyExchangeDN values on an existing Exchange 2000 computer so that the server can accommodate a database that is stamped with different values. Some situations in which you may want to change legacyExchangeDN values include the following:
You set up a recovery server incorrectly, and you want to avoid completely uninstalling and reinstalling the recovery server.
You create a dedicated recovery server, and you want to use the dedicated recovery server to recover databases from more than one administrative group or organization.
The procedure that is described in this appendix is intended only for use in a laboratory environment. In a complex production environment, this procedure may have unintended consequences, and may cause databases to stop responding or may cause mail flow to stop. The instructions in this section assume that you are performing this procedure in a single-server Active Directory forest, and that communication and mail flow with other servers is not essential.
At first, this procedure may seem complex and confusing, but after you practice the procedure a few times, you can change a server from one organization and administrative group to an entirely different organization and administrative group in a matter of minutes.
Keep in mind that you can no longer start existing databases after you make these changes. In most cases, this is not a concern. However, the Exmerge utility requires the database that houses the system attendant mailbox to be running. In most cases, this database is the first mailbox store that is created during installation. (While a database is running, you can inspect the Mailboxes table to determine where the system attendant mailbox is located.)
If you cannot start the system attendant's database, you can delete that database (assuming that there is no other critical data in that database), or move that database temporarily out of the way. During the next attempt to mount the database, a new database is created, along with a new system attendant mailbox.
To wipe a database, stop the information store, and then move the .edb and .stm files that are defined in the database properties. Restart the information store, and then mount the database in Exchange System Manager.
To alter the legacyExchangeDN values for an existing Exchange 2000 computer:
If necessary, change the organization and administrative group names.
You cannot change an organization name by using Exchange System Manager, but you can change the organization name by using the Active Directory Sites and Services Microsoft Management Console (MMC) snap-in.
Important: Never change the organization name in a production environment.
To change the Exchange 2000 organization name, open the Active Directory Sites and Services MMC snap-in, and then click Show Services Node on the View menu. Click to expand the Services container, click to expand the Microsoft Exchange container, right-click the organization object, and then click Rename. You can continue to expand Exchange 2000 containers and change other names as well, including administrative groups.
Note: You can also change administrative group names in Exchange System Manager, but only after you switch the organization to native mode.
Generate an LDIF export file that contains all of the objects that must be changed.
Export all objects in the Microsoft Exchange container, including the Microsoft Exchange container, by using an ldifde command that is similar to the following:
ldifde -f e:\legacy.ldf -p subtree -l legacyexchangedn -d "CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=corp,DC=mycompany,DC=com"
-r "(legacyexchangedn=*/ou=First*)"
(Refer to the "Exchange 2000 Alternate Server Recovery" section of this white paper for more details about how to use Ldifde and how to determine existing legacyExchangeDN values.)
In the preceding command, the –l LDAP_attribute_list parameter restricts the output for each object that is found to only the legacyeExchangeDN attributes. This parameter is very important because you need to edit this file to re-import the file. Any extra attributes are clutter that you need to delete before you can successfully import the file.
The –r LDAP_filter parameter returns only objects that have a legacyExchangeDN value that includes the string "First". In most cases, the current legacyExchangeDN value on your recovery server includes /ou=First Administrative Group. But if the current legacyExchangeDN value is different, you can substitute an appropriate search string.
This command should generate an export file that contains several entries similar to the following:
dn: CN=RECOVERY1,CN=Servers,CN=First Administrative Group,
CN=Administrative Groups,CN=ORGANIZATION1,
CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mycompany,DC=com
changetype: add
legacyExchangeDN:
/o=Organization1/ou=First Administrative
Group/cn=Configuration/cn=Servers/cn=RECOVERY1There may be anywhere from six objects to several dozen objects, depending on how many storage groups or databases are defined for this administrative group.
Modify each legacyExchangeDN value.
You can modify each legacyExchangeDN value manually, one by one, by using the Ldp or ADSI Edit utility with the Legacy.ldf file that you just generated as a guide. But it is likely to be much easier to modify each legacyExchangeDN value by performing a bulk import.
To perform a bulk import, you must modify the Legacy.ldf file significantly; this modification is not as simple as just changing the /ou= value and importing the file. The Ldif import format to make modifications to existing objects differs considerably from the format to add new objects, and the file that you exported is a "new object" file.
It is much easier to change the export file into a proper import file if you have a text editor that supports search and replace across line breaks. Notepad does not support this capability, but Microsoft Word does. If you do not have an appropriate text editor, it still only takes several minutes to make the modifications that you need.
A simple LDIF import file that is designed to modify an existing attribute on an existing object consists of records in the following format:
dn: distinguished name of the object to be modified
changetype: modify
replace: attribute name
attribute name: new value
-
<blank line>
next record . . .You need to change each record from the following
dn: CN=RECOVERY1,CN=Servers,CN=First Administrative Group,
CN=Administrative Groups,CN=ORGANIZATION1,
CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=microsoft,DC=com
changetype: add
legacyExchangeDN:
/o=Organization1/ou=First Administrative
Group/cn=Configuration/cn=Servers/cn=RECOVERY1to the following:
dn: CN=RECOVERY1,CN=Servers,CN=First Administrative Group,
CN=Administrative Groups,CN=ORGANIZATION1,
CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=microsoft,DC=com
changetype: modify
replace: legacyExchangeDN
legacyExchangeDN:
/o=Organization1/ou=New Administrative
Group Name/cn=Configuration/cn=Servers/cn=RECOVERY1
-
The items that you need to change are formatted in bold type and are red in the preceding example. Specifically, you need to make the following changes:
You must change the changetype value from add to modify.
You must add a line that reads replace: legacyExchangeDN under the changetype line.
You must change the administrative group name to the correct value.
You must add a hyphen on a line by itself after each entry, and there must also be an additional blank line after every hyphen.
Note: The LDIF import format is strictly adhered to; even minor deviations cause errors when you try to import the file. There must be one space and only one space after each colon in each entry. If you need to break long lines, you must indent the continuation of each line exactly one space. At the end of the file, the last entry must also contain a hyphen, and a blank line under the hyphen, or the file does not import correctly.
Many text editors, including Word, use the characters ^p to represent line breaks. ("^p" does not stand for "CONTROL+P", but for the caret (^) character followed by a lower case p.) The following table uses the ^p convention to represent a line break.
Search for . . . |
Replace with. . . |
|---|---|
/ou=current_value |
/ou=new_value |
^p^p |
^p-^p^p |
changetype:[space]add^p |
changetype:[space] modify^preplace:[space] legacyExchangeDN^p |
Important: If you use Word or another word processing program to edit the file, be sure to save the file as plain text. Inspect the file in Notepad after you save the file to be sure that the file is readable and is formatted correctly as plain text.
After you generate the import file, import the file back into Active Directory by using the following command:
ldifde -i -f legacy.ldf
All objects should import successfully. If there are any problems, Ldifde reports the line on which a problem was encountered. Investigate such problems by carefully examining the affected record in the import file. For most errors, Ldifde stops the import procedure at the first error, even if records after the error are good. If the cause of an error is not immediately obvious, it may be more efficient to remove the problem record, finish the import, and then manually modify the object that did not import by using ADSI Edit or Ldp.
You can verify that all objects were modified by running the ldifde command that you used previously to export the objects. The command should now locate no objects to export because all legacyExchangeDN values have been changed.
Note: To avoid overwriting your import file, change the –f filename parameter to con so that Ldifde output is sent only to the screen.
After you modify the legacyExchangeDN values, you need to stop and restart all Exchange 2000 services, which include the system attendant. Before you do this, the previous naming is cached, and the system performs as if you did not make any changes.
For More Information
For the latest information about Exchange 2000 Server, see the following Microsoft Web site: