Skip navigation.
Downloads | Product Documentation | Support

Administration Console Online Help

# Creating, Configuring, and Monitoring Servers

[Attributes and Console Screen Reference for Servers]

If a domain's Administration Server is running, you can use the Administration Console to add and remove servers in the domain and to configure all of the domain's properties. In addition, you can use the Administration Console to monitor the performance and overall health of a domain.

If you want to create a new domain, use the Configuration Wizard. You can also use the Configuration Wizard to modify many features of a domain's configuration without starting server instances in the domain. The Configuration Wizard can configure only a subset of a domain's features. For more information, refer to "Creating and Configuring Domains Using the Configuration Wizard."

The following sections describe how to create, configure, and monitor servers from the Administration Console:

- Adding and Removing Servers in an Existing Domain
- Configuring the Default Network Connections
- Configuring a Custom Network Channel for a Non-Clustered Server
- Transitioning Domains from Development to Production Environments: Main Steps
- Other Configuration Tasks
- Monitoring a Server

# Adding and Removing Servers in an Existing Domain

A domain can include multiple WebLogic Server instances. A minimal domain contains only one WebLogic Server instance, which functions both as an Administration Server and as a Managed server—such a domain can be useful while developing applications, but is not recommended for use in a production environment.

A Managed Server is a WebLogic Server instance that retrieves its configuration data from the domain's Administration Server. There can be many Managed Servers in a domain, but only one Administration Server. Usually, you create and start server instances as Managed Servers to run your business applications in a production environment. In this standard scenario, the server instance that you start as the Administration Server does not run business applications. Instead, it only manages resources in the domain. To improve reliability and performance, you can install the WebLogic Server software on several computers and run the servers that you create on the various WebLogic Server hosts. For more information about Managed Servers and Administration Servers, refer to "WebLogic Server Domains."

Any server instance that you define for a domain can run as an Administration Server or a Managed Server. There is no attribute within a server's configuration that designates it as an Administration Server or Managed Server. Instead, the first server instance that you start in a domain always functions as the Administration Server. If you start additional servers in a domain, you must start them as Managed Servers. For more information, refer to Starting and Stopping Servers.

The following sections describe how to add and remove servers:

- Creating a Managed Server in an Existing Domain
- Cloning a Server
- Deleting a Managed Server
- Deleting an Administration Server

## Creating a Managed Server in an Existing Domain

To create a Managed Server in an existing domain:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, click on the name of the Servers folder. (See Figure 330-1.)

Figure 330-1 Click on the Name of the Servers Folder

3. On the Servers page, click Configure a new Server.

The Administration Console displays the Servers —> Create page in the right pane.

4. On the Create page, enter the name of the server in the Name field.

Each server instance in your WebLogic environment must have a unique name, regardless of the domain or cluster in which it resides, or whether it is an Administration Server or a Managed Server. Within a domain, each server, machine, cluster, JDBC connection pool, virtual host, and any other resource type must be named uniquely and must not use the same name as the domain.

The server name is not used as part of the URL for applications that are deployed on the server. It is for your identification purposes only. The server name displays in the Administration Console, and if you use WebLogic Server command-line utilities or APIs, you use this name to identify the server.

5. For information about modifying the default values on the General tab, refer to Attributes.
6. Click Create.

The new server appears under the Servers node in the left pane. The Administration Console updates the domain's `config.xml` file with the new server configuration data.

## Cloning a Server

Cloning a server creates a new server instance with the same attributes as the original server.

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, click on the name of the Servers folder. (See Figure 330-1.)

The Servers page displays a list of servers that have already been defined in the domain.

3. On the Servers page, click the Clone icon in the row of the server you want to clone.

A dialog displays the tabs associated with cloning a new server.

4. Enter a new name for the server.
5. Click the Clone button in the lower right corner to create a server instance with the name you specified in the Name field.

The new server appears under the Servers node in the left pane. The Administration Console updates the domain's `config.xml` file with the new server configuration data.

