We are using an instance of the PowerShell connector to create unique AD accounts which are then to be reimported to FIM to allow the normal FIM Active Directory connector to drive standard inbound/outbound flow rules.

Given we can't easily implement a delta import mechanism for AD, and that the only changes we're interested in checking are the ones made by Identity Broker itself, is it OK to perform say the following lines at the end of the ADD.PS1 script?

$entity['sAMAccountName'] = $sAMAccountName
$entity['mailNickname'] = $mailNickname
$entity.Commit()

The LoggingEngineConfigurationViewInformation currently validates out negative numbers, which is the mechanism for keeping log files indefinitely.

A check box should be added to the UI to allow for keeping log files indefinitely. Determine whether the log writers should be changed to use this new boolean option, or whether the negative value should be kept at that level.

Update the logging pages on documentation.

The MaxReceivedMessageSize is being surpassed for large imports - ~500,000 entities and upwards.

A quick fix is to simply edit the MaxReceivedMessageSize to be its maximum value:

maxReceivedMessageSize = "2147483647"

However, this may only be hiding a more ingrained systematic problem - Why is the IDB Service sending a SOAP message that would surpass the recommended configuration?.

A determination needs to be made about the correct course of action with regards to this behaviour.

I have the same issue with the lack of a smallint/short validator as documented in IDB-70. There is mention of a workaround, but no details. Can someone help me out?

Looking at https://unifysolutions.jira.com/wiki/display/SUBIDB/Downloads, I only see an x86 version of the Management Studio.

Is there a 64-bit version? If not, can one be created?

What's the impact of using an x86 version in an x64 environment?

Can Identity Broker be configured to send e-mail log notifications of errors?

When exporting a date field (such as EmployeeStart) to the FIM portal, if this field has been supplied by a date field in Identity Broker, a datetime-string-format-incorrect error occurs.

The work around is to use a concatenation of T00:00:00.000 on the end of the date value.

As in improvement, Identity Broker should supply this field in a format that FIM recognizes.

Some transformations do a good job picking up invalid configuration, but a lot of the relationship connectors don't actually check that the relationship fields exist. It should be an invalid configuration.

As the quality of some connectors will be dictated by the quality of the target system, it would be good if all relationship transformations included the ability to automatically convert types. This would mean using the entity schema validator method to convert the values (IEntitySchemaFieldValidator.CreateValue() I think) of the input keys in each page to the value type of the relationship key.

Some of the relationship connectors don't check that the relationship connector ID supplied exists. This should be an invalid configuration.