Sometimes I have a need to remigrate or re-sync certain objects through a driver. Sometimes there are only a couple of objects which is easy or maybe it's all objects in a container which is also easy.
But there are those occasions where I may need to re-sync several thousands of objects that match a certain criteria.
In those cases I have several options at my disposal, these are the ones I know about:
1* Use iManager and create an advanced search query when performing a "Migrate from Identity Vault". The problem with using iManager is that the performance drops dramatically if you are trying to add thousands of users to the list, while processing the list you will need to wait quite a long time and be prepared to answer the question if the script should be stopped or allowed to continue. If there was some way to work around the poor performance then iManager would be my choice.
2* Use DA Modifier to perform the re-sync, very nice tool and quite fast if you are on the same LAN as the Identity Vault, running it over VPN isn't recommended. You also need Windows and the Novell Client to run it. The only drawback this solution has is that you can only specify two attributes as the search criteria and from what I have seen, you can't specify auxiliary attributes. Most of the time it works just fine.
3* Use an LDAP tool to export associations, edit them using awk/sed or some other tool and re-import them to trigger a sync. The advantage with this approach is that you can specify any LDAP filter you can think of and just get those objects. The bad side is trying to edit those files and get them the way you want to.
4* Forget the criteria, sync all objects and let the IDM rules veto those that don't fulfill your conditions in a event policy. Works OK, the problem is that you need to edit the rule with the conditions each time, deploy and restart the driver and that you'll get a bunch of objects with a 3 (manual) or 4 (migrate) state in the association attribute.
* Use a dynamic group.
This approach allows you to have all the flexibility of no 1 and no 3.
Create a dynamic group that will be used as the scope for a subscriber channel trigger.
The policy will transform <trigger> events to <sync> events.
My group is named "TriggerSyncOnTrigger".
Since a dynamic group is basically an LDAP filter you can build any search criteria you want.
On the driver where you want to do the re-sync create a job that has the type "Subscriber channel trigger" and associate it with the appropriate server. The schedule should be set to "Run manually".
As the scope point out your dynamic group and select "Apply job to the members of this group.".
On the parameters tab set the options that fit your needs, my settings are:
Submit a trigger document for objects without a driver association? = TRUE
Use Job CN as trigger document identifier? = TRUE
Method for submitting trigger documents = Queue (Use cache)
Now you'll need a policy that will take care of the <trigger> and create a <sync> event.
On the subscriber channel event transformation create a new policy and move it to the top so it runs before all other policies.
My policy looks like this:
sub-etp:SyncOnTrigger
<policy> <rule> <description>Break if not trigger</description> <comment name="author" xml:space="preserve">alekz</comment> <comment name="version" xml:space="preserve">1.0</comment> <comment name="lastchanged" xml:space="preserve">2010-08-29</comment> <conditions> <and> <if-operation mode="case" op="not-equal">trigger</if-operation> </and> </conditions> <actions> <do-break/> </actions> </rule> <rule> <description>Break if not correct trigger</description> <comment name="author" xml:space="preserve">alekz</comment> <comment name="version" xml:space="preserve">1.0</comment> <comment name="lastchanged" xml:space="preserve">2010-08-29</comment> <conditions> <and> <if-op-property mode="nocase" name="source" op="not-equal">TriggerSyncOnTrigger</if-op-property> </and> </conditions> <actions> <do-break/> </actions> </rule> <rule> <description>Create <sync> event for each triggered object</description> <comment name="author" xml:space="preserve">alekz</comment> <comment name="version" xml:space="preserve">1.0</comment> <comment name="lastchanged" xml:space="preserve">2010-08-29</comment> <conditions> <and> <if-src-dn op="available"/> <if-operation mode="case" op="equal">trigger</if-operation> <if-op-property mode="nocase" name="source" op="equal">TriggerSyncOnTrigger</if-op-property> </and> </conditions> <actions> <do-append-xml-element expression=".." name="sync"/> <do-set-xml-attr expression="../sync[last()]" name="class-name"> <arg-string> <token-class-name/> </arg-string> </do-set-xml-attr> <do-set-xml-attr expression="../sync[last()]" name="src-dn"> <arg-string> <token-src-dn/> </arg-string> </do-set-xml-attr> <do-set-xml-attr expression="../sync[last()]" name="qualified-src-dn"> <arg-string> <token-xpath expression="@qualified-src-dn"/> </arg-string> </do-set-xml-attr> </actions> </rule> <rule> <description>Veto trigger</description> <comment name="author" xml:space="preserve">alekz</comment> <comment name="version" xml:space="preserve">1.0</comment> <comment name="lastchanged" xml:space="preserve">2010-08-29</comment> <conditions> <and> <if-operation mode="case" op="equal">trigger</if-operation> </and> </conditions> <actions> <do-veto/> </actions> </rule> </policy>
You can add this policy to all your drivers.
When you need to do a re-sync just edit the dynamic group search filter to get those objects you need and then run the job using iManager and you're done.
Update 2010-09-06:
You might need to assign trustee rights for the Job so it can access the dynamic group and the members of that group.
