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.

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

I have made a backup of the IdB 4.0 files and run the install of 4.1.5, but it didn't upgrade the configuration files. I have edited the connector and adapter files by removing expert v7.5 so that we only have chris21.

When adding a new transformation, the UI defaults to the first Constant Value transformation:

The details field says Select a transformation for more information

When you then click the dropdown and choose Constant Value:

No real issue, just a quirk. May be worth showing the transformation explanation as default for the first selected one or adding a blank transformation option as the default selection in the dropdown.

Currently when adding an adapter, it is expected to contain LDAP compliant fields. If the fields are not LDAP compliant (contain invalid characters) then it recommends automatically adding rename transformations to LDAP compliant names.

When you add the adapter; however, it allows you to use invalid named fields to set the DN template.

Idea is that either the field name transformations are able to be added before setting the DN template (so that on creation all fields are LDAP compliant), or when a rename transformation is added it gives the option to update all existing references to the name (so that the DN template would be updated from the old value to the new value).

The following 2 identical transformations are being used to flow the same data into 2 separate CS properties being used in the FIM configuration for different purposes.

The data in each property should be identical, but it is not ... there are some 1.3K users with nulls in the DEPARTMENTS field but which have values in the ALLDEPARTMENTS field, e.g.

3.5K have values in both.

Please advise what could be causing the null values in the second property, but only for about a quarter of the user base?

This is having a significant impact at CSODBB where the data in the original mapped value (DEPARTMENTS) is now significantly compromised. There is only one user with a null value in the ALLDEPARTMENTS property.

Note that in testing both values always had the same values present - this is only something which I have spotted since the change to introduce the second transform was promoted before Christmas.

Logged for customer against https://unifysolutions.jira.com/browse/CSODBB-536

Just installed IdB 5.1 and Aurion connector. Set up Agent and set up connector. Tried to retrieve schema from query - that was successful - but the button proceed with schema did nothing (for ages) then threw error:

Error

System.ArgumentException: The parameters dictionary contains a null entry for parameter 'connectorId' of non-nullable type 'System.Guid' for method 'System.Web.Mvc.ActionResult ConnectorDetails(System.Guid)' in 'Unify.Connect.Web.ConnectorController'. An optional parameter must be a reference type, a nullable type, or be declared as an optional parameter.
Parameter name: parameters
at System.Web.Mvc.ActionDescriptor.ExtractParameterFromDictionary(ParameterInfo parameterInfo, IDictionary`2 parameters, MethodInfo methodInfo)
at System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext controllerContext, IDictionary`2 parameters)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<BeginInvokeSynchronousActionMethod>b__36(IAsyncResult asyncResult, ActionInvocation innerInvokeState)
at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult`2.CallEndDelegate(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethod(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<InvokeActionMethodFilterAsynchronouslyRecursive>b__3c()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<>c__DisplayClass45.<InvokeActionMethodFilterAsynchronouslyRecursive>b__3e()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethodWithFilters(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass1e.<>c__DisplayClass28.<BeginInvokeAction>b__19()
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass1e.<BeginInvokeAction>b__1b(IAsyncResult asyncResult)

Going back into the connector and the schema has saved (with no unique key, so that might be why the error) so maybe this is just cosmetic/timing issue.

This applies to other HR data feeds as well, not just Aurion.

HR systems typically give us the Org Unit hierarchy in parent-child format. However we need to "flatten" this against person objects so we can use the values for group population and attribute flows.

- The number of Org Unit levels will differ from organisation to organisation

- There will be a mapping between level and org unit type - for example "Section" may be level 4.

- There may be gaps in the Org Unit hierarchy - for example a level 4 org unit that is the child of a level 1 org unit. This means you cannot assume the level of the parent org unit - you have to actually look at what it's level is.

- Populating all ancestor Org Units in a multi-value field may be ok for group population but is not helpful for flowing values like "Division", "Branch", "Section" where you have to know the level.

Data feed from HR data source comes like this. For each Org Unit:

OrgUnitID: (Key, req) Identifier of the Org Unit

OrgUnitName: Name of the Org Unit

OrgUnitLevel: (Req) A number specifying level where 1 is the top. The lowest org unit number should not be enforced – current Aurion customer goes down to level 9. This will differ for different environments.

ParentID: Identifier of the parent in the hierarchy. It is *not* required that the parent level is one level up – eg., a level 4 can be the child of a level 2, skipping level 3. However we can assume there will only be one parent. The level 1 Org Unit will not have a parent.

Data to produce – for each Org Unit:

OrgUnitID: Identifier of the Org Unit

OrgUnitName: Name of the Org Unit

OrgUnitLevel: Level of the Org Unit

OrgUnit1: (Req) The OrgUnitID of the level 1 ancestor of this Org Unit

OrgUnit2: (If applicable) The OrgUnitID of the level 2 ancestor of this Org Unit

OrgUnit3: (If applicable) The OrgUnitID of the level 3 ancestor of this Org Unit

… OrgUnitN: (If applicable) The OrgUnitID of the level N ancestor of this Org Unit