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
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.
UNIFYNow Upgrade Failing operation lists afterwards
Just upgraded UNIFYNow (4.0.0.1 to 4.0.4.0) after upgrading broker (5.2.0.2 to 5.3.2.0) and alot of the UNIFYNow operations lists that are supposed to trigger IDB operations lists are failing all with the same error.
The field the error message is quoting was removed in v4.0.3. Please check for and remove any old patches, as we discuses in your earlier issue.
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.
Event Broker Operation management halts with Blank screen
Email logger does not support multiple TO email addresses
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.
Incorporate progress bar on executing operations
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.
Preferred DC list for AD agents
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.
Edit operation return 404 Not Found for /Operation/CreateRunProfileOperationChooseManagementAgentByViewInformation
New UNIFYNow installation with extensibility files copied across from an older server as part of a server migration. Other parts of the UNIFYNow UI are working fine, such as below. It seems to be just the /Operation/CreateRunProfileOperationChooseManagementAgentByViewInformation that shows the error.
Both the old and new UNIFYNow installs are v4.0.4
What have I misconfigured or missed?
How to set UNIFYNow security Roles
https://voice.unifysolutions.net/knowledge-bases/8/articles/2717-unifynow-security says "Operations on the UNIFYNow website require the user to be in one of the following four roles: Read, Write, Full, Admin"
How is this done - i.e. how is a user put in a Role?
Morning Adrian,
I believe this should be done through the App Roles feature of an app registration:
Add app roles and get them from a token - Microsoft Entra | Microsoft Learn
I have a feeling that the config on the documentation may be incorrect, it may look more like this:
<add key="AuthorizeSetting" value="OpenId"> <add key="ida:ClientId" value="{ClientId}"></add> <add key="ida:AADInstance" value="https://login.windows.net/"></add> <add key="ida:TenantId" value="{TenantId}"></add> <add key="ida:PostLogoutRedirectUri" value="{PostLogoutRedirectUri}"></add>
Not many people use the auth feature, so it's also possible that Microsoft have changed a few things in how the auth works and issue claims since the feature was built. At a quick glance, we validate the ClientId and Authority (where Authority is the combination of the AADInstance and Tenantid). If you find that it's not working as expected, let us know and we can investigate to see if any changes are needed.
KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414)
Microsoft server hardening for DCOM and RPC is now underway with the stage 2 (June 14, 2022) of the timeline described in KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) (microsoft.com) having just passed.
At least one customer has reported that the Microsoft Security Update has adversely impacted one or more MIM agents, and have sited the above article as how they have identified the root cause. This customer is now after a patch before stage 3 has elapsed and the stated registry key override setting will no longer work.
There is now a possibility other UNIFYNow customers who have also installed the same security update(s) are going to also run into similar problems in the coming weeks, and as a result there will need to be a patch developed for all such customers.
Between now and March 14 2023, the registry change described in the linked article above will allow business continuity for UNIFYNow customers, while advice on the availability of a patch is pending.
Thanks.
Closing as no further feedback was provided, and the above date has come and gone without any further reports of the issue.
Feel free to re-open the ticket if the issue presents and further details on the behaviour are available.
Customer support service by UserEcho