Found during IDB-197, the changing of the add method to prevent mismatching DNs (see IDBFIM-11) has exposed a new issue with non-required key fields. If a key field is not specified during the save operation (which is valid for systems such as SharePoint List as the target system generates it), null reference exceptions are perpetuated throughout. Estimate includes discovery, environment configuration, debugging and testing time.

Initial error occurred because the array equality comparer did not properly handle null values around hash codes. Fixing this has caused additional null reference exceptions to occur when the connector entity repository is checked to see if the key already exists.

Hi Guys,

While testing last night, I encountered an error with the CUCM User connector.
If an export is made without the 'groupNames' field present, it throws a null reference exception.

If the field is present, the export run's without error and behaves as expected.

I expect this will be straightforward to track down, but regardless, here is the full stack trace from the IDB log:

Save entities to connector failed.
Save entities [Count:1] to connector CUCM User Connector failed with reason Object reference not set to an instance of an object.. Duration: 00:00:00.3788820
Error details:
System.NullReferenceException: Object reference not set to an instance of an object.
 at Unify.Framework.CUCMUserCommunicator.SetAdditionalUpdateFields(XElement updateElement, IConnectorEntity entity)
 at Unify.Framework.CUCMCommunicatorBase`1.SetElementFromEntity(XElement requestElement, IConnectorEntity entity, IEnumerable`1 ignoredFields, Action`2 setFieldsAction)
 at Unify.Framework.CUCMCommunicatorBase`1.CreateUpdateRequest(IConnectorEntity entity)
 at Unify.Framework.CUCMCommunicatorBase`1.Update(IConnectorEntity entity)
 at Unify.Framework.CiscoReadWriteConnectorBase`1.UpdateEntity(IConnectorEntity entity)
 at Unify.Framework.Visitor.Visit[T](IEnumerable`1 visitCollection, Action`2 visitor)
 at Unify.Product.IdentityBroker.EventNotifierUpdatingConnectorDecorator.UpdateEntities(IEnumerable`1 entities)
 at Unify.Product.IdentityBroker.Adapter.UpdateEntities(IEnumerable`1 entities, Boolean reflect)
 at Unify.Product.IdentityBroker.AdapterNotifierDecoratorBase`1.UpdateEntity(IAdapterEntity entityToSave)
 at Unify.Product.IdentityBroker.AdapterNotifierDecoratorBase`1.UpdateEntity(IAdapterEntity entityToSave)
 at Unify.Product.IdentityBroker.LDIFAdapterBase.ExportChanges(ExportedLDIFForAdapter exportedLdifForAdapter)
 at SyncInvokeExportChanges(Object , Object[] , Object[] )
 at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
 at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)

Let me know if I can provide further assistance.

See IDB-302. Identity Broker currently allows you to see each entity that has failed validation on an import, but it is all dumped to the log file. It would be useful if this information could be grouped kind of like the FIM run history shows you individual items that have failed following an import, and logged somewhere such as the connector statistics information.

Schema validation is an instance of a connector import failure that would not cause the entire batch to fail.

While it is often useful to be able to filter records at the connector level, it would be handy to be able to do this at the adapter level as well.

An example is one which occurred at DEEWR where I needed to exclude all CLAIM objects from the Claims adapter where the IsDerived flag was set to 1. Since this was a single adapter/single connector configuration, this was easily achieved at the connector level. However, the side-effect was that this same connector was also being used in another adapter with a different base connector ... to derive group membership style reference properties for a PERSON object. There was one such transformation that needed ALL claims objects (i.e. inclusive of the IsDerived=1 claims) in order to calculate the membership. In my case I had already decidedd to discontinue using the group transformation and achieve the requirement a different way, but this could have forced me down the path of multiple connectors (10s of 1000s of rows) for the same data source.

If this is not already achievable (without configuring multiple connectors for the same data source), please consider this as a feature request.

