Sun Java Enterprise System 2005Q4 Installation Planning Guide

Previous: Chapter 2 The Implementation Specifications

Chapter 3 The Installation Plan

This chapter describes the process of developing an installation plan. You begin with the information in the deployment architecture and the implementation specifications These documents describe the final state of your Java ES solution. You analyze the deployment architecture and the implementation specifications, and you determine how to use the Java ES installer and the configuration wizards to reach that final state.

This chapter describes how to develop an installation plan in the following sections:

Installation Planning Issues

The goal of the installation and configuration process is the distributed system described in the deployment architecture. The distributed system is composed of component instances that run on multiple computers and interoperate with each other. To achieve a functioning distributed system, you must install the component instances on multiple computers and perform the basic configuration that establishes interoperation among the component instances.

The procedures for installation and configuration are determined by the behavior of the Java ES installer and the requirements of the individual components. To ensure that you achieve a functioning distributed system, you must develop an installation plan that uses the installer appropriately and considers the requirements of the components used in the solution. Your plan must describe the correct order for installing the component instances and performing basic configuration. The plan must also specify the configuration values that configure the component instances to interoperate.

This section describes the major issues you must consider when developing an installation plan.

Distributed Installations

The quality-of-service requirements for production Java ES solutions lead to architectures that place component instances on more than one computer. For example, to achieve reliable messaging services the architecture might require two instances of Messaging Server on two different computers and use load balancing to establish a failover relationship between the two instances.

The Java ES installer, however, operates on only one computer at a time. Therefore, when you install a distributed solution, you must run the installer on every computer used in the solution.

In many cases, you must install a component or components on a computer and then run configuration wizards to perform the basic configuration. You typically complete installation and configuration on one computer before you proceed to install and configure another set of components on another computer. To install and configure distributed component instances, you might perform a sequence of tasks similar to the one illustrated in Figure 3–1.

Figure 3–1 Distributed Installation Procedure Example

On computer 01, install Messaging Server and Calendar Server,
configure Messaging Server, configure Calendar Server. On computer 02, repeat procedure.

Configuring for Interoperation

The goal of the installation process is a system of interoperating component instances. When you install components and perform basic configuration, you supply configuration values that result in component instance interoperation.

The configuration values that result in interoperation include such values as the URLs or port numbers that one component instance uses to communicate with another component instance and the administrator account IDs and passwords that one component instance uses to authorize access to another component instance. For example, if your solution uses Access Manager, you must first install and configure an LDAP repository, such as a Directory Server instance. Then, when you install and configure an Access Manager instance, you must provide configuration values that tell the instance where to find the LDAP directory you prepared.

The Java ES installer does not know what components are installed on the other computers used in the solution. For example, when you install Access Manager, the installer does not know where the appropriate LDAP directory is located. To ensure the success of your installation and configuration process, you must plan in advance which components are installed on each computer. As you add a components to the solution, you configure them to interoperate with the components already installed on the other computers.

You might perform a sequence of installation and configuration tasks similar to the one illustrated in Figure 3–2.

Figure 3–2 Configuring Components to Interoperate

Computer 01: Directory Server. Computer 02: install and configure
Access Manager to interoperate with Directory Server instance on computer 01.

Whatever the architecture of your solution, you must develop an installation plan that includes all the configuration values needed to configure the components and achieve an interoperating, distributed solution.

Component Dependencies

Some Java ES components cannot be installed and configured unless other components are installed and configured first. Dependencies occur for several reasons:

Some components cannot function unless certain other components are installed and configured. For example, the Communications Express interface needs data supplied by messaging and/or calendar services. The configuration procedure for Communications Express requires input of URLs that enable Communications Express to interoperate with already functioning messaging and calendar services. Because of this dependency, Messaging Server and/or Calendar Server must be installed and configured before Communications Express is installed and configured.
A number of components require an LDAP directory for authentication and authorization. The installation and configuration procedures for instances of these components require input of URLs for the LDAP directory service. Because of this dependency, Directory Server (or some other identity repository) must be installed before the components that use the LDAP directory service.
Some components modify the configuration of an existing component. For example, installing and configuring Access Manager modifies the LDAP directory schema. If your solution uses Access Manager, your installation plan must specify that an LDAP directory is installed and configured before Access Manager is installed.
A number of Java ES components are web applications. These components must be deployed into web containers to function. A web container must be installed and running before the components are installed and configured. You can use Web Server, Application Server, or some third-party web containers, but a web container must be present on the computer when you install the web application component.

Tip –
If the solution uses Web Server or Application Server, the Java ES installer can install the web container and the web application component at the same time and automatically deploy the web application component to the web container.
Components may be installed in a high-availability cluster provided by Sun Cluster software. The Sun Cluster software must be installed and running before the other components are installed and configured. Additionally, the Sun Cluster Agents for the other components must be installed and configured.

Notice that some of these dependencies are solution-wide and some are local. You consider system-wide dependencies and local dependencies differently when you develop your installation plan. The difference is described in the following example:

The dependency of Access Manager on Directory Server is a system-wide dependency. When you install Access Manager, you supply a URL for a directory service provided by one or more instances of Directory Server. Once Directory Server is installed and configured, the directory service is available to all components in the solution. This type of dependency determines the solution-wide sequence for installing and configuring component instances: Directory Server is installed and configured before Access Manager. In your installation plan, solution-wide dependencies determine the overall sequence of installation and configuration steps.

The dependency of Access Manager on a web container is a local dependency. To satisfy this dependency, a web container must be installed on the computer that runs Access Manager. This web container, however, does not provide services for the entire solution. In a distributed solution, web containers are typically installed on multiple computers. Each web container supports a different component locally. Therefore, in a distributed solution there is no single location for web container installation, and there is no single point in the installation sequence for installing the web container.

To develop an installation plan for a solution, you analyze the deployment architecture that describes a solution and identify dependencies among the components. Your plan must install and configure components in a sequence that satisfies all of the dependencies. In general, you develop the overall installation sequence from the solution-wide dependencies. Then you consider the local dependencies that might exist on each computer.

The component dependencies are listed in Table 3–1. For more information about working with these dependencies, see the descriptions of the individual components in Developing an Installation Plan.

Table 3–1 Java ES Component Dependencies


Product Component	Dependencies	Nature of Dependency	Must be Local?
Access Manager	Directory Server	To store configuration data; to store and enable lookup of user data	No
	J2EE web container, one of: -Application Server -Web Server -BEA WebLogic Server -IBM WebSphere Application Server	Access Manager must be deployed to one of these web containers	Yes
Access Manager SDK	Access Manager	To provide Access Manager services	No
	J2EE web container, one of: -Application Server -Web Server -BEA WebLogic Server -IBM WebSphere Application Server	Access Manager SDK must be deployed to one of these web containers	Yes
Administration Server	Directory Server	To provide a configuration directory	No
Application Server	Message Queue	To provide reliable asynchronous messaging	Yes
	Web Server (optional)	To provide load balancing between Application Server instances	Yes
	High Availability Session Store (optional)	To store session state, which supports failover between Application Server instances	Yes
Calendar Server	Directory Server	To store user data used for authentication and authorization	No
	Directory Preparation Tool	Prepares the LDAP directory for use with Calendar Server	No
	Access Manager (optional)	Required if your solution uses single sign-on	No
	Messaging Server (optional)	To provide email notifications	No
	Delegated Administrator (optional)	To mange LDAP schema; to provision users of calendar services	No
Communications Express	J2EE web container, one of: -Application Server -Web Server	Communications Express must be deployed to a web container	Yes
	Directory Server	To store user data, such as address books	No
	Directory Preparation Tool	To prepare the LDAP directory for Communications Express	No
	Either Access Manager or Access Manager SDK	To provide authentication and authorization services and single sign-on; a local Access Manager SDK provides access to remote Access Manager	Yes
	Messaging Server	To provide underlying messaging service	No
	Calendar Server	To provide underlying calendar service	No
Delegated Administrator	J2EE web container, one of: -Application Server -Web Server	Delegated Administrator must be deployed to one of these web containers	Yes
	Directory Server	To store the LDAP data that Delegated Administrator works with	No
	Directory Preparation Tool	To prepare the LDAP directory for Delegated Administrator	No
	Either Access Manager or Access Manager SDK	To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager	Yes
Directory Preparation Tool	Directory Server	Directory Preparation Tool prepares the directory for use with Java ES communications components	Yes
Directory Proxy Server	Administration Server	To configure Directory Proxy Server	No
	Directory Server	To provide underlying LDAP directory services	No
Directory Server	Administration Server	To configure Directory Server	No
High Availability Session Store	None
Instant Messaging	Directory Server	To store user, conference room, and news channel data	No
	Access Manager or Access Manager SDK (optional)	To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager	Yes
	J2EE Web Container, one of: -Application Server -Web Server (required for delivery of Instant Messenger client resources)	To support distribution and downloading of Instant Messenger client resources.	Yes
	Calendar Server (optional, if calendar pop-ups feature is used)	To support Calendar Server pop-ups	No
	Messaging Server (optional, if offline delivery of instant messages is used)	To support offline delivery of instant messages as email messages	No
Message Queue	None
Messaging Server	Directory Server	To store configuration data; To store and lookup user data for authentication and authorization	No
	Administration Server	To store configuration data in Directory Server configuration directory	Yes
	Directory Preparation Tool	To prepare the LDAP directory for Messaging Server	No
	Access Manager (if your solution uses single sign-on)	To provide single sign-on authentication and authorization service	No
	Delegated Administrator (optional)	To manage user and group data; to manage the directory schema	No
Portal Server	J2EE web container, one of: -Application Server -Web Server -BEA WebLogic Server -IBM WebSphere Application Server	Portal Server must be deployed to one of these web containers	Yes
	Directory Server	To store user data used for authentication and authorization	No
	Access Manager or Access Manager SDK	To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager	Yes
	Communications Express	To provide messaging and calendar channels for the portal desktop	No
Portal Server Secure Remote Access	Portal Server	To provide the underlying portal service.	Yes
	Either Access Manager or Access Manager SDK	To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager	Yes
Service Registry	Application Server		Yes
Sun Cluster Software	None
Sun Cluster Agents	Sun Cluster	To recognize components installed on Sun Cluster nodes	Yes
Web Proxy Server	Web Server	To provide remote access to web applications	Yes
Web Server	None

Redundancy Strategies

Most solutions intended for production use include some type of redundancy. Redundancy strategies use multiple instances of a component to provide a single service. Redundancy is used to satisfy quality of service requirements. For example, redundancy is used to increase throughput in order to satisfy performance requirements, or to avoid a single point of failure to in order satisfy reliability requirements.

Three strategies are available for using redundant instances of Java ES components: load balancing, clustering with Sun Cluster software, and Directory Server multi-master replication. The recommended installation and configuration procedure for each of these strategies is outlined briefly in the following paragraphs:

Load balancing can be implemented either in hardware or software. Load balancing is best set up by installing and configuring one instance of the load-balanced component, and then testing that the service provided by the first instance is available through the load balancer. After verifying that the service is available, you install and configure the additional instances of the component required by your deployment architecture. This phased approach to installing and configuring facilitates troubleshooting configuration problems.
Clustering is implemented in several steps. The first step is to install the Sun Cluster software and establish and configure the cluster. The next step is to install the components that run in the cluster. For example, the first step towards implementing the cluster shown in Figure 2–1 is installing Sun Cluster software on computers mscs01 and mscs02, and establishing and configuring the cluster. The second step is installing and configuring Messaging Server and Calendar Server. The third, and final, step is installing and configuring the Sun Cluster Agents for Messaging Server and Calendar Server. When the Sun Cluster Agents are configured, the cluster nodes recognize the Messaging Server and Calendar Server instances.
Directory Server multimaster replication is also implemented in several steps. The first step is installing, configuring, and verifying all of the Directory Server instances. The second step is shutting down all but one of the Directory Server instances. The third step is installing and configuring the other components in the solution. Any changes to the schema or directory structure are made to the single running Directory Server instance. The final step, after all component instances in the solution are installed, configured, and verified, is restarting the other instances of Directory Server and using the replication feature to configure synchronization and failover. This copies the modified and updated directory data to all of the Directory Server instances.

