In the synchronization settings for Identity Broker LITE for Aurion, the tooltip information displays the incorrect information for 'Baseline to AD' and 'Baseline to Aurion'. The information that is displayed tells the user that the baseline operations will run daily, however, they in fact run at the frequency set in the synchronization settings.

The imported gender values imported are in the form:

"MALE" and "FEMALE"

but on export there's a Maximum value validation process of one; as such only values of "M" and "F" work.

A useful extended transformation would be to create a constant. This allows it to be used in matching rules before the importflowrules.

Inputs: Datatype, value, column name.

See IDB-227. When GetValue was called to retrieve a StringValue from an integer field, the error stated "Type Entity was expected". A quick search on JIRA shows this message coming up where the GetValue type does not match the field definition type. This error message should be improved for future Identity Broker versions.

After adding additional items to to the Aurion query, the following error occurred during an import:

error -1: Query PERSON has not been validated process cancelled

This was fixed by "validating the join" before running the query. Confirm the correct language in the product before documenting the fix.

If a workgroup code is specified it will validate that the workgroup doesn't exist as opposed to confirming that it exists before continuing.

Choice List types can cause some issues in an identity management solution - see the troubleshooting information. It would therefore be helpful if the SharePoint Connector Configuration wizard could highlight fields that are marked as choice list fields (as simple as checking the ChoiceTypes enum of the attribute's PropertyInfo when retrieving the schema).

Moreover, if the choice list is marked as "Closed", the field could be marked as readonly in the schema - see http://msdn.microsoft.com/en-us/library/microsoft.office.server.userprofiles.choicetypes.aspx. This could also be done by default in order to prevent new choices from being added when the property is not set to "Open" - although this would prevent updates of the field to other valid options for the user. Some further investigation into appropriate behaviour in this case should be carried out.

Estimate includes familiarization with UI, formatting of the XSL, and testing.

The check to confirm that a delete has succeeded has regressed Identity Broker.

In a composite adapter, entity ids don't have to belong to the adapter being visited, and as such the error will occur for every delete performed.

If the adapter containing the deleted entity is first in the configuration, the delete will succeed, but report back a failure when an exception in thrown in another adapter.

If the adapter containing the deleted entity is not the first in the configuration, the delete will fail and report back the failure.

An identity broker adapter engine configuration similar to the following will not break, and will overwrite entities in the db:

<composite-adapter id="YYYYYYY">
<adapter id="XXXXXXXXX" />
</composite-adapter>

<adapter id="XXXXXXXXX" />

I have not performed any operations on my local IdB 4 build, but the adapter is reporting 51909 changes. This is because there are 51909 items in the changes table for the adapter. However, there are no entities present in the Entity table. Relationship should be added between the two tables to clear the changes when the entity no longer exists.