Question on whether we can make the Aurion connector more resilient to a specific issue I'm seeing where Aurion will repeatedly send all report data twice. It sends the full set of output between <DocumentRoot> and </DocumentRoot>, then starts all over again, this time skipping the opening <DocumentRoot> tag but still terminating with a final </DocumentRoot>.

The problem is definitely on the Aurion side and the customer has raised a support ticket - but at the same time perhaps we can make IdB a bit more resilient? If it ignored everything after the first </DocumentRoot> we'd be ok here. If there's a good reason why we can't do that then that's ok - I just want to be able to explain to the customer.

As discussed with Curtis:

Recently at DET (and at TAFE) we have experienced some issues with IDB where one or more entities in the Adapter get out of sync with the entity state on the associated MA in FIM. This results in a few error conditions:

Delta imports of entities in this state usually present with a staging-error on the MA.

eg.

Exporting changes to entities in this state usually results in an error similar to this:

Internal Server Error #9:
Unify.Product.IdentityBroker.LDAPModifyException: Cannot add the value 43-61-72-6D-65-6C to the existing,
non-multivalue field SAFE-MiddleName.


   at Unify.Product.IdentityBroker.LDAPModifyRequestToEntityConverter.HandleAttributeValueAdd(IModifyRequestOperation
op, IAdapterEntity entity, IEntitySchema schema)


   at
Unify.Product.IdentityBroker.LDAPModifyRequestToEntityConverter.Transform(IRfcModifyRequest
sourceValue, IAdapterEntity origEntity)


   at
Unify.Product.IdentityBroker.ModifyRequestHandler.InnerApplyTransformation(IHandleRequestCoreRequest
request, LDAPModifyRequestToEntityConverter converter)

The advice to-date on how to resolve this issue is "run a full import/full sync" or alternatively "clear the entity from IDB and re-import". While both of these actions usually work, they aren't always a valid/practical option in an operational environment. (Here at DET, running a Full Import/Sync on SAFE consumes most of the day, and block all other operations while it's running.)

I was discussing this issue with Curtis, and he suggested that a change to the FIM Adapter might be possible to address this. Essentially adding in some logic to identify and flag records that have failed with either a staging error on import, or specific IDB related export errors (Likely text file store in the MA data directory).

Then on the next delta import, any existing records that are flagged could be requested and supplied as a full object, in order to re-sync it's state with FIM.

Does this sound feasible?

Cheers

Richard

@HSF, We migrated IdB4.0 to 4.1 and we have configured in FIM to flow email address to update back in chris21. And during testing chris21 tech team found that IdB is updating attributes like surname, dob etc in addition to email address. I checked all connector and adapter configuration, there is no flow to the above attributes. in FIM there is just one export flow from MV to chris21 person, email address. I can send the adapter and connector config, but couldnt find a way to add them here.

I'm getting the following error on import from Identity Broker for chris21 v4.1.

