MIM error code 0x8023063D

FYI the first hit on Google for that error code has the answer - this relates to triggering multiple run profiles at the same time. A recent change in MIM broke something that a lot of solutions relied upon. Ensure that exclusion groups are used to prevent this.

So based on that, parallel Sync Run Profiles will generate this error message: 0x8023063D.

Parallel Sync (for the same object) is not a good idea.

I did not setup Event Broker at this customer, is there a way to determine whether there is any Event Broker Sync Profile overlap?

Should Event Broker be intelligent enough not to trigger parallel Sync Profile operations?

Hi,

I have followed Bob's advice, and added the string to MIM Agents' Success Status, as follows:

success;in-progress;completed-no-objects;completed-warnings;completed-sync-errors;completed-discovery-errors;completed-export-errors;completed-transient-objects;stopped-object-limit;no-start-ma-already-running;call-failure:0x8023063D

However, the errors are still being logged in Event Broker Logs.

So my question is still - does Event Broker execute multiple MIM Sync Profiles in parallel?

So my question is still - does Event Broker execute multiple MIM Sync Profiles in parallel?

If you've configured it to, yes.

Just in case, please provide the recent log entries, now that you have updated the success statuses.

Correction on my part, I mis-read the EB Logs.

Since adding that line to the "Success Status", the error has indeed disappeared.

So - what does adding that line to the "Success Status" actually do in Event Broker?

Does EB suppress and ignore this error?

Why did EB log this error to begin with (if there was indeed a parallel Sync Run), but MIM did not report anything wrong at the same time?

https://unifysolutions.jira.com/wiki/display/EB32/Forefront+Identity+Manager

The error was originally logged because that's the default behaviour for unknown error codes.

As to why it's now not considered an error, I'll defer to Bob.

So according to the URL you posted: "A success status is a return value from the FIM or ILM run profile that FIM Event Broker is to consider as successful"

So by adding the line ";call-failure:0x8023063D" we are telling EB that this is a success.

Surely that is wrong? I don't understand this approach? There is clearly an error, why would one add it to the success status?

Please clarify, thank you.

Tom - this is the configuration that we've been using all year since the FIM-MIM upgrade for CSODBB, and I agree it is not exactly intuitive.  When MIM replaced FIM, Microsoft decided to tighten up their rules around concurrent sync (which they have never recommended due to highly likely db locking issues, and the reason we implemented EvB exclusion groups).  In doing so they created a problem for us and everyone else by assigning an ERROR status to something which is really no more serious than the no-start-ma-already-running return status.  The difference here is that we are treating this new "error" as a success status ONLY because we know that by doing so Event Broker will continue on waiting for the next opportunity to tell the MIM sync service it needs to do something - with the only risk that the MIM MA will miss a delta import/sync (which is not ideal I must say, but something we can easily work around).

However, while this approach we're taking at CSODBB seems to be working OK, the Application Event Log is certainly filling up with unwanted error-concurrent-synchronization-not-supported exceptions (Event 6309).  This is also not ideal, so I now believe we need to rethink this a little such that the error is not raised in the first place - and the place I'd start is with putting everything in an exclusion group, then removing only those operation lists which you know are never going to run into this problem (i.e. pure exports or imports, but not syncs).  If that doesn't work then we might have to come up with a new feature request ...