When your deployment architecture uses any of these redundancy strategies, you must develop a plan for installing multiple instances of a component and configuring the instances to operate as a single service.

Distributed Subcomponents

Some Instant Messaging components have subcomponents that can be separately installed and configured. For example, Messaging Server has four subcomponents, Message Transfer Agent, Message Multiplexor (MMP), Messenger Express Multiplexor (MEM), and Message Store. A deployment architecture might place these subcomponents on separate computer systems to satisfy quality of service reasons. For example, the sample architecture in Figure 2–1 places instances of MEM on computer systems CX1 and CX2, outbound Message Transfer Agent on computer systems MTA1 and MTA2, the inbound Message Transfer Agent on computer systems MTA3 and MTA4, the MMP on computer systems MMP1 and MMP2, and the message store on computer systems STR1 and STR2.

Table 3–2 lists the Java ES components that have separately installable subcomponents. Analyze the deployment architecture for your solution and determine whether it uses distributed subcomponents. If your solution uses distributed subcomponents, you need to develop a plan to install the subcomponents on the correct computer systems, in the correct order, and configure the subcomponents to interoperate. For more information on configuring distributed subcomponents, see the descriptions of individual components in Developing an Installation Plan.

Table 3–2 Components with subcomponents


Component	Subcomponent
Instant Messaging	Instant Messaging Multiplexor Instant Messaging Resources Instant Messaging Server
Messaging Server	Message Transfer Agent (MTA) Message Store Messaging Multiplexor (MMP) Messenger Express Multiplexor (MEM)

Subcomponents are separately installable. If your deployment architecture calls for distributed subcomponents, run the installer on each computer and select the subcomponents specified in the architecture. The input values required by the installer or configuration wizard are a subset of values for the complete component. For the components that are not configured by the installer, start the configuration wizard, select the subcomponents to be configured on the computer and supply the input values required by the configuration wizard.

LDAP Schema and LDAP Directory Tree Structure

Most Java ES solutions include Directory Server. Installing and configuring a solution requires input values that establish both the directory schema and the directory tree structure. Your installation plan must list input values that result in the correct LDAP schema and directory tree structure.

The LDAP schema and directory tree structure are specified before you begin the installation plan. For examples of specifications, see Developing Your User Management Specifications.

The LDAP schema is established by the following installation and configuration processes:

Installing Directory Server automatically establishes a directory with Schema 1. No input is required to select the schema.
Installing Access Manager automatically modifies the directory, and converts it to Schema 2. No input is required to select the schema.
Running the Directory Preparation Tool extends the schema for use with Messaging Server, Calendar Server, and Communications Express. The Directory Preparation Tool extends both Schema 1 and Schema 2 directories. Input values for the Directory Preparation Tool are listed in your installation plan.
Running Delegated Administrator extends the schema with object classes and attributes used to authorize and authenticate users for specific services. The input values depend on the service provided by your solution. The input values are listed in your installation plan. For more information on the input values, see Adding Procedures for Delegated Administrator to Your Installation Plan.

The installation and configuration process also establishes the basic directory tree structure:

Installing Directory Server creates the base suffix, or directory tree root. The base suffix is a required input value when the Java ES installer installs Directory Server. Your installation plan lists the base suffix as one of the input values for the installation process.
Installing and configuring Messaging Server branches the directory tree and creates an LDAP organization. This organization represents the email domain managed by the Messaging Server instance. The name of the organization is a required input for the Messaging Server configuration wizard. Your installation plan lists the organization DN as one of the input values for the Messaging Server configuration process.
Installing and configuring Calendar Server, Communications Express, Delegated Administrator, and Instant Messaging specifies where in the directory these components look up user data. An LDAP DN is required input for each component's configuration wizard, and your installation plan lists the DN as an input value for each configuration wizard. If the solution uses Access Manager single sign-on, all of these components must be configured to use the same location for user data, which is the organization that the Messaging Server configuration wizard created. The same LDAP DN is input in all of these configuration wizards. Your installation plan lists the organization DN as one of the input values for all of the configuration wizards.

The names for the LDAP base suffix and email domain organization are taken from the user management specification and added to the installation plan. For more information about the user management specification, see Developing Your User Management Specifications. For more information about adding the LDAP base suffix to your installation plan, see Table 3–5. For more information about adding the email domain organization to your installation plan, see Table 3–9, Table 3–10, Table 3–11, Table 3–13, and Table 3–14.

Java ES Installer Behavior

This section describes some behaviors of the Java ES installer that affect installation planning.

The Installer is Local

The Java ES installer installs component software on one computer at a time. For most solutions, this means the installer runs more than once. The installation plan must indicate how many times to run the installer. This section describe how to analyze a deployment architecture and determine how many times the installer is run to install and configure a solution.

A few solutions are installed on one computer only, and the installation plans for these solutions provide procedures for running the installer runs only once. The solutions that require running the installer only once are the following:

A number of component are installed on one computer to evaluate Java ES features
One component instance is added to an established solution. This includes adding component instances that have dependencies on existing components.

Most solutions are distributed across several computers. Installation plans for these solutions must describe running the installer multiple times to install and configure the complete solution. To analyze these solutions, use the following guidelines:

Most combinations of components on a computer can be installed by running the installer once. This is particularly true if the installer runs in configure now mode, because in configure now mode, the installer can install both a web container and the component that runs in the web container. In these cases, the installation plan describes running the installer once on the computer and selecting all of the components specified for the computer.

Tip –
Some components cannot be configured by the installer, even in configure now mode. When these components are installed on a computer, the configuration process is completed by running a configuration wizard for each component. When these components are installed in combination with components that are configured by the installer, the installer runs first. After the installer runs, the process is completed by running the configuration wizards for those components not configured by the installer. In these cases, the installation plan must describe running the installer and the correct sequence for running the configuration wizards.
Some combinations of components can only be installed by running the installer more than once on a computer. These combinations include the following:
- Some component combinations that include a web container. If Web Server or Application Server is installed in configure later mode, an instance of Web Server or Application Server must be configured and verified before the component that runs in the web server can be installed. If the solution uses third-party web containers, the web container must be installed with its own installer, started, and verified, before the Java ES components are installed. The installation plan must describe running the installer multiple times on each computer.
- Component combinations that use Sun Cluster software. If the components installed into the cluster are installed on a cluster file system, the Sun Cluster software must be installed and the cluster file system created before other components can be installed in the cluster nodes. The installation plan must describe running the installer multiple times on each computer.

The purpose of this section is to introduce the idea that installation plans must sometimes describe running the installer and the configuration wizards on one computer, or running the installer multiple times on one computer. For more information on the actual installation procedures for different component combinations, see Developing an Installation Plan.

Installer Operating Modes

The installer runs in two different modes, known as configure now and configure later. The modes differ in the following ways:

In configure now mode, the installer configures runnable instances of some, but not all, components. The components configured in configure now mode can be started and verified as soon as the installer completes. Runnable instances of the remaining components are created after the installer runs, by running component product configuration wizards. For components configured by the installer, the installer requires input of the configuration values, and the installation plan lists the configuration values as part of the instructions for running the installer. For components configured after the installer runs, the configuration values are required input for the configuration wizards, and the configuration values are listed as part of the instructions for running the configuration wizards.

Tip –
A significant feature of configure now mode is its ability to install a web container and components that run in the web container at the same time. The installer automatically deploys the components to the web container.
In configure later mode, the installer copies component software files to the computer but does not create runnable instances. Instances are created after the installer runs, by running the component product configuration wizards. The configuration values are required input for the configuration wizards, and the configuration values are listed as part of the instructions for running the configuration wizards.

The selected configuration option applies to an entire installation session. If you need to select different configuration options for some components, you might need to run additional installation sessions.

Installer Compatibility Checking

The installer performs some dependency and compatibility checking. Can only check what is installed locally. For example, if your solution is using a remote Directory Server instance, the installer cannot check whether the remote Directory Server is compatible with the Access Manager you are installing. If you are installing and configuring an all-new solution. It might be an issue if you are adding a new component to an established solution, or building a Sun Java System around existing components. For example, if you are already using Directory Server, and you are building a solution using Access Manager, Messaging Server, Calendar Server, and Communications Express around the existing Directory Server, compatibility among the components becomes an issue.

Component Dependency Checking. The Java ES installer will prevent you from omitting components that are required by other components you have selected for installation, but only on the local host. In a distributed solution, the installer does not check the remote host to verify that the remote component is there. You are responsible for verifying that the remote component is compatible and in the proper running state.
Upgrading. The Java ES installer does not perform any component upgrading except when Application Server and Message Queue have already been installed with the Solaris OS. In this case, the installer asks if you want to upgrade Application Server and Message Queue during installation.

The Java ES installer does perform upgrade of shared components. For more information of this topic, see Surveying Existing Hosts in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

Other Installation Issues

This section lists a number of specific issues that occur in some solutions with references to detailed information.

Table 3–3 Installation Issues to Consider


Solution Requires	Guidelines or Instructions
Using Solaris 10 zones	If you will be installing into Solaris 10 zones, refer to Solaris 10 Zones in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.
Using Directory Server encryption	Configuring LDAPS (SSL over LDAP) on the Directory Server instance Note: If Directory Server encryption is a requirement, Administration Server must be installed when Directory Server is installed.
Using a third-party web container with Access Manager	Third-party web containers (BEA WebLogic Server or IBM WebSphere Application Server) can be used with Portal Server and Access Manager. These containers must be installed and running before installing any Java ES components that depend on them. To use a third-party web container for Access Manager SDK, you must configure Access Manager SDK manually after installation. See Access Manager SDK With Container Configuration Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX Note: Portal Server can only use third-party web containers on Solaris OS. Note: Access Manager and Portal Server should use the same type of web container.
Using Apache Web Server for load balancing plugin	The Apache Web Server can be used with the Application Server load balancing plugin. In this case, the Apache Web Server must be installed and running before installing any Java ES components that depend on it. For additional information, refer to Installation Prerequisites in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.
Using Schema 1 LDAP	An installation example based on LDAP Schema 1 is described in Calendar-Messaging Schema 1 Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX. For a Schema 1 deployment, you cannot use Access Manager.
Configuring single user entry and single sign-on	Procedures for setting up single sign-on, can be found in the Chapter 8, Configuring and Using Single Sign-On, in Sun Java Enterprise System 2005Q1 Deployment Example Series: Evaluation Scenario. Access Manager is required for single sign-on.
Configuring High availability using HADB	An example of setting up HADB for high availability is contained in Web and Application Services Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.
Application Serverload balancing	An example that includes using the Application Server load balancing plugin is contained inWeb and Application Services Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.
Non-root ownership	If non-root ownership will be required for Application Server or Web Server, refer to one of the following examples: Access Manager Configured to Run as a Non-root User Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX, or Portal Server on a Non-root Owned Web Server or Application Server Instance Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

Developing an Installation Plan

Your deployment architecture and implementation specifications describe the final state of your solution. The deployment architecture shows you how many component instance are installed, which computer systems the component instances are installed on, and how the components interoperate. To reach the state described in the deployment architecture, you must install and configure the component instances in your solution, one computer system at a time, until you have installed and configured the complete solution. Your installation plan provides installation and configuration procedures every component instance in your solution, in the correct order.

To develop an installation and configuration plan, you must apply your knowledge of component dependencies and other installation issues to your Java ES deployment architecture and implementation specifications. You must determine the correct sequence for installing and configuring the component instances in your solution and the installation and configuration input values that will achieve interoperation of the component instances.

This section is a guide to analyzing a deployment architecture and set of specifications and developing an installation plan. In general, you begin as follows:

Open a text file, a blank sheet of paper, or some other medium for recording your plan.
In your deployment architecture, examine the components on each computer system and determine what component dependencies exist.
Identify the component instances that have no dependencies on other components. These are typically instances of Directory Server. You begin your installation plan with instructions for installing these component instances on the specified computer systems. Begin your installation plan by recording these computer systems, and the component instances installed on them.
Determine the correct installation/configuration values in your solution for these component instances on these specific computer systems. Add these configuration values to your installation plan.
Among the remaining components, determine which components have dependencies only on Directory Server. These are typically the computer systems with Access Manager. List these computer systems next in your installation plan.
Continue analyzing your specifications in order of component dependencies. Determine the necessary configuration values, and record these component instances in your plan.

