This chapter describes how to install and configure Oracle Communications Contacts Server.
Before installing Contacts Server, read these chapters:
The instructions in this chapter assume:
You are deploying Contacts Server on a single host or Solaris zone, or multiple hosts or Solaris zones.
Oracle Directory Server Enterprise Edition is already installed.
You have installed and configured the application server as the web container for Contacts Server.
You have installed the database back end for storing the contact information.
The tasks to install Contacts Server are as follows:
To download Contacts Server software:
Download the Contacts Server software, and the Oracle Communications Directory Server Setup comm_dssetup.pl script, for your operating system from the Oracle software delivery website, located at:
The Contacts Server server software is part of the Calendar Server media pack.
Copy the Contacts Server ZIP file to a temporary directory on your Contacts Server hosts and extract the files.
Copy the Directory Server Setup ZIP file to a temporary directory on your Directory Server hosts and extract the files, to be able to install and run the comm_dssetup.pl script.
You prepare your Directory Server by running the comm_dssetup.pl script against it. You can run the comm_dssetup.pl script in either interactive or silent mode. For silent mode instructions, see "Running the comm_dssetup.pl Script in Silent Mode".
To prepare Directory Server and run the comm_dssetup.pl script in interactive mode:
On the host where Directory Server is installed, log in as or become the superuser (root).
Start Directory Server, if necessary.
Change to the directory where you extracted the Directory Server Setup ZIP file and run the installer.
commpkg install
For more information about running the installer, see "commpkg Reference".
Select Comms DSsetup and proceed with the installation.
Run the comm_dssetup.pl script in interactive mode (without any arguments), then enter your choices when prompted.
/usr/bin/perl comm_dssetup.pl
For more information, see "comm_dssetup.pl Reference".
Note:
You can use either LDAP Schema 2 or Schema 1.If necessary, provision users in the Directory Server.
If Directory Server is already installed at your site, users have already been provisioned. If you have just installed Directory Server at your site, then you need to provision users. For information, see the discussion on provisioning users and schema in Schema Reference.
To install the Contacts Server software:
On the Contacts Server host, log in as or become the superuser (root).
Go to the directory where you extracted the Contacts Server files.
Run the installer.
commpkg install
For more information about running the installer, see "commpkg Reference".
Select Contacts Server and proceed with the installation.
When the installation is complete, depending on your database choice for the back end, go to one of the following tasks:
You can either perform the following steps in this section or run the config-mysql script to prepare a new MySQL installation for use with Contacts Server. See "Running the config-mysql Script" for more information about running the config-mysql script.
Note:
When necessary, the following instructions show where commands differ between Solaris OS, and Red Hat Linux or Oracle Linux.Caution:
You must use the MySQL Connector version packaged with Contacts Server. Do not use a different version.To prepare MySQL Server for use with Contacts Server:
Create a mysql group. For example:
/usr/sbin/groupadd mysql
Create a mysql user by running following command.
/usr/sbin/useradd -g mysql mysql
Initialize the database.
Remove the pre-created data. For example:
rm -rf /opt/mysql/mysql/datarm -rf /var/lib/mysql
Create an initial database using the following command, substituting a different directory for /var/mysql if desired.
Solaris OS:
/opt/mysql/mysql/scripts/mysql_install_db --user=mysql --ldata=/var/mysql
Red Hat Linux or Oracle Linux:
/usr/bin/mysql_install_db --user=mysql --ldata=/var/lib/mysql
Verify that the MySQL configuration file, /etc/my.cnf, exists with the following content:
Solaris OS:
[mysqld] basedir = /opt/mysql/mysql datadir = /var/mysql default-storage-engine = InnoDB character-set-server = utf8mb4 transaction-isolation = READ-COMMITTED
Red Hat Linux or Oracle Linux:
[mysqld] basedir = /usr datadir = /var/mysql default-storage-engine = InnoDB character-set-server = utf8mb4 transaction-isolation = READ-COMMITTED
Change the value of basedir and datadir if needed. Make sure there are no extra spaces if you cut and paste the path.
Install the startup script:
Solaris OS:
cp /opt/mysql/mysql/support-files/mysql.server /etc/init.d/mysql
Red Hat Linux or Oracle Linux:
cp /usr/share/mysql/mysql.server /etc/init.d/mysql
Start MySQL Server.
/etc/init.d/mysql start
Change the MySQL root password.
Solaris OS:
/opt/mysql/mysql/bin/mysqladmin -u root password 'password'
Red Hat Linux or Oracle Linux:
/usr/bin/mysqladmin -u root password 'password'
Replace password with the appropriate password to use for the root user.
Run the secure MySQL installation to disable remote root access, remove anonymous users, remove test databases, and so on.
Solaris OS:
/opt/mysql/mysql/bin/mysql_secure_installation
Red Hat Linux or Oracle Linux:
/usr/bin/mysql_secure_installation
Create the MySQL user and database.
The following example uses nab as the MySQL user name, and nab as the database name. You can use different names.
# /opt/mysql/mysql/bin/mysql -u root -p Enter password: mysql> CREATE DATABASE nab CHARACTER SET = utf8mb4; mysql> CREATE USER 'nab'@'localhost' IDENTIFIED BY 'password'; mysql> GRANT ALL ON nab.* TO 'nab'@'localhost'; mysql> exit
For more information, see the MySQL CREATE USER syntax at:
http://dev.mysql.com/doc/refman/5.5/en/create-user.html
Replace localhost with the Contacts Server host name if MySQL Server is on a remote host (or use % for any host). Also, replace password with the password to use for the nab user.
Do one of the following to configure MySQL to start automatically upon system restart.
Create a symbolic link to the MySQL start script.
ln /etc/init.d/mysql /etc/rc3.d/S99mysql
If you need to add the stop scripts, use the following command:
ln /etc/init.d/mysql /etc/rc0.d/K48mysql
Configure MySQL to run with Solaris Management Facility (SMF). See the information about how to configure MySQL to run with SMF at:
https://dev.mysql.com/doc/refman/5.7/en/solaris-installation.html
http://www.oracle.com/technetwork/systems/articles/smf-example-jsp-136458.html
After preparing MySQL Server for use with Contacts Server, continue with the "Configuring Contacts Server" section.
Use the appropriate task based on your Oracle Database version:
Preparing Oracle Database 11g Release 2 or Oracle Database 12c Not Pluggable (non-CDB)
To prepare Oracle Database 11g Release 2 or Oracle Database 12c not pluggable (non-CDB):
If your Oracle Database resides on a different host from where you installed the Contacts Server software, copy the config-oracle script and the Util.pm module, located in the ContactsServer_home/tools/unsupported/bin directory, to the Oracle Database host.
Ensure that the Oracle environment has been configured after installing the software by running the /usr/local/bin/oraenv script (or corenv for C Shell).
Run the config-oracle script.
cd ContactsServer_home/tools/unsupported/bin
config-oracle -c
Respond to the following prompts.
Enter the Oracle SYS user password: Enter the name of the contacts database user (nab): Enter the password for contacts database user <user>: Please enter password again:
The script configures the Oracle Database for use with Contacts Server. See "Running the config-oracle Script" for more information.
After preparing Oracle Database for use with Contacts Server, continue with "Configuring Contacts Server."
Preparing Oracle Database 12c Container Database
You cannot run the config-oracle script to prepare an Oracle Database 12c container database (that is, one that uses a pluggable database). Instead, you must manually prepare Oracle Database for Contacts Server:
Ensure that the Oracle environment has been configured after installing the software by running the /usr/local/bin/oraenv script (or corenv for C Shell).
Run the following commands to prepare Oracle Database for Contacts Server:
sqlplus / as sysdba
ALTER SESSION SET CONTAINER = PDBORCL;
CREATE USER caldav IDENTIFIED BY password;
GRANT CONNECT, RESOURCE TO nab;
GRANT CREATE VIEW to nab;
GRANT UNLIMITED TABLESPACE to nab;
GRANT EXECUTE ON DBMS_LOCK to nab;
After preparing Oracle Database for use with Contacts Server, continue with the "Configuring Contacts Server" section.
When you run the Contacts Server installer in silent mode, you are running a non-interactive session. The installation inputs are taken from the following sources:
A silent installation file (also known as a state file)
Command-line arguments
Default settings
You can use silent mode to install multiple instances of the same software component and configuration without having to manually run an interactive installation for each instance.
This section includes:
To perform a Contacts Server silent installation:
Obtain the state file by one of the following means.
Run an interactive installation session and use the state file that is created in the /var/opt/CommsInstaller/logs/ directory. The state file name is similar to silent_CommsInstaller_20070501135358. A state file is automatically created for every run of the installation.
Create a silent state file without actually installing the software during the interactive session by using the --dry-run option, then modifying the state file. For example:
commpkg install --dry-run
Copy the state file to each host machine and edit the file as needed. See "Silent Mode File Format".
Run the silent installation on each host. For example:
commpkg install --silent input_file
where input_file is the path and name of the silent state file, for example /var/opt/CommsInstaller/logs/silent_CommsInstaller_20070501135358.
For details about the --silent option, see "install Verb Syntax".
Note:
Command-line arguments override the values and arguments in the state file.By default, shared components that require user acceptance for upgrading are not upgraded when you run a silent installation. The option to upgrade shared components in the silent state file is automatically disabled. That is, the option is set to UPGRADESC=No. This is true even if you explicitly asked to upgrade shared components when you ran the interactive installation that generated the silent state file. That is, you ran either commpkg install --upgradeSC y or you answered ”yes” when prompted for each shared component that needed upgrading.
Disabling upgrading shared components in the silent state file is done because the other hosts on which you are propagating the installation might have different shared components installed, or different versions of the shared components. Therefore, it is safer to not upgrade the shared components by default.
You can upgrade shared components when you run a silent installation by performing either of the following actions:
Use the --upgradeSC y option when you run the silent installation. (The command-line argument overrides the argument in the state file.)
Edit the UPGRADESC=No option in the silent state file to: UPGRADESC=Yes.
Caution:
If you do not upgrade shared components your installation might not work properly.The silent mode file (also known as a state file) is formatted like a property file: blank lines are ignored, comment lines begin with a number sign (#), and properties are key/value pairs separated by an equals (=) sign. Table 5-1 shows which options you can change and provides examples:
Table 5-1 Silent Mode File Options
| Option | Description | Example |
|---|---|---|
|
VERB |
Indicates which function to perform. For a silent install, this is set to install. |
VERB=install |
|
ALTDISTROPATH |
Indicates an alternate distro path. |
ALTDISTROPATH=SunOS5.10_i86pc_DBG.OBJ/release |
|
PKGOVERWRITE |
A boolean indicating whether to overwrite the existing installation packages. (See the --pkgOverwrite switch). |
PKGOVERWRITE=YES |
|
INSTALLROOT |
Specifies installation root. |
INSTALLROOT=/opt/sun/comms |
|
ALTROOT |
A boolean indicating whether this is an alternate root install. |
ALTROOT=yes |
|
EXCLUDEOS |
Specifies to not upgrade operating system patches. |
EXCLUDEOS=YES |
|
EXCLUDESC |
Specifies to exclude shared component patches. |
EXCLUDESC=no |
|
COMPONENTS |
A space separated list of mnemonics of the components to be installed. You can precede the mnemonic with a ~ to indicate that only the shared components for that product be installed. |
COMPONENTS=CS |
|
ACCEPTLICENSE |
This option is no longer used. |
Not applicable |
|
UPGRADESC |
Indicates whether all shared components should or should not be upgraded without prompting. |
UPGRADESC=no |
|
INSTALLNAME |
The friendly name for the INSTALLROOT. |
INSTALLNAME= |
|
COMPONENT_VERSIONS |
This option is unused. |
Not applicable |
To display a complete list of the product names (such as MS, MS64, CS) to use with the COMPONENTS property, run the commpkg info --listPackages command. This command displays the mnemonics for each product. For more information, see the discussion on the commpkg info command in "commpkg Reference".
This information explains how to install Contacts Server on Solaris OS Zones.
The topics in this section include:
You can install Contacts Server in the global zone, whole root non-global zones, and sparse non-global zones. Follow these guidelines:
Treat the global zone as an ”administration zone.”
Install shared components and OS patches in the global zone that are to be shared among all zones. However, do not install and run products from the global zone.
Use whole root non-global zones to run Contacts Server.
Do not use the global zone or sparse zones. A whole root zone can have versions that are different from other whole root zones, thus giving it a measure of being ”self-contained.”
Be aware of the following zone aspects:
You can have different shared component versions in the whole root non-global zone, but it isn't entirely insulated. If you do a packaging or patching operation in the global zone for a shared component, that operation is also attempted in the whole root zone. Thus, to truly have different shared component versions, use an alternate root.
To avoid affecting whole root zones you can attempt to never install and patch shared components in the global zone. However, it might not be realistic to never have to install or patch a shared component in the global zone. For example, NSS is a shared component, but it is part of Solaris OS. So to expect to never install and patch NSS in the global zone seems unrealistic, especially given it is a security component.
Although it isn't a recommended best practice, you can use Contacts Server in sparse non-global zones. Do note that shared components cannot be installed into the default root because many of them install into the read-only shared file system (/usr). Thus, you must run the installer in the global zone to install shared components into the default root. Prepend your selection with ~ in the global zone to install only the dependencies (that is, shared components). You do not have to install in the global zone first before installing in the sparse zone. The installer allows you to continue even when you do not install all the dependencies. However, upgrading the shared components in the global zone affects the sparse non-global zones, thus requiring downtime for all affected zones simultaneously.
Note:
Sparse root zones are not available beginning with Oracle Solaris 11.The non-global whole root zone scenario is the equivalent of installing Contacts Server on a single box with no zones. Simply install Contacts Server as you normally would.
Caution:
Any operations performed in the global zone (such as installations, uninstallations, and patching) affect the whole root zones.Although it isn't a recommended best practice, you can use Contacts Server in a non-global sparse root zone on Solaris 10. To install Contacts Server in a non-global sparse root zone, you first need to install or upgrade the applicable OS patches and shared components in the global zone. You are unable to do so in the sparse root zone, because the /usr directory (where the shared components reside) is a read-only directory in the sparse root zone.
Follow the pre-installation requirements as described in "Contacts Server Pre-Installation Tasks".
Verify that you are about to install the shared components and OS patches in the global zone and not the sparse root zone. To verify you are in the global zone, run zonename. The output should be global.
Run the installer in the global zone and only install or upgrade the OS patches and the Shared Components. Do not install Contacts Server in the global zone. To do this, add a ~ (tilde) to the component number you want to install in the sparse zone.
For example, if you plan to install Contacts Server in the sparse zone, you select ~1 during the global zone installation. The installer will know to only install dependencies and not the product itself.
Once you have the shared components and OS patches installed, install Contacts Server in the sparse root zone.
You must configure Contacts Server to complete the installation. You use the Contacts Server configuration command-line script, init-config, to perform this initial runtime configuration.
Before running the Contacts Server init-config script, ensure that you have satisfied the following prerequisites.
On the Directory Server host, you run the comm_dssetup.pl script, as described in "Preparing Directory Server".
(Linux only) On Contacts Server front-end hosts, install the openldap-clients RPM, which installs LDAP tools such as /usr/bin/ldapsearch and /usr/bin/ldapmodify.
Note:
If you are configuring Contacts Server with WebLogic Server in a secure-mode, ensure to perform the steps provided in the "Installing and Configuring WebLogic Server" section and keep the keystore details handy.When you configure Contacts Server for the first time with Oracle WebLogic Server in a secure mode, run the extractSSLArgs.sh script. This script validates the SSL configuration details in Oracle WebLogic Server and stores the valid details in a format that is required by Contacts Server for all future deployments and processing.
To validate and store Oracle WebLogic Server SSL details for Contacts Server in a secure mode:
Open a new terminal and prepare the terminal by sourcing the setDomainEnv.sh script of the Oracle WebLogic Server domain:
cd Weblogic_Domain/bin
source ./setDomainEnv.sh OR . ./setDomainEnv.sh
Set the WLST_PROPERTIES environment variable depending on the selected Oracle WebLogic Server keystore configuration.
If the CustomIdentityandCustomTrust keystore option is configured as the Oracle WebLogic Server keystore configuration, set the WLST_PROPERTIES variable to:
export WLST_PROPERTIES="-Dweblogic.security.TrustKeyStore=CustomTrust , -Dweblogic.security.CustomTrustKeyStoreFileName= WebLogic_home/user_projects/domains/base_domain/mytrust.jks"
where WebLogic_home/user_projects/domains/base_domain/mytrust.jks is the location of truststore file.
If the CustomIdentityandJavaStandardTrust keystore option is configured as the Oracle WebLogic Server keystore configuration, set the WLST_PROPERTIES variable to:
export WLST_PROPERTIES="-Dweblogic.security.TrustKeyStore=JavaStandardTrust"
Run the extractSSLArgs.sh bash shell script extractSSLArgs.sh which is available under the Contacts Server installed location: ContactsServer_Installedlocation/sbin:
sh ./extractSSLArgs.sh -u weblogic_admin_user -p weblogic_admin_user_password -l t3s://weblogic_server_host:SSL_port
If the execution of the script is successful, it creates .wls_sslargs in the configuration directory of your Oracle WebLogic Server domain. You can verify the creation of .wls_sslargs by navigating to Weblogic_Domain/config.
Do the following on the Contacts Server front-end hosts so that Contacts Server locates the proper JDK:
Create a symbolic link between /usr/jdk/latest and the desired installed JDK in the /usr/jdk directory. For example:
ln -s /usr/jdk/jdk1.7.0_25 /usr/jdk/latest
Define the JAVA_HOME variable in the GlassFish Server user's login profile. You cannot only define the variable in the current shell that you are using to run the init-config script.
If the GlassFish Server user is referencing a JDK in a different location, set that location in the user's .profile file by adding the following line. If you want, you can add the line to the system-wide profile file, /etc/profile, instead.
export JAVA_HOME=JDK_location
If you use WebLogic Server:
Ensure the WebLogic Administration Server and Managed Server are correctly set up with JDK1.8.0 update version support. Whenever you start or stop WebLogic Server from the system terminal, ensure the JAVA_HOME and PATH environmental variables on that terminal are pointing to the same JDK1.8.0_xx version which was used during the WebLogic Server setup. That is, the symbolic link /usr/jdk/latest, JAVA_HOME must be pointing to the same JDK location.
To run the Contacts Server initial configuration:
Log in as or become the superuser (root).
Note:
Log in as "su -" when running init-config if you installed GlassFish Server in a secure mode.Change to the ContactsServer_home/sbin directory.
The default installation directory is /opt/sun/comms/nabserver.
Run the initial configuration script and respond to the prompts.
See "Contacts Server Configuration Scripts" for more information.
Note:
Refer to "Information Requirements" for information about the values you need to provide during initial configuration.Run the initial configuration script in an interactive mode.
If you use GlassFish Server, run init-config
If you use WebLogic Server, run init-config -W
Note:
If you do not use the -W option, by default, GlassFish Server is used to configure the init-config script.When you configure Contacts Server for the first time with Oracle WebLogic Server in a secure mode, run the extractSSLArgs.sh script. This script validates the SSLconfiguration details in Oracle WebLogic Server and stores the valid details in a format that is required by Contacts Server for all future deployments and processing.
When prompted, enter the Contacts Server settings:
Directory to store configuration and data files
Contacts Server runtime user
Contacts Server runtime group
Fully qualified host name of this system.
Enter the Back-End Database Settings.
Choose MySQL database or Oracle database (the default is mysql), then enter the following information, depending on whether you chose MySQL database or Oracle database:
MySQL Database Details
Server Host
Server Port
Contacts Database User
Contacts Database User Password (The password you provided while creating the nab user in "Preparing MySQL Server for Use with Contacts Server".)
Contacts Server DB Name
Oracle Database Server Details
Server Host
Server Port
Service Name
Contacts DB User
Password (The password you provided while creating the nab user in "Preparing Oracle Database for Use with Contacts Server".)
If you receive a database connection error, you are prompted to re-enter all the database information in this step. When the validation passes, continue with the next step.
Enter the Contacts Server Back-End Document Store Settings.
Back-end document store type, either local, dbdocstore, or remote (See "Configuring the Contacts Server Document Store" for more information.)
Back-end name to with which the document store is associated
Back-end store path
Enter the application server configuration details.
Install Directory
Domain Directory
Document Root Directory
Server Target Name
Virtual Server Identifier
Application server administration server host
Secure Administration Server Instance
Application server administration server port
Administrator User ID
Administrator Password
Full URL of the deployed server (default: https://FQDN of host:443/)
Use / (root) as the default context URI for production deployments. Using root enables users to configure their clients by typing a host name. If root is not used, users must enter a long URL, potentially leading to misconfigurations. The following example URIs describe the behavior of this entry:
https:/host.example.com:8080/ - Deploy in root.
https:/host.example.com:8080/nabserver - Deploy in nabserver.
https:/host.example.com:8080 - Not allowed, deployment context cannot be blank.
https:/host.example.com:443/nab/dav - Not allowed, deployment context cannot be more than one level.
If you use GlassFish Server:
Using context root as the URI path replaces the GlassFish Server's main index.html file. Therefore, the GlassFish Server welcome page does not display at http://host:port.
If you use WebLogic Server:
The URI pattern for deploying the server must be:
https://FQDN of host:ManagedServer_Port/context-root
where:
ManagedServer_Port: WebLogic Server domain must be set up with at least one ManagedServer which hosts Contacts Server. The port of that Managed Server must be provided here.
context-root can be / or /nabserver.
Note:
If you select a secure mode, ensure to enter https and the SSL port of the Managed Server instance.Note:
You cannot deploy Contacts Server and Calendar Server in the same domain, even if you use different contexts, for example, /nabserver and /davserver. You must deploy Contacts Server and Calendar Server in different domains.Enter the User/Group Directory Server Details.
LDAP URL
The default uses LDAP over SSL (ldaps://). If you want Contacts Server to communicate by using SSL with Directory Server in the runtime configuration, you need to use LDAPS in the URL specification. You must also put the certificate database containing the Directory Server certificate in the ContactsServer_home/lib directory. This setup works only for Solaris OS. See the openldap documentation for the required SSL setup on Linux. If you use LDAP in the URL specification, you do not need to perform any SSL setup for the initial configuration. However, you can enable LDAP SSL communication in the runtime configuration as described in Contacts Server Security Guide.
Bind Distinguished Name (DN)
Bind Password
The following message appears if you do not have the correct password:
ldap_bind: Invalid credentials (49) Error validating password for cn=Directory Manager
In this case, you are prompted again to enter the password.
LDAP unique ID attribute
Enter the LDAP attribute whose value serves as the unique identifier for each account in the contacts database. The default is davuniqueid.
Caution:
Do not use the value of nsUniqueId in a production deployment. See "Changing the User Unique Identifier" for more information about choosing a production-ready value.User/Group default domain (The default value results from when you ran the comms_dssetup.pl script against the Directory Server.)
Enter the domain name for the LDAP users in the deployment.
Default organization DN (The default value results from when you ran the comms_dssetup.pl script against the Directory Server.)
Enter the organization DN under which all users and groups that belong to the default domain are located in the LDAP tree.
Contacts Server administrator user
Contacts Server administrator user password
If other messages appear when validation failed, you are prompted to re-enter all the Directory Server settings in this step.
Enter the Notification Mail Server Configuration Details.
Mail Server Host Name
Mail Server Port Number
When prompted whether to proceed with configuring Contacts Server, answer Y.
The installer displays messages indicating its actions and progress. The last messages indicate the location where the installation log file was written.
Restart the application server.
You can run the init-config script in a silent mode for GlassFish Server and WebLogic Server.
If you use GlassFish Server, see "Contacts Server Configuration Scripts" for more information.
If you use WebLogic Server, obtain the correct statefile to run using init-config in a silent mode. You should not use the statefile from the past release versions.
Perform the following step to obtain the correct statefile to run using init-config in a silent mode:
Complete the interactive-mode init-config -W configuration.
After the configuration is completed, a statefile is created in this location:
ContactsServer_home/install/nabserver-config-timestamp/saveState
Note:
If you want to save the statefile in a different location, run init-config in an interactive mode as: init-config -W -S customlocation_for_statefile.About the new parameter: From the Contacts Server 8.0.0.5.0 release onwards, a new parameter appsrv.isweblogic is created inside the statefile. Therefore, when Contacts Server is deployed on WebLogic Server, the appsrv.isweblogic parameter is set to true. If the appsrv.isweblogic parameter is set to false or the absence of this parameter indicates that Contacts Server is deployed on GlassFish Server.
If you want to re-run the Contacts Server configurator for WebLogic Server in a silent mode in the future, you can reuse this statefile as shown below:
init-config -s -f path_to_statefile_saved_during_freshconfig_usingWeblogic
After configuring Contacts Server, continue with the following chapters:
Go to "Configuring Contacts Server With Multiple Hosts" if you have multiple hosts in your deployment.
Follow the instructions in "Configuring the Contacts Server Document Store" to configure the document store.
Follow the instructions in "Contacts Server Post-Installation Tasks" to perform post-installation tasks.