## Deleting a Managed Server

When you delete a server, WebLogic Server removes its associated configuration data from the domain's configuration file (`config.xml`). To see which data will be deleted, select the server in the left pane of the Administration Console. All of the data in the right pane will be deleted. For example, any network channels that you created for the server are deleted, but applications and EJBs that are deployed on the server will not be deleted.

You cannot delete a server that is currently active; therefore, you cannot use the Administration Console to delete the Administration Server. (The Administration Console runs on the Administration Server.) For more information, see Deleting an Administration Server.

You cannot delete a server if it is running a pinned service. Before you can delete such a server, you must migrate the service to a migratable target. See "Migration for Pinned Services."

To delete a Managed Server:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, click on the name of the Servers folder. (See Figure 330-1.)

The Servers page displays a list of servers that have already been defined in the domain.

3. On the Servers page, click the Delete icon in the row of the server you want to delete.
4. Click Yes to confirm your deletion request.

## Deleting an Administration Server

To delete the server instance that you are using as an Administration Server:

1. Shut down all server instances in the domain, including the Administration Server.
2. Start another server in the domain as the Administration Server by entering the following command:
   `java -Dweblogic.Name=``serverName` `weblogic.Server`

See Starting an Administration Server With the java weblogic.Server Command.

3. Use the Administration Console to delete the server instance that you were previously using as the Administration Server.

# Configuring the Default Network Connections

Each WebLogic Server instance provides default settings for the protocols, listen addresses, and listen ports through which it can be reached. These settings are referred to collectively as the default network channel. This default network channel provides two listen ports through which it receives requests: one for non-SSL requests and the other for SSL requests. You can disable one of these ports, but at least one must be enabled.

The following sections describe how to configure the default network channel for a server instance:

- Configuring Protocols
- Configuring the Listen Address
- Configuring the Listen Ports

You can configure additional network channels to meet various connection requirements and improve the utilization of your system and network resources. For information on configuring additional network channels, refer to "Configuring Network Resources."

## Configuring Protocols

Servers can be reached through the following URL: `protocol``://``listen-address``:``listen-port`

The default network channel supports multiple protocols for communicating with a server instance. By default, clients can contact a server instance through the HTTP and HTTPS protocols. BEA utilities (such as the `weblogic.Admin` command-line utility) can also connect to servers using the proprietary T3 and T3S protocols.

The following sections describe how to enable and configure communications protocols for a WebLogic Server instance:

- Configuring the HTTP Protocol
- Configuring the T3 Protocol
- Enabling and Configuring the IIOP Protocol
- Enabling and Configuring jCOM

### Configuring the HTTP Protocol

The server instance for which you configure the HTTP protocol does not need to be running. If it is running, and if you change settings on the HTTP tab, you must restart it. Changes on the Protocols —> General tab take effect without requiring you to restart the server.

To configure the HTTP protocol:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)
3. Select Protocols —> HTTP.
4. Modify the default settings as desired. See Attributes.
5. Click Apply.
6. To enable tunneling of connections:

1. Select Protocols —> General.
2. In the Advanced Options bar, click Show.
3. Click Enable Tunneling and provide values for Tunneling Client Ping and Tunneling Client Timeout. For information about each setting, refer to Attributes.

Note: These settings apply to all protocols in the server's default network configuration that support tunneling.

Also see "Setting Up WebLogic Server for HTTP Tunneling."

4. Click Apply.

7. If the server instance is running, and if you made changes on the HTTP tab, restart the server.

### Configuring the T3 Protocol

The server instance for which you configure the T3 protocol does not need to be running. If it is running, all modifications to the T3 protocol settings take effect immediately.

To configure the T3 protocol:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)
3. Select Protocols —> General.
4. In the Advanced Options bar, click Show.
5. Modify the values for Complete Message Timeout, and Maximum Message Size. See Attributes.

Note: These settings apply to all protocols in the server's default network configuration. See "The Default Network Channel."

