FIM fails to run Extensible Connectivity 2.0 MA after applying KB2688078


  • Hi,

    We have FIM 2010 v4.0.3617.2

    Recently we created an Extensible Connectivity 2.0 Call-Based MA. We began simply, by first enabling IMPORT capabilities of MA. This worked fine.

    Later we added the EXPORT capability to this MA. The Export profile used to fail with an Event ID 6401. We did some troubleshooting and a technet article led us to try installing KB2688078 to resolve this issue.

    After the installation of this KB, the MA would fail to launch even the IMPORT profile.

    Simply even going to the Properties sheet of this MA and trying to hit Refresh Interface results in an Error "The extension operation aborted due to an internal error in FIM Synchronization Service" This message pops-up 4 times before the MA list of capabilities is shown on screen. Progressing to the other steps in Properties page lead to same result.

    Trying to run the MA, either Import or Export profile, shows the status as no-start-ma

    Digging into Event Viewer shows this:

     <Provider Name="FIMSynchronizationService" />
      <EventID Qualifiers="49152">6401</EventID>
    <Data>ERR: MMS(4380): libutils.cpp(9939): Failed to start run because of undiagnosed MA error Forefront Identity Manager 4.0.3617.2</Data>

    In the last 2 days of our troubleshooting, we have tried to recycle the services, restarted the server a few times, and followed other general suggestions as posted by users on technet. The only last option that the forums talk about is reinstalling the FIM. We want to avoid re-installation and troubleshoot the issue to find a fix. Still, if there is no other way out, we would like to know the impact of re-installation and how it can be avoided in the future?

    Would like to clarify that DB based MA's, AD based MA's and LDAP based MA's are still working fine. Only the Extensible MA's are failing.

    Any help will be appreciated.



    Wednesday, May 23, 2012 2:43 PM


