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.
DataTables warning: table id=Logs - Invalid JSON response
Clicking on the last page of Logs often throws the following error:
---------------------------
Message from webpage
---------------------------
DataTables warning: table id=Logs - Invalid JSON response. For more information about this error, please see http://datatables.net/tn/1
---------------------------
OK
---------------------------
The user cannot access that page.
Hi Matthew, I believe I was able to track down and fix this issue. If you're able to test please take a look at:
Aurion Attribute Mapping broken & possibly not required anymore
Using Aurion connectors, I have 4 types:
- Schedule
- Security User
- Person
- Generic
If I use Security User as an example, immediately after creating the connector I get the error "Aurion connectors require Query Mappings to be configured for imports to successfully complete. Please reconfigure this connector to update the Query Mappings."
1) If I use the "default Security User schema", an incorrect schema is created and I need to guess the correct attribute names.
If I use the "query fields" option, the correct names are created & have the option to do mapping in the connector which is very time consuming, or I can have the adapter do it automatically.
2) Is it necessary/advisable to do this mapping in the connector?
The default schema allows the fields to be exported to, they are the names that are required for the API to work. Due to a mismatch in Aurion (and the ability to rename fields in the query tool), there needs to be a mechanism to map between the differently named fields.
The default schema should be used for the connectors that have one. Then use the mapping tool to map between these field names and those that are returned by the query (or the query schema provider).
Change Core Log location
Core Logs are being written to C:\Program Files\UNIFY Solutions\Identity Broker\Services\Logs There doesn't seem to be a place to do this in the UI.
Hi Matt,
This location currently can't be changed. If you need to log to a different directory, you can create another CSV log writer configured to log to the desired directory. Alternatively, you could try replacing the C:\Program Files\UNIFY Solutions\Identity Broker\Services\Logs directory with a symbolic link to the desired directory.
Schema Provider errors with "Value cannot be null. Parameter name: key"
On some of the other connectors when I attempt to request schema, I get the error "Value cannot be null. Parameter name: key".
NEWS-LTD-101: Idb for Workday: Request to change filtering date from hire date to current date
News has requested that UNIFY modify the code for IdB for Workday such that filtering on a user;s Top-Level Org uses the current date rather that the target user's Hire Date. Currently News are seeing users filtered that should not be filtered and the cause appears to be that when the hire date is used, the IdB returns the SupervisoryOrg level instead of the Top Org level for the user i.e. the returned result is:
SupervisioryLevelOrganisation = SupervisioryOrg
TopLevelOrganisation = SupervisioryOrg
Which results in the user being filtered
News-Ltd now have given approval for UNIFY to make to the requested code change and agree that (in the absence of advice from Theory of Mind), that they take full responsibility for the performance of the code and have agreed that the code change will be staged through a full regression test cycle in their UAT environment prior to migrating the code to Production.
Thanks Jeff.
Install IdB MIM Adapter DLL to appropriate MIM directory
The MIM adapter currently installs to a Unify directory in Program Files, after which it needs to be moved manually into the appropriate MIM Directory.
The installer could install into the appropriate directory, which would result in better end user experience, both in the initial install and in repairs.
The FIM Sync base directory can be retrieved from the registry at:
SYSTEM\CurrentControlSet\Services\FIMSynchronizationService\Parameters\Path
as documented here.
After this \extensions needs to be added to the path value to find the location.
Will be included in the next adapter release.
Unable to retrieve schema
MIMs IdB MA is unable to retrieve schema from IdB during implmentation. Error returned is:
-------------------------------------------
Synchronization Service Manager
Unable to retrieve schema. Error: Exception from HRESULT: 0x80231343
-------------------------------------------
Event Log contains the following:
-------------------------------------------
The extensible extension returned an unsupported error.
The stack trace is:
Unify.Product.IdentityBroker.LdapOperationException: Object reference not set to an instance of an object.
at Unify.Product.IdentityBroker.LdapConnection.SendRequest(ILdapRequest request)
at Unify.Product.IdentityBroker.LdapConnection.GetSchema(String schemaDn)
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Enumerable.Aggregate[TSource](IEnumerable`1 source, Func`3 func)
at Unify.Product.IdentityBroker.LdapConnectionProxy.get_Schema()
at Unify.Product.IdentityBroker.UnifyLdapConnectorTypeProxy.GetSchema(KeyedCollection`2 configParameters)
Forefront Identity Manager 4.4.1459.0
-------------------------------------------
Thanks Matt,
It looks like you have an entry in the [Container] table left over from an adapter with a container name of users. These should be removed automatically when you delete the adapter, or if you delete it directly from the xml config, at service startup. I'm not sure how it's managed to stay in there for you if you don't have any such adapter. You can manually delete the entry from the [Container] table where the [DistinguishedName] column has the value OU=users,DC=IdentityBroker to resolve this issue, and I'll re-raise this as bug in our backlog.
You should be able remove the patches supplied on this issue as well.
Missing object class in IdB 5.1
Configuring IdB5.1 for the first time with SharePoint connector and MIM. MIM does not see the object class that the Adapter is presenting, but it does see the container.
IdB for MIM 5.1 RC2 is the version I have installed.
I forgot that the installer doesn't put the DLL into the right directory. 🤦
The 5.0 version was in an responding to requests.
I'm getting a different error now, but will open a new issue for that one.
PowerShell Connector handling of DN.multi attributes where there is a single value
The PowerShell Connector treats DN.multi attributes with a single value differently to how it treats string.multi attributes with a single value. This can be overcome in the script however unnecessarily complicates import the script.
Error if handled the same as a string.multi (appears to take first char rather than first array entry):
Script that will handle the single value: StudentParentRelationshipsImport.ps1
DN.multi attribute: ParentRelationshipDNs
String.multi attribute: ParentIDLIST
Identity Broker: v5.0.5
Hi Boyd,
This appears to be a peculiarity with PowerShell.
$array = @('A')
$array.GetType() # Object[]
$sort = $array | Sort
$sort.GetType() # String
$sort = @($array | Sort)
$sort.GetType() # Object[]Please make sure that you force your value into an array before assigning to multi-valued fields.
Adapter object doesn't have corresponding object in Connector resulting in "duplicate-objects error"
This is related to http://voice.unifysolutions.net/topics/2674-idb-51-returning-duplicate-objects-that-only-exist-once-in-the-adapterconnector/ although the bug is now exhibiting new characteristics and the work around is no longer working.
Drilling down on one of these records we can see that they exist twice in IdB adaptor but only once in the connector:
The second entry in the adaptor was once correct but has since been removed from the source system (as this is to do with student enrollments that's a normal procedure). According to Andrew Silcock's notes in the linked job, previously the entries only existed in the adaptor once.
Customer support service by UserEcho
