Previous | Home | Next


Building systems with profiles

Profiles can be created at any time during or after installation using graphical or command-line tools. WAS provides the following profile management tools:

When you use the Profile Management Tool with the Motif graphical user interface on the Solaris operating system, the default size of the Profile Management Tool might be too small to view all of the messages and buttons of the Profile Management Tool. To fix the problem, add the following lines to the app_server_root/.Xdefaults file:

After adding the lines, run the following command before launching the Profile Management Tool:

xrdb -load user_home/.Xdefaults

Each profile you create is registered in a profile registry, which is under:

INSTALL_ROOT/properties/profileRegistry.xml


Starting the WebSphere Customization Toolbox Profile Management Tool

There are several ways to start the WebSphere Customization Toolbox:


Common steps for all profiles

Many of the options available when you create a profile are the same, regardless of the type of profile.


Environment selection

The Profile Management Tool provides profile templates, including the cell template, which has the ability to create a cell in a single step. During profile creation, you are asked to select the type of profile to create.


Profile type selection

We can select the following profiles:


Profile creation options

While creating profiles, you are presented with a choice of following the Typical path, where a set of default values for most settings are used, or an Advanced path, which lets we specify values for more options.


Profile creation path selection

The Advanced path is preferred because it gives you additional control over names and settings.

Administrative security

All profiles except the custom profile can be secured by enabling the administrative security.

Prevents users from gaining unauthorized access to the dmgr console. If you enable administrative security during profile creation, you are asked for a user ID and password that are added to a file-based user registry with the Administrator role.

Enabling administrative security: Consider enabling administrative security. An XML file-based user repository is created during profile creation and can be later federated with other repositories to provide a robust user registry for both administrative and application security.

If we do not want to use the file-based repository, do not enable administrative security during profile creation and configure it manually afterwards.

Configuration of administrative security during profile creation

If you are going to create a job manager and register a deployment manager, keep in mind that we cannot register a deployment manager that has security enabled to a job manager that does not. So, plan your administrative security policy across the entire WebSphere environment.


Certificates

Each profile contains a unique chained certificate signed by a unique long-lived root certificate generated when the profile was created. When a profile is federated to a deployment manager, the signer for the root signing certificate is added to the common truststore for the cell, establishing trust for all certificates signed by that root certificate.

Two windows are used during profile creation to manage the import or creation of these certificates. The first window allows you to generate the certificates or import existing certificates.

The second window is used to modify the certificate information to create new certificates during profile creation. The auto-generated DNs for the certificates are usually long, so you might want to change them.

The default password for the generated keystores is WebAS. Consider changing it with our own password to increase the server security.

Also review the expiration period of the certificates. The root certificate minimal expiration period is 15 years.


Port assignments

Every process uses a set of ports at run time. These ports must be unique to a system.

The profile management tool wizard assigns unique port numbers to a profile to omit port conflicts when multiple profiles are installed on the same system. Ensure there are no port conflicts with other software installed on the same system.

When you take the Advanced path through the profile wizard, we have three options:

After profile creation, we can obtain port numbers by looking in the following file:

For example:

We can also use the PortManagement command group for AdminTask in wsadmin to list application and server ports and modify server ports.

Note the following port numbers for later use:

SOAP connector port If you plan to federate this node to a deployment manager later using the deployment manager administrator console, know this port number. This port is also the port that you connect to when using the wsadmin administration scripting interface.
Administrative console port You must know this port to access the dmgr console. When you turn on security, know the Administrative console secure port.
HTTP transport port This port is used to access applications running on the server directly versus going through a web server. Running as a service

When creating a profile on a Windows or Linux system, we have the option of running the application server as a Windows service. This action provides you with a simple way of automatically starting the server process with the system.

To run the process as a Windows service, select the check box, and enter the values for the logon and startup type. The window lists the user rights the user ID you select needs to have. If the user ID does not have these rights, the wizard automatically adds them.

Configuring the profile to run as a Windows service...

When you take the Typical path through the profile creation wizard on a Windows operating system, the default is to define the process as a Windows service. On Linux operating systems, the default setting is not to define the process as a service.

