The timing components in Unify.Framework need to be upgraded with a property that calculates a DateTime value of the next time the timing is expected to execute.

As we're using a released version of Framework, the appropriate classes will need to be pulled in to the Event Broker solution, modified and integrated back in to a future version of the framework (e.g. v3.1.0).

Estimate includes development, testing and re-integration in to framework.

The ability to copy operation lists would make configuration of Event Broker much simpler. It would be useful for EB-39 in allowing operations lists to be easily reconfigurable, as well as to avoid repetition between similar systems (eg. if the same operations are carried out for 10 Active Directory systems, it would only be a matter of changing the agent, rather than recreating the operation list from scratch)

The current setup for the WeeklyExclusion timing allows a user to specify days of the week when the timing should not fire. However, for Event Broker v3.0.0, consider the following use case:

Not between 4pm and 7pm on Thursdays

The current setup as per Framework v3.0.1 to present instead does the following:

Not on Thursdays or between 4pm and 7pm any day

The first case may be a more desirable case, although both should be accounted for.

The DatesException timing needs to be updated similarly to the DailyExclusion timing changes. This includes:

• Sufficient unit testing to match similar use cases
• Allowance to specify multiple exclusion periods

System administrators prefer to observe activity and errors through existing monitoring tools, such as SCOM. The value of Event Broker (and our entire product range) in an Enterprise would be greatly improved by permitting this.

There has been talk about this, but should there be an auto-configuration wizard/generator for any part of version 3? I think the initial idea was to create an operation list for every detected MA.

In particular, this could be useful for the FIM Portal custom activity, which requires a full baseline operation list - containing a full sync operation for every detected MA (I imagine you could do this by checking the step details of a run profile). Would this be something worthwhile for v3.0.0, or is it something that should be put off/avoided?

The ability to export/import configuration for individual MAs, not just the whole Event Broker solution, would save time.

Migrated from Helpdesk #331

A new attribute to be added to the schema of both Operation and Operation List object classes, and a corresponding free text field placed in the UI, in order to allow Event Broker configurations to be documented. This attribute is to be optional and not to have any bearing whatsoever on the operation of the service or console - purely to serve as "self documentation". Server export/import functionality will need to be extended to include this new attribute for both classes.

This will also provide a means of diarising any post-deployment changes to a configuration in any given environment, as well as the initial deployed configuration by the original implementor.

We're using the OpenLDAP MA in anticipation of having the Identity Broker for TAM MA ... there is no change detection mechanism for this, and this would be handy from a "third party sales of Event Broker" perspective, even though it is questionable as to its present desirability on the DET/IBM contract .

As some plug-ins will require x86 DLLs (and sometimes x64 DLLs), specific x86 and x64 platform installers should be supplied.