Troubleshooting - Exchange Database Agent

Restore Failures

Symptom Resolution
Transaction Log restore fails Transaction log files are temporarily stored in the Job Results directory during a restore. Before performing a restore of these files, ensure that the Job Results directory has enough free space to hold all the transaction logs or the restore will fail.
In-Place Database restore fails Ensure the database is marked for overwrite on the Exchange Server prior to performing the restore.
No Loss restore fails The sequence of transaction logs may be broken or have become corrupted. Ensure that the transaction log sequence is in tact prior to performing the restore.
Database mounting fails after a restore The database might contain a "+" character in the name. To resolve this issue:
  1. Manually dismount the original database.
  2. Perform the restore.
  3. Once the restore is completed, manually mount the database.

Completed with one or more errors

Restore jobs from Exchange Database iDataAgent will be displayed as "Completed w/ one or more errors" in the Job History in the following cases:

  • During restore, if few databases or storage groups cannot be restored since no data was found to restore from.
  • During restore, if at least one of the databases were not restored successfully though the rest were successfully restored.

Local continuous replication continues to occur during a restore

Suspend the Storage Group copy so that replication does not attempt to take place during the restore.

Old files appear in the passive copy after restore

After the restore has completed, you must manually resume the Storage Group copy, which will delete the old files in the passive copy and then reseed it before resuming replication.

For more information on performing this task, refer to the Microsoft TechNet article on "Local Continuous Replication".

Unable to restore data from decommissioned clients on Exchange Server 2003

Refer to the Knowledge Base article EXDB0002: Restoring Exchange 2003 Database Backup as a File.

EXDB0003: Error Code 28:163: Database not found

A non-VSS-enabled (Volume Shadow Copy Service) Exchange database restore fails with the following error:

Error Code 28:163 The Exchange server returned the following error message: [0xc7fe1f42] - [Database not found. ]. Api: [HrESERestoreAddDatabase()], Item: [MBDB]

The error can occur under the following conditions:

  • A Recovery Storage Group (RSG) or a Recovery Database (RDB) was created for another database.
  • The original database was deleted.

Review the extidbrestore.log on the Exchange server where the database is restored. If either of the conditions were met, the following error appears in the log:

6112 166c 03/20 14:08:05 5609 [::DoRestoreWithSharedLogs]: Error in HrESERestoreAddDatabase() (-939647166/0xc7fe1f42). Database not found.

Symptom 1

Applies to: Exchange 2003 and 2007

When you restore a non-VSS-enabled backup, SnapProtect tries to restore to an RSG automatically if it exists.

Resolution 1

  1. Do either of the following:
    • To restore the database to an RSG, make sure that the RSG is associated with the correct database.
    • To restore the database to the production server, delete the RSG.

Symptom 2

Applies to: Exchange 2003, 2007, and 2010

The restore job fails with the error even though all of the data was restored and the transaction logs were replayed. This occurs because the GUID of the original database and the restored database do not match.

Even though the job failed, you can still mount the restored database and use the data.

Resolution 2

If you delete the original database, and then create a new one, the name of the new database and the name of the RSG (Exchange 2007 and earlier) or the RDB (Exchange 2010) must match the name of the original database exactly.

To avoid this error, make sure the names match.

To bring business operations online immediately, you can create a dial tone database. Use the dial tone database to restore basic email services until the RSG or RDB is restored. After the restore is complete, replace the dial tone database with the restored database. To complete the process, merge the data from the dial tone database with the restored (production) database to bring it up to date. For more information, see:

Exchange 2003: "Recovering a Mailbox Database Using a Dial Tone Database in Exchange Server 2003": https://technet.microsoft.com/en-us/library/aa998947(v=exchg.65).aspx

Exchange 2007: "Dial Tone Recovery": https://technet.microsoft.com/en-us/library/bb310765(v=exchg.80).aspx

Exchange 2010: "Dial Tone Portability": https://technet.microsoft.com/en-us/library/dd876950(v=exchg.141).aspx

