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.

In the development of the Event Broker Changes UI component, an attempt was made to retrieve a list of operation lists from the Event Broker service, to avoid the need to insert the operation list identifier into the interface (Guid). However, the FIM portal seemed to struggle with the service contract reference in the UI, for no clear reason. Debugging UI components in the portal proved to be quite difficult, with trace logs not even revealing the source of error. In the interest of progress, further research into this was cut, but may be revisited at a later stage.

The check operation for an identity broker operation has failed with the following error message:

Operation aefb9eb8-b07c-4331-97f8-f818af653f89 failed in operation list with id 24120bff-cc78-4154-80af-81d708957f0b for the following reason. This is retry number 0: System.IO.FileNotFoundException: Could not load file or assembly 'Unify.Framework.ConnectEngine.Client, Version=3.0.0.0, Culture=neutral, PublicKeyToken=84b9288cb2633de4' or one of its dependencies. The system cannot find the file specified.
File name: 'Unify.Framework.ConnectEngine.Client, Version=3.0.0.0, Culture=neutral, PublicKeyToken=84b9288cb2633de4'
at Unify.Product.EventBroker.IdentityBrokerAgentFactory.CreateComponent(IAgentInformation factoryInformation)
at Unify.Product.EventBroker.AgentPlugInGenerator.CreateComponent(IAgentInformation factoryInformation)
at Unify.Product.EventBroker.AgentEngineRepository.<>c_DisplayClass13.b_12()
at Unify.Product.EventBroker.ExtensionMethods.WaitOnMutex(Mutex mutex, Action work)
at Unify.Product.EventBroker.AgentEngineRepository.GetAgent(Guid agentId)
at Unify.Product.EventBroker.AgentEngineRepository.GetAgentTAgent(Guid agentId)
at Unify.Product.EventBroker.IdentityBrokerChangesPlugInFactory.CreateComponent(ICheckOperationFactoryInformation factoryInformation)
at Unify.Framework.ExtensibilityPlugInGenerator`4.CreateComponent(TFactoryInfo factoryInformation)
at Unify.Product.EventBroker.StandardOperationListExecutor.RunCheck(ICheckOperationFactoryInformation checkOperation)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value HKLM\Software\Microsoft\Fusion!EnableLog (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value HKLM\Software\Microsoft\Fusion!EnableLog.

This is kind of a downer trying to test the Identity Broker plug-in.

The ability is required to rename management agents in the tree-view when there is a rename in the corresponding ILM configuration. Presently any existing configuration for a renamed MA can be exported and re-imported to resolve this as a work-around - otherwise it becomes "orphaned".

The following shortcoming has always been addressed by educating the ILM administrators to always stop/start the Event Broker service either side of a config change. However, it is worth consideration if a feasible solution can be found ...

One of the ongoing problems with UNIFYNow is that it will run a "Delta Sync" MIIS run profile that would otherwise throw a warning in the management console to say that a "Full Sync" is required. As a result, a warning is written to the event log that a delta has run when a "full" should have been run first - and this has the potential to damage MIIS integrity!

We have known for some time that the MIIS console raises this error if it detects that the MA version number has been incremented. The version number can be incremented in a number of ways, including the following:

The MIIS Config is changed directly, either via the console or an import/update from XML
An extension DLL is updated, or our config file is changed - both of which live in C:\Program Files\Microsoft Identity Integration Server\Extensions
The problem for us is that the MA version number is only exposed by a SQL query on the MIIS database, and this is not 100% reliable.

The idea I have is that we can use exactly the same mechanism as MIIS does to cover MOST of these (i.e. all except the one where the MA configuration is actually changed directly. This involves using a .Net file listener on the MIIS Extensions folder. This could be used in conjunction with my previous proposal of running a SQL check on the MA version number.

What we should get the UNEE service to do when it detects this scenario is to check the corresponding OpList configuration somehow to see what alternative action (e.g. Full Import Sync run profile) is required in this circumstance - the default action would therefore be to continue processing as it currently does, and allow MIIS to throw the warning (if this wasn't configured).

The following is an example of the warning written to the application event log:

Event Type: Warning
Event Source: MIIServer
Event Category: Management Agent Run Profile
Event ID: 6127
Date: 19/05/2006
Time: 11:53:45 AM
User: N/A
Computer: UNI-MIIS-01
Description:
The management agent "Domino Person ACC MA" completed run profile "Delta Import Sync" with a delta import or delta synchronization step type. The rules configuration has changed since the last full synchronization.

User Action
To ensure the updated rules are applied to all objects, a run with step type of full synchronization should be completed.

While errors and general events on the server will be logged with the standard UNIFY logging mechanisms, the same does not apply to the Web Studio. Some kind of logging mechanism will need to be created so unhandled exceptions are logged in an appropriate manner so they can be addressed by the product group.