The audit log for Microsoft® Provisioning Framework (MPF) contains a user-defined subset of data that is stored for data mining, error checking, and other reporting and analysis purposes. For example, data on failed transactions, failed procedures, and execution times is often used for performance analysis.

MPF setup installs the audit log. An MPF installation can have only one audit log database.

The audit log receives transaction data from transaction logs via the auditing and recovery manager service. Since the number of transactions in a data center can become very large, logging all information about every transaction, procedure, and error would require excessively large databases. Using Provisioning Manager, you can reduce the size of the databases by specifying which information to save to the audit log, limiting it to only the required information. The Audit Level property in Provisioning Servers, Provisioning Engines determines which transactions are saved to the audit log and what kinds of data to pass for these transactions. For more information, see Provisioning Engines.

Depending on the reporting purpose, it may be necessary to modify the audit log database. To add rows of data to the database or execute custom stored procedures, use Custom Audit::Audit.

MPS has a number of built in audit and debug logging mechanisms. The following table list some log examples.

Log Name	Description
MPF Transaction logs	Short lived logs, contain transaction specific information necessary for execution and rollback purpose
MPF Audit logs	Historical data pertaining to all completed(successful or failed) transactions
ComTracer logs	Logs saved through either the MPF Profiler or TraceView
Event logs	Many MPF Components including providers will write events to the Event logs
Web Services logging	MPS Web Service logging saves out the XML input (request) as well as the XML output (response) for each Web Service Request. It is turned off by default. For more information,see Web Service Debug logging.

While the logs and data stores can be invaluable in troubleshooting issues or identifying trends, it is important to understand that there may be sensitive data stored in these logs including, Customers PII (Personally Indentifiable Information), Security Credentials, internal infrastructure details, billing related information

While some of the mechanisms above offer some protection from exposing things like credentials -- for example, MPF will strip passwords from transaction data as it is being written to the MPF Audit logs and Web Service Debugging strip off passwords as requests and responses are being written to log files, it is imperitive that these logs be protected. At a minimum, the following processes should be put in place to protect this data:

• Logs should be stored only on trusted and physically secured servers
• Backups should protected under tight security and only shipped to secure locations
• Debug tracing including ComTrace and Web Service logging should only be enabled when it is absolutely necessary.
  • Debug logs should be destroyed when they are no longer needed
  • Debug logs should only be made available to support personel who need access to them.
• Audit logs should be purged on a regular (6 - 12 month) basis depending on auditing requirements.
• Event logs should be purged on a regular basis depening on operations requirements.