8 Installing Messaging Server

This chapter describes how to install Oracle Communications Messaging Server. If you are installing Messaging Server in a highly available deployment, follow the instructions in "Configuring Messaging Server for High Availability." For more information on the Messaging Server install command, see the discussion on the commpkg install command in "commpkg Reference."

Before installing Messaging Server, read these chapters:

About Messaging Server Components

When you install Messaging Server, you install and configure one or more of the following components:

  • Message Store. Consists of a set of components that store, retrieve, and manipulate messages for mail clients.

  • Message Transfer Agent (MTA). Receives, routes, transports, and delivers mail messages using the SMTP protocol. An MTA delivers messages to a local mailbox or to another MTA.

  • Messaging Multiplexor (MMP). Enables scaling of the Message Store across multiple physical machines by decoupling the specific machine that contains a user's mailbox from its associated DNS name.

  • Webmail Server (mshttpd). Acts as a front-end host that handles the HTTP protocol retrieval of messages from the message store. This component is used by Convergence to provide web-based access to end users.

Installation Assumptions

The instructions in this chapter assume:

  • You are deploying Messaging Server on a single host or Solaris zone, or multiple hosts or Solaris zones.

  • Each Messaging Server component is one functional component of your multi-host deployment.

  • You are installing the Messaging Server component on a separate host or Solaris zone; you are not bundling the component with other Communications Suite products on the same host.

  • Oracle Directory Server Enterprise Edition (Directory Server) is already installed.

The instructions also assume the following for the specific Messaging Server components:

  • Message Store: If you are distributing multiple partitions of the message store across several hosts or zones, you can follow these instructions for each host on which you install store partitions.

  • Message Transfer Agent (MTA): This MTA relay in and MTA relay out is one functional component of your multi-host deployment.

  • Messaging Multiplexor (MMP): You are installing only the MMP front end; you are not installing message store or SMTP functions.

  • Webmail Server (mshttpd): You are installing only the Webmail Server front end; you are not installing message store or SMTP functions.

About Unified Configuration

You need to decide if you want to use Unified Configuration or legacy configuration. Unified Configuration is an improved, streamlined process to configure and administer Messaging Server. Unlike in legacy configurations, Unified Configuration uses validation to verify configuration accuracy, and employs a single tool to configure the entire Messaging Server configuration (with a few exceptions). For more information, see the discussion on Unified Configuration in the Messaging Server System Administrator's Guide.

Prerequisites for Installing Messaging Server

This section includes steps to take before installing Messaging Server. The topics in this section include:

Before Installing Messaging Server

The following steps must be completed for all Messaging Server components: Message Store, Message Transfer Agent (MTA), Messaging Multiplexor (MMP), and Webmail Server (mshttpd).

  1. Ensure that DNS is running and configured properly.

    For details, see "Checking the DNS Configuration."

  2. Ensure you have sufficient file descriptors on Linux. For details, see "Checking the Number of File Descriptors."

  3. Make sure you do not configure conflicting port numbers on a host when various components are running on a single machine.

    Table 8-1 lists the default port numbers used by Messaging Server.

Table 8-1 Messaging Server Default Ports

Port Number Purpose


Standard SMTP port or MMP SMTP Proxy


Standard POP3 port or MMP POP3 Proxy


Standard IMAP4 port or MMP IMAP Proxy


Default port for communications to back-end store through LMTP




Standard Message Submission (SMTP SUBMIT) port


IMAP over SSL or MMP IMAP Proxy over SSL


POP3 over SSL or MMP POP Proxy over SSL


Event Notification Service port


mshttpd daemon port


mshttpd over SSL daemon port


Used by Job Controller for product internal communication


Used by the Watcher for internal product communication

Preparing Directory Server

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."

Downloading the comm_dssetup.pl Script

  1. Download the comm_dssetup.pl script from the Oracle software delivery website, located at:


    You can either download the Oracle Communications Directory Server Setup (comm_dssetup.pl) file separately, or as part of the Messaging Server software.

  2. Copy the Directory Server Setup ZIP file to a temporary directory on your Directory Server hosts and extract the files.

Running the comm_dssetup.pl Script in Interactive Mode

To prepare Directory Server and run the comm_dssetup.pl script in interactive mode:

  1. On the host where Directory Server is installed, log in as root or become the superuser (root).

  2. Start Directory Server, if necessary.

  3. Copy the Comms DSsetup ZIP file to a temporary directory on your Directory Server hosts and extract the files.

  4. Run the Installer.

    commpkg install

    For more information about running the Installer, see "commpkg Reference."

  5. Select Comms DSsetup and proceed with the installation.

  6. 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."


    You can use either LDAP Schema 2 or Schema 1.
  7. 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.

Configuring Messaging Server Against a Directory Server Replica

