Provisioning Engines

Microsoft Provisioning Framework (MPF) has provisioning engine servers that act as transaction coordinators, routing real-time provisioning requests to called providers. The engine provides a framework for integrating multiple actions into a single transaction. The engine maintains contextual information and transaction state. After a failure, it also issues rollback calls and manages rollback data for actions subject to rollback.

The provisioning engine supports the following transaction models:

Compensating transactions for providers that perform updates subject to rollback. After a failure, the provisioning engine initiates rollback using contextual information the provider receives from the request.
Transactions for providers that use Microsoft® Distributed Transaction Coordinator (DTC). Currently, the only standard provider that is DTC-compliant is the SQL Provider.
External (non-MPF) transactions, for servers that use Transaction Internet Protocol (TIP). Whenever a provisioning engine receives a TIP request, it automatically enlists the transaction in MPF and generates a tipUrl attribute to link the transaction back to the remote server. A remote server can also enlist into an MPF transaction by having a provider fetch the TIP URL (via the property bag of the IProvHelper interface).

MPF setup installs Provisioning Engine in Windows Component Services, COM+ Applications. An MPF installation can have one or more engine servers.

Requests enter provisioning engines via a client. The interfaces IProvEngine::SubmitRequest and IProvEngine::SubmitTrustedRequest pass requests directly to the engine. The IProvQueue::SubmitRequest and IProvQueue::SubmitTrustedRequest interfaces pass queued requests to a queue manager, which submits them to a provisioning engine when it is time to process them.

Each request is a set of calls to one or more procedures defined as part of a in the configuration database. As the engine executes a procedure call, it acts on the incoming data by executing the XSL transformations and conditional operations defined in the procedure. For more information, see Provisioning Schema. The engine sends the current state of executing transactions to transaction logs in order to roll back the transactions after a failure.

The behavior of provisioning engines is configurable as follows.

Using Provisioning Manager, set properties in Microsoft Provisioning, Provisioning Servers, Provisioning Engines.
Using , call MSFT_MPFSite.maps_SetSiteProperty. For more information, see the page for class .

Property	Description
Requests Security	This property controls which users and groups can submit requests to provisioning engines and the type of requests they can submit. Options for submitting requests include the following. A caller can have multiple access permissions. Execute Procedures: Callers with this permission can submit simple requests using IProvEngine::SubmitRequest. Execute with Caller's Credentials: Callers with this permission can pass a security context in the request. Execute Trusted Procedures: Callers with this permission can submit trusted requests using IProvEngine::SubmitTrustedRequest. By default, only users in the Administrator, MPFAdmins, and MPFTrustedUsers groups are allowed to execute trusted procedures. Callers with this permission automatically receive the Execute with Caller's Credentials permission. Execute Private Procedures: Callers with this permission can access namespace procedures marked as private in the configuration database. MPF has two types of procedures: public and private. A public procedure can be invoked from outside of MPF (for example, when a user submits requests from a Web application). A private procedure can only be executed by MPF procedures or authorized callers and not directly by the request. In general, callers should not call private procedures directly; rather, they should call public procedures that call private procedures. If this is disabled, the caller can only access public procedures. To access private procedures, the caller can use either a submit or submit trusted method.
Audit Level	Flag that marks a procedure for auditing. During transaction processing, provisioning engines initially move all transactions to a transaction log. Periodically, an auditing and recovery manager will clear the log and moves transactions for audited procedures to the . You have the following options for saving data to the audit log. Note that you can select more than one option. However, be aware that one setting can override another. For example, if you set both Transactions with errors and All transactions, the latter would prevail. Data stored for procedures includes the transaction identifier, step number, namespace, and procedure name. Data stored for errors includes the transaction identifier, source, error code, and event description. The transaction settings determine which kinds of transactions to audit. Transactions with errors: Save to audit all transaction with errors. This option is checked by default. Transaction marked for audit: Save to audit all transactions containing one or more procedures marked for audit. This option is checked by default. Aborted transactions: Save to audit all aborted transactions. This option is checked by default. Transactions in doubt: Save to audit all transactions in doubt. This option is checked by default. Successful transactions: Save to audit all successful transactions. All transactions: Save to audit all transactions. The remaining settings determine what kinds of data to pass to the audit log for the transactions marked for audit. Errors: Save to audit all errors. This option is checked by default. Audit data: Save to audit the audit data. This option is checked by default. All transaction data: Save to audit all transaction data. This option is checked by default. Procedures marked for audit: Save to audit all MPF procedures marked for "Save to audit." This option is checked by default. Aborted procedures: Save to audit all aborted MPF procedures. This option is checked by default. Procedures in doubt: Save to audit all MPF procedures in doubt. This option is checked by default. Successful procedures: Save to audit all successful MPF procedures. Failed procedures: Save to audit all failed MPF procedures. This option is checked by default. All procedures: Save to audit all MPF procedures.
Enable Schema Validation	Specifies whether to validate XML data passed to procedures in client requests against the input/output schema in the corresponding procedure definitions. If validation fails, MPF returns an error to the caller. Important Enable schema validation only when testing new functionality. If you enable schema validation in a production environment, you might experience significant performance problems.
Transaction Log Pool Size	Specifies the maximum number of connections that can be established to one transaction log database. The default setting is 100 simultaneous connections.
Tran Log Timeout	Time to wait (seconds) before a provisioning engine places a malfunctioning connection to a transaction log server on a bad server list. The default setting is 300 seconds. Provisioning engines save the state of requests in progress to a transaction log server. If the network connection or the server fails while transactions are in process, MPF continues executing against the server until the transaction log timeout is reached. If the server does not come back online, MPF executes rollback and routes the transaction to the next available transaction log server (if any).