emc replication manager and microsoft exchange … exchange 2000/2003 to offer an end-to-end...

White Paper

Abstract

This white paper describes how Replication Manager integrates with Microsoft Exchange 2000/2003 to offer an end-to-end solution of continuous availability. It discusses recommendations for configuration, mount, and restore, and describes step-by-step procedures for mailbox recovery. December 2011

EMC REPLICATION MANAGER AND MICROSOFT EXCHANGE 2000/2003 A Detailed Review

2 EMC Replication Manager and Microsoft Exchange 2000/2003 - A Detailed Review

Copyright © 2004-2011 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided “as is.” EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. Part Number h809.5


Table of Contents

Executive summary.................................................................................................. 4

Introduction ............................................................................................................ 4

Audience ............................................................................................................................ 4

Replication Manager architecture ............................................................................. 4

Replication Manager GUI console and CLI ........................................................................... 5

Replication Manager Server ................................................................................................ 5

Replication Manager agents ............................................................................................... 6

Replication Manager Exchange 2000/2003 agent .............................................................. 6

Storage services and technologies ........................................................................... 7

CLARiiON replication .......................................................................................................... 7

Symmetrix replication ......................................................................................................... 7

Celerra replication .............................................................................................................. 8

Invista replication ............................................................................................................... 8

RecoverPoint family ............................................................................................................ 8

Microsoft VSS framework integration ....................................................................... 9

Configuring the Exchange production server ........................................................... 10

Disabling circular logging ................................................................................................. 11

Other recommendations ................................................................................................... 11

Configuring the Exchange backup server ................................................................ 11

Microsoft Exchange replication on Windows 2000 .................................................. 11

Microsoft Exchange 2003 replication process ........................................................ 12

Mounting Exchange replicas .................................................................................. 13

Restoring Exchange replicas .................................................................................. 14

Restoring with Exchange 2000 ......................................................................................... 15

Restoring with VSS ........................................................................................................... 15

Restore considerations .......................................................................................... 15

Exchange mailbox store recovery ........................................................................... 16

User mailbox recovery ...................................................................................................... 17

Recovering a deleted mailbox using the Exchange System Manager ................................. 17

Reconnecting a deleted mailbox to a new user object ....................................................... 18

Recovering a deleted mailbox using the Exchange 2003 recovery storage group .............. 19

Conclusion ............................................................................................................ 25

References ............................................................................................................ 25


Executive summary EMC® Replication Manager is a software application that simplifies the creation and management of disk-based replicas. Replication Manager automates the creation of exact point-in-time copies of mission-critical data that can be used for rapid recovery or repurposing.

Replication Manager is designed to tightly integrate with Microsoft Exchange, coordinating replica creation with Microsoft Volume Shadow Copy Service (on Windows 2003) or array-based, hot-split technology (on Windows 2000) to ensure a complete copy of active Exchange stores without disrupting the application.

This white paper focuses on Replication Manager’s application integration with Microsoft Exchange 2000 and Exchange 2003.

Introduction This white paper provides a brief overview of Replication Manager architecture and supported storage technologies, followed by a description of Replication Manager’s integration with Microsoft Volume Shadow Copy Service. It continues with recommendations for configuring the Exchange production server and backup server, and under-the-hood details on the replication process. The paper describes important information on mounting and restoring Exchange replicas. Finally, step-by-step procedures for mailbox recovery are provided.

Audience

This white paper is intended for customers and internal EMC personnel who need an introduction to Replication Manager support for Exchange 2000 and Exchange 2003 and procedures for replication and recovery.

Replication Manager architecture Replication Manager uses a LAN and SAN to communicate and control storage-based functions. Figure 1 shows the Replication Manager architecture and the components that reside in various parts of the system. An introduction to each component is provided.


Figure 1. Replication Manager software architecture

Replication Manager GUI console and CLI

The Replication Manager Console is a portable Java application that lets you control Replication Manager from a Windows system that has a TCP/IP connection to the Replication Manager Server.

