Due to the architecture of the agents, and the UI parts for agents, there are multiple usages of Agents names throughout various dictionaries and views.

This is going end up being unmaintainable, e.g. there are 23 different references to the IDB Agent alone.

The actual fix is to have pluggable views, depending on the scope of agents, but in the interim this can at least be cleaned up.

After deleting an operation list that contains a listen operation, every 30 seconds the following message appears:

14/03/2013 5:36:53 AM   Error   Operations      FIM Event Broker        The operation list with id ac850de8-6c4d-48f6-8dcb-050e858f3920 does not exist.

The default configuration is to baseline on start-up; however irrespective of whether this is the correct configuration, it is a dangerous setting for the edge cases where it is incorrect.

To avoid users "clicking through" and accidentally setting up EB to baseline the solution on start-up this should default to false.

The listen operation runs check operation on encountered changes, it should only run the tree.

Currently you can not view the configuration of an operation without pausing the operation list that the operation is a part of. In a production environment, for some clients pausing operation lists is a task that needs approval from clients which may encourage consultants to review the configuration by opening the XML configuration.

It would be ideal if a read-only view of an operation was visible so that the configuration of an operation can be reviewed without the need to pause the operation list or to access the config via the XML config files.

Incorrect operation list ids are being persisted; links should be provided once the FIM MA is configured.

There is no demote/promote operation in the operations menu.

The default configuration makes reference to a "hostname" configuration option which is not valid in cassini. This needs to be removed and the regression test document updated.

Copy Operation List does not copy the listen operation of the target.

Is the filter in the AD/LDAP listen operations sufficient to filter out changes in attributes?