MIM Event Broker Forum

Welcome to the community forum for MIM Event Broker.

Browse the knowledge base, ask questions directly to the product group, or leverage the community to get answers. Leave ideas for new features and vote for the features or bug fixes you want most.


REST API to access Event Broker service methods directly

Bob Bradley 3 years ago • updated by anonymous 2 years ago 1

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.

anonymous 2 years ago

Now that this has been proven in Identity Broker we'll look at this for MIM Event Broker.


Event Broker agent wizard leads to "The server is unwilling to process the request" exception for specific OU

Bob Bradley 3 years ago • updated by anonymous 1 year ago 10

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.

anonymous 1 year ago

Fixed in 4.0


Event Broker Operation management halts with Blank screen

Shane Day (Chief Technology Officer) 3 years ago • updated by anonymous 2 years ago 4
Hi Product Team!
Attempting to delete operations from "/Operation" (Operation Lists Page) is met with a blank screen. The URL redirects to "/Operation/ModifyOperationLists" but the page is blank.
The only way to delete operations via the GUI is to Open the operation from the operations list. Click Actions and Delete from within the Operation. Even attempting to delete the operation this way acts strange.. When attempting to delete from within the operation the "Are you sure" window pops up for a second and automatically submits the deletion without confirmation.
Happy to ellab on this if required.

Item originally from Ryan Crossignham from PRODUCT-389

screen2.png - Latest 21/Sep/15 4:47 PM - Ryan Crossingham

Email logger does not support multiple TO email addresses

Bob Bradley 2 years ago • updated by anonymous 2 years ago 4

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.

anonymous 2 years ago

Added ability to have logs emailed to multiple addresses. Will be included in the next release.


Incorporate progress bar on executing operations

Bob Bradley 3 years ago • updated by anonymous 1 year ago 3

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.

anonymous 1 year ago

To be investigated during UI rewrite.


Preferred DC list for AD agents

Bob Bradley 3 years ago • updated by anonymous 2 years ago 10

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.

Not a bug

UNIFYNow doesn't handle changed MIM Run Profile names

Adrian Corston 1 week ago • updated by Adam van Vliet (Chief Information Security Officer) 20 hours ago 5

In UNIFYNow, I had an operation which invoked an existing MIM Run Profile.  In MIM, I renamed that Run Profile.  Back in UNIFYNow, the old Run Profile name remained and the new name did not appear.  I tried Refresh MA on the MIM Sync agent, no luck.  I tried restarting UNIFYNow followed by another Refresh MA on the MIM Sync agent, no luck.  I ran iisreset on the server running UNIFYNow Web, no luck.

The Operation Lists which invoked the renamed MIM Run Profile is now failing, with the following error in the logs:

Please note that the Run Profile GUID is unchanged - the only thing I did was change the name of the Run Profile in MIM.

How can I get UNIFYNow to acknowledge and use the changed Run Profile name?


Hi Adrian,

Please upgrade to the latest version of UNIFYNow, v4.0.4. There were some issues surrounding MA update tracking that were resolved in that release.

Under review

Queue on Blocked didn't run the blocked operation in a timely fashion

Adrian Corston 1 month ago • updated by Adam van Vliet (Chief Information Security Officer) 4 weeks ago 8

I have two Operation Lists configured as shown:

Operation List "Incoming":
- Run Profile operation (a delta import)
- Calls Operation List "Sync"

Operation List "Sync":
- Run Profile operation (a delta sync)

Operation List "Sync" is in an exclusion group with various other operation lists that perform Sync run profiles.

When one of the other Sync operation lists are running and Operation List "Incoming" is run, the first operation (Run Profile operation (a delta import)) completes, but since Operation List "Sync" is in an exclusion group, it does not run (which is as expected).

However, I have configured Operation List "Sync" with the "Queue on Blocked" flag, so I'm expecting that it should run soon after the other Sync operation list completes.  However, it does not appear to do so in a timely manner, if at all (I only waited a few minutes).

The desired outcome here is that I can avoid having to put all my "Incoming" operation lists in an exclusion group.  I only want to exclude parallel sync operations - it's fine if delta import operations run in parallel.

Can you please advise how I can get the desired outcome to work?


Is the UNIFYBroker agent the correct agent to use for very recent versions of UNIFYBroker?

Tom Parker 1 month ago • updated by Beau Harrison 4 weeks ago 2

Hi all,

Based on the issue I had recently that Beau ended up talking me through, is the UNIFYBroker agent actually the correct agent to use for very recent releases of UNIFYBroker?

The issue that I was having when trying to configure UNIFYNow I wasn't seeing the UNIFYBroker runs appear until I replaced the UNIFYNow agent with a Rest API agent.

Under review

Enhanced control over execution of operation lists in Exclusion Groups

Adrian Corston 2 months ago • updated 2 months ago 2

1/ Priority control flag

According to the documentation, UNIFYNow Exclusion Groups, Priority operation lists execute immediately, even if Normal operation lists are currently running:

PriorityWhen this operation list runs, it prevents other priority and normal members from running. If a priority member begins execution when a normal member is running, it will not be blocked.

(emphasis added)

Could you please add a flag to the group configuration to control this behaviour, so that the group can be configured to block Priority operation list execution until any currently-running Normal operation list completes.

This would be much more useful in a MIM environment than the current default behaviour.

2/ Multiple priority levels

Could you please add a numeric priority to each member of an Exclusion Group, to allow more refined control over operation list execution scheduling.  At any time, the scheduler would select the operation list with the highest priority to execute next.

The "Priority control flag" is desirable in this situation, to control whether or not higher priority operation lists run concurrently or wait for lower priority operation lists to complete first.