If we do not register the process as a Windows or Linux service during profile creation, we can do that later using the WASService command. This command enables to you create a service for a Java process on both Windows and Linux operating systems.


Verification steps

At the end of the profile creation, we have the opportunity to start the First steps console . This interface helps you start the server process and has other useful links, such as opening the dmgr console, an information center and IBM Education Assistant link, starting the WebSphere Customization Toolbox, and installation verification.

Using the First steps console after successful profile creation

To verify the new profile installation, we can use the Installation verification link. It launches the new profile and log information in a pop-up window. We can also use it later by running the firststeps script from PROFILE_HOME directory, for example:

To manually verify profile installation...

  1. View the messages produced during profile creation:

      INSTALL_ROOT/logs/manageprofiles/profile_name_create.log

    For example:

      /IBM/WAS/AppServer/logs/manageprofiles/AppSrv01_create.log

  2. Review server logs for any problems, errors, or warnings:

    • PROFILE_HOME/logs/server_name/startServer.log
    • PROFILE_HOME/logs/server_name/SystemOut.log
    • PROFILE_HOME/logs/server_name/SystemErr.log

    For example:

      /IBM.WAS.AppServer.profiles.AppSrv01.logs.server1.SystemOut.log

  3. If applicable, log in to the dmgr console hosted by the process.

    We can access the console from the First Steps menu or by accessing its URL from a web browser:

      http://server_host:<admin_console_port>/ibm/console

    For example...

      http://localhost:9060/ibm/console/


Create an application server profile

An application server profile can be run stand-alone or can be later federated to a deployment manager cell for central management.

To create the profile:

  1. Start the WebSphere Customization Toolbox, and open Profile Management Tool.

  2. Click Create.

  3. Select Application server as the profile type, and click Next.

  4. Select whether to take a typical or advanced path to install the profile:

    • If Typical is selected, proceed to step 8 and continue from step 13.

    • If Advanced is selected, continue with the following steps.

  5. Select both check boxes to deploy the dmgr console and the default application.

    Installing the dmgr console is recommended. However, there might be some circumstances when we do not want to install an dmgr console, such as if you plan to control all administrative tasks through scripting. If we do not install the dmgr console during profile creation, we can install it using the deployConsole.py script at a later time.

    To install the dmgr console after profile creation:

    1. Navigate to PROFILE_HOME/bin.

    2. Start the server...

    3. Enter the following command to install the application:

        wsadmin.bat(sh) -lang jython -f deployConsole.py install

      If you configured administrative security during profile creation, you are prompted for an administrative user ID and password when running the wsadmin install command.

    The second option of deploying the default application installs a default application that can be used to verify the application server is running and serving application content. The default application contains a web module called DefaultWebApplication and an EJB module called Increment. The application includes a number of servlets that retrieve information that can be used for verification. For example we can try to invoke the Snoop servlet to verify if the application server is properly serving the content:

      http://localhost:9080/snoop

    Other sample apps are available

  6. Enter a unique name for the profile or accept the default.

    Enter a unique directory path for the profile directory or accept the default. Click Next.

    From WAS V8, additional server runtime performance tuning option has been introduced during profile creation. You have three performance tuning options to choose from:

    Standard The standard default configuration settings that are optimized for general purpose usage.
    Peak Appropriate for a production environment where application changes are rare and optimal runtime performance is important.
    Development Appropriate for a development environment where frequent application updates are performed and system resources are at a minimum. Do not use the development setting for production servers.

  7. Enter the new node name and the system host name.

    The node name defaults to a name based on the host name of your system. The wizard checks if there are existing nodes in the installation and takes this situation into account when creating the default node name |

    Click Next.

    If you plan to create multiple stand-alone application servers for federation later to the same cell, select a unique node name for each application server.

  8. Choose whether to enable administrative security.

  9. The next two screens guide you through certificate generation.

  10. Configure TCP/IP ports for the server.

  11. If you install the server on Windows or Linux, configure the server to run as a service.

  12. The wizard allows you to create an optional web server definition, which defines an external web server.

    This setup allows you to manage web server plug-in configuration files for the web server and, in some cases, to manage the web server instance. If we have not installed a web server or want to perform this action later, we can do it from the dmgr console.

    For this installation, disable the check box, and click Next.

  13. Review the options you provided for the new profile, and click Create to create the profile.

  14. Click Finish to close the wizard and start the First Steps console.

  15. Use the First Steps console to verify the installation, start the server, and access the dmgr console.

  16. Log in to the console, if you disabled the security login without providing credentials.

  17. Click...

      Servers | Server Types | WebSphere Application servers

    We can see the application server you just created.


