You should never react on a <move/>, you need to look for <sync from-move="true" timestamp="0#0"/>. Moves only take place on the master as they are partition operations.

You "anonymization" probably trigger on a modification, which is why it takes pace while the move is being process by the master.

There is a bit of explanation here: https://www.netiq.com/documentation/identity-manager-49/driver_admin/data/b1bkcznz.html

Thanks for this tip! We will give it a try.

Side question: as we use a loopback driver for the anonymisation work, what do you recommend as filter configuration?

Currently we have some code in both the subscriber (to "catch" the move event - we have a 'Notify' on an attribute set when the user is starting the move process) and in the publisher (to anonymize the record - we have a 'Notify' on another attribute set by the subscriber, after the 'move' command was issued); this is how we try to act AFTER the move is finished, but this does not work 100%.

Based on your suggestion I guess we can simplify and simply wait for the <sync from-move="true" timestamp="0#0"/> tag in the event, but is it best to put our code in the subscriber or the publisher, and using what filter?

Again thank you for your help!

A filter should never contain more than you need for the driver logic.

You would not see a sync event in the publisher, that will always be a subscriber event as it originates from the engine.

LDAP Wiki had a very nice graphics (originally from Novell) how the flow is: ldapwiki.com/.../Wiki.jsp

I would try with just the class set to sync on the Subscriber channel, if you just want to react to an object being in an OU you shouldn't need any attributes in the filter.

If you want a solution that anonymizes everybody, even those that have failed, create a policy in the subscriber event transformation and let it act on operation=sync or operation=trigger AND src-dn = "Archive OU".

Then if will act on the sync with from-move, and it will act on a regular manual sync and you can also create a subscriber channel trigger job that runs every day/week/month and sends through all users in the "Archive OU" in case some were not anonymized...

Thanks; we rapidly added suggested code in the subscriber and veto() if the event is a sync from-move="true" without timestamp="0#0".

Then, when the same sync event comes back later, this time with timestamp="0#0", we act as desired. 

Currently under (stress) tests to make sure we systematically act AFTER the move effectively completed.