Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

Initial idsync resync Operation for Primary Installation

The first time that you run idsync resync, divide the Active Directory users into five batches to reduce the peak load on Message Queue. Use the -a <ldap-filter\> option with idsync resync to limit the scope of the idsync resync operation to a subset of Active Directory users. When dividing users, the following must be ensured:

Note –

Running idsync resync in batches will not significantly increase the total time required to do a full idsync resync operation. It might even speed the operation because it prevents the Message Queue Broker from thrashing as it reaches its memory limits.

Only a single idsync resync operation can be run at a time, not in parallel.

The -a <ldap-filter\> option always applies to the source of the idsync resync operation. When users are linked with the -f option, Active Directory must be the source of the operation. Thus, only consider how to divide users based on the available Active Directory attributes.

Due to these requirements, Global Telco is resynchronizing its users based on each user's cn attribute, a mandatory attribute that is indexed. Users are categorized into the following groups:

Note –

If a user's cn exactly matches one of the boundary conditions (for example, cn=d), the user will be synchronized twice, introducing negligible overhead but not causing any problems.

Global Telco then uses the following Perl script to iterate through the idsync resync operations. The script first retrieves the current maximum uSNChanged value from Active Directory. The specified Active Directory host must be the same host as the one the Active Directory Connector uses for communication because uSNChanged values differ between Active Directory domain controllers. The script then iterates through each idsync resync operation, pausing for one minute between the operations to allow the connectors to reset and settle. The last search filter matches all user entries that changed during the other idsync resync operations.

#! /usr/bin/perl
# This script executes a sequence of resync operations.
# Each resync operation occurs on a subset of users
# based on an LDAP filter.
# Parameters specific to this deployment
my $linkFile = "/var/opt/SUNWisw/samples/linkusers-simple-gt.cfg";
my $idsync = "/opt/SUNWisw/bin/idsync";
my $adHost = "";
my $secBetweenOps = 60;
my $dsPassword = "<omitted password\>";
 my $configPassword = "<omitted password";

# Guard against users whose cn changes during this operation
# by retrieving the maximum uSNChanged value before we start
# the operation, and later running resync for only these users.
my $origUsn = ”ldapsearch -h $adHost -b ’’ -s base ’(objectclass=*)’ \\
highestCommittedUSN | grep highestCommittedUSN | sed ’s/[^0-9]//g’”;
chomp $origUsn;
# Run each user in a batch
            (cn<=a)",             # cn <= a
            "(&(cn\>=a)(cn<=d))", # a <= cn <= d
            "(&(cn\>=d)(cn<=h))", # d <= cn <= h
            "(&(cn\>=h)(cn<=m))", # h <= cn <= m
            "(&(cn\>=m)(cn<=s))", # m <= cn <= s
            (cn\>=s)",            # s <= cn
            "(uSNChanged\>=$origUsn)",# modified users);
# Run each user in a batch
for my $filter (@BATCH_FILTERS) {
       print "Running resync with filter ’$filter’.\\n";
       my $command = "$idsync resync -a ’$filter’ -f $linkFile"."
       -i NEW_LINKED_USERS -q $configPassword -w $dsPassword";
       print "Waiting $secBetweenOps before next iteration.\\n";
       sleep $secBetweenOps;

Notice that the -i NEW_LINKED_USERS option is passed to idsync resync, which resets all Directory Server passwords to match their Active Directory counterparts after the entries are linked.

Note –

If Global Telco did not want to reset the passwords for the Directory Server accounts, it would not run this command with the -k option, which only links users. The idsync resync command primes the object cache database in the Active Directory Connector, which is used to detect changes to entries.

When idsync resync is run with the -k option, the object cache is not primed, and if the connector detects a change to an existing user, it will erroneously assumes that the change is a new user. Thus, if you run idsync resync -k, you must run the idsync resync command again with the -u option, which updates the object cache only.