The FIM/MIM Synchronization engine stops responding

Problem

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.

Cause

This is triggered when the following two conditions occur

1. A delta import on the FIM MA finishes
2. A synchronization run on another MA is in progress

Investigation

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                     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.

Workaround

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.