6. To enable tunneling of connections, click Enable Tunneling and provide values for Tunneling Client Ping and Tunneling Client Timeout. See Attributes.

Note: These settings apply to all protocols in the server's default network configuration that support tunneling.

7. Click Apply.

Note: Messages sent via the default channel can contain DNS information about the hosts they originate on or are destined to. If a T3 connection is established across a firewall that has network address translation (NAT) enabled, it is possible that some information about the network configuration behind the firewall will be revealed. Using the firewall to prevent T3 connections through the firewall will prevent this problem.

### Enabling and Configuring the IIOP Protocol

The IIOP (Internet Inter-ORB Protocol) protocol makes it possible for distributed programs written in different programming languages to communicate over the Internet. For information about using RMI-IIOP in your applications, refer to the "Programming WebLogic RMI over IIOP" guide.

The server instance for which you enable and configure the IIOP protocol does not need to be running. If it is running, you must restart it after you complete these steps.

To enable and configure the IIOP protocol:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)
3. Select Protocols —> IIOP.
4. Enable the IIOP protocol by checking the Enable IIOP check box.
5. To modify the default configuration, in the Advanced Options bar, click Show.
6. If you want to specify a default IIOP user name and password:

1. In the Default IIOP User field, enter a user name.
2. Click Apply.
3. In Default IIOP Password, enter a password.
4. In Confirm Default IIOP Password, enter the password again.

7. To configure the other options on the IIOP tab, see Attributes.
8. Click Apply.
9. To configure maximum messages size and timeout settings:

1. Click the Protocols—>General tab.
2. In the Advanced Options bar, click Show.
3. Modify the values for Complete Message Timeout, Idle Connection Timeout, and Maximum Message Size. For information about each setting, refer to Attributes.

Note: These settings apply to all protocols in the server's default network configuration. See "The Default Network Channel."

4. Click Apply.

10. To enable tunneling of connections:

1. Select Protocols —>General.
2. In the Advanced Options bar, click Show.
3. Click Enable Tunneling and provide values for Tunneling Client Ping and Tunneling Client Timeout. See Attributes.

Note: These settings apply to all protocols in the server's default network configuration that support tunneling.

4. Click Apply.

11. If the server instance is running, restart it.

### Enabling and Configuring jCOM

WebLogic jCOM is a software bridge that allows bidirectional access between Java/J2EE objects deployed in WebLogic Server, and Microsoft ActiveX components available within Microsoft Office family of products, Visual Basic and C++ objects, and other Component Object Model /Distributed Component Object Model (COM/DCOM) environments. For more information about WebLogic jCOM, refer to the "Programming WebLogic jCOM" guide.

The server instance for which you enable and configure the jCOM protocol does not need to be running. If it is running, you must restart it after you complete these steps.

To enable and configure the jCOM protocol:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)
3. Select Protocols —> jCOM.
4. Enable the jCOM protocol by checking the Enable COM check box.
5. Use the other items on the jCOM tab to configure jCOM. See Attributes.
6. Click Apply.
7. If the server instance is running, restart it.

## Configuring the Listen Address

Servers can be reached through the following URL: `protocol``://``listen-address``:``listen-port`

By default, a server's listen address attribute is undefined, which enables you to reach the server through any of the following listen addresses:

- The primary IP address of the computer that hosts the server
- The host DNS name
- The `localhost` string (valid only for requests that are issued from the computer on which the server is running)

If the server instance must be accessible as `localhost` (for example, if you create administrative scripts that connect to `localhost`), and must also be accessible by remote processes, leave the listen address blank. Otherwise, if you want to limit the valid listen address for a server, refer to Table 330-2 for guidelines on specifying listen addresses.

Note: On multi-homed Windows NT machines, if you leave the listen address undefined or if you specify a DNS name, a server instance binds to all available IP addresses.

Table 330-2 Setting the Listen Address