For example, if you use this process to analyze the deployment architecture illustrated in Figure 2–1, you develop an installation plan that looks like Table 3–4.

Table 3–4 shows the first eight steps of the installation plan. In order to make clear the outline of the plan, the individual configuration values are not listed. In this plan, note the following:

The plan lists the computers in the solution according to the order in which the component instances will be installed and configured.
The sequence of installation is determined by applying both solution-level dependencies and the local dependencies. Applying the solution-level dependencies gives a basic sequence of Directory Server, Access Manager, Messaging Server, and then Calendar Server. Applying the local dependencies to this sequence adds Web Server instances on computers am01 and am02, and also Sun Cluster software and the Sun Cluster agents on computers mscs01 and mscs02.
The plan includes outline procedures for the installation and configuration procedures for all of the redundancy strategies employed in Java ES solutions. The list of tasks for ds01 and ds02 is an example of a plan for Directory Server multi-master replication. The list of tasks for am01 and am02 is an example of a plan for load balanced components. The list of tasks for mscs01 and mscs02 is an example of a plan for components that run in a Sun Cluster configuration.
The tasks for mscs01 provide and example of installing and configuring multiple components on one computer. The first time the installer runs, it installs the Sun Cluster core component. After the Sun Cluster core component is configured, the installer runs again. The second time the installer runs, it installs Messaging Server and Calendar Server. These components are configured in order, according to their dependencies. The third time the installer runs on the computer, it installs the Sun Cluster agents for Messaging Server and Calendar Server, which depend on the presence of Messaging Server and Calendar Server.

Table 3–4 Summary Installation Plan for the Sample Deployment Architecture


Computer	Installation and Configuration Tasks
ds01	Run the Java ES installer on this computer. Install and configure a Directory Server instance, using the configuration values specified in the user management specification. Start and verify the Directory Server instance.
ds02	Run the Java ES installer on this computer. Install and configure a Directory Server instance with the configuration values specified in the user management specification. Start and verify the Directory Server instance. Verify that the load balancer is working properly for both Directory Server instances. Shut down the Directory Server instance in DS02. Leave the Directory Server instance on DS01 running.
am01	Run the Java ES installer on this computer. Install and configure an Access Manager instance. Configure the Access Manager instance to interoperate with the logical directory service created by the load balanced Directory Server instances. Start and verify the Access Manager instance. Configure the Access Manager instance for load balancing.
am02	Run the Java ES installer on this computer. Install and configure an Access Manager instance. Configure the Access Manager instance to interoperate with the logical directory service created by the load balanced Directory Server instances. Start and verify the Access Manager instance. Configure the Access Manager instance for load balancing. Use the Access Manager console to modify directory entries for Access Manager. Verify that the two Access Manager instances are working correctly with load-balanced operation.
mscs01	Run the Java ES installer. Install the Sun Cluster core component. Prepare the computer for Sun Cluster configuration. This step includes creating and mounting file systems used by Sun Cluster. Run the Sun Cluster configuration wizard. Establish and configure the cluster.
mscs02	Run the Java ES installer. Install the Sun Cluster core component. Prepare the computer for Sun Cluster configuration. This step includes creating and mounting file systems used by Sun Cluster. Run the Sun Cluster configuration wizard. Establish and configure the cluster. Complete the configuration of the Network Timing Protocol (NTP) on ms01 and ms02. Add the quorum device to the cluster (connected to both computers). Create cluster file systems, and resource groups, set up virtual host name and IP address. Verify the cluster's failover capabilities.
mscs01	Run the Java ES installer. Install Messaging Server and Calendar Server. On computer ds01, run the Directory Server Preparation Tool. Run the Messaging Server configuration wizard to create a Messaging Server instance. Supply configuration values that create a branch in the LDAP directory tree according to the user management specification. Supply configuration values that configure the Messaging Server instance to interoperate with the load-balanced Access Manager instances and load-balanced Directory Server instances. Configure Messaging Server for single sign-on. Start and verify the Messaging Server instance. Run the Calendar Server configuration wizard to create a Calendar Server instance. Supply configuration values that configure the instance to use the LDAP branch created by Messaging Serverconfiguration for user and group data. Supply configuration values that configure the Calendar Server instance to interoperate with the load-balanced Access Manager instances and load-balanced Directory Server instances. On computer mscs02 create a Calendar Server user, user group, and directory. Edit the Calendar Server configuration file. Set configuration parameters to use the virtual IP address instead of the computer's IP address. Configure Calendar Server for single sign-on. Start and verify the Calendar Server instance.
mscs01	Run the Java ES installer. Install Sun Cluster Agent for Messaging Server and Sun Cluster Agent for Calendar Server. Using the Messaging Server agent, create and enable a Messaging Server resource. Verify failover of the Messaging Server resource from mscs01 to mscs02. Using the Calendar Server agent, create and enable a Calendar Server resource. Verify failover of the Calendar Server resource from mscs01 to mscs02.
mscs02	The instances you configured on mscs01 are automatically recognized as shared resources.

The rest of this section describes how to analyze your deployment architecture and implementation specifications in detail. It covers the components individually, in an order based on beginning with the least dependent and proceeding to the most dependent. It describes what to look for and how to develop the configuration values for your solution. Notice that the components that satisfy local dependencies, such as Sun Cluster, Application Server, and Web Server are listed last. The need for these components can arise anywhere in the installation plan, and your plan might install these components more than once.

Directory Server

Directory Server provides LDAP directory services for other components. The directory can be used for data about the configuration of other components, data about users and groups of users, or both.

Examine your deployment architecture. Locate any instances of Directory Server. Directory Server has no dependencies on other components, and you can install Directory Server first, on the specified computer systems.

Tip –

For information on setting up Directory Server replication, see Sun Java System Directory Server 5 2005Q1 Administration Guide.

Tip –

If your solution runs a 32-bit Directory Server on a 64-bit Solaris SPARC Platform, some special considerations apply. For more information, see Directory Server Postinstallation Configuration in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

Basic Installation Procedures for Directory Server

The basic procedures for installing and configuring Directory Server are as follows:

Install and configure Directory Server on the computer systems specified in your deployment architecture. When you install Directory Server, you specify the base, or root, DN for the directory tree and the administrator accounts.
Start and verify all of the Directory Server instances.
If your solution uses load balancing, verify that the load balancing is routing requests among the Directory Server instances.
If your solution uses Directory Server multi-mastering replication, shut down all but one of the Directory Server instances.
Install and configure the other Java Enterprise System components in your solution. Depending on what other components are used in your solution, installing and configuring the other component instances can add configuration data to the directory, update the LDAP schema, or modify the LDAP directory tree. The effects of installing and configuring other components are described in the following sections, component by components.

If your solution uses multi-mastering replication, you complete the configuration of Directory Server after all other components are installed and configured. The basic steps for this are as follows:

After all other components are installed and configure, restart the Directory Server instances that you shut down in A.
Configure multi-master replication. This will synchronize the contents of the directories (copies the data from the one instance that ran throughout the installation and configuration process to all of the newly started instances).

Choosing Configuration Values for Directory Server

For each Directory Server instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. For example, if your solution has multiple Directory Server instance, the configuration values must configure the Directory ServerDirectory Server instances to interoperate with each other. Use Table 3–5 to help you choose configuration values.

Table 3–5 Key Configuration Values for Directory Server Instances


Input Field	Choosing a Value for Your Solution
Administrator User ID and password	You assign the ID and password for administrator account for the Directory Server instance. See Developing Your User Management Specifications
Directory Manager ID and Password	You assign the password for the Directory Manager account. See Developing Your User Management Specifications
Server Identifier	You assign the label that identifies the Directory Server instance in the Administration Server console. The default is the computer's hostname. The default value is usually the best choice.
Server Port	The port on which the Directory Server instance accepts connections from other components. Specified in your network connectivity diagram. For more information see Developing a Network Connectivity Specification.
Suffix	The value you supply in this field establishes the base suffix, or root DN of the LDAP directory tree. This value is specified in the directory tree specification. See Specifying the Directory Tree Structure for a Solution .
Administration Domain	The value you supply is used in the Administration Server console to group the components installed on the computer. The default value is the DNS domain of the computer on which you are installing.
System User and System Group	The Directory Server instance will run under this user ID and group. The default values are `root` and `other.`
Store User Data and Group Data on This Server, etc.	Use these fields to define the function of the Directory Server instance. The default is for the Directory Server instance to serve as the directory for both user and group and configuration data, with the same URL for client connections. If your solution calls for separate directories for user and group data and configuration data, you can use these fields to indicate the function of the instance. To install an instance for configuration data only, select Store User and Group Data in the Following Instance, and specify another Directory Server instance. On the next page, select Store Configuration Data on This Server. Use the remaining fields to specify the URL the instances uses for client connections. To install an instance for user and group data only, select Store User and Group Data on This Server. On the next page, select Store Configuration Data in the Following Instance, and supply the URL for the configuration data instance of Directory Server Use the remaining fields to specify the URL the instances uses for client connections.

Note –

The names used in this table for the configuration values are the names used in the Java ES installer. These are the names you see if you install Directory Server in configure now mode. If you install Directory Server in configure later or silent mode, you may need to use different names for these key configuration values.

Adding Installation Procedures for Directory Server to Your Installation Plan

To begin your installation plan, add installation and configuration instructions for Directory Server, as follows:

If theDirectory Server instances are load balanced, the first step in your installation plan is confirming that the load balancer is functioning before anyJava ES software is installed.
Next, in your plan, list all of the computers with Directory Server instances.
1. For each computer, add an instruction to run the Java ES installer and select Directory Server.
2. If other components are installed on the same computer system, you can add instructions to select all of the components at the same time, but your plan must put the instructions for configuring, starting, and verifying the Directory Server instances before the instructions for configuring or starting any instance of any other component. For example,
3. If your solution uses multi-mastering replication, you must choose one of the Directory Server instances to be the master that runs while other components are installed and configured. List the computer with this instance first.
4. If your deployment architecture has separate configuration—only Directory Server instances, list these first. Configuration-only instances must be installed and running before user and group instances are installed.
Underneath each Directory Server instance in your plan, list the key values for configuring the instance.
If the solution uses multi-mastering replication, add an instruction to shut down all but one of the Directory Server instances.

Administration Server

Administration Server provides administrative support for Directory Server, Directory Proxy Server, and Messaging Server.

Administration Server has a solution-level dependency on Directory Server. Administration Server stores configuration data in the LDAP directory. If your solution uses separate Directory Server instances for user and group data and configuration data, you specify the Directory Server instance designated for configuration data. Therefore, it is logical to install and configureAdministration Server immediately after Directory Server.

Note –

If your solution uses Directory Server Console, you must plan to install Administration Server when Directory Server is installed.

Basic Installation Procedures for Administration Server

The basic procedures for installing and configuring Administration Server are as follows:

Install and configure Administration Server on the computer systems specified in your deployment architecture. When you install Administration Server, you specify the Directory Server instance where Administration Server configuration data will be stored.
Start and verify all of the Administration Server instances.
If your solution uses load balancing, verify that the load balancing is routing requests among the Administration Server instances.

Choosing Configuration Values for Administration Server

For each Administration Server instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. Specifically, you identify the Directory Server instance where Administration Server stores its configuration data. UseTable 3–6 to help you choose configuration values.

Table 3–6 Key Configuration Values for Administration Server


Input Field	Choosing a Value for Your Solution
Server Root	The pathname under which Administration Server is installed.
Administration Port	The port at which the Administration Server accepts connections.
Administration Domain	The label used in the administration console to group the component instances administered by the Administration Server instance.
System User and System Group	The user ID and group under which the Administration Server instance runs. This user ID and group you specify here must match the user ID and group for the component instances administered by Administration Server. For example, if you are installing Administration Server to mange a specific Directory Server instance, the Administration Server user and group must match the Directory Server user and group.
Administration User ID and Password	Establishes the administrator account and password used to log in to the administration console.
Directory Server Host and Directory Server Port	Specifies the Directory Server instance where Administration Server stores configuration data for the component instances in the administration domain.

Adding Procedures for Administration Server to Your Installation Plan

