Bootstrap FreeKB - IBM WebSphere - Create profile using the manageprofiles create command
IBM WebSphere - Create profile using the manageprofiles create command

Updated:   |  IBM WebSphere articles

If you are not sure what a cell, profile, node, application server, dmgr are, check out my article WebSphere terms (cell, profile, node, application server, dmgr).

The (Linux) or manageprofiles.bat (Windows) script can be used to create a profle. In fact, the manageprofiles script can be used to do a number of different things.

When possible, it is usually best to create a profile as root (Linux) or administrator (Windows). If you must create a profile as a non-root or non-administrator, then you may need to perform additional file permission and ownership changes, such as making the non-root or non-administrator user the owner of files that make up the profile.

Before you can create a profile, you must install the websphere package such as

At a minimum, the only options that are required to create a profile are -create and -profileName. If you are going to have two or more profiles on the same application server, each profile name must be unique.

${WAS_INSTALL_ROOT}/bin/ -create -profileName AppSrv01


When creating a profile, there will be different types of profiles that can be created, such as an application server profile, a management profile, et cetera. The -templatePath option is used to choose the type of profile. If you do not include the -templatePath option, the default template will be used. In this example, a management profile will be created. In other words, which will create a deployment manager (dmgr) profile.

${WAS_INSTALL_ROOT}/bin/ -create -profileName Dmgr01 -templatePath ${WAS_INSTALL_ROOT}/profileTemplates/management


If you don't include the -profilePath option, the profile will be created in the ${WAS_INSTALL_ROOT}/profiles directory.

If you don't include the -cellName option, the cell name will be the hostname of your server followed by Node01Cell1. For example, if the hostname of your server is wasServer1, then the cell name will be wasServer1Node01Cell1.

If you don't include the -nodeName option, the node name will be the hostname of your server followed by Node01. For example, if the hostname of your server is wasServer1, then the node name will be wasServer1Node01.

If you don't include the -serverName option, the server name will be server1.

If you do not include the -hostName option, the hostname will be hostname of the Linux or Windows Operating System.

If you don't include the -isDefault option, the profile will not be identified as the default profile. Certain scripts will do a change to the default profile when the -profileName option is not used in the script.

If you don't include the -enableAdminSecurity-adminUserName, and -adminPassword options, administrative security will be disabled. Administrative security can be configured after the profile has been created. If these options are used, administrative security will be enabled with a federated repository.

-profileName AppSrv01
-enableAdminSecurity true
-adminUserName john.doe
-adminPassword itsasecret


Optionally,  the -portsFile or -startingPort option can be used. You may also want to include the -validatePorts option. You wouldn't want to use the -defaultPorts option, as this would configure the profile to use the default ports, such as port 9060 for the web console. You would never use a combination of -portsFile, -startingPort, or -defaultPorts. Instead, you would use only one of these options. If using the -startingPort option, you would specify a value, such as 20000.

For example, let's say /tmp/portdev.props contains the following.



You could include the -portsFile option when creating the profile.

-profileName Dmgr01 
-templatePath ${WAS_INSTALL_ROOT}/profileTemplates/management
-enableAdminSecurity true
-adminUserName john.doe
-adminPassword itsasecret
-portsFile /tmp/portdef.props


If creating two profiles on two different servers that will be part of a cluster, give the first profile a node name such as node01 and give the second profile a node name such as node02. This is necessary so that when you are creating the cluster, you can select node01 and node02. The server name will typically be the same on both nodes.


If the profile was successfully created, the following output should be displayed.

INSTCONFSUCCESS: Success: Profile your_profile_name now exists.


The profile will now exist at /opt/IBM/WebSphere/AppServer/profiles. You could also list the profile with the -listProfiles option.

~]# ls ${WAS_INSTALL_ROOT}/profiles


And the -listProfiles command should list the profile.

~]# ${WAS_INSTALL_ROOT}/bin/ -listProfiles


You can now start the application server or start the deployment manager and then access the web browser console.


Did you find this article helpful?

If so, consider buying me a coffee over at Buy Me A Coffee


Add a Comment

Please enter d3ad77 in the box below so that we can be sure you are a human.