I do not usually mark more than one operation for STARTUP, but in the CSO Staff FIM solution I am building I am using this idea right now. I started the scheduler, and then stopped it again while I waited for the first of 3 startup operations to complete ... thinking that the others wouldn't start. They did. I don't think this would be considered "expected behaviour" and I think the scheduler status should be checked before ANY new operation is started. Thoughts?

Noticed that the former Documentation and Support links appear to be missing - can these please be reinstated, or if they are hiding somewhere can they be made more obvious please? I find these useful as I am sure other users will too.

From the Groups page, clicking the "Edit Operation List Groups" button shows a list of all operations, but the context of the group name is lost. You are left with not being able to see the name of the group you're editing. No breadcrumb either.

The number of operation lists that appear on the Home\Index page should be limited.

Order by the next run date and display all of the running lists. If that does not equal a certain number (10?) display as many more as needed.

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.

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.