To add installation and configuration instructions for Administration Server, do the following:

If theAdministration Server instances are load balanced, the first instruction in your installation plan is confirming that the load balancer is functioning before anyJava ES software is installed.
Next, in your plan, list all of the computers with Administration Server instances. For each computer, write Administration Server. Underneath Administration Server, add an instruction to run the Java ES installer and select Administration Server.
Underneath each heading for an Administration Server instance, list the key values for configuring the instance. Use Table 3–6 to help you select configuration values.
Following the configuration values, add an instruction to start and verify the Administration Server instance.
If the Administration Server instances are load balanced, add an instruction to verify operation of the load balancer.

Directory Proxy Server

Directory Proxy Server manages access to an LDAP directory that is maintained by Directory Server. Routing requests for directory information in solution with directory information accessed by internal and external users, and distributed across sites.

Solution-level dependencies on Directory Server and Administration Server. No local dependencies. Therefore, if a solution uses Directory Proxy Server, it is logical to install and configure Directory Proxy Server after Directory Server and Administration Server, but before any of the other components, which are potentially consumers of Directory Proxy Server services.

Basic Installation Procedures for Directory Proxy Server

The basic procedures for installing and configuring Directory Proxy Server are as follows:

Install and configure Directory Proxy Server on the computer systems specified in your deployment architecture. When you install Directory Proxy Server, you specify the Directory Server instance where Administration Server configuration data will be stored.
Start and verify all of the Directory Proxy Server instances.
If your solution uses Directory Proxy Server to implement load balancing for the Directory Server instances, verify that the load balancing is routing requests among the Directory Server instances.

Choosing Configuration Values for Directory Proxy Server

For each Messaging Server instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. For example, instances to interoperate with each other. Use Table 3–7 to help you choose configuration values.

Table 3–7 Key Configuration Values for Directory Proxy Server


Input Field	Choosing a Value for Your Solution
Directory Proxy Server Port	The port on which Directory Proxy Server listens for connections. This should be specified in the network connectivity specification. For more information, see Developing a Network Connectivity Specification.
Administration Root Directory	The directory where the installer stores configuration data about the Directory Proxy Server instance for Administration Server's use.

Adding Installation Procedures for Directory Proxy Server to Your Installation Plan

To add installation and configuration instructions for Directory Proxy Server, do the following:

If theDirectory Proxy Server instances are load-balanced, add an instruction to verify that the load balancer is functioning before anyJava ES software is installed.
In your plan, list all of the computers with Directory Proxy Server instances. For each computer, add Directory Proxy Server to list of components installed.
Beneath the Directory Proxy Server heading, add an instruction to run the Java ES installer, that includes the following:
1. Selecting Directory Proxy Server.
2. A list of the key values for configuring the instance. Use Table 3–6 to help you select configuration values.
Add an instruction to start and verify the Directory Proxy Server instance.
If the Directory Proxy Server instances are load balanced, add an instruction to verify operation of the load balancer.

Access Manager

Access Manager provides authentication and authorization services for most other Java ES components. In any particular solution, the components that use Access Manager services depend on the specific solution, but almost every other Java EScomponent is a possible consumer of Access Manager services.

Access Manager has only one solution-level dependency, on a source of user and group data. Therefore, it is logical to install and configureAccess Manager immediately after Directory Server and Administration Server, before any possible consumers of Access Manager services are installed and configured.

Access Manager has a local dependency on a web container.

Note –

Access Manager has two operating modes. Legacy mode (6.x style) supports Access Manager 6 features. If you are installing Access Manager with Portal Server, Messaging Server, Calendar Server, Delegated Administrator, or Instant Messaging, you must select the Access Manager Legacy (6.x) installation type.

Realm mode (7.x style) supports Access Manager 7 features, including the new Access Manager 7 Console. However, realm (7.x) can only be used in solutions that include none of the components listed above.

Note –

If your deployment architecture places Portal Server and Access Manager on separate computers, some considerations apply. For more information, see Portal Server Using a Remote Access Manager Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

Basic Installation Procedures for Access Manager

The basic steps for installing and configuring Access Managerare the following:

Use the Java ES installer to install Access Manager on all computers systems specified in your deployment architecture.
1. When you install Access Manager you must specify the web container in which Access Manager runs.
2. When you install Access Manager you must specify the repository for user and group data (typically a Directory Server instance, specified with a URL).
3. Installing Access Manager modifies the LDAP directory to support single sign-on (sometimes referred to as schema 2). For more information about LDAP schemas, see Specifying the LDAP Schema for a Solution.
Start and verify all instances of Access Manager.
If your solution uses load balancing for the Access Manager instances, verify that the load balancer is working properly.

Choosing Configuration Values for Access Manager

For each Access Manager instance in your solution, you must specify configuration values that configure the instance to interoperate with the other components in the solution.

Table 3–8 Key Configuration Values for Access Manager Instances


Input Field	Choosing a Value for Your Solution
Administrator User ID and Administrator Password	You establish the password for the fully privileged administrator account. This account logs in to the Access Manager console. This account has complete access to all directory entries managed by Access Manager.
LDAP User ID and LDAP Password	You establish the password for a less privileged administrator account. This account logs in to the Access Manager console. This account has read and search privileges.
Install Type	You indicate whether the Access Manager instance should operate in realm mode or legacy mode. Legacy mode is required if the instance is interoperating with Portal Server, Messaging Server, Calendar Server, Instant Messaging, or Delegated Administrator.
Web Container	You specify the web container in which the Access Manager instance runs. Depending on your selection, the installer prompts you for the necessary information.
Host Name, Web Server Port, Web Server Instance Directory, Document Root Directory, Secure Server Instance Port	If you are installing Access Manager and Web Server together, use these fields to specify how Web Server is installed. If you are installingAccess Manager on a computer where Web Server is already installed, use these fields to specify an existing Web Server instance.
Installation Directory, Access Manager Runtime Instance, Instance Directory, Access Manager Instance Port, Document Root, Administrator User Id, Administrator Port, Secure Server Instance Port, Secure Administration Server Port,	If you are installing Access Manager and Application Server together, use these fields to specify how the Application Server is installed. If you are installingAccess Manager on a computer where Application Server is already installed, use these fields to specify an existing Application Server instance.
Host Name, Services Deployment URI, Common Domain Deployment URI, Cookie Domain, Administration Console (Deploy New Console, Use Existing Console), Console Deploy URI, Password Deployment URI, Console Host Name, Console Port	Use these fields to specify how Access Manager Identity Management and Policy Services Core (core) and Administration Server Console (console) services are deployed to Web Server.
Directory Server Host, Directory Server Port, Access Manager Directory Root Suffix, Directory Manager DN, Directory Manager Password.	Use these fields to provide access to the Directory Serverinstance that your solution uses for user and group data. If you are using something other than Directory Server as your repository for user and group data, this URL must be? Directory Server Host and Directory Server Port were assigned when Directory Server was installed and configured. If Directory Server is configured with multi-master replication, and/or load balancing, use the logical address for the replicated/load-balanced service, rather than the name of one of the computers. Access Manager Directory Root Suffix is the directory entry that Access Manager uses as the directory root. The default value is the actual directory root, also established when the Directory Server instance was installed. The Directory Manager DN and password were also established when the Directory Server instance was installed. If your solution uses some other source of user and group data, this URL must be?
No, Yes, Organization Marker Object Class, Organization Naming Attribute, User Marker Object Class, User Naming Attribute	Use these fields to configure Access Manager to work with a directory already provisioned with user data.

Adding Installation Procedures for Access Manager to Your Installation Plan

To add installation and configuration instructions for Access Manager, do the following:

If theAccess Manager instances are load balanced, the first instruction in your installation plan is confirming that the load balancer is functioning before anyJava ES software is installed.
Next, in your plan, list all of the computers with Access Manager instances.
1. Access Manager has a local dependency on a web container. Each computer that runs an instance of Access Manager must also run an instance of the specified web container. Your deployment architecture should indicate which web container your solution is using.
2. For each computer, add an instruction to run the Java ES installer and select Access Manager. If you are using Web Server or Application Server as your web container, add an instruction to select the web container, too. The installer is capable of automatically deploying Access Manager to the selected web container.
3. If the computers that run Access Managerare already listed in your plan (for example, if Directory Server is installed on the same computer) add an instruction to select Access Manager. You can install Access Manager at the same time as Directory Server, even if you use the configure now option, but your plan must put the instructions for configuring, starting, and verifying the Directory Server instances before the instructions for configuring or starting any instance Access Manager.
Underneath each Access Manager instance, list the key values for configuring the instance. Use Table 3–8 to help you select configuration values.
Underneath each Web Server or Application Server instances, list the key values for configuring the instance. For information on selecting configuration values for these components, see Web Server or Application Server.
If your solution uses one of the third-party web containers that supports Access Manager, you install Access Manager in configure later mode. To configure and deploy the Access Manager instance, you run an Access Manager configuration tool named amconfig. For more information, see Access Manager amconfig Script in Sun Java System Access Manager 7 2005Q4 Administration Guide. The third-party web container must be installed and running before you run the amconfig configuration tool.
For each computer, add an instruction to start and verify the Access Manager instance. If the instances are load balanced, add an instruction to verify operation of the load balancer.

Messaging Server

Examine your deployment architecture for computer systems with instances of Messaging Server.

Messaging Server provides mail collection, storage, and delivery services. Messaging Server's services can be accessed through Communications Express, Portal Server, and third-party email clients.

Messaging Server has a solution-level dependency on a source of user and group data. The user and group data contains account names and passwords that are used to verify access to messaging services. The user and group data also identifies user's mail servers and other information needed to deliver mail. This information is typically in an LDAP directory managed by Directory ServerTherefore, it is logical to install and configureAccess Manager after Directory Server.

If your solution uses single sign-on, Messaging Server is a consumer of Access Manager services. In single sign-on solutions, Messaging Server must be installed and configured after both Directory Server and Access Manager are installed and configured.

In order to use Messaging Server with an LDAP directory managed by Directory Server, the Directory Preparation Tool must be run on the computer that is running the Directory Server instance. Therefore, the Directory Preparation Tool is covered as part of Messaging Server installation.

Installing and configuring Messaging Server modifies the LDAP directory tree, as described in Developing Your User Management Specifications. This modification adds a branch to the tree that represents the email domain managed by the Messaging Server instance. Information about users in the email domain is added to this email domain branch. If your solution uses single-sign on, all of the other components in the solution, such as Calendar Server, should also store their user data in the email domain branch. Therefore, it is logical to install and configure Messaging Server before installing any other components that might use the email domain branch.

Basic Installation Procedures for Messaging Server

Determine which redundancy strategy, if any, your solution is using for messaging services.
- If your solution uses load-balancing.
- If your solution uses clustered messaging services, the Sun Cluster software must be installed, configured, and verified before Messaging Server.
Use the Java ES installer to install Messaging Server on all computers systems specified in your deployment architecture. The installer does not configure instances of Messaging Server.
Run the Directory Preparation Tool on the computer that is running Directory Server.
Run the Messaging Server configuration wizard.
1. When you configure Messaging Server you must specify the Directory Server instance where information about Messaging Server users is stored.
2. When you configure Messaging Server you supply the name of the LDAP directory branch that will represent the email domain managed by the Messaging Server instance. The Messaging Server configuration wizard adds this branch to the tree.
Start and verify all instances of Messaging Server.
If your solution includes single sign-on, configure Messaging Server for single sign-on, restart Messaging Server, and verify functioning of single sign-on.
If your solution includes Sun Cluster software, install, configure, start, and verify the Sun Cluster Agent for Messaging Server.
If your solution uses load balancing for the Administration Server instances, verify that the load balancer is working properly.

Choosing Configuration Values for Messaging Server

For each Messaging Server instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. For example, if your solution uses Access Manager single sign-on, the Messaging Server instances must be configured to interoperate with Access Manager. Use Table 3–9 to help you choose configuration values.

Table 3–9 Key Configuration Values for Messaging Server Instances


