none
GALSync (FIM 2010R2) trying to stamp mail-enabled contacts with groupType RRS feed

  • Question

  • "Smarter than me" folks,

    I've configured GALSync between two forests. Fairly basic setup, with the mainly OOB settings. Exchange cross-forest settings:

    Error during the Delta Sync (I run a Delta Import (Stage Only) -> Delta Sync -> Export -> Delta Import (Stage Only), but the same errors occur during a Full Import, Full Sync. Error occurs on mail-enabled group objects as contacts only. (Needless to say, contact objects don't have a groupType attribute, so it makes sense.)

    Stack trace:

    And, the output from the extension-attribute-not-present below (obviously, clicking the Stack Trace button gives the above)

    Looking at the GALSync GALMA.vb source, lines 303 and 1032:

    303 and associated lines:

     
    Case "msExchMasterAccountSidMappingForwards"
          EAFmsExchMasterAccountSidForwards(csentry, mventry)

    1032 and associated lines (Sub referenced above):

     Private Sub EAFmsExchMasterAccountSidForwards(ByRef csentry As CSEntry, ByRef mventry As MVEntry)
    
                ' Variables
                Dim uac As Long
    
                ' Clear master account history
                csentry.Item(MASTER_ACCOUNT_SID).Delete()
    
                ' Only security mv group object result in stamping of resulting contact when dealing with GROUPS
                Dim MAConfig As GALMA = FindMA(csentry)
                Dim isTrustEnabled As Boolean = MAConfig.XFDelegation
                If (isTrustEnabled AndAlso mventry.ObjectType.Equals(GROUP) AndAlso mventry(OBJECT_SID).IsPresent) Then
    Offending line->Dim isSecurityGroup As Boolean = (mventry.Item(DISTRIBUTION_GROUP_TYPE).Value And SECURITY_GROUP_TYPE_CODE) = SECURITY_GROUP_TYPE_CODE
                    If isSecurityGroup AndAlso mventry.Item(MAIL_NICKNAME).IsPresent Then
                        csentry(MASTER_ACCOUNT_SID).Value = mventry(OBJECT_SID).Value
                    End If
                End If

    I SUSPECT that there needs to be a decision made to NOT attempt to stamp the contact object, but I'm not sure how to differentiate between when to allow it and when not to, or how to detect 'contact' versus a real group.. Knowing full well that the GALSync is really a fancy (or not so fancy) ADMA, the code obviously believes it can do things that it can't. Such as forcing a groupType attribute on a contact object.

    Interested in any input from the SmartFolk(tm) here.

    Thank you in advance!


    Rick Lync Server UA

    Thursday, February 22, 2018 2:35 PM

Answers

  • Then I would say something is wrong with the code on the import attribute flow for group type. I suggest debugging it to see what is happening

    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    Friday, February 23, 2018 6:56 PM

All replies

  • Hey Rick-

    If you look at the metaverse object for this group, I assume the groupType attribute is null? Is it populated upstream on the source object?


    Thanks,
    Brian

    Consulting | Blog | AD Book

    Thursday, February 22, 2018 9:41 PM
    Moderator
  • Rick,

    Brian has pointed you at the likely path to follow to the solution. Allow me to explain a little. If the source object is a mail-enabled security group then it wants to set the MasterAccountSID on the destination contact object.

    So while this piece of code trips the exception the problem is really on the import flow side.

    Does this error happen for a lot of groups or just a handful?

    David


    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    Friday, February 23, 2018 5:15 PM
  • David, Brian;  (Hey Brian - long time, no talk!)

    LOTS of groups - on both forests, needed to extend the error count to 10000 just to complete runs.

    Thanks, guys!


    Rick Kingslan - Jack-of-all-trades Infrastructure Engineer/Architect

    Friday, February 23, 2018 6:47 PM
  • Brian,

    Yes - groupType is null. Source object on all that are complaining do have a groupType attribute populated.

    Rick


    Rick Kingslan - Jack-of-all-trades Infrastructure Engineer/Architect

    Friday, February 23, 2018 6:49 PM
  • Then I would say something is wrong with the code on the import attribute flow for group type. I suggest debugging it to see what is happening

    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    Friday, February 23, 2018 6:56 PM
  • David,

    Thank you. I'll go back and review this. I need to grok the import attribute workflow and figure out what is being applied, and where.

    (FIM is my part time job - after all of AD, ADFS, Orchestrator, SCCM, PowerShell, Architecture, and general cat-herding! I'll muddle through this, but if you have a debugging tip or two - I'd gladly accept. And - if we can get this figured out, I'll buy your book.

    I'll probably buy it anyway. I like supporting our SmartFolk and I think Brian can attest to my support in the past. Me - Directory Services MVP, 2003 - 2005 until hired by MSFT into MCS and on to the Lync Product Group)


    Rick Kingslan - Jack-of-all-trades Infrastructure Engineer/Architect

    Saturday, February 24, 2018 2:57 PM