If the Listen Address is set to... | Then the following is true...
--- | ---
IP address or DNS name | To connect to the server instance, processes can specify either the IP address or the corresponding DNS name. Processes that specify `localhost` will fail to connect. You must update existing processes that use `localhost` to connect to the server instance. Connections that specify the IP address for the listen address and a secured port for the listen port must disable host name verification. Note: To resolve a DNS name to an IP address, Weblogic Server must be able to contact an appropriate DNS server or obtain the IP address mapping locally. Therefore, if you specify a DNS name for the listen address, you must either leave a port open long enough for the WebLogic Server instance to connect to a DNS server and cache its mapping or you must specify the IP address mapping in a local file. If you specify an IP address for ListenAddress and then a client request specifies a DNS name, WebLogic Server will attempt to resolve the DNS name, but if it cannot access DNS name mapping, the request will fail.
`localhost` | Processes must specify `localhost` to connect to the server instance. Only processes that reside on the machine that hosts the server instance (local processes) will be able to connect to that server instance.

### Configuring the Listen Address from the Administration Console

The server instance for which you configure the listen address does not need to be running. If it is running, you must restart it after you complete these steps.

To configure the listen address from the Administration Console:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)

Figure 330-3 Click on a Server

3. In the right pane, select Configuration —> General.
4. Enter a value in the Listen Address box. Refer to Table 330-2 for guidelines.
5. Click Apply.
6. If the server is running, restart it.

## Configuring the Listen Ports

Servers can be reached through the following URL: `protocol``://``listen-address``:``listen-port`

Each WebLogic Server instance defines two listen ports in its default network channel: one for regular, non-secure requests (via such protocols as HTTP and T3) and the other for secure requests (via such protocols as HTTPS and T3S).

Note: By default, a server instance uses demonstration certificates to authenticate requests from the secure port. In a production environment, you must configure SSL to use certificates from a certificate authority. See "Configuring the SSL Protocol" in the Managing WebLogic Security guide.

You can disable either the default non-SSL or the default SSL listen port, but at least one must be enabled, even if you create one or more network channels for the server.

Although you can specify any valid port number, if you specify port `80`, you can omit the port number from the HTTP request used to access resources over HTTP. For example, if you define port `80` as the listen port, you can use the URL `http://hostname/myfile.html` instead of `http://hostname:portnumber/myfile.html`.

On some operating systems, port 80 can be accessed only by processes that run under a privileged user or group ID. In this case, you can assign the server instance to a UNIX Machine that has defined a Post-Bind UID or GID. For more information, refer to Machines.

If you run multiple instances of WebLogic Server on a single computer, each instance must use a unique listen port/listen address combination. On a multihomed computer (a computer that can be accessed through multiple IP addresses), you can use the same listen port but configure each server to use a unique IP address as its listen address. If your computer does not support multiple IP addresses, you must use a different listen port for each active instance.

### Configuring the Listen Ports from the Administration Console

The server instance for which you configure the listen ports does not need to be running. If it is running, you must restart it after you complete these steps.

To configure the listen ports from the Administration Console:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)
3. In the right pane, select Configuration —> General.
4. If you want to disable the non-SSL listen port so that the server listens only on the SSL listen port, remove the checkmark from the Listen Port Enabled box.

If you want to disable the SSL listen port so that the server listens only on the non-SSL listen port, remove the checkmark from the Enable SSL Listen Port box.

Note: You cannot disable both the non-SSL listen port and the SSL listen port. At least one port must be active.

5. If you are using the non-SSL listen port and you want to modify the default port number, change the default number in the Listen Port box.
6. If you want to modify the default SSL listen port number change the value in the SSL Listen Port box.
7. Click Apply.
8. If the server is running, restart it.

# Configuring a Custom Network Channel for a Non-Clustered Server

You can configure custom network channels to meet varying connection requirements and improve utilization of your systems and network resources. See "Configuring Network Resources."

Note: If this server belongs to a cluster, refer to "Configuring Network Channels with a Cluster."

The server instance for which you configure a custom network channel does not need to be running. If it is running, you must restart it after you complete these steps.

