This section describes error scenarios concerning the loss or corruption of the Resource Manager database or the Plans database. Each scenario provides both preventative and recovery details to help mitigate problems from each situation.

During a normal operations day, the Microsoft Provisioning System (MPS) begins to throw errors to the Microsoft Operations Manager (MOM) console that show that MPS can no longer access resource management data to provision new organizations and users. One or both of the Resource Manager database or the Plans database has been lost or has been corrupted.

The Resource Manager and Plans databases are key to the provisioning environment and must be reliably maintained, either by shadowing or regular, frequent backups depending on your provisioning transaction volume, using Microsoft SQL Server Backup.

To create a set of backups, you typically make a database backup at periodic intervals, such as daily, and transaction log backups at shorter intervals, such as every 10 minutes. You must have at least one database backup, or a covering set of file backups, to make log backups useful.

For critical components such as these databases, in particular when you are performing frequent provisioning operations, consider performing at least a differential backup on an hourly basis.

For the Resource Manager and Plans databases, we recommend the combination of regular full database backups, and regular transaction log backups so that you can perform a full recovery in the event of loss. Books on SQL Server provides detailed information on backup and restore procedures and using transaction logs to restore the database to a known good state.

Recovering the Plans and Resource Manager databases can be performed in one of two ways:

• Restore from recent backup: Microsoft SQL Server Backup procedures enable you to perform a simple recovery in which the database can be recovered to the point of the last backup. However, because you are dependent solely on the backup, you cannot restore the database to the point of failure or to a specific point in time. For this type of procedure, simply stop MPS once the database is lost or corrupted, and then restore it from a recent backup image.
  
• Point in time restore: Point in time restores are possible with the PlanManager and ResourceManager databases, but they must both be restored to the exact same point in time. In addition, the PWDB40 database must be restored to an earlier point in time than the PlanManger and ResourceManager databases. Follow the steps below for this type of procedure:
  
  1. Stop MPS to prevent additional provisioning requests from coming in.
     
  2. Configure the recovery software to recover the Resource Manager database from the online backup copy.
     
  3. Check through the recovered transaction logs and note the last transaction time stamp.
     
  4. Replay the transaction logs in the Provisioning Engine from that time stamp to the most current transaction.
     
  5. Issue some specified test transactions to ensure that organizations, users, and mailboxes can be provisioned.
     
  6. Bring the Provisioning Engine back online and edit the trouble ticket to start an investigation of the cause of the database corruption failure.
     
  Through this process, the messaging and collaboration services continue to function normally, although MPS is taken offline during the recovery time. Once the database is restored, you can restart MPS.