Change detection engine import all items failed.Change detection engine import all items for connector Chris21 Person Connector failed with reason An error occurred while evaluating a task on a worker thread. See the inner exception details for information.. Duration: 00:00:51.0016320
Error details:
Unify.Framework.EvaluatorVisitorException: An error occurred while evaluating a task on a worker thread. See the inner exception details for information. ---> System.ArgumentException: An item with the same key has already been added.
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 comparer)
at System.Linq.Enumerable.ToDictionary[TSource,TKey](IEnumerable`1 source, Func`2 keySelector)
at Unify.Product.IdentityBroker.PageableEntityChangesReportGenerator`2.ToDistinctChangesEnumerable(IEnumerable`1 entitiesWithKey, IHashSet`1& knownEntityKeys)
at Unify.Product.IdentityBroker.PageableEntityChangesReportGenerator`2.CreateDifferencesReport(IEnumerable`1 knownEntities, IEnumerable`1 newEntities)
at Unify.Product.IdentityBroker.RepositoryChangeDetectionWorkerBase.PerformChangeDetectionOnConnectorEntityPage(IEnumerable`1 connectorEntities, Int32& index, Int32 entitiesProcessedSoFar, IEntityChangesReportGenerator`2 reportGenerator, IHashSet`1 seenKeys)
at Unify.Product.IdentityBroker.RepositoryChangeDetectionWorkerBase.<>c__DisplayClass12_0.<PerformChangeDetection>b__0(IEnumerable`1 page)
at Unify.Framework.Visitor.ThreadsafeVisitorEvaluator`1.ThreadsafeItemEvaluator.Evaluate()
--- End of inner exception stack trace ---
at Unify.Framework.Visitor.ThreadsafeVisitorEvaluator`1.CheckForException()
at Unify.Framework.Visitor.ThreadsafeVisitorEvaluator`1.WaitForAvailableThread()
at Unify.Framework.Visitor.ThreadsafeVisitorEvaluator`1.Visit()
at Unify.Product.IdentityBroker.RepositoryChangeDetectionWorkerBase.PerformChangeDetection(IEnumerable`1 connectorEntities)
at Unify.Product.IdentityBroker.ChangeDetectionImportAllJob.ImportAllChangeProcess()
at Unify.Product.IdentityBroker.ChangeDetectionImportAllJob.RunBase()
at Unify.Framework.DefinedScopeJobAuditTrailJobDecorator.Run()
at Unify.Product.IdentityBroker.ConnectorJobExecutor.<>c__DisplayClass27_0.<Run>b__0()
at Unify.Framework.AsynchronousJobExecutor.PerformJobCallback(Object state)

Aurion is giving me multiple security records per person. I have been told the only way to select the correct record is to go for the one where "Clearance Date To" is NULL. How do I do this in IdB 5?

I know I have seen this before, but cannot find it anywhere.

The ISAS connector at TAFE is a SQL connector and is not showing me its config in any kind of user friendly way. Any idea what needs to be done to rectify? I assume (but do not know) that it used to be correct.

Does IdentityBroker support the SQL AlwaysOn Availability Groups feature introduced with SQL2016? An "early adopter" preview of a MIM2016 supporting this feature has just been made available to MVPs, and with growing awareness of this feature, it would be good to put this on the roadmap if it's not already there.

Import is failing for Google User Settings Connector after exactly 1 hour (log entries attached).

Error Google User Settings.txt

I've noticed in the AdapterEnginePlugInKey config file, when creating adapter transformations, the powershell transformation lists its name as PoweShell:

<adapter name="PoweShell" key="fcc41e33-bff4-4286-8aa8-610a46f2d9ce">              
    <Extended xmlns="">
        <Scripts transformationScript="..." />
    </Extended>
</adapter>

Not a huge deal; no loss of functionality has been reported because of it as far as i'm aware.

Client is reporting an issue with IdB 5.1.0 Rev 2 where DN creation is not escaping LDAP reserved characters, resulting in an exception being thrown on reflection attempt.

Exception message (truncated):

20170224,04:30:52,UNIFY Identity Broker,Adapter,Error,"Request to reflect change entities of the adapter.Request to reflect change entities of the COPP Class adapter (44f6b6c4-005e-420c-9331-21b04e0cbf77) adapter errored with message: Value 2 is not a valid hexadecimal number.Parameter name: sourceValue. Duration: 00:00:01.0537045
Error details:System.ArgumentException: Value 2 is not a valid hexadecimal number.Parameter name: sourceValue
at Unify.Framework.IO.DNComponentAttributeValueParserAdapter.Transform(String sourceValue)

1\2 MS
1\2C

In IDB 3.0, the values were being escaped for DN creation:

"UID=COPP:1\\2 MS,DC=class class COPP COPP:1\2 MS"
"UID=COPP:1\\2C,DC=class class COPP COPP:1\2C"

In V3, the DN creation was set up as the following:

<dn>    
    <dnComponent name="Field" attributeType="CN" key="srksNumber"/>
    <dnComponent name="Constant" attributeType="DC" value="student"/>
</dn>

In V5, it is set up as follows:

<dn template="CN=[srksNumber]" />

Few other differences between the V3 and V5 setup for the client; V3 used custom connector while V5 is using OOTB SQL connector. I've attached the adapter configuration for both 3 and 5 to this issue.

AdapterEngine.extensibility.config.xml - v3 config

Unify.Product.IdentityBroker.AdapterEnginePlugInKey.extensibility.config.xml - v5 config

It's my understanding that the DN is meant to be automatically escaped for creation - is there a configuration step that has been missed in this case?

See Client Ticket for further details / attachments: https://unifysolutions.jira.com/browse/ACTDET-49