Create a deployment manager profile

To create the deployment manager profile:

  1. Start the WebSphere Customization Toolbox, and open Profile Management Tool.

  2. Click...

      Create | Management | Next | Deployment manager | Next

  3. Select whether to take a typical or advanced path to install the profile:

    • If Typical is selected, then proceed to step 9 and continue from step 13

    • If Advanced is selected, continue with the following steps

  4. Select the option to deploy the dmgr console (the default), and click Next.

  5. Enter a unique name for the profile or accept the default. The profile name becomes the directory name for the profile files. Click Next.

    If you enable the Make this profile the default check box, this profile receives console wsadmin commands by default. Otherwise specify the profile name for the command using the profile parameter.

  6. Enter the node, host, and cell names. The defaults are based on the host name of your system. The wizard recognizes if there are existing cells and nodes in the installation and takes this setup into account when creating the default names. Click Next.

  7. Choose whether to enable administrative security.

  8. The next two screens guide you through certificate generation.

  9. Configure TCP/IP ports for the server.

  10. If you install the server on Windows or Linux, configure the server to run as a service.

  11. Review the options you provided for the new profile, and click Create to create the profile.

  12. Click Finish to close the wizard and start the First Steps console.

  13. Use the First Steps console to verify the installation, start the server, and access the dmgr console.

  14. Log in to the console, if you disabled the security login without providing credentials.

  15. In the console, the following items are visible from the dmgr console:

    Deployment manager System administration | Deployment manager
    Deployment manager node System administration | Nodes
    The default node group System administration | Node groups
    Cell information System administration | Cell | Local Topology

    We can see a similar topology. Notice, that at completion of this process, we do not have any nodes or application servers in the cell.


Create a cell profile

Using this option, you create two distinct profiles: a deployment manager profile and an application server profile federated to the new cell. The Profile Management Tool windows give you basically the same options that you see if you create a deployment manager and then an application server.

Cell profile creation paths...

Typical Advanced
The dmgr console and default application are deployed by default. You have the option to deploy the dmgr console (recommended), the default application, and the sample applications (if installed).
The profile name for the deployment manager is Dmgrxx by default, where xx is 01 for the first deployment manager profile and increments for each one created. The profile is stored in PROFILE_ROOT/Dmgrxx. We can specify the profile name and its location.
The profile name for the federated application server and node is AppSrvxx by default, where xx is 01 for the first application server profile and increments for each one created. The profile is stored in PROFILE_ROOT/AppSrvxx. We can specify the profile name and its location.
Neither profile is made the default profile. Choose to make the deployment manager profile the default profile.
The cell name is <host>Cellxx. The node name for the deployment manager is <host>CellManagerxx. The node name for the application server is <host>Nodexx. We can specify the cell name, the host name, and the profile names for both profiles.
We can enable administrative security (yes or no). If you select yes, you are asked to specify a user name and password given administrative authority.
TCP/IP ports default to a set of ports not used by any profiles in this WebSphere installation instance. We can use the recommended ports for each profile (unique to the installation), There are three different configurations for deployment manager, application server, and node agent.
If installing on Windows, the deployment manager runs as a service. If installing on Windows or Linux, we can choose whether the deployment manager runs as a service.
Does not create a web server definition. Allows you to define an external web server to the configuration.


Create a custom profile

A custom profile defines an empty node on a system. The purpose of this profile is to define a node to be federated to a cell for management through a deployment manager.

As you create the profile, we have the option to federate the node to a cell during the wizard or to simply create the profile for later federation. Before we can federate the custom profile to a cell, have a running deployment manager.

With other profiles, we have the option of registering the processes as Windows or Linux services. This option is not available when you create a custom profile.

