Copy connector function results in polling and getAllEntities timers not to fire

Bob Bradley 4 years ago • updated by anonymous 3 years ago 9

This issue is really 2 issues in one:

  • the Copy Connector function causes duplicate Timing id GUIDs to be generated, and
  • the presence of duplicate Timing id GUIDs cause the corresponding timing node not to fire the connector when the cycle comes around.

So Richard Green - I have just discovered the cause of FIM issue 133 (and most likely 134 as well) - namely multiple connectors with the same polling id GUID, causing the timer not to fire. How they got there I believe was via the COPY CONNECTOR menu option, and I have just proven this (see comments following this issue description).

In the attached configuration, the GUID 43b343ba-a287-401f-b92a-347d572b80f0 appears on 2 connectors' polling Timing nodes, and the GUID 15c3fa6b-cf9e-4fb5-8724-5eae2027da49 appears on several getAllEntities Timing nodes.

The impact of the GUIDs being the same appears to be that the timings count down and then roll over and nothing happens (nothing executed - no log of execution). This would explain why a number of the connectors hadn't reported any changes between the time they were installed to TEST last Friday, and the time the bug report was raised (Wednesday).

I am wondering how many other IdB 4.* implementations out there have this sleeper? As a result I have assigned a CRITICAL status (due to the potential impact), even though I now know the cause of the problem and have implemented a solution.

Edit: FIM Event Broker has been confirmed to generate new id's, and as such is not going to have this issue.

Affected Versions:
Fixed by Version:

Having identified the cause of the problem, I wrote the following script to identify the duplicate id nodes:

[xml]$xml = get-content "C:\Program Files\UNIFY Solutions\Identity Broker\Services\Extensibility\Unify.Product.IdentityBroker.ConnectorEnginePlugInKey.extensibility.config.xml"
$hash = @{}

$xml.ConnectorEngine.connectorconfigurations.connectorconfiguration | % {
    if ($_.getAllEntities.Timing.id) {
    if ($_.polling.Timing.id) {
    if ($_.polling.Timing.Timing.id) {

This failed with a Item has already been added. Key in dictionary exception whenever it tried to add a duplicate GUID to the hash table variable. I then generated a new GUID to replace the duplicate, and reran the above script until I got a clean parse of the file. I used the following to generate a new GUID each time.


Once I had a clean parse, I restarted the Identity Broker service and performed a Copy Connector ... then reran the above script and sure enough:

Exception calling "Add" with "2" argument(s): "Item has already been added. Key in dictionary: '39a71313-c7f2-44cb-b53a-fdd954888b99'  Key being added: 
At line:7 char:9
+         $hash.Timing.Add($_.getAllEntities.Timing.id,"")
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentException
Exception calling "Add" with "2" argument(s): "Item has already been added. Key in dictionary: '04d2471f-4411-4bb2-9f0f-6f4d9d4bddb4'  Key being added: 
At line:10 char:9
+         $hash.Timing.Add($_.polling.Timing.id,"")
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentException

... one error for each of the getAllEntities and polling nodes.

Please confirm these 2 problems and advise if we will be OK to proceed with the corrected extensibilty file - noting that a patch is probably only going to help other IdB 4.* sites now.

Re-assigning to Adam van Vliet having confirmed the cause of the duplicate GUIDs - now need to know if there is only 1 bug to fix, or if in fact you agree there are 2.

Adam van Vliet - I believe this issue needs to be moved to the Identity Broker project, but I presume you will do that?

Adam van Vliet - not wanting to get too far ahead here, but at the same time thinking about desired behaviour, should the IdB service detect the presence of duplicate timing GUIDs on startup and abort startup with an error? I suspect it should (as opposed to a warning) because this sort of problem can obviously go undetected otherwise for quite some time, and result in troubleshooting the wrong aspects of a configuration. While it would mean that you would expect a heap of upgrade issues to arise out of such a change if people don't read the installation notes, I think this would be the lesser of two evils compared to continuing to allow the problem to go undetected. So that could mean a couple of fixes:

  • fix Copy Connector function to generate new guid; and
  • either
    • fix timer processing to throw an error via the UI for a duplicated timing GUID (instead of current behaviour of doing nothing and no error being raised); OR
    • extend startup checks to abort startup of ANY timing GUID duplication, not just those that might have been generated via the Copy Connector feature (e.g. someone copying timing nodes in extensibility config manually)

Carol Wapshere, did you duplicate the connectors at News that weren't correctly running imports?

Huu Tran was the one who created the new connector. Huu can you fill Adam in on how you did it?

No, the Workday employee connector was not copied in UI. It was migrated from DEV environment by copying the whole "Extensibility" folder and modify the database connector and the agent setting accordingly