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.

UNIFYNow has been observed to invoke operations as soon as UNIFYBroker changes are detected, rather than waiting until UNIFYBroker has completed generating changes.  In a bulk change scenario, this can result in small batches of changes being imported via a MIM run profile (for example), and in the case of changes that may breach a configured change threshold (e.g. UNIFYNow Safety Catch feature), it is possible that the catch won't be tripped because individual batches themselves fall below the threshold.  For example, when 1000 changes are made in HR, and the import threshold is 500, 4 batches of 250 identity import changes could still get through to MIM.

Instead of change detection returning TRUE as it currently does as SOON as there are changes present in the adapter, is there a way of holding these up (queueing them internally within UNIFYBroker) while reflection is still going on.  This way in the above example, change detection would return TRUE only after the 1000th change had been surfaced to the adapter.

There may be multiple ways of looking at this … for example, a result of BUSY could signal to UNIFYNow that changes have been detected but there could be MORE COMING.  Not sure which option would be best, nor the degree of configuration that may be required to throttle this.  Looking for the most elegant solution to achieve the desired result - and suspect this would be best isolated to within Broker rather than surfacing the decision to UNIFYNow.

After recently updating to the latest version of UNIFYBroker (5.3.1) and UNIFYNow (4.0.4), I have noticed that some UNIFYNow operations appears to be reporting errors when errors are not being thrown on the corresponding UNIFYBroker job. 

To explain this a little better an example of this is an operation list "IDB- Scheduled - SMS Enrolments - Import All". Each night this operation list is scheduled to run with two steps :

1. Import Files
2. Run UNIFY Broker Rest API Operation (Import all)

This operation list runs fora while and then throws an error:

Both operations in the list continue to run successfully, however it just appears to time out.

All errors of this type appear to be occurring on operation lists that take more than an hour to run. Please let me know if you need any further information and please also find attached the extensibility folder for UNIFYNow.

Thanks,

Hayden

I've read this https://voice.unifysolutions.net/knowledge-bases/8/articles/2719-migrating-unifynow-between-environments.

I think I've read in some deployment guides that MAs need to be reselected in each of the operations after a migration. I want to delete 2 operation lists and add 2 and change 1 in a list of about 15 operation lists. If I have to reselect each MA the migration might be better done manually. Do you still need to re-select the MAs in operation lists when migrating configuration?

V3.2.0 Rev 1

I was doing a test with this and it doesn't appear to be the case. If not, this might be a good idea to implement as it can lead to some confusion.