FIM 2010 R2 Full Sync on FIM MA gives lots of unexpected errors RRS feed

  • Question

  • Hi,

    We recently upgraded to FIM 2010 R2 SP1 and after upgrading, ran a Full Import, Full Sync on FIM MA.

    Most of the objects in the metaverse have 3 sync rules in the EREs. When we did the Full Sync on FIM MA after upgrading to SP1, it gave us a lot of errors "ma-extension-error". On clicking on the error, we can see that 1 of the sync rules in the ERE is now failing to apply because one of the attributes it must export to the connected data source is null. This is correct behaviour.

    However, what is happening is that it the Full Sync is also changing the status for the other 2 sync rules from "Applied" to "Not Applied" when those two have nothing to do with the attribute that is missing for the 3rd sync rule.

    We did not have this behaviour in the previous installation of FIM 2010.

    Can anyone shed some light on this? we performed an "in-place"upgrade to FIM 2010 R2 SP1.

    Any tips/help would be greatly appreciated. 

    Sunday, May 11, 2014 2:16 PM

All replies

  • Hi,

    I thought I'd add some more information regarding this.

    The problem seems to be  a null (or missing) value for an attribute in the Metaverse. This attribute is "department"

    For 2,000 odd objects, the department attribute was changed from an actual value to null a few years ago. These objects had 3 EREs in their ERL. 1 out of these EREs had a sync rule that exported " 'department' + <a constant string>" to a connected source. For 2 years, this was not a problem.

    However, when I upgraded to R2 SP1 over the weekend, on doing a full sync, FIM Sync started throwing "extension-dll-exception" and complaining about "object reference not set to an instance of an object". Clearly the way concatenation with "null" values has changed in R2 SP1, but I didn't see a mention of that in release notes (or maybe I saw in the wrong place).

    Either way, it throws these 2000 errors and has changed the ERE from Applied to Not Applied.

    For 1 ERE that deals with the sync rule containing "department", it is correct to change "Applied" to "not Applied". What I don't get is why is it changing the other 2 EREs (which are not dealing with department) from Applied to Not Applied too ? Is this behaviour correct ? Something new in R2 SP1 (because this did not happen in the earlier release)

    I'd really appreciate some insight into this. Happy to provide more details / information.


    Tuesday, May 13, 2014 9:35 AM
  • You may be able to get around this by updating your attribute flow with a custom expression to check the existence of department before flowing it out. Something like:

    IIF(IsPresent(department),department+"<Constant String>",Null())

    Friday, May 16, 2014 12:46 AM
  • Hi Cameron,

    Thanks for taking the time to reply to this. 

    My question was more about why this behaviour is happening after the upgrade and not so much about the solution (thanks for that though). I did get rid of the sync rule error by flowing a constant value to department in case it is missing in the metaverse.

    However, I wanted to know why the other EREs are being changed to "Not Applied" when the ERE for department is not applied. Like I said, my data hasn't changed so this behaviour must be something to do with the upgrade.

    Friday, May 16, 2014 8:16 AM
  • Hi

    what happened to the value of "Department" in the metaverse after your upgrade? I can't think of they were deleted during the upgrade procedure. I would look at the precedence definition in metaverse designer and then at the Imports that are run after the upgrade.


    Friday, May 16, 2014 1:53 PM
  • Hi Henry,

    That's exactly what I stated - nothing happened to the data. The value of Department has not changed, but it looks like the new code has introduced an exception and exits prematurely without applying the other two EREs

    Precedence does not matter because "department" is coming from only 1 connected data source.

    Friday, May 16, 2014 1:56 PM
  • Hi Henry and All,

    Just thought I'd update this thread for others' benefit - I had raised a ticket with MS for this one and they came back to me and confirmed that they have changed the way the sync engine deals with null attributes and EREs that concern these attributes as well as the other EREs for this object. 

    They should have included this information in the release notes.

    Hope this helps - the solution is to always have some non-null value for an attribute.

    Best Wishes,

    • Proposed as answer by kmittal82 Tuesday, September 16, 2014 3:12 PM
    Tuesday, September 16, 2014 1:37 PM