Scenario: Run Profile Operation, followed by a PowerShell Script Operation, followed by a Run Profile Operation;

The Run Profile Operation is executed, Success/Failure is evaluated, PowerShell command then runs. The 2nd Run Profile Operation appears to occur immediately, without a wait for the PowerShell operation to complete. There does not appear to be any evaluation of if it was Success/Fail.

I've upgraded IDB5.0.4 to 5.1 RC in the TAFE development environment and it now appears that the Event Broker 3.2 IDB Check Changes functionality no longer works.

Getting the following errors:

When a FIM Event Broker configuration includes an incoming operation list for the WAAD (OOTB Windows Azure AD) connector, a check operation is required which can be used to poll AAD for changes.

Hi Gents,

We've had an issue in PROD at DET - essentially as part of a new deployment, EVB configuration from DEV was deployed, the service started and then left for a period with the scheduler in a paused/stopped state. The credentials for the agents were not updated at that time.

In this case, the credentials on a bunch of the AD agents used the same account names as in DEV but (obviously) different passwords. Also DET has an across the board policy on service accounts including lockouts.

As such, after running in this state for a while, we discovered that the AD service accounts in-use had become locked out/disabled. Unfortunately for us, one of those accounts was also shared by the VIS service which ended in a number of outages :(

What we're asking however, is this expected behavior of the Agent? What is the polling interval between credential checks? And should this be reviewed (perhaps something like if the last 1-2 checks failed, don't poll again until the agent is updated) or should polling be performed at all?

In the upgrade to version 3.2 we lost the green play button that appears against each Operation List on the dashboard - in favour of a consolidated "Actions" button. While I understand that this helps in context sensitive operations (e.g. Execute not visible while list is executing) I find that during testing in particular it is annoying to have to click twice for just this one thing I do repeatedly - and I'm sure other users of the console would do likewise in an operations context.

This sounds like a very minor change - but I am noticing how annoying it is to have to continually do this - so I figure it must be the same for others.

When adding the Identity Broker REST agent to EventBroker, the port has a drop down list, HTTP, HTTPS, Custom. Could that also include Default Identity Broker (59991). Or failing that, in the mouseover message for the custom port field, instead of the message "Specify a custom port to use", could we have "Specify a custom port to use (the defaut for Identity Broker is 59991)

Thanks

A vanilla install of Event Broker 3.2.1 RTM throws an Access Denied exception when attempting to connect to the local SQL Server 2012 (Enterprise x64) FIMSynchronizationService database. This is despite the service account having the correct db_datareader role membership on this database, and a UDL file running under the service account identity successfully connecting to the database.

Log file entry as follows:

20160401,03:05:29,UNIFY FIM Event Broker,Agent Engine,Error,"An error occured when attempting to execute a function against the agent with the id 78271e3f-e5af-4f4e-a4ea-9e076acc3904:

With regards the release notes of FIM Event Broker v3.2.1

Question regarding "Increased timeout of LDAP operations to one hour". I am thinking that there may be scenarios whereby a timeout of 1 hour may not be desirable (e.g. on a sync changes check operation you would most likely WANT this to fail to bring the issue to the attention of the operators). Can you explain the scenario that this was implemented for, and whether it is confined or applied in general? I can see specific examples of where increased timeouts may be required - but I would have thought this would be on an operation-by-operation basis (in which case you could conceivably have 2 agents with different configurable timeouts).

Case in point - at one particular site we are actually REDUCING timeouts for certain operations as this is indicative that there are external problems impacting the solution which need to be addressed. The changes we are looking to make there are to identify long-running operations that are out of the ordinary and disable them until the root cause has been identified and remediated. Allowing something to run for an abnormally long time in actual fact appears to have been a major contributor to a severe FIM solution outage (after damage was caused by mass account disabling as an indirect result).

When Event Broker is installed the service account is not being given rights to the extensibility directory. This means changes made to the configuration through the console are not saved.

The correct permissions are being assigned to Logs and Patches

At the moment you can configure operations to execute, so when one operation completes it executes the next.

Would be handy if you could configure a time delay between these executions - such that after an export run has completed (with unknown processing time) you could tell event broker to wait 2 or 3 minutes before executing a delta import run or such.