Namespaces consist of a set of procedures that define the business logic for executing provisioning actions. Microsoft Provisioning System (MPS) provides several Managed (predefined) namespaces that contain the procedures to carry out common provisioning tasks. However, you can also create new namespaces that contain unique procedures for your provisioning environment.

Rather than writing long provisioning procedures that are difficult to manage, you can create smaller procedures that encapsulate the functionality of common provisioning actions. You can then create custom namespaces that call specific combinations of these procedures to perform designated provisioning tasks. By approaching the organization of your provisioning tasks in this manner, you can encapsulate business logic into reusable modules that can be applied to a diverse range of provisioning tasks, which you define in your custom namespaces. This approach also simplifies procedure debugging and maintenance.

For example, suppose you have a procedure that contains a list of actions that are defined in a hypothetical namespace named ServiceUser. In this example, the procedure is named CreateUser, it is configured as a Public procedure, and it has the logic that causes it to perform the following actions:

• Creates a user account.
  
• Sets the user password.
  
• Adds the user to a group.
  
• Creates a folder.
  
• Sets folder security.
  
• Shares the folder.
  

This is one way to organize provisioning actions within a procedure; however, it is not the best way. Rather than perform all these actions in a single procedure, you can break them up into modular Private procedures that are nested within the CreateUser procedure and called by the ServiceUser custom namespace, as shown in the following figure.

Figure: Creating reusable provisioning actions

After you use these Private procedures within some custom namespace that you create, you can also utilize their preconfigured functionalities wherever else you need them. You can do this by nesting them within any new procedure that you create within a namespace, in any combination that facilitates a particular provisioning task that you want to implement. In this respect, you can use Private procedures similar to the way you might employ reusable code in other programming environments. The only limitation is that any procedure that is marked as Private can only be called by a Public procedure.

When you deploy a procedure, you should set the access type to Private if Public access is not required. By default, the namespace file sets the access type to Public, which is sufficient for testing. However, in a production environment, this configuration does not provide appropriate security.

See the MPS Operations Guide "What a Procedure Is" topic for information about public and private procedures. You can locate the MPS Operations Guide on at: \Service Provisioning\MPS\MPF\help\opsguide.chm.

The following is an example of an instance when you might extend a managed namespace. You might want to use the functionality of the Managed Active Directory namespace (or another managed namespace), but you need additional functionality to accommodate the environment you want to implement. Rather than changing a managed namespace, which can result in an unsupported configuration, you can extend the functionality of an MPS managed namespace by doing the following:

• Create a custom namespace that performs your required tasks.
  
• Create a procedure within the custom namespace that calls Managed Active Directory to employ its functionality where needed.
  

The following is an example of an instance when you might create a custom namespace.

You might have an existing Active Directory design that is in production and working well for operators, but it is different from the directory structure that the MPS Managed Active Directory Namespace implements. In this situation, you can write a custom namespace that interacts with your current Active Directory structure through the MPS Active Directory Provider. This custom namespace will then replace the Managed Active Directory Namespace.

See the MPS Operations Guide "Active Directory Hosting Configuration" and "Implemented Active Directory Structure" topics for information about how the Active Directory hosting structure is implemented by MPS within the Active Directory domain. You can locate the MPS Operations Guide on the Microsoft Hosting Solutions for Service Providers site at: \Service Provisioning\MPS\MPF\help\opsguide.chm.

The MPF Profiler is provided as a development tool to assist you in the process of implementing new namespaces that you create. This application, which is a part of MPS, is targeted towards developers who are creating solutions on top of MPS.

The Profiler enables you to monitor data flow in and out of namespaces, named procedures, and named procedure constructs. The Profiler is built on top of a client-server architecture. You can install the Profiler client application on the same server as the Provisioning Engine or any other machine that is in the same domain. By using filters on both the server and client, you can easily narrow down the volume of Profiler debugging information to that which is of most interest to you.

The Profiler exists in the following location on the Microsoft Hosting Solutions for Service Providers site:

\Service Provisioning\MPS\MPF\mpfreskit\Profiler