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 will 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.

At a minimum, the only options that are required to create a node profile are -create, -serverType, and -profileName.

~]# /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh  
-create 
-profileName Node01

AVOID TROUBLE

If you are going to be federating the application server profile into a WebSphere deployment manager (dmgr), the cellName of the application server profile must be different than the cell name of the WebSphere deployment manager. When the application server profile is federated into the WebSphere deployment manager, the cell name of the application server profile will be updated to be the same as the WebSphere deployment manager cell name.

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

If you don't include the -cellName option, the cell name will be the hostname of your server followed by Node01Cell1, such as wasNode01Cell1.

If you don't include the -nodeName option, the node name will be the hostname of your server followed by Node01, such as wasNode01.

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

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.

If you will be creating two or more profiles on the same application server, you will want to use the -portsFile or -startingPort option. 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 -portsFile option, you would specify the path to the files that contains the ports you want to use. If using the -startingPort option, you would specify a value, such as 20000.

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

INSTCONFSUCCESS: Success: Profile your_profile_name now exists.

If you didn't include the -profilePath option, the profile will be created in the was_home/profiles directory.

~]# ls ${WAS_INSTALL_ROOT}/profiles
Node01

And the manageprofiles.sh -listProfiles command should list the profile.

~]# ${WAS_INSTALL_ROOT}/bin/manageprofiles.sh -listProfiles
[Node01]

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