none
mmsscrpt.exe consumes 100% CPU, build 4.0.3561.2 + exchange 10 provisioning

    Question

  • Hi,

    after switching to Exch2010 user provisioning sometimes after delta or full sync /export run cycle I have mmsscrpt.exe consuming all CPU resources.

    Looking on it with procexp I can only see 4 threads cycling with mscorwks.dll!InitializeFusion (.net)

    I can't find the 100% reproducible scenario to open a case with product support group and search on this forum related to high cpu load also points to hotfixes I do have already installed...

    sometimes full sync cycle for all MAs finishes fine, sometimes mmsscrpt remains consuming from 25 to 100% cpu (depending on number of threads)

    Anyone with the same experience?

    Tuesday, December 28, 2010 8:52 AM

Answers

All replies

  • it happens after export to AD MA obviously, but not all the time.
    Tuesday, December 28, 2010 9:07 AM
  • Most of those threads (and hotfixes) relate to miiserver.exe using 100%. However mmsscrpt.exe using 100% has been solved for a similar case here:

    http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/0ed2ab1f-0dd3-4cbf-895d-67136a77cc96

    The .net patches referenced there are definately worth a try


    http://setspn.blogspot.com
    Tuesday, December 28, 2010 9:20 AM
  • Thomas, thanks again.

    I thought I have already applied Windows6.1-KB981574-v2-x64.

    its even unpacked on the server, but mscorwks.dll has wrong version.

    so applied the patch.

    now after sync cycle .NET optimization engine consumes 25% of CPU for 2-3 minutes and then drops CPU load to 0.

     

    really interesting what has caused .NET .dll to rollback to the previous version...

    Tuesday, December 28, 2010 9:56 AM
  • An old thread I know, but it seemed like the only relevant thread out there for this.

    Just wanted to let others know that this issue (or at least one with the same symptoms) reappears when the BETA Windows Management Framework 3.0 (PowerShell 3.0, WMI, WinRM) update is installed on Server 2008 R2.  In my case it was FIM 2010 R2.  Turning off Exchange provisioning prevented the issue, which got me down the PowerShell path.

    I removed the Beta WMF 3.0 and the issue went away.  I installed the RTM WMF 3.0 and the issue did not return.

    Hope it helps someone down the line...


    Keith

    Tuesday, November 20, 2012 2:41 PM