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.
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.
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
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.
Fixed in 4.0
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.
Added ability to have logs emailed to multiple addresses. Will be included in the next release.
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.
To be investigated during UI rewrite.
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 :
- Import Files
- Run UNIFY Broker Rest API Operation (Import all)
This operation list runs fora while and then throws an error:
|Operation Identity Broker Rest API Operation with id 00ad3527-87cb-4826-9ecc-a134f5007fd5 failed in the operation list IDB - Scheduled - SMS Enrolments - Import All with id d7b24af6-c394-4d8d-9336-9e9339be5b94 for the following reason. This is retry number 0: Unify.Product.EventBroker.RestAPIAgentSendRequestFailedException: The sending of the request failed. See the inner exception for more information. ---> System.Threading.Tasks.TaskCanceledException: A task was canceled.|
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
--- End of inner exception stack trace ---
at Unify.Product.EventBroker.OperationListExecutorBase.RunNextOperations(IEnumerator`1 operationEnumerator)
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.
Hi Hayden, check your timeout setting on the rest api agent in Now. Make sure it greater than the length of time the longest connector import takes to complete.
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?
The re-select is not required. UNIFYNow can recalculate based on name if there are new MA and run profile id's.
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.
Customer support service by UserEcho