Input Field	Choosing a Value for Your Solution
Enter FQHN	The fully qualified domain name for the computer on which you are configuring Messaging Server.
Select Components to Configure	Select the components that your solution specifies for this computer. This information is available in the deployment architecture. For more information, see Analyzing a Deployment Architecture.
Enter Username and Enter Group	You specify the username and group under which the Messaging Server instance will run.
Config Server LDAP URL, Bind As, Password.	You specify the Directory Server instance that your solution uses for configuration data, and the directory manager account and password. The Messaging Server configuration wizard writes configuration data about the Messaging Server instance to this directory.
User/Group Server LDAP URL, Bind As, Password.	You specify the Directory Server instance that your solution uses for user and group data, and the directory manager account and password. The Messaging Server configuration wizard adds the mail domain branch to this Directory Server's directory tree. The Messaging Server looks up user and group data in this directory.
Password for All Admin Accounts	You establish the password used for all of the Messaging Server instance's administrator accounts.
Default Email Domain	You establish the email domain for which the Messaging Server instance provides mail services.
Enter Org DN	You establish the LDAP directory tree branch that will store data about users in the default email domain. The DN for the directory tree branch can be specified as o=, ou=, or dc=,dc= If your solution uses a single user entry to authenticate and authorize multiple services, you must configure the other components to use the LDAP branch you specify in this field for user and group data.

Adding Installation Procedures for Messaging Server to Your Installation Plan

To add installation and configuration instructions for Messaging Server, do the following:

If theMessaging Server instances are load balanced, the first instruction in your installation plan is confirming that the load balancer is functioning before anyJava ES software is installed.
If your solution uses Sun Cluster software, Messaging Server has a local dependency on Sun Cluster software. Do the following:
1. Each computer that runs an instance of Messaging Server must a Sun Cluster node. The Sun Cluster software must be installed, configured, and verified before Messaging Server is installed.
2. In your plan, list all of the computers that run clustered Messaging Server instances.
3. For each computer, add the instructions for installing Sun Cluster software. For the Sun Cluster software installation instructions, see Sun Cluster Software. For an example installation plan that shows how to run the installer multiple times on a computer to set up clustered components, see Table 3–4.
Next, in your plan, list all of the computers with Messaging Server instances.

Tip –
If your solution uses clustered Messaging Server instances, this is the second time the installer runs on the computers designated for Messaging Server.
1. In your plan, for each computer, add an instruction to run the Java ES installer and select Messaging Server.
2. If the computers that run Access Managerare already listed in your plan (for example, if Directory Server is installed on the same computer) add an instruction to select Access Manager. You can install Access Manager at the same time as Directory Server, even if you use the configure now option, but your plan must put the instructions for configuring, starting, and verifying the Directory Server instances before the instructions for configuring or starting any instance Access Manager.
Underneath each Messaging Server instance, list the key values for configuring the instance. Use to help you select configuration values.
Directory Preparation Tool-need table of configuration values.
For each computer, add an instruction to start and verify the Messaging Server instance.
If the Messaging Serverinstances are load balanced, add an instruction to verify operation of the load balancer.
If the Messaging Server instances are clustered, add an instruction to complete the cluster configuration by installing the Sun ClusterAgents for Messaging Server and verifying their operation. You can find the instructions for the Sun Cluster Agent in Sun Cluster Software.

Calendar Server

Examine your deployment architecture for computer systems with instances of Calendar Server.

Calendar Server provides calendar services. Calendar Server's services can be accessed through Communications Express, or Portal Server.

Calendar Server has a solution-level dependency on a source of user and group data. The user and group data contains account names and passwords that are used to verify access to calendar services. The user and group data also identifies each user's calendar server and other information needed to provide calendar services. This information is typically in an LDAP directory managed by Directory Server. Therefore, it is logical to install and configureCalendar Server after Directory Server.

If your solution uses single sign-on, Calendar Server is a consumer of Access Manager services. In single sign-on solutions, Calendar Server must be installed and configured after both Directory Server and Access Manager are installed and configured.

If your solution uses both Calendar Server and Messaging Server, Calendar Server's user and group data should be stored in the same branch of the LDAP directory that Messaging Server uses for user and group data. This data is create by the Messaging Server configuration wizard. Therefore, Calendar Server has a dependency on Messaging Server. Calendar Server should be installed and configured after Messaging Server is installed and configured.

Basic Installation Procedures for Calendar Server

Determine which redundancy strategy, if any, your solution is using for messaging services.
- If your solution uses load-balancing.
- If your solution uses clustered calendar services, the Sun Cluster software must be installed, configured, and verified before Calendar Server.
Use the Java ES installer to install Calendar Server on all computers systems specified in your deployment architecture. The installer does not configure instances of Messaging Server.
If necessary, run the Directory Preparation Tool on the computer that is running Directory Server. If your solution includesMessaging Server, the Directory Preparation Tool is run as part of Messaging Server configuration.
Run the Calendar Server configuration wizard.
1. When you configure Calendar Server you must specify the Directory Server instance where information about Calendar Server users is stored.
2. When you configure Calendar Server you supply the name of the LDAP directory branch where user and group data is stored. This is normally the branch created by the Messaging Server configuration wizard.
Start and verify all instances of Calendar Server.
If your solution includes Sun Cluster software, install, configure, start, and verify the Sun Cluster Agent for Messaging Server.
If your solution includes single sign-on, configure Calendar Server for single sign-on, restart Calendar Server, and verify functioning of single sign-on.
If your solution uses load balancing for the Calendar Server instances, verify that the load balancer is working properly.

Choosing Configuration Values for Calendar Server

For each Calendar Server instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. For example, if your solution uses Access Manager single sign-on, the Calendar Server instances must be configured to interoperate with Access Manager. Use Table 3–10 to help you choose configuration values.

Table 3–10 Key Configuration Values for Calendar Server Instances


Input Field	Choosing a Value for Your Solution
LDAP Server Host Name, LDAP Server Port	Use these fields to specify the Directory Server instance your solution uses for user and group data.
Directory Manager Name, Directory Manager Password	Use these field to supply the directory manager and account and password for the user and group directory. The Calendar Server uses this information to connect to the Directory Server instance at configuration time.
Base DN	Specify the LDAP directory tree branch where the Calendar Server instance looks up user data. If your solution uses single user entry and single sign-on, this must be the directory tree branch created by Messaging Server configuration. For more information, see Table 3–9.
Administrator User ID and Administrator Password	Use these field to define the main administrator account for the Calendar Server instance. This account will be added to the directory in the location specified by the Base DN field.
Administrator Email Address	Create an email address for the primary administrator account.
SMTP Host	Specify the mail host used to send mail alarms. Specify the computer that is running the Messaging Server instance for your solution. If you solution uses a load-balanced or clustered messaging service, specify the logical address for the service.
Service Port	Assign the port on which the Calendar Server instance listens for connections. The port number should be specified in the network connectivity specification. For more information, see Developing a Network Connectivity Specification.
Maximum Sessions, Maximum Threads, Number of Server Processes	Use these fields to specify the runtime characteristics of the Calendar Server instance.
Runtime User ID, Runtime Group ID	Use these fields to specify the user ID and group under which the Calendar Server runs.

Adding Procedures for Calendar Server to Your Installation Plan

To add installation and configuration instructions for Calendar Server, do the following:

If theCalendar Server instances are load balanced, the first instruction in your installation plan is confirming that the load balancer is functioning before anyJava ES software is installed.
If your solution uses Sun Cluster software, Calendar Server has a local dependency on Sun Cluster software. Do the following:
1. Each computer that runs an instance of Calendar Server must be configured as a Sun Cluster node. The Sun Cluster software must be installed, configured, and verified before Calendar Server is installed.
2. In your plan, list all of the computers that run clustered Calendar Server instances.
3. For each computer, add the instructions for installing Sun Cluster software. For the Sun Cluster software installation instructions, see Sun Cluster Software. For an example installation plan that shows how to run the installer multiple times on a computer to set up clustered components, see Table 3–4.
Next, in your plan, list all of the computers with Calendar Server instances.

Tip –
If your solution uses clustered Calendar Server instances, this is the second time the installer runs on the computers designated for Calendar Server.
1. In your plan, for each computer, add an instruction to run the Java ES installer and select Calendar Server.
2. If the computers that run Calendar Serverare already listed in your plan (for example, if Directory Server is installed on the same computer) add an instruction to select Calendar Server. You can install Calendar Server at the same time as Directory Server, even if you use the configure now option, but your plan must put the instructions for configuring, starting, and verifying the Directory Server instances before the instructions for configuring or starting any instance Calendar Server.
Underneath each Calendar Server instance, list the key values for configuring the instance. Use to help you select configuration values.
Directory Preparation Tool-need table of configuration values.
For each computer, add an instruction to start and verify the Calendar Server instance.
If the Calendar Serverinstances are load balanced, add an instruction to verify operation of the load balancer.
If the Calendar Server instances are clustered, add an instruction to complete the cluster configuration by installing the Sun ClusterAgents for Calendar Server and verifying their operation. You can find the instructions for the Sun Cluster Agent in Sun Cluster Software.

Communications Express

Examine your deployment architecture for computer systems with instances of Communications Express.

Communications Express provides an end user interface to mail and calendar services. Communications Express also provide a mechanism for Portal Server to access mail and calendar services.

Communications Express has a solution-level dependency on Messaging Server andCalendar Server. Communications Express provides an interface for data that is supplied by specific instances of Messaging Server and/or Calendar Server. Therefore, it is logical to install and configure Communications Express afterMessaging Server and Calendar Server.

Communications Express also has a solution-level dependency on a source of user and group data. The user and group data contains account names and passwords that are used to verify access to messaging and calendar services. This information is typically in an LDAP directory managed by Directory Server. Communications Express accesses this data via Access Manager. Communications Express also depends on the LDAP schema and directory tree modifications that result from installing Access Manager, running Directory Preparation Tool, and installing and configuring Messaging Server. Therefore, it is logical to install and configureCommunications Express after Directory Server and Access Manager.

Communications Express is configured by default to use Access Manager single sign-on.

Communications Express has local dependencies on a web container and on either Access Manager or the Access Manager SDK. Typically, in a distributed solution, the deployment architecture will specify a local copy of the Access Manager SDK, which supports interaction with remote instances of Access Manager.

Basic Installation Procedures for Communications Express

The basic steps for installing and configuring Communications Express are the following:

Use the Java ES installer to install Communications Express on all computers systems specified in your deployment architecture.
1. When you install Communications Express you also install the web container in which Communications Express runs.
2. When you install Communications Express you must also install either a copy of the Access Manager SDK, or a local copy of Access Manager.
Run the Communications Express configuration wizard. When you configure Communications Express you must specify the repository for user and group data (typically a Directory Server instance, specified with a URL).
Start and verify all instances of Communications Express.
If your solution uses load balancing for the Communications Express instances, verify that the load balancer is working properly.

Choosing Configuration Values for Communications Express

For each Communications Express instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. In particular, Communications Express is configured to interoperate with the Messaging Server and Calendar Server instances that provide messaging and calendar data, and the Access Manager and Directory Server instances that provide authentication and authorization services. Use Table 3–11 to help you choose configuration values.

Table 3–11 Key Configuration Values for Communications Express


Input Field	Choosing a Value for Your Solution
Mail Component and Calendar Component	Select the Communications Express components for the services your solution is providing.
Hostname and DNS Domain Name	These fields, together, identify the computer on which you are configuring Communications Express.
Web Server or Application Server	Select the web container your solution is using. You can find this information in the deployment architecture. For more information, see Analyzing a Deployment Architecture.
Server Root Directory, Server Instance Identifier, Virtual Server Identifier, HTTP Port	If you are installing Communications Express and Web Server together, use these fields to specify how Web Server is installed. If you are installingCommunications Express on a computer where Web Server is already installed, use these fields to specify an existing Web Server instance.
	If you are installing Communications Express and Application Server together, use these fields to specify how Web Server is installed. If you are installingCommunications Express on a computer where Application Server is already installed, use these fields to specify an existing Web Server instance.