To create the custom profile:

  1. Start the WebSphere Customization Toolbox, and open Profile Management Tool.

  2. Click Create.

  3. Select Custom profile.

  4. Select whether to take a typical or advanced path to install the profile:

  5. Enter a unique name for the profile or accept the default. The profile name becomes the directory name for the profile files. If you enable the Make this profile the default check box, this profile receives console commands by default. Click Next.

  6. Enter the node and host names. The defaults are based on the host name of your system.

    The wizard recognizes if there are existing cells and nodes in the installation and takes this setup into account when creating the default names. Click Next.

  7. We will federate the nodes later, so we can enable the check box...

      Federate this node later check box

    If you choose to federate the node during the custom profile installation, enter the host name, SOAP port, user ID, and password of the administrator defined for the deployment manager profile. The wizard uses this information to attempt a connection to the deployment manager. If you entered any of these values incorrectly, an error is displayed and you will have to correct the values.

    To federate the node, the network deployment profile has to be up and running.

  8. The next two screens guide you through certificate generation.

  9. Review the options you provided for the new profile, and click Create to create the profile.

  10. Disable the Launch the First steps console check box, and click Finish.

Custom profiles do not create a server process, so we cannot verify, stop, or start this profile. The only reason to launch the First Steps menu is to link to the information center or launch the migration wizard.

If you choose to federate the node to the deployment manager during the installation, you might want to check if it is available from the deployment manager console by accessing the cell local topology, and continue by defining an application server on the new node


Federating nodes to a cell

A custom profile defines a node that can be added to a cell using the addNode command. A stand-alone application server can also be federated to a cell with the addNode command or from the deployment manager dmgr console (the dmgr console invokes the addNode command on the target system).

When you federate a node, the node name from the federated node is used as the new node name and must be unique in the cell. If the name of the node that you are federating already exists, the addNode operation fails.


Use the addnode command

The addNode command is run from the INSTALL_ROOT/bin or PROFILE_HOME/bin directory of the profile to be federated.

The most important addNode command parameters are:

If you are federating an application server, we can keep any applications or service integration buses deployed to the server. The default behavior is not to include any of these resources during federation, so they will be lost.

The addNode command performs the following actions:

  1. Connects to the deployment manager process. This action is necessary for the file transfers performed to and from the deployment manager to add the node to the cell.
  2. Attempts to stop all running application servers on the node.
  3. Backs up the current stand-alone node configuration to the PROFILE_HOME/config/backup/base/ directory.
  4. Copies the stand-alone node configuration to a new cell structure that matches the deployment manager structure at the cell level.
  5. Creates a new local config directory and definition (server.xml) for the node agent.

  6. Creates entries (directories and files) in the master repository for the new node's managed servers, node agent, and application servers.

  7. Uses the FileTransfer service to copy files from the new node to the master repository.
  8. Uploads application or service bus resources to the cell only if the includeapps or includebuses options are specified.
  9. Performs the first file synchronization for the new node. This action synchronizes data from the cell to the new node.
  10. Corrects the node's setupCmdLine and wsadmin scripts to reflect the new cell environment settings.
  11. Launches the node agent (unless noagent is specified).

We can trace this procedure by viewing the federation logs.


Federating a custom node to a cell

You only have to do this action if you created a custom profile and chose not to federate it at the time.

To federate the custom node to the cell:

  1. Ensure the deployment manager is up and running. If it is stopped, start it.

  2. Go to the PROFILE_HOME/bin directory on the system where you created the custom profile for the new node.

  3. Run the addNode command, providing your information about the deployment manager.

    If administrative security is enabled, use the username and password arguments on the command line to provide the deployment manager user ID and password. If we do not provide the arguments, you are prompted for them.

    Federating node to a deployment manager cell using addNode command... 

    ./addNode.sh was85.ral.ibm.com 8879 -username wasadmin -password passw0rd -includeapps
