Once testing is complete the Event Broker configuration is invariably deployed to new target environments, meaning that various configuration components (specifically connection details and file paths) are invalidated in the process. About the only things that (happily) remain consistent from one environment to the next are the various FIM MA and run profile guids ... but just about everything else needs adjustment. The changes I am referring to are generally either (a) to the agents, (b) to (non-run profile) plug-ins.
Some thought should be given to how to improve the deployment experience (or more importantly the integrity of a tested solution) ... conceptually adopting a similar model to the FIM Sync Service's "import server configuration" wizard.

Despite attempts to avoid this, MA Guids invariably have been known to vary between one environment to the next, and in this case any Event Broker operation references to these guids need to be deleted and recreated. To avoid this it would be good if the service were to detect the problem and alert the admin to the need to either replace this with the correct reference or delete the operation(s). An initial comparison against MA name could be used to propose a likely match for the user to confirm - akin to the "partition matching" that happens when you are deploying an AD MA where the AD partition guids are different.

Edit (Adam): The auto-config will also have to be looked at here.

https://unifysolutions.jira.com/wiki/display/EB300/Prerequisites
details on service account permissions
needs write access to 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files'.

Symptom - open browser to verify install (http://localhost:8080)
get error in attachment
check Event Viewer,
see error in attachment 2
grant service account (FIMSyncAdmins group) rights to folder
refresh browser and the EvB web console displays as expected

As per request, the attached screenshots are a list of potential changes to make the breadcrumbs look more separated.

See QDET-203. When trigger members are introduced into an exclusion group, their function is not entirely clear. Consider renaming or changing the functionality of "Normal" and "Trigger" members, or provided some additional information on the UI as to what the current group configuration will mean. This could take the form of a dynamic paragraph describing what will happen, eg.

"Operation Lists X and Y will block operation lists Z, A and B. X and Y will also block each other"

When an export run profile executed for the FIM MA resulted in a "completed-export-errors" return status, the Outgoing Pending Check Operation continued to report on the change pending, resulting in the operation list firing indifinitely. The "success statuses" for the configured FIM Agent correctly includes this status value explicitly, since the failure is for individual export failure(s) and not the batch as a whole.

When an export failure occurs, an indicator is set for the connector space object in the FIMSynchronizationService database, and this should be used as a "circuit breaker" to prevent infinite looping (until the problem is resolved, which may take days/weeks/months ...). However, care must be taken to ensure that once the indicator is cleared, the export is allowed to fire once more ... see https://unifysolutions.jira.com/browse/EB-203 for a detailed explanation of this problem witnessed with EvB 2.0.3 (the fix for which may have inadvertently led to this problem).

While unsuccessful in creating the FIM Agent, I was however able to create Operations and Operation Lists ... albeit incomplete. This was only possible after deleting the ill-configured FIM Agent, as while this was in existence, the following error details were generated:

Error
System.ServiceModel.FaultException`1System.ServiceModel.ExceptionDetail: Access denied (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is: System.UnauthorizedAccessException: Access denied ----> System.Management.ManagementException: Access denied at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
at Unify.Product.EventBroker.FIMAgent.GetManagementAgents() — End of inner ExceptionDetail stack trace — at Unify.Product.EventBroker.FIMAgent.UnauthorizedAccessExceptionHandler(ManagementException managementException)
at Unify.Product.EventBroker.FIMAgent.ExceptionHandlerT(T exception, IEnumerable`1 exceptionHandlers)
at Unify.Product.EventBroker.FIMAgent.GetManagementAgents()
at Unify.Product.EventBroker.FIMAgent.UpdateManagementAgents()
at Unify.Product.EventBroker.AgentRequestResponseEngine.FIMAgentGetManagementAgentsRequestAction(IAgent agent, XElement details, Guid agentId)
at Unify.Pro...).

It is obvious from the stack that the FIM Agent is intended to support retrieval of management agent details, so the question remains what of the FIM MA itself? I am suspecting this is an oversight to some extent ... but I hope it isn't, as it's part of the core FIM configuration itself (a special MA case), with its own run profiles like any other MA, and is the reason for the need for the new FIM Portal Integration plug-in developed by Matt.

Issue hit with Event Broker 3.0.0 RTM. When configuring the FIM Agent in EvB when EvB resides on a FIM synchronisation server and the FIMSynchronizationServer database resides on a separate SQL server, the server name entered in the Database Connection details dialogue must be fully qualified otherwise the error below occurs. Recommend documentation update to include this requirement.

The FIM agent test is failing with the message: "A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - The requested name is valid, but no data of the requested type was found.)". Ensure the agent is configured correctly and the target system is running.

I have a script which works correctly when I run it manually. When run through Event Broker I get this:

Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information

I found APRA-82 with the same problem but can't see what the resolution was after reading through all the comments.

The line that is causing the error is the one where I try and run a SQL query:

Invoke-SQLCmd ($sqlquery -f $timestamp,$MAName,$xmlstring) -SuppressProviderContextWarning

On outbound runs that are scheduled for - say every 30 minutes - only execute the export if there is something to export. i.e. if the export is for a CSV file, and there may or may not be data to send. However, we may want to "wake-up" and attempt to generate an export if there is something to send. Priority is medium.

Bob I can confirm that I have seen this bug when specifying a schedule for an outgoing operation list (no such problem observed when no schedule specified to override the default 10 seconds). The problem report #249 is (kind of) related.