Before you decide to create a new provider, you should first understand the role of providers. Providers are the source of all the functionality required to support specific provisioning services within Microsoft Provisioning System (MPS). Providers perform low-level tasks that are initiated by requests passed into MPS. Providers are implemented as .dll files, each with a corresponding provider namespace registered in the Configuration database. Providers supply the programmatic procedures that are required to interact with the management interface of applications such as Microsoft Exchange Server 2007, Internet Information Services (IIS), Active Directory, Microsoft SQL Server, and Microsoft Windows SharePoint Services. Providers employ these procedures to provision resources and specific sets of services.

For example, if you are implementing hosted Windows SharePoint Services provisioning, you can make calls to the Windows SharePoint Services provider to provision SharePoint sites for customers and manipulate site properties, users, and groups.

You can determine if you need to create one or more new providers by assessing your provisioning functionality. You can create a new provider to either completely replace a provisioning process or a part of it. Before you commit to creating a new provider, you should ensure that you cannot duplicate the same functionality with an existing MPS provider by reviewing Providers.

If none of the MPS providers have the provisioning functionality you need, you can create one or more new providers by using components of the Microsoft Provisioning System SDK. This means you can still take advantage of the transactional, compensational, and auditing capabilities of MPS within your environment, even though you are not using providers shipped with MPS. With the MPS software development kit (SDK), you can develop new providers in C# .NET by deriving provider functionality from the MPS Provider .NET Base Class.

For example, you might create a provider to implement a process that prevents the update of a billing system if a credit card was not approved. You might also create a provider that signs up a new user and updates a call center database that tracks customers.

If you create a custom provider that communicates with Active Directory, be sure to use the <preferred DC> tag. Using this tag ensures that the provider methods will always default to Active Directory on the correct domain controller. This might be necessary if you have multiple method calls that depend on locating a newly created user account.

For example, if you have a procedure that performs a serverless bind to create a user account in Active Directory, the call will target the logon server containing Active Directory. You might also have another procedure that calls into a different application such as Exchange, yet the procedure must have access to the new user account. If this procedure also performs a serverless bind, the call might target Active Directory on a different logon server. Without using the <preferred DC> tag, the second call will be unable to locate the user account and your provisioning tasks will fail.