The FIM Portal workflow generation script specifies the machine name but in my testing only the localhost identifier was sufficient.

Exception in post-processing request:

Forefront Identity Manager Service is not able to serialize this XOML definition:
'<ns0:SequentialWorkflow x:Name="SequentialWorkflow" ActorId="00000000-0000-0000-0000-000000000000" WorkflowDefinitionId="00000000-0000-0000-0000-000000000000" RequestId="00000000-0000-0000-0000-000000000000" TargetId="00000000-0000-0000-0000-000000000000" xmlns:ns1="clr-namespace:Unify.Product.EventBroker;Assembly=Unify.EventBroker.PortalWorkflow, Version=3.0.0.0, Culture=neutral, PublicKeyToken=84b9288cb2633de4" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
xmlns:ns0="clr-namespace:Microsoft.ResourceManagement.Workflow.Activities;Assembly=Microsoft.ResourceManagement, Version=4.0.3594.2, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
	<ns1:EventBrokerChangesActivity x:Name="authenticationGateActivity1" EndPointAddress="http://FIMEVENTBROKER:59990/EventBroker/EventBrokerManagementStudio.svc" OperationListName="{x:Null}" EndPointConfigurationName="ServerNotifications" Description="Invokes a specified Event Broker operation list. This activity should only be used to specify either an incoming operation list for the FIM Portal MA, or to point at a baselining operation list." OperationListGuid="aba8517a-92e8-41b6-8e5d-5468e12f8bbf" />
</ns0:SequentialWorkflow>'.

Unable to to install Event Broker Changes Activity due to PermissionDeniedException.

I am logged in as the FIMService account, which is also an administrator of the FIM Portal.

When I run the ConfigureEventBrokerChangesActivity.ps1 script I get the following error:

Import-FIMConfig : Failure when making web service call.
SourceObjectID = dc42094d-0f86-4035-8a98-38b3520669c9
Error = Microsoft.ResourceManagement.WebServices.Client.PermissionDeniedException: Policy prohibits the request from co
mpleting. ---> Microsoft.ResourceManagement.WebServices.Faults.ServiceFaultException: Policy prohibits the request from
 completing.
   at Microsoft.ResourceManagement.WebServices.ResourceFactoryClient.Create(Message request)
   at Microsoft.ResourceManagement.WebServices.ResourceFactoryClient.Create(Create createBody)
   at Microsoft.ResourceManagement.WebServices.Client.ResourceTemplate.CreateResource()
   --- End of inner exception stack trace ---
   at Microsoft.ResourceManagement.WebServices.Client.ResourceTemplate.CreateResource()
   at Microsoft.ResourceManagement.WebServices.ResourceManager.CreateResource()
   at Microsoft.ResourceManagement.Automation.ImportConfig.Create(String objectType, List`1 changeList)
   at Microsoft.ResourceManagement.Automation.ImportConfig.EndProcessing()
At C:\Program Files\UNIFY Solutions\Event Broker\Portal Workflow\ConfigureEventBrokerChangesActivity.ps1:67 char:27
+ $fimAIC | Import-FIMConfig <<<<
    + CategoryInfo          : InvalidOperation: (:) [Import-FIMConfig], InvalidOperationException
    + FullyQualifiedErrorId : ImportConfig,Microsoft.ResourceManagement.Automation.ImportConfig

Is there anything that I am missing? My assumption is that the administrator account should have permission to do this. If this is not true, then we should document how to change this permission.

As per EB31:Active Directory Sync Changes, the plugin was designed to include tombstone objects as part of the check. Confirm this functionality is working.

Might pay to double check the code, as I seem to recall setting a property for this, as well as testing it myself.

When running ConfigureEventBrokerChangesActivity.ps1 the green bar across the top of the PowerShell script window says:

Importing change {0}
Importing change 1

One of the largest tasks when managing the operations of Event Broker is operating on its schedule. From week to week, the schedule for a system may change as backup schedules change, clashes are found, or implications for other systems are discovered. In large solutions, it can be a number of months before a suitable schedule is decided on such that all interested parties are not affected adversely, and that all operations are given fair time to complete unhindered.

This process is quite arduous due to v2.2.x's scheduling interface, and the fact that schedules are stored all over the place. To get a full picture of what operations occur during a week, for instance, you need to manually check every operation list, and draft a schedule for yourself. This could be made much more efficient by having a mechanism for displaying a week or a month's schedule.

It would also be useful to have highlighted areas where contention or clashes occur regularly. For instance, if a weekly full sync is constantly clashing with export operations, it would be useful to have at the very least some sort of notification for this sort of behaviour, and perhaps suggestions of suitable times for these to run.

Moreover, it would be useful to highlight when an operation is taking much longer than expected. Event Broker could calculate the average run time for an operation, and feed back when the operation takes far longer than this amount of time.

While this may be "visions of grandeur", having Event Broker make scheduling much "smarter" would be a big step forward in the maturation of the product.

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.