none
Issue with asymmetrical attribute flow and delta sync

    Question

  • I am seeing an interesting behavior with the sync engine and I am not sure if it is a bug or a feature.

    I have a situation where a user created in the FIM Service may or may not have a user-assigned AD account name. If an account name is specified I need to use the specified name, otherwise I need to generate an account name for the person.

    My solution is to have an optional “Account Name Requested” attribute in the FIM Service that when specified is used as the account name during provisioning (and later in synchronization to handle account name changes).

    The native “Account Name” attribute in the FIM Service contains the actual account name in AD and is not editable by the user.

    My setup is:

    • In the FIM Service, I have AccountName and AccountNameRequested
    • In the Sync engine, I have the same attributes.
    • On the FIM MA:
      • AccountNameRequested flows from the FIM MA to the Sync engine.
      • AccountName flows from the Sync engine to the FIM MA
    • On the AD MA:
      • AccountNameRequested flows out to sAMAccountName if AccountNameRequested has a value (via a rules extension)
      • sAMAccountName flows in to AccountName
    • Provisioning code uses the value for AccountNameRequested if it is present; otherwise, it generates an account name.

    Provisioning works properly.

    The issue is when an account name needs to be changed: A user updates the Account Name Requested attribute in the FIM Service. It flows properly to the sync engine and it flows out to sAMAccountName in AD. The following confirming delta import shows the update to sAMAccountName as applied in AD. Unfortunately, the delta import (containing the change in AD) is not recognized as a delta, so a subsequent delta sync does not process the record (and does not flow the new value for sAMAccountName back into the AccountName attribute in the metaverse.) A full import will properly flow the sAMAccountName back in from AD.

    So the question is: If in the metaverse you have attribute A that flows outbound to attribute B in a connected directory and that same attribute B in the connected directory also flows inbound to attribute C in the metaverse, should a change in attribute A that is exported to B and successfully imported back from B be considered a delta change in the connector space so that a subsequent delta sync flows B into C?

    If the answer to the above is “Yes, it should be considered a delta”, then I need to open a support case, otherwise it is a “feature” and I need to solve the problem another way (probably by having workflow reach out directly to AD, which I would prefer not to do.)

    Thanks,

    Rex
    Monday, April 07, 2014 10:55 PM

Answers

  • I reported this very issue in a Premier Support call a couple of years ago.  They acknowledged the change in product behavior from ILM to FIM (though I'm not sure they labelled it a "bug") and credited our hours back, but said they were close to a release (perhaps R2?) and it would be fixed later.  To my knowledge it has not been resolved but I haven't read up on or tried every hotfix.  It is definitely "new behavior" starting with FIM 2010 RTM.

    The workaround I have found is that any time I am re-importing a value to the metaverse that I export, the import must be written as a Rule Extension (it can be as simple as mventry("attribute").Value = csentry("attribute").Value) and the attribute precedence for the attribute set to manual in Metaverse Designer...even if AD (or whatever source) is the only source for the attribute.  That seems to cause FIM to process the import and sync correctly during a delta operation.

    My personal theory is that this became "broken" in the code when they introduced the mechanism for equal precedence, and that may be why it is going away (if I remember correctly).

    Chris


    • Proposed as answer by Chris Clayton - STLCC Wednesday, April 09, 2014 3:57 PM
    • Edited by Chris Clayton - STLCC Wednesday, April 09, 2014 4:26 PM Microsoft may not have actually used the word "bug" so I reworded my statement.
    • Marked as answer by Rex Wheeler Wednesday, April 09, 2014 5:48 PM
    Wednesday, April 09, 2014 3:57 PM

All replies

  • I've seen this behaviour as well. It used to work correctly in MIIS and ILM, so looks like some optimisation is at work now which breaks it.
    Tuesday, April 08, 2014 8:53 AM
  • Thanks. I could have sworn that this used to work "back in the day". Now the question is if the current behavior is considered correct or if it is a bug.
    • Edited by Rex Wheeler Tuesday, April 08, 2014 7:49 PM grammar
    Tuesday, April 08, 2014 7:49 PM
  • I reported this very issue in a Premier Support call a couple of years ago.  They acknowledged the change in product behavior from ILM to FIM (though I'm not sure they labelled it a "bug") and credited our hours back, but said they were close to a release (perhaps R2?) and it would be fixed later.  To my knowledge it has not been resolved but I haven't read up on or tried every hotfix.  It is definitely "new behavior" starting with FIM 2010 RTM.

    The workaround I have found is that any time I am re-importing a value to the metaverse that I export, the import must be written as a Rule Extension (it can be as simple as mventry("attribute").Value = csentry("attribute").Value) and the attribute precedence for the attribute set to manual in Metaverse Designer...even if AD (or whatever source) is the only source for the attribute.  That seems to cause FIM to process the import and sync correctly during a delta operation.

    My personal theory is that this became "broken" in the code when they introduced the mechanism for equal precedence, and that may be why it is going away (if I remember correctly).

    Chris


    • Proposed as answer by Chris Clayton - STLCC Wednesday, April 09, 2014 3:57 PM
    • Edited by Chris Clayton - STLCC Wednesday, April 09, 2014 4:26 PM Microsoft may not have actually used the word "bug" so I reworded my statement.
    • Marked as answer by Rex Wheeler Wednesday, April 09, 2014 5:48 PM
    Wednesday, April 09, 2014 3:57 PM
  • Thanks Chris. That workaround is working for me.

    I ended up using:

    if (mventry["accountName"].IsPresent)
       {
          if (mventry["accountName"].Value != csentry["sAMAccountName"].Value)
             {
                 mventry["accountName"].Value = csentry["sAMAccountName"].Value;
             }
       }
    else
       {
          mventry["accountName"].Value = csentry["sAMAccountName"].Value;
       }

    so that the flow statistics didn't show an inbound flow for every record.

    Luckily in this case my only flow that has this issue only has a single source (AD). If I had a value also coming in from the FIM MA, I would not be able to use manual precedence because of the "no rules extensions" on the FIM MA thing.

    If anyone from the product group is reading this, please please please consider letting us put rules extensions on the FIM MA (or have some other solution to specify manual precedence when the FIM MA is involved.) - Also please fix this bug / change in behavior...

    Rex

    Wednesday, April 09, 2014 5:48 PM