IDB Renames - Multiple Successive Renames on the same object fail on the second FIM confirming import.

Matthew Clark 12 years ago in UNIFYBroker/Microsoft Identity Manager updated by anonymous 9 years ago 14

Hey Guys,

I've uncovered a new issue with IDB in regards to renames.

This issue occurs when multiple renames are perfomed on the same object. I've performed a significant ammount of testing and analysis on this issue, which i'll explain in detail below, but in each case, after the second rename, the confirming import in FIM produces one or more need-full-object errors. I also believe I have determined where the issue is being produced.

In most cases, this is the general procedure for producing the issue:

1. Rename user (uid) in Active directory and produce a Provisioning Rename for Export to TAM.
2. Export rename to TAM (Successfull)
3. FIM Delta Import confirms rename. (Successfull)
4. Rename same user again in AD.
5. Export rename to TAM (Successfull)
6. FIM Delta Import - need-full-object error produced.

In each case the rename is successfully exported to TAM, and i have confirmed that in all cases the Modify Anchor method on the connector is being hit.

These are the cases tested, and the results:
(All UNIFYDelta files for these cases are in the attached ZIP)

1. - Rename user cladn3 to cladn30, and then rename back to cladn3.
2nd Import Result - need-full-object error produced on cladn3

2. - Rename user kxhep0 to kxhep50, and then rename again to kxhep70.
2nd Import Result - need-full-object errors produced on both kxhep70, and kxhep0

3. - Rename user uxngt0 to uxngt05. Perform an IDB full import, then rename user back to uxngt0.
2nd Import Result - need-full-object error produced on uxngt0

4. - Rename user ulgni1 to ulgni10. Perform a FIM full import, then rename user back to ulgni1.
2nd Import Result - need-full-object error produced on ulgni1

5. - Rename user ugfen1 to ugfen10. Perform an IDB & FIM full import, then rename user back to ugfen1.
2nd Import Result - need-full-object error produced on ugfen1

6. - Rename user bxttt0 to bxttt05. Drop IDB Connector Partition and FIM CS, then Reimport. Rename user back to bxttt0.
2nd Import Result - Rename successfull.

The need-full-object error is defined here: http://support.microsoft.com/kb/818559
We've seen this error before on QDET-156, and it occurs when an update operation is attempted on an object before the object is sucessfully renamed. The rename is completed by the presence of a moddn operation in the delta ldif file. Until this operation is processesd, the object in FIM retains it's original DN.

In viewing the UNIFYDelta ldif files produced on the second confirming import, the issue becomes apparant.

In the cases where the uid was changed back, no moddn entry is present to confirm the rename. Updates present for the object fail with the error as explained above.

In case 2, where the uid was renamed again to a different uid, the ldif file did contain a moddn, but it was incorrect. As above in this case, the first rename was from kxhep0 to kxhep50, and the second from kxhep50 to kxhep70. The second moddn (see below) was trying to rename from kxhep0 to kxhep70.

The moddn for the first rename in this case looked like this:

dn: UID=kxhep0,CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU
changetype: moddn
newrdn: UID=kxhep50
deleteoldrdn: 1
newsuperior: CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU

This is correct, and the rename was successful.

The second rename:

dn: UID=kxhep0,CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU
changetype: moddn
newrdn: UID=kxhep70
deleteoldrdn: 1
newsuperior: CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU

This is incorrect, as it is trying to rename from kxhep0 to kxhep70, but at this point in FIM, the DN is kxhep50.

After seeing this error, i performed some analysis on the database to monitor the status of the records around a simlilar operation. In this case i renamed a user from uxnnt3 to uxnnt30, and then to uxnnt31.
The results of this trace are in the attached excel sheet, but i was able to note that throught all of the exports and imports, the DN field on the entity table remained unchanged from it's initial state.

The fact that this field is not being updated explains all of the above issues. When the uid is being renamed as in case 2, it produces a moddn from the DN present, to the required DN. In cases where the uid is being changed back, as it allready has the same value in the DN field, it does not produce a moddn as assumes none is required.

It looks like this field is used to create the moddn entry, particularly in specifying the current DN of the object. On the second rename, the moddn entry is produced incorrectly, as the DN was not updated after the first rename. The result of this is that the rename is not confirmed on the FIM import, and remains in the state of awaiting export confirmation.

To summarise all of the above, i've confirmed that on rename operations within IDB, the DN field of the entity table is not updated to reflect the new DN of an object. The result of this causes issues when creating the moddn entries after a second object rename.

Rename Issue Data.zip
SQL Check.xlsx


I haven't attempted to replicate your issue but this has given me enough information to see a potential issue in Identity Broker causing this to happen (see IDB-481). We would plan to address this in the next major release of Identity Broker (v4.0). Is this currently blocking any behaviour or is this being managed by Event Broker?


this unfortunately does cause a few issues in DET. The good news is that it appears as though the change is finding its way to TAM which is great. However, it seems like the only way to fix it is to perform a Full Import into FIM. We have disabled Full Imports at the moment because of QDET-183 so the error stays.

Hence it is not blocking but we may need to re-visit the timing of a fix after we investigate QDET-183 further.


Additional information from the meeting this morning:

  • The DN still remains the same even after performing an adapter full import

I've identified that the full and delta may be handling this issue differently:

  • Full imports do not seem to reflect DN changes as they are only using the change report
  • Delta imports do not seem to modify the context when processing differences (although they do successfully create the change indicator)


I've fixed up a location I believe was causing issues with the delta import (yet to confirm in local testing), but on revisiting the full import, it appears as though the entire adapter entity should be recalculated. You mentioned in the meeting that a full import does not fix the issue. Is this because you were unable to do full imports, or was it that you have confirmed this in testing v3.0.7?

Hey Matt,

I was testing this in DEV, so was able to run full and delta imports.

In cases 3 & 5 above a connector full import was run, and in cases 4 & 5, an Adapter full import was run. Neither seemed to correct the issue. Infact the only method of correction seemed to be dropping the connector via Management Studio and reimporting.

This was definitely tested with v3.0.7

Great, thanks for the clarification. I'll let you know how things go.

I have confirmed this issue for both full and delta imports, and have confirmed a fix for delta imports using SharePoint. Full import behaviour to be rectified.


Attached is a DLL which I have confirmed to fix the issue for delta imports. I had thought above that I had confirmed the behaviour occurring following full imports, but with no changes to its processing it also seems to now be working.

I have also pulled this fix into Identity Broker v4.

Please let us know if this resolves your issue.


Thanks Matt,

I'll drop this in to DEV and give it a test


Hey Matt,

Tested 3 successive renames on the same object. Both full and delta imports working perfectly. Confimed Entity table record is being updated


This fix is scheduled to go into PROD tomorrow.

Fix has been applied to PROD, No further issues of this type have occurred. Thanks Guys.

Re-opening to correct Billing Key