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.

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?

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.

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

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.

$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?

UNIFYConnect instance created some new users in an AD connector, but then the next time it ran the following error appeared:

When a lower priority incoming adapter source field value change is processed by a Changes Polling operation, higher priority field values from the target locker are not written back to the adapter entity.  When a Baseline Sync operation runs they are.  The practical outcome of this is that UNIFYBroker only enforces managed field values in downstream systems when a Baseline Sync is run.

Here's an example from a UNIFYConnect instance: MemberDNs is a multi-valued string field for managing group membership.

Incoming from Azure Cloud Groups:

Outgoing to AD Groups:

The mapping priorities in the Locker are as follows (i.e. Azure Cloud Groups is set as a higher priority mapping than AD Groups):

When the MemberDNs field of the Azure Cloud Groups entity changes (i.e. add or remove a value) that change goes through to the AD group and the AD group's membership is updated with the current values from the Azure Cloud Group and locker entity, as expected.

However, if the group membership's membership is then changed directly in AD that change then comes back as far as the adapter entity, but doesn't flow into the locker entity (and neither should it, because there are already a higher priority values mapped into the locker from the Azure Cloud Group adapter).  However, the correct values from the locker are not being written back to the adapter, which is the functionality we would like to have, so that when a change is made to a managed attribute in a downstream system UNIFYBroker/Plus will quickly revert that change and enforce the correct upstream value.

When a subsequent Baseline Sync is run on the AD Groups link the correct value from the locker is written to the adapter and the downstream system is updated to enforce the value.  This is a functional workaround, but scheduling frequent Baseline Sync operations has an operational overhead.

It's ~9:30am and I just added and enabled an Import All and Import Changes schedule to a connector.  The Import All I set to run at 12:55:57am, and the Import Changes every 1 minute.  The following appeared, which doesn't look right - 1am isn't an hour away, and one minute is not 10 hours away:

On the Remove Joins screen the Created and Modified dates are both set to "00001-01-01 00:00:00Z" for Adapter entities:

This is not impacting me in any way and I'm just mentioning it for completeness.