The following conditions might prevent you from configuring Messaging Server against a Directory Server host:

  • You do not have Directory Server credentials.

  • Messaging Server cannot communicate directly with the Directory Server master.

To configure your deployment to be able to run Messaging Server against a Directory Server replica, you must update the Directory Server master, which then feeds the replica with the necessary changes. You cannot update the Directory Server replica directly because the master Directory Server overwrites it.

To configure Messaging Server against a Directory Server replica:

  1. Run the Messaging configure program using the replicated Directory Server credentials as described in "Configuring Messaging Server."

    Use the --ldif option to produce MessagingServer_home/data/install/configure.ldif file that is needed to allow proper privileges to the Directory Server.

  2. Move the configure.ldif file to the Directory Server master.

  3. Run the ldapmodify command on the configure.ldif file.

    Once the changes are replicated to the Directory Server replica, it is now configured to work with your Messaging Server.

Installing Messaging Server

The tasks to install Messaging Server are as follows:

Downloading the Messaging Server Software

  1. Download the media pack for Oracle Communications Messaging Server from the Oracle software delivery website, located at:


  2. Copy the Messaging Server ZIP file to a temporary directory on your Messaging Server hosts and extract the files.

Installing the Messaging Server Software

For each Messaging Server component, you must install the Messaging Server software on each individual server host (Message Store, MTA, MMP, and Webmail Server).

To install the Messaging Server software:

  1. On each server host (Message Server, MTA, MMP, and Webmail Server), log in as or become the superuser (root).

  2. Go to the directory where you extracted the Messaging Server ZIP file.

  3. Run the installer.

    commpkg install
  4. Choose the installation directory or accept the default.

  5. Select Messaging Server and proceed with the installation.

When the installation is complete, continue with "Configuring Messaging Server."

Installing Messaging Server in Silent Mode

When you run the Messaging 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 Run a Messaging Server Silent Installation

  1. Obtain the state file by one of the following two 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
  2. Copy the state file to each host machine and edit the file as needed. See "Silent Mode File Format."

  3. 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 the discussion on silent installation usage in "commpkg Reference."


    Command-line arguments override the values and arguments in the state file.

About Upgrading Shared Components

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.


If you do not upgrade shared components your installation might not work properly.

Silent Mode File Format

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 8-2 shows which options you can change and provides examples:

Table 8-2 Silent Mode File Options

Option Description Example


Indicates which function to perform. For a silent install, this is set to install.



Indicates an alternate distro path.



A boolean indicating whether to overwrite the existing installation packages. (See the --pkgOverwrite switch).



Specifies installation root.



A boolean indicating whether this is an alternate root install.



Specifies to not upgrade operating system patches.



Specifies to exclude shared component patches.



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.

To specify 64-bit Messaging Server:



This option is no longer used.

Not applicable


Indicates whether all shared components should or should not be upgraded without prompting.



The friendly name for the INSTALLROOT.



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."

Installing Messaging Server on Solaris Zones

This information explains how to install Messaging Server on Solaris OS 10 Zones.

The topics in this section include:

Installing on Solaris OS 10 Zones: Best Practices

You can install Messaging Server components 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 Messaging 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.”

  • The one exception to these two guidelines is to install the HA agent (MS_SCHA) only in the global zone. The Messaging Server Installer automatically propagates HA agents to all non-global zones. That is, the pkgadd -G switch is not used for HA agents.

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 Messaging 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.

Installing into a Non-Global Whole Root Zone

The non-global whole root zone scenario is the equivalent of installing Messaging Server on a single box with no zones. Simply install Messaging Server as you normally would.


Any operations performed in the global zone (such as installations, uninstallations, and patching) affect the whole root zones.

Installing into a Non-Global Sparse Root Zone

Although it isn't a recommended best practice, you can use Messaging Server in a non-global sparse root zone. To install Messaging Server in a non-global sparse root zone, you first need to install/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.

  1. Follow the pre-installation requirements as described in "Messaging Server Pre-Installation Tasks."

  2. 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.

  3. Run the installer in the global zone and only install/upgrade the OS patches and the Shared Components. Do not install Messaging Server components 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 Messaging 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.

  4. Once you have the shared components and OS patches installed, install Messaging Server components in the sparse root zone.

Guidelines for Using Oracle Solaris Cluster HA Packages in a Non-Global Zone

The HA agent (MS_SCHA) should be installed in the global zone only. The Messaging Server Installer will propagate the installation of the HA agent to all non-global zones. This is required since the version of the HA agent must be identical on all zones.

For more information, see the discussion on how to install Messaging Server Cluster HA Agent in non-global zones in "Installing Messaging Server Oracle Solaris Cluster HA Agent in Solaris Zones."

Next Steps

After installing Messaging Server, continue with the following chapters: