Delta Import and Delta Sync on AD MA, the userAccountControl direct import attribute flow is not updating in the Metaverse
Hi All, I am using FIM Sync 2010 v4.0.25920.0 This is for a single Metaverse object type, eg mv_person. For AD MA, I have a “Direct” import attribute flow of userAccountControl to a number type mv_userAccountControl in the Metaverse. This is the only MA that flow to the mv_userAccountControl attribute in the Metaverse for the object, thus precedence is not an issue. I have an Advanced Export Attribute Flow rule on the AD MA to set the value of userAccountControl to an appropriate value, eg 514. The result of this sync is an Export Attribute Flow on the AD MA. After an Export followed by Delta Import and Delta Sync on the AD MA the changed userAccountControl value is not update in the Metaverse. In the preview mode the Delta Sync’s Import Attribute Flow page it indicated the Final Value is Unchanged. In the preview mode the Full Sync’s Import Attribute Flow page the Final Value is changed correctly. (That is the mv_userAccountControl attribute is only update when a Full Sync is applied) I have the following setup and flow sequence: 1 – Advanced Export Attribute Flow rule extension on AD MA to set the csentry for the userAccountControl value to a new value (eg 514 – the value would change from 512 to 514) 2 – Performed Export on AD MA 3 – Performed Delta Import and Delta Sync on AD MA. The new userAccountControl value (514) is not flow to the mv_userAccountControl in the Metaverse. The expected behaviour is after step 3 the mv_userAccountControl value should be 514. I am not certain if this is a FIM bug or the used the "_" character in the attribute name and in the extended person object is not support or I am missing something else. The current work-around I have is the add an Advanced Import Attribute Flow rule to simply set the userAccountControl attribute value to the mv_userAccountControl value. Thank you in advance for your help.
February 15th, 2011 10:07pm

Just chiming in here ... Shane changed the flow from DIRECT to ADVANCED so that we could try to trap the sync process in a debug session, so this "work-around" was really discovered by accident. What concerns me here, apart from the delta sync not giving the expected result (updating the MV with a direct flow when there is an obvious difference in value detected between the ONLY authoritative CS connector and the MV attribute - which I believe to be a bug) is that Shane has now proven that there is a difference in behaviour between a DIRECT attribute flow and an ADVANCED attribute flow whereby the net result should be identical (another bug, or is the above bug just with direct flows I wonder?). Very keen to hear of any other similar experiences, or arguments as to why the above observations somehow make any sense at all to anyone :). Seeing this behaviour kind of makes you question the most fundamental principles of the sync engine ... and I found I had to reassure myself by re-reading the following (ancient MIIS principles!) KB827118 which confirmed (to me at least) that I'm not getting the "wrong end of the stick" here.Bob Bradley, www.unifysolutions.net (FIMBob?)
Free Windows Admin Tool Kit Click here and download it now
February 15th, 2011 10:35pm

