Quote Originally Posted by ab View Post
This bug, assuming you mean the one where nothing shows up on the
Publisher channel, is resolved. I believe you already have an SR open
with NTS so getting that form them should be trivial. If you mean some
other issue besides the problem with the filter covered in that thread, it
may be helpful to have the bug description, bug number, and SR # if you
are having difficulties on that side of things. Also, for any
unreasonable SR service (for whatever you definition of "unreasonable")
feel free to post something in the talk-to-a-technical-services-manager
forum which is here:
https://forums.netiq.com/forumdispla...rvices-Manager
We opened an SR request, but got no response and had to rewrite it as an edir to edir setup in the end.
Also, moving back to bidirectional is out of the question.

Quote Originally Posted by ab View Post
Is this the heart of the problem, that passwords sometimes do not
synchronize because of a password policy problem? If so, just fix that by
changing the options under the 'Server Variables' tab of the driver config
object to always accept passwords. Setting both environments to have the
same password policy restrictions is better, but sometimes that is not
possible and so this option lets you get around that simply under the
assumption tat since on environment accepted the user-set password every
other should do the same, at least within the scope of the Identity Vault.
The heart of the problem is handling the returned status events for failed password modifications.
The password policies are actually the same, but the problem is the
password history mostly. In our setup we can never guarantee the password histories
are in sync and users are too lazy to think up new password combinations.

Isn't there any way to properly tag or handle the status events?
Where did that extra status come from?

I'm still kind of new to the IDM world, so I can't really tell how off I am.
I can't help feeling i've missed something extremely obvious. After all,
it doesn't make sense that all edir-to-edir driver by default can't report failed password synchronizations, does it?