| Downloads |
|---|
| 21801.zip |
Every administrator should know how to set up an offline copy of his or her production Exchange 2000 Server system. This skill is essential for three reasons. First, you inevitably receive requests to recover mailboxes, folders, or individual messages from backup tape. No matter how strict you are about not retrieving individual items from tape, you'll find yourself making exceptions for important messages or certain people. To retrieve such items, you'll need the functionality of an offline server. Second, restoring to an offline server is a good disaster-recovery drill. Restoring your production Information Store (IS) to an offline server not only confirms that your backup tapes and recovery procedures are sound but also provides good practice and keeps you confident that you can get your systems up and running quickly after disaster strikes. Third, restoring to an offline server lets you check the integrity of your database. When your Exchange services stop unexpectedly (e.g., because of a power failure), you usually count on the mailbox and public stores to restart with no problems. But are you sure no problems have occurred?
The best way to prevent disasters is to watch for developing problems and solve them before they become severe. When you restore to an offline server, you can use Exchange Server's Eseutil and Isinteg tools to verify that the database tables within the IS files aren't corrupted. Whenever a server crashes, the possibility always exists that some small error might go unnoticed—for example, a corrupted pointer that doesn't cause problems until months later. If you have an offline copy of your IS, you can assess the stability of the databases after such an outage. Obviously, you can't accomplish some of these tasks on your production systems. You need a server that can access your production database files without affecting your business operations.
In Exchange Server 5.5, you're limited to an offline server that's not only separate from your production domain but also physically isolated from your production network. This restriction typically leads to cloning a domain controller (DC) so that you have access to the service account's Windows NT SID, then building an Exchange Server machine that has the same name as your production system. In Exchange 2000, you're no longer relegated to a completely disconnected network, you don't need to clone the service account's SID, and you aren't constrained by the server's original name. (These advantages are possible because each server no longer needs its own directory.) I recommend scheduling regular restores to an offline server to validate your procedures, backup tapes, and software and to force yourself to practice recovery procedures.
Satisfying Requirements
So, what information do you need to gather before you build your offline server? First, the offline Exchange Server machine's organization name must match the organization name of the production system that you're duplicating. To satisfy this requirement for Exchange 2000, you must establish a separate Active Directory (AD) forest. Because Exchange 2000 relies on AD to store the organization's and administrative groups' naming information, you can have only one Exchange Server organization per AD forest. Second, because administrative groups provide the same partitioning mechanism as sites do in earlier versions of Exchange Server, the names of the administrative groups must also match. Third, the offline server's storage group (SG) and logical database names must match the names that you use on the production server. Fourth, the LegacyExchangeDN attributes of all offline server objects must match the production system's LegacyExchangeDN attributes. To accommodate backward compatibility with Exchange 5.5, the Exchange 2000 LegacyExchangeDN attribute resides on each Exchange 2000—related object. Understanding the exact purpose of the attribute isn't essential. You simply need to know that it exists, because to successfully mount copies of your production databases, you'll probably need to alter the attribute's value after you install Exchange 2000 on your offline server.
More About the LegacyExchangeDN Attribute
In earlier versions of Exchange, the distinguished name (DN) is always in the form /O=Organization/OU=Site/CN=Container/CN=Object. When you install Exchange 2000, the legacy DN is constructed in one of two ways, depending on whether you're performing an initial Exchange 2000 installation or upgrading from an existing Exchange Server installation to Exchange 2000. If you're upgrading to Exchange 2000, the values that Exchange Server applies to the root portion of the LegacyExchangeDN attribute (i.e., the /O and /OU components) will be the same as your Exchange 5.5 organization and site names (e.g., /O=COMPAQ/OU=Americas). If you aren't upgrading, Exchange 2000 uses the organization name that you specify during installation to construct the /O portion of the DN and always uses First Administrative Group for the /OU portion (e.g., /O=COMPAQ/OU=First Administrative Group). The instructions I provide later for building an offline server assume that you're performing an initial Exchange 2000 installation. If you're working with databases from a system that you've upgraded from Exchange 5.5, the databases won't mount until you modify the offline server's attributes to match the original DN.
The easiest way to determine which value your production system's LegacyExchangeDN attribute holds is to use the ADSI Edit utility. You can load ADSI Edit by installing the Windows 2000 System Tools from the Win2K installation CD-ROM. When you run ADSI Edit, you'll see three naming-context trees: Configuration, Domain, and Schema. To display the name of your first administrative group, expand the Configuration tree, as Figure 1 shows. (In this example, my Exchange 5.5 production server has an organization called TESTBED, which has a site name of FAIRFAX.) Right-click your administrative group name, then select the Properties option from the menu to display the Properties dialog box that Figure 2 shows. Select the LegacyExchangeDN attribute, and in the Value(s) field, you see the value that you need when you construct the offline copy of your production databases.
9 Steps to an Offline Server
For the purposes of the following steps, assume you have a production server named EX1 that has two SGs. The first SG has three databases, and the second SG has two databases, as Figure 3 shows. The following steps duplicate the Mailbox Store 1b store to an offline server.
1. If you used ADSI Edit to examine the LegacyExchangeDN attribute, then you've already begun the first step, which is to gather and record the names and attribute values you need. You need six pieces of information: the Exchange Server organization name, the administrative group name, the SG name, the logical database name, the physical database names, and the LegacyExchangeDN attribute value. The logical database name is the display name that you assigned to the database in your SG (e.g., Mailbox Store 1b). The physical database names are the filenames of the disk's database components (e.g., priv1b.edb, priv1b.stm).
2. Install a Win2K server. The name that you give the server isn't important. When you install the server, be sure to install Microsoft IIS and include the SMTP and Network News Transfer Protocol (NNTP) components, which Exchange 2000 requires. Also, make sure you use the same Windows and Exchange Server service pack levels as the production system's.
3. Choose Start, Run and run Dcpromo to create a separate forest. On the wizard's second and third pages, choose the appropriate options to create a new DC and domain tree. On the fourth page, create a new forest, using a name that's different from your network's existing forests. During this process, the system prompts you to install DNS. Unless your offline server needs to connect to your production DNS server, I recommend that you install DNS on the offline server simply to keep everything self-contained.
4. Use the Exchange 2000 setup.exe program's /forestprep and /domainprep command-line options to add the appropriate schema definitions to your new forest's directory. During this process, specify an Exchange Server organization name that's exactly the same (including case) as your production environment's Exchange Server organization name. After you complete the /forestprep and /domainprep steps, run setup.exe again to install Exchange 2000 on your server. For this installation, you can use the Typical settings.
5. Before you begin restoring databases, you must confirm that you've properly configured on your offline server the information you gathered in Step 1. If you haven't, you'll need to reconfigure the offline server. You configured the organization name during the /forestprep process, so the next item you need to configure is the administrative group. In new Exchange 2000 installations, the software creates a default group named First Administrative Group. Because I upgraded my production Exchange 2000 server from Exchange 5.5, Exchange 2000 inherited the administrative group named FAIRFAX. I needed to modify this name for my offline installation. To do so, I used Exchange System Manager (ESM) to make two configuration changes. I started ESM, right-clicked the Organization Level container, and selected Properties. After I confirmed that the Display Administrative Groups check box was selected, I clicked the Change to Native Mode button. (I needed to switch to Exchange 2000's native mode so that I could rename the administrative groups—a functionality that isn't available in mixed mode.) Next, I used ESM to select the First Administrative Group and rename it to match the name of my Exchange 5.5 site (i.e., FAIRFAX).
6. Create an SG whose name matches the name of the SG that the database you want to duplicate belongs to. (In my example, the name of the SG was First Storage Group, so I had nothing to modify.) After you create the SG, create a database within the SG and give it the same logical and physical filenames as the production database that you want to duplicate. The offline database doesn't need to have the same partition letter and pathname as the production database. Information that you set during the restore process will let you recover databases to a location that's different from that of the original production database.
7. Modify the LegacyExchangeDN attribute value. This step might seem complicated, but it isn't. First, use the Ldifde utility to generate an export file that contains the current attribute values. Open a command prompt and enter the command that Listing 1 shows. When you execute this command, change the DC= values to reflect the domain in which your Exchange Server machine resides. This example uses the domain name test.net. (If your domain name were recovery.domain.com, you would use DC=recovery, DC=domain, and DC=com.) The Ldifde command queries AD, then exports to the fix.ldf file the names of any objects in the LegacyEchangeDN attribute's value that contain the word First. Use a text editor to open the fix.ldf file. You need to modify the entries in the file, then import the file to set the proper LegacyExchangeDN attribute value on your offline server. Perform the following steps for each entry in the file: First, replace all occurrences of First Administrative Group with your Exchange 5.5 site name (e.g., FAIRFAX). Second, edit the changetype: add lines to read changetype: modify. Third, immediately below each changetype: modify line, add the line
Replace: LegacyExchangeDN
Fourth, separate each entry in the fix.ldf file with two specially formatted lines. Immediately after the attribute value data, add a line that contains only one dash, followed by one blank line. Your goal is to create entries similar to those that Figure 4 shows.
Save your work, then use the following command to import the fix.ldf file to the offline server:
ldifde -i -f fix.ldf
If you encounter any errors during the import, the lines that Ldifde can't process will appear on your screen. Carefully check the syntax of those lines. After the import finishes successfully, you might want to rerun the original Ldifde export command to export the LegacyExchangeDN attribute values to a new file to confirm that you didn't miss any changes. Examine the output to confirm that you've successfully modified all attributes. Next, stop and restart the Exchange services.
8. Access ESM. You'll find that the databases haven't mounted. In the event log, you'll see that the IS has reported event ID 1088. This expected error confirms that each standard database is linked to the LegacyExchangeDN attribute value that Exchange 2000 automatically set during the installation. After you modified this attribute in AD—in Step 7—you rendered the databases currently on disk unusable with this server.
On each database's Properties tab, you must select the Database can be overwritten by a restore check box, then restore the databases from tape. For more information about restoring Exchange Server databases from tape, see "Restoring the Exchange 2000 Store Step by Step," April 2001.
9. Monitor the event logs for the Extensible Storage Engine 98 (ESE98) events 901 and 902. These events signal the start and completion of the recovery process. After the recovery successfully finishes, use ESM to mount the store. You'll now be able to determine whether your backups are valid. If they aren't valid, you'll see errors in the event log as the system replays transaction logs or as the databases fail to start.
When you complete these steps, you'll have a copy of your IS available on an offline server. You can use that copy of the IS for many purposes. For information about your next step, see the sidebar "Extracting a Mailbox to a Personal Store File." If you want to mount other databases or SGs from the same administrative group offline, you need only create the appropriate message store or SG, then use standard Exchange 2000 restore procedures to make the database available on your server.
After you successfully perform this procedure once, repeat it. Try recovering your public folder store. Recover multiples stores simultaneously. Extract multiple mailboxes to a personal store (.pst) file. Practice makes perfect. Disaster recovery is one task that you don't want to "learn as you go" when the boss's mailbox is unavailable.
