none
Which table/column holds the connector space object data for a disconnector? RRS feed

  • Question

  • I've been burrowing around the FIMSynchronizationService database looking to surface some info found in the UI with some success but I've hit a stumbling block: I can't find the actual connector space object data, such as sAMAccountName, displayName or objectSid.

    For example, I have an ambiguous-import-flow-from-multiple-connectors on my AD LIVE MA. In the Synchronization Service Manager, if I click on the link for one of these objects (CN=XT1002, OU=XT Users, OU=...) I get three tabs: Import, Synchronization Error and Lineage.   For some of these, I can find data in the mms_connectorspace table.  E.g. from the Lineage tab, I can find 'Last import change' (as last_import_modification_date); from the Synchronization Error tab, I can find data such as Object Type (as object_type), Initial occurrence (as initial_import_error_date) and, by converting the xml-as-a-string column import_error_detail to an XML column and using XQueries, I can get the Synchronisation step (as algorithm-step) and the DN of the object.  But I can't find the data shown on the Import tab.  Can anyone help?

    Monday, December 17, 2012 1:06 PM

Answers

  • AFAIK CS objects are stored as blobs in the tables. And I'm pretty sure that changing stuff in the database is supported. There are some WMI interface that you could maybe use to peek into the CS or some of the old commandline tools such as csexport that you'd maybe find useful.

    Regards, Soren Granfeldt
    blog is at http://blog.goverco.com | twitter at https://twitter.com/#!/MrGranfeldt

    Monday, December 17, 2012 1:11 PM
  • I think Søren meant to say changing things in the database is "unsupported".  :-)  And he is right about the connector space being stored as a blob.  That is the reason that "forward joins" are not possible during synchronization on another MA.

    For the case of your ambiguous-import-flow-from-multiple-connectors error, if you use the Preview feature to see what a full or delta sync does, it should indicate the metaverse object that it is trying to join to.  Based on that error, it seems you have another AD LIVE MA connector to that metaverse object already, and given a second the sync engine does not know which to flow in metaverse attribute values from.

    Chris

    Monday, December 17, 2012 5:48 PM
  • The format of the blob isn't documented AFAIK.

    You can use the WMI classes to make a remote connection and grab connector space data - that might be part of your strategy.


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Monday, December 17, 2012 7:57 PM
    Moderator

All replies

  • AFAIK CS objects are stored as blobs in the tables. And I'm pretty sure that changing stuff in the database is supported. There are some WMI interface that you could maybe use to peek into the CS or some of the old commandline tools such as csexport that you'd maybe find useful.

    Regards, Soren Granfeldt
    blog is at http://blog.goverco.com | twitter at https://twitter.com/#!/MrGranfeldt

    Monday, December 17, 2012 1:11 PM
  • I think Søren meant to say changing things in the database is "unsupported".  :-)  And he is right about the connector space being stored as a blob.  That is the reason that "forward joins" are not possible during synchronization on another MA.

    For the case of your ambiguous-import-flow-from-multiple-connectors error, if you use the Preview feature to see what a full or delta sync does, it should indicate the metaverse object that it is trying to join to.  Based on that error, it seems you have another AD LIVE MA connector to that metaverse object already, and given a second the sync engine does not know which to flow in metaverse attribute values from.

    Chris

    Monday, December 17, 2012 5:48 PM
  • Yes, I assumed as much and had no intention of changing anything.

    The issue is that we don't allow people to log onto servers, in general, but there's no client UI for the Sync Service.  We see errors like this a lot (legacy - best not to go there) so I am looking for a way to surface them to the support teams.  I'm trying to provide a screen which will show the error in FIM and the related objects and allow them to fix the source data.

    The join rules aren't complex so I can use the DN from the xml to retrieve the CDS object from the source and then work out which MV-object is the target but I would have preferred to use the CS-object data rather than fetch it from the CDS as some CDSs are remote and a bit slow.

    I suppose the BLOB format is secret?

    Monday, December 17, 2012 6:39 PM
  • The format of the blob isn't documented AFAIK.

    You can use the WMI classes to make a remote connection and grab connector space data - that might be part of your strategy.


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Monday, December 17, 2012 7:57 PM
    Moderator
  • I'll look into that, thanks.
    Tuesday, December 18, 2012 8:45 AM
  • Thanks, Chris..

    Yes, I did mean unsupported :-) Wrote it early in the morning (on a train) - FYI here's a link with some probably old doc on csexport (http://technet.microsoft.com/en-us/library/jj590346(v=ws.10).aspx)


    Regards, Soren Granfeldt
    blog is at http://blog.goverco.com | twitter at https://twitter.com/#!/MrGranfeldt

    Tuesday, December 18, 2012 11:35 AM