FIM Delta Import/Delta Sync not syncing attribute to Metaverse

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.

August 7th, 2013 4:33pm

Are you doing o365 DI and DS steps separately in the run profile or that's a single DIDS?
Free Windows Admin Tool Kit Click here and download it now
August 20th, 2013 11:31am

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?

August 20th, 2013 11:51am

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>

Free Windows Admin Tool Kit Click here and download it now
August 20th, 2013 1:51pm

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())".

August 20th, 2013 3:02pm

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.

Free Windows Admin Tool Kit Click here and download it now
August 20th, 2013 6:00pm

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.

August 20th, 2013 9:29pm

Anyone have any updates on this? I'm still hitting the issue on FIM Sync Service 4.1.3496.0.
Free Windows Admin Tool Kit Click here and download it now
December 4th, 2013 6:24pm

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.
August 13th, 2015 7:56am

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 occa
Free Windows Admin Tool Kit Click here and download it now
August 13th, 2015 10:30am

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 :).
August 13th, 2015 10:33am

Just seen you're in Washington ... maybe you should pop down to Redmond and sort this out face t
Free Windows Admin Tool Kit Click here and download it now
August 13th, 2015 10:37am

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. :)

August 13th, 2015 10:52am

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.
Free Windows Admin Tool Kit Click here and download it now
August 13th, 2015 10:58am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics