On some employee records in Chris21, Identity Broker cannot read the PDTORG1CD field for an enployee. This field is the "Company Code"
This issue has been around for some time and sometimes seems to resolve itself.
One example that we can see right now is an employee named Dianne Humphreys.
In Chris21 she has a Company code of MAA in the PDTORG1CD field.
When doing and Adapter Entity Search on the Chris21 GTR Person adapter via the Unify Management Studio, I cannot see any value in the PDTORG1CD field for that user.

This error was received when trying to update the phoneProfiles field on the user. Do I need to use the guid or can I use the string representation of the device

20120401,08:54:16,Cisco communicator,Update,Error,"Exception occured after 00:00:00 duration.

System.NullReferenceException: Object reference not set to an instance of an object.
at Unify.Framework.CiscoUserCommunicator.SetAdditionalUpdateFields(XElement updateElement, IConnectorEntity entity)
at Unify.Framework.CiscoCommunicatorBase`1.SetElementFromEntity(XElement requestElement, IConnectorEntity entity, IEnumerable`1 ignoredFields, Action`2 setFieldsAction)
at Unify.Framework.CiscoCommunicatorBase`1.CreateUpdateRequest(IConnectorEntity entity)
at Unify.Framework.CiscoCommunicatorBase`1.UpdateEntity(IConnectorEntity entity)
at Unify.Framework.CiscoCommunicatorBase`1.Update(IConnectorEntity entity)",Verbose
20120401,08:54:16,Save entities to connector failed.,Connector,Warning,"Save entities Count:1 to connector Cisco User Connector failed with reason Object reference not set to an instance of an object.. Duration: 00:00:00.4531250
Error details:
System.NullReferenceException: Object reference not set to an instance of an object.
at Unify.Framework.CiscoUserCommunicator.SetAdditionalUpdateFields(XElement updateElement, IConnectorEntity entity)
at Unify.Framework.CiscoCommunicatorBase`1.SetElementFromEntity(XElement requestElement, IConnectorEntity entity, IEnumerable`1 ignoredFields, Action`2 setFieldsAction)
at Unify.Framework.CiscoCommunicatorBase`1.CreateUpdateRequest(IConnectorEntity entity)
at Unify.Framework.CiscoCommunicatorBase`1.UpdateEntity(IConnectorEntity entity)
at Unify.Framework.CiscoCommunicatorBase`1.Update(IConnectorEntity entity)
at Unify.Framework.CiscoReadWriteConnectorBase`1.SaveEntity(IConnectorEntity entity)
at Unify.Framework.CiscoReadWriteConnectorBase`1.SaveEntities(IEnumerable`1 entities)
at Unify.Framework.ConnectorToWritingConnectorBridge.SaveEntities(IEnumerable`1 entities)
at Unify.Framework.EventNotifierWritingConnectorDecorator.SaveEntities(IEnumerable`1 entities)
at Unify.Framework.Adapter.SaveEntities(IEnumerable`1 entities, Boolean reflect)
at Unify.Framework.Adapter.SaveEntity(IAdapterEntity entity, Boolean reflect)
at Unify.Framework.CompositeAdapter.SaveEntity(IAdapterEntity entity)
at Unify.Framework.AdapterNotifierDecorator.SaveEntity(IAdapterEntity entityToSave)
at Unify.Framework.LDIFAdapter.ExportAdapterEntity(IAdapterEntity adapterEntity, Guid adapterId)
at Unify.Framework.LDIFAdapterServiceHostDecorator.ExportAdapterEntity(IAdapterEntity adapterEntity, Guid adapterId)
at SyncInvokeExportAdapterEntity(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.ProcessMessage4(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)",Normal

The following is logged repeatedly in the IdB LITE demo:

chris21 Agent
Logout failed with the following message:

Unable to cast object of type 'Unify.Product.IdentityBroker.Chris21ErrorLine' to type 'Unify.Product.IdentityBroker.IChris21CommandLine'.

System.InvalidCastException: Unable to cast object of type 'Unify.Product.IdentityBroker.Chris21ErrorLine' to type 'Unify.Product.IdentityBroker.IChris21CommandLine'.
 at Unify.Product.IdentityBroker.Chris21Agent.CheckLogoutResult(IChris21Record logoutResultRecord, IChris21ConnectorInformation connectorRequest)
 at Unify.Product.IdentityBroker.Chris21Agent.CheckLogout(String module, String loginToken, IChris21ConnectorInformation connectorRequest)

Also fix up the following message:

Completed polling successfully after [{0}] duration.

Starting deletion of chris21 EAI change files.

When clicking on edit button inside the connector, it leads to the webpage: http://localhost:8008/Connector/ExtendedUpdateConnector/23d5cb8d-bfce-4519-857a-1bb0f52a1560?plugInId=CSV&currentStepId=InitialUpdateStep and display the following error:

This one seems very simple on the surface, but none of the usual configuration steps are working.

When I try to start the Identity Broker service, the service fails to start with the following error message:

Service cannot be started. Unify.Framework.ConnectorEngineConfigurationException: Connector Engine unable to start due to bad database connection.
at Unify.Framework.ConnectorEngine..ctor(IAdoNetDataControlFactory dataControlFactory, INotificationMessageService messageService, XElement xmlConnectorConfiguration, IConnectorEntityPartitionContextGenerator entityPartitionUpdateableContextFactory, IScheduleCollection scheduler, IAdoNetDataControlGenerator dataControlGenerator)
at Unify.Framework.ConnectorEnginePlugInFactory.CreateComponent(IUnifyEnginePlugInFactoryInformation factoryInformation)
at Unify.Framework.DependencyPlugInGenerator`4..ctor(ICollection`1 plugInGenerator, IPlugInFactory`2 factoryInformationFactory)
at Unify.Framework.UnifyEngine..ctor(IEnumerable`1 additionalPlugInFactories, DirectoryInfo executingAssemblyLocation)
at Unify.Service.IdentityBrokerServiceEngine..ctor(DirectoryInfo assemblyExcutionPath)
at Unify.Service.IdentityBrokerService.OnStart(String[] args)
at System.ServiceProcess....

Data Engine file:

<?xml version="1.0" encoding="utf-8" ?>
<DataEngine>
<dataRepository>
<dataConnection name="sql" repository="Unify.IdentityBroker" connectionString="Data Source=SQLSERVER;Initial Catalog=Unify.FIMIdentityBroker;Integrated Security=True" />
</dataRepository>
</DataEngine>

Connector Configuration:

<?xml version="1.0" encoding="utf-8" ?>
<ConnectorEngine>
<dataConnection name="repository" repository="Unify.IdentityBroker" />
<connectorconfigurations>
</connectorconfigurations>
</ConnectorEngine>

Steps taken:

• Identity Broker service account is set to a domain account
• Domain account is local administrator on IdB server
• Confirmed domain account has owner access to Unify.FIMIdentityBroker
• Distributed Transaction Coordinator is configured on the SQL Server and the IdB server
• SQLServer is a valid alias (connects fine in SQL Server Management Studio), configured under SQL Server Configuration Manager
• Have another 32-bit server in same environment running Identity Broker, connecting to a different database (Unify.IdentityBroker), which runs fine.
• Have tried re-creating the database, re-downloading the IdB service, changing the database name, changing the IdB service account

Is there anything else worth trying here?

With

• any Identity Broker deployment
• polling or non-polling
• with or without Event Broker, and
• for whatever version
  as an implementor you are always making little more than an educated guess as to the appropriate cycle of full and/or delta imports for each of your connectors. This needs to be more scientific, and an opportunity may exist as part of Identity Broker 4 to take empirocal data and suggest refinements (thinking green/yellow/red dashboard style info here) on what would make optimal use of available CPU/network resources.
  Equally, with frequencies recently configured for CSODBB's Peoplesoft (polling) connector for PHRIS, we found that my initial values were on the over-ambitious side. Something to draw attention to the fact that the service was "spinning its wheels" trying to keep up with unrealistic cycles would be useful console feedback (i.e. I summised that the number of queued but unprocessed polling requests was growing because they couldn't be processed fast enough). Ryan had some trouble and called me about it during UAT last week, where memory for the Identity Broker service grew astronomically and delta imports started failing. In the end I think that the resolution was at least partly to do with setting realistic frequencies.

The image node for a composite adapter renders the image node for any contained adapters redundant. However, when the adapter node is excluded from the adapter xml the Identity Broker service fails to start - and an error message is displayed stating that the node is mandatory. When an empty node is added the service still fails to start, but another exception is raised instead. The service will only start when a non-empty image node is included in the configuration.

I noticed the presence of these images (which are not displayed in the Identity Broker Management Studio) when building xsl stylesheets to document the Identity Broker configuration for DEEWR. Not only do they add unnecessary bulk to the configuration, but they can lead to irrelevant images persisting and being accidentally deployed (the images that I found were actually carried over from another project).

As a work-around I have generated a dummy binary string from the smallest PNG file I could find, and used that for all of the adapters that make up my composite adapter.

I believe the image node should only be mandatory for an adapter if it is NOT part of a composite adapter. Given that composite adapters are now likely to be the norm rather than exception, certainly when used with FIM, then this issue is likely to affect more deployments. I doubt whether anyone who has deployed a composite adapter actually realizes what images lay hidden in the nested adapter configurations they have deployed.

After deploying UNIFY Identity Broker for Microsoft FIM v3.0.0 (x86).msi from https://unifysolutions.jira.com/wiki/display/SUBIDBFIM/Downloads and completing my IdB 3.0.6 DEEWR configuration, I was ready to create an instance of the IdB FIM xMA ...

After installing using the default options, I found that:

(a) PDF files cannot normally be opened on a server - we might want to think of an alternative format that can say be opened in Wordpad which is (almost) guaranteed to be there ... I got around this by mailing myself the file from my DEEWR email account which was the only way I could get hold of the file over a VPN. Of course I could have installed this to my XP laptop ...

I've noticed that in general the exception reporting is very good at identifying the cause of a problem, however in the following scenarios it is not:

• when 2 field nodes in the same entitySchema have the same name (obvious error but easy to make when hand crafting xml) the exception raised in the Application Event log (when the Identity Broker fails to start) is simply "The parameter is incorrect". There is no evidence as to what was the problem, nor whether it was an adapter or connector issue;
• when configuring a Relation.Group.Composite transformation, I accidentally included a key reference to a column of the base connector in a dnComponent, instead of a column defined by the RelationshipConnectorID - in this case the IdB service started OK, but when attempting an Adapter entity search an exception "Adapter get all entities for adapter xxx failed with reason 'Specified argument was out of the range of valid values. Parameter name: attributeValue'". Of course there is no such parameter "attributeValue" exposed in the adapter config, so I presume this is internal to IdB. While the text makes sense once you know the problem is with your DN, trying to track this problem down in a composite adapter with many adapters configured is quite problematic.

I'm sure if I was diligent in logging more of these in JIRA I would come up with a few more, so maybe we can keep reusing this JIRA item in the future ... but right now the above 2 are a good start

Export performance is likely to be a major bottleneck for Origin during the "initial load" sync process where FIM is writing back network account and email address to SuccessFactors (SAP HR). Current performance metrics from DEV are not a great guide due to the limited number of employees loaded into FIM for that environment (<50), however the last sizeable batch was 39 user updates in 00:09:50 (a rate of 1 every 15 seconds!!!). When it comes to a full set we are talking upwards of 33K users requiring updates - and at the above rate we will be looking at 8250 minutes, or 137.5 hours, or 5.7 days.

In an attempt to head this problem off in advance of it coming to the attention of the testers, I am thinking that we may have to rethink the way we are applying updates for the initial load.

See linked issue for idea as to how the PS connector architecture might be improved for exports in future.