• The mailbox database copy being activated must be configured with a replay lag time greater than 0.
  
  
• The mailbox database copy being activated must have all log files to the point in time to which you want to recover it. Keep in mind that database transactions can span multiple log files when determining the point in time to which you want to recover.
  
  

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Mailbox database copies" entry in the High Availability Permissions topic.

Note:
You can't use the Exchange Management Console (EMC) to activate a lagged mailbox database copy to a specific point in time.

1. Suspend replication for the lagged copy being activated by using the Suspend-MailboxDatabaseCopy cmdlet, as shown in this example.
   
   

   	Copy Code
   Suspend-MailboxDatabaseCopy DB1\EX3 -SuspendComment "Activate lagged copy of DB1 on Server EX3" -Confirm:$false

2. Optionally (to preserve a lagged copy), take a file system-based (non-Exchange aware) Volume Shadow Copy Service (VSS) snapshot of the volumes containing the database copy and its log files. You can use the vssadmin.exe tool that's included in Windows to take a VSS snapshot, as shown in this example.
   
   

   	Copy Code
   vssadmin create shadow /For=C:\mountpoints\db01 vssadmin create shadow /For=C:\mountpoints\db01_logs

   Note:
   At this point, you have shadow copies outstanding for the database and log volumes. Continuing to perform this procedure on the existing volume would incur a copy on write performance penalty. If this isn't desirable, you can copy the database and log files to another volume to perform the recovery.

3. Determine which log files are required to replay into the database to meet your point-in-time requirement for this recovery (based on log file date and time, as shown in Windows Explorer). All logs created after this point should be moved to a different directory, until the recovery process is completed, and the logs are no longer needed.
   
   
4. Delete the checkpoint (.chk) file for the database.
   
   
5. Use Eseutil to perform the recovery operation, as shown in this example.
   
   

   	Copy Code
   Eseutil.exe /r eXX /a

   Note:
   In the preceding example, eXX is the log generation prefix for the database (for example, E00, E01, E02, and so on).

   Important:
   This step may take a considerable amount of time, depending on several factors, such as the length of the replay lag time, the number of log files generated during that period, and the speed at which your hardware can replay those logs into the database being recovered.

6. After log replay is finished, the database is in a clean shutdown state and can be copied and used for recovery purposes.
   
   
7. After the recovery process is complete, resume replication for the database that was used as part of the recovery process, as shown in this example.
   
   

   	Copy Code
   Resume-MailboxDatabaseCopy DB1\EX3

For detailed syntax and parameter information, see Suspend-MailboxDatabaseCopy or Resume-MailboxDatabaseCopy.

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Mailbox database copies" entry in the High Availability Permissions topic.

1. Optionally (to preserve a lagged copy), take a file system-based (non-Exchange aware) Volume Shadow Copy Service (VSS) snapshot of the volumes containing the database copy and its log files.
   
   
   1. Suspend replication for the lagged copy being activated by using the Suspend-MailboxDatabaseCopy cmdlet, as shown in this example.
      
      

      	Copy Code
      Suspend-MailboxDatabaseCopy DB1\EX3 -SuspendComment "Activate lagged copy of DB1 on Server EX3" -Confirm:$false

   2. You can use the vssadmin.exe tool that's included in Windows to take a VSS snapshot, as shown in this example.
      
      

      	Copy Code
      vssadmin create shadow /For=C:\mountpoints\db01 vssadmin create shadow /For=C:\mountpoints\db01_logs

      Note:
      At this point, you have shadow copies outstanding for the database and log volumes. Continuing to perform this procedure on the existing volume would incur a copy on write performance penalty. If this isn't desirable, you can copy the database and log files to another volume to perform the recovery.

2. Activate the lagged mailbox database copy using the Move-ActiveMailboxDatabase cmdlet with the SkipLagChecks parameter, as shown in this example:
   
   

   	Copy Code
   Move-ActiveMailboxDatabase DB1 -ActivateOnServer EX3 -SkipLagChecks