The following code:

            var values = from rightSideEntity in context.Entities
                         where IncludeEntity(leftSideValues, rightSideEntity)
                         select rightSideEntity;

in MembershipListEntityDistinguishedNameTransformationBase

IncludeEntity method cannot be used this way, as the Entity Repository LINQ expression for function IncludeEntity cannot be transformed into LINQ to SQL.

Fix this issue.

To cut down on the time required to add Move transformations for each field
to ensure that it is LDIF-compliant, it may be useful to give the user the ability to hit a "Make LDIF compliant" button, which would either add a series of Move transformations automatically or add a single LdifComplianceTransformation.

In Identity Broker v3.0.5.6, for the IDB305:Move attributes transformation the use of SourceAttribute and TargetAttribute is in the reverse order (swapped). This caused inconstency with the documentation for <columnMapping>, IDB305:Column mapping configuration and other transformation type such as IDB305:Relational transformation and IDB305:Relational with string priority transformation

Please see -ACGCEO-10- for further details of this issue.

There is a race condition in Identity Broker that can be exhibited by the following:

• Begin a full import against a connected source.
• While full import is occurring, export a new item from the Identity Management platform.
• The full import finishes.
• The change detection takes place and completes.

For some connectors, any export of a new item before the full import finishes will mean that item is not reported in the full import list. This will result in the item being deleted.

For all connectors, if the export of a new item occurs during the change detection phase, it may result in the item being deleted as the item is in the entity repository but not in the list of reported items from the connected source.

For most level 1 compliant connected sources, this will self correct over time, but there may be a window in which the item is in limbo. For level 0 compliant connectors, this will invariably end up with the item being lost, even though it may exist in the connected source.

A common FIM requirement is to be able to provision users based on membership of an AD group. For FIM to be able to do this OOTB would be required that it was possible to define a SET based on the (derived or explicit) ComputedMember collection of a group, but as of a recent FIM build this is now not possible.

In the following thread, Markus Vilcinskas (moderator of the ILM and FIM forums on TechNet) suggests a solution designed to work around this shortcoming: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/a8f5ecea-7375-48da-a920-e4bcea87bba3?prof=required

... and in this thread on the same subject I pointed out that the post marked as an answer to the problem is no longer valid: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/e6661c08-3747-4c99-bb1a-cbba75b89726

At NAB this requirement was satisfied using a custom activity (written by Paul Williams, MVP) prior to UNIFY involvement in the account.

In the end, all of the above mechanisms are really just complicated work-arounds and leave you asking the question ... surely there's a better way?

I am thinking that we could promote the use of the Identity Broker Placeholder Connector to write out both group and user objects with the group.member relationship, and "reflect back" (via a Group.Relation.dn transformation) the "back-link" user.memberOf collection (which confuses everyone when they first see this collection in AD only to find that the memberOf attribute isn't "real" but calculated in AD). The benefit of this approach would be that we could "black box" this solution (it is 100% generic) and it would provide superior performance and simplicity over any of the suggested work-arounds above, especially leveraging the intrinsic delta import capability of Identity Broker which would translate changes to group.member into changes to user.memberOf.

Firstly, can someone confirm that the above configuration will work the way I have described, and secondly (if the assumption is correct) what would it take to package this solution (IdB 3.*, Placeholder Connector, IdB for FIM, pre-generated MA configuration) as a salable commodity to the FIM world?

I am thinking that Peter Wass may have done something like this in the past, but at the time wasn't thinking of how it could apply to this dilemma. Note that this is a special case where the authoritative source of the group.member change is the AD MA. If we had our own Identity Broker for Active Directory MA then we wouldn't need to worry about the Placeholder connector, and could provide this feature OOTB. That might be an even more appealing option, but in the meantime I'm thinking that the only thing stopping the Placeholder Connector option from being a reality is UNIFY buy-in, followed by packaging and marketing ...

As discussed on PRODUCT-64, the Employee and Schedule connectors should be expanded to support all possible attributes.