Symptom 3

Applies to: Exchange 2003, 2007, and 2010

The restore job fails if the Exchange server to which the data is restored is not the same Exchange server that is used to back up the data.

Resolution 3

The Exchange server name that you entered during the installation of the Exchange Database Agent must be the correct NetBIOS name of the Exchange server is assigned the Mailbox server role.

Validate that the Exchange Server Name is correct.

  1. From the CommCell browser, expand Client Computers > client.
  2. Right-click Exchange Database, and then click Properties.

    The Exchange Database Properties dialog box appears.

  3. On the General tab, make sure that the value in the Exchange Server Name box is the correct NetBIOS name of the Exchange server that is assigned the Mailbox server role.
  4. Click OK.

EXDB0004: Error code 27:118: Error initializing XML files

A VSS-enabled (Volume Shadow Copy Service) Exchange database restore fails with the following error:

Error Code 27:118 Error initializing XML files

The error can occur again under the following conditions:

  • A Recovery Storage Group (RSG) or a Recovery Database (RDB) was created for another database.
  • The original database was deleted.

Review the Applications Event Log on the Windows Server. If either of the conditions were met, the following error appears in the log:

Exchange VSS Writer cannot restore a backup to the storage group 'RestoreDelete' because the database specified for restore ('MBDB.edb' in 'S:\deletetest\mbdb') does not match any of the databases in the target storage group.

The original GUID for the database is 'd22b656b-2564-4684-ba98-524d678b9128', but the target GUID specified in the Restore Options string is 'd22b656b-2564-4684-ba98-524d678b9128', which does not exist in the Active Directory.

Symptom 1

Applies to: Exchange 2007 and 2010

After the original database was deleted, and then recreated, the restore fails.

Resolution 1

In this case, you cannot perform and in-place restore. You must perform an out-of-place restore with the recovery option.

  1. From the CommCell Console, expand Client Computers > client.
  2. Right-click Exchange Database, and then click All Tasks > Browse and Restore.

    The Browse and Restore Options dialog box appears.

  3. Click View Content.
  4. In the left pane of the Client Browse window, expand Exchange Database > Microsoft Information Store > Storage Group/Database.
  5. In the right pane, select the database that you want to restore, and then click Recover All Selected.

    The Restore Options for All Selected Items dialog box appears.

  6. From the Destination client, select the appropriate client.
  7. In the Restore Options area, select Restore to another database.
  8. In the list at the bottom of the dialog box, select the Source DB.
  9. In the Destination DB/Out of Place Location column, click ...

    The Choose Database dialog box appears.

  10. Select a database, and then click OK.
  11. Click OK to close the Restore Options for All Selected Items dialog box.
  12. After the restore is completed, copy the restored .edb file, and then paste it in the correct Exchange database location.
  13. Manually mount the stores.

Symptom 2

Applies to: Exchange 2003, 2007, and 2010

The restore job fails with the error even though all of the data was restored and the transaction logs were replayed. This occurs because the GUID of the original database and the restored database do not match.

Even though the job failed, you can still mount the restored database and use the data.

Resolution 2

If you delete the original database, and then create a new one, the name of the new database and the name of the Recovery Storage Group (Exchange 2007 and earlier) or the Recovery Database (Exchange 2010 or later) must match the name of the original database exactly.

To avoid this error, make sure the names match.

To bring business operations online immediately, you can create a dial tone database. Use the dial tone database to restore basic email services until the RSG or RDB is restored. After the restore is complete, replace the dial tone database with the restored database. To complete the process, merge the data from the dial tone database with the restored (production) database to bring it up to date. For more information, see:

Exchange 2003: "Recovering a Mailbox Database Using a Dial Tone Database in Exchange Server 2003": https://technet.microsoft.com/en-us/library/aa998947(v=exchg.65).aspx

Exchange 2007: "Dial Tone Recovery": https://technet.microsoft.com/en-us/library/bb310765(v=exchg.80).aspx

