FIM 2010 (not R2), OLSync and rollup 4.0.3627.2. RRS feed

  • Question

  • Hi folks,

    I'm reasonably certain I'm going to have to resort to lodging a PSS call for this, but I figured I'd ask here anyway. Also, this has nothing to do with the portal as we don't use it; only the synchronisation service.

    I'd like to know if anyone is running FIM 2010 (not R2), provisions to the Microsoft Live@EDU (or Office 365) space and has had "stopped-server" issues after applying rollup 4.0.3627.2 (as per this KB article This question is the main point of the post, but I'll quickly cover the issue on the off-chance someone has seen this and may have resolved the issue.

    We had the issue described in "Issue 4" of "0 is not a valid DN depth" in our AD MA. We were "working around" this by manually restarting the synchronisation service, after which it would work for one pass then subsequently fail until the next manual restart.

    So, with that in mind, we applied the rollup and it worked a treat: we now don't have any issues with the AD MA stopping in any of the scheduled multiple runs per day. However, the rollup seems to have created an issue with the Outlook Live Management Agent (OLSync R4) in that it will no longer even start anything that involves talking to the external service.

    What I've tried thus far is resetting the password in both the connection and password reset dialogs in the MA along with checking the application log in Event Viewer to no avail. All I get is a "this MA did not work" error, which I kind of already figured out. I did take the time to verify that the account details were still working outside of FIM using the following steps:, but as expected, the account connected just fine leaving me to believe whatever the error is isn't related to the credentials themselves.

    I also checked the database permissions but couldn't find anything amiss. An SQL Server Profiler session also seemed to confirm that access wasn't an issue.

    My gut feeling is it's either a .NET configuration change (such as in a manifest) or an outright problem with the OLMA .dll.

    That's the short version. Given there is no logging to consult and the Event Viewer information sheds no light on the matter, I'll likely look to engage PSS or rebuild the server, not apply the rollup and simply live with the ongoing AD MA failure. This one feels very much out of my hands to investigate.

    As a side note, I'm not particularly interested in posting this on as that's never really borne fruit. If people don't know here, then I may as well head straight to PSS.


    Monday, September 17, 2012 9:46 AM


  • No progress was made determining what the actual issue was, so I simply reverted to the sledgehammer approach by removing and re-installing FIM, the OL MA and our rule extension and provisioning DLLs. Below is a direct copy-and-paste from the closing comments of our Live@EDU support incident.

    Hopefully we don't see a repeat of the AD MA issue that caused the knock-on fault to come about as I didn't really learn anything about the specific root cause.


    The detailed steps I ended up following were:

      •        Export the server configuration.
      •        Uninstall the FIM Synchronisation Service (we don’t use the portal).
      •        Backup and remove the database from the remote SQL Server.
      •        Remove the directory structure that FIM had been installed to.
      •        Reboot the FIM server.
      •        Re-install the FIM Synchronisation Service.
      •        Stop the FIM Synchronisation Service service.
      •        Apply KB2502631.
      •        Restart the server.
      •    Stop the FIM Synchronisation Service service.
      •    Apply KB 2688078.
      •    Restart the server.
      •    Extract the OL MA files (version
      •    Use xcopy /d /e /h  to copy the contents to Extensions, SourceCode and UIShell.
      •    Copy our custom rule extension DLLs into Extensions.
      •    Imported the previously exported server configuration.
      •    Run “full import” cycles across all MAs.
      •    Run “synchronise” cycles across the MAs, starting with the MAs responsible for provisioning into the metaverse, followed by those that simply join.

    • Marked as answer by Lain Robertson Thursday, September 20, 2012 7:54 AM
    • Edited by Lain Robertson Thursday, September 20, 2012 7:59 AM Added a step I missed from the e-mail.
    Thursday, September 20, 2012 7:53 AM