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.

Bob Bradley 2 years ago • updated by anonymous 4 months 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 4 months ago

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

Bob Bradley 2 years ago • updated by Matthew Davis 6 days 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.

Matthew Davis 6 days ago

Fixed in 4.0

Shane Day (Chief Technology Officer) 2 years ago • updated by anonymous 1 year 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
Bob Bradley 1 year ago • updated by Matthew Davis 4 months 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.

Matthew Davis 4 months ago

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

Bob Bradley 1 year ago • updated by Adam van Vliet (Product Manager) 5 days 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.


To be investigated during UI rewrite.

Bob Bradley 2 years ago • updated 4 months 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
Bob Bradley 1 month ago • updated by Beau Harrison 1 month ago 1

Using EvB 4.0, the display name property for a new operation list is not defaulted and the user is forced to enter a value:

  1. For an existing Operation List, select New Operation
  2. Select Operation Run Profile Operation / click CREATE
  3. Select Agent (if more than one agent) / click CREATE
  4. Select Management Agent / click CREATE
  5. Display Name appears blank with the field box in RED and the warning "The DisplayName field is required."

The behaviour for version 3..2.1 is as above for steps 1-4, but for step 5 we have:

5. Display Name appears with a checkbox, and by selecting the checkbox the default calculated display name could be overridden ... by not selecting this checkbox the default operation name is created, e.g. Management Agent: PHRIS - Run Profile: Delta Import.

The old v3 behaviour of defaulting the operation display name is requested to be reinstated, as this creates unnecessary work for the implementer.  I suspect that the logic to do this is still there, but the UI change to make DisplayName mandatory has ensured that this can no longer fire.

Beau Harrison 1 month ago

Hi Bob

This option was purposefully removed to better support operation types for which a meaningful automatically generated name could not be determined as well as to bring operations in line with with the standard followed by all other configurable elements in Identity Broker and Event Broker.

Give any operations you configure a meaningful display name as you would operation lists, connectors, adapter etc.

Matthew Woolnough 1 month ago • updated by anonymous 1 month ago 1

I just logged into EvB at APRA test env & saw that it wasn't running the AD Outgoing Operation as it was queued.  It hadn't been able to run for hours.  It didn't appear to be blocked.  RAM usage was very high.

Does EvB log the reason that it was blocked? I couldn't find any detail in the logs.

anonymous 1 month ago

No, not with normal logging as it would spam the logs. Increase the logging level for more detail.

Anthony Soquin 2 months ago • updated by anonymous 2 months ago 7

Hi I have the following error: 

  • The agent FIM Agent has failed with the message: Access denied
  • I followed the requirements  which are in the page: https://unifysolutions.jira.com/wiki/spaces/EB32/pages/93454604/Prerequisites

    Firewall: Checked: Able to connect to SQL Server via telnet

    • Log on as a service. For details see hereChecked
    • Access to write to its Logs directory. Defaults to: Checked FULL CONTROL
      • C:\Program Files\UNIFY Solutions\Event Broker\Services\Logs
    • Ability to create the Logs file directory;Checked
    • Full update access to the Extensibility directory. Defaults to:  Checked FULL CONTROL
      • C:\Program Files\UNIFY Solutions\Event Broker\Services\Extensibility
    • Permission to create a WCF end-point (see Create WCF end-point); Checked 

    PS C:\> netsh.exe http add urlacl url=http://+:59990/ user=****\svc_fimeb

    Url reservation add failed, Error: 183
    Cannot create a file when that file already exists.

    • Permission to write to C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files; Checked FULL CONTROL
    • Membership in the FIMSyncAdmins group. Checked
    • Read permission (db_datareader) to the FIMSynchronizationService database, either for the service account, or a separate SQL authentication login. Checked Created a SQL agent with same connection string. Work perfectly

    If installed on the same machine as Microsoft Identity Lifecycle Manager or Microsoft Forefront Identity Manager, the service account also requires the following:

     Checked FIMSYNCADMINS group full control on MicrosoftIdentityIntegrationServer 

    Do you have another ideas about the root cause?

    Thanks in advance.

    anonymous 2 months ago

    Issue resolved.

    It was linked to a MIM/FIM Corrupted files found thanks to your help and the WMI Diagnosis Utility tool.

    If something similar appears in the report, please reinstall/repair FIM/MIM sync service:

    30646 14:40:48 (0) ** ----------------------------------------------------------------------------------------------------------------------------------

    30647 14:40:48 (1) !! ERROR: Unable to locate MOF file(s) in the WBEM folder or in Auto-Recovery list for the

    30648 14:40:48 (1) !! ERROR: following CIM registered WMI provider(s): .................................................................... 2 ERROR(S)!

    30649 14:40:48 (0) ** - ROOT/MICROSOFTIDENTITYINTEGRATIONSERVER, MIIS ({9A6AE3F8-5DEF-416E-A569-BB74B3184DC6})

    30650 14:40:48 (0) ** - ROOT/SERVICEMODEL, SERVICEMODEL ()

    30651 14:40:48 (0) ** => If the WMI repository is rebuilt, the listed provider(s) may not be available anymore

    30652 14:40:48 (0) **    because the registration data is not located in the list of known MOF files. You can either:

    30653 14:40:48 (0) **    - Locate the MOF file(s) and manually recompile the corresponding MOF file(s) with

    30654 14:40:48 (0) **      the 'MOFCOMP.EXE <FileName.MOF>' command.

    30655 14:40:48 (0) **    - Retrieve a copy of the missing MOF file(s) and make sure there are part of the Auto-Recovery.

    30656 14:40:48 (0) **      registry key.

    30657 14:40:48 (0) **    Note: If you want the MOF file to be part of the Auto-Recovery, make sure the

    30658 14:40:48 (0) **          statement '#PRAGMA AUTORECOVER' is included.

    30659 14:40:48 (0) **    - If the corresponding MOF file can't be located, the MOF file can be recreated with

    30660 14:40:48 (0) **      WBEMTEST and/or CIM Studio available at

    30661 14:40:48 (0) **      http://www.microsoft.com/downloads/details.aspx?FamilyID=6430f853-1120-48db-8cc5-f2abdc3ed314&DisplayLang=en

    30662 14:40:48 (0) **    - It is also possible that the application implemented its own recovery mechanism.

    30663 14:40:48 (0) **      In that case, no action is required.

    30664 14:40:48 (0) **      You must verify with the application vendor if the application has this capability (i.e. Microsoft SMS)



    Not a bug
    Bob Bradley 2 months ago • updated by anonymous 2 months ago 1

    On upgrade to version 4, the existing IIS website for the Event Broker application failed to open due to a permissions error.  This was subsequently resolved by re-enabling Integrated Authentication on the IIS website.

    One possibility for the issue might be that the IIS application pool identity (svcFIM_EBrokerWeb) in this case is not configured to be the same identity as the Event Broker service account (svcFIM_EBroker - as specified in the MSI).  However this is only a guess.

    anonymous 2 months ago

    This was already in the backlog for Identity Broker, I've now copied it over to MIM Event Broker. The issue is that the web.config file isn't "permanent", so gets overridden on upgrade.