Troubleshooting FIM 2010
Use this Troubleshooting Guide to help diagnose and resolve common issues encountered in your Microsoft® Forefront® Identity Manager (FIM) 2010 environment.
FIM Service
The FIM Service makes diagnostic information available in four primary ways:
Simple Object Access Protocol (SOAP) faults
- SOAP faults include diagnostic information that appears in the diagnostic log for the FIM management agent (MA). This information is not included by default for normal FIM Portal requests, and the FIM Portal user interface (UI) is not presently capable of displaying it.
Requests
Request resources record the outcome of all operations in the FIM Service.
For more information, see the Workflow activities section.
FIM diagnostic log
The FIM log is an application-specific log found in the Event Viewer under Applications and Services Logs.
The diagnostic log contains all Microsoft .NET exceptions from the FIM Service.
Note
Many exceptions are expected and are desirable behavior.
This log should be used only to diagnose specific errors and not to monitor the health of the service.
Events are logged in the diagnostic log from both the FIM Service in Microsoft.ResourceManagement.Service.exe.config (FIM Service installation directory) and the FIM Portal in the web.config file (C:\inetpub\wwwroot\wss\VirtualDirectories\80).
Health Events
- Health Events are a set of specific events that the FIM Service emits to the Application Log when root cause failures occur.
Workflow activities
Scenario: A request fails
Resolution
The first resolution step for any request failure is to inspect the request resource.
To find the status of the request
Find the request in Search Requests or in My Requests (use My Requests if you are investigating your own request).
Open the request resource.
On the Detailed Content tab, review the actual requested changes.
Note the value that is listed in Request Status.
Case 1: Request Status is “Denied”
If the Request Status is Denied, refer to the Scenario: A request’s Request Status is “Denied” section.
Case 2: Request Status is “Failed”
If the Request Status is Failed, refer to the Scenario: A request’s Request Status is “Failed” section.
Case 3: Request cannot be found
If the request resource cannot be found, an error was likely encountered during the process of creating the request. The request may have timed out. The default timeout configuration for operations submitted to the FIM Service is 58 seconds, so if you notice that the request is taking longer than 58 seconds to process, the problem is likely due to a timeout.
To collect more information to investigate the issue
Repeat the request that is failing.
Click Start, Programs, Administrative Tools, and then click Event Viewer.
Click Applications and Service Logs, and then double-click Forefront Identity Manager.
Search for an error event that occurred near the same time.
Information in the error should inform you about what system constraint or workflow activity failure prevented the request from succeeding.
Scenario: A request’s Request Status is “Denied”
A request failed and the Request Status of the request has a value of Denied.
Resolution
Case 1: Insufficient permissions for the requested operation
To verify that the user, represented as the Creator of the request, has permission to make the request:
- Open the request resource and view the Applied Policy page. If no Management Policy Rule (MPR) is listed on the page that grants permission to the request, you have confirmed that the problem is due to insufficient permissions.
Note
Alternatively, you can use the MPR Explorer feature in the FIM Portal to verify that a permission-granting MPR exists for that user’s request. If no MPR granting permissions to the requested operation exists, review the existing MPR configuration and consider changing it to allow the request.
Note
Remember that permission must be granted for the user to modify the requested attributes.
Case 2: Authentication or authorization failed
To verify if the request failed authentication or authorization, start by opening the denied request and viewing the Applied Policy page. See if any MPRs that apply authentication or authorization workflows are listed on this page.
If any MPRs that apply authentication or authorization workflows are listed on the Applied Policy page, view the value of the Request Status Detail attribute of the request resource. In the Normal View of the request resource in the FIM Portal, the Request Status Detail attribute is named Request Workflow Remarks.
If the information included in the Request Status Detail attribute does not clearly indicate an error in an authentication or authorization workflow, search for terminated authentication and authorization workflows associated with the request.
To search for terminated authentication and authorization workflows associated with the request
Log on to the FIM Portal as an administrator.
On the home page, under Administration, click All Resources, and then click Workflow Instance.
Click Advanced Search.
Click Add Statement, then click Click to select attribute and select Resource.
Click Click to select value and select the request by either searching by its Display Name or its ResourceID.
Click Add Statement, then click Click to select attribute and select Workflow status.
Click Click to select value, type Terminated, and then click Search.
Note
As an alternative to using the advanced search, a search scope with the following XPath filter can be used to identify only the terminated authentication and authorization workflows: /WorkflowInstance[Request = '2b2bb0b4-695d-43f5-b167-d479834756ff' and WorkflowStatus = 'Terminated' and WorkflowDefinition = /WorkflowDefinition[RequestPhase = 'Authorization' or RequestPhase = 'Authentication']]
Note
The ResourceID of the request that you are investigating needs to be used in place of the previous example for the Request = condition.
If you find that any of the workflow instances returned is an instance of an authentication or authorization workflow definition, you have discovered the reason for the denied request.
To understand why the workflow instance was terminated, refer to the Scenario: A workflow instance was terminated section.
Case 3: The request violated constraints of the FIM Service
It is possible that the requested operation violates FIM schema constraints, such as not supplying a value for a required attribute or supplying an invalid value.
It is also possible that the requested operation violates a fundamental constraint of the FIM Service.
View the request resource and its request details to see if any of the requested operations violate FIM Service constraints.
Case 4: The requested operation timed out
It is possible that the requested operation did not finish within the timeout threshold permitted by the FIM Service. The timeout setting for Read or Query operations is governed by the dataReadTimeoutInSeconds setting. The timeout setting for Create, Update or Delete operations is governed by the dataWriteTimeoutInSeconds setting. Extending these timeout settings may be needed for some large operations such as the creation, modification, or deletion of a large set or group.
The timeout settings can be modified in the Microsoft.ResourceManagement.Service.Exe.Config file.
For example, the following statement sets the Read and Write timeouts to 1 hour. If a value is not specified in the configuration file, the default value of 58 seconds is used for each timeout.
<?xml version="1.0" encoding="utf-8"?><configuration><resourceManagementService dataReadTimeoutInSeconds="3600" dataWriteTimeoutInSeconds="3600"/></configuration>
To avoid a timeout in the FIM Portal, the timeoutInMilliseconds setting in the resourceManagementClient section of the Microsoft.ResourceManagement.Service.Exe.Config file and the Windows SharePoint® Servicesweb.config need to be adjusted. For example:
<?xml version="1.0" encoding="utf-8"?><configuration> <resourceManagementClient timeoutInMilliseconds="3600" /></configuration>
Note
The FIM Service must be restarted for the FIM Service configuration setting changes to take effect. The Microsoft Identity Integration Server (IIS) World Wide Web Publishing Service (W3SVC) must be restarted for the FIM Portal configuration setting changes to take effect.
You can verify if the requested operation timed out by analyzing the FIM Application Log in the Event Viewer and searching for an error event around the same time of the failed request. The error message should indicate a timeout occurred.
Case 5: The FIM Service was interrupted while processing the request
It is possible that the requested operation was affected by a FIM Service interruption.
In particular, if a request had not yet reached the Authenticated state at the time of a FIM Service interruption, the request is canceled by the FIM Service upon startup and results in a Denied status.
To identify the error that prevented the request from succeeding
Repeat the failing request.
Click Start, Programs, Administrative Tools, and then click Event Viewer.
Click Applications and Service Logs, and then double-click Forefront Identity Manager.
Search for an error event at around the same time.
Information in the error should inform you about what prevented the request from succeeding.
If a request failed because of a FIM Service interruption, the only solution is to resubmit the request.
Scenario: A request’s Request Status is “Failed”
A request failed and the Request Status of the request has a value of Failed.
Resolution
A request results in a Failed status only when it encounters a failure while committing the requested operation to the FIM Service database.
It is possible that the requested operation violates a fundamental constraint of the FIM Service.
If the request did not violate a FIM Service constraint, the request may have encountered an unexpected error or timed out.
The following steps can be taken to identify the error that prevented the request from succeeding:
To identify the error that prevented the request from succeeding
Repeat the failing request.
Click Start, Programs, Administrative Tools, and then click Event Viewer.
Click Applications and Service Logs, and then double-click Forefront Identity Manager.
Search for an error event that occurred near the same time.
Information in the error should inform you about the system constraint or other error that prevented the request from succeeding. If the problem is due to a timeout, try extending the FIM Service Read and Write timeout and retrying the request.
Scenario: A workflow fails to start
A requested workflow activity fails to start.
Resolution
If the workflow was part of a configuration migration, ensure that the product version numbers were the same.
While migrating configurations across version numbers is not recommended or supported, you can often do this by replacing the pilot version number with the production version number in pilot.xml. Specifically, WorkflowDefinition and ActivityInformationConfiguration objects require the version number to refer precisely to workflow activities in the production environment. Failing to replace the version number results in the Compare-FIMConfig cmdlet identifying differences between the XOML attributes on WorkflowDefinitions and migrating the pilot’s version number. The production FIM Service may fail to start workflow activities with the incorrect version number.
Scenario: A request’s Request Status is "PostProcessingError”
A request completed its operation but its Request Status has a value of PostProcessingError.
Resolution
A request has a Request Status of PostProcessingError if any Action workflows triggered by the request failed or if any Collateral Requests linked to the request failed.
Case 1: An Action workflow failed
To determine if an Action workflow triggered by the request failed, first view the Request Status Detail attribute of the request to see if any errors were logged by workflows run for the request. The Request Status Detail attribute is named Request Workflow Remarks in the FIM Portal’s Normal View of the request resource.
If the information in the Request Status Detail attribute does not help to diagnose the problem, perform the following procedure.
To search for terminated authentication and authorization workflows associated with the request
Log on to the FIM Portal as an administrator.
On the home page, under Administration, click All Resources, and then click Workflow Instance.
Click Advanced Search.
Click Add Statement, then click Click to select attribute and select Resource.
Click Click to select value and select the request by either searching by its Display Name or its ResourceID.
Click Add Statement, and then click Click to select attribute and select Workflow status.
Click Click to select value, type Terminated, and then click Search.
Note
As an alternative to using the advanced search, a search scope with the following XPath filter can be used to identify only the terminated Action workflows: /WorkflowInstance[Request = '2b2bb0b4-695d-43f5-b167-d479834756ff' and WorkflowStatus = 'Terminated' and WorkflowDefinition = /WorkflowDefinition[RequestPhase = 'Action' ]]
Note
The ResourceID of the request that you are investigating needs to be used in place of the previous example for the Request = condition.
If any of the workflow instances are returned, to understand why the workflow instance was terminated, refer to Scenario: A workflow instance was terminated. If no workflows are returned, refer to Case 2: A Collateral Request failed.
Case 2: A Collateral Request failed
To determine if a Collateral Request triggered by the request failed
Log on the FIM Portal as an administrator, click Search Requests, and then locate the Request.
Open the request and click the Advanced View button.
From Advanced View, go to the Extended Attributes page to see if the Has Collateral Request option is selected.
If the request does have Collateral Requests, perform the following steps:
Log on to the FIM Portal as an administrator.
On the home page, under Administration, click Search Requests.
Click Advanced Search.
Click Add Statement, then click Click to select attribute and select Parent Request.
Click Click to select value and select the request by either searching by its Display Name or its ResourceID.
Click Add Statement, then click Click to select attribute and select Workflow status.
If any of the requests returned have a Status of Denied, refer to the Scenario: A request’s Request Status is “Denied” section.
If any of the requests returned have a Status of Failed, refer to the Scenario: A request’s Request Status is “Failed” section.
If any of the requests returned have a Status of PostProcessingError, repeat the steps in this section for the request.
Scenario: A request’s status may be stuck
A request has had the same Request Status value for an extended period of time.
Resolution
As a starting point, view the value for the Request Status attribute of the request resource in question. The value of Request Status can be an indication of different causes for the problem.
Case 1: Request Status is “Authorizing” or “PostProcessing”
A request with a Request Status of Authorizing or PostProcessing is in the process of running workflows.
To verify that the request does indeed have running workflows, perform the following steps in the FIM Portal:
To verify that the request has running workflows
Log on to the FIM Portal as an administrator.
On the home page, under Administration, click All Resources, and then click Workflow Instance.
Click Advanced Search.
Click Add Statement, then click Click to select attribute and select Request.
Click Click to select value and select the request by either searching by its Display Name or its ResourceID.
Click Add Statement, then click Click to select attribute and select Workflow status.
Click Click to select value, type Terminated, and then click Search.
Note
As an alternative to using the advanced search, a search scope with the following XPath filter can be used to identify the running workflows: /WorkflowInstance[Request = '2b2bb0b4-695d-43f5-b167-d479834756ff' and WorkflowStatus != 'Completed’ and WorkflowStatus != 'Terminated’]
Note
The ResourceID of the request that you are investigating needs to be used in place of the previous example for the Request = condition.
If no running authorization or Action workflows were found by using steps 1–3 listed previously, and the request has no active Collateral Requests, you need to cancel and resubmit the request.
If running authorization or Action workflows were found for the request, refer to Scenario: A workflow’s status may be stuck.
Case 2: Request Status is “Canceling”
A request with a Request Status of Canceling has had a Cancel command issued to it and is waiting for the request’s associated workflows to finish or be canceled and any Collateral Requests to finish or be canceled. If the request has a large number of workflows or Collateral Requests associated with it, the request may remain in the Canceling status for an extended period of time.
Note
The default maximum request cancel rate is 1,200 requests per minute.
Case 3: Request Status is “Validating,” “Validated,” or “Authenticating”
Requests with Request Status values of Validating, Validated, or Authenticating need to be canceled.
Case 4: Request Status is “Committed”
If a request has a Request Status of Committed, it was likely interrupted by a FIM Service interruption. Restarting the FIM Service should resolve the issue; otherwise, the request should be canceled.
Note
A request with a Request Status of Committed has already performed its requested operation. The work remaining for such a request is the execution of any applicable Action workflows.
Scenario: Unable to approve a request
A user approves a request but the approval is denied by the FIMService.
Resolution
This can occur when two FIM Service and FIM Portal servers are configured and both have e-mail processing enabled. If the request originates from one server and the approval is sent to the other server, the approval will fail as the Authorization workflow resides on a different ServicePartition.
In this scenario, it is recommended to turn off e-mail processing on one of the servers.
Scenario: A workflow’s status may be stuck
A workflow has had the same Workflow Status value for an extended period of time.
Resolution
As a starting point, view the value for the Request Status attribute of the request resource in question. The value of the Request Status can be an indication of different causes for the problem.
Case 1: Workflow Status is “Created” or “Pending”
A workflow that has had a Workflow Status of Created or Pending for an extended period of time does not automatically correct itself without intervention. Restarting the FIM Service that created the workflow directs the FIM Service to attempt to resume the execution of this workflow. Alternatively, the workflow can be canceled by canceling the associated request.
Note
Canceling the associated request also cancels all other workflows that have not yet finished.
Case 2: Workflow Status is “Running” and the workflow is waiting for input
A workflow that is waiting for input before proceeding to the next step in its execution will remain stuck in a running status until the input is provided. For example, an Approval activity cannot finish until it receives the required number of approval responses or reaches its expiration threshold.
To complete the execution of this workflow, the input the workflow is waiting for must be provided. If the situation is one where the provider of the input is no longer available, you can cancel the workflow by canceling the associated request.
Note
Canceling the associated request also cancels all other workflows that have not yet finished.
Case 3: Workflow Status is “Running” and workflow is attempting to send e-mail messages
If the workflow uses EmailNotificationActivity or ApprovalActivity and was unable to send e-mail messages, the workflow retries sending e-mail messages based on a delayed approach.
Wait up to 48 hours for the workflow to attempt to complete sending the e-mail messages. If this time passes and the workflow remains in Running status, you need to cancel and resubmit the request if it is not in the PostProcessing state. If the request is in the PostProcessing state, you can cancel the request, which terminates the running Action workflows. The workflows can be rerun by creating a new MPR with the workflow definition that you want and with run on policy update turned on, targeting a set that contains the resources to run the workflow against.
Case 4: Workflow Status is “Running” and the workflow is queued behind many other running workflows
If there are many other workflows currently running, this creates a long queue of workflows until system resources are available for them.
To view how many workflows are currently running in the environment
Log on to the FIM Portal as an administrator.
On the home page, under Administration, click All Resources, and then click Workflow Instance.
Click Advanced Search.
Click Add Statement, then click Click to select attribute and select Workflow Status.
Click Click to select value, type Running, and then click Search.
If a large number of workflows are returned (> 1000), there is a good possibility that the running workflow queue is very large and some workflows will remain running for an extended period of time. The reason a workflow may remain in a running status without actually executing its tasks and finishing is because there are no available CPU threads for it, since they are all being used by other running workflows.
As a first step, repeat the previously listed steps 1–5 periodically to verify that the number of running workflows is gradually decreasing. If the rate of execution of the workflows is not high enough, an option is to increase the number of CPU threads available for the workflows to use. This in turn allows more workflows to actively execute simultaneously.
The maximum number of simultaneously executing workflows can be configured in the Microsoft.ResourceManagement.Service.exe configuration file belonging to the FIM Service. There are two settings that can be added to the configuration file to control the number of simultaneous executing workflows. These settings are described in the following table.
| Setting | Example usage | Supported values | Default value |
|---|---|---|---|
maxSimultaneousAuthenticationWorkflows |
|
[0,Int32.Max] A value of 0 results in all workflows being throttled and no workflows being started. |
The default value for this method is 5 for a single-processor computer and (int)(5 * Environment.ProcessorCount * .8) for a multiple-processor computer. |
maxSimultaneousAuthorizationAndActionWorkflows |
|
[0,Int32.Max] A value of 0 results in all workflows being throttled and no workflows being started. |
The default value for this is 5 for a single-processor computer,and (int)(5 * Environment.ProcessorCount * .8) for a multiple-processor computer. |
Note
The workflow configuration settings in the previous table directly configure the DefaultWorkflowSchedulerService.MaxSimultaneousWorkflows Property. (https://go.microsoft.com/fwlink/?LinkId=186741).
Modification of these settings does not take effect until the FIM Service is restarted.
Important
Caution should be used when modifying these workflow throttle settings because setting a number too high may starve the system of resources for other tasks while setting the number too low may negatively impact workflow throughput. It is recommended that changes to these settings be tested in a test environment before implementing in a production environment.
Case 5: Workflow Status is “Running” and a qualifying Service Name and Service Partition Name cannot be found
When a request or workflow instance is created, it is tied to the Service Partition Name of the FIM Service that created it. A request or workflow instance can only be managed by a FIM Service instance that has the same Service Partition Name as the FIM Service that created it.
If a workflow instance appears to be stuck, identify the request referenced by the workflow instance’s ParentRequest attribute.
To identify the request referenced by the workflow instance’s ParentRequest attribute
Open the request resource in the FIM Portal.
To display the additional attributes for the request resource, click Advanced View, and then click Extended Attributes.
View the value of the Service Partition Name attribute and determine if any FIM Service installations have this value specified in their Microsoft.ResourceManagement.Service.Exe.config file for the servicePartitionName setting.
Note
If no value is specified for servicePartitionName in the configuration file, the value provided for the externalHostName setting is used as the Service Partition Name.
If you do not find a FIM Service installation with the same servicePartitionName value as that used by the Service Partition Name attribute on the request, you must configure a FIM Service to use the request’s Service Partition Name.
To configure FIM Service to use the request’s Service Partition Name
For any FIM Service installation, open the Microsoft.ResourceManagement.Service.Exe.config file.
Modify the value configured for servicePartitionName in the configuration file or add the property to the configuration file’s resourceManagementService section as follows:
<?xml version="1.0" encoding="utf-8"?><configuration><resourceManagementService servicePartitionName = “FIMService1”/></configuration>
Important
If a request has a Service Partition Name value of FIM SYSTEM, it can be managed by any FIM Service, regardless of the FIM Service’s servicePartitionName. Do not use the value FIM SYSTEM for the servicePartitionName or serviceName setting of any FIM Service.
If the request or workflow instance remains stuck even after ensuring that a FIM Service with the same Service Partition Name exists, the problem may be related to the Service Name that the request’s workflow instances are tied to.
When a workflow instance is running and is not in a dehydrated state, it is tied to the specific Service Name assigned to the FIM Service instance that it is running on. A running workflow instance can only be managed by a FIM Service instance that has the same Service Name as the one that the workflow instance is tied to.
If any of the following has taken place after the CreatedTime listed on the request or workflow instance, you may need to adjust the Service Name setting of a FIM Service installation:
A FIM Service server was taken offline.
The server hosting a FIM Service was renamed.
The database from one FIM Service instance was restored on a different computer.
You can adjust the Service Name of a FIM Service as follows:
To adjust the Service Name of a FIM Service
Open the Microsoft.ResourceManagement.Service.exe configuration file.
Modify the value configured for serviceName in the configuration file or add the property to the configuration file’s resourceManagementService section as follows:
<?xml version="1.0" encoding="utf-8"?><configuration><resourceManagementService serviceName = “machine1”/></configuration>
Scenario: A workflow instance was terminated
A workflow has a Workflow Status of Terminated.
Resolution
As a starting point in investigating any workflow-related issue, begin by viewing the Request Status Detail attribute on the associated request resource. If you cannot find enough helpful information in this attribute, perform the following procedure to view any additional information about the error, which is saved to the Workflow Status Detail of the affected workflow.
To view additional information about the error
Log on to the FIM Portal as an administrator.
On the home page, under Administration, click All Resources, and then click Workflow Instance.
Click Advanced Search.
Click Add Statement, then click Click to select attribute and select Request.
Click Click to select value and select the request by either searching by its Display Name or its ResourceID.
Click Add Statement, then click Click to select attribute and select Workflow status.
Click Click to select value, type Terminated, and then click Search.
Note
As an alternative to using the advanced search, you can use a search scope with the following XPath filter to identify terminated workflows: /WorkflowInstance[Request = '2b2bb0b4-695d-43f5-b167-d479834756ff' and WorkflowStatus = 'Terminated']
Investigate the workflows returned by your search by opening them in the FIM Portal and viewing the value of their Workflow Status Detail attribute to get specific details of the error encountered.
Case 1: The workflow logic terminated the workflow
Workflows terminate if they throw an unhandled exception. This is often the case in authentication and authorization workflows when the workflow logic determines that the request should not be authenticated or authorized.
To see if the workflow included a message indicating why it terminated, view the RequestStatusDetail attribute on the associated request resource and the WorkflowStatusDetail on the associated workflow instance resource.
Case 2: The workflow’s request failed
If the workflow submits requests to the FIM Service, it is possible that one of the requests failed or was denied. If this is the case, refer to the Scenario: A request fails section.
It is also possible that the workflow is attempting to perform an operation on a resource that no longer exists.
Case 3: The authentication workflow failed due to a FIM Service interruption
If the FIM Service is shut down or stopped while an authentication workflow is running, the workflow is terminated when the FIM Service restarts. The request associated with the failed workflow must be resubmitted.
Case 4: The workflow failed to persist
If a public property on the workflow cannot be serialized, the workflow fails when attempting to persist. To resolve this problem, all the public properties on workflows must be marked as serializable and the failed workflows need to be rerun.
Case 5: Workflow activity code error
If the terminated workflow contains a custom workflow activity, there is a possibility that an error has been encountered in the custom activity code or logic. Test the custom activity thoroughly in the test environment to ensure that the activity works as expected. Workflow activities must be able to run multiple times on the same target resource or be resumed from any persistence point.
Case 6: Workflow version mismatch
The XOML of a workflow definition contains a reference to the version number of the Microsoft.ResourceManagement.dll assembly. If the version of this assembly changes, the following steps are needed:
Binding redirection must be added to the Microsoft.ResourceManagement.Service.exe configuration file for the updated FIM Service, redirecting calls to the Microsoft.ResourceManagement.dll assembly from the old version to the newly installed version.
Note
If an installation of FIM is updated through a software update, this binding redirection should automatically be added by the update installation.
Ensure that the old version of the Microsoft.ResourceManagement.dll assembly (the version prior to the update) is in the Global Assembly Cache (GAC). This is needed to allow workflow instances created prior to the update to be rehydrated. If the old version of the Microsoft.ResourceManagement.dll assembly cannot be found, the workflow instances that were persisted prior to the installation of the software update need to be canceled.
Web Service Interface
The following scenarios relate to troubleshooting SOAP messages custom clients send to the FIM Service.
Scenario: SecurityNegotiationException
Custom client receives exception System.ServiceModel.Security.SecurityNegotiationException.
Resolution
This is a Windows Communication Foundation (WCF) or network-level failure that is independent of the FIM Service.
Verify that the credentials for the client are correct.
- Ensure that the username and password are valid Active Directory® accounts.
Verify that the domain controller is reachable.
Verify that the Kerberos version 5 protocol delegation and the Service Principal Name (SPN) is properly configured for the FIM Service.
- For more information, see the FIM 2010 Installation Guide.
Exchange Mail Listener
The Exchange Mail Listener polls Microsoft Exchange Web Services periodically to process incoming Microsoft Office Outlook® requests and to send outgoing approval mails.
Scenario: Cannot connect to Exchange
FIM Service cannot send outgoing mail or does not process Office Outlook requests. The Application Log contains multiple errors with Event ID 12.
Resolution
To verify that Exchange Web Service is reachable from the FIM Service computer
Ensure that the mailServer value in the Microsoft.ForefrontIdentityManager.exe.config file is correct.
Open the mailServer value address (typically https://server/ews/exchange.asmx) in Windows Internet Explorer®.
To verify that the Exchange Web Service certificate is valid and trusted by the FIM Service computer
Log in to the computer as the FIM Service account and, in Internet Explorer, open the Exchange Web Service address.
Ensure that the Web Service Description Language (WSDL) appears without certificate errors or access denied errors.
To verify that the FIM Service account has an active mailbox in Exchange Web Service
- Log on to Office Outlook Web Access as the FIM Service account.
Scenario: Exchange does not process group management requests
The FIM Service can process approval responses from Outlook but cannot process any group management requests. The Application log does not contain errors with Event ID 12.
Resolution
Ensure that FIM is configured to actively poll exchange for Group Management Requests. Verify that the following registry value is set to 1:
SYSTEM\CurrentControlSet\Services\FIMService\PollExchangeEnabled
If the registry value is 0, then you must restart the service in order for the change to take effect.
Configuration Migration
Migrating a configuration between two FIM Services often exposes unseen dependencies. To avoid many of these scenarios, follow the steps listed in the FIM 2010 Configuration Migration Tool Deployment Guide (https://go.microsoft.com/fwlink/?LinkID=165849) in the FIM documentation.
Scenario: Failure importing a change
A failure occurs from importing a change.
Resolution
Open the undone.xml file and inspect the first ImportObject.
This ImportObject is the one that could not be imported successfully.
To troubleshoot the cause of why this request failed, follow the instructions in the Scenario: A request fails section.
It may be necessary to edit the ImportObject and remove the problem change.
Scenario: Migrating changes to Display Names
You want to migrate a change to a display name for policy resources such as MPRs. The cmdlets produce two changes: a Delete for the existing resource and a Create for a new resource with the different display name.
Resolution
For many resource types, such as MPRs, the default join criteria is to use the display name as the only anchor attribute between two systems.
Use different join criteria to match resources between environments.
Bind a custom attribute to all configuration object types and use that attribute as the join criteria.
Scenario: Cycles in configuration
The Compare-FIMConfig cmdlet displays an error when a cycle exists in the pilot configuration.
Because the Compare-FIMConfig cmdlet displays a list of changes in order of precedence, there must be no cycles among the references of configuration objects.
Resolution
To resolve a cycle conflict
You must break the cycle manually.
Start with the ResourceID of one of the resources included in the cycle.
Follow that resource’s references to other resources and identify the cycle.
- A common cycle is two sets that refer to each other.
Remove one of the references from the cycle.
Restart the migration process.
FIM Service Performance Counters
Enable WCF performance counters
FIM uses WCF performance counters to monitor your service usage. Monitoring service usage with WCF performance counters is an optional step to turn on when diagnosing performance problems. It is not necessary to leave performance counters turned on for normal operations. To turn on and configure WCF performance counters, follow the instructions in Enabling Performance Counters (https://go.microsoft.com/fwlink/?LinkId=164848), and edit Microsoft.ResourceManagement.Service.exe.config located in the FIM installation directory.
Adding performance counters to the Windows Performance Monitor
Once WCF performance counters are turned on and the FIM Service is started, the counters may be viewed in the Windows Reliability and Performance Monitor (perfmon.exe). For more information about the Windows Reliability and Performance Monitor, see the Windows Performance Monitor article (https://go.microsoft.com/fwlink/?LinkID=140807).
ServiceModelService instances
The FIM Service WCF counters are listed under ServiceModelService 3.0.0.0, ServiceModelEndpoint 3.0.0.0, and ServiceModelOperation 3.0.0.0. The following table summarizes the individual WCF services listed in ServiceModelService 3.0.0.0.
| Service | Description |
|---|---|
resourcemanagementservice@exchange.mail |
The primary Web service interface of FIM. This service exposes the Resource, ResourceFactory, and Enumeration endpoints that the FIM Portal uses to make requests. Additionally, this service polls the monitored Exchange mailbox. |
securitytokenservice@http |
The primary Web service interface for password reset. This service exposes the Security Token Service that the password reset feature uses to register and reset passwords. |
sequentialworkflow@[guid] |
Most environments have multiple sequential workflow services turned on. Each sequential workflow represents one workflow definition that contains an approval activity. By default, there are two workflow definitions. This service exposes the Resource and ResourceFactory endpoints that the FIM Portal uses to submit approvals. |
ServiceModelEndpoint instances
The following table summarizes the individual WCF endpoints in ServiceModelEndpoint 3.0.0.0 (## indicates a number that is environment-specific).
| Endpoint | Description |
|---|---|
resourcemanag##.imetadataexcha## @##resourcemanagementservice|mex |
https://server:5725/ResourceManagementService/MEX The MetadataExchange endpoint exposes the IMetadataExchange interface that returns the service metadata. Calls to this endpoint should occur on periodic intervals—every 10 or 15 minutes—as the FIM Portal refreshes its schema. This endpoint should produce no faults or failures. Such failures indicate a corruption of schema configuration. |
resourcemanag##.resource @##cemanagementservice|alternate |
https://server:5725/ResourceManagementService/Alternate The Alternate endpoint exposes the Resource interface that anonymous users can use to initiate the password reset process. Calls to this endpoint generally measure end users who are initiating self-service password resets. All calls to this endpoint should generate corresponding faults because all requests to this endpoint generate an authentication workflow. |
resourcemanag##.resource @##rcemanagementservice|resource |
https://server:5725/ResourceManagementService/Resource The Resource endpoint exposes the Resource interface that authenticated users can use to read, update, and delete existing objects in the FIM Service. Calls to this endpoint generally measure end users who are initiating self-service group management and user profile management requests. Most calls to this endpoint should generate corresponding faults that represent authorization workflows. The proportion of faults depends on the usage and the configuration. |
resourcemanag##.resourcefactory @##gementservice|resourcefactory |
https://server:5725/ResourceManagementService/ResourceFactory The ResourceFactory endpoint exposes the ResourceFactory interface that authenticated users can use to create new objects in the FIM Service. Calls to this endpoint generally measure end users who are initiating self-service group management creation requests. Most calls to this endpoint should not generate corresponding faults because the default implementation has no authorization workflow for group creation. The proportion of faults depends on the usage and the configuration. |
resourcemanag##.resourcemail @##anagementservice|resourcemail |
An internal endpoint used to route Exchange mail from the monitored Exchange mailbox. |
resourcemanag##.search @##managementservice|enumeration |
https://server:5725/ResourceManagementService/Enumeration The Search endpoint exposes the Enumeration endpoint that authenticated users can use to query existing objects in the FIM Service by using XPath filters. Calls to this endpoint generally measure end users who are querying the service. Many FIM Portal operations result in queries. For example, loading the FIM Portal involves querying for portal configuration objects that describe how to lay out the Web page. Most calls should not generate corresponding faults. |
sequentialwor##.imetadataexcha## @[guid] |
Most environments have multiple sequential workflow MetadataExchange endpoints turned on. Each sequential workflow MetadataExchange endpoint returns the metadata of the object required to complete the workflow on the corresponding sequential workflow resourcefactory endpoint. Calls to this endpoint generally measure Web service clients that are refreshing their schema for the approval scenario. Most calls should not generate corresponding faults. |
sequentialwor##.resourcefactory @[guid] |
Similar to the previous MetadataExchange endpoint, most environments have multiple ResourceFactory endpoints turned on for each sequential workflow. Each ResourceFactory endpoint accepts an object that the workflow uses to complete a request. For example, the approval workflow accepts an approval object to signify the request is approved. Calls to this endpoint generally measure end users who are approving requests. Most calls should not generate corresponding faults. |
ServiceModelOperation instances
The following table summarizes the individual WCF operations in ServiceModelOperation 3.0.0.0. Each of the endpoints described previously in ServiceModelEndpoint instances implements one or many endpoint interfaces. Each operation described in the following table is present in the endpoint interface listed and may be matched.
| Operation | Endpoint interface | Description |
|---|---|---|
Create |
ResourceFactory |
The Create operation is used to create FIM Service objects such as groups and submit approvals. |
Put |
Resource |
The Put operation is used to update an existing FIM Service object. For example, updating a group’s display name or adding a member are both accomplished by the Put operation. Additionally, on the Alternate endpoint, the Put operation is used to initiate the password reset process. |
Delete |
Resource |
The Delete operation is used to delete an existing FIM Service object. |
Get |
Resource |
The Get operation is used to retrieve an existing FIM Service object. |
Enumerate |
Enumeration |
The Enumerate operation is used to query for existing objects that match a given filter. |
Pull |
Enumeration |
The Pull operation is used to retrieve additional objects that match an initial Enumerate but could not fit in the initial response. |
Get |
IMetadataExchange |
The Get operation is used to retrieve the metadata of a service. |
Interpreting performance counter results
The WCF performance counters measure broadly the requests made to the system and their outcomes.
One specific note is that FIM uses SOAP faults to communicate that authentication and authorization workflows are running, and, in typical deployments, most requests lead to such workflows and therefore most requests lead to SOAP faults. There are no published thresholds of FIM Service WCF counters.
The following table summarizes WCF counters that are relevant to FIM.
| Counters | Description |
|---|---|
Calls Calls Per Second |
Measures individual SOAP requests made to the interface. In many cases, a single operation in the FIM Portal or in the password reset feature consists of multiple SOAP requests. |
Calls Faulted Calls Faulted Per Second |
Measures individual SOAP responses that are SOAP faults. Many operations such as requesting to join a group or initiating the password reset process result in SOAP faults. These faults are expected for most end-user requests. Use Calls Faulted and Calls Faulted Per Second to measure the general load of requests to change the system. To measure specific requests, query the number of request objects in the FIM Service. instead |
Calls Failed Calls Failed Per Second |
Measures all SOAP responses that are SOAP faults and WCF communication failures. In addition to the faults measured by Calls Faulted, Calls Failed measures WCF authentication failures, requests with misconfigured SOAP action elements, and other corrupt SOAP requests. Use Calls Failed and Calls Failed Per Second to measure all calls which result in any response other than a normal SOAP response. |
Calls duration |
Measures the duration of individual SOAP requests. Use Calls Duration to generally measure the responsiveness of the FIM Portal and the password reset feature. |
Measuring specific scenarios
Turn on the following performance counters to measure the following common scenarios.
| Scenario | Counters to Turn On |
|---|---|
Password reset requests |
Calls or Calls Per Second on ServiceModelOperation instance resou##.resou##.put@##cemanagementservice|alternate |
Password reset responsiveness |
Calls Duration on ServiceModelEndpoint instance resourcemanag##.resource @##cemanagementservice|alternate |
Completed approvals |
Calls or Calls Per Second on all ServiceModelEndpoint instances sequentialwor##.resourcefactory @[guid] |
FIM Portal responsiveness |
Calls Duration on ServiceModelService instance resourcemanagementservice@exchange.mail |
General FIM Portal load |
Calls or Calls Per Second on ServiceModelService instance resourcemanagementservice@exchange.mail |
FIM Portal
The FIM Portal provides an end-user experience for managing groups and approving requests.
Scenario: Cannot connect to the FIM Service
The FIM Portal cannot connect to the FIM Service. The Application Log contains an error event with Event ID 10.
Resolution
Verify that the configuration settings point to the correct FIM Service.
- See the web.config file or reinstall the portal.
Verify network connectivity between the FIM Portal and FIM Service.
If the FIM Portal is on a different server than the FIM Service, verify that ports 5725 and 5726 allow incoming HTTP traffic.
Verify that the FIM Service is running.
FIM Synchronization Service
FIM Management Agent
Scenario: Export failure
Exporting changes to the FIM Service results in failed-creation-via-web-services.
Resolution
Inspect the cause of the failure by clicking on the failed-creation-via-web-services link.
The dialog box contains the fault details with diagnostic information from the FIM Service.
Note
The information in this dialog box is the same information you would find in the diagnostic log; the FIM MA saves you the correlation Step.
Note
It may be necessary to begin diagnosing the request following the instructions in the Scenario: A request fails section.
Common fault details:
InvalidRepresentation - The failure is in parsing the user input or the input violates public constraints such as the schema.
UnwillingToPerform – The request failed to dispatch. For example, running the FIM MA on an account the FIM service doesn’t think is the FIM MA will trigger this fault.
PermissionDenied – The request was dispatched but failed to complete. In general this can be related to an Authorization workflow, but for the FIM MA this is an issue with a missing or misconfigured MPR.
EndpointUnavailable - A cross-cutting failure which also emits a health event.