ProblemThere is a known issue with FIM/MIM that causes the synchronization service to stop responding, requiring you to kill miiserver.exe with task manager and restart the service.
CauseThis is triggered when the following two conditions occur
- A delta import on the FIM MA finishes
- A synchronization run on another MA is in progress
InvestigationWhen the FIM MA goes to write its delta watermark, it does so by updating the value in its MA configuration. Unlike other MAs, this requires a full MA config update (the same as if you changed a flow rule or other setting in the MA config), which increments the version number, and requires an exclusive database lock.
A synchronization running at the same time reads the same database table and causes a deadlock situation that is never resolved.
Evidence that this behaviour is different from other MAs can be seen by running the following command using Lithnet MIIS PowerShell. The FIM MA will always have a much higher version number that any other MA, and will increment after every import operation. Other MAs only update their version number when their configuration is changed by an admin in the UI.
PS C:\Windows\system32> Get-ManagementAgent | select Name, Version, Category
Name Version Category
---- ------- --------
AD 59 AD
_IAM_ReleaseVersion 42 Extensible2
FIMService 113951 FIM
_IAM_SyncEngineVersion 41 Extensible2
Sap 35 Extensible2
GoogleApps 83 Extensible2
LDS 23 ADAM
ACMA 76 Extensible2
StudentDB 93 Extensible2
ZAVip 99 MSSQL
Interestingly, the UI prevents you from making changes to an MA when other MAs are running, presumably to protect against this kind of situation. However a FIM MA delta import ultimately does exactly the same thing.
WorkaroundUnfortunately, the only way to prevent this from happening is to not run any synchronization profiles, when an import is running on the FIM MA.
This issue was logged with Microsoft, however, this will not be fixed, as their support statement is that running multiple run profiles simultaneously is not supported.