Web Container User ID and Web Container Group ID	Specify the user and group that will run the web container process.
URI Path	Specify the URI for accessing Communications Express
LDAP URL, Bind DN, Administrator Password	Specify the Directory Server instance that your solution uses for user and group data. Bind DN and Administrator Password are the directory manager account and password. If your solution uses load-balanced Directory Server instances, type the logical URL for the load-balanced directory service.
DC Suffix Tree	Specify the base DN of the user and groupDirectory Server instance. This was established when the Directory Server instance was installed. For more information, see Table 3–5.
Enter the Domain Name	Type the name of the mail domain your solution is using. This mail domain was established when Messaging Server was configured. For more information, see Table 3–9.
Login URL, Administrator DN, and Administrator Password	Specify the values used to connect to Access Manager. Login URL has the form http://hostname:port/amserver/UI/login, where hostname specifies the computer on which Access Manager is running. Administrator DN must be the full LDAP name for the Access Manager administrator account. It should resemble the following: uid=amadmin,ou=people,o=DirectoryBaseDN. The administrator password must be the password established when Access Manager is installed. For more information, see Table 3–8.
Messenger Express Port	Specify the port that Messaging Server is using. The port was specified when Messaging Server was configured. For more information, see Table 3–9.
Calendar Server Hostname and Calendar Server Port Number	Specify the name of the computer that is running Calendar Server. If the calendar service in your solution is clustered or load-balanced, supply the logical name for the service. The Calendar Server Port Number was assigned when Calendar Server was configured. For more information, see Table 3–10.
Administrator User ID and Administrator Password	Use the Calendar Server administrator ID and password. These values were established when Calendar Server was configured. For more information, see Table 3–10.
Login URL, Administrator DN, Administrator Password	Specify the Directory Server instance that your solution uses for personal address book data. If you solution uses load-balanced Directory Server instances, type the logical URL for the load-balanced directory service. These values were established when theDirectory Server instance was configured. For more information, see Table 3–5.

Adding Procedures for Communications Express to Your Installation Plan

To add installation and configuration instructions for Communications Express, do the following:

If theCommunications Express instances are load balanced, add an instruction to your installation plan to confirm that the load balancer is functioning before anyJava ES software is installed.
Next, in your plan, list all of the computers with Communications Express instances.
1. Communications Express has a local dependency on a web container. Each computer that runs an instance of Communications Express must also run an instance of the specified web container. Your deployment architecture should indicate which web container your solution is using.
2. For each computer, add an instruction to run the Java ES installer and select Communications Express. Add an instruction to select either Web Server or Application Server as the web container. Add an instruction to select either Access Manager SDK or Access Manager.
3. If the computers that run Communications Expressare already listed in your plan (if the plan already has instructions for installing another component on the same computer) simply add an instruction to select Communications Express when the installer runs. You can install Communications Express at the same time as the other components, and deploy it to the same web container, but your plan must put the instructions for configuring, starting, and verifying any Directory Server, Access Manager, Messaging Server, or Calendar Serverinstances ahead of the instructions for configuring or starting the Communications Express instances.
Add an instruction to run the Communications Express configuration wizard. Underneath this instruction, list the key values for configuring the instance. Use Table 3–11 to help you select configuration values.
Underneath each Web Server or Application Server instances, list the key values for configuring the instance. For information on selecting configuration values for these components, see Web Server or Application Server. If your plan already installs Web Server or Application Server on the computer, you do not need to repeat this step. You can deploy Communications Express to the same web container instance when you run the Communications Express configuration wizard.
For each computer, add an instruction to start and verify the Communications Express instance.
If the instances are load balanced, add an instruction to verify operation of the load balancer.

Portal Server

Examine your deployment architecture for computer systems with instances of Portal Server.

Portal Server provides portal services that are accessed through the portal desktop.

If portal service is provided as part of a solution that uses Java ES messaging and calendar services, than Portal Server uses the same LDAP branch for user and group data that Messaging Server and Calendar Server, and Portal Server shares all of the dependencies for Messaging ServerCalendar Server. These dependencies are met when Messaging Server and Calendar Server are installed and configured. In solutions that combine portal services with messaging and calendar services, it is logical to install Portal Server after Messaging Server and Calendar Server.
If portal service is used without messaging and calendar services, Portal Server has a solution-level dependency on a source of user data. This dependency is met with Directory Server, or Directory Server and Access Manager.

Portal Server has a local dependency on a web container. Web Server, Application Server, and several third-party web containers can be used. Portal Server also has a local dependency on Access Manager or the Access Manager SDK. Typically, in a distributed solution, the deployment architecture will specify a local copy of the Access Manager SDK, which supports interaction with remote instances of Access Manager.

Note –

Basic Installation Procedures for Portal Server

The basic steps for installing and configuring Communications Express are the following:

Use the Java ES installer to install Portal Server on all computers systems specified in your deployment architecture.
1. When you install Portal Server you must specify the web container in which Portal Server runs.
2. When you install Portal Server you must specify the repository for user and group data (typically a Directory Server instance, specified with a URL).
3. When you install Portal Server you must also install either a copy of the Access Manager SDK, or a local copy of Access Manager.
Start and verify all instances of Portal Server.
If your solution uses single sign-on, configure Portal Server for single sign-on.
If your solution displays messaging and calendar data on the portal desktop, configure the portal channels to interoperate with specific Messaging Server and Calendar Server instances.
If your solution uses load balancing for the Portal Server instances, verify that the load balancer is working properly.

Choosing Configuration Values for Portal Server

For each Portal Server instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. In particular, Portal Server is configured to interoperate with Directory Server for user data lookup. In most solutions, Portal Server is configured to interoperate with Access Manager for single-sign on authentication and authorization services, and with Messaging Server and Calendar Server as sources of messaging and calendar data that is displayed on the portal desktop. Use Table 3–12 to help you choose configuration values.

Table 3–12 Key Configuration Values for Portal Server Instances


Input Field	Choosing a Value for Your Solution
Web Container	Select the web container that your solution uses for Portal Server. Tip – If your solution uses one of the third-party web containers, it must be installed, configured, and running before the Java ES installer runs.
Installation Directory, Server Instance, Server Instance Port, and Server Secure Instance Port	If you are installing Portal Server and Web Server together, use these fields to specify how Web Server is installed. If you are installingPortal Server on a computer where Web Server is already installed, use these fields to specify an existing Web Server instance.
Installation Directory, Domain Name, Server Instance Directory, Server Instance Port, Document Root Directory, Administration Port, Administrator User ID, Administrator Password, Secure Server Instance Port, Secure Administration Server Port	If you are installing Portal Server and Application Server together, use these fields to specify how Application Server is installed. If you are installingPortal Server on a computer where Application Server is already installed, use these fields to specify an existing Application Server instance.
Home Directory, Product Installation Directory, User's Project Directory, Product JDK Directory, Server/Cluster Domain, Server/Cluster Instance, Server/Cluster Port, Server/Cluster Protocol, Document Root Directory, Administrator User ID, Administrator Password, Managed Server	Use these fields to specify a BEA WebLogic instance that is installed and running on the computer.
Installation Directory, Virtual Host, Cell, Node, Server Instance, Server Instance Port, Document Root Directory, Java Home Directory, Secure Server Instance,	Use these fields to specify an IBM WebSphere instance that is installed and running on the computer.
Load Balancer Controlling Multiple Portal Servers, Load Balancer Protocol, Load Balancer Host, Load Balancer Port	If your solution uses load-balanced portal services, use these fields to configure the Portal Server instance for interoperation with the load balancer.
Deployment URI	Specify the URI path used to access portal services.
Install Sample Portal	Specify whether you want the installer to install the sample portal desktop. The sample desktop is useful in verifying Portal Server.

Adding Procedures for Portal Server to Your Installation Plan

To add installation and configuration instructions for Portal Server, do the following:

If thePortal Server instances are load balanced, the add an instruction to your installation plan to verify that the load balancer is functioning before anyJava ES software is installed.
Next, in your plan, list all of the computers with Portal Server instances.
1. Portal Server has a local dependency on a web container. Each computer that runs an instance of Portal Server must also run an instance of the specified web container. Your deployment architecture indicates which web container your solution is using.
2. For each computer, add an instruction to run the Java ES installer and select Portal Server. If you are using Web Server or Application Server as your web container, add an instruction to select the web container, too. The installer is capable of automatically deploying Portal Server to the selected web container. Add an instruction to select either Access Manager SDK or Access Manager.
3. If the computers that run Portal Serverare already listed in your plan (if the plan already has instructions for installing another component on the same computer) simply add an instruction to select Portal Server. You can install Portal Server at the same time as the other components, and deploy it to the same web container, but your plan must put the instructions for configuring, starting, and verifying any Directory Server, Access Manager, Messaging Server, or Calendar Server instances ahead of the instructions for configuring or starting the Portal Server instances.
Underneath each Portal Server instance, list the key values for configuring the instance. Use Table 3–12 to help you select configuration values.
Underneath each Web Server or Application Server instances, list the key values for configuring the instance. For information on selecting configuration values for these components, see Web Server or Application Server. If your plan already installs Web Server or Application Server on the computer, you do not need to repeat this step. You can specify the same web container instance and deploy Portal Server to the same web container instance.
If your solution uses one of the third-party web containers that supports Portal Server, your Portal Server instances are deployed with the web container's deployment tool. Add instructions to your plan to deploy each Portal Server instance.
For each computer, add an instruction to start and verify the Portal Server instance. If the instances are load balanced, add an instruction to verify operation of the load balancer.

Portal Server Secure Remote Access

Portal Server Secure Remote Access provides controlled access to internal resources through the portal mechanism.

Portal Server Secure Remote Access has solution-level dependencies on Portal Server and on Access Manager authentication and authorization.

Both dependencies are also local dependencies. Portal Server Secure Remote Access must be installed on the same computer as the Portal Server instance that serves the resources to be accessed through secure remote access. Portal Server Secure Remote Access must also have local access to Access Manager services. In a distributed solution, this is typically accomplished by installing a local copy of Access Manager SDK, which lets Portal Server Secure Remote Access interact with a remote instance of Access Manager.

Basic Installation Procedures for Portal Server Secure Remote Access

The basic procedures for installing and configuring Portal Server Secure Remote Access are as follows:

Install and configure Portal Server Secure Remote Access on the computers specified in your deployment architecture. The Portal Server instance that provides the resources controlled by Portal Server Secure Remote Access is installed on the same computer.
Start and verify all of the Portal Server Secure Remote Access instances.

Choosing Configuration Values for Portal Server Secure Remote Access

For each Messaging Server instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. For information on choosing configuration values, see Portal Server Secure Remote Access Configuration Information in Sun Java Enterprise System 2005Q4 Installation Reference.

Adding Procedures for Portal Server Secure Remote Access to Your Installation Plan

To add installation and configuration instructions for Portal Server Secure Remote Access, do the following:

In your plan, list all of the computers with Portal Server Secure Remote Access instances. For each computer, add Portal Server Secure Remote Access to list of components installed.
Beneath the Portal Server Secure Remote Access heading, add an instruction to run the Java ES installer, that includes the following:
1. Selecting Portal Server Secure Remote Access.
2. A list of the key values for configuring the instance.
Add an instruction to start and verify the Portal Server Secure Remote Access instances.
If the Portal Server Secure Remote Access instances are used to load balance Portal Server instances, add an instruction to verify the load balancing feature.

Instant Messaging

Examine your deployment architecture for computer systems with instances of Instant Messaging.

Instant Messaging provides instant messaging services to end users.

If instant messaging services are provided as part of a solution that uses Java ES messaging and calendar services, Instant Messaging looks up user data in the same LDAP organization as Messaging Server and Calendar Server. In this type of solution, Instant Messaging shares all of the dependencies for Messaging Server and Calendar Server. These dependencies are met when Messaging Server and Calendar Server are installed and configured. In this type of solution, it is logical to install Instant Messaging after Messaging Server and Calendar Server.
If instant messaging services are provided without messaging and calendar services, Instant Messaging has a solution-level dependency on a source of user data. This dependency is met with Directory Server, or Directory Server and Access Manager.

TheInstant Messaging client resources subcomponent has a local dependency on a web container. Web Server or Application Server can be used. If your solution distributes the Instant Messaging sub components, the web container must be installed on the same computer as the client resources.

If your solution uses Access Manager single sign-on, Instant Messaging also has a dependency on Access Manager. This dependency can be satisfied with a local Access Manageror Access Manager SDK. Typically, in a distributed solution, the deployment architecture will specify a local copy of the Access Manager SDK, which supports interaction with a remote instances of Access Manager.