Exchange 2010: "Dial Tone Portability": https://technet.microsoft.com/en-us/library/dd876950(v=exchg.141).aspx

Symptom 3

Applies to: Exchange 2003, 2007, and 2010

The restore job fails if the Exchange server to which the data is restored is not the same Exchange server that is used to back up the data.

Resolution 3

The Exchange server name that you entered during the installation of the Exchange Database Agent must be the correct NetBIOS name of the Exchange server is assigned the Mailbox server role.

Validate that the Exchange Server Name is correct.

  1. From the CommCell browser, expand Client Computers > client.
  2. Right-click Exchange Database, and then click Properties.

    The Exchange Database Properties dialog box appears.

  3. On the General tab, make sure that the value in the Exchange Server Name box is the correct NetBIOS name of the Exchange server that is assigned the Mailbox server role.
  4. Click OK.

Recovering data associated with deleted clients and storage policies

Symptom

In a disaster recovery scenario, use the following procedure to recover data associated with the following entities:

  • Deleted storage policy
  • Deleted client, agent, backup set or instance

Before You Begin

This procedure can be performed when the following are available:

  • You have a Disaster Recovery Backup that contains information on the entity that you are trying to restore. For example, if you wish to recover a storage policy (and the data associated with the storage policy) that was accidentally deleted, you must have a copy of the disaster recovery backup that was performed before deleting the storage policy.
  • Media containing the data you wish to recover is available and not overwritten.
  • If a CommCell Migration license was available in the CommServe when the disaster recovery backup was performed, no additional licenses are required. If not, obtain the following licenses:
    • IP Address Change license
    • CommCell Migration license

    See License Administration for more details.

  • A standby computer, which is used temporarily to build a CommServe.
Recovering Deleted Data
  1. Locate the latest Disaster Recovery Backup that contains the information on the entity (storage policy, client, agent, backup set or instance) you are trying to restore.
    • Check the Phase 1 destination for the DR Set or use Restore by Jobs for CommServe DR Data to restore the data.
    • If the job was pruned and you know the media containing the Disaster Recovery Backup, you can move the media in the Overwrite Protect Media Pool. See Accessing Aged Data for more information. You can then restore the appropriate DR Set associated with the job as described in Restore by Jobs for CommServe DR Data.
    • If the job is pruned and you do not know the media containing the Disaster Recovery Backup, you can do one of the following:
      • If you regularly run and have copies of the Data on Media and Aging Forecast report, you can check them to see if the appropriate media is available.
      • If you do not have an appropriate report, and know the media that contains the DR Backup, catalog the media using Media Explorer. Once the cataloging process is completed, details of the data available in the media are displayed.
  2. On a standby computer, install the CommServe software. For more information on installing the CommServe, see Install the CommServe.
  3. Restore the CommServe database using the CommServe Disaster Recovery Tool from the Disaster Recovery Backup described in Step 1. (See CommServe Disaster Recovery Tool for step-by-step instructions.)
  4. Verify and ensure that the NetApp Client Event Manager NetApp Communications Service (EvMgrS) is running.
  5. If you did not have a CommCell Migration license available in the CommServe when the disaster recovery backup was performed, apply the IP Address Change license and the CommCell Migration license on the standby CommServe. See Activate Licenses for step-by-step instructions.
  6. Export the data associated with the affected clients from the standby CommServe as described in Export Data from the Source CommCell.

    When you start the Command Line Interface to capture data, use the name of the standby CommServe in the -commcell argument.

  7. Import the exported data to the main CommServe as described in Import Data on the Destination CommCell.

    This brings back the entity in the CommServe database and the entity is visible in the CommCell Browser. (Press F5 to refresh the CommCell Browser if the entity is not displayed after a successful merge.)

  8. You can now browse and restore the data from the appropriate entity.

    As a precaution, mark media (tape media) associated with the source CommCell as READ ONLY before performing a data recovery operation in the destination CommCell.