To configure a custom network channel from the Administration Console:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)
3. In the right pane, select Configuration —>Protocols —> Channels.
4. Click Configure a new Network Channel.
5. Enter the Name, Protocol, Listen Address and Listen Port for the new network channel and click Create.
6. To support Network Address Translation (NAT) firewalls, in External Listen Address enter the IP address or DNS name that clients use to access applications on the server instance.
7. To configure additional attributes for this network channel:

1. In the Advanced Options bar, click Show.
2. Modify the values in advanced options. See Advanced Attributes.

8. Click Apply.
9. If the server is running, restart it.

# Transitioning Domains from Development to Production Environments: Main Steps

In a production environment, the security requirements are typically much stricter than in a development environment. The network environment is typically more complex, and the need for monitoring and availability is greater.

The following steps outline a logical order for transitioning a server that you originally configured for a development environment to a production environment:

1. Secure the hardware, WebLogic Server software, and your application in the production environment. See "Securing a Production Environment."
2. If you want to use multiple Network Interface Cards (NICs) and/or multiple port numbers in your domain to improve performance and solve common networking problems, set up Network Channels. For more information, refer to "Configuring Network Resources."
3. Configure servers to start in production mode. For more information, refer to Changing the Runtime Mode.
4. Configure servers to use a JVM that is optimized for production-level performance. For more information, refer to "Changing the JVM that Runs Servers."

On a Windows or Linux platform, BEA recommends using the JVM that the WebLogic JRockit SDK provides. This JVM provides optimal running performance but initial startup cycles can require more time than other JVMs.

Note that when you change JVMs, you most likely need to adjust the memory available to the JVM.

5. If you want to use the Administration Console to start the Managed Servers in your domain, do the following:

1. Configure a Node Manager to run on a specific computer (machine). For more information, refer to "Configuring a Machine."
2. Start the Node Manager. The Node Manager is a small program that can run on WebLogic Server hosts. In addition to enabling you to start server instances from the Administration Console, the Node Manager can also restart servers that report themselves to be in an unhealthy state. For more information, refer to "Starting and Stopping Node Manager."
3. Start the Managed Server from the Administration Console. For more information, refer to "Starting Managed Servers from the Administration Console."

6. If you want to use the Node Manager to automatically restart unhealthy servers, refer to "Configure Monitoring, Shutdown, and Restart for Managed Servers."
7. If you want to use a WebLogic Server instance as a Web server, refer to "Configuring WebLogic Server Web Components."

The WebLogic Server Web server component can handle high volume Web sites, serving static files such as HTML files and image files as well as servlets and JavaServer Pages (JSP).

## Changing the Runtime Mode

The runtime mode is a domain-wide setting. As each Managed Server starts, it refers to the mode of the Administration Server to determine its runtime mode. By default, all servers run in development mode. If you configure the domain to run in production mode, the Administration Server saves this setting to the domain's `config.xml` file.

BEA recommends that you set the mode when you first create a domain instead of changing the mode for an existing domain. See Production and Development Modes.

To change the mode in which all servers in a domain run:

1. Start the Administration Server.

See Starting Administration Servers.

2. Select the name of the active domain in the left pane to display the domain's configuration attributes.
3. In the right pane, select Configuration —>General.
4. To specify production mode, select the Production Mode check box.

To specify development mode, clear the Production Mode check box.

5. Restart all Managed Servers in the domain.

# Other Configuration Tasks

The following sections describe miscellaneous configuration tasks:

- Replicating a Domain's Configuration Files for Managed Server Independence
- Disabling Managed Server Independence
- Creating Execute Queues in WebLogic Server Performance and Tuning.

## Replicating a Domain's Configuration Files for Managed Server Independence

The server instance for which you configure Managed Server Independence (MSI) replication does not need to be running. If it is running, you must restart it after you complete these steps.

