Stopping Synchronization at the Primary Installation

Before starting synchronization at the failover installation,
stop synchronization at the primary installation to prevent unwanted interaction
between the two systems. Depending on the reasons for failing over this is
accomplished in different ways. If the primary Identity Synchronization for Windows installation
is still operating properly, for example, failing over because a domain controller
or Directory Server is down, then just stop synchronization using the console
or idsync stopsync. Otherwise, stopping the Identity Synchronization for Windows daemon
(on Solaris) or service (on Windows) on each Identity Synchronization for Windows system that is
still operational is recommended.

Starting Synchronization at the Failover Installation

After synchronization is stopped at the primary installation,
it must be started at the failover
installation using the console or idsync startsync.

Note –

The Directory Server Connector will not enter the SYNCING state
until the Directory Server Plugins are re-installed on the preferred and secondary
masters (master3-eu.gt.com and master4-eu.gt.com).

The Active Directory Connector will need to process every entry
in Active Directory that was modified since it was last started, it might
take several minutes for it to begin propagating changes to Directory Server.
Setting the log level to INFO before starting synchronization
can reduce the impact of the Active Directory Connector having to catch up.

Re-enabling the Directory Server Plugins

To complete the failover process, the Directory Server Plugin
is re-enabled on each Directory
Server, which ensures:

The plugins running on the masters use the encryption key from the failover installation to
encrypt password changes.

Logging done by the plugins is sent to the Central Logger
of the failover installation.

The plugins must
be re-enabled in this order:

Failover installation's preferred master.

Failover installation's secondary master.

All other masters.

All read-only replicas.

Note –

The order in which the Directory Server Plugins are enabled is
important. If they are enabled in the wrong order, on-demand synchronization
requests could loop between two masters, tying up all Directory Server connections.

When re-enabling the plugins, make sure to specify the configuration
directory of the failover installation, for example, config-eu.gt.com

This reinstallation procedure can be automated by doing more work ahead
of time:

Install the Directory Server Plugins for the Failover configuration.

Export the plugins' configuration for each master from the cn=pswsync,cn=plugins,cn=config tree and it includes two entries.

Re-enable the Directory Server Plugins for the Primary configuration.

To failover:

Delete the cn=pswsync,cn=plugins,cn=config tree.

Add the failover installation entries using ldapmodify.

Restart the directory server.

Changing the PDC FSMO Role Owner

This step is optional. If the Active Directory Connector in the failover installation is configured to communicate
with a domain controller that does not have the PDC
FSMO role, then synchronization from Active Directory will be delayed due
to the Active Directory replication latency. To avoid this delay, the PDC
FSMO role can be transferred to the domain controller that the connector is
accessing.

Monitoring the Logs

After the Failover process is complete, monitor the central error log
of the failover installation for any unexpected warnings. Warnings similar
to the following will likely appear:

[08/Nov/2004:07:58:24.803 -0600] WARNING 25 CNN100 connectors-eu
"Unable to obtain password of user CN=Jane Test,OU=people,DC=gt,DC=com,
because the password was encoded by a previous installation of
Identity Synchronization for Windows Directory Server
Plugin. The password of this user cannot be synchronized at this time.
Update the password of this user again in Directory Server."

These warnings occur for each password update in the Retro changelog
that was made before the Directory Server Plugin was re-installed because
the Primary Directory Server Plugin was configured to use a different encryption key from the failover
Directory Server Plugin. Many of these password updates were likely synchronized
by the primary installation before it went off line, but those that occurred
after the primary installation went offline cannot be recovered. These users
must change their password either in Active Directory or Directory Server
to synchronize their passwords.

Failing Back to the Primary installation

The procedure for failing back to the
primary installation is identical.