Basic Installation Procedures for Instant Messaging

The basic steps for installing and configuring Instant Messaging are the following:

Use the Java ES installer to install Instant Messaging on all computers systems specified in your deployment architecture.
1. When you install Instant Messaging you satisfy the web container dependency by installing the web container in which Instant Messaging runs or by specifying a wed container already installed on the computer.
2. If the solution uses Access Manager single sign-on, you satisfy the Access Manager dependency by installing either a copy of the Access Manager SDK or a local copy of Access Manager.
Run the Instant Messaging configuration wizard. When you configure Instant Messaging you must specify the repository for user and group data (typically a Directory Server instance, specified with a URL).
Start and verify all instances of Instant Messaging.
If your solution uses load balancing for the Instant Messaging instances, verify that the load balancer is working properly.

Choosing Configuration Values for Instant Messaging

For each Instant Messaging instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. Use Table 3–13 to help you choose configuration values. For detailed information on the input values, see Chapter 1, “Configuring Instant Messaging after Installation,” in Sun Java System Instant Messaging 7 2005Q1 Administration Guide.

Table 3–13 Key Configuration Values for Instant Messaging


Input Field	Choosing a Value for Your Solution
Sun Java System Instant Messaging Server, Sun Java System Instant Messaging Resources, Sun Java System Access Manager Instant Messaging Service	Select the subcomponents specified in the deployment architecture. For more information, see Analyzing a Deployment Architecture and Distributed Subcomponents.
Runtime User ID, Runtime Group, HTTP Port, Document Root Directory	Use these fields to specify the Web Server instance in which Instant Messaging client resource runs.
Are you planning to leverage an Access Managerdeployment for SSO? and Are you planning to leverage an Access Manager deployment for Policy?	Use these fields to specify how Instant Messaging interacts with Access Manager.
Domain Name, IM Server Port, Multiplexor Port, Disable Server, Remote IM Host Name	Domain name is the mail domain that your solution is using. It was established when Messaging Server was configured. For more information, see Table 3–9.
LDAP Host Name, LDAP Port Number, Base DN, Bind DN, Bind Password	Specify the Directory Server instance used for user and group data. Bind DN and Bind Password are the directory manager account and password. Base DN is the LDAP organization for Instant Messaging user data. If the solution also includes Messaging Server, Base DN is the email domain LDAP organization created by Messaging Server configuration. For more information see Table 3–9. If your solution uses load-balanced Directory Server instances, type the logical URL for the load-balanced directory service.
SMTP Server	Specify the computer running Messaging Server. If your solution uses load-balanced or clustered Messaging Server instances, use the logical URL for the load-balanced messaging service.
Instant Messenger Resources Codebase	Specify the location from which users will download Instant Messenger client resources.
Assign IM Service to Existing Users

Adding Procedures for Instant Messaging to Your Installation Plan

To add installation and configuration instructions for Instant Messaging, do the following:

If the Instant Messaging instances are load balanced, add an instruction to your installation plan to confirm that the load balancer is functioning before any Java ES software is installed.
Next, in your plan, list all of the computers with Instant Messaging instances.
1. The Instant Messaging client resources subcomponent has a local dependency on a web container. Each computer that runs this subcomponent must also run an instance of the specified web container. Your deployment architecture should indicate which web container your solution is using.
2. For each computer, add an instruction to run the Java ES installer and select Instant Messaging. Add an instruction to select either Web Server or Application Server as the web container. Add an instruction to select either Access Manager SDK or Access Manager.
3. If the computers that run Instant Messaging are already listed in your plan (if the plan already has instructions for installing another component on the same computer) simply add an instruction to select Instant Messaging. You can install Instant Messaging at the same time as the other components, and deploy it to the same web container, but your plan must put the instructions for configuring, starting, and verifying any Directory Server, Access Manager, Messaging Server, or Calendar Server instances ahead of the instructions for configuring or starting the Instant Messaging instances.
Add an instruction to run the Instant Messaging configuration utility. Underneath this instruction, list the key values for configuring the instance. Use Table 3–13 to help you select configuration values.
Underneath each Web Server or Application Server instances, list the key values for configuring the instance. For information on selecting configuration values for these components, see Web Server or Application Server. If your plan already installs Web Server or Application Server on the computer, you do not need to repeat this step. You can deploy Communications Express to the same web container instance when you run the Instant Messaging configuration utility.
For each computer, add an instruction to start and verify the Instant Messaging instance.
If the Instant Messaging instances are load balanced, add an instruction to verify operation of the load balancer.

Delegated Administrator

Delegated Administrator provides user management services by operating on user data in the LDAP directory.

Delegated Administrator operates on an LDAP directory tree branch that represents an email domain. Delegated Administrator is designed for solutions when all component instances share the same LDAP tree branch for user and group data. The LDAP branch is created by the Messaging Server configuration wizard. In this type of solution, Messaging Server itself has solution-level dependencies on Directory Preparation Tool, Access Manager, and Directory Server. Therefore, it is logical to install and configure Delegated Administrator after Directory Server, Administration Server, Messaging Server, and Calendar Server are all installed, configured, and verified.

Delegated Administrator has local dependencies on a web container and on either Access Manager or the Access Manager SDK. Typically, in a distributed solution, the deployment architecture will specify a local copy of the Access Manager SDK, which supports interaction with remote instances of Access Manager.

Basic Installation Procedures for Delegated Administrator

The basic steps for installing and configuring Delegated Administrator are the following:

Use the Java ES installer to install Delegated Administrator on all computers systems specified in your deployment architecture.
1. When you install Delegated Administrator you also install the web container in which Delegated Administrator runs.
2. When you install Delegated Administrator you must also install either a copy of the Access Manager SDK, or a local copy of Access Manager.
Run the Delegated Administrator configuration wizard. When you configure Instant Messaging you must specify the repository for user and group data (typically a Directory Server instance, specified with a URL).
Start and verify all instances of Delegated Administrator.
If your solution uses load balancing for the Delegated Administrator instances, verify that the load balancer is working properly.

Choosing Configuration Values for Delegated Administrator

For each Delegated Administrator instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. For example, Delegated Administrator manages LDAP directory entries. Therefore, Delegated Administrator must be configured to log in Directory Server instance that stores user and group data. Use Table 3–14 to help you choose configuration values.

Table 3–14 Key Configuration Values for Delegated Administrator Instances


Input Field	Choosing a Value for Your Solution
Delegated Administrator Utility, Delegated Administrator Console, Delegated Administrator Server	Select the subcomponents specified in the deployment architecture. For more information, see Analyzing a Deployment Architecture and Distributed Subcomponents.
Hostname and Port	Use these fields to specify the Access Manager instance used in your solution. Hostname is the fully qualified domain name of the computer running Access Manager. Port is the port on which Access Manager listens for connections. The port was assigned when Access Manager was configured. For more information, see Table 3–8.
Default Domain	Specify the default email domain defined byMessaging Server configuration. This is specified as the default email domain for user data managed by Delegated Administrator. For more information, see Table 3–9.
Default SSL Port	Assign the port on which Delegated Administrator listens for connection requests.
Web Container: Web Server, App Server 7.x, App Server 8.x	Select the web container used in your solution.
Server Root Directory, Server Instance Identifier, Virtual Server Identifier, HTTP Port	If you are installing Delegated Administrator and Web Server together, use these fields to specify how Web Server is installed. If you are installingDelegated Administrator on a computer where Web Server is already installed, use these fields to specify an existing Web Server instance.
	If you are installing Delegated Administrator and Application Server together, use these fields to specify how Application Server is installed. If you are installingDelegated Administrator on a computer where Application Server is already installed, use these fields to specify an existing Application Server instance.
Domain Separator
Access Manager Base Directory	Specify the directory where the Access Manager instance used in your solution is installed. This can be a directory on the remote computer you specified earlier in the configuration process. What if Access Manager is load balanced?
LDAP URL, Bind As, Password	Use these fields to specify the Directory Server instance used in your solution. LDAP URL is in the form http://directory_hostname:directory_port, where directory_hostname specifies the computer running Directory Server, and directory_port is the port assigned for connection requests when the Directory Server instance was configured. Bind As, and Password are the directory manager account and password. For more information, see Table 3–5.
Access Manager Top Level Administrator: Username and Password	Use the top-level administrator account for the Access Manager instance used in your solution. Username is always amadmin, Password was assigned when Access Manager was configured. For more information, see Table 3–8.
Access Manager Internal LDAP Authentication Password: Username and Password	Use the LDAP user account for the Access Manager instance used in your solution. Username is always amldapuser. Password was assigned when Access Manager was configured. For more information, see Table 3–8.
Enter Org DN	Specify the LDAP organization (directory tree branch) your solution is using for user and group data. This is the organization created by Messaging Server configuration. For more information, see Table 3–9. The components in your solution look up user data in this LDAP organization for authentication and authorization. Delegated Administrator is used to manage user and group data in the same LDAP organization.
Top Level Administrator for the Default Organization: Username and Password	Specify a privileged administrator account for Delegated Administrator. Administrators who log in to Delegated Administrator with this account have unrestricted privileges, included the ability to create lower-level administrator accounts.
Load Sample Service Packages and Load Sample Organizations	If you select these options, the configuration wizard adds sample service packages and organizations to the directory. You can use the samples to develop your own.

Adding Procedures for Delegated Administrator to Your Installation Plan

To add installation and configuration instructions for Delegated Administrator, do the following:

If theDelegated Administrator instances are load balanced, add an instruction to your installation plan to confirm that the load balancer is functioning before anyJava ES software is installed.
Next, in your plan, list all of the computers with Delegated Administrator instances.
1. Delegated Administrator has a local dependency on a web container. Each computer that runs an instance of Delegated Administrator must also run an instance of the specified web container. Your deployment architecture should indicate which web container your solution is using.
2. For each computer, add an instruction to run the Java ES installer and select Delegated Administrator. Add an instruction to select either Web Server or Application Server as the web container. Add an instruction to select either Access Manager SDK or Access Manager.
3. If the computers that run Delegated Administrator are already listed in your plan (if the plan already has instructions for installing another component on the same computer) simply add an instruction to select Delegated Administrator. You can install Delegated Administrator at the same time as the other components, and deploy it to the same web container, but your plan must put the instructions for configuring, starting, and verifying any Directory Server, Access Manager, Messaging Server, or Calendar Serverinstances ahead of the instructions for configuring or starting the Instant Messaging instances.
Add an instruction to run the Delegated Administrator configuration wizard. Underneath this instruction, list the key values for configuring the instance. UseTable 3–14 to help you select configuration values.
Underneath each Web Server or Application Server instance, list the key values for configuring the instance. For information on selecting configuration values for these components, see Web Server or Application Server. If your plan already installs Web Server or Application Server on the computer, you do not need to repeat this step. You can deploy Delegated Administrator to the same web container instance when you run the Delegated Administrator configuration wizard.
For each computer, add an instruction to start and verify the Delegated Administrator instance.
If the Delegated Administrator instances are load balanced, add an instruction to verify operation of the load balancer.

Service Registry

Service Registry manages a UDDI registry of web services.

Service Registry has a local dependency on Application Server.

Service Registry cannot be configured by the installer, even when the installer runs in configure now mode.

Basic Installation Procedures for Service Registry

The basic procedures for installing and configuring Service Registry are as follows:

Use the Java ES installer to install Service Registry on all computers systems specified in your deployment architecture. Service Registry has a local dependency on Application Server. Each computer that runs an instance of Service Registry must also run an instance of Application Server.
Run the Service Registry configuration script.

Adding Installation Procedures for Service Registry to Your Plan

To add installation and configuration instructions for Service Registry, do the following:

In your plan, list all of the computers with Service Registry instances.
Add an instruction to select Application Server.

Tip –
Configuring Application Server might be more efficient in configure now mode. Configure now mode does not configure Service Registry.
Add an instruction to run the Service Registry build and configuration script. To change the default configuration values, edit the install.properties file before running the configuration script. For more information on the installation properties, see Chapter 1, Configuring and Setting Up Service Registry, in Service Registry 3 2005Q4 Administration Guide.

Web Server

