Provisioning Auditing and Recovery Service

Microsoft® Provisioning Framework (MPF) uses Provisioning Auditing and Recovery Service to:

MPF setup installs Provisioning Auditing and Recovery Service in Windows Component Services, Services. An MPF installation can have one or more auditing and recovery servers.

For failure management, the service detects crashes in provisioning engines and alerts the remaining engines whenever an engine fails. Rollback is actually executed by an engine, however, not by the auditing and recovery service.

For transaction processing, the service periodically cleans up transaction logs. For permanent storage, you can set MPF to move selected transactions to the audit log for data warehousing. It is important to determine an optimal frequency for moving transactions. Move them often enough to prevent transactions from flooding the log, but not so often that server processing times slow to a crawl.

When moving transactions to the audit log, the service also executes any SQL commands that the Custom Audit::Audit procedure has added to the transaction log. If a command fails, other commands still need to move to the transaction log. Initially, the auditing and recovery service moves bad commands to the BadAuditCommands table and generates an error event to alert administrators. It periodically re-attempts command execution until:

For queue management, the service periodically clears queues, storing the final status of each queued request in the transaction log. You can specify how long to maintain records in this table and how much time to spend deleting each chunk.

The behavior of auditing and recovery managers is configurable as follows. The following properties apply to all servers in an MPF installation.

Property Description
Bad Commands Delay Maximum delay between retries of failed SQL commands inserted into the transaction log by Custom Audit::Audit. The default value is 60 minutes. The audit and recovery service continues retrying the command for the duration specified by Bad Commands Keep Time.
Bad Commands Keep Time Maximum keep time for failed SQL commands inserted into the transaction log by Custom Audit::Audit. The default value is one day.

Specify enough time for people to respond to problems. The audit and recovery service automatically deletes the command from the transaction log once the keep time elapses.

Max Move to Audit Delay Maximum delay between two auditable procedures. The default value is 15 minutes.

The audit and recovery service moves transactions to the audit log in chunks. Max Move to Audit Delay is the maximum allowable time that can elapse between moves. Indirectly, this value determines how long transactions can remain in the transaction log.

Max Move to Audit Duration Maximum duration of one auditable procedure step. The default value is 30 seconds.

Each transaction corresponds to a row in a database table. As the audit and recovery service moves transactions to the audit log, it moves as many rows as it can in the amount of time specified in Max Move to Audit Duration.

Moves consume significant system resources. To minimize server slowdowns and transaction flooding, specify a short duration to move only a few transactions at a time.

Queue Cleanup Duration Maximum duration of one queue cleanup step. The default value is 15 seconds.

Each transaction corresponds to a row in a database table. As the auditing and recovery service moves transactions to the Audit Log, it moves as many rows as it can in the amount of time specified in Queue Cleanup Duration.

Moves consume significant system resources. To minimize server slowdowns and transaction flooding, specify a short duration to move only a few transactions at a time.

Queue Status Keep Time Maximum keep time for queue status records. The default value is 24 hours. Once this period elapses, the auditing and recovery service automatically clears the transaction log.

To start or stop operations for an audit and recovery manager, use Provisioning Manager.

See Also

Architecture