PingDirectory

Upgrade considerations introduced in PingDirectory 9.x

Keep in mind the following upgrade considerations introduced in PingDirectory 9.x versions.

Permissive Modify no longer enabled by default in Directory REST API

In previous versions, Permissive Modify behavior was enabled by default for all API modify (PATCH) requests. In version 9.3, this behavior is controlled by an always-use-permissive-modify configuration parameter, which now has a default value of false. If you see a change in your application’s behavior as a result of this default configuration, you can re-enable Permissive Modify by changing the value of the configuration parameter to true with bin/dsconfig.

Enabling Permissive Modify behavior affects operations like removing an attribute that does not exist, or adding a duplicate value to a single-value attribute, by returning a "success" response without actually modifying the underlying data. Having the always-use-permissive-modify configuration parameter set to false by default will return "failure" responses for such permissive operations.

Enabling replication-purge-obsolete-replicas

The following requirement applies when upgrading from a version earlier than 9.2 to version 9.2 or higher:

You must set the replication-purge-obsolete-replicas global configuration property to true on each server in the topology before beginning the upgrade process. Failure to do so could result in a server entering lockdown mode over missing changes from an obsolete replica.

Cleaning replication history

When cleaning replication history from a PingDirectory server, you must now use the new remove-defunct-server argument --performLocalCleanup. If you have existing automation around disaster recovery, the previous method of running remove-defunct-server without bind credentials no longer performs this replication cleanup step. For PingDirectory versions 9.0.0.0 and later, update any existing automation to use the --performLocalCleanup flag.