Bob, Shane, Did you check for the export attribute flow precedence. More info here: About Attribute Flow Precedence Just a sanity check, did you run a full sync on the MA after making changes to the attribute flows? Do you see the attribute exported to AD, do you see it set in AD (verifying via AD tools)? What is the import run profile statistic showing you? Do you see the update popping up in the import statistics? Is the system behaving the same if you use another attribute (without the underscore)? Kind regards, PeterPeter Geelen (Traxion) - Sr. Consultant IDA (http://www.fim2010.be) [If a post helps to resolve your issue, please click the "Mark as Answer" of that post or "Helpful" button of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]
February 16th, 2011 6:30am

Peter - thanks for replying. We're not using the portal, so export attribute flow precedence isn't a factor I believe. Yes - full sync (both MAs) done before any flows. Export was successful - have to admit I didn't check the value in AD, just went on the 514 in the CS. Will check, but not expecting this to lie. Yes the (delta) import attribute change shows up as a mod to userAccountControl (512->514). We were going to try using another attribute without an underscore - until Shane discovered that the advanced flow rule did the trick ... not sure if Shane actually got around to that test (MV attribute without an underscore). Shane??? Again - thanks.Bob Bradley, www.unifysolutions.net (FIMBob?)
Free Windows Admin Tool Kit Click here and download it now
February 16th, 2011 6:40am

Hi Peter, Replying to Peter, in addition to Bob's reply. Yes I have verified, using AD Tool on AD that the change occurred. I have also tried a Direct flow the userAccountControl to mvUserAccountControl with the same result - attribute not update. When I two IAF rule for userAccountControl for AD MA: userAccountControl --> Direct --> abcUserAccountControl - no update in Metaverse userAccountControl --> Advanced --> mv_UserAccountControl - update in the Metaverse occurred. Thank you.
February 17th, 2011 5:47pm

Hi, I currently facing the same problem with a declarative Rule declared in the FIM Portal. The userAccountControl is well exported in Active Directory. The User Account is disabled and the userAccounControl has moved to 514 (512 originally). During the Delta Import, imported value is 514 but delta synchronisation for AD MA does not update the metaverse object for userAccountControl attribute. I notice the same behavior, the value is only up-to-date after a full synchronization of the AD MA. My attribute is named userAccountControl in metaverse and it is declared as Number and single-value. It should not be a problem with the attribute flow precedence (the only input attribute flow for this attribute is the AD MA). Have you find how to correct the problem or a workaround for this behavior? Thanks in advance. Regards. H.
Free Windows Admin Tool Kit Click here and download it now
March 8th, 2011 7:04am

Hi, I currently facing the same problem with a declarative Rule declared in the FIM Portal. The userAccountControl is well exported in Active Directory. The User Account is disabled and the userAccounControl has moved to 514 (512 originally). During the Delta Import, imported value is 514 but delta synchronisation for AD MA does not update the metaverse object for userAccountControl attribute. I notice the same behavior, the value is only up-to-date after a full synchronization of the AD MA. My attribute is named userAccountControl in metaverse and it is declared as Number and single-value. It should not be a problem with the attribute flow precedence (the only input attribute flow for this attribute is the AD MA). Have you find how to correct the problem or a workaround for this behavior? Thanks in advance. Regards. H.
March 8th, 2011 7:04am

No there's no fix yet - not to my knowledge anyhow. I'll check with Shane ... sounds like we need to submit a bug report ... Thanks for posting your response as it adds weight to the investigation. Bob Bradley, www.unifysolutions.net (FIMBob?)
Free Windows Admin Tool Kit Click here and download it now
March 8th, 2011 7:07am

No there's no fix yet - not to my knowledge anyhow. I'll check with Shane ... sounds like we need to submit a bug report ... Thanks for posting your response as it adds weight to the investigation. Bob Bradley, www.unifysolutions.net (FIMBob?)
March 8th, 2011 7:07am

Hi halmix, The current work-around I use is the add an Advanced Import Attribute Flow rule to simply set the userAccountControl attribute value to the mv_userAccountControl value. This involve writing the classic custom code, the MA rule extension for IMASynchronization.MapAttributesForImport(...) method. A snipped of the custom code is: void IMASynchronization.MapAttributesForImport(string flowRuleName, CSEntry csentry, MVEntry mventry) { switch (flowRuleName) { case "UserAccountControlIAFRule": if (csentry["userAccountControl"].IsPresent) { mventry["mv_userAccountControl"].Value = csentry["userAccountControl"].Value; } break; default: // TODO: remove the following statement and add your default script here throw new EntryPointNotImplementedException(); } } Cheers, Shane Lim
Free Windows Admin Tool Kit Click here and download it now
March 8th, 2011 6:09pm

Hi Shane, Thank you for this information. My need was to identify the status of an AD account (enabled/disabled). I finally use a custom Expression in my attribute flow to force FIM to re-evaluate the value and it seems it works. Regards, H.
March 10th, 2011 9:52am

I'm experiencing the same problem: Declarative inbound attribute flow (AD Sync Rule) in Portal, userAccountControl -> userAccountControl (Number) Sync Engine Attribute Flow, Direct, MetaverseAttribute userAccountControl export -> userAccountControl (Portal Attribute, Integer) The user account is disabled in AD, the Delta Import step from AD shows the change of userAccountControl from 512 to 514. A Delta Sync re-applies the existing sync-rule-mapping and changes the userAccountControl back to 512 while staging nothing to export to the Portal. A full sync stages the 514 to the Portal. Halmix can you explain more about "I finally use a custom Expression in my attribute flow to force FIM to re-evaluate the value and it seems it works"?
Free Windows Admin Tool Kit Click here and download it now
March 26th, 2011 12:45am

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

Other recent topics Other recent topics