Found an interesting one i believe. We have been seeing the following behavior in the PROD environment out at QDET.
1. A delta import from IDB fails with due to the configured operation timeout being exceeded.
2. After the failure, no subsequent delta imports are triggered via EVB (using the IDB changes plugin as a trigger).
3. Manually triggering a delta import (with an extended timeout setting), clears the issue once the import completes. Further imports are triggered ok via EVB. (Running a Full Import also works here)
I believe the following is occurring:
1. Delta fails due to timeout in FIM.
a. The following is in the windows event log:
The extensible extension returned an unsupported error.
The stack trace is:
"Unify.Product.IdentityBroker.LdapOperationException: Operation timed out.
at Unify.Product.IdentityBroker.LdapConnection.SendRequest(ILdapRequest request)
at Unify.Product.IdentityBroker.ExtensionMethods.Take[TSource](IEnumerator`1 source, Int32 count, IList`1& items)
at Unify.Product.IdentityBroker.ImportProxy.Import(GetImportEntriesRunStep importRunStep)
Forefront Identity Manager 4.1.3627.0"
b. IDB log shows the LDAP connection, followed by a connection aborted error after the timeout.
2. For some reason, the delta operation is not actually terminated within IDB. Thus when EVB tries to check for changes, the operation returns false as it thinks an import is in progress.
This is evidenced by the following. On manually running a delta import from FIM, IDB showed on the adapter that the operation had a duration of 15 hours:
I was able to trace this time back to the exact time when the first delta import operation had timed out:
So essentially it seems that because IDB thinks it's still going, it stops the IDB changes plugin from initiating subsequent operations.
We have a workaround for now - obviously increase timeouts, and run manual operations when needed.
Customer support service by UserEcho