ADMU0116I: Tool information is being logged in file /IBM/WAS/AppServer/profiles\Custom01\logs\addNode.log
ADMU0128I: Starting tool with the Custom01 profile CWPKI0308I: Adding signer alias "CN=was85.ral.ibm.com, OU=Root C" to local keystore "ClientDefaultTrustStore" with the following SHA digest:
B8:3A:87:41:57:53:73:FB:B5:B3:8A:30:68:83:55:ED:06:12:BF:EB
CWPKI0309I: All signers from remote keystore already exist in local keystore.
ADMU0001I: Begin federation of node was85Node01 with Deployment Manager at was85.ral.ibm.com:8879.  
ADMU0009I: Successfully connected to Deployment Manager Server: was85.ral.ibm.com:8879 
ADMU0507I: No servers found in configuration under: /WAS/AppServer/profiles/Custom01/config/cells/Node02Cell/nodes/Node01/servers 
ADMU2010I: Stopping all server processes for node was85Node01 
ADMU0024I: Deleting the old backup directory.  
ADMU0015I: Backing up the original cell repository.  
ADMU0012I: Creating Node Agent configuration for node: was85Node01 
ADMU0014I: Adding node was85Node01 configuration to cell: was85Cell01 
ADMU0016I: Synchronizing configuration between node and cell.  
ADMU0018I: Launching Node Agent process for node: was85Node01 
ADMU0020I: Reading configuration for Node Agent process: nodeagent 
ADMU0022I: Node Agent launched. Waiting for initialization status.  
ADMU0030I: Node Agent initialization completed successfully. Process id is: 1752 
ADMU0505I: Servers found in configuration: 
ADMU0506I: Server name: nodeagent 
ADMU0308I: The node was85Node01 and associated applications were successfully added to the was85Cell01 cell.  
ADMU0306I: Note: 
ADMU0302I: Any cell-level documents from the standalone was85Cell01 configuration have not been migrated to the new cell.  
ADMU0307I: You might want to: 
ADMU0303I: Update the configuration on the was85Cell01 Deployment Manager with values from the old cell-level documents.  
ADMU0003I: Node was85Node01 has been successfully federated.  /IBM/WAS/AppServer/profiles\Custom01\bin$

  4. Open the deployment manager dmgr console, and view the new node and node agent details:

    • System Administration | Nodes
    • System Administration | Node agents are visible
    • System administration | Cell | Local Topology

    The new custom profile federated to the cell as a new node

The node is started as a result of the federation process. If it does not appear to be started in the console, we can check the status from a command window on the node system:

If you find that it is not started, start it using the startNode command from its PROFILE_HOME\bin directory:

If despite the successful addNode command usage, we do not see any new nodes in the deployment manager console, log out and log in to the console again. This forces the deployment manager GUI to pick the new changes to view them.

Be aware the custom profile does not automatically give you an application server.


Federating an application server profile to a cell

To federate an application server profile to a cell:

  1. Ensure that both the target application server and the deployment manager are running.

  2. Open the deployment manager dmgr console, and log in with administrative privileges.

  3. Click...

      System Administration | Nodes | Add Node | Managed node | Next

  4. Enter the information about the environment, and click OK.

    Choose the method to connect to the application server from the deployment manager. Consider using the default SOAP method if possible. Using the RMI method is also available but deprecated in WAS V8.5. Use the JSR160RMI connection type instead, to stick to RMI.

    Notice that if the application server profile is secured, provide credentials for both the application server and the deployment manager.

    To keep the applications you installed on the application profile, select the check box...

      Include applications


Federating the application profile using the deployment manager console

If the node you are adding runs on a Windows machine, we can register the new node agent to run as a Windows service. Click OK to start the profile federation.

The federation process is similar to the process. We can observe the state of this operation in the console window.

When the process completes:

After successful federation, check the new cell member in the local cell topology in the deployment manager console.


Create a job manager profile

To create the job manager profile:

  1. Start the WebSphere Customization Toolbox, and open Profile Management Tool.

  2. Click...

      Create | Management | Next | Job manager | Next

  3. Select whether to take a typical or advanced path to install the profile:

  4. Select the option to deploy the dmgr console (the default), and click Next.

  5. Enter a unique name for the profile or accept the default. The profile name becomes the directory name for the profile files.

  6. Enter the node and host name. The defaults are based on the host name of your system.

  7. Choose whether to enable administrative security.

  8. The next two screens guide you through certificate generation.

  9. Configure TCP/IP ports for the server.

  10. If you install the server on Windows or Linux, configure the server to run as a service.

  11. Review the options you provided for the new profile, and click Create to create the profile.

  12. Click Finish to close the wizard and start the First Steps application.

  13. Use the First Steps console to verify the installation, start the server, and access the dmgr console.

  14. Log in to the console, if you disabled the security login without providing credentials.

  15. Click...

      System Administration | Job manager

