Issues Related to Migrating Replicated Servers
Depending on your replication topology, and on your migration strategy, certain issues might
arise when you migrate replicated servers. These issues are described in the following sections.
Issues With the New Password Policy
If you are migrating a multi-master replicated topology, a situation will arise where a 6.0 master
is replicating to a version 5 server. In this situation, an object class violation will occur if changes
are made to the new password policy attributes on the 6.0 server, and replicated to the version 5
server. The password policy attributes are managed internally by the server but they might be
updated in the event of a bind, a user password modify, or the addition of an entry with the
userpassword attribute.
To avoid the object class violation, the 6.0 password policy schema le (00ds6pwp.ldif) must
be copied to every version 5 server that will be supplied by a 6.0 master. When the password
policy schema le has been copied, restart the version 5 server.
Migration of Replication Agreements
If possible, you should migrate replicated servers to the same host name and port number. If
you must change the host name or port number of a replicated server, all replication agreements
that point to that server must be updated manually to point to the new server. For example, if
you migrate a consumer server from red.example.com:1389 to blue.example.com:1389, the
replication agreements on all masters that point to red.example.com:1389 must be updated
manually to point to blue.example.com:1389.
Replication agreements from the migrated master to consumers in the topology are managed by
the dsmig migration tool. If your topology does not support automated migration, these
replication agreements must also be updated manually.
Migration of Referrals
Referrals are also aected if you migrate a master replica to a new host or port. The details of
each master in a topology are present in the Replica Update Vector (RUV) of all other servers in
the topology. The RUV of each server is used to determine the referrals. When you change the
host name or port number of a master server during migration, all referrals to that master from
other servers in the topology become invalid. The easiest way to correct this is to use the
following steps, in order, when performing the migration.
1. Before migrating a master server, verify that there are no pending changes to be replicated.
You can use the insync tool to do this.
IssuesRelatedto MigratingReplicatedServers
SunJavaSystemDirectoryServerEnterpriseEdition6.0 MigrationGuide • March200752
SunCondential:Registered