It is currently not possible to tell whether a check operation registered changes outside of going through the EventBroker logs. This could be alleviated by simply adding a Changes Registered field in the Last Run Statistics.

Examples of when this may become an issue include:

1. The operation list executes too quickly for changes to be displayed.
2. The EventBroker operator is away from the computer while the operation list executes and no warnings/errors appear.

A confirmation dialog box does not appear if an agent is deleted in IE6.

The log viewer isn't entirely clear what time zone the log items timestamps are being displayed in. This could be improved by informing the user of the time zone, and potentially allowing swapping between local/browser and UTC times.

When setting a schedule in EB it tels me to enter the frequency as "hh:mm:ss". So I tried entering "24:00:00" for 1 day, and instead that was 24 days/ Seems to comment should probably say "dd:hh:mm".

The images in the Operation details page flicker quite substantially, which appear to be in time with the page refresh.

I just shared a remote desktop session with Henry and his customer and he showed me what he described as a problem whereby the eDir and AD agent dialogs were seemingly being confused. This is hard to explain - basically when he had set up an eDir agent and tried to view the details, the labels were what you would expect for an AD agent, and vice versa.

Firstly I am logging this call on Henry's behalf because he doesn't yet have an Atlassian ID (he told me that Shane Day had organised something and that he should have had an email from the website by now, but there has been no email, and there is certainly no evidence of a Henry.Schleichardt user id). Henry has promised to email me with the details, but until he does, this issue serves as a placeholder for that further info.

What I then did was tell Henry to save a backup of his Extensibility folder, and then to delete all agents/connectors/groups - which he did. I then got him to recreate the FIM agent, then the AD agent, and check that it worked and fired the correct AD MA in FIM - which it did (although we couldn't get this working with Authentication type = Secure, and had to use Basic ... but that is another issue entirely - right now working with Basic was adequate).

So then with this working I got him to examine the created configuration and check that all the details were as expected - inspecting the LISTENER and the CHANGES settings for the first AD MA.

I then got him to repeat the exercise for eDir - and here is the first evidence of the problem ... when we chose "LDAP Agent" from the list of agents and clicked CREATE AGENT, Henry entered the name of the agent and the server DNS name ... then when he selected "Basic" from the drop-down list we were presented with the following fields to complete:

• Domain
• User
• Password
• Repeat Password

The problem of course is that the first property "Domain" is redundant here, since the user name being entered is in its full DN format (Henry's screenshots will show you this - details as he is using in the eDir MA's connection details itself). Since this field is shown as MANDATORY, we had to enter SOMETHING - I suggested that this looks like a bug but for the time being we could re-enter the server DNS name. This was accepted but of course when we enabled the operation it failed.

So at this point we are stuck with not being able to configure the agent correctly for eDir. We also tried anonymous, but this didn't work in this case either (we weren't sure if some level of anonymous was allowed, but it appears not - it was a long shot regardless!).

For the time being I have advised Henry to simply delete the check operation and to run the eDir DI/DS run profile at intervals of say 10 minutes.

Could you please have a look at this Agent with an eDir instance (I believe Eddie Kirkman has a working instance of one if you need one) and see if you can see the same problem? Ideally then get back to Henry asap with either advice on what he/we have done incorrectly or a patch to fix what could be a bug.

Add a WMI dependency to service installer.

http://wix.sourceforge.net/manual-wix3/wix_xsd_servicedependency.htm

The issue occurred by following the Regression Test Document (https://unifysolutions.jira.com/wiki/display/INTEB/Regression+Test+Document) test# 6.3.9.3. The operation list was set to fire every two seconds.

After selecting the Exclude this time period on the selected days... under Schedules (with Start time 00:00:00, End time 23:59:59 and all Exclusion days selected) the CPU reached 100% usage and the interface stopped responding. This only seems to happen when the time is first created or the service is restarting. After a long period, the interface responds again and correctly displays that the timing should never run. Subsequent attempts to view the next run do not slow down.

A problem with Event Broker 3.0.* which needed to be resolved for the DEEWR deployment was how to handle the (special) run profile return status of no-start-ma-already-running to ensure that FIM MA delta import/delta sync run profiles. The solution implemented was along the lines of the advice offered by Matt (refer https://unifysolutions.jira.com/browse/EB-381?focusedCommentId=17596&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17596) involving the use of a secondary FIM agent for use exclusively by the FIM MA Operations invoked externally by FIM Portal workflow. The new agent, with the no-start-ma-already-running run profile return status excluded from its success status list, was otherwise identical to the existing FIM agent in order that any externally invoked operation list would raise an exception in the Event Broker logs, thereby enabling these operations to be marked as "Queue Missed" so that Event Broker would retry once the MA was free to run.

The implementation of the above solution has several unwanted side effects (such as the editing/creating of run profile Operations for ANY MA forcing you to re-specify which of the 2 agents to use), as well as complicating the deployment of Event Broker to meet what will be a standard requirement of EVERY Event Broker 3.* deployment involving the FIM MA (i.e. Portal).

A more standard/transparent approach is requested which could avoid the need to define a secondary FIM agent, and thereby streamline the configuration in a repeatable "standard FIM MA configuration" for other FIM sites. My thoughts around how this might be achieved involve the following:
1. Extension of the FIM Agent schema to include an additional "Retry Statuses" property for which the default value of no-start-ma-already-running could also be retained in the existing "Success Statuses" but allow special handling (see below);
2. Operation handling to be enhanced to use the new "Retry Statuses" property to enable the event to be logged as a warning as opposed to an exception (in one day's processing @ DEEWR there were 114 exceptions logged, and of these 99 were cases of no-start-ma-already-running), but still observe the "Queue Missed" property if set for that MA.