test

Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

Initial idsync resync Operations

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

Performing a full idsync resync operation is expensive in Identity Synchronization for Windows. For a deployment as large at gt.com (500,000 users), the operation might take a few hours to complete. It also places a heavy load on Message Queue because all users and log messages are sent over Message Queue during the idsync resync operation. To reduce this load, do the following:

  1. Increase the Message Queue Broker available memory to 1 Gbyte as described in the Sun Java System Directory Server Enterprise Edition 6.0 Installation Guide.

  2. Change the Identity Synchronization for Windows system-wide log level from the default FINE to INFO, using the Console.

    Note –

    If you need to increase the log level to debug an issue, use the -a option of idsync resync to restrict the operation to only the affected users.

  3. Divide the 500,000 users into five separate idsync resync batches by using the -a option.

    This process is described in more detail in the next section.

These steps are also performed for the failover installation.

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 resync-batch.pl 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 = "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, 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.

Initial idsync resync Operation for Failover Installation

You must also run the idsync resync command for the failover installation. The links between the entries are already established, and idsync resync is only needed to prime the object cache database for the Active Directory Connector. Therefore, the command is run with the -u option.

To avoid overloading Message Queue with log messages, the following must be done:

You must modify the script in the previous section and run it on the failover installation Core, config-eu.gt.com. Change the parameters at the top of the script, and replace the -i NEW_LINKED_USERS option with just -u.