A command line interface is also provided. It can be run interactively or in batch mode.

Replication Manager Server

The server software is installed on a Windows system. It controls replication activities and stores data about each replica. The server software has three distinct components:

• Replication Manager Server Service, also known as the IRD, controls and

coordinates replication and recovery activity for all storage corresponding to registered clients and their application sets. The IRD also handles all requests from the Replication Manager Console.

• Policy engine links Replication Manager with the supported storage arrays. The policy engine is a set of dynamic libraries that link to the Replication Manager Server Service.


• Replication Manager Repository is an embedded database that stores data about application sets (for instance, information about Exchange storage groups), jobs (mount, backup, log truncation, and so on), and replicas.

When installed on Microsoft Cluster Server, Replication Manager Server components fail over in the event of a cluster failover.

Replication Manager agents

Replication Manager agent software is installed on each host that participates in the replication process, including hosts that manage production data and hosts that are used to mount and back up replicas. The agent software has three distinct components:

• Replication Manager Client Service, also known as the IRCCD, waits for incoming requests from the IRD, then coordinates all operations on the agent.

• Storage services component manages the storage relationships between the IRCCD and the storage technologies used to create the replicas.

• Application agents are provided for each supported information interface, including Exchange 2000/2003. Each agent is a separate library, dynamically linked and loaded with the IRCCD at runtime. The following section describes the Exchange 2000/2003 agent in detail.

Replication Manager Exchange 2000/2003 agent

Replication Manager uses array-based, hot-split technology to support replication of storage groups for Exchange 2000 and Exchange 2003 installed on Windows 2000. To support Exchange 2003 on Windows Server 2003, Replication Manager uses Microsoft Volume Shadow Copy Service (VSS) technology.

As with agents for other applications, the Exchange 2000/2003 agent provides Replication Manager with a logical view of the data that resides on the storage array. The agent enables Replication Manager to:

• Specify which storage groups to replicate.

• Ensure that the data can be replicated safely.

• Return the database to normal operation.

When replicating storage groups on Windows 2000, the Exchange agent communicates with the Microsoft Exchange Information Store service to discover storage group information and control the state (online or offline) of the mailbox stores. It works with technology in the storage array to create a hot-split replica. (Support for Exchange 2003 on Windows 2000 is provided as an interim solution as you migrate to Exchange 2003 on Windows Server 2003.)

When replicating storage groups for Exchange 2003 on Windows Server 2003, the agent communicates with the Microsoft Exchange Information Store service and the Exchange 2003 VSS Writer to discover storage group information and create an application-consistent VSS shadow copy replica.


Storage services and technologies This section summarizes the storage technologies supported by Replication Manager and how they relate to Exchange replication.

CLARiiON replication

On CLARiiON® arrays, Replication Manager can take advantage of both clone and snapshot functionality. Clones are fractured from the source and therefore have no impact on production environments, and are ideal for creating copies of production data for business continuity and backup acceleration. Snapshots offer an alternative to clones in that they require less space, but because they are pointer-based they may cause spindle contention, in which case users may opt for the performance benefit provided by clones. Since both features are included with SnapView™, customers can evaluate which makes the most sense for their particular environment. CLARiiON-based storage technologies to consider for Exchange replication are:

• CLARiiON SnapView clone, which creates exact copies of active production data on separate drives

• CLARiiON SnapView clone (remote), which creates clone LUNs of a MirrorView™/S secondary device (Targets that use multiple secondaries are not supported by Replication Manager.)

• CLARiiON SnapView snapshot, which creates SnapView snapshots of CLARiiON LUNs

• CLARiiON SnapView snapshot (remote), which creates SnapView snapshots of a MirrorView/S secondary device (Targets that use multiple secondaries are not supported by Replication Manager.)

• SAN Copy™, which is a storage system application that copies data between storage arrays (Symmetrix®-to-CLARiiON and CLARiiON-to-CLARiiON) and within a CLARiiON array

