From CSODBB-222, the following exception may occur for the AD Sync Changes operation:

System.DirectoryServices.DirectoryServicesCOMException (0x800700EA): More data is available.
at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext()
at System.DirectoryServices.SearchResultCollection.get_InnerList()
at System.DirectoryServices.SearchResultCollection.get_Count()
at Unify.Product.EventBroker.ADSyncChangesPlugIn.GetChanges(DirectorySearcher searcher)
at Unify.Product.EventBroker.ADChangesPlugInBase.Check()
at Unify.Product.EventBroker.OperationListExecutorBase.RunCheck(ICheckOperationFactoryInformation checkOperation)

This can be fixed by adding the following configuration to FIM Event Broker:

  <configSections>
    <section name="system.directoryservices" type="System.DirectoryServices.SearchWaitHandler, System.DirectoryServices, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </configSections>
  <system.directoryservices>
    <DirectorySearcher waitForPagedSearchData="true" />
  </system.directoryservices>

When reconfiguring the FIM Maintenance settings the following exception is thrown:

System.ServiceModel.FaultException: An operation list with the name of 'Baseline for FIM Agent' already exists.

Server stack trace: 
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Unify.Product.EventBroker.FIM.IFIMAutoConfigurationEngineCollector.SaveFIMMaintenanceConfiguration(FIMMaintenanceConfiguration maintenanceConfiguration)
at Unify.EventBroker.Web.AgentsController.SaveMaintenanceSettings(FIMMaintenanceSettingsViewInformation maintenanceConfiguration) in c:\TeamCity\buildAgent\work\e1e11e299a05c3e1\Source\Unify.EventBroker.Web\Controllers\AgentsController.cs:line 1419
at lambda_method(Closure , ControllerBase , Object[] )
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)

Present Event Broker behaviour when the scheduler is shut down while operation lists are still executing is to invoke configured retry processing on each operation if there has been a failure in that operation. Under these circumstances a run profile operation which is forced to stop by an operator using the FIM Identity Manager console automatically starts again, and the operator is forced to stop the run profile a second time. Presumably this would have also been a third time if not for the resultant communications error which resulted:

Management Agent: Claims MA - Run Profile: Full import and full synchronization
0 of 2 Operation faulted: Operation for management agent with id 37818139-7ef0-4a70-a16a-046aff0d5226 with name Full import and full synchronization failed with result stopped-user-termination-from-wmi-or-ui - Please see the log viewer for more details.
1 of 2 Operation faulted: Operation for management agent with id 37818139-7ef0-4a70-a16a-046aff0d5226 with name Full import and full synchronization failed with result stopped-user-termination-from-wmi-or-ui - Please see the log viewer for more details.
2 of 2 Operation faulted: Operation for management agent with id 37818139-7ef0-4a70-a16a-046aff0d5226 with name Full import and full synchronization failed with result connection-failure - Please see the log viewer for more details.

Although this scenario is not limited to "start-up" operations lists, this behaviour is most likely to be a "nuisanse" in start-up conditions than anywhere else ... for instance the operator discovers a problem during start-up of the EvB scheduler, and wants to shut down all FIM operations. Turning off the scheduler is only the start ... followup actions are always required (which are tedious and sometimes unpredictable) in order to bring all EvB operations to a complete stand-still.

Although I very much doubt it, perhaps under some circumstances you might want retry to continue to work at an operation level, but more times than not this would be unwanted behaviour (you are trying to shut down ... if you wanted things to continue you would disable everything else).

John Hennessy (DB Guru) from DET has been looking at the SQL CPU load created by Event Broker v 2.2.3 when it polls the FIM database for pending exports. One thing he noted was the SQL query that searches the connector spaces for pending exports. He said it seems inefficient in that it checks every record in the connector space table (which contains all connector spaces) for being the correct MA and a pending export. I think he's saying it would be more efficient to find all the entries for the MA, then check that set for pending exports. I imagine this wouldn't have been too significant in most environments but at DET some of the FIM instances have 10+ MAs with ~500-900 thousand objects in each. There's also some indexing stuff he was talking about. He's getting together some more formal statistics and we (Eddie, Richard and I) told him that the product team would be interested.

There was also some confusion about the frequency of the polling for pending exports. It seems as in the attached screen shot that you have two options.

1. Click 'Autorun on Outgoing Provisioning Pending'
or
2. Set a schedule to run the operation list

Both of these options aren't ideal in the DET environment with 10+ MAs. We don't want to set a scheduled export that runs whether there are pending exports or not and it seems that the Autorun option polls the connector space more frequently than what would be ideal.

There'll be more actual numbers to come.

I've noticed that another consultant has a FIM Event Broker operation list that runs under more or less the following arrangement

• Perform import of an MA
• Run a powershell script
  • On Failure stop operation list
  • On Success continue
• Run additional operations

The sole purpose of the Powershell script in operation 2 appears to be to check the outcome of the first operation and to throw an exception under certain conditions (in this case the import had no changed in it). The later operations are task that are redundant if no import occurred, such as using scripts to log the outcome of operation 1.

Essentially the consultant has implemented an "if" condition to the operation list by having an operation that is dedicated to throwing errors and ceasing additional operations from running under a specific condition.

My issue with this approach is that in order for step two to function, an exception has been thrown. This exception will appear in the logs as an error, resulting in this case in 100's of errors appearing in the solution on a daily basis. My very strong belief is that in this circumstance, no actual error has occurred and as such, it should not be reported in the logs.

The actual intention though is interesting and one that may in fact be useful. As such, I'm wondering if we can 'fail' a Powershell operation without throwing an exception. In 3.0.X I've tested using a Powershell script that consists purely of

exit 1

This is treated as a success by FIM Event Broker and the subsequent operation runs.

Could we add exit codes as a failure condition to the Powershell activities. There are possibly a number of scenarios where we may want to handle some sort of conditional statement without having exceptions thrown, populating the logs and perhaps suggestion there is an underlying issue when there isn't one.

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.