See PUBEB-75. If an operation list is due to run while the scheduler is disabled, the operation list will run as soon as the scheduler is reenabled, eg. once a week every Saturday night, scheduler disabled, the operation list runs on Monday when the schedule is reenabled.

This is because stopping the scheduler only stops the Timer in the PollingScheduleDecorator. The jobs are polled on the event that the timer is incremented, so this prevents the operation lists from running. However, the NextRun information of timings is not updated, and as such the timings say they are due to run.

The most ideal fix here would be to force timings to run CalculateNextRunAfterTime when the schedule is reenabled to recalculate their next run information. For operation lists marked as QueueMissed, these will need to be added to the queue and executed when the scheduler is reenabled. Although the changes may be minor, they have potentially far reaching effects, and all scheduling options should be thoroughly regression tested following the changes.

This issue will also affect Identity Broker 4.

The screen for creating run profiles.

The browser window title says: "Create Run-Profile Operation - UNIFY Event Broker"
The title in the rendered page says "Create Run Profile Operation"

Pick one and stick with it.

I also think:

Use the form below to finalise the Create process of the run profile operation.

could be a bit more helpful description.

I have seen FIM Exports with web service errors because the DB server was running backups for FIM Sync and Service. Additionally The source data that IB reads (SAS2IDM = SQL view) is on the same server)... I can config exlcusion timeing for IB to exlude the backup window. How do I do the same for EB as I am not using an EB schedule. Becasue I am using change detection I want to config EB to not dtect during exlcuison times. This would stop EB detecting then exporting to FIM MA and the risk of web servie errors in FIM Sync

After creating a FIM agent (Server Name = localhost, Authentication = "Windows and all others are defaults) I attempt to click the "Auto Configure for FIM Agent" button. Upon accepting the prompt I get the following stack track

System.ArgumentException: The parameters dictionary contains a null entry for parameter 'id' of non-nullable type 'System.Guid' for method 'System.Web.Mvc.ActionResult AutoConfigureForFIMAgent(System.Guid)' in 'Unify.EventBroker.Web.AgentsController'. 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.ToArrayTSource(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)

Following from work done for EB-24 and EB-47, the timings have been changed for usability and clarity in configuration, and also for utility in Event Broker. With the addition of exclusion periods to v3.0.0, a number of use cases need to be considered, and the current interface needs to be extended.

In particular, DailyExclusion timing should be updated to account for multiple exclusion periods. Further work needs to be carried out to allow for this functionality, with appropriate error and configuration handling at the factory level, as well as proper functionality as a decorated timing. Specifically:

• Testing of multiple exclusion periods with use cases appropriate to both Identity Broker and Event Broker (as this is a Framework level change to be ported over to Framework at a later date)
• Unit testing for performance of the NextRun given long exclusion periods - this has been carried out
• Refactoring of timing configuration to take multiple exclusion periods in its configuration, rather than decorating itself multiple times - this way, overlaps and potential infinite calculations (eg. the whole day is excluded) can be detected easily at the factory level when the configuration is read, rather than in the operation of the timing (which could be undesirable)

A long requested feature of Event Broker has been the ability to quickly switch between configurations, or to run a different operation list under certain conditions. It would be useful for Event Broker v3 to finally allow for this, or alternatively, allow for more sophisticated branching under certain events (more easily configurable than label operations in v2.2.x).

A use case for the former would be switching between an operation list with logging operations enabled, and one without. This would be useful when testing system configuration using Event Broker to automate ILM/FIM attribute flows, without having to sit through unnecessary logging. Once testing has completed and the Event Broker configuration is migrated to the a production environment, the alternative operation list could be used. There are many cases like this where this would be useful

It should be intuitive and straight-forward to be able to switch between configurations

From QDET-207, it was asked if the clear run history plugin would clear out password change histories. It does not, but appears easy enough to do in the same way we do for clear run history. Carol linked to http://msdn.microsoft.com/en-us/library/windows/desktop/ms696072(v=vs.85).aspx which shows how.

Is there a benefit to having this as a plugin (or incorporated into the clear run plugin), instead of requiring a PowerShell script? Is this something that will be required at more than one site?

The synchronization cookie mechanism used by the AD Sync Changes mechanism can consume large amounts of memory, as the token seems to represent all changes present in the AD instance. This was investigated as part of EB-463 and found to be because of a FindAll call that is required for this mechanism to work (whereas a FindOne may retrieve each change until all changes are finally exhausted). Further investigation may be performed into:

• Any Active Directory level setting which may reduce the size of the cookie
• Programming constructs around the DirectoryServices namespace that will ensure large amounts of memory are not consumed
• Testing of FindOne to confirm whether or not individual changes only will be constantly retrieved, or if the token is successfully updated following a delta import

Perhaps because the application configuration is not set up properly for end-point. However, the agent check never failed at any point, and I'm too tired to go check the end-point configuration for Event Broker service.

Error message is:

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 2: System.InvalidOperationException: Could not find endpoint element with name 'IdentityBroker' and contract 'Unify.Framework.IChangesAvailableAdapter' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element.
at System.ServiceModel.Description.ConfigLoader.LoadChannelBehaviors(ServiceEndpoint serviceEndpoint, String configurationName)
at System.ServiceModel.ChannelFactory.ApplyConfiguration(String configurationName, Configuration configuration)
at System.ServiceModel.ChannelFactory.ApplyConfiguration(String configurationName)
at System.ServiceModel.ChannelFactory.InitializeEndpoint(String configurationName, EndpointAddress address)
at System.ServiceModel.ChannelFactory`1..ctor(String endpointConfigurationName, EndpointAddress remoteAddress)
at Unify.Product.EventBroker.IdentityBrokerChangesPlugIn.GetAdapter()
at Unify.Product.EventBroker.IdentityBrokerChangesPlugIn.Check()
at Unify.Product.EventBroker.StandardOperationListExecutor.RunCheck(ICheckOperationFactoryInformation checkOperation)

The LDAP Directory Changes operation fails with the following exception on execution:

Operation 7b4a99fd-d4f5-42e0-9349-b672b0a83882 failed in operation list with id a0daf801-7960-4946-80c2-1234c7f5672e for the following reason. This is retry number 0: System.ArgumentNullException: Value cannot be null.
Parameter name: sourceElement
at Unify.Framework.XElementExtensions.AttributeValueModify(XElement sourceElement, XName attributeName, Action`1 modifyAttribute)
at Unify.Product.EventBroker.LDAPAgentConfigurationFactory.CreateComponent(XElement factoryInformation)
at Unify.Product.EventBroker.OpenLDAPAgentFactory.CreateComponent(IAgentInformation factoryInformation)
at Unify.Product.EventBroker.AgentEngineRepository.<>c__DisplayClass13.<GetAgent>b__12()
at Unify.Product.EventBroker.ExtensionMethods.WaitOnMutex(Mutex mutex, Action work)
at Unify.Product.EventBroker.AgentEngineRepository.GetAgent[TAgent](Guid agentId)
at Unify.Product.EventBroker.OpenLDAPChangesPlugInFactory.CreateComponent(ICheckOperationFactoryInformation factoryInformation)
at Unify.Framework.ExtensibilityPlugInGenerator`4.CreateComponent(TFactoryInfo factoryInformation)
at Unify.Product.EventBroker.OperationListExecutorBase.RunCheck(ICheckOperationFactoryInformation checkOperation)

This is happening for the LDAP Listen operation too.