Job manager can send jobs to remote machines to remotely install or configure profiles. We can view the list of its targets by clicking...

After initial creation of the job manager profile, the list is empty.


Create an administrative agent profile

To create the administrative agent profile:

  1. Start the WebSphere Customization Toolbox and open Profile Management Tool.

  2. Click...

      Create | Management | Administrative agent

    The rest of the administrative agent profile installation is the same as the installation for the job manager profile.

  3. Click...

      System Administration | Administrative agent

Nodes that are registered to the administrative agent can be viewed by clicking the Nodes link under Managed nodes. After initial creation of the administrative agent, the list will be empty.


Registering nodes to an administrative agent

The administrative agent profile provides a single interface to manage unfederated application server nodes (stand-alone application server profiles).

The administrative agent and application servers must be on the same machine or sysplex.

The administrative agent must be started before running the registerNode command.

We can only run the command on an unfederated stand-alone application server. When you run the command, the node for the stand-alone server is converted into a node the administrative agent manages.

To register a node with an administrative agent, use the registerNode command.

Registering a stand-alone application server to an administrative agent 

$ cd /WAS/AppServer/profiles/AdminAgent01/bin
$ registerNode.bat -profileName AdminAgent01 
                   -host was85.ral.ibm.com 
                   -profilePath "/IBM/WAS/AppServer/profiles\AppSrv02" 
                   -connType SOAP 
                   -port 8877 
                   -username aaadmin 
                   -password aapassw0rd 
                   -nodeusername wasadmin 
                   -nodepassword passw0rd

ADMU0116I: Tool information is being logged in file /IBM/WAS/AppServer/profiles\AdminAgent01\logs\registerNode.log
[...]
/IBM/WAS/AppServer/profiles\AppSrv02 has been successfully registered.

After registering a new server to the administrative agent, log in to the administrative agent console to manage the server. Notice that now we can select which server to administrator, the administrative agent, or the new stand-alone profile.

If you select the new server, provide its credentials to log in. Go to...

Notice that from this console we can do additional operations to the profile, such as starting the server. There is no such option in standard stand-alone console.

After registering the stand-alone application server it no longer provides the build-in management console. If you try to access the console using the server's administrative port, notice the management console is no longer available.

A stand-alone server can be federated to a deployment manager cell or registered to administrative agent. We cannot do both operations on the same stand-alone server.


Deregistering a node from the administrative agent

To deregister a node from the administrative agent... 

deregisterNode.bat -connType SOAP 
                   -port 8877 
                   -profilePath "/IBM/WAS/AppServer/profiles\AppSrv02" 
                   -username wasadmin 
                   -password passw0rd


Registering administrative nodes with a job manager

The Job manager profile provides a single administrative interface for managing other WebSphere profiles. In this section, we register both the administrative agent and deployment manager profiles to a job manager.


Registering administrative agents

To register administrative agents with a job manager:

  1. Log on to the administrative agent node.

  2. Click...

    Select which node will be registered with the job manager

  3. Enter the information required to connect to the job manager, including the host name, port, user ID, and password. Click OK.

    If the node name you are registering is already in use by the job manager, we can enter an alias for the node.

To view the newly registered node, log in to the job manager console, and click...

This action lists the nodes and deployment managers that are registered with the job manager.

To register a deployment manager node with a job manager:

  1. Log in to the deployment manager dmgr console, and click...

  2. Click Register with Job Manager.

  3. Enter the information required to connect to the job manager, including the host name, port, user ID, and password. Click OK.

    If the node name you are registering is already in use by the job manager, we can enter an alias for the node.

To view the newly registered deployment manager, log in to the job manager console, and click...

This action lists the nodes and deployment managers that are registered with the job manager.