From Help Desk #404:

The MAs in the Event Broker treeview should be displayed in alphabetical order by default - this would make finding particular MAs much easier

At DET, the workaround was to sort the Server Config XML into alphabetical order, then reimport.

At ACT Edu they have 89 MA's. Each of these needs a global full, delta, and export run profile created. Its currently an all day task, especially if they want to move things around. They would like to be able to copy and paste run profiles between or into the same area (global->global, global->MA) and then modify them as a faster method of getting things moving.

In Event Broker v2.2.3.6, the default LDAP filter for the AD Changes plugin, according to the plugin description, should be:

(& amp ;(objectClass=user)(objectCategory=person))

Instead, it is:

(& amp ; amp ;(objectClass=user)(objectCategory=person))

Spaces added

This results in the plugin never detecting changes. This is easily fixed by updating the LDAP filter and removing the additional "amp;".

I believe this may be already incorporated into Event Broker v3

Currently at ACT Edu they have 89 MAs. They are called the same thing in Test and Prod. They would like to be able to export the configuration from Test and import it into prod rather then rebuilding it each time. This would also be very useful as a 'backup' feature for eventbroker, as well as for consultants deploying solutions in the field.

Framework Core currently contains several timings that are useful for Event Broker, however, they aren't currently configured to allow for multiple sets of each amount (eg. every 3 weeks). Event Broker could be configured to simply insert multiple timings where longer times are needed, but it would be more robust to extend the current timings to account for multiples.

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.