locked
sync-rule-validation-parsing-error throw by FIM Management Agent RRS feed

  • Question

  • Hi all,

    I encounter the following error: sync-rule-validation-parsing-error

    Given by msdn to be: "Encountered an error while parsing/validating a synchronization rule."

    Well well well, not very clear

     

    I obtained this error just after I added the attribute to provision Exchange 2010 mailbox for Users.

    So this error is throw by the FIMMA when the sync engine is parsing my "AD Users Outbound SR".

    As documented I flow the following attribute : homeMDB, mailNickname, msDBUseDefaults, msExchMailboxSecurityDescriptor and msExchHomeServerName

    All values were chosen by editing attributes of an existing users's mailbox.

     

    So what I like to know is how I can debug this error to understand what is the cause of the parsing or validating error ?

     

    Regards,

    Fabrice

    Tuesday, June 29, 2010 10:00 AM

Answers

  • You can find a description of the attribute here.
    Security descriptors are stored as binary data by a directory service.

    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
    Monday, July 19, 2010 3:11 PM

All replies

  • Well,

    The error is coming with the attribute msExchMailboxSecurityDescriptor.

    Once this attribute is removed from the Outbound SyncRule, the user is correctly created and his mailbox too.

    So I assume the syntax was not correct, or maybe this attribute doesn't accept String values ?

    According to this guide: http://technet.microsoft.com/en-us/magazine/ff472471.aspx, we must provision this attribute to create a mailbox.

    I didn't need it.... So why ? And what is the exact role of this attribute ?

    Tuesday, June 29, 2010 10:52 AM
  • You can find a description of the attribute here.
    Security descriptors are stored as binary data by a directory service.

    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
    Monday, July 19, 2010 3:11 PM
  • Just for the record, today I noticed I was getting the sync-rule-validation-parsing-error status on a full sync preview of a CS object, and I was baffled as to why I was seeing this.  I had just completed the process of deleting and recreating a corrupted management agent, and had put in all of the sync rules - in my case these were non-declarative because of issues with the Notes MA not working with declarative :(.  Anyhow, they all looked fine and yet I still got this error.

    Turns out the reason was I had forgotten to delete a redundant SR in the FIM Portal and resync the FIM MA ... the old SR was still there with that lovely warning you get telling you what to do when your MA can't be found any more.  I deleted the SR, ran a delta import on the FIM MA and then a full sync ... and voila, no more error on preview.

    This post is for the benefit of anyone else (including me when I've long since forgotten this experience) running into a similar issue in the future.


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Thursday, August 23, 2012 6:03 AM
  • An error in any of the sync rules can also cause this issue.

    The solution is to delete all the sync rules from the metaverse by disconnecting their connector in the FIM MA connector space.

    Then re-import all the sync rules into the metaverse.


    Bahram

    Wednesday, March 27, 2013 12:55 AM
  • An error in any of the sync rules can also cause this issue.

    The solution is to delete all the sync rules from the metaverse by disconnecting their connector in the FIM MA connector space.

    Then re-import all the sync rules into the metaverse.


    Bahram

    This solved our problem!
    Wednesday, January 21, 2015 10:07 AM
  • Thank you! This would be more-or-less my scenario. Recreated an MA in my test system to fix a different system, and didn't recreate the Sync Rule that went with it.

    Tuesday, January 19, 2016 6:14 PM