Before performing any restore procedures for these agents, review the following information.
z Common Considerations
z Exchange Database iDataAgents z Exchange Mailbox iDataAgents
z Exchange Public/Web Folder iDataAgents
Common Considerations
z The performance of this type of recovery operation may vary depending on the number of index cycles of archived data being recovered.
z This feature is only supported for no-image browse.
Removal of MAPI32.dll
If you previously added the MAPI32.dll file to the <Software Installation Path>/Base installation directory on the Client to support PST archiving or recoveries to PST, then you will need to remove that file prior to performing a non-PST restore, recover, or retrieve operation for Exchange. Otherwise, such jobs may go into a pending state.
Exchange Database iDataAgents
Backing up after a Restore
After performing a restore operation on the Exchange Database, a full backup is required before a scheduled pre-selected backup (incremental or differential) can successfully occur.
Dismounting Information Stores/Databases
z The Exchange 2000/2003 Database iDataAgents require you to dismount the information stores that you will be selecting for restore. If you are restoring the entire Exchange Server, dismount all stores.
The Dismount database during restore option is provided on the Restore Options (General) dialog to configure the system to dismount them automatically during the restore.
z The Exchange 2007 Database iDataAgent requires you to dismount the database(s) that you will be selecting for restore. However, the Exchange 2007 Database iDataAgent will not automatically dismount the database(s) during restore operations. Therefore, you must manually dismount the database(s) when performing restore operations using this iDataAgent.
Manual dismount/mount requirement for storage groups/stores that contain a "+" in their names If you are restoring storage groups/stores that contain a plus sign "+" in their names, then you will need to manually dismount those storage groups/stores prior to the restore, and then manually mount them after the restore has completed. The restore options to automatically Dismount Database During Restore and Mount database after restore do not apply in this scenario.
To automatically mount the Information Stores/Databases after the restore operation
z The Mount database after restore option is provided on the Restore Options (General) dialog to configure the system to mount the stores automatically after the restore has completed. Keep in mind that this option will be disabled if only KMS or SRS databases have been selected for restore. Also, this option does not apply when restoring data to Recovery Storage Groups (RSGs), or when restoring from VSS-enabled backups.
z The Exchange 2007 Database iDataAgent does not automatically mount the database(s) after restore operations. Therefore, you must manually mount the database(s) after performing restore operations using this iDataAgent.
Ensuring there is Enough Space in the Job Results Directory for Restoring Transaction Logs
During the restore process, transaction logs are temporarily placed in the Job Results directory, therefore you must ensure that the Job Results directory has enough free space to hold all the transaction logs for the restore job or the restore will fail.
Restoring data to Recovery Storage Groups (RSGs)
Do not mount mailbox stores in the RSG before the restore. Keep in mind that live production stores must not be dismounted at any time during this operation. Also, the restore option to Mount database after restore only applies to Exchange Server 2003 in this scenario.
Key Management Service (KMS) database
If you are restoring the Key Management Service (KMS) database, verify that the Key Management Server data directory is empty (typically \Program Files\Exchsrvr\KMSDATA), and make sure that the Microsoft Exchange Key Management Service is started.
After successfully restoring the KMS database, make sure that you stop and then re-start the Microsoft Exchange Key Management Service.
Site Replication Service (SRS) database
If you are restoring the Site Replication Service (SRS) database, verify that there are no *.edb, *.log or
*.chk files in the Exchsrvr\srsdata folder, and make sure that the Microsoft Exchange Site Replication Service is started.
After successfully restoring the SRS database, make sure that you stop and then re-start the Microsoft Exchange Site Replication Service.
Restoring from VSS-enabled Backups
The Exchange 2003/2007 Database iDataAgent on a Windows Server 2003 platform provides the capability of restoring data from a Volume Shadow Services (VSS) shadow copy backup. Consider the following before restoring data from VSS enabled backups:
z Before restoring Exchange 2003/2007 database data from a VSS shadow copy backup, it is required that you dismount all stores within the Storage Group you wish to restore, regardless of whether you’ve selected only one store or all stores in the Storage Group.
For example, if Storage Group SG1 has two stores in it, called DB1 and DB2, and the user has
browsed and selected only DB1 for restore, then the user should have dismounted both DB1 and DB2 before beginning this type of restore. After all stores within the Storage Group have been dismounted, follow the normal restore procedures.
z Point-in-time restores from VSS-enabled backups will only support entire Storage Group restores.
Prior to a point-in-time restore, all files in the database and log file directories must be manually deleted (i.e., *.chk and *.log).
z The Storage Group needs to be completely dismounted in order to perform the restore. This is different from traditional restores where you don't have to dismount the entire Storage Group to restore a single database. All databases must be dismounted before starting the restore from a VSS-enabled backup.
z For mixed-mode CommCells where the CommServe has the latest software release version and the client is at a prior release version, there is a requirement to manually dismount the stores prior to restoring from VSS in addition to the requirement to manually mount the stores after the restore.
z If the database is installed on the system drive, non-system databases will need to be manually brought back online after the restore.
z After restoring from a VSS-enabled backup, you must manually select a Full backup to be run from the Backup Options dialog because the system will not automatically convert a pre-selected incremental or differential backup to a full backup in this scenario.
z Out-of-Place restores from VSS-enabled backups for the Exchange 2007 Database iDataAgent allow the database stores to be restored to a different storage group (including Recovery Storage Groups) on the same Exchange Server, or to a different Exchange Server within the same Exchange
organization, or to a physically different location on disk (i.e., non-Exchange location) with a choice of whether or not to replay the logs. For step-by-step instructions, see Restore Out-of-Place or Cross-Application.
z Restores from VSS-enabled backups are supported only with storage groups containing English characters.
Restoring Database and Log Files Out-of-Place from Non-VSS Backups
The Exchange Database iDataAgent provides several advanced restore destination options for logs backed up without VSS enabled. These options are available when the Restore Destination (Only valid for non-VSS restores) option is checked in the Exchange Options tab of the Advanced Restore Options dialog box. These options include:
z Restore logs to separate location, which, when selected, restores the database in-place while restoring log files to a specified out-of-place location.
When restoring Exchange 2003/2007 Database data from a VSS-enabled backup, the restore options to Mount Database After Restore and No Loss Restore do not apply.
z Restore all the logs in cycle, which, when selected, restores only the log files backed up in the current cycle to a specified out-of-place location.
z Restore DBs and Logs in separate location, which, when selected, restores both the database and log files to a specified out-of-place location.
Exchange Mailbox iDataAgents Disabling Storage Limits
Before performing a mailbox, mailbox folder, or mailbox message restore, ensure that the storage limits are disabled. Otherwise the storage limit may prevent the entire list of items from being restored, even though the restore job may report success.
Follow the steps below to remove or disable any storage limit before performing a restore operation:
z From the Exchange Server software hierarchy view, under the Exchange Server computer, select Private Information Store.
z Select the Private Information Store Properties box.
z Remove or disable any storage limits.
Storage limits can be set from an individual mailbox, or to use the value taken from the Private Information Store Properties box. If any individual mailboxes have set storage limits, disable them as well.
Large Restores of Data
If you are trying to restore a large amount of data (for example, if the restore operation time exceeds the time allowed in the operation window for the client), we recommend that you either break up the restore into many smaller restores, or perform an Exchange Server Database restore.
Special Characters
The use of the characters "/", "\" and "
address may be rendered inconsistently when performing a restore browse operation. For example, a slash or backslash in the subject header may be displayed as a pipe character. Also, when the slash or backslash is used in the mailbox or display name, the entry may appear blank in the restore browse screen, and may not be a valid backup. We recommend avoiding the use of these characters in the mailbox name, display name and subject header, where possible.
Restore Failure Housekeeping
If a restore job fails in progress and there are entries in the restore list, there may be leftover items in the MailboxAdmin mailbox (which is associated with the MailboxAdmin profile that is required on the Exchange Server for this product). If so, open the MailboxAdmin mailbox and remove any mailboxes, folders, or messages left over. Be sure that there are no restores in progress or scheduled during this procedure.
Alias Name Browse/Search
z If you perform an incremental backup after an alias name change, and then perform an image browse of the data, then you will only see the latest alias displayed in the Browse window. If you perform a non-image browse, then all alias names will be displayed in the Browse window for the current index.
z For Exchange Mailbox-based agents, when performing searches on TO or FROM fields, alias name changes are not taken into account regardless of where the search is being conducted from.
Therefore, it is recommended that you take alias names into consideration when searching at the mailbox level and narrow the search only by SUBJECT, if necessary, leaving the TO and FROM fields empty.
Out-of-Place Restores to the Recovered Items Folder
z If you perform a Find and Recover operation from Outlook Add-In, messages will always be appended to the destination path \recovered items.
z If you perform a restore/recovery/retrieve operation using the CommCell Console and the restore/recovery/retrieve destination path is \recovered items, then the Overwrite and Skip restore options will be ignored. Instead, the messages will be appended.
Exchange Public/Web Folder iDataAgents
There are no special pre-restore considerations for these agents.