After you have unzipped the server distribution file, you might want to carry out the following functions depending on your deployment requirements:

  • Custom Schema Elements. If your deployment uses custom schema elements in a custom schema file (for example, 98-schema.ldif), you can do one of the following:
    • Copy your custom schema file to the config/schema directory before running setup.
    • Copy your custom schema file to the config/schema directory after setup and re-start the server. If replication is enabled, the restart will result in the schema replicating to other servers in the replication topology.
    • Use the Schema Editor after setup. If replication is enabled, schema definitions added through the Schema Editor will replicate to all servers in the replication topology without the need for a server restart.
  • Certificates. If you are setting up a new machine instance, copy your keystore and truststore files to the <server-root>/config directory prior to running setup. The keystore and truststore passwords can be placed, in clear text, in corresponding and files in <server-root>/config.
  • Encryption Passphrase. Encryption for directory data, backups, LDIF exports, and log files can be enabled during setup by providing or generating an encryption key with a passphrase.
  • Locations. Location names are used to define a grouping of server products based on physical proximity. For example, a location is most often associated with a single datacenter location. During the installation, assign a location to each server for optimal inter-server behavior. The location assigned to a server within Global Configuration can be referenced by components within the server as well as processes external to the server to satisfy "local" versus "remote" decisions used in replication, load balancing, and failover.
  • Validate ACIs. Many directory servers allow for less restrictive application of its access control instructions (ACIs), so that they accept invalid ACIs. For example, if a Sun/Oracle server encounters an access control rule that it cannot parse, then it will simply ignore it without any warning, and the server might not offer the intended access protection. Rather than unexpectedly exposing sensitive data, server rejects any ACIs that it cannot interpret, which ensures data access is properly limited as intended, but it can cause problems when migrating data with existing access control rules to a server. If you are migrating from a Sun/Oracle deployment to a server, server provides a validate-acis tool in the bin directory (UNIX or Linux systems) or bat directory (Windows systems) that identifies any ACI syntax problems before migrating data. For more information, see Validating ACIs before migrating data.

Each server deployment requires an execution of setup. Duplicating a server-root is not supported. The installation of the server doesn't write or require any data outside of the server-root directory.

After you run the setup tool, do not copy the server-root to another location or system to duplicate the installation because this isn't a supported method of deployment. If a host or file system change is needed, you can move the server-root to another host or disk location.