To configure a Managed Server to replicate a domain's configuration files:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)
3. In the right pane, select Configuration —>Tuning.
4. In the Advanced Options bar, click Show.
5. Under Advanced Options, make sure that the Managed Server Independence Enabled check box is checked.
6. Click the MSI File Replication Enabled check box.
7. Click Apply.
8. If the server is running, restart it.

## Disabling Managed Server Independence

When a Managed Server starts, it tries to contact the Administration Server to retrieve its configuration information. If a Managed Server cannot connect to the Administration Server during startup, it can retrieve its configuration by reading configuration and security files directly. A Managed Server that starts in this way is running in Managed Server Independence (MSI) mode. For more information about MSI mode, refer to "Managed Server Independence Mode."

By default, MSI mode is enabled.

The server instance for which you want to disable MSI does not need to be running. If it is running, you must restart it after you complete these steps.

To disable MIS:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)
3. In the right pane, select Configuration —> Tuning.
4. In the Advanced Options bar, click Show.
5. Under Advanced Options, clear the Managed Server Independence Enabled check box.
6. Click Apply.
7. If the server is running, restart it.

# Monitoring a Server

The following tasks monitor the performance and health state of servers:

- Monitoring a Server Instance from the Administration Console
- Determining the Platform on Which a Server Is Running
- Monitoring the JRockit Virtual Machine
- Configure Self-Health Monitoring, Shutdown, and Restart for Managed Servers

For more information about monitoring WebLogic Server, refer to "Monitoring a WebLogic Server Domain."

## Monitoring a Server Instance from the Administration Console

The WebLogic Server Administration Console provides visibility into a broad array of configuration and status information of a server instance.

The server instance that you want to monitor must be running. WebLogic Server does not archive performance statistics.

To monitor a server instance from the Administration Console:

1. Start the Administration Server and the server instance you want to monitor.

See Starting and Stopping Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)
3. In the right pane, select Configuration —> Monitoring.
4. Refer to "Server Monitoring Pages."

## Determining the Platform on Which a Server Is Running

To determine the platform on which a server instance is running:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)
3. In the right pane, select Configuration —> Monitoring.
4. In the Advanced Options bar, click Show.
5. Under Advanced Options, the Administration Console indicates the software platform on which the server is running.

## Monitoring the JRockit Virtual Machine

If you run a server with the JRockit Virtual Machine (VM), you can view runtime data about the underlying JRockit VM and the memory and processors on the computer that is hosting the VM.

To monitor the JRockit VM:

1. Use the JRockit VM to start the server instance.
2. Start the Administration Server.

See Starting Administration Servers.

3. In the left pane of the Administration Console, expand the Servers folder and select a server that is using the JRockit VM. (See Figure 330-3.)
4. In the right pane, select Monitoring —> JRockit.

The JRockit tab displays monitoring information.

To view additional data about the VM, such as how long it spends in a specific method, use the JRockit Management Console. Note that if you want to use the JRockit Management Console, you must include the `-XManagement` startup option when you start the server. (You do not need this option to use the WebLogic Server Administration Console to monitor the VM.) For more information, refer to "JRockit Documentation Home Page."

## Configure Self-Health Monitoring, Shutdown, and Restart for Managed Servers

A server can also monitor key aspects of its subsystems and report when a subsystem is not functioning properly. If the server is running under a Node Manager, the Node Manager can automatically restart a server with an unhealthy subsystem.

The server instance for which you want to self-health monitoring does not need to be running. If it is running, you must use the Node Manager to restart it after you complete these steps.

Follow these steps to configure Node Manager features for monitoring, shutting down, and restarting a Managed Server:

1. Start the Administration Server.

See Starting Administration Servers.

2. In the left pane of the Administration Console, expand the Servers folder and select a server. (See Figure 330-3.)
3. In the right pane, select Configuration —> Health Monitoring.
4. On the Health Monitoring tab, edit the values. For information about each attribute, refer to Attributes.
5. Click Apply.
6. If the server is running, shut it down.
7. Use the Node Manager to start the server. Node Manager can perform automatic monitoring and shutdown only for servers that it starts.