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.
Customer support service by UserEcho