Preparing for Identity Synchronization for Windows Migration

Use one or more of the following utilities to migrate from Identity Synchronization for Windows 1.1
to Identity Synchronization for Windows 6.0:

export11cnf. A
stand-alone utility that enables you to create an export configuration file
from your Identity Synchronization for Windows 1.1 configuration. For more information ,
see Exporting Version 1.1 Configuration.

checktopics. A utility that
checks Message Queue synchronization topics in a 1.1 installation and determines
if any undelivered messages remain in the queue.

Updates can remain
in Message Queue after you stop 1.1 synchronization. You must verify that
no updates exist in the Message Queue before you proceed with the migration.
For more information, see Checking for Undelivered Messages.

forcepwchg. A Windows
NT tool that enables you to identify users who changed passwords during the
migration process and forces them to change passwords again when the version 6.0 system
is ready. Password changes made on Windows NT are not captured during the
migration process. For more information, see Forcing Password Changes on Windows NT for detailed information.

Note –

These utilities facilitate the migration of Identity Synchronization for Windows version
1.1 to version 6.0. The migration is performed in the same
environment where Identity Synchronization for Windows 1.1 is deployed. Consequently, these
utilities are available in the Solaris/SPARC and Windows packages only.

You can find the migration utilities in the installation migration directory. No additional installation steps are required.

Exporting Version 1.1 Configuration

You can use the export11cnf utility
to export an existing version
1.1 configuration file to an XML file and then use the idsync importcnf command
to import the file into the Identity Synchronization for Windows 6.0 system
before installing the connectors.

Tip –

While you can update the 1.1 system configuration manually by using
the Identity Synchronization for Windows console, we recommend that you use the export11cnf utility. If you do not use export11cnf, the
state of the connectors is not preserved.

Exporting the version 1.1 configuration enables you to:

Eliminate most of the initial configuration process to be
performed from the management Console.

Guarantee that the connector IDs assigned in version 6.0 match
the connector IDs used in version 1.1. This simplifies the task of preserving
the existing connector states that can be used directly in the version 6.0 deployment.

Back up the persist and etc directories, and then restore them later
to avoid confusion about the underlying directory structure.

You can find the export11cnf utility in the installation migration directory. No additional installation steps are necessary.

Using the export11cnf Utility

To export an Identity Synchronization for Windows configuration to an XML file, execute export11cnf from the migration directory as follows:

Inserting Clear-Text Passwords

For security reasons, the export11cnf utility does not export clear-text passwords from version 1.1.
Instead, the utility inserts empty strings in cleartextPassword fields
wherever applicable. For example,

<Credentials
userName="cn=iswservice,cn=users,dc=example,dc=com"
cleartextPassword=""/>
<!-- INSERT PASSWORD BETWEEN THE DOUBLE QUOTES IN THE ABOVE FIELD -->

You must enter a password manually, between double quotes, for every cleartextPassword field in the exported configuration file, before
you can import the file into Identity Synchronization for Windows. importcnf validation prevents you from importing
a configuration file with empty password values.

For example,

<Credentials
userName="cn=iswservice,cn=users,dc=example,dc=com"
cleartextPassword="mySecretPassword"/>
<!-- INSERT PASSWORD BETWEEN THE DOUBLE QUOTES IN THE ABOVE FIELD -->

After the completion of configuration export, export11cnf reports
the result of the operation. If the operation fails, an appropriate error
message is displayed with an error identifier.

Checking for Undelivered Messages

The migration process minimizes system downtime
by preserving the connectors’ states in the existing deployment. However,
these states reflect only the last change received and acknowledged by the
Message Queue. Therefore, you do not know whether the message was actually
delivered and applied to the destination connector.

This behavior does not cause problems as long as the Message Queue remains
the same. However, you will lose any messages on the Message Queue during
the migration process when you install Message Queue 3.6.

You must verify that the synchronization topics on the existing Message
Queue do not have any undelivered messages before you proceed with the migration.
The Identity Synchronization for Windows checktopics utility
enables you to verify that all the synchronization topics are empty and the
system is not causing any problem.

Using the checktopics Utility

The checktopics utility
is delivered in the migration directory of the Solaris/SPARC and
the Windows Identity Synchronization for Windows 6.0 package.

Note –

The prerequisite to run checktopics is a Java
Virtual Machine.

When you run the checktopics utility, it connects to the configuration directory, which contains
information about Synchronization User Lists (SULs) and current synchronization
topic names used in Message Queue. In addition, when you run checktopics, it queries Message Queue to check how many outstanding messages
remain on each active synchronization topic and then displays this information
for you.

After runningchecktopics, check your
terminal for the following messages:

If the operation succeeds, the terminal window displays a
message stating that there are no outstanding messages in the logs.

If the operation fails, an appropriate error message is displayed
with an error identifier.

To Clear Messages

If any of the active synchronization topics contain outstanding messages,
use the following procedure to clear the messages.

Restart synchronization.

Wait until the messages are applied to the destination connector.

Stop synchronization.

Rerun checktopics.

Forcing Password Changes on Windows NT

On Windows NT, password changes are not monitored and new password values
are not captured during the migration process. Consequently, you cannot
determine new password values after the migration process.

Instead of requiring all users to change passwords when you finish migrating
to 6.0, you can use the forcepwchg command-line
utility to require a password change for all the users who changed passwords
during the migration process.

Note –

The forcepwchg utility
is available only in the Windows packages.

You can find the forcepwchg utility
in the Windowsmigration directory. Execute forcepwchg directly from that directory. No additional installation
steps are necessary.

You must run forcepwchg on the Primary Domain Controller
(PDC) host where the NT components
(connector, Change Detector DLL, and Password Filter DLL) are installed. You
cannot run forcepwchg remotely.

The forcepwchg utility also prints the account names
(one name per line) that it is trying to migrate. If an error occurs during
the migration process, look into the next entry to the last printed entry.