Symmetrix replication On Symmetrix arrays, Replication Manager can take advantage of TimeFinder®/Mirror (BCVs), TimeFinder/Clone (STDs), or TimeFinder/Snaps (VDEVs). Symmetrix-based storage technologies to consider for Exchange replication are: • TimeFinder/Mirror, which creates mirror images of active production volumes from

a standard device onto a BCV device

• TimeFinder/Mirror (remote), which creates mirror images of active production volumes from a standard device onto BCVs for R2 devices across an SRDF link

• TimeFinder/Clone, which creates copies of active production volumes in which the source and target devices can be either STD or BCV devices

• TimeFinder/Clone (remote), which creates copies across an SRDF link from an R1 device onto a STD or BCV on a remote Symmetrix


• TimeFinder/Snap, which creates copies of active production volumes or R1 devices onto a TimeFinder/Snap (also known as a VDEV) on the local Symmetrix

• Symmetrix TimeFinder/Snap (remote), which creates copies of active production volumes onto TimeFinder/Snaps (VDEVs) by way of an R2 device located on a remote Symmetrix array (connected to the production volumes using SRDF/S)

• SAN Copy (Symmetrix-to-CLARiiON)

Celerra replication

On Celerra® iSCSI network servers, Replication Manager can take advantage of Celerra SnapSure™ for local snapshots or Celerra Replicator™ for remote snapshot functionality. When you create a replica using iSCSI Celerra snapshot functionality, Replication Manager creates a point-in-time copy of all data on the source LUN. For the initial snapshot, Replication Manager creates a full copy of the original LUN, therefore requiring the same amount of space on the file system as the LUN. Subsequent snapshots space usage depends on how much the data has changed since the last snapshot was taken. For copy replicas, a full copy is created each time the job runs.

Invista replication

Invista® is EMC’s storage virtualization technology. The storage attached to the Invista instance is exposed to Replication Manager as Invista Virtual Volumes. Invista instances virtualize the underlying storage and allow you to manage the storage as you see fit. Invista instances are discovered in the same way that other supported storage arrays are discovered. Invista Virtual Volumes display in the tree panel and the storage type for replicas is clones. Clones can be used for data that changes a great deal in a short time or storage of more critical data. Replication Manager helps customers manage Invista clones that are often used for data refresh/repurposing of test and development copies, backup to tape, or EMC Disk Library.

RecoverPoint family

Replication Manager now supports EMC RecoverPoint software, enabling users to manage applications protected by RecoverPoint Continuous Data Protection (CDP), RecoverPoint Continuous Remote Replication, and RecoverPoint Concurrent Local Remote Replication (CLR). Replication Manager’s support for RecoverPoint provides near-instantaneous mounting of critical business data. It allows rapid recovery of the data on a volume to any point in time (crash-consistent recovery) or to a significant point in time (application-consistent recovery). Replication Manager with RecoverPoint addresses the problem of lengthy recoveries of files and databases made by traditional backup software. It allows rapid reconstruction of a volume image that may be only seconds or minutes old.


Microsoft VSS framework integration Replication Manager leverages the functionality provided by Microsoft Volume Shadow Copy Service (VSS) that facilitates the creation of application integrated shadow copy backups. Specifically, Replication Manager uses VSS to perform online replication of Exchange 2003 storage groups. VSS is included with Windows Server 2003 (but not with Windows 2000).

VSS provides the framework to create point-in-time, transportable shadow copies of Exchange 2003 using hardware-assisted technologies. There are three components of VSS: a requestor, a writer, and a provider. A VSS requestor is typically a backup application—it initiates the creation of a shadow copy. Replication Manager is a VSS requestor. The VSS writer is the application-specific component in the shadow copy creation and restore/recovery process. The VSS writer is provided by Exchange 2003. The VSS provider creates and manages the shadow copy. Replication Manager uses the EMC provider that works with its storage arrays. The Volume Shadow Copy Service coordinates these functions as shown in Figure 2.

