There 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.
This 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
When 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 59AD _IAM_ReleaseVersion42Extensible2 FIMService 113951FIM _IAM_SyncEngineVersion 41Extensible2 Sap35Extensible2 GoogleApps 83Extensible2 LDS23ADAM ACMA 76Extensible2 StudentDB93Extensible2 ZAVip99MSSQL
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.
Unfortunately, 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.