All replies

  • Any comments???
    Thursday, May 24, 2012 6:59 AM
  • Sounds like you've hit another bug to me, but have you tried running your MA in a separate process, and have you got FIM Update 2 rollup installed (I can't remember all the version numbers) and not taken this into account (not the issue, but the .Net 4 issue resolution) 

    Long shot ... but suspect a bug.

    Bob Bradley (FIMBob @ ... now using Event Broker 3.0 @ for just-in-time delivery of FIM 2010 policy via the sync engine

    • Edited by UNIFYBobMVP Thursday, May 24, 2012 11:02 AM clarification
    Thursday, May 24, 2012 10:59 AM
  • Thanks for the reply Bob. Still no luck.

    Would try updating to Rollup 2. Still looks like a lost cause.

    Monday, May 28, 2012 10:15 AM
  • Have you checked your event logs for DCOM errors or suchlike?

    Bob Bradley (FIMBob @ ... now using Event Broker 3.0 @ for just-in-time delivery of FIM 2010 policy via the sync engine

    Monday, May 28, 2012 10:44 AM
  • Yes I did check the logs, actually the event logs were the only stuff I had to carry forward my R&D.

    As there was nothing coming out of the R&D, we decided to roll-back the KB patch that we had applied. As we are working on a VM, we just restored the VM image from the time before we applied the patch.

    The only downside to that is, now we are back to square one where we are having stopped-server error while trying to export. :(

    Any help would be truly appreciated.

    Wednesday, June 06, 2012 3:17 PM
  • Unfortunately I've run in to this at a customer as well. We ended up doing an in-place upgrade to FIM 2010 R2 and everything began running again.

    Remember to keep your encryption key handy or do an export with MIISKMU before upgradering - and depending on the numbe of objects in your solution prepare for some upgrade time. Also, do an Server Export to save configuration before upgrade to be on the safe side.

    After upgade do Full Imports and Full Syncs to freshen the objects.

    Regards, Soren Granfeldt
    blog is at | twitter at!/MrGranfeldt

    Wednesday, June 20, 2012 7:10 AM
  • I don't know if you guys solved this already but check the version of the Microsoft.MetadirectoryServices.dll file, I'm pretty sure there is known issue with 4.0.3606.2 being upgraded to 4.0.3617.2 and this file not being updated properly. If this is true, you should be able to fix by getting correct version of the file and replacing the 3606 version.

    Also, did you verify the .NET 4.0/miiserver.exe.config file issue that Bob mentioned above?

    Saturday, August 18, 2012 6:34 AM
  • After installing RU 2 with the new ECMA 2.0, my existing XMAs all died. Here is the error I get t from them:

    These are physical Sync servers so I am stuck unless I can find a way to re-install and make SQL play nice with the new structures, but I doubt it.

    The management agent controller encountered an unexpected error.
     "BAIL: MMS(6064): extensionmanager.cpp(550): 0x80230709
    BAIL: MMS(6064): extensionmanager.cpp(1740): 0x80230709
    BAIL: MMS(6064): export.cpp(1090): 0x80230709
    BAIL: MMS(6064): export.cpp(130): 0x80230709
    BAIL: MMS(6064): cntrler.cpp(3530): 0x80230709
    ERR: MMS(6064): cntrler.cpp(3673): Controller Export failed with hr=  80230709.
    Forefront Identity Manager 4.0.3617.2"

    I performed the rollup to 3617 too, but it did not help. MS is working on this for me and I'll get back to you when I hear something.

    They are working on several of these.

    Monday, August 20, 2012 3:07 PM
  • Soren ..... I have read some posts that describe failed attempts to do in-place upgrades to FIM 2010 R2.

    Do you have a good reference for tips on the procedure? I have solved this problem dows to a single NOTES field that is producing the problem,

    but I would like to have all of the data if possible.



    Mike W.

    Monday, August 20, 2012 5:08 PM
  • Take a look at miiserver.exe.config -- what do you have in the <startup /> block?

    Also examine Microsoft.MetadirectoryServicesEx.dll; is it the exact same version against which your ECMA2 was built?  If not, add a bindingRedirect to miiserver.exe.config (presuming this is running in-process) or update the development copy and rebuild.

    In my experience almost all "ECMA + FIM update" issues stem from the two areas above.


    Monday, August 20, 2012 5:38 PM
  • Any resolution from anyone for this one - one of my customers has just run into this issue with old Extensible MAs. Environment was running rollup update 2 and after updating to latest patch we have run into this issue with all ExMAs. Changes in miiserver.exe.config files are not helping. Doing things with DLLs is not helping. All files seems to be in correct version.
    Thursday, August 23, 2012 7:42 PM
  • @Tomasz: I've only run into this at one customer and they were only running Sync Service, so we did and in-place upgrade to R2 and everything was back to "normal". I did not have enough time to troubleshoot, so I can't repro the problem unfortunately.

    Seems like MS is working on this apparently.

    Regards, Soren Granfeldt
    blog is at | twitter at!/MrGranfeldt

    Thursday, August 23, 2012 7:51 PM
  • I've yet to do an in-place upgrade of the FIM Service/Portal; we only did the Sync Engine. We are planning for a reinstallation (followed by re-sync) when time allows for it, as I'm not fond off in-place upgrades.

    Regards, Soren Granfeldt
    blog is at | twitter at!/MrGranfeldt

    Thursday, August 23, 2012 7:54 PM
  • I did an in-place upgrade of a 22GB FIM environment on our Development server (2 procs - 8GB RAM) VM and it took 18 days to finish.

    It was easier to to a fresh install and do a complete migration of the old MAs and then reinitialize. I still have an open case with MS

    but no solution for the legacy ECMA issues.

    Mike Welborn

    Wednesday, September 12, 2012 12:05 PM
  • After running into this at another customer, I'm now pretty sure that this is an issue in the installation package for Sync. The file Microsoft.MetadirectoryServicesEx.dll is NOT updated during patch (properly because it has the same version number even though it is never and MSI doesnt think that it needs updating). The previous file has version number and is dated Jan 28, 2012 whereas the new file also has version but is dated Aug 3, 2012. As far as I know MSIEXEC will only use version numbers and not timestamps when comparing (correct me if I'm wrong) and thus it will not update the file.

    After checking bindingRedirects and all other things, we manually extracted the new Microsoft.MetadirectoryServicesEx.dll from the CAB file and copied it to the Bin\Assemblies folder and things started working again. This is properly not supported by Microsoft, but it helped save the customers production environment for now - and we are going to move to R2 soon where I haven't seen this problem.

    Hope this helps.

    I'll write a short blog on this as soon (when I've validated the actions above) and when I get the time...

    Regards, Soren Granfeldt
    blog is at | twitter at!/MrGranfeldt

    Tuesday, October 02, 2012 8:20 AM
  • Don't know if you guys fixed this, but this helped me in a tight spot (

    Regards, Soren Granfeldt
    blog is at | twitter at!/MrGranfeldt

    Tuesday, October 02, 2012 7:04 PM
  • Jup - I will confirm this. Customer of mine went through this problem with PSS and actually there was few more files not updated by this update besides only Microsoft.MetadirectoryServicesEx.dll. 

    Tomek Onyszko, memberOf Predica FIM Team (, IdAM knowledge provider @

    Tuesday, October 02, 2012 9:30 PM
  • We had stopped-error problems in our environment after applying KB2737503 (version 4.0.3627.2). We followed your steps in the blog, and this solved the problem!

    Thank you so much!



    Friday, October 19, 2012 10:42 AM