VSS provides point-in-time recovery and roll-forward recovery of Exchange 2003 storage groups via Copy and Full backup modes. Both modes back up the databases and transaction logs, but only the Full mode truncates the logs after a successful backup. Since these shadow copies are transportable, they can be mounted to alternate hosts for consistency checking, backup, or mailbox recovery.

Figure 2. Volume Shadow Copy Service components


Configuring the Exchange production server The EMC Replication Manager Product Guide contains detailed installation instructions and requirements for configuring the Exchange production server. For example, data that is shared in a Microsoft Cluster Service (MSCS) environment will require an alternate, nonclustered mount host. Ensure that you have met the prerequisite software and hardware requirements as outlined in the EMC Replication Manager Release Notes and EMC Replication Manager Support Matrix.

Because the storage group replication process takes place transparently to the Exchange server, there are minimal requirements on the server itself. All Exchange mailbox, log, and system files to be backed up must be on storage supported by Replication Manager. You can use the Exchange System Manager to relocate all of the storage group files to appropriate volumes. This includes all mailbox store (*.edb and *.stm) and transaction log and checkpoint files for each Exchange storage group.

It is also best to arrange the data so that volumes used for Exchange data do not share physical volumes with other data that is not associated with that storage group. This prevents potential problems when you restore data from a replica to the production Exchange server.

A storage group consists of up to five mailbox stores, transaction logs, and system files (such as the checkpoint file). There can be up to four storage groups on an Exchange server. A mailbox store consists of two files: the database file and streaming database file.

When preparing your Exchange environment for Replication Manager, note the following requirements:

• The database file (.edb) and its associated streaming database file (.stm) must be on the same volume. The location of the database and streaming database files are controlled by the “Database” properties of the mailbox store.

• The transaction log files cannot be on the same volume as the mailbox store files. The location of the transaction log is controlled by changing the “Transaction log location” property of the storage group.

• The checkpoint file (E00.chk) for each Exchange storage group must be located on the volume that contains the logs for that storage group. The location of the checkpoint file is controlled by the “System path location” property of the storage group.

• Circular logging must be disabled (see next section).

• Data pages for hot-split replicas must be aligned on a 4K boundary to prevent data corruption.

• A domain account must exist with Exchange Full Admin privileges.


Disabling circular logging

Replication Manager requires circular logging to be disabled. Circular logging is disabled by default when you create an Exchange storage group. If you enabled circular logging, you must disable it for proper Exchange recoverability after a hot-split or VSS backup.

Note: If you change the circular logging status of a storage group, the Microsoft Exchange Information Store service must be stopped and restarted.

Circular logging alleviates storage constraints on the transaction log volume by keeping only the latest five logs and deleting the rest. Without a full history of transaction logs, you cannot replay transactions against a cloned copy of the Exchange mailbox store. When circular logging is disabled, you must be more careful with log file maintenance, because transaction logs continue to build up. Replication Manager can be used to truncate transaction logs.

Deleted item retention needs to be properly configured. Microsoft Exchange Server allows you to retain deleted items for a specified period. You can restrict the purging of these deleted items after a full backup. However, hot-split backups do not trigger the purging of deleted items. If you are using hot-split technology and you select the “Do not permanently delete mailboxes and items…” option, be sure to run periodic online streaming backups of your storage groups.

Other recommendations

If you want to restore at the storage-group level, Microsoft Exchange 2000/2003 storage groups must be arranged on physical volumes so that each storage group uses separate physical volumes for the Exchange data and the logs.

If you want to restore individual mailbox stores, each store must be located on a separate physical volume.

Configuring the Exchange backup server To mount an Exchange replica for consistency checking only, it is not necessary to install the complete Exchange server software on the backup host. For Exchange 2003, install the Exchange Administrator Tools. For Exchange 2000, copy eseutil.exe and ese.dll from the production Exchange server to the mount host and specify that location in the Replication Manager job.

Microsoft Exchange replication on Windows 2000 Replication Manager automatically creates a physical copy of the Exchange 2000/2003 databases (mailbox stores) and transaction log and checkpoint files for the storage groups that you select.


