none
FIM Delta Import/Delta Sync not syncing attribute to Metaverse RRS feed

  • Question

  • Feel free to offer better ways to accomplish this task.

    Single metaverse; mv_person

    3 MAs:

    - DIDS from SQL

    imports cs:userPrincipalName -> mv:userPrincipalName

    - Export & DIDS to o365,

    exports mv:userPrincipalName -> cs:userPrincipalName

    imports cs:userPrincipalName -> mv:audit_userPrincipalName

    - Export to SQL audit

    exports mv:audit_userPrincipalName -> cs:audit_userPrincipalName

    Data flows from SQL source to o365 perfectly. o365 delta import sees the data change but does not sync the data to the metaverse. Generating a full preview works as expected. From everything I've read, I would expect a DI DS to change the data in the metaverse? 

    Running a full sync catches the change and things flow as expected.

    Wednesday, August 7, 2013 4:33 PM

All replies

  • Are you doing o365 DI and DS steps separately in the run profile or that's a single DIDS?
    Tuesday, August 20, 2013 11:31 AM
  • The O365 CS object userPrincipalName doesn't change on the confirming DIDS, therefore there will be no attribute flow during the DS portion. Or have I lost the plot?


    Dave Nesbitt | Architect | Oxford Computer Group

    Tuesday, August 20, 2013 11:51 AM
  • Yes. I've also tried a DIDS in a single step to enlarge the hologram scope. No luck. Also, my userPrincipalName IS changing on the CS, which is exactly why I'd expect it to toggle a delta sync on the CS object.

    I also have confirmation from another source that MS is aware of my bug and working on it.

    <quote>

    if FS preview works and DS preview doesn't work, and the imported delta was created by an export from this ma, then this is a problem I've seen before, which was introduced with FIM (used to work fine in ilm etc) - basically, it seems to assume that because the delta went out through this ma, then it doesn't need to flow it back into the metaverse.

    This is a problem if you are flowing the delta back into an mv attr other than the one it flowed out of, for example to confirm the change has been applied.

    so, for example, if you construct a upn on outbound flow, then want to flow in it from ad and onto some other system, this is not possible. A workaround is to construct the upn on inbound flow from another system, and then simultaneously flow it out to ad and the third system. However, I don't think this is a nice approach, and I'm sure there are other scenarios where it is bad.

    it has been reported to the product group, but not via pss - if you can, do.

    </quote>

    Tuesday, August 20, 2013 1:51 PM
  • Understand you have run into a bug here, but what is wrong with importing a totally different user property from O365 that has something that's generated from the O365 directory itself (e.g. objectSID or suchlike - since AzureAD is supposed to be ADLDS), since you already have the userPrincipalName in the MV and what is being imported will never be any different right?

    The MV source for your EAF to your cs:audit_userPrincipalName would essentially be "IIF(IsPresent(MV.O365-only-attr),userPrincipalName,null())".


    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

    Tuesday, August 20, 2013 3:02 PM
  • I'm not sure I follow.

    How would importing the SID cause a delta sync on a specific unrelated attribute? My syncs process the CS object fine, they just ignore the individual attribute.

    Tuesday, August 20, 2013 6:00 PM
  • I can confirm from experience that FIM does not trigger attribute flows or provisioning based on confirming an attribute it exported as part of a delta sync--you've gotta run a full sync to get the dependent flows to fire.

    This may not have always been the case... sometime in the last two-ish years maybe, I'm assuming someone "optimized" that small facet of the sync engine.


    Steve Kradel, Zetetic LLC

    • Proposed as answer by UNIFYBobMVP Thursday, August 13, 2015 11:52 AM
    Tuesday, August 20, 2013 9:29 PM
  • Anyone have any updates on this? I'm still hitting the issue on FIM Sync Service 4.1.3496.0.
    Wednesday, December 4, 2013 6:24 PM
  • I have since found that there is a work-around that never fails here - convert your direct flow into either a sync rule expression or an advanced attribute flow (rules extension) and the delta sync will work.  Definitely a bug that needs fixing, but this is the work-around I have successfully used on many occasions now.

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

    • Proposed as answer by UNIFYBobMVP Thursday, August 13, 2015 11:54 AM
    Thursday, August 13, 2015 11:54 AM
  • I have since found that there is a work-around that never fails here - convert your direct flow into either a sync rule expression or an advanced attribute flow (rules extension) and the delta sync will work.  Definitely a bug that needs fixing, but this is the work-around I have successfully used on many occasions now.

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

    Agreed, that has worked for me elsewhere.

    However, this is a Microsoft-packaged connector for Office365. I cannot modify their code to implement a sync rule. 

    Thursday, August 13, 2015 2:28 PM
  • Wow - then I'd say that it's time for a PSS call to get this bug fixed once and for all.  In fact I think the issue has already been logged and might just need an enquiry as to its status.  Sometimes bugs like this hang around because we come up with work-arounds to get by :).

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

    Thursday, August 13, 2015 2:31 PM
  • Just seen you're in Washington ... maybe you should pop down to Redmond and sort this out face to face? ;)

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


    • Edited by UNIFYBobMVP Thursday, August 13, 2015 2:36 PM
    Thursday, August 13, 2015 2:35 PM
  • Washington University in St. Louis (Missouri).

    Unfortunately, it takes more time to call and get the case rolling than I'd like to spend. I already worked around the problem by adding another MA to validate these fields. It's been running in production since 2013, so no reason to fix it now.

    At this point, I'm just waiting for MIM to fix all my problems. :)

    Thursday, August 13, 2015 2:50 PM
  • Ah - wrong Washington!  What would an Aussie know anyhow - and yes, I empathise on the time it takes.  You really should join our monthly www.thefimteam.com user group (rename pending!) since you're an old hand at this beast.

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

    Thursday, August 13, 2015 2:56 PM
  • Hello people 

    Can any one answer this please.

    https://social.technet.microsoft.com/Forums/en-US/04699a70-1da4-426e-b680-ffe28d005b36/delta-syncs-do-not-bring-the-deltas-in-the-metaverse-hence-not-triggering-provisioning-code?forum=ilm2

    Is this an issue with MIM 2016 as well ?

    Delta Sync do not update the attributes and hence does not fire the provisioning code.

    Monday, August 26, 2019 2:44 AM