The stopped-server status is a common status that is seen in the FIM Synchronization Service Engine when executing an import and/or export run on a given management agent. The following information has been compiled to provide guidance on how to begin troubleshooting a stopped-server status and possibily resolve a stopped-server status.
The stopped-server status is a WMI Return Code (http://msdn.microsoft.com/en-us/library/windows/desktop/ms699322(v=vs.100).aspx) from the RunStatus Property.
Additionally, this blog will cover at-least one specific scenario that had a stopped-server status.
|SQL Server Instance Check||
|Determine which Management Agent is returning the Stopped-Server||
|Determine which Run Profile is returning the stopped-server||
|Review the Run History (Operations Tab)||
|Application Event Log||
|FIM Service Management Agent||
FIM 2010 R2 – Receiving a stopped-server when running an export on the FIM Service Management Agent. The export will sit there for a few minutes and then return a stopped-server status and stop the export. Actions Taken
- Application Event Log: In any stopped-server issue, we should always start with the Application Event Log, as the stopped-server may throw some valuable information into the Application Event Log. In review of the Application Event Log the following line was found in the BAIL error message. “The operation failed because the object cannot be found”.
|Application Event Log|
Event ID: 6301
The server encountered an unexpected
2. Request History: Based on the fact that we are running an Export on the FIM Service Management Agent, and that we are seeing a message indicating that the object cannot be found the next stop is the Request History. You can review Request History via the following steps:
- Open Internet Explorer and navigate to the FIM Portal
- Click Search Requests on the menu on the left
- To search requests for today, simply click the magnifying glass
I. If you need to review prior days, you may have to execute an advanced search
d. If you see a request for msidmCompositeType then the issue could very well be asynchronous processing.
In FIM 2010 R2 Asynchronous Processing was enabled by default.
NOTE: Asynchronous Processing is where we process a batch of records at one time.
3. Review Asynchronous Processing Configuration: Since we have an idea that the problem is asynchronous processing, let’s review the current asynchronous processing configuration.
- Open a Windows Explorer window and navigate to where you have the FIM Synchronization Service application installed
- Double Click on the Bin Folder
- Locate the MIISERVER.EXE.CONFIG file
- Make a backup copy of the MIISERVER.EXE.CONFIG File
- Edit the MIISERVER.EXE.CONFIG file
- Search for the section resourceSynchronizationClient
i. By default it will look like <resourceSynchronizationClient />
ii. There is a commented section with the specified property names that can be utilized here. I have put them in the below table.
|Property Name||Default Value||Description|
|asynchronous||True||This property controls
whether FIM MA uses the older synchronous channel or the new asynchronous
channel when communicating with FIM Service.
|Aggregate||True|| This property controls whether FIM MA can
send data to FIM Service in batches.
|aggregationThreshold||1000|| This property controls the number of
attributes per aggregated batch.
|delayUpdateAcknowledgements||False||This property controls
whether the FIM Management Agent sends acknowledgements to FIM
Synchronization Service immediately upon Request completion, or withholds
them until the end for Update operations. Setting this to true may reduce the
overall time to export data, but the FIM Synchronization Service UI
statistics are not updated as frequently.
|exportRequestsInProcessMaximum||50||This property controls the
maximum number of export requests that
can be in process.
To resolve this scenario it is recommended to go through the following steps:
- Disable Asynchronous Processing (Throttling)*NOTE: More information on next slide
- Run the Export on the FIM Service Management Agent followed by the Confirming Delta Import (Stage Only) then the Delta Synchronization.
- Once you have cleared the Pending Exports, you can then re-enable Asynchronous Processing. However the recommendation is not to use the default value of 1000. Start at a low number, like 100 and let it run for a while to ensure no stopped-server. Increment from there.
|Default:: Asynchronous Processing is
enabled with a 1000 record threshold
|Disable Asynchronous Processing||<resourceSynchronizationClient
|Asynchronous Processing on with a
threshold of 300 objects
asynchronous=“true” aggregate=“true” aggregationThreshold=“300” />
- FIM 2010 R2: Troubleshooting FIM 2010 R2 stopped-server on the FIM Service Management Agent: http://social.technet.microsoft.com/wiki/contents/articles/11331.troubleshooting-fim-r2-stopped-server-error-on-the-fim-service-management-agent.aspx
- Troubleshooting stopped-server returned on a GalSync MA: http://social.technet.microsoft.com/wiki/contents/articles/15526.troubleshooting-fim-galsync-stopped-server-on-ma-export.aspx
- Troubleshooting stopped-server (Event ID: 6311 and 6401) obsoletionlist.cpp(319) is not a valid DN depth: http://social.technet.microsoft.com/wiki/contents/articles/10930.troubleshooting-stopped-server-event-id-6311-and-6401-obsoletionlist-cpp-319-0-is-not-a-valid-dn-depth.aspx
- Reference: How to Enable Tracing (FIM MA, FIM Service, FIM Portal, Lotus Notes, DirSync): http://blogs.msdn.com/b/ms-identity-support/archive/2012/05/04/how-to-enable-fim-service-fim-service-management-agent-tracing-and-verbose-tracing-for-the-fim-portal.aspx
- WMI Provider Return String: http://msdn.microsoft.com/en-us/library/windows/desktop/ms699322(v=vs.100).aspx