The fact that the scheduler service is not running does not prevent the FIM custom workflow from firing the nominated Event Broker operation list.
While this arguably makes sense when you consider that this is the only non-polling interface for EvB, it was still unexpected because it would be fair to say that most FIM administrators would expect that stopping the scheduler should disable all interaction with FIM.
This issue probably falls into the "traps for young players" category, as there is an easy work-around as long as you remember to ALSO disable the corresponding FIM MA (inbound) operation list. My point is that I expect 9 out of 10 admins will be a victim of this oversight unless this "feature" is not spelled out clearly somehow.
Unless this feature was unintentional, then we probably need to talk this one through to decide what's best to do here ... agreed?

Where an external call to run an EvB operation fails due (for example, a run profile execution return code of "no-start-ma-already-running" from the FIM Sync service) then this request can be queued for retry if the operation list is configured to do so. In such a circumstance this queued request is not presently visible to the Event Broker administrator, and consequently there is nothing telling him if he needs to manually invoke the operation list him/herself. This situation will also occur with the planned intro of a new non-polling change trigger for Active Directory.

Some way is required for these pending triggers to be visible to the administrator, including:

• number of queued requests (if indeed more than one may be present - may not be applicable)
• age of (oldest) request
• expected time until request will be cleared (with a retry)
• reason for request being queued

Possibly the ability to flush all queued requests would be sensible too.

At present - particularly after an export to the FIM Portal via the FIM MA - you can be watching the FIM Identity Manager Console for some time before you see the confirming delta import/delta sync fire, and something that can help identify the cause of any delay would be enlightening.

I have configured an Agent for AD, which is currently not working. See EB-293

It continued to peridically perform the TestConnection() operation, eventhough the associated Operation List are disabled. This of course keep writing the warning/error to the log entry and it make it harder go through the log trying to diagnose other issues.

Is there a way to disable the TestConnection() when we definitely know that the Agent is not working and should only enable once we know that it is working again?

I am not certain disabling the Agent itself has other implication to the Operation List that are enabled and use this agent.

So I thought I ask this question.

I am unable to delete check operations in RC1 in the Test 1 environment. Error is as follows:

System.ArgumentException: The parameters dictionary contains a null entry for parameter 'operationListId' of non-nullable type 'System.Guid' for method 'System.Web.Mvc.RedirectToRouteResult DeleteCheckOperation(System.Guid)' in 'Unify.EventBroker.Web.OperationController'. An optional parameter must be a reference type, a nullable type, or be declared as an optional parameter.
Parameter name: parameters
at System.Web.Mvc.ActionDescriptor.ExtractParameterFromDictionary(ParameterInfo parameterInfo, IDictionary`2 parameters, MethodInfo methodInfo)
at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
at System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext controllerContext, IDictionary`2 parameters)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters)
at System.Web.Mvc.ControllerActionInvoker.<>c__DisplayClass15.<InvokeActionMethodWithFilters>b__12()
at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodFilter(IActionFilter filter, ActionExecutingContext preContext, Func`1 continuation)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodWithFilters(ControllerContext controllerContext, IList`1 filters, ActionDescriptor actionDescriptor, IDictionary`2 parameters)
at System.Web.Mvc.ControllerActionInvoker.InvokeAction(ControllerContext controllerContext, String actionName)

The v3.0.0.0 service is running.

I went to install v3.0.0.1 and get an unhelpful error message from the installer.

The installation log is attached to this issue.

I will also include a screenshot, and will also confirm if stopping the service first allows this installation to proceed.

As you shrink the size of the screen the page eventually begins to deform, in particular the tab navigation.

Its not a big issuenbut it would be nice if it all scaled down more cleanly. While I havent tested it on a mobile browser, it wouldnt surprise me if the scaling issues I'm seeing on a desktop browser would make the site unusable on a mobile device. It might not be in scope, but if the top menu scaled ok the rest of the site might actually work pretty well on a standard mobile device which could be useful for remote administration.

Seems to be an issue when you drop bellow about 640px, which means its not an issue for desktops. As noted I havent actually tested on any mobile devices.

Commit operations serve no purpose when there is no check/listen operation of the corresponding type.

As such, the available operations in the tree should at least be filtered to match the selected check or listen operations.

This raises questions about the viability of the commit operation as an operation altogether, namely:

An operation consists of a name (not particular useful for a commit), retry wait (it'll never fail), retry count (it'll never fail), and child/next operations for which the use thereof for commit operations is dubious.

It may be worth considering giving an operation list something along the lines of exit conditions, where it could:

DoNothing
CommitChanges

based on whether it Suceeded.

Alternatively, it could just automatically do that behind the scenes.

Either way, this wouldn't break the role of a check operation with regards to the operation list, namely because the operation list already knows about and works with it's check operation directly.

A useful feature as suggested by Bob would be for the Powershell script to not only register the workflow, but also to add some default MPRs for data and rule changes. These MPRs could then have the configured workflow added, without needing to modify any existing MPRs.

Currently the time it takes to search through the logs for a recent event feels a little sluggish - with more operation lists / events happening at once it may end up being very difficult to find the details of a particular event.

This could be alleviated by the introduction of search parameters:

e.g. OR / AND / TO-FROM etc.

Additionally, the Logs action should facilitate the search filters in its parameters, such that external pages can redirect to it. This would allow for the following:

e.g. An operation list has run, a little yellow arrow comes up next to the last-run details and it redirects to the log action with the a filter similar to:

<opListGuid> AND <opListName> AND time TO-FROM endtime

Which would adequetly describe the logged details of the run.

I have been running a PowerShell script (attached) without a problem for some time, but now that I have added parameters for the first time I am unable to pass values for these parameters to the script without getting the above error.

The script is attached, and the plug-in parameters are being specified as follows:

Module Path: \\EDMGT051\D$\Scripts\FIM.ScriptBox\FIM Object Visualizer\Reports\DEEWR.Requests.Today.ps1
Script Parameters: -pdb EDMGT053 -pdbinstance FIMSQL

I am following the mouse-over instructions, and have tried all combinations I can think of (including renaming to lower case params, including quotes, using local file path) - all without success.

Assuming others are able to use this OK, can I please have some assistance with this as it will remove the need for the DEEWR admin to edit the scripts when deploying to other environments?