Replication Manager uses the hot-split capabilities of the array to manage the actual replica creation. The following steps describe the process:

1. Checks the Exchange Server event log for database consistency errors. As

Exchange reads pages in its databases, it checks them for damage (referred to as torn pages), and reports them in the event log as a -1018 error. The database can usually continue running, but you should perform a recovery as soon as possible. Replication Manager checks the event log for -1018, -1019, and -1022 errors and stops upon finding a torn page. This helps to avoid replicating a corrupted database on top of your previous good replica.

2. Extracts the database, transaction log, and system paths from the production Exchange server.

3. Discovers and establishes the mirrors (or creates the snapshot sessions) and creates a replica that captures the database, transaction logs, and checkpoint files for the selected storage groups.

4. Creates the replica by performing a hot split.

5. Mounts the replica to a backup server. In a CLARiiON environment, Access Logix™ is automatically used to present the LUNs to the backup server. There is no need to present the LUNs manually ahead of time.

6. Checks the database and log consistency using Eseutil. When you run an integrity check on the database replicas, you can expect to find a logical inconsistency reported because the replica has been split while the database was active. Upon recovery, log files are applied to make the database current and consistent. The integrity check looks for evidence of physical inconsistencies and damaged database pages, which are indicated by a checksum error. The Exchange Eseutil utility looks for checksum errors in Exchange 2000 databases. When the utility reports no checksum errors, the database is available for recovery.

Note: If you change the circular logging status of a storage group, the Microsoft Exchange Information Store service must be stopped and restarted.

7. Truncates logs using the Exchange 2000 backup API. (Transaction logs cannot be truncated on Exchange 2003.)

The production Exchange server remains available throughout the entire replication. There is no disruption of this server during this process.

Microsoft Exchange 2003 replication process If you are creating replicas of Exchange 2003 on Windows Server 2003, Replication Manager does not use hot-split technology to quiesce the mailbox stores. Instead, Replication Manager uses VSS to perform a truly online replication. In this environment, you can select Online Full or Online Copy as the replication option:


• Online Full — Replication Manager replicates the mailbox store(s), transaction logs, and checkpoint files, and then runs Eseutil to verify the consistency of the databases and logs. If Eseutil completes successfully, Replication Manager instructs the Exchange VSS Writer to truncate the logs so that only changes that are uncommitted to the database remain. Microsoft requires that you mount the replica as part of the job, and run Eseutil. If the mount fails for any reason (Eseutil or device errors, and so forth), the logs are not truncated and the replica fails. The transaction log files cannot be on the same volume as the mailbox store files. The location of the transaction log is controlled by changing the “Transaction log location” property of the storage group.

• Online Copy — Replication Manager replicates mailbox store(s), transaction logs, and checkpoint files in the same way as it does during a Online Full option; however, it does not truncate the logs. Online Copy replications are often intended for testing and diagnostic purposes only.

A limitation in the Microsoft’s Exchange VSS Writer prevents two Exchange 2003 replicas from running at the same time on the same machine, even if they are replicating different storage groups. Therefore, Replication Manager runs one replica at a time; subsequent replicas must wait until the previous replica is completed.

The following steps describe the Exchange 2003 replication process:

1. Replication Manager:

a. Runs a scheduled job

b. Pre-syncs the production LUNs to the clone LUNs

c. Tells VSS to create a shadow copy of the selected storage groups

2. Next, VSS:

a. Tells the Exchange Writer to prepare for a backup (freezes I/O)

b. Tells the EMC provider to create a shadow copy that must complete in under 10 seconds

c. Releases Exchange to resume operation (thaws I/O)

3. Finally, Replication Manager:

a. Mounts the replica and runs a consistency check to verify integrity of the database and transaction logs

b. Informs Exchange (through VSS) that the backup was successful. (Full VSS backup will truncate logs at this time.)

Mounting Exchange replicas Consider mounting a replica when you need to run a consistency check, do a backup, or perform a mailbox recovery.


