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.
UNIFYBroker/Plus locker deprovision doesn't remove entities from CSV or PowerShell connectors
I have a UNIFYBroker/Plus link with outgoing deprovision configured to a CSV adapter/connector, and when a joined locker entity is deleted the joined adapter/connector entity isn't deleted when a Changes Sync is run on the link. It isn't deleted when a Baseline Sync runs on the link, either.
I tried the same process with a PowerShell connector and the same behaviour was apparent (i.e. the adapter/connector entity was not deleted). I added logging and confirmed that the entity was not passed to the PowerShell connector's Delete script at all.
For reference, after Sync the Remove Joins page for the link did not show the deleted entity for either the locker or the adapter.
I don't know of anyone from Professional Services who has used Outgoing Deprovision in a UNIFYBroker/Plus solution before, so it may be worth checking around to see if this functionality has every been exercised before.
Error on AD group provisioning: System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection
The following error is occuring when I provision an AD group using the Active Directory connector. The group provisions just fine, but the following error is logged:
I will put the UNIFYConnect customer environment details in the next message, for access to the log files and config.
Hi Adrian
You'll need to set the Primary Object Class configuration on the connector to "Group", instead of "User". This field is used in the filter of a confirmation search request made after an entity is added to AD.
Access to source entity fields for target entities returned by CheckFieldUniqueness
When using the CheckFieldUniqueness component to ensure target entity field uniqueness I would like to use source entity field values in order to calculate candidate values for the unique field. I'm only aware of a way to access target entity field values.
Is there a way to access the source entities for a target entity in this scenario?
Otherwise, please change this ticket to an Idea to have the ability to do so.
I see. You could just mapping the required values to to fields on the target entities, but assuming you don't want to do that you should process the $joinedEntities collection into a HashTable keyed on the target entities. For example:
$entityMap = @{};
foreach ($joinedEntity in $joinedEntities)
{
$entityMap[$joinedEntity.TargetEntity] = $joinedEntity.SourceEntity;
}
You'll then be able to use the target entities returned by CheckFieldUniqueness to lookup the corresponding source entity efficiently.
Time Offset Flag description in UNIFYBroker doesn't match the implementation or the voice documentation
On the Edit Timeoffset Flag page in the UNIFYBroker UI, the description says:
In particular, "The target value is populated based on whether the current time is less than, equal to or greater than the offset value".
The Voice documentation (https://voice.unifysolutions.net/en/knowledge-bases/7/articles/2888-time-offset-flag-transformation) says:
An actual configuration appears like this in the UI:
When this transform was evaluated on 15/12/2020 for a value of StartDate="03/Feb/2020" the value to which PreStart was set was "Yes".
This matches the UI configuration, and the Voice documentation (i.e. source time compared to NOW - with the source time offset implied). However, it does not match the description in the "Edit Timeoffset Flag" UI (i.e. NOW compared to the offset value - with "offset value" presumably meaning "source time plus offset"). The "Edit Timeoffset Flag" UI description is reversed compared to those others and therefore misleading.
This has been implemented and is available in the release of UNIFYConnect V6, which will be made available shortly.
AD Agent default destination port should be 636 if SSL is selected
In the ActiveDirectory agent the default destination port is 389. This can be overridden by appending a colon and an explicit port to the Server configuration.
In AD, port 389 is conventionally used for non-SSL traffic and port 636 is used for SSL traffic. The default port should reflect the SSL setting, in order to avoid confusion and reduce the risk of inadvertent configuration error.
Managing AD user account distinguished name/organisational unit from UNIFYBroker (The connector does not support anchor modification)
Using UNIFYBroker and the Active Directory agent/connector I can set a new user account's organisational unit via their distinguishedName during account creation, but when I subsequently try to modify it this error is logged:
UnifyLog20201207.csv:14572:System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> System.NotSupportedException: The connector AD Users does not support anchor modification.
My customer's solution requires that an employee's OU be managed. Do you have any suggestions how I could achieve this?
Hi Adrian
The "anchor" in the error message is in reference to the connector schema field/s which are marked as Key. Use a different, unique field which doesn't change as the connector key instead. Moving a user between OUs with the AD connector works, and has been done a lot in the past, so there should be plenty of PS resources you can reference.
Allow $logger component to specify module and submodule fields
There is no documented way to set the third and fourth fields (which I will call 'module' and 'submodule') of each UNIFYBroker log entry when calling the $logger component. It would be nice to be able to set them to more informative values, rather than always having them as 'UNIFYBroker' and 'PowerShellTask' respectively.
Hi Adrian,
The $logger component is designed to be a simple wrapper around the logging mechanism. For more complex log messages, use the $messageService variable.
There's some extension methods provided for the next level of logging. You can find more information on those here:
Class NotificationEnumerableExtensions (unifysolutions.net)
Otherwise, you can use the underlying NotificationMessageService to notify listeners of a particular message. In this case, the product loggers will be listening on ILogEntryNotification: Class LogEntryNotification (unifysolutions.net)
The tricky thing with crafting one of these will be building the branding object, (for a BrandedLogEntry). Technically this would allow you to change both the 'module' and 'submodule' components.
For ease of use, i'd recommend just using the NotificationEnumerableExtensions to log - which still use the underlying product for the third field but allow you to define the fourth field.
As a side note, for some reason the $messageService variable isn't actually hooked up for the Plus components, but is hooked up for the Powershell connector and transformations.
Request to sync changes on link in direction outgoing failed with message Duplicate key calculating target to source id lookup
Can you tell me what circumstances might cause this error to happen? I'm not sure where to start investigating. I can't find any problems with what the solution is doing, just this error that occurs whenever I run a Baseline Sync on one of the links.
Thank you
Hi Adrian
It looks like a number of of your locker entities have had multiple connections generated for them. Connections are the record Broker keeps that maps adapter entities to locker entities. Normally there is only one per entity pair per link, but it's not impossible for duplicates to be generated if a link is reconfigured.
The quickest way to fix this would be to clear the locker and re-baseline all related links, which deletes any connections associated with the locker entities. The same also applies to adapter entities.
Generating unique field values in Link pre-provisioning tasks
In a Link pre-provisioning task I would like to generate a unique value for an adapter field. I tried using $components.CheckFieldUniqueness to check $targetEntities, but that variable only contains adapter entities that are being provisioned, and not all the others that already exist in the adapter.
I also looked at $joinedEntities, but it similarly only includes the entities being provisioned.
Can you suggest some way that I can perform a unique value check for a field across all adapter entities?
In the MH solution I used a call-out to AD directly (via the ActiveDirectory PowerShell module) rather than using $components.CheckFieldUniqueness() so I didn't see this behaviour.
Unfortunately in this solution the field value clashes will be very common because the customer wants the first UPN that gets tried to be derived solely from the person's first name.
Case insensitive version of $components.CheckFieldUniqueness?
$components.CheckFieldUniqueness appears to be case sensitive, but UserPrincipalName in AD is case insensitive.
In my solution I am doing a check to ensure my UserPrincipalName field value is unique and $components.CheckFieldUniqueness tells me it is, but my update to AD fails because there that value is already present with different case.
i.e. "tom@contoso.com" vs "Tom@contoso.com"
How can I perform a case insensitive unique value check?
Customer support service by UserEcho
©2025 UNIFY Solutions Pty. Ltd.
