In my customer's UAT and PROD environments an adapter is retaining old entities when a connector import all operation completes with less entities (i.e. some entities have been deleted). This happens every time the import all operation is run.  It seems some updated/new entities may not be being processed either, but that's not as clear.  What is clear is that the adapter entity count increases to a number greater than the connector's entity after the import all.  There are no corresponding errors in the log.  Generate changes does not fix the problem, but deleting the adapter entities and then running generate changes does.

What information would you like to help debug this?

Version is v5.3.3 Revision #0
The connector is a PowerShell one

When the scheduler is disabled it's not possible to run Import or Sync operations.  During solution development, initial data load and remediation activities it is often necessary to perform manual import and sync operations in specific orders while all scheduled other activity is suspended.  To achieve this right now all connector and link schedules must be individually disabled, which can be time consuming for non-simple solutions, and comes with an increased risk of schedules being left disabled inadvertently.

Provide some way to suspended scheduled operations, while allowing manual operations to continue to work.

I suggest adding a "Manual Operations Only" flag (or similar) to the dashboard.

In my customer's TEST environment they are seeing AD sAMAccountName being updated for existing users where the join criteria are met.  The only place where the sAMAccountName is set is in the outgoing pre-provisioning task, which should not be called for existing joined entities.

I have also seen a second confirmation that the task is being called for pre-existing users: the "AD Account Creation" notifications being repeatedly sent for a large number of entities every time a Baseline Sync is performed.  The only place where that notification is sent is in that same outgoing pre-provisioning task.

When an adapter entity is deleted any persistent joins remain and block subsequent joins to remediated data.

Steps to reproduce
1. Configure a Link with outbound provisioning and persistent joins configured
2. Import an adapter entity that is intended to join a locker entity, but which is missing its join criteria field value
3. The link will provision a "duplicate" record (thereby creating an internal "Join" for the newly provisioned adapter entity)
4. To clean up the duplicate, delete the SoT for the "duplicate" adapter record and update the "intended" record to have a correct join criteria field value
5. Attempt to join the locker to the newly corrected adapter entity - it fails and re-provisions the "duplicate" record again

In my UNIFYConnect config the MOBILE_PHONE value isn't being written back to Aurion successfully.

The relevant connector config is:

In the customer's Aurion report the mobile phone field is called 'Contact_Mobile_Phone' so a mapping is necessary.  Import is working correctly, but the field is not updated in Aurion on export.

Here is the rest of the relevant config:

Adapter Transform (to remove underscores from the field name)

Link Mapping

Locker Entity

After a connector Import the Contact_Mobile_Phone field is set to the old value from Aurion as expected.  After a Baseline Sync on the link the value in the connector is changed to '0418 999 999' temporarily, but then reset back to the old value from Aurion after the next connector Import, showing that the value has not been updated in Aurion.

What is causing the writeback to fail and how do I get it to work?

This error is being written to the UNIFYBroker logs in multiple UNIFYConnect environments.  I deleted all transforms that referred to those fields, removed references to the fields from links, and then recreated them all, but it didn't stop the error from appearing.

In my customer's TEST I am seeing this Aurion error when a Baseline Sync runs, for 23 of ~500 entities:

20210803,01:01:15,UNIFYBroker,EntitySaver,Error,The entity mbishop (1100a4a9-3f58-4f13-9c39-480b36abbf41) for the adapter Aurion Security User (c5460bd3-0167-4290-a2a0-180f8632a474) failed to update for the following reasons: Aurion API error -1: User is already linked to an Employee and cannot be changed by this process,Normal

Looking at the data for this specific case, it appears the only update that needs to be sent to Aurion is Name (changing from "Matthew BISHOP" to "Matthew Bishop"). Other fields appear to be unchanged.

What do you suggest I do to debug the root cause?

I am looking to add 'rename' support to a PowerShell connector.  According to https://voice.unifysolutions.net/en/knowledge-bases/7/articles/2911-powershell-connector the export update script is passed $components.InputEntities which contains the updated entities.  For a rename operation the key field value will have been changed, so how do I identify the record in the external system that needs to be updated?  Is the old key available somewhere?

A few weeks ago all the connectors in a connector exclusion group inexplicably stopped running.  Scheduled Import All operations are running OK on connectors not in the connector exclusion group.  There does not appear to be any running Import All operations on any of the connectors in the group.

Hi,

Please let me know what could be the reason for 500 internal server error here.

Thank you

20210701,00:28:13,UNIFY Identity Broker,Connector,Warning,"Update entities to connector failed.

Update entities [Count:1] to connector TechOne SMS Student Management Users failed with reason The remote server returned an error: (500) Internal Server Error.. Duration: 00:00:02.1884079

Error details:

System.Management.Automation.RuntimeException: The remote server returned an error: (500) Internal Server Error. ---> System.Net.WebException: The remote server returned an error: (500) Internal Server Error.

at System.Net.HttpWebRequest.GetResponse()

at CallSite.Target(Closure , CallSite , Object )

--- End of inner exception stack trace ---

at Unify.Product.IdentityBroker.PowerShellConnector.Execute(String script, IEnumerable`1 inputEntities, IEnumerable`1 inputKeys)

at Unify.Product.IdentityBroker.EventNotifierUpdatingConnectorDecorator.UpdateEntities(IEnumerable`1 entities)

at Unify.Product.IdentityBroker.Adapter.UpdateEntities(IEnumerable`1 entities, EntityToConnectorEntityBridge[]& connectorEntities)

at Unify.Product.IdentityBroker.Adapter.UpdateEntities(IEnumerable`1 entities)

at Unify.Product.IdentityBroker.AdapterNotifierDecoratorBase`1.UpdateEntity(IAdapterEntity entityToSave)

at Unify.Product.IdentityBroker.AdapterNotifierDecoratorBase`1.UpdateEntity(IAdapterEntity entityToSave)

at Unify.Product.IdentityBroker.LDIFAdapterBase.HandleExportUpdate(IAdapter adapter, IAdapterEntitySaveChange pendingUpdate)

at Unify.Product.IdentityBroker.LDIFAdapterBase.ExportChanges(ExportedLDIFForAdapter exportedLdifForAdapter)

at SyncInvokeExportChanges(Object , Object[] , Object[] )

at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)

at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)

at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)

at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)

at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)",Normal