For Exchange 2000, Replication Manager runs the consistency check against the Exchange databases. For Exchange 2003 it is run against the database and the logs. Replication Manager uses the eseutil /k command when running a consistency check.

RM can run Eseutil in parallel on several databases simultaneously in Replication Manager. This can shorten the overall time required to complete the consistency check. Running Eseutil in parallel on CLARiiON is not recommended. Keep the default (sequential) option if the databases reside on the same LUN.

When creating a replica for backup, be sure to enable the mount option Copy Metadata Files To. This option copies the following files to a specified location that you can then specify when backing up the replica volumes:

• The Exchange writer metadata document, RMVSSEXCHWRITERDATA

• The backup components document, RM_VSS_BCD

• Replication Manager metadata for the replica, RM_DB_METADATA

Restoring Exchange replicas There are various scenarios and methods for performing Exchange recoveries. You may need to recover a server due to corruption, or to perform a mailbox restore, for example. Depending on the circumstances and the version of Exchange being recovered, the processes vary. Refer to the Microsoft Exchange Disaster Recovery Guide for your specific version of Exchange. This guide provides details on each of the possible recovery methods.

Replication Manager can manage either a partial (database only) or full (storage group – database, transaction log, and checkpoint files) restore of Exchange replicas to the production Exchange server.

When a Microsoft Exchange replica is restored, the following restore options are available:

• All storage groups in the application set

• One or more storage groups in the application set

• One or more database(s) from the application set (database files only or database files and log files)

When you are restoring a database file from an older replica, verify that the transaction log files needed for recovery are present. An unbroken sequence of transaction log file generations is required. To determine the minimum required range, run the following Eseutil command against each database after the restore and look for the log required information:

eseutil /mh <database name>


A Microsoft Exchange 2000/2003 replica includes a checkpoint file (.chk) that records the location in the transaction log files of the last complete transaction that Exchange wrote to the database. If you choose to perform a full restore of databases and logs, the checkpoint file helps Exchange know where to start if you choose to roll the database forward. If there is no .chk file, Microsoft Exchange 2000/2003 starts with the oldest transaction in the log file.

Restoring with Exchange 2000

In Exchange 2000, if you choose to perform a partial restore (a single database) without restoring the transaction logs, Microsoft recommends that you perform the following steps in the order shown, after the restore.

After Replication Manager restores the data and log files:

Note: Because restores are done at the physical volume level, all other data on the volumes is overwritten.

1. Dismount all databases in the storage group.

Note: If you are using Microsoft Exchange 2003, Replication Manager dismounts the databases in the storage group automatically. In a Microsoft Exchange 2000 environment, you must manually dismount any databases in the storage group that were not restored.

2. In Exchange 2000, remove the .chk file from the system path folder.

3. Remount all databases in the storage group. When you remount all databases, Exchange automatically applies the logs.

Restoring with VSS

On Windows 2003, Replication Manager coordinates with VSS and Exchange 2003 to restore the volumes containing the databases and logs that you have selected to recover. If you choose to restore just one database from a storage group, Replication Manager takes all databases in the storage group offline, because no temporary restore directory is available in which logs can be played forward. When restoring a VSS replication, you must restore it to the same location on the server from where it originated. Also, you cannot restore a VSS replication to a recovery storage group. VSS will automatically delete the checkpoint file if it is not needed.

Restore considerations If a replica contains one storage group and both logs and databases are selected for restore, the logs will overwrite any newer logs created since the replica was created. This means that the database will represent the point in time when the replica was taken. To preserve logs created since the replica was taken, only the database(s) should be restored without transaction log files. This will prevent Replication Manager from restoring older logs over newer logs.


To restore at the storage group level, Microsoft Exchange 2000/2003 storage groups must be arranged on volumes so that each storage group uses separate physical volumes for the Exchange data and the logs. To restore individual databases, each database must be stored on a separate physical volume.

If data other than that associated with the storage group resides on the same physical volumes, users may inadvertently restore data that they did not intend to restore or overwrite data they did not intend to overwrite.

