How to build an AD change cookie in RapidIdentity Connect

Purpose

The openADChangeIterator action in RapidIdentity Connect relies on a change cookie to limit the number of processing between systems to only records that have changed since the previous sync. On occassion, these change cookies can become corrupted resulting in the iterator not behaving as expected (processing all accounts or many more than expected). This document details the process of building a new change cookie without having to touch all accounts that an action targets. NOTE: If your action set uses the deprecated getADChanges action, please consult the Caveats section at the end of the document before taking any action. Also, these instructions do not apply to OpenLDAP actions.

How-to

1. If the action set you are editing is used with a scheduled job, first you should disable the job. If there is a instance of the job currently running, kill it in the Status screen.

2. Find the existing cookie that the job is using, if it exists. Append something like ".old-<today's date>' to the name so that the action set no longer finds it.

3. Open the action set you wish to build the cookie for. At the very top of the for action, before any transformations occur, insert a continue action and Click Save. The placement of this continue will ensure that all accounts are iterated over, but no actual changes are made. The point of this exercise is to capure current state of all accounts without making any changes to them.

4. Run the job that utilizes the action set manually from the Jobs screen. Note that depending on how your action set is written, it may take two times to actually build the cookie. There are cases where a failed cookie check will create a cookie and exit the job immediately. If the job you are working with has this code, you will need to run the job with the continue twice.

5. Once the "continue" job has finished running, check the Files screen to ensure that a new cookie has been built.

6. Open the action set once more and delete the continue action that you added in step 3. Click Save.

7. Run the job manually once more. You should see little to no changes take place, as only accounts that have changed since the new cookie was built will be processed.

8. Enable the scheduled job once again.

Caveats

• The process described above is relevant for openADRecordChangeIterator, along with other current actions in RapidIdentity Connect that use change cookies. If your action set utilizes the deprecated getADChanges action, the placement of the continue action will be slightly different. Under the for loop, you should see an if statement that evaluates recordChange['objectClass'] == "cookie". You need to place the continue at the top of the else statement following the aforementioned if.
• Any changes that occur between when the cookie stopped working and when you build the new cookie will not trigger updates. If you need to ensure all accounts are touched, you can rebuild the cookie without the continue to ensure that all accounts are up-to-date.