Web Server is primarily used to provide web container services for other Java ES components. If your solution uses Web Server for web container support, an instance of Web Server must be installed on each computer that runs an instance of a supported components.

For example, if your solution uses Web Server to provide web container support for Communications Express, then every computer with an instance of Communications Express also has an instance of Web Server. Every instance of Communications Express is deployed to the instance of Web Server on the same computer.

The Java ES installer can both install and deploy some components, such as Access Manager. For other components, such as Communications Express, installation is followed by a separate configuration step. For these components, a configuration wizard creates an instance and deploys it. The sections on the individual components explain what is required for each component.

Instances of different components can be deployed to one instance of Web Server. For example, if your solution runs Access Manager and Portal Server on one computer, both components can be deployed to the same Web Server instance.

Web Server has no system-level dependencies.

Web Server has several local dependencies. An instance of Web Server always requires a local instance of Message Queue. If your solution uses Web Server to load-balance multiple instances of Web Server, a Web Server instance must be installed locally. And, if your solution uses the High Availability Session Store feature, an instance of this component must be installed locally.

Basic Installation Procedures for Web Server

The basic procedures for installing and configuring Web Server are as follows:

Use the Java ES installer to install and configure Web Server on the computer systems specified in your deployment architecture. When you install Web Server, you specify configuration values. In some cases (Access Manager and Portal Server), you also specify configuration values for the supported component, and the supported component is deployed to the Web Server instance. In other cases, you separately run the supported component's configuration wizard to create and deploy an instance.
Start and verify all of the Web Server instances.
Verify that the supported components are running.
If your solution uses load balancing, verify that the load balancing is routing requests among the component instances.

Choosing Configuration Values for Web Server

For each Web Server instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. Use Table 3–15 to help you choose configuration values.

Table 3–15 Key Configuration Values for Web Server


Input Field	Choosing a Value for Your Solution
Administrator User ID and Administrator Password	Use these fields to establish an administrator account for the Web Server instance.
Web Server Host	The fully qualified domain name of the computer on which Web Server is installed. This value is used as the name of the Web Server instance created by installation.
Administration Port and Administration Runtime User ID	The port on which Web Server's administration server listens for connections. Web Server's administration server process runs under the Runtime User ID.
Runtime User ID and Runtime Group	The User ID and group under which the Web Server instance runs. When Web Server is installed as a container for Access Manager or Portal Server, set these values to root and other. When Web Server is installed as a container for other components, use a non-root user.
HTTP Port	The port on which Web Server listens for connections.
Document Root Directory	The directory where deployed documents are stored. You cannot switch from the default directory to another directory unless the alternate directory already exists. The installer will not create the alternate directory for you.
Automatically Start Web Server When System Restarts	Selecting this item configures Web Server to restart automatically when the computer restarts. Note, however, that this value is ignored when Web Server runs as a container for Access Manager. The Access Manager startup script takes precedence and automatically restarts Web Server when the computer restarts.

Adding Installation Procedures for Web Server to Your Plan

Add these instructions anywhere there is a local dependency on Web Server. In a distributed solution, your installation plan may repeat the installation and configuration instructions for Web Server on several computers, to support different web application components. For example,

To add installation and configuration instructions for Web Server, do the following:

The section on the supported component tells you to add to your installation plan an instruction to run the installer and select both the supported component and Web Server.
Next, list the configuration values for Web Server. Use Table 3–15to help you choose configuration values for Web Server.
If the supported component is configured and deployed by the installer (Access Manager, and Portal Server), do the following:
1. Add to your plan the configuration values for the supported component.
2. Add an instruction to run the installer and supply configuration values for Web Server and the supported component.
3. Add an instruction to start the Web Server instance. This step also starts the supported component.
4. As described in the section on the supported component, verify that the supported component is running correctly.
If the supported component is not configured and deployed by the installer (Communications ExpressDelegated AdministratorInstant Messaging), do the following:
1. Add an instruction to run the installer, select Web Server, and supply configuration values for Web Server.
2. Add an instruction to list the configuration values for the supported component.
3. Add an instruction to run the supported component's configuration wizard and supply the configuration values for the supported component.
4. Add an instruction to start the Web Server instance. This step also starts the supported component.
5. As described in the section on the supported component, add and instruction to verify that the supported component is running correctly.
As described in the section on the supported component, if the support component instances are load balanced, add an instruction to verify operation of the load balancer.

Application Server

Application Server is primarily used to provide web container services for other Java ES components. If your solution uses Application Server for web container support, an instance of Application Server must be installed on each computer that runs an instance of a supported components.

For example, if your solution uses Application Server to provide web container support for Communications Express, then every computer with an instance of Communications Express also has an instance of Application Server. Every instance of Communications Express is deployed to the instance of Application Server on the same computer.

Instances of different components can be deployed to one instance Application Server. For example, if your solution runs Access Manager and Portal Server on one computer, both components can be deployed to the same Application Server instance.

Application Server has no system-level dependencies.

Application Server has several local dependencies. An instance of Application Server always requires a local instance of Message Queue. If your solution uses Web Server to load-balance multiple instances of Application Server, a Web Server instance must be installed locally. And, if your solution uses the High Availability Session Store feature, an instance of this component must be installed locally.

Basic Installation Procedures for Application Server

The basic procedures for installing and configuring Application Server are as follows:

Use the Java ES installer to install and configure Application Server on the computer systems specified in your deployment architecture. When you install Application Server, you specify configuration values. In some cases (Access Manager and Portal Server), you also specify configuration values for the supported component, and the supported component is deployed to the Application Server instance. In other cases, you separately run the supported component's configuration wizard to create and deploy an instance.
Start and verify all of the Application Server instances.
Verify that the supported components are running.
If your solution uses load balancing, verify that the load balancing is routing requests among the Application Server instances.

Choosing Configuration Values for Application Server

For each Application Server instance in your solution, you must input values that configure the instance to interoperate with the other components in the solution. For information on choosing configuration values, see Application Server Configuration Information in Sun Java Enterprise System 2005Q4 Installation Reference

Adding Procedures for Application Server to Your Installation Plan

Insert instructions for installing Application Server anywhere some other Java ES component uses Application Server for web container support.

To add installation and configuration instructions for Application Server, do the following:

The section on the supported component tells you to add to your installation plan an instruction to run the installer and select both the supported component and Application Server.
Add an instruction to also select Message Queue, and if used in your solution, High Availability Session Store, and Web Server.
Next, list the configuration values for Application Server.
If the supported component is configured and deployed by the installer (Access Manager, and Portal Server), do the following:
1. Add to your plan the configuration values for the supported component.
2. Add an instruction to run the installer and supply configuration values for Application Server, Application Server's local dependencies, and the supported component.
3. Add an instruction to start the Application Server instance. This step also starts the supported component.
4. As described in the section on the supported component, verify that the supported component is running correctly.
If the supported component is not configured and deployed by the installer (Communications ExpressDelegated AdministratorInstant Messaging), do the following:
1. Add an instruction to run the installer and supply configuration values for Application Server and Application Server's local dependencies.
2. Add an instruction to list the configuration values for the supported component.
3. Add an instruction to run the supported component's configuration wizard and supply the configuration values for the supported component.
4. Add an instruction to start the Application Server instance. This step also starts the supported component.
5. As described in the section on the supported component, verify that the supported component is running correctly.
If the Application Serverinstances are load balanced, add an instruction to verify operation of the load balancer.

Message Queue

Message Queue is a local dependency of Application Server. When developing procedures for installing Application Server, add an instruction to select Message Queue.

There are no additional input values for Message Queue. Message Queue is configured by default to interoperate with Application Server.

Message Queue can also be by custom applications, but that is beyond the scope of this guide. For more information see Message Queue documentation, such as Sun Java System Message Queue 3 2005Q4 Technical Overview.

Sun Cluster Software

Sun Cluster software is installed to satisfy local dependencies. Some components in a solution might use Sun Cluster software to satisfy quality of service requirements. On these computers, the Sun Cluster software must be installed, configured, and verified before the components that run in the cluster are installed. Typically, Sun Cluster software is installed when solution-level dependences dictate the installation of the components that run in the cluster.

Sun Cluster software itself has no dependencies on other components so it can be installed and configured at any time during the installation and configuration of a distributed solution.

Basic Installation Procedures for Sun Cluster Software

The basic steps for installing and configuring Sun Cluster software are the following:

Before attempting to install Sun Cluster software, make sure that the shared external storage has been attached and configured. This is typically done as part of implementing the network connectivity specifications. For more information, see Developing a Network Connectivity Specification.
Use the Java ES installer to install Sun Cluster core software on all computers systems specified in your deployment architecture. Do not install the components that run in the cluster at this time.
Configure the computers, including running the Sun Cluster configuration utility.
Run the Java ES installer a second time and install the components that run in the cluster. These are typically Messaging Server and/orCalendar Server. Install these components only on the first computer in the cluster.
Run the Directory Preparation Tool, and configure the component instances, including configuring them for single sign-on.
Verify the component instances.
Run the Java ES installer a third time. Install the Sun Cluster Agent for Messaging Server and/or Sun Cluster Agent for Calendar Server.
Use the agents to configure component resources, add the resources to the resource group, and enable the resources.
Test the failover capability of the resources.

Choosing Configuration Values for Sun Cluster

For each Sun Cluster node in your solution, you must input values that configure the instance to interoperate with the other computers in the cluster. For information on choosing configuration values, see Chapter 2, Installing and Configuring Sun Cluster Software, in Sun Cluster Software Installation Guide for Solaris OS.

Adding Installation Instructions for Sun Cluster to Your Plan

Note –

For detailed information on installing Sun Cluster software that, see Sun Cluster Software Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

To add installation and configuration instructions for Sun Cluster software, do the following:

Before attempting to install Sun Cluster, software make sure that the shared external storage has been attached and configured. This is typically done as part of implementing the network connectivity specifications. For more information, see Developing a Network Connectivity Specification.
Use the Java ES installer to install Sun Cluster Core on all computers systems specified in your deployment architecture. Do not install the components that run in the cluster at this time.
Prepare the computers for Sun Cluster configuration. This includes adding file systems to the shared storage, setting up mount points, and mounting these file systems.
Run the Sun Cluster configuration utility on the first computer to establish the cluster. Supply configuration values suitable for the expected load. After configuration, reboot the computer.
Complete the configuration of Network Timing Protocol on all computers in the cluster.
1. When you configure Messaging Server you must specify the Directory Server instance where information about Messaging Server users is stored.
2. When you configure Messaging Server you supply the name of the LDAP directory branch that will represent the email domain managed by the Messaging Server instance. The Messaging Server configuration wizard adds this branch to the tree.
Add a quorum device to the cluster.
Set up cluster disks and mirroring.
Create new cluster file systems and mount the corresponding global directories.
Create a cluster resource group and associate it with a virtual host name and IP address.
Test failover of the cluster resource group.
Run the Java ES installer a second time and install the components that run in the cluster. These are typically Messaging Server and/orCalendar Server. Install these components only on the first computer in the cluster.
Run the Directory Preparation Tool, as described in Messaging Server.
If Messaging Server is installed in the cluster, run the Messaging Server configuration wizards, as described in Messaging Server.
If Messaging Server is installed in the cluster, configure Messaging Server for single sign-on.
If Messaging Server is installed in the cluster, start the Messaging Server instance.
Verify the Messaging Server instance.
If Calendar Server is installed in the cluster, run the Calendar Server configuration wizard, as described in Calendar Server.
If Calendar Server is installed in the cluster, create a calendar server administration user, user group and directory on the other computers in the cluster. (The configuration wizard did this on the first computer in the cluster.)
If Calendar Server is installed in the cluster, configure the Calendar Server instance for single sign-on.
If Calendar Server is installed in the cluster, start the Calendar Server instance.
Verify the Calendar Server instance.
Run the Java ES installer a third time. Select the Sun Cluster Agent for Messaging Server and/or Sun Cluster Agent for Calendar Server.
Use the Messaging Server agent to configure a Messaging Server resource, add it to the resource group, and enable it.
Test the failover capability of the Messaging Server resource.
Use the Calendar Server agent to configure a Calendar Server resource, add it to the resource group, and enable it.
Test the failover capability of the Calendar Server resource.

Previous: Chapter 2 The Implementation Specifications