When restoring from an older replica, you should restore the entire storage group; otherwise you will need to fill in gaps in the log sequence.

Exchange mailbox store recovery From the Replication Manager Console, expand the replicas object tree, select the replica you want to recover, and invoke the restore wizard. To restore all the database files in the storage group, without restoring the log files, select Exchange Database Files under the selected storage group, as shown in Figure 3.

Figure 3. Selecting a mailbox store from a storage group without the log files


User mailbox recovery

One of the most time-intensive tasks for Exchange administrators involves recovering single mailboxes or single messages from Exchange backups. The alternative is a lengthy process of setting up a recovery server, loading the last full backup from tape, and then recovering a single mailbox. Having a standby recovery server saves some time but adds cost and administrative overhead. To improve service to internal clients and meet service level agreements (SLAs), administrators need a simpler, faster, more accurate method of restoring individual Exchange items. The scenario presented in the next section uses a feature of Exchange 2003 to recover a deleted mailbox. The scenario in “Recovering a deleted mailbox using the Exchange 2003 recovery storage group” on page 16 recovers a mailbox using an Exchange 2003 recovery storage group.

Recovering a deleted mailbox using the Exchange System Manager

If you mistakenly delete a mail-enabled user account, you can re-create that user object and then, by default, reconnect that mailbox for a period of 30 days. This is because when you delete a user, Exchange retains a user’s mailbox for a specified period.

You configure Exchange to retain a user’s mailbox in the same way that you specify how many days Exchange retains mail that a user deletes. You configure a deleted mailbox retention period at the mailbox store object level.

To configure a deleted mailbox retention period:

1. Using Exchange System Manager, navigate to the mailbox store for which you want to configure a deleted-mailbox retention period.

2. Right-click that mailbox store, and select Properties.

The Mailbox Store Properties dialog box appears (Figure 4).


Figure 4. Mailbox Store Properties, Limits tab

3. On the Limits tab in the Keep deleted mailboxes for (days) field, type the number of days you want Exchange to retain deleted mailboxes.

Reconnecting a deleted mailbox to a new user object

If you delete a user account, the user’s mailbox is not actually deleted until the deleted mailbox retention period expires. The following procedure outlines the steps for reconnecting a mailbox. In the following example, John Doe is a mailbox-enabled user that you previously deleted, and you are within the 30-day deleted mailbox retention period.

To reconnect a deleted mailbox to a new user object: 1. From Active Directory Users and Computers, create a new user object for John Doe.

Important: When creating the new user object, clear the Create an Exchange Mailbox checkbox. This is to create a new Windows account without creating a corresponding Exchange mailbox. You will connect this user account to a mailbox later in this procedure.

2. From Exchange System Manager, navigate to the information store on which John Doe’s mailbox is located. In the details pane, locate the mailbox for John Doe.


Note: Verify that the Mailbox icon appears with a red X, as shown in Figure 5. Mailboxes that are displayed with a red X are mailboxes that have been deleted but will be retained in the mailbox store until the deleted mailbox retention period expires. If the Mailbox icon does not appear with a red X, right-click Mailboxes and select Run cleanup agent.

Figure 5. Disconnected Mailbox

3. Right-click the mailbox named John Doe, and select Reconnect.

4. In New User for this Mailbox, select the new user object you created for John Doe, and then click OK.

Recovering a deleted mailbox using the Exchange 2003 recovery storage group

The recovery storage group feature in Exchange Server 2003 allows you to mount a replica of an Exchange mailbox store on the same server as the original database (production server), or on any other Exchange server in the same Active Directory. This can be done while the production database is running and serving clients. This capability allows you to recover data from an older copy of the database without disturbing user access to current data. One common recovery scenario is to use the recovery storage group to recover mail from individual mailboxes. Mail can be recovered by copying or merging it from the recovery storage group databases to the active database using the mail merge tool built into Exchange System Manager.

1. Before you can use a recovery storage group, you must first create it manually.

Using Exchange System Manager, right-click the Exchange server where you want to create the recovery storage group and select New > Recovery Storage Group


