See SSICT-101. An environment with a composite adapter containing three adapters - 50000 entities in the first, 38000 in the second, and 50000 in the third. The third was requiring an update to a single field and was taking 4-9 seconds per object. This was alleviated by changing the order of the adapters such that the third adapter was made the first.

This is because the LDIF reading in the LDIF adapter relies on TryGetEntityByDN to get the object class of the object. This is done because LDIF spec does not contain the objectclass field for updates. An improvement to this interface is required in order to allow exports in larger, time-sensitive environments to run in an efficient manner.

This impacts both Identity Broker 4.0.0.3 and FIM Event Broker 3.0.2.

I personally think it's counter intuitive that a days worth of logs is loading in a GMT based set of data but any times output to the UI are the local system timezone. I can't think of any situations where I want the dataset to be aligned to GMT. Ideally, if on the Logging section I select a days worth of logs (say 8 Feb 2014) then every log entry should appear in that date range starting at 12:00AM and going to 11:59PM.

I've atatched a screenshot where you can see the log starts and stops around 11AM which is counter intuitive for end user browsing and arguably incorrect given the mismatch between the page header and the actual log entries.

I am getting a warning about MSDTC in the IdB log. Full imports work on server 2 but deltas give me no changes (though also no error).

I have followed the instructions in the IdB prereqs to set up MSDTC network permissions through Component Services. The windows firewalls are currently disabled on both servers. The MAs are using server names and tyhey report no connectivity problems.

What else should I check?

Here's the full error:

System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException (0x8004D02B): The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception from HRESULT: 0x8004D02B)

Application: Unify.Service.Connect.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
Stack:
at System.ModuleHandle.ResolveType(System.Reflection.RuntimeModule, Int32, IntPtr*, Int32, IntPtr*, Int32, System.Runtime.CompilerServices.ObjectHandleOnStack)
at System.ModuleHandle.ResolveType(System.Reflection.RuntimeModule, Int32, IntPtr*, Int32, IntPtr*, Int32, System.Runtime.CompilerServices.ObjectHandleOnStack)
at System.ModuleHandle.ResolveTypeHandleInternal(System.Reflection.RuntimeModule, Int32, System.RuntimeTypeHandle[], System.RuntimeTypeHandle[])
at System.Reflection.RuntimeModule.ResolveType(Int32, System.Type[], System.Type[])
at System.Reflection.CustomAttribute.FilterCustomAttributeRecord(System.Reflection.CustomAttributeRecord, System.Reflection.MetadataImport, System.Reflection.Assembly ByRef, System.Reflection.RuntimeModule, System.Reflection.MetadataToken, System.RuntimeType, Boolean, System.Object[], System.Collections.IList, System.RuntimeType ByRef, System.IRuntimeMethodInfo ByRef, Boolean ByRef, Boolean ByRef)
at System.Reflection.CustomAttribute.GetCustomAttributes(System.Reflection.RuntimeModule, Int32, Int32, System.RuntimeType, Boolean, System.Collections.IList, Boolean)
at System.Reflection.CustomAttribute.GetCustomAttributes(System.Reflection.RuntimeAssembly, System.RuntimeType)
at System.Attribute.GetCustomAttributes(System.Reflection.Assembly, System.Type, Boolean)
at System.AppDomain.GetTargetFrameworkName()

When attempting to edit the DN generator for a membership list transformation, I received the following error:

Not yet known if the component is not working for other transformations.

The string "C1 Callam Offices, Easty Street, Woden ACT 2606; " was exported to the Placeholder Connector but the returned (confirming) import was "C1 Callam Offices, Easty Street, Woden ACT 2606;", causing ILM2007 to raise a "exported-change-not-reimported" warning.
Sure the data could be trimmed in a rules extension, but this is the same as the bug that was just fixed in the FIM 2010 Portal which was exhibiting the same behaviour (as well as incorrectly converting " " to " "). Whatever gets exported (right or wrong should always come back exactly the same.
The above problem will result in an infinite loop of export/import with Event Broker ... so it becomes a bigger issue when this happens. We're still in the DEV stage right now with CIT ...

Adapter GUIDs are not available in the IdB UI.
,
Connectors are referred to by name

20130501,17:02:58,UNIFY Identity Broker,Adapter,Information,"Adapter import all entities to adapter space completed.
Adapter import all entities to adapter space 6e91a985-feb0-4d17-9ed9-191d9cd85c86 returned 8435 entities. Duration: 00:01:40.6744522",Normal
20130501,17:02:58,UNIFY Identity Broker,Adapter,Information,"Adapter
Adapter 6e91a985-feb0-4d17-9ed9-191d9cd85c86 page started reflection.",Normal
20130501,17:03:15,UNIFY Identity Broker,Adapter,Information,"Adapter
Adapter 6e91a985-feb0-4d17-9ed9-191d9cd85c86 page completed reflection. Duration: 00:00:16.9066828",Normal
20130502,04:10:41,UNIFY Identity Broker,Logging Engine,Information,Log file completed.,Minimal

The MultiRelationalTransformationContribution can take a very long time to evaluate, as the current method re-evaluates the repository for each entity in the page.

According to https://unifysolutions.jira.com/wiki/display/IDBXT306/Multi-value+Distinguished+Name+generator+transformation, the multivalue DN generator introduces a temporary field of MultivaluePart to an entity in order to run the DN generator across every value in a multivalue field. As this is not a field in the adapter schema, the field is not displayed in the dropdown when configuring the transformation, or in the DN generator for the transformation.

As such, a special type of DN generator should be introduced that is able to take a multivalue field in a component generator and produce the multivalue DN field accordingly. The transformation would no longer need to use a temporary field as a result. This would need to be done in such a manner that existing DN generators function correctly, and that it was only in the context of this transformation that the DN generator behaves this way (as multivalue fields in DNs can be used externally and simply print the multivalue as a string).

For Identity Broker 3.* reference attributes are "forward (read) only". It is a standard IdM connector requirement to be able to export to reference attributes. While work-arounds are often (but not always) possible they are clumsy at best, and require double-processing of data (e.g. once for a reference flow, and once or more - in the case of multi-part keys - for a string flow). In most scenarios this requires storing of data redundantly (denormalisation) on the object being exported, and when this is necessary it usually creates additional overhead in deriving this data (e.g. for FIM Portal => FIM Metaverse => Identity Broker for a SQL connected system), e.g. through the use of FIM custom workflow activities. This creates not only inefficiency, but also potential loss of data integrity if there are workflow errors.

This idea came from this issue raised for DEEWR