The ConfigureEventBrokerChangesActivity.ps1 script makes use of the host.UI.RawUI.ReadKey function. When running under ISE the function isn't made available and the belowexception is thrown. A troubleshooting article should explain that the script is not intended to run under ISE, and that the line can be removed if required.

PS C:\FIM Installers> C:\FIM Installers\FIMEventBrokerWorkflow.ps1

PS C:\FIM Installers> C:\FIM Installers\ConfigureEventBrokerChangesActivity.ps1
This script will add the required Activity Information Configuration to the FIM instance for the Event Broker Changes Activity. Press any key to continue.
Exception calling "ReadKey" with "1" argument(s): "The method or operation is not implemented."
At C:\FIM Installers\ConfigureEventBrokerChangesActivity.ps1:37 char:1
+ $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : NotImplementedException
 
Import complete. Verify that the Event Broker Changes Activity is correctly listed in the Activity Information Configuration. Press any key to finish.
Exception calling "ReadKey" with "1" argument(s): "The method or operation is not implemented."
At C:\FIM Installers\ConfigureEventBrokerChangesActivity.ps1:68 char:1
+ $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : NotImplementedException

There's a display issue in IE6 and IE7 that removes the border where the arrow images are.

Good morning,
We have a major job that runs every night at 03:00, except on Sunday. The schedule has been set as follows:
Runs every 1 day(s) at 03:00:00 starting from 20.08.2012
•Does not run on the days of Sunday
In spite of this schedule the job runs at 00:00 between Sunday and Monday and again at 03:00 on Monday.
Any idea why this happens?

Thanks,

Meni Ariely

I'm sure I've detailed this requirement in the former Project Management tool, but it is presently offline so I can't tell. I do recall spending quite some time writing this (and other issues) up in that tool - but I can't find them here. I feel strongly enough about this issue to write this up while on leave ...

A key requirement @ Centrelink (as with ANY FIM Portal implementation) is the ability for Event Broker to differentiate between data vs. rule changes that have occurred in the FIM portal, and thereby ensure that the correct operation list is run as a result. Both rule and data changes are imported together into the same FIM MA connector space (there can only ever be one FIM MA), and different sync cycles are required depending on whether or not the imported changes included rule changes (essentially sync rules).

The easiest way to explain this is in terms of a FIM administrator attempting to manually execute run profiles involving multiple MAs, including the FIM MA. If running a delta import/delta sync on the FIM MA immediately after a rule has changed in the portal, the FIM administrator should not be surprised to see the sync service raise a warning when he attempts to run a subsequent delta import/delta sync on another MA, with words to the effect that rules have been changed since the last full sync cycle, and that a new full sync is required. When the Event Broker (or any other non-interactive process) executes run profiles under this scenario a warning is written to the Application Event Log but this does not prevent the run profile from subsequently being executed.

A variation on this scenario has always been around since MIIS/ILM days, but what is new here is that the FIM portal now introduces an additional (less obvious) way that the sync engine configuration can be changed by a FIM administrator type. It is anticipated that there will be certain types of changes that could occur in day-to-day FIM operations whereby a FIM sync server under the "governance" of Event Broker would be expected to handle this scenario without having to first shut down the Event Broker service and manually perform "re-baselining".

I won't go into any further detail on this now, but suffice to say it was an issue for us @ Centrelink, and Jeff Nelson (MCS) sees this as a key business driver in the ultimate purchase of Event Broker by Centrelink.

The way change detection has been implemented for the FIM Portal @ Centrelink is using the file changes plug-in with log files written by a FIM custom activity (as I demonstrated in a live meeting on the NAB site before christmas) and the way that "data changes" are differentiated from "rule changes" are that the custom activity is used to write to either a "data" or a "rule" file depending on the nature of the change that has been logged. The challenge then is for Event Broker to correctly interpret changes to either file ...

The present Event Broker design does not allow multiple incoming operation lists to be configured for the same MA, but this would have allowed me to meet the requirement together with the mutex capability recently added to the product.

As a work-around I was able to configure the INCOMING operation list for the FIM MA using the standard File Changes plug-in for the DATA log file, and this did little more than a delta import/delta sync on the FIM MA (followed by a commit file changes plugin call). I coupled this with a GLOBAL operation list on a similar schedule to the above delta (10 secs which is the default) which ran the File Changes plug-in on the RULE log file as the first step in the run profile. If this plug-in returned false it "jumps to a label" operation at the end of the operation list, but proceeds to run a full sync on each MA (with each operation on the same MUTEX thread name as those of the regular delta operation list) if it returns true.

The implications now on the equal precedence issue (written up by Nigel this week) now throw up concern that running a series of full syncs to re-baseline the FIM sync service in ANY WAY could lead to loss of MV data for attributes marked as equal precedence applicable. However, this does not take away from the fact that data and rule changes detected in the FIM portal need to be handled differently.

Event Broker v2.x had limited scheduling capabilities, typically allowing for operations to be performed only in intervals (e.g. every 1 hour).

Event Broker v3.0 should improve on the existing capabilities by allowing for the following:

• Support for different kinds schedules, including timed (e.g. midnight every day), support for exclusion periods (hourly but not between 9am and 5pm), etc. The Timing page for Identity Broker provides sufficient examples.
• A user interface component that allows for easy configuration of these timing. This will ideally contain a graphical representation, but is not a requirement due to time and resources constraints.

From Help Desk #404:

The MAs in the Event Broker treeview should be displayed in alphabetical order by default - this would make finding particular MAs much easier

At DET, the workaround was to sort the Server Config XML into alphabetical order, then reimport.

At ACT Edu they have 89 MA's. Each of these needs a global full, delta, and export run profile created. Its currently an all day task, especially if they want to move things around. They would like to be able to copy and paste run profiles between or into the same area (global->global, global->MA) and then modify them as a faster method of getting things moving.

In Event Broker v2.2.3.6, the default LDAP filter for the AD Changes plugin, according to the plugin description, should be:

(& amp ;(objectClass=user)(objectCategory=person))

Instead, it is:

(& amp ; amp ;(objectClass=user)(objectCategory=person))

Spaces added

This results in the plugin never detecting changes. This is easily fixed by updating the LDAP filter and removing the additional "amp;".

I believe this may be already incorporated into Event Broker v3

Currently at ACT Edu they have 89 MAs. They are called the same thing in Test and Prod. They would like to be able to export the configuration from Test and import it into prod rather then rebuilding it each time. This would also be very useful as a 'backup' feature for eventbroker, as well as for consultants deploying solutions in the field.

Framework Core currently contains several timings that are useful for Event Broker, however, they aren't currently configured to allow for multiple sets of each amount (eg. every 3 weeks). Event Broker could be configured to simply insert multiple timings where longer times are needed, but it would be more robust to extend the current timings to account for multiples.