(Figure 6). Keep in mind that the Exchange replica cannot be mounted when creating the recovery storage group. Even though the entire replica will be mounted, you do not have to recover every database in the replica.

Figure 6. Creating a new Recovery Storage Group

The Recovery Storage Group Properties dialog box appears, as shown in Figure 7.

Figure 7. Identifying where to mount log files


2. Modify the Transaction log location and System path location fields to point to where the log files will be mounted. Click OK.

The recovery storage group is created and now you need to add the databases you want to recover.

3. Right-click on the new recovery storage group and select Add database to recover. The Select database to recover dialog box appears, as shown in Figure 8.

Figure 8. Add database to recover

4. Select one of the databases that you want to recover and click OK. The Properties dialog box for the database appears (Figure 9).


Figure 9. Database properties

5. Modify the Exchange database and Exchange streaming database fields on the Database tab to point to where the database files will be mounted. Make sure the databases in the recovery storage group are dismounted and This database can be overwritten by a restore option is selected. Then, click OK.

6. Using Replication Manager, select the replica from which you want to recover data. Right-click the replica and select Mount Replica. Select the production host or alternate host, and the mount point used when you created your recovery storage group.

7. When the replica is successfully mounted, you must change the prefix of the log and system files. Open a command prompt window and change to the directory where the log files are mounted. Run the command shown in Figure 10:


Figure 10. Renaming the log and system files

8. Using Eseutil, perform a soft recovery of the database using the alternate mount paths of the database, system, and log files. It is important to run the command without any spaces after the /L, /S, and /D options (Figure 11). If the alternate mount path has any spaces in the name, enclose the path in double quotes.

Figure 11. Running eseutil

9. Using the Exchange System Manager, right-click each recovered database in the recovery storage group and select Mount Store. The This database can be overridden by restore option must be selected. Click Yes on the warning dialog box that appears.

10. Once Exchange mounts the databases, you can recover data from mailboxes using the Exchange System Manager. To recover mailbox data, select the Mailboxes node that appears when you expand the database node.

The mailboxes for that database will display in the right-hand panel (Figure 12).


Figure 12. Selecting the Mailboxes node

11. Select the mailboxes that you want to recover. Right-click and select Exchange Tasks. The Exchange Task Wizard appears.

12. Click Next. The Available Tasks window appears (Figure 13).

Figure 13. Available Tasks window

13. Select the Recover Mailbox Data option and click Next.


14. Select the appropriate destination mailbox store and click Next.

15. Depending on whether you want to merge the mailbox data or copy the mailbox, select either Merge Data or Copy Data, and click Next.

16. Schedule the task and click Next.

17. When you are done recovering mailboxes, use Exchange System Manager to dismount and delete each database in the recovery storage group. Right-click each database and select Dismount. Then right-click and select Delete.

18. When all of the databases have been deleted, delete the recovery storage group. Right-click on the recovery storage group and select Delete.

19. Using the Replication Manager Console, unmount the replica.

Conclusion By tightly integrating with Microsoft Exchange 2000/2003 and coordinating with VSS and array-based hot-split technologies, Replication Manager automates nondisruptive creation of exact copies of Exchange stores. Support for full and partial restores to the production server or a backup server enables you to take best advantage of the mailbox recovery procedures described here.

References For more information about Replication Manager, refer to the following sources:

• EMC CLARiiON Storage Solutions Microsoft Exchange 2003 Best Practices -Storage Configuration Guidelines

• EMC Solutions for Microsoft Exchange 2003 CX Series iSCSI - Best Practices Planning Guide

• EMC Replication Manager Administrator's Guide

• EMC Replication Manager Product Guide

• EMC Replication Manager Release Notes

• EMC Replication Manager Support Matrix on E-Lab™ Interoperability Navigator

For more information about Microsoft Exchange 2003, refer to the following source:

• Using Exchange Server 2003 Recovery Storage Groups

emc replication manager and microsoft exchange … exchange 2000/2003 to offer an end-to-end...

Documents