This chapter describes how to install and configure Oracle Communications Calendar Server.
Before installing Calendar Server, read these chapters:
The instructions in this chapter assume:
You are deploying Calendar 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 Calendar Server.
You have installed the database back end for storing the calendar information.
The tasks to install Calendar Server are as follows:
Download the Calendar 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:
Copy the Calendar Server ZIP file to a temporary directory on your Calendar Server hosts and extract the files, to be enable to install the Calendar Server software.
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 the Schema Reference.
To install the Calendar Server software:
On the Calendar Server host, log in as or become the superuser (root).
Go to the directory where you extracted the Calendar Server files.
Run the installer.
commpkg install
For more information about running the installer, see "commpkg Reference".
Select Calendar Server and proceed with the installation.
(Optional) If you are going to use remote document stores, install the Calendar Server software on the remote hosts.
When the installation is complete, depending on your database choice, 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 Calendar Server. See "Running the config-mysql Script" for more information.
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 Calendar Server. Do not use a different version.To prepare MySQL Server for use with Calendar Server:
Create a mysql group. For example:
/usr/sbin/groupadd mysql
Create a mysql user by running the 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 caldav and iSchedule databases.
The following example uses caldav as the MySQL user name, caldav as the database name, and ischedule as the iSchedule database name. You can use different names. For more information, see the MySQL CREATE USER syntax at:
http://dev.mysql.com/doc/refman/5.5/en/create-user.html
/opt/mysql/mysql/bin/mysql -u root -p Enter password: mysql> CREATE DATABASE caldav CHARACTER SET = utf8mb4; mysql> CREATE USER 'caldav'@'localhost' IDENTIFIED BY 'password'; mysql> GRANT ALL ON caldav.* TO 'caldav'@'localhost'; mysql> CREATE DATABASE ischedule CHARACTER SET = utf8mb4; mysql> GRANT ALL ON ischedule.* TO 'caldav'@'localhost'; mysql> exit
Replace localhost with the Calendar 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 caldav 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 must 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 following links for information about how to configure MySQL to run with Solaris Management Facility (SMF):
https://blogs.oracle.com/ritu/entry/how_to_configure_mysql_to
http://www.oracle.com/technetwork/systems/articles/smf-example-jsp-136458.html
https://blogs.oracle.com/smenon/entry/how_to_configure_mysql_to
After preparing MySQL Server for use with Calendar Server, continue with the "Configuring Calendar 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 Calendar Server software, copy the config-oracle script and the Util.pm module, located in the CalendarServer_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 CalendarServer_home/tools/unsupported/bin
config-oracle -c -i
Respond to the following prompts.
Enter the Oracle SYS user password: Enter the name of the Calendar db user (caldav): Enter the password for Calendar db user user: Please enter password again: Enter the name of the iSchedule db user (ischedule): Enter the password for iSchedule db user user_ischedule: Please enter password again:
The script configures the Oracle Database for use with Calendar Server. See "Running the config-oracle Script" for more information.
After preparing Oracle Database for use with Calendar Server, continue with the "Configuring Calendar Server" section.
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 Calendar 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 Calendar Server:
sqlplus / as sysdba
ALTER SESSION SET CONTAINER = PDBORCL;
CREATE USER caldav IDENTIFIED BY password;
GRANT CONNECT, RESOURCE TO caldav;
GRANT CREATE VIEW to caldav;
GRANT UNLIMITED TABLESPACE to caldav;
GRANT EXECUTE ON DBMS_LOCK to caldav;
Run the following commands to prepare the iSchedule database:
sqlplus / as sysdba
ALTER SESSION SET CONTAINER = PDBORCL;
CREATE USER ischedule IDENTIFIED BY password;
GRANT CONNECT, RESOURCE TO ischedule;
GRANT CREATE VIEW to ischedule;
GRANT UNLIMITED TABLESPACE to ischedule;
GRANT EXECUTE ON DBMS_LOCK to ischedule;
After preparing Oracle Database for use with Calendar Server, continue with the "Configuring Calendar Server" section.
When you run the Calendar 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 Calendar 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 Calendar Server on Solaris OS Zones.
The topics in this section include:
You can install Calendar 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 Calendar 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 Calendar 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 Calendar Server on a single box with no zones. Simply install Calendar 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 Calendar Server in a non-global sparse root zone on Solaris 10. To install Calendar 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 "Calendar 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 Calendar 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 Calendar 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 Calendar Server in the sparse root zone.
You must configure Calendar Server to complete the installation. You use the Calendar Server configuration command-line script, init-config, to perform this initial runtime configuration.
Before running the Calendar Server init-config script, ensure that you have satisfied the following prerequisites:
On the Directory Server host, you ran the comm_dssetup.pl script, as described in "Preparing Directory Server".
(Linux only) On Calendar 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 Calendar 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 Calendar 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 Calendar Server for all future deployments and processing.
To validate and store Oracle WebLogic Server SSL details for Calendar 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 Calendar Server installed location: CalendarServer_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.
If you chose a non-root user as the GlassFish Server runtime user, do the following on the Calendar Server front-end hosts so that Calendar 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 Calendar 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 CalendarServer_home/sbin directory.
The default installation directory is, /opt/sun/comms/davserver.
Run the Calendar Server initial configuration script and respond to the prompts.
See "Calendar Server Configuration Scripts" for more information.
Note:
See "Information Requirements" for information about the values you must provide during the 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 Calendar 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 Calendar Server for all future deployments and processing.
When prompted, enter the Calendar Server settings:
Directory to store configuration and data files
Calendar Server runtime user
Calendar 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
Calendar Database User
Calendar Database User Password (The password you provided while creating the dav user in "Preparing MySQL Server for Use with Calendar Server".)
Calendar Server DB Name
iSchedule DB Name
Oracle Database Server Details
Server Host
Server Port
Service Name
Calendar DB User
Password (The password you provided while creating the caldav user in "Preparing Oracle Database for Use with Calendar Server".)
iSchedule DB User
Password
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 Calendar Back-End Document Store Settings.
Back-end document store type, either local, dbdocstore, or remote (See "Configuring the Calendar Server Document Store" for more information.)
Back-end name with which the document store is associated
Back-end store path
Enter the iSchedule Back-End Document Store Settings.
Back-end document store type, either local, dbdocstore, or remote.
iSchedule back-end name
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
Application Server administration server port
Secure Administration Server Instance
Administrator User ID
Administrator Password
Full URI 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, which leads to misconfigurations. The following example URIs describe the behavior of this entry:
https:/host.example.com:443/ - Deploy in root.
https:/host.example.com:443/davserver - Deploy in davserver.
https:/host.example.com:443 - Not allowed, deployment context cannot be blank.
https:/host.example.com:443/cs/dav - Not allowed, deployment context cannot be more than one level.
If you use GlassFish Server:
Using 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 deploy Calendar Server by using a root (/) URI context, you cannot deploy Convergence in the same instance of GlassFish Server without moving the /iwc_static/ files to a different location. The Convergence static files are deployed in the default root context and if another application is deployed to /, GlassFish Server cannot find the /iwc_static/* URLs. This results in 404 error immediately after login.
Therefore, create an additional domain in GlassFish Server that listens on a different port so that Convergence and Calendar Server run in separate instances. See Oracle GlassFish Server 3.0.1 Reference Manual for information on creating a new GlassFish domain. Additionally, for assistance in configuring clients for non-root URL configurations, see the topic on accounts that use non-standard or demo settings in Calendar Server System Administrator's Guide.
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 Calendar Server. The port of that Managed Server must be provided here.
Note:
If you select a secure mode, ensure to enter https and the SSL port of the Managed Server instance.context-root can be / or /davserver.
Enter the User/Group Directory Server Details.
LDAP URL
The default uses LDAP over SSL (ldaps://). If you want Calendar Server to communicate by using SSL with Directory Server in the runtime configuration, you must use LDAPS in the URL specification. You must also put the certificate database containing the Directory Server certificate in the CalendarServer_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 need not perform any SSL setup for the initial configuration. However, you can enable LDAP SSL communication in the runtime configuration as described in Calendar 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 calendar 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 run 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 run 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.
Calendar Server administrator user
Calendar 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 Calendar Server, answer Y.
The configurator displays messages indicating its actions and progress. The last messages indicate the location where the installation log file was written.
Restart the application server.
Note:
If you use GlassFish Server, see "Calendar 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:
CalendarServer_home/davserver/install/davserver-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 Calendar Server 8.0.0.4.0 release onwards, a new parameter appsrv.isweblogic is created inside the statefile. Therefore, when Calendar 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 Calendar Server is deployed on GlassFish Server.
If you want to re-run the Calendar 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 Calendar Server, continue with the following chapters:
Go to "Configuring Calendar Server with Multiple Hosts" if you have multiple hosts in your deployment.
Follow the instructions in "Configuring the Calendar Server Document Store" to configure the document store.
Follow the instructions in "Calendar Server Post-Installation Tasks" to perform post-installation tasks.