- UNIFYNow Forum
-
Ideas
Option to execute alternate run profile on config mods detected
The following shortcoming has always been addressed by educating the ILM administrators to always stop/start the Event Broker service either side of a config change. However, it is worth consideration if a feasible solution can be found ...
One of the ongoing problems with UNIFYNow is that it will run a "Delta Sync" MIIS run profile that would otherwise throw a warning in the management console to say that a "Full Sync" is required. As a result, a warning is written to the event log that a delta has run when a "full" should have been run first - and this has the potential to damage MIIS integrity!
We have known for some time that the MIIS console raises this error if it detects that the MA version number has been incremented. The version number can be incremented in a number of ways, including the following:
The MIIS Config is changed directly, either via the console or an import/update from XML
An extension DLL is updated, or our config file is changed - both of which live in C:\Program Files\Microsoft Identity Integration Server\Extensions
The problem for us is that the MA version number is only exposed by a SQL query on the MIIS database, and this is not 100% reliable.
The idea I have is that we can use exactly the same mechanism as MIIS does to cover MOST of these (i.e. all except the one where the MA configuration is actually changed directly. This involves using a .Net file listener on the MIIS Extensions folder. This could be used in conjunction with my previous proposal of running a SQL check on the MA version number.
What we should get the UNEE service to do when it detects this scenario is to check the corresponding OpList configuration somehow to see what alternative action (e.g. Full Import Sync run profile) is required in this circumstance - the default action would therefore be to continue processing as it currently does, and allow MIIS to throw the warning (if this wasn't configured).
The following is an example of the warning written to the application event log:
Event Type: Warning
Event Source: MIIServer
Event Category: Management Agent Run Profile
Event ID: 6127
Date: 19/05/2006
Time: 11:53:45 AM
User: N/A
Computer: UNI-MIIS-01
Description:
The management agent "Domino Person ACC MA" completed run profile "Delta Import Sync" with a delta import or delta synchronization step type. The rules configuration has changed since the last full synchronization.
User Action
To ensure the updated rules are applied to all objects, a run with step type of full synchronization should be completed.
Customer support service by UserEcho
Requires analysis.
This is the reason that the FIM Portal workflow has been created - to address rule changes in the Portal. As for addressing this in the FIM Sync Service itself, I believe our earlier discussions indicated this could not be detected.
We might have our wires crossed here ... I achieve this requirement presently with the File Changes plug-in by having 2 separate log files (one for data changes and one for rule changes). I wire up the data changes to any relevant MPR(s) which are fired whenever user/group objects (etc.) change that only need a delta import/delta sync on the FIM MA. However I've been using a global scheduled task for rule changes (just this second finished setting this up!) whereby every 10 seconds I check for changes to the RULE changes file and if there's nothing to do I jump to the end of the operation list which includes a full sync on each MA. Make sense? Of course it would be great to have 2 separate INCOMING operation lists (with 2 separate change rules) to avoid the need to use the global operation list - but in the new design the fim portal will just need to call one of 2 separate operation lists DIRECTLY.
Sorry, probably should've been a bit clearer. What I meant was the reason we have to use a custom workflow to address a FIM Portal rule change is because we couldn't detect this in the Sync Service.
I recall our earlier discussions on this issue where we weren't sure how to address the issue of a full sync being required because we had thought the FIM Sync Service/ILM/MIIS did not provide you with any information as to whether or not this is needed (outside of the event logs). However, your above suggestion of "using a .Net file listener on the MIIS Extensions folder" or "running a SQL check on the MA version number" is something we could explore.
Marked as Unassigned
The Auto Config's suggestion of regular full synchronization profiles should take care of most instances of this problem
Migrated to Visual Studio Online.