I know this is somewhere on the roadmap, but I thought I'd give you a specific example of how I would like to use this to lookup the Operation List name for a corresponding guid from within a PowerShell script. I know this method exists on the WCF endpoint because it is exposed in the WSDL. However it is not a simple exercise to access this from PowerShell.

For the time being I have a work-around which relies on looking up the Event Broker registry key to determine the extensibility file path, then querying the operations extensibility xml directly. However the limitation here is that this will only work if the script is running locally on the Event Broker service host.

When an OU is configured for an AD agent that is NOT the domain root (e.g. "OU=Employees,DC=mim2016,DC=local") we get the following exception when the generated incoming operation list is activated:

Operation faulted: The server is unwilling to process the request. - Please see the log viewer for more details.

This is because the AD Sync Changes check operation uses the full DN for the "Domain" property instead of the DC part only (i.e. "DC=mim2016,DC=local").

To avoid this error the AD sync changes operation needs to extract the DC DN from the full DN supplied.

Presently the TO address supports only a single target email address. However this field is multi-valued in the sendmail API and the logger could easily be extended to support this. There is no tooltip on this field so it was not intuitive that this restriction applied - however attempts using "," and ";" delimiters both failed. Work-arounds include setting up multiple loggers, or using a distribution list. However there are times when this would still be handy - especially when d-lists are not easily modified or the requirement is only temproary.

With the release of Ryan Newington's latest Lithnet miis-powershell module it occurred to me that it may be possible in some scenarios (e.g. full imports vs. delta imports) to leverage the progress bar idea for the Event Broker console.

The native AD MA for the FIM Sync service has long had an optional configuration section for preferred DCs, so that administrators can nominate an ordered list of preferred DCs to connect to for imports/exports. When this is used with Event Broker, especially in forests where there are delays in AD replication between DCs, the result can be that Event Broker detects a change before it is replicated to the DC from which FIM is connecting. This generally results in a missed change.

A feature to configure the AD agent exactly in line with that in the corresponding AD MA is suggested here.

Currently the REST Agent supports GET and POST requests to configured endpoints.

There's also an IdentityBroker REST agent built in, however it only supports the triggering of a Full Import or Polling Import.

Would it be possible to expand the REST agent to support other method requests such as GET, and/or expand the IdentityBroker REST agent to support custom endpoint calling? I'd love to be able to trigger a Generate Changes on the UNIFYBroker API, which currently isn't possible through either of these mechanisms.

Hi,

We have a customer that has requested some details on an upgrade from EventBroker 3.1 to UNIFYNow 4.02 (the current latest RTM version); and we have a few questions:

- Is an in-place upgrade supported?

- Are there any gotchas?

- Can someone suggest an estimate effort for such an upgrade engagement?

thank you

Check Operation - Create Pending Export Operation is not working since the upgrade to v4.0.1.

The select agents is displayed and list is populate with MIM/AAD Connect agents but nothing happens when clicking on continue. Confirmed this is happening on more than one Event Broker instance.

After upgrading EB from v3 to v4 all my operations stopped working with errors like "Attempting to check for exports in non-existant management agent". I refreshed the FIM Agent which did not help. I then created a new MIM Agent and went through manually updating every single check operation and run operation (there are *lots*) to reference the new agent. Dev then worked.

I have just upgraded Test and the same thing has happened, even though I migrated the OperationEnginePluginKey and AgentEnginePluginKey files from Dev (then fixed the agent database path through the UI). Again I've refreshed MAs, and restarted a few times, but everything is broken with "non-existant management agent" type messages.

The MA GUIDs are identical in both environments and I always update EB by copying the OperationEnginePluginKey file.

How can I fix this without having the edit every single operation again?