IBM WebSphere Developer Technical Journal: System management for WebSphere Application Server V6 -- Part 3

Easier system management with profiles

The new concept of profiles makes managing managing IBM®WebSphere® Application Server easier, as shown in the third in a series of articles covering the significant system management functionality enhancements in WebSphere Application Server V6.

Qinhua Wang (, Senior Software Engineer, IBM

Qinhua Wang is a senior software engineer with IBM working in the WebSphere Application Server development organization in Austin, Texas. She has been one of the leading developers on the WebSphere system administration team since WebSphere Application Server Version 3.5. The main focus of her work is WebSphere configuration.

Leigh Williamson (, WebSphere System Management Architect, IBM

Leigh Williamson is a Senior Technical Staff Member software engineer at the IBM Software Development Lab in Austin, Texas. As System Management Architect for WebSphere Application Server, he currently leads the evolution of WebSphere product management capabilities.

11 May 2005

Also available in Chinese


IBM WebSphere Application Server V6 contains many significant enhancements in system management functionality over the previous release, Version 5. This article series explores the evolution of the product in this area, with each installment focusing on the details related to a specific feature. The articles in this series so far include:

with additional chapters on the way.

What is a profile?

WebSphere Application Server V6 introduces the concept of profiles to physically separate product binaries from user data, and to enable users to define multiple sets of user data.

Prior to Version 6 of WebSphere Application Server, both product binaries and user data were located under the WebSphere installation directory:

  • WebSphere Application Server product binaries are read by the end user processes, but never modified by them.
    Binaries are modified only by product maintenance updates, such as fix packs and ifixes, and by the installation of other products that extend the WebSphere platform (which could be considered a type of product maintenance, as well).
  • User data is owned and writeable by an end user.
    Typically, user data includes -- but is not limited to -- configuration files, deployed applications, log files, temporary work space, and so on.

Before, the product installation program used to lay down the product binaries and a default WebSphere configuration under the install directory, and then users could use the various system management tools provided by the product to customize the configuration and deploy their applications. In other words, product binaries and user data were mixed together and only one set of user data could be defined through a particular WebSphere installation.

The concept of profiles, on the other hand, captures a set of user data on the disk as well as its associated run time execution environment: a WebSphere Application Server V6 profile is made up of the file set that is owned and writeable by an end user and the processes that execute under that end user's identity.

On UNIX® and Linux® systems, all files and directories in the created profile have the same group and owner permissions as the user who executed the utility to create the profile. One way to think about the WebSphere profile is to consider it as the "user data partition," the equivalent of the user's home directory in UNIX/Linux operating system environments.

The WebSphere Application Server V6 product installation program places the files it creates into one of two separate environments: the product binaries are installed in one location, then an initial profile is created in a separate, end user-configurable location. Users can create additional profiles post installation. All profiles created by the same WebSphere Application Server installation share the same product binaries, which they cannot modify.

How do V6 profiles relate to V5 instances?

If you used the wsinstance utility before, the profile concept might sound familiar to you. The wsinstance utility, introduced in WebSphere Application Server V5.1, enables users to create multiple configuration instances of one installation of the product. The profile feature is an extension, enhancement, and replacement of that capability.

Despite the surface similarities between the two features, there are important differences:

  1. Version 6 does not support an initial default configuration mixed in with the product binary directories. All operational environments in WebSphere Application Server V6 are represented by profiles, and the initial profile is created using the same logic as all subsequent profiles.
  2. In Version 5, the initial product installation produced several directories: a config directory immediately under the install root directory, logs and tranlog directories, temp and wstemp directories, and what was basically the first user area, which acted as peer directories to the lib, java, bin, and classes directories that held product binaries. Though logical, this structure presented challenges for users when creating a read-only file system that held their system files, while at the same time maintaining the ability to read and write these files used by both their configuration and by the product run time. Version 6 provides a distinct separation between product binary files and all instances of user data, all of which is encapsulated in one or more profiles.
  3. The profile feature offers a profile management tool that is integrated with all other system management tools, making it a more mature and complete implementation than the wsinstance utility.

Create your first profile

Creating your first profile at another time
If you choose not to create your first profile at product installation time, you may launch the PCT tool directly after product is installed. The tool is located in the <WAS_INSTALL_DIRECTORY>/bin/ProfileCreator directory, and is an executable file named as pct<platform>; for example, on Windows® the executable file would be called pctwindows.exe. This is also the convention you would use to create multiple profiles.

As mentioned above, the WebSphere Application Server installation program places all the product binary files under the installation directory that the user specifies. The install program then launches a GUI profile creation tool (PCT) that creates the initial profile. The PCT wizard shall will guide you through the creation of your first profile.

Figure 1 shows a screen shot of the PCT tool, which prompts for the name of the profile, the directory of where the profile will be stored, the node name, the host name, and other information. The tool also provides a set of default ports for the profile, which you can modify if necessary; the default ports will not assign those already in use by WebSphere Application Server on the same machine, thereby avoiding any port conflicts. However, the tool does not look at ports used by services outside of WebSphere Application Server.

Figure 1. Profile creation tool
Figure 1. Profile creation tool

By default, the created profile is stored in the <WAS_INSTALL_DIRECTORY>/profiles/<PROFILE_NAME> directory. You can, however, specify a custom profile location when prompted by the PCT. The location you choose can be anywhere in the file system, provided the end user has sufficient permission to create directories and files in that location.

If you are using WebSphere Application Server Network Deployment (ND), you will also be prompted to select one of three predefined profile types, two of which are applicable only in an ND environment. (We will describe later how to use these three profile types to set up an ND environment.)

Profile typeDefinition
Application ServerDefines a standalone application server environment used by WebSphere Application Server, WebSphere Application Server - Express, and WebSphere Application Server Network Deployment. This profile contains one default application server definition.
Deployment managerDefines a deployment manager environment. This profile tyoe contains a default deployment manager definition, and is only available for WebSphere Application Server ND..
CustomDefines an empty managed node containing no application server definition. At profile creation time, the profile creation tool also gives you the option to automatically federate the created custom profile to a deployment manager as a managed node, so that users can add resources and customized server definitions on the node.

Use your WebSphere profile

To use the profile you created above, you need to invoke commands provided in the <PROFILE_DIRECTORY>/bin directory. The commands in that directory have the same names as the commands in the <WAS_INSTALL_DIRECTORY>/bin directory. If you used WebSphere Application Server V5 products before, these commands will be familiar to you. You can use the commands under <PROFILE_DIRECTORY>/bin directory the same way you did before -- the only difference is that these commands only operate on this particular profile. For instance, to start an application server defined by this profile on Windows, you can use the startServer command:

<PROFILE_DIRECTORY>\bin\startServer.bat server1

Similarly, if you want to stop the server just started, you can use the stopServer command:

<PROFILE_DIRECTORY>\bin\stopServer.bat server1

(See the WebSphere Application Server Information Center for more details on these commands.)

With the server launched, and your applications installed on the server through the admin console, you may now be wondering where the log files and the installed applications are. To answer these questions, let's examine the directory structure of the profile: under the profile directory you should also see a list of subdirectories other than the bin subdirectory. This table details these subdirectories and their contents:

binThe set of commands that can be operated on the created profiles. These commands have the same names as the commands under the <WAS_INSTALL_DIRECTORY>/bin directory but they only operate on this profile.
configA set of configuration documents for WebSphere Application Server processes that execute under this profile. If the profile is a deployment manager profile, it contains the configuration documents for the entire cell, which may include the configurations of other profiles that are federated to this deployment manager.
databasesCloudscape® databases.
etcKey files and certificates (at least the initial set that is shipped with the product).
installableApps The default location of installable applications.
installedApps Installed and expanded application binaries.
installedConnectors Installed JCA Resource Adapter libraries.
logsLog files of all varieties such as SystemOut.log, tranlog, FFDC, activity.log, and so on.
propertiesVarious property files, including the same set of property files seen in Version 5, but these property files will only apply to the current profile.
tempTemporary working directories.
tranlogDefault transaction log directory.
wstempTemporary work space for configuration modification. As in Version 5, the configuration changes on a profile are made in a temporary work space before users decide to save the configuration change to the config repository. This directory holds the temporary configuration changes made on the current profile before they are saved.

These subdirectories capture the entire contents of the profile instance. When an end user launches any command defined under the bin directory of a profile, the launched process shall only modify the user data of this profile, and should not change any product binaries or user data in the other profile instances.

Set up a Network Deployment environment with profiles

In WebSphere Application Server V5, you needed to perform multiple steps to set up a Network Deployment environment. For the sake of comparison, those general steps were:

  1. Set up the deployment manager, which is done through installing the WebSphere Application Server ND product.
  2. Start the deployment manager.
  3. Set up a node, which is done by installing a WebSphere Application Server product on the same or a different host. When the node is on the same host, the installation directory has to be different from that of the deployment manager, since they are two different product installations. In other words, the deployment manager and the node cannot share the same product binaries even though they are mostly the same.
  4. Federate the node into the deployment manager using the addNode command. This step sets up a basic ND environment, and is the task that makes the node a part of the ND environment.
  5. After this is done, you can add additional nodes by repeating steps 3 and 4, customizing the configuration, and deploying applications into the Network Deployment environment.

In WebSphere Application Server V6, the basic steps to set up an ND environment are the same, but more efficient and easier to perform with profile support. To set up the deployment manager, you install WebSphere Application Server ND as before. Then:

  1. Launch the PCT tool as described previously.
  2. Select a profile type on the first step of the PCT wizard. Choose a deployment manager profile type, then go through the rest of steps as before.
  3. Make note of the ports that this deployment manager profile uses, because you will need the port number later when you add nodes to this deployment manager. Since you are creating a new profile, the information in the previous section applies here as well.
  4. To start the created deployment manager, go to the <DMGR_PROFILE_DIRECTORY>/bin subdirectory and use the startManager command. For example, on Windows, you would execute the command:


In Version 5, WebSphere Application Server ND created only the deployment manager, whereas WebSphere Application Server Base or Express created a node. In Version 6, ND can create both a deployment manager and an application server, eliminating the need for more than one installation program. In Version 6, you can also create multiple instances of the same profile type (or different profile types) using the same product installation, enabling you to share product binaries between the deployment manager node and other nodes, should you want to. With these points in mind, the cheapest way to set up a node is to launch the PCT tool again and create an application server profile with the application server profile type, then use the same addNode command to federate the new node to the deployment manager profile.

One thing to be careful of is that you need to invoke the addNode command under the bin directory of the node profile, like <NODE_PROFILE_DIRECTORY>\bin\addNode.bat. If you use the command under the <INSTALL_DIRECTORY>/bin directory, the result might surprise you. Next, we will explain how to invoke the command under the <INSTALL_DIRECTORY>/bin directory properly when there are multiple profiles under the same installation directory.

You can also set up the node in another product installation if you would rather not share the product binaries between the node and deployment manager, or if you need to add a node from another host. You just need to install WebSphere Application Server ND first, then follow the steps above for Version 6.

The custom profile type is very similar with the application server profile type, except that it does not contain any server definition. Therefore, this type of profile cannot be used standalone and should be federated into an ND cell after creation.

Make your profile the default profile

By now you should be able to set up a single server and an ND environment and feel relatively comfortable with the idea of profiles. However, if you only create one profile under a particular installation directory most of time and don't want to go to the extra directory levels to invoke commands, you might want to know about the idea of the default profile

You can mark a profile as the default profile under an installation directory at profile creation time, as you can see in Figure 1. What this means is that when you invoke commands under <INSTALL_DIRECTORY>/bin, they will implicitly operate on the profile you defined as the default. This is largely just a convenience so you can invoke commands more easily; all the user data for the profile is still stored under the profile directory.

However, it is not a good idea to use the default profile notion when there are multiple profiles under the same installation directory, even if the idea of a default profile still applies. The reason is because there can only be one default profile in the entire product installation. If you mark a second profile elsewhere as the default, then the previous default profile is overridden, losing that setting. Tracking which profile is the default can cause confusion when multiple profiles are around.

Using multiple profiles

If you frequently switch between multiple profiles under the same product installation, you may get tired of changing the current working directory from the bin directory of one profile location to another. If so, you will be happy to know that you can invoke the commands under <INSTALLATION_DIRECTORY>/bin and explicitly specify the profile they operate on through the profileName option.

For example, if you want to start the server defined under profile myProfile1 and the server defined under profile myProfile2 on Windows, then you can use these commands:

<INSTALLATION_DIRECTORY>\bin\startServer.bat server1 -profileName myProfile1
<INSTALLATION_DIRECTORY>\bin\startServer.bat server1 -profileName myProfile2

Manage your profiles

Besides the GUI PCT wizard, WebSphere Application Server V6 also provides a command line tool for profile management, called wasprofile. Not only can you create additional profiles with the wasprofile utility, but you can also use it to manage multiple profiles under a product installation. This command is located under <INSTALLATION_DIRECTORY>/bin directory, and you will find complete command reference information in the WebSphere Application Server Information Center, which also provides example commands for the various modes and options available. Help options are also available from the command line, as illustrated below:

.\wasprofile.bat -help
The available modes are: create, augment, delete, unaugment,
deleteAll, listProfiles, getName, getPath, validateRegistry,
validateAndUpdateRegistry, help
For detailed help on each mode enter: -<mode> -help. For
example, -create -help.

Command line arguments are case sensitive.

The basic syntax of the wasprofile command is:

.\wasprofile.bat -<mode> -<option> value -<option> value

The first argument is always the mode. Subsequent arguments are mode-specific options and their values. The options are not ordered so you can specified in any sequence. You can get the applicable options for a specific mode and its semantics through the help option, which is supported in every mode. For example, to get detailed options for "create" mode:

.\wasprofile.bat -create -help

Modes that you are likely to use regularly include:

  • create -- creates a profile and is the functional equivalent of the profile creation tool.
  • delete -- deletes a particular profile.
  • deleteAll -- deletes all the profiles under the product installation.
  • listProfiles -- lists all the profiles.
  • getName -- gets the profile name when given a specific profile location.
  • getPath -- the opposite of getName; gets the profile location when given a profile name.

There are other modes, if you are curious:

  1. Internally, WebSphere Application Server uses a registry to keep track of all the profiles under the product installation. Sometimes the registry may end up in an inconsistent state if any execution of wasprofile command fails unexpectedly. This is a very rare occurrence, but if you suspect this has really happened, you can use validateRegistry mode to check if the profile registry is in a consistent state.
  2. If validateRegistry does report any inconsistencies, you can use validateAndUpdateRegistry mode to correct the problem.
  3. Modes you will never use include augment and unaugment, since these are only used by other WebSphere products.

When a wasprofile command is executed, it places log files in the <INSTALL_DIRECTORY>/logs directory, and typically names log files as XXX_<PROFILE_NAME>.log. You will also find additional log files under the <PROFILE_DIRECTORY>/logs directory for commands that are specific to a particular profile.

Replicate your profile configuration

WebSphere Application Server V6 enables you to replicate the configuration among the application server profiles. You can use this capability between two application server profiles under the same or under different product installations, on the same or on different host environments. In general, you can also use this capability to replicate a profile configuration across different platforms -- as long as you do not add OS-specific system properties to your configuration. An exception to this is that configurations of z/OS and distributed platform profiles are not compatible, and thus you cannot replicate configurations between these platforms. Another limitation is that this capability only works with application server profiles, not for ND profiles.

To replicate your profile configuration:

  1. Export your application server profile configuration into a configuration archive using the exportWasprofile command in wsadmin. For example, the command shown below illustrates how to export the configuration of the current profile to configuration archive file c:\work\ in JACL:

    wsadmin>$AdminTask exportWasprofile {-archive c:\work\}
  2. Import this configuration archive into another application server profile using the importWasprofile command in wsadmin. If the target profile does not yet exist, you will need to create it first. To execute importWasprofile, launch the wsadmin that operates on the target profile. For example, if you want to import the configuration to profile myProfile2, use this command to start wsadmin:

    <INSTALL_DIRECTORY>\bin\wsadmin.bat -profileName myProfile2
  3. After wsadmin is launched, execute the importWasprofile command to import the configuration. For example, you can import the configuration archive exported above through this JACL command:

    wsadmin>$AdminTask importWasprofile {-archive c:\work\}

The importWasprofile command replicates the entire configuration of the source profile, which includes both the server configuration and the applications deployed on the server. This command does not merge the configuration in the archive to the target profile. Rather, it replaces the entire configuration of the target profile. The only information it preserves is the information that is specific to the existing target profile, such as installation directory, host name, server name and ports. This command only replicates the WebSphere Application Server configuration. If any of your applications depend on external products beyond WebSphere Application Server (such as database or messaging products), you may need to take additional steps to replicate these environments.

As with other wsadmin scripting commands, exportWasprofile and importWasprofile commands are available in Jython as well. The WebSphere Application Server Information Center has more information regarding AdminTask scripting commands in general, and on these two commands in particular.

Replicate your server configuration

In WebSphere Application Server V6, you can also replicate a customized server configuration (without applications deployed on it) among multiple profiles. Similar to the concept of replicating your profile configuration, you can use this capability between two profiles under the same or different product installations, and on the same or different host environments. In general, you can use this ability to replicate server configurations across different platforms, as long as you do not add OS-specific system properties into your server configuration. An exception to this is, again, that z/OS and distributed platform profiles are not compatible, and thus you cannot replicate server configurations between these platforms.

Despite the resemblance between the two replication capabilities, there are some important distinctions:

  • The server configuration replication capability does not carry over the applications that are deployed on the server when the configuration is replicated.
  • The server configuration replication capability is available for both application server and ND profiles.

To replicate your server configuration:

  1. Export your server configuration to a configuration archive through the exportServer command in wsadmin. For example, the command below illustrates how to export the configuration of the current profile to a configuration archive file c:\work\ in JACL. (When you work on a single server profile, the nodeName and serverName options are not required.)

    Click to see code listing

    wsadmin>$AdminTask exportServer {-nodeName myNode -serverName myServer -archive c:\work\}
  2. Import this configuration archive into another profile using the importServer command in wsadmin. To execute the command, launch the wsadmin that operates on the target profile. For example, if you want to import the configuration of server myServer to profile myProfile2, you can use this command to start wsadmin.

    <INSTALL_DIRECTORY>\bin\wsadmin.bat -profileName myProfile2
  3. When wsadmin is launched, execute the importServer command to import the configuration. For example, you can import the exported server configuration to the node named as anotherNode in profile myProfile2 through the JACL command shown below. If the serverName option is not specified, then the server name in the configuration archive will be used as the name for the imported server.

    Click to see code listing

    wsadmin>$AdminTask importServer {-node anotherNode -serverName myNewServer -archive c:\work\}

The importServer command creates a new server with a customized configuration based on the server configuration defined in the archive. This is different with the importWasprofile command, which overrides the server configuration. While you can execute the exportServer command on both the application server and ND profiles, the importServer is only available in an ND profile, since creating a new server is not a function for the application server profile.

Again, as with other wsadmin scripting commands, these commands are also available in Jython. See the WebSphere Application Server Information Center for more information.


WebSphere Application Server V6 introduced the concept of profiles to physically separate product binaries and user data; a profile consists of a set of user data and its run time execution environment. This article explained how to create, use, and manage profiles in both base application server and Network Deployment (ND) environments, and also described the mechanisms for replicating configurations across profiles. While the concept of a profile is new in Version 6 and may present something of a learning curve for users, profiles enable users to use WebSphere products more efficiently and with more flexibility, and also make it easier and cheaper to set up an ND environment. This article attempts to help you overcome the learning curve so you can explore the profile features and implement them in your environment more quickly.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=IBM WebSphere Developer Technical Journal: System management for WebSphere Application Server V6 -- Part 3