I recently had issue in which mmsscrpt.exe would peg one CPU and hang indefinitely during an sync to the FIM Service MA. My environment is a single Windows Server 2008 R2 box. My run sequences consisted of delta imports and delta sync to my two data MAs (SQL and AD) and to the FIM service. These were followed by an export and a delta import delta sync to the same MAs. All was fine until the final delta import and delta sync ran. When it did mmsscrpt.exe jumped to consume one thread and the runs effectively stopped.
Also, a run of full imports and full syncs on all MAs did not show the problem, it was only when the exports were introduced.
In an effort to fix it, I upgraded my FIM 2010 R2 from RTM (4.1.2273.0) to Hotfix Rollup 1 (4.1.2548.0) – no change.
I found a similar issue on the FIM Forum, but it was caused by a .Net Framework bug. I already had all of the current updates, so those hotfixes were not relevant to me. However, it was mentioned in there that turning off Exchange 2010 provisioning caused the issue to go away. The same was true for me, which was the light bulb moment – PowerShell.
In my environment I had deployed the Windows Management Framework 3.0 (PowerShell 3.0, WMI, & WinRM) so that I could use Server 2012’s Server Manager with the older operating systems. I figured PowerShell 3.0 was breaking something with the remote PowerShell call done when provisioning Exchange, so I went to remove WMF 3.0. In doing so, I noticed that I apparently had deployed the WMF 3.0 BETA. I removed it, rebooted, and the issue was gone.
Finally, after realizing it was a beta, I download the current installer for WMF 3.0 (RTM) and installed it. After another reboot, the issue did not return.
So, the bottom line is that the WMF 3.0 Beta is incompatible with FIM 2010 R2 (not tested with FIM 2010, but I’d be willing to bet it causes issues there too).