InfoCenter Home >
6: Administer applications >
6.6: Tools and resources quick reference >
6.6.46: Administering WebSphere administrative servers

6.6.46: Administering WebSphere administrative servers

The administrative server manages configurations and states of application servers, applications, and other resources in the WebSphere administrative domain. It keeps its administrative data in a database that you define during product installation.

Configuring the administrative server and database

There are a couple of ways to configure the administrative server, and provide information about its administrative database.

Administrative configuration file

The administrative server obtains its own configuration from the properties in the administrative configuration file. Some values are set during product installation, while others are primarily for modification later.

Adding Java command line arguments for the administrative server

The admin.config file contains many administrative server properties you can set. In addition, you might want to pass the administrative server some generic Java command line arguments.

In the admin.config file, add the properties and their values as arguments on the com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs property. Add them using standard Java command line syntax:

-D property_name=property_value

For example, this setting passes performance-related Java parameters to the Java process constituting the administrative server:

com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs=-ms32m -mx128m

The admin.config file contains both default properties that apply to most configurations and non-default properties.

Creating the database tables and default configuration

In most cases (see below for special cases), the administrative database tables are created, and populated with a default configuration, when you install WebSphere Application Server. During product installation, you must provide information regarding the administrative database you would like the installation's administrative server to use.

Settings in the administrative configuration file record the database information, and determine whether the database tables are created and (or) populated with the default configuration.

Special cases requiring additional steps after product installation

In some cases, the database tables are not created automatically during product installation, or the tables are not populated with the default configuration. If you need to, trigger the actions manually by setting properties in the administrative configuration file and starting the administrative server again.

  Users of WebSphere Application Server Advanced Edition Version 4.0 on Solaris and AIX operating systems with an Oracle database as the administrative database should note the following. In those cases, the default server is not created when you start the administrative server for the first time after installing the product. To create the default server and other default resources, set:

install.initial.config=true
in the administrative configuration file and start the administrative again.

  If you use an Oracle database user ID other than EJSADMIN, the default value assigned during the WebSphere Application Server installation, you will need to edit the administrative configuration file.

Ensure that the user ID and schema lines reflect your actual database user ID and password:

com.ibm.ejs.sm.adminServer.dbuser=your_user_name
com.ibm.ejs.sm.adminServer.dbSchema=your_schema_name

Then start the administrative server.

Establishing centralized administration

Multiple administrative servers can be configured to use the same administrative database, allowing configuration data to be kept in a centralized place for administration of WebSphere Application Server across multiple machines (known as administrative nodes). In a successful multiple node configuration, the administrative console tree view will show each of the administrative nodes and its contents.

Configuring the 2nd through Nth machine in a cluster

Do not create the database tables or populate them with the default configuration.

When you are setting up a cluster of administrative nodes, only the WebSphere application server product installation needs to install the default configuration:

  1. On the first machine, ensure that the database tables have been created, and populated with the configurations for the default resources. In the administrative configuration file, this means:
    install.initial.config=true
    
  2. On all subsequent machines sharing the same administrative database, ensure the database tables are not created and the default resources are not installed a second time.
    install.initial.config=false
    com.ibm.ejs.adminServer.dbInitialized=false
    

If you have already installed the second (or later) machine, with install.initial.config set to true, then the problem should work itself out after all machines in the cluster have been shut down and started again. Until then, you might notice these problems:

  • Absence of the WebSphere Administrative Domain resource in the tree view of the administrative console, or other peculiarities in the administrative topology
  • Administrative server on the second or later machine will throw exceptions when you first start it
Configuring a remote DB2 database as the administrative database

  If the administrative server is going to store its administrative data in a remote DB2 database, you need to catalog the remote database. See your database documentation for instructions.

Setting the dbserverName and dbportNumber for the data source (flags in the administrative configuration file) is not working in the case of a remote DB2 database. For example, if you have the application server and the DB2 client is installed on one machine, and are trying to connect the client to the DB2 server on another machine.

This problem could be overcome in a subsequent WebSphere Application Server fixpak. Be sure to consult the release notes for each fixpak to see whether the problem is fixed.

What to do if you must drop the administrative database tables

If you must drop the tables in the administrative database for some reason, then reset the pertinent settings in the administrative configuration file to create the tables again.

You will always need to set:

com.ibm.ejs.adminServer.dbInitialized=true

If the machine is the first machine in a cluster of machines sharing an administrative database, then populate it with the default configuration:

install.initial.config=true

When you start the administrative server again, the settings will be applied.

Miscellaneous topics

The remainder of this article discusses miscellaneous topics pertaining to the administrative server and database.

Backup copies of admin.config

Note, commented out lines in admin.config will be removed completely when the administrative server starts.

It is recommended you periodically save a backup copy of admin.config. For example, you might delete lines that you want to restore later.

Running the administrative server in the background

To run the server as a background process, add this parameter to admin.config:

com.ibm.ejs.sm.adminServer.processPriority=>number
where number is 28 for AIX and 24 for Solaris. It could also be the default priority of the non-root user ID under which the administrative server is running. (See also the information on running as non-root).

You will also need to edit the properties of each application server associated with this administrative server. Modify the process priority of each server to have the same process priority (number) you assigned to the administrative server.

Configuring the nanny process

On UNIX-based systems, the nanny process tries to start an administrative server when the administrative server fails. The nanny settings are available in the admin.config file for the administrative server that the nanny is tending.

Go to previous article: Checking your IBM HTTP Server version Go to next article: Administrative server configuration file properties

 

 
Go to previous article: Checking your IBM HTTP Server version Go to next article: Administrative server configuration file properties