0
Declined

Resync of IDB Adapter Entities with FIM MA without a Full Import

Richard Green 2 years ago in UNIFYBroker/Microsoft Identity Manager • updated by anonymous 2 years ago 3

As discussed with Curtis:

Recently at DET (and at TAFE) we have experienced some issues with IDB where one or more entities in the Adapter get out of sync with the entity state on the associated MA in FIM. This results in a few error conditions:

Delta imports of entities in this state usually present with a staging-error on the MA.

eg.


Exporting changes to entities in this state usually results in an error similar to this:

Internal Server Error #9:
Unify.Product.IdentityBroker.LDAPModifyException: Cannot add the value 43-61-72-6D-65-6C to the existing,
non-multivalue field SAFE-MiddleName.


   at Unify.Product.IdentityBroker.LDAPModifyRequestToEntityConverter.HandleAttributeValueAdd(IModifyRequestOperation
op, IAdapterEntity entity, IEntitySchema schema)


   at
Unify.Product.IdentityBroker.LDAPModifyRequestToEntityConverter.Transform(IRfcModifyRequest
sourceValue, IAdapterEntity origEntity)


   at
Unify.Product.IdentityBroker.ModifyRequestHandler.InnerApplyTransformation(IHandleRequestCoreRequest
request, LDAPModifyRequestToEntityConverter converter)

The advice to-date on how to resolve this issue is "run a full import/full sync" or alternatively "clear the entity from IDB and re-import". While both of these actions usually work, they aren't always a valid/practical option in an operational environment. (Here at DET, running a Full Import/Sync on SAFE consumes most of the day, and block all other operations while it's running.)

I was discussing this issue with Curtis, and he suggested that a change to the FIM Adapter might be possible to address this. Essentially adding in some logic to identify and flag records that have failed with either a staging error on import, or specific IDB related export errors (Likely text file store in the MA data directory).

Then on the next delta import, any existing records that are flagged could be requested and supplied as a full object, in order to re-sync it's state with FIM.

Does this sound feasible?

Cheers

Richard

Affected Versions:
Fixed by Version:
Under review

Hi Richard,

As I mentioned in our discussion, I believe that a Delta Import/Delta Sync should also resolve a state mismatch issue, and that recent issues around timeouts with Delta Imports can cause this to occur more frequently and harder to resolve.

If we find that the issue persists with the fixes to Delta Imports and that Delta Imports can't resolve the issue, then this sounds like a great solution for customers who can't realistically run a Full Import to resolve it.