Identity Broker Forum
Welcome to the community forum for Identity Broker.
Browse the knowledge base, ask questions directly to the product group, or leverage the community to get answers. Leave ideas for new features and vote for the features or bug fixes you want most.
Connector description not saved
I set a Description value on two new Aurion connectors (IdB 5.0.4) during creation but the Comment still says "A comment has not been provided". I have edited the connectors again to set the Description but still have nothing in Comment.
As well as it not being saved it would be good if the same terminology could be used in setting and viewing - either Description or Comment.
Aurion connectors require Query Mappings to be configured
I have created a new Aurion connector with IdB 5. I have configured the Agent and successfully retrieved the schema using the "Query fields" provider.
However in the Connector I see the message "Aurion connectors require Query Mappings to be configured. Please reconfigure this connector to update the Query Mappings."
What does this mean? The documentation on creating the Aurion connector has nothing about this, when I go back into the settings there is nothing called "Query Mapping", and I couldn't find anything on jira or voice about "Query Mapping" either.
Found it by accident when I went in the set a Comment value.
Could this please be added to the documentation! It is not at all clear what you're supposed to do and is apparently a setup step. so I would expect to find it in the doco.
Is it possible to set XML_FILE_PATH value when making calling the QUERY_TO_XML on Aurion Connector?
As per the header, is it possible to set the XML_FILE_PATH value when making calling the QUERY_TO_XML API via SOAP to MIM_WAMI.xml (don’t specify a path?
Hi Matthew,
Yes it's possible, in the Aurion query tool it's one of the options. The connector (intentionally) doesn't pass this value so that it's part of the query (it's not sending the path p:\aurion\temp\).
Thanks.
IDB Adapter Delta Import still processing after an Operation Timeout from an MA.
Hi Gents,
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.LdapConnectionProxy.<SearchRequestPaged>d__6.MoveNext()
at System.Linq.Enumerable.<SelectManyIterator>d__14`2.MoveNext()
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Enumerable.<SelectManyIterator>d__14`2.MoveNext()
at Unify.Product.IdentityBroker.ExtensionMethods.Take[TSource](IEnumerator`1 source, Int32 count, IList`1& items)
at Unify.Product.IdentityBroker.ExtensionMethods.<Page>d__0`1.MoveNext()
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.
Hi Richard,
The issue is that we were constrained to meet the same interface between IdB and EB for the v5.0 development (to avoid spending too much time on an interface that will eventually be redundant). As the interface is bool ChangesAvailable(Guid adapterId), we're unable to tell whether you were successful in importing those changes (as the LDAP endpoint is separate from the adapter) or whether or not multiple clients were checking for changes (still not possible).
As we're now using LDAP, our intention is to meet the specification so that IdB can respond to the same queries that EB issues for the LDAP operations (check changes or listen operation).
Thanks.
Identity Broker last run connector statistics are cleared on a service restart
Currently in IDB the Import and Export statistics for the last connector run are lost when the Identity Broker windows service is restarted. After a restart it makes it difficult to tell when the last run was and how long etc it took to run.
It would be a nice to have if this data was stored persistently somewhere so it was visible on the Connector page after a restart.
Hi Andrew.
This is the current intention of the statistics, as they aren't persisted. There is an item on the road map (Improved statistics...) to make improvements in this area, however, we'd love to get some feedback or suggestions if you have any?
Thanks.
The server cannot handle directory requests during installation
With EB and IdB:
Login details validation failed with the following error: "The server cannot handle directory requests." Please check your login information. There doesn't appear to be any issues with AD.
Found a solution online suggesting to provide the override for System.DirectoryServices.AccountManagement.ContextOptions of Negotiate, which is strange as it has worked everywhere else. The setting has worked and will be available in the next releases.
Is the Aurion Schedule Connector filtered?
I haven't worked with the Aurion Schedule connector before. The old Design doc I'm reading (for IdB 3) states that the Schedules will disappear from ILM once they have been completed in Aurion. I can't see any filtering on date in the Adapter so would I be right in assuming the Schedules Connector only imports Schedules that haven't yet been completed?
And if so does the IdB 5 Aurion Schedules connector work the same way? I looked at https://unifysolutions.jira.com/wiki/display/IDBAUR50/Aurion+Schedule+Connector but it doesn't say.
The Schedule connector is designed to manage scheduled employees. As the connector uses the generic reading connector for reads, it is dependent on a query to bring in the right information - so the scheduled connector would bring in the same information in v3 as v5.
LDAP timeout in IdB
Is there anywhere that the LDAP timeout can be configured for the IdB 5 adapters?
FIM import tifailed with stopped-extension-dl;l and event viewer shows
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)
Is there a setting for the LDAP timeout somewhere?
CPU pegs at 100% during import all
Running an Import All of a million users is pegging the CPU at 100%. The environment is not production so the server only has 1 CPU.
Is that expected/normal?
Is there any way to make the service play nice?
LDAP error on bulk export
Was running a bulk export of 966 users to Office 365 using the Graph API connector, the MIM MA finished running in approx 2mins 30secs however the Identity Broker save entities process continued running for an additional 20mins.
MIM received an ma-extension-error for each users object with unexpected error has occurred however all the user objects were successfully created in Office 365. Using version 5.0.4 for both IDB and the FIM connector
Found the following error entries in the IDB logs which are timestamped approx 20secs after the MIM MA finished its run.
Entry 1
Handling of LDAP Bulk Update request.
Handling of LDAP Bulk Update request received from user admin on connection 127.0.0.1:55046 failed with error "Cannot access a disposed object.
Object name: 'System.Net.Sockets.NetworkStream'.". Duration 00:01:44.1525241.
Entry 2
An error occurred on client from 127.0.0.1:55046. More details:
Internal Server Error #11: System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.Sockets.NetworkStream'.
at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at Unify.Framework.Visitor.Visit[T](IEnumerable`1 visitCollection, Action`2 visitor)
at Unify.Product.IdentityBroker.LDAPConnection.<RespondToMessageAsync>d__33.MoveNext()
I'm currently running another full sync to generate an additional bulk export to test further.
Customer support service by UserEcho
