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:
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.
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.
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.
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.
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.
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
Dependencies |
Nature of Dependency |
Must be Local? |
|
---|---|---|---|
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 |
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 |
|
Directory Server |
To provide a configuration directory |
No |
|
To provide reliable asynchronous messaging |
Yes |
||
To provide load balancing between Application Server instances |
Yes |
||
To store session state, which supports failover between Application Server instances |
Yes |
||
To store user data used for authentication and authorization |
No |
||
Prepares the LDAP directory for use with Calendar Server |
No |
||
Required if your solution uses single sign-on |
No |
||
To provide email notifications |
No |
||
To mange LDAP schema; to provision users of calendar services |
No |
||
-Application Server -Web Server |
Communications Express must be deployed to a web container |
Yes |
|
To store user data, such as address books |
No |
||
To prepare the LDAP directory for Communications Express |
No |
||
To provide authentication and authorization services and single sign-on; a local Access Manager SDK provides access to remote Access Manager |
Yes |
||
To provide underlying messaging service |
No |
||
To provide underlying calendar service |
No |
||
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 Server |
Directory Preparation Tool prepares the directory for use with Java ES communications components |
Yes |
|
Administration Server |
To configure Directory Proxy Server |
No |
|
Directory Server |
To provide underlying LDAP directory services |
No |
|
Administration Server |
To configure Directory Server |
No |
|
High Availability Session Store |
None | ||
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 | ||
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 |
|
-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 |
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 |
To recognize components installed on Sun Cluster nodes |
Yes |
|
Web Server |
To provide remote access to web applications |
Yes |
|
Web Server |
None |
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.
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 Multiplexor Instant Messaging Resources Instant 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.
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.
This section describes some behaviors of the Java ES installer that affect installation planning.
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.
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.
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.
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.
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.
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. |
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. |
|
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. |
|
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. |
|
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: |
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.
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 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.
For information on setting up Directory Server replication, see Sun Java System Directory Server 5 2005Q1 Administration Guide.
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.
The basic procedures for installing and configuring Directory Server are as follows:
A
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.
B
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).
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.
|
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.
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.
For each computer, add an instruction to run the Java ES installer and select Directory Server.
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,
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.
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 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.
If your solution uses Directory Server Console, you must plan to install Administration Server when Directory Server is installed.
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.
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. |
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 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.
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.
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. |
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:
Selecting Directory Proxy Server.
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 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.
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.
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.
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.
When you install Access Manager you must specify the web container in which Access Manager runs.
When you install Access Manager you must specify the repository for user and group data (typically a Directory Server instance, specified with a URL).
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.
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
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.
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.
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.
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.
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.
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.
When you configure Messaging Server you must specify the Directory Server instance where information about Messaging Server users is stored.
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.
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. |
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:
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.
In your plan, list all of the computers that run clustered Messaging Server instances.
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.
If your solution uses clustered Messaging Server instances, this is the second time the installer runs on the computers designated for Messaging Server.
In your plan, for each computer, add an instruction to run the Java ES installer and select Messaging Server.
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.
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.
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.
When you configure Calendar Server you must specify the Directory Server instance where information about Calendar Server users is stored.
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.
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. |
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:
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.
In your plan, list all of the computers that run clustered Calendar Server instances.
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.
If your solution uses clustered Calendar Server instances, this is the second time the installer runs on the computers designated for Calendar Server.
In your plan, for each computer, add an instruction to run the Java ES installer and select Calendar Server.
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.
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.
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.
When you install Communications Express you also install the web container in which Communications Express runs.
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.
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.
|
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. |
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.
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.
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.
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.
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.
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.
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.
When you install Portal Server you must specify the web container in which Portal Server runs.
When you install Portal Server you must specify the repository for user and group data (typically a Directory Server instance, specified with a URL).
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.
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. |
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.
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.
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.
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 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.
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.
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.
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:
Selecting Portal Server Secure Remote Access.
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.
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.
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.
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.
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.
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 |
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.
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.
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.
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 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.
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.
When you install Delegated Administrator you also install the web container in which Delegated Administrator runs.
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.
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. |
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.
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.
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.
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 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.
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.
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.
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 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.
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.
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. |
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:
Add to your plan the configuration values for the supported component.
Add an instruction to run the installer and supply configuration values for Web Server and the supported component.
Add an instruction to start the Web Server instance. This step also starts the supported component.
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:
Add an instruction to run the installer, select Web Server, and supply configuration values for Web Server.
Add an instruction to list the configuration values for the supported component.
Add an instruction to run the supported component's configuration wizard and supply the configuration values for the supported component.
Add an instruction to start the Web Server instance. This step also starts the supported component.
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 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.
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 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.
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.
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
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:
Add to your plan the configuration values for the supported component.
Add an instruction to run the installer and supply configuration values for Application Server, Application Server's local dependencies, and the supported component.
Add an instruction to start the Application Server instance. This step also starts the supported component.
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:
Add an instruction to run the installer and supply configuration values for Application Server and Application Server's local dependencies.
Add an instruction to list the configuration values for the supported component.
Add an instruction to run the supported component's configuration wizard and supply the configuration values for the supported component.
Add an instruction to start the Application Server instance. This step also starts the supported component.
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 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 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.
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.
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.
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.
When you configure Messaging Server you must specify the Directory Server instance where information about Messaging Server users is stored.
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.