The objective of FIM is to process requests that can be initiated by various FIM clients such as the FIM synchronization service and the self-service components according to your configured business policies.
If you have only one FIM service instance deployed to handle the all requests, it is possible that you experience processing latencies. Some operations
can even exceed the default timeout values that are appropriate for self-service operations.
FIM service partitions can help you to address this issue.
Regardless of whether you have only one or multiple FIM service instances deployed, your current FIM service partition configuration has an impact on how requests and associated workflows are processed in your environment.
The objective of this article is to explain, what FIM service partitions are, what you need to know about architectural components of a FIM service partition and how you can leverage and configure this feature to address latency related issues when processing requests in your environment.
When you configure a FIM service instance, you must provide a FIM Service Server address.
The following screenshot shows an example for this:
The FIM Service Server address is used by the FIM Portal and other clients to contact a FIM service instance.
In the FIM terminology, the FIM Service Server address is also known as external host name attribute.
Each FIM service instance belongs to a logical group that consists of one or more FIM service instances, which is also known as FIM service partition.
The default value for this attribute is the value of the external host name attribute.
Requests are associated with a specific service partition and must be completed using FIM service instances that are associated with the same service partition.
You can find the service partition name a request is associated with under the Extended Attributes of a request’s Advanced View.
The following screenshot shows an example for this:
Processing a request can result in the execution of one or more related workflows.
Each FIM service instance that belongs to that service partition can process the request or execute associated workflows; however an individual workflow instance can only run within one FIM service instance at a time.
This design keeps other FIM service instances from trying to load an already executing workflow program.
The record of the workflow in the FIM service database is locked using the name of the FIM service instance.
The name of a FIM service instance is also known as service name.
The default value of the service name attribute is the name of the computer that hosts a FIM service instance.
The following table provides a summary of the architectural components that are related to a FIM service partition:
| Attribute Name | Default Value | Description |
|---|---|---|
| external host name | The FIM Service Server address provided during the configuration of a FIM service instance. | The address FIM Portal and other clients should use to contact the FIM Service. |
| service partition name | external host name | Identifier for a service partition. |
| service name | The name of the computer that hosts the FIM service instance. | Unique identifier for the FIM service instance. |
Because it is a common practice for stand-alone Server address provided during the configuration of a FIM service instance.
The FIM service partition related configuration settings are stored as attributes of the resourceManagementService tag in the
Microsoft.ResourceManagement.Service.exe configuration file.
This file is located in the following folder:
%ProgramFiles%\Microsoft Forefront Identity Manager\2010\Service
The following shows an example for a related setting:
<resourceManagementService
externalHostName="FIMServer01"
/>
If you want to overwrite the default values of the servicePartitionName or the serviceName, you need to manually add these attributes including the new values to your configuration file. The following shows an example for this:
<resourceManagementService externalHostName="FIMServer01" servicePartitionName="MyFIMPartition" serviceName="MyFIMService"/>
Note |
|---|
| When you have updated your configuration file, you need to restart your FIM service instance to activate the most recent configuration settings. |
The parameters of a FIM service partition are relevant in the context of a processing sequence that consists of a request and the related workflows.
The servicePartitionName is stored with the request object and the workflow instances are stamped with the serviceName of the FIM service instance that is processing them.
In FIM, already queued workflow instances can only be completed by a FIM service instance that has the same values for servicePartitionName and serviceName attributes as the originating instance.
If a FIM service instance that has already added workflows to the related processing queues goes down, the workflow instances are locked in the FIM service database.
To unlock these workflow instances, you need to replace the faulty FIM service instance with a new instance that has the same values for the service partition name and service name attributes configured as the faulty instance.
In other words, when you have to replace a faulty FIM service instance, you might be required to overwrite the default values of the servicePartitionName and the serviceName attribute in the configuration file of the new FIM service instance if you have locked
workflow instances in the FIM service database.
In FIM, all actions within the system result in request objects.
Requests can be initiated by various sources such as self-service users, administrators that are managing the FIM environment or the synchronization service that is exchanging identity data with the FIM service.
The following diagram shows a logical example for this:
In the context of the request and workflow processing model, it is important to keep in mind that some activities can result in a large amount of requests and associated workflows.
This is especially true for administrative tasks such as the identity data exchange between the FIM synchronization service and the FIM service or activities that are triggering the run on policy update feature.
When the FIM service is busy processing already queued requests, a new request that is generated in response to the attempt of user to create a distribution group can take an unacceptable amount of time to be completed or the request can even time out while
waiting for a response.
One option you have to address this issue is to increase the timeout values.
|
Note |
|---|
| For more details about the timeout related attributes and how to configure them, see Troubleshooting FIM 2010. |
The FIM architecture supports having multiple FIM service instances that are connected to the same FIM database.
The following diagram shows an example for this:
Because administrative tasks have the potential to generate a large amount of requests that may take a long time to complete, just distributing the incoming requests amongst several FIM service instances does not necessarily help to improve the experienced performance of a user that tries to create a distribution group.
|
Note |
|---|
| As a best practice recommendation, you should keep the number of your deployed FIM service instances at a required minimum. |
In addition to deploying multiple FIM service instances and connecting them to a single instance of a FIM service database, you can also group one or more of these FIM service instances into workload based FIM service partitions.
The following diagram shows an example for this:
The FIM service instances that are grouped based on a workload share the processing of requests and workflow in an environment.
A workload based FIM service partition is a group of one or more FIM service instances that are sharing the same servicePartitionName.
If you have workload based service partitions deployed, the request initiators can use the partition name to access your FIM service because each member has the same authority to process requests for the configured workload.
deploying multiple FIM service instances and connecting them to a single instance of a FIM service database, you can also group one or more of these FIM service instances into workload based FIM service partitions.
The following diagram shows an example for this:
T
One common scenario for deploying workload based service partition is to isolate self-service and administrative request workflows, to improve the experienced response time of a self-service related task such as the creation of a new distribution group.
The following diagram shows an example for this:
In FIM, each request must be completed and approved in the context of the FIM service instance that was used to initiate it.
This is important to know when you have to troubleshoot request and workflow related issues.
Because all FIM service instances are sharing the same database, you can find all requests on each FIM service instance of a FIM service partition cluster.
However, if necessary, to take action on a request, you need a FIM service instance that belongs to the same workload service partition that was used to initiate a request.
The reason of this behavior is the fact that service partitioning is designed to support the isolation of request based workloads.
The objective of deploying FIM service partitions is to improve the experienced response time for request workloads in your environment.
Depending on the workload type, it might be sufficient to have only one FIM service instance in a FIM service partition configured.
If you experience timeout related issues, you can adjust the timeout values.
This is, for example, a good method to handle timeout issues in the case of an administrative service partition.
However, for self-service based service partitions, increasing the timeout values, doesn’t improve the experienced response time.
If the response time for such a service partition is not acceptable, you can add additional FIM service instances to a partition and connect them by using Network Load Balancing (NLB). The following diagram shows an example for this:
To isolate request based workloads in your environment, you can deploy several FIM service instances that are connected to a single FIM service database and group them into service partitions.
A client component connects to a service partition by specifying the related partition name.
The main objective of deploying service partitions is to improve the experienced performance of users performing self-service related tasks.
Note |
|---|
| To provide feedback about this article, create a post on the FIM TechNet Forum or respond to this post. |
