test

Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

Initial idsync resync Operation

The next step in the installation and configuration process is to run idsync resync. In this deployment, idsync resync:

Note –

If you need to increase the log level to debug an issue, then it is recommended that you use the -a option during idsync resync operation to restrict the idsync resync operation to only the affected users.

Initial idsync resync Operation for Primary Installation

When you run idsync resync for the first time, the Active Directory users are divided 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, and might even speed the operation as 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, so these operations cannot be run in parallel.

The -a <ldap-filter\> operation 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, so we 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 their cn attribute. cn is a mandatory attribute and 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), then the user will be synchronized twice, but this introduces negligible overhead and does not cause any problems.

Global Telco then uses the following Perl script to iterate through the idsync resync operations. The resync-batch.pl script first retrieves the current maximum uSNChanged 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 will match all users 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 = "ad1-us.gt.com";
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
my @BATCH_FILTERS =  ("
            (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";
       system($command);
       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, they 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 it is a new user. If you run idsync resync -k, then you must run the idsync resync command again with the -u option, which updates the object cache only.

Initial idsync resync Operation for Failover Installation

You must run the idsync resync command also for the failover installation. The links between the entries are already established and idsync resync is only required to prime the object cache database for the Active Directory Connector. Therefore, it is run with the -u option. To avoid overloading Message Queue with log messages: the Message Queue Broker's maximum memory is increased, the Identity Synchronization for Windows log level is changed to INFO, and idsync resync is run over the entire user population in batches. The script above is modified slightly and run on the failover installation Core machine, config-eu.gt.com. The parameters at the top of the script are changed, and the -i NEW_LINKED_USERS option is replaced with just -u.