Google Apps Connector has an issue that when we import (with primaryEmail as key) it import users as duplicates. Those records are not duplicate in the data source, I have verified it by reviewing the data via Google App admin portal.

I have marked it as blocker as it prevents us from importing/exporting data from Google Apps and blocking our DEV and TEST activity.

Currently the SharePoint Broker causes the startup of Identity Broker to fail if a connection can not be established to sharepoint (see error below).

This is not ideal behaviour as it places a dependency of Identity Broker on the SharePoint server being available. Realistically, even if SharePoint is not available, other systems may be and the inability to connect to SharePoint should not prevent data synchronization between HR, SQL or any other systems.

The issue is documented already, but I think if possible we should at least allow Identity Broker to start, as we do with other systems. https://unifysolutions.jira.com/wiki/display/IDBSP305/Identity+Broker+Service+fails+to+start+or+a+full+import+fails+due+to+a+permissions+error

The current work around is to remove/comment out the connector and any adapters completely.

Service cannot be started. Unify.Framework.UnifyServerInitializeException: Could not connect to http://sharepoint/_vti_bin/unify/userprofile.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.0.133:80.  ---> System.ServiceModel.EndpointNotFoundException: Could not connect to http://sharepoint/_vti_bin/unify/userprofile.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.0.133:80.  ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.0.133:80
   at System.Net.Soc...

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.