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.

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?

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?

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.

1/ Priority control flag

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

(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.