manageprofiles command

1. Overview
2. Syntax
3. Options
4. Scenarios
5. Logs
6. Create a deployment manager profile
7. Create a cell profile
8. Use predefined port numbers
9. Increment default port numbers from a starting point

Overview

Use the manageprofiles command to create, delete, augment, back up, and restore profiles, which define runtime environments. Using profiles instead of multiple product installations saves disk space and simplifies updating the product because a single set of core product files is maintained. The manageprofiles command and its graphical user interface, the Profile Management Tool, are the only ways to create runtime environments.

app_server_root/bin/manageprofiles.sh

If we run manageprofiles with a managed profile template, application servers are not created, however, ports are still used if we are federating a node. The default behavior for manageprofiles is to create files with permissions of 755, ignoring the system wide umask. To modify these permissions, use the chmod command each time you pass the profile from one user to another.

Syntax

-create	Create a profile
-delete	Delete a profile
-augment	Augment a profile
-unaugment	Unaugment a profile
-unaugmentAll	Unaugment all profiles augmented with a specific augmentation template
-deleteAll	Delete all profiles
-listProfiles	List all profiles
-listAugments	List augments for a profile
-getName	Get a profile name
-getPath	Get a profile path
-validateRegistry	Validate a profile registry
-validateAndUpdateRegistry	Validate and update a profile registry
-getDefaultName	Get the default profile name
-backupProfile	Back up a profile
-restoreProfile	Restore a profile
-response	Perform manageprofiles command tasks contained in a response file

For detailed help including the required parameters for each of the tasks accomplished with the manageprofiles command, use the -help parameter. The following example uses the help parameter with the manageprofiles -augment command...

$APPSERVER_ROOT/bin/manageprofiles -augment -help

Depending on the operation to perform with the manageprofiles command, provide one or more of the following parameters. The command-line tool validates that the required parameters are provided and the values entered for those parameters are valid. Be sure to type the name of the parameters with the correct upper and lower case as the command-line tool does not validate the case of the parameter name. Incorrect results can occur when the parameter case is not typed correctly.

app_server_root/bin/manageprofiles.sh -create \
-profileName profile \
-profilePath /path/to/profile \
-templatePath /path/to/template

Options

-adminPassword adminPassword

Password for the administrative security user ID specified with the -adminUserName parameter.




-adminUserName adminUser_ID

User ID used for administrative security.




-applyPerfTuningSetting option

Performance-tuning setting that most closely matches the type of environment in which the application server will run. Only valid for the default profile template.

standard	The standard settings are the standard out-of-the-box default configuration settings that are optimized for general-purpose usage.
peak	The peak performance settings are optimized for a production environment where application changes are rare and optimal runtime performance is important.
development	The development settings are optimized for a development environment where frequent application updates are performed and system resources are at a minimum. not use the development settings for production servers.

If we do not specify an option with the -applyPerfTuningSetting parameter, the default value is standard. If we specify both the -isDeveloperServer and -applyPerfTuningSetting parameters, depending on the option selected for -applyPerfTuningSetting, -applyPerfTuningSetting might override -isDeveloperServer.




-appServerNodeName application_server_node

Node name of the application server that we are federating into the cell. Specify this parameter when we create the deployment manager portion of the cell and when we create the application server portion of the cell.




-augment

Use the augment parameter to make changes to an existing profile with an augmentation template. The augment parameter causes the manageprofiles command to update or augment the profile identified in the -profileName parameter using the template in the -templatePath parameter. The augmentation templates we can use are determined by which IBM products and versions are installed in the environment. Important: The templates that are included with the WebSphere Application Server Network Deployment product can only be used to create profiles and not to augment existing profiles because only create templates are shipped with the product. Also, do not manually modify the files located in the install_dir/ profileTemplates directory. If we are changing the ports during profile creation, for example, use the -startingPort or -portsFile arguments on the manageprofiles command instead of modifying the file in the profile template directory.

manageprofiles.sh -augment -profileName profile -templatePath /path/to/template

We can specify a relative path for the -templatePath parameter if the profile templates are relative to the app_server_root/profileTemplates directory. Otherwise, specify the fully qualified template path. For example:

manageprofiles -augment -profileName profile -templatePath /path/to/template

See also the -unaugment parameter.




-backupFile /path/to/backupfile

Back up the profile registry file to the specified file.




-backupProfile

Perform a file system backup of a profile folder and the profile metadata from the profile registry file. Any servers using the profile to back up must first be stopped prior to invoking the manageprofiles command with the -backupProfile option. The -backupProfile parameter must be used with the -backupFileand -profileName parameters, for example:

manageprofiles.sh -backupProfile -profileName profile -backupFile /path/to/backupfile

When we back up a profile using the -backupProfile option, first stop the server and the running processes for the profile to back up.




-cellName cell (Optional Parameter)

Cell name of the profile. Use a unique cell name for each profile.

Use a unique name even if we plan to federate the custom profile or standalone profile into a deployment manager cell. Federation requires unique cell names before it can make the node part of the deployment manager cell. A cell name must be unique in any circumstance in which the product is running on the same physical machine or cluster of machines, such as a sysplex. Additionally, a cell name must be unique in any circumstance in which network connectivity between entities is required either between the cells or from a client that must communicate with each of the cells. Cell names must also be unique if their namespaces are federated. Otherwise, we might encounter symptoms such as a javax.naming.NameNotFoundException error, in which case, create uniquely named cells.

Optional. If we omit the parameter, a default cell name is assigned. The default value for this parameter is based on a combination of the short host name, the constant cell, and a trailing number:

Profile type	Default value
Application server profile	Not any
Custom profile	Not any
Management profile with the deployment manager server	shortHostNameCellCellNumber
Management profile with the job manager server	shortHostNameJobMgrCellCellNumber
Management profile with the administrative agent server	shortHostNameAACellCellNumber
Cell profile, application server portion	shortHostNameCellCellNumber
Cell profile, deployment manager portion	shortHostNameCellCellNumber
Secure proxy profile	Not any

where CellNumber is a sequential number starting at 01.

The value for this parameter must not contain spaces or any invalid characters that are not valid such as the following: *, ?, ", <, >,,, /, \, |, and so on.




-create

Create the profile.

For help:

manageprofiles -create \
               -/path/to/template \
               -help 

Available templates include:

Profile template	Description
cell	Deployment manager cell (dmgr and default)
management	Management. Use in conjunction with the -serverType parameter to indicate the type of management profile.
secureproxy	Secure proxy
default	Application server
managed	Custom




-debug

Turn on the debug function of the Ant utility, which the manageprofiles command uses.




-personalCertValidityPeriod validity_period (Optional Parameter)

An optional parameter that specifies the amount of time in years that the default personal certificate is valid. If not specified with the -personalCertDN parameter, the default personal certificate is valid for one year.




-defaultPorts

Assign the default or base port values to the profile. During profile creation, the manageprofiles command uses an automatically generated set of recommended ports if we do not specify the -startingPort, -defaultPorts or the -portsFile parameter. The recommended port values can be different than the default port values based on the availability of the default ports. Do not use when using the -startingPort or -portsFile parameter. Do not use this parameter if we are using the managed profile template.




-delete

Delete the profile. Deleting a profile does not delete the profile directory. For example, suppose that we create a profile in...

/usr/WebSphere/AppServer/profiles/managedProfile

The directory remains after you delete the profile. We can delete or leave the directory. However, the profile_root/logs directory contains information about uninstalling the profile. For example, we might retain the _nodeuninst.log file to determine the cause of any problem during the uninstall procedure. If we delete a profile that has augmenting templates registered to it in the profile registry, then unaugment actions are performed automatically. If we are deleting an old node that has been migrated, shut down the new migrated deployment manager before deleting the old node. This will ensure that the new migrated node is not accidentally removed from the new migrated cell.




-deleteAll

Delete all registered profiles. Deleting a profile does not delete the profile directory. For example, suppose that we create a profile in...

/usr/WebSphere/AppServer/profiles/managedProfile

The directory remains after you delete the profile. We can delete or leave the directory. However, the profile_root/logs directory contains information about uninstalling the profile. For example, we might retain the _nodeuninst.log file to determine the cause of any problem during the uninstall procedure. If we delete a profile that has augmenting templates registered to it in the profile registry, then unaugment actions are performed automatically.




-dmgrAdminPassword password

If we are federating a node, specify a valid user name for a deployment manager if administrative security is enabled on the deployment manager. Use this parameter with the -dmgrAdminUserName parameter and the -federateLater parameter.




-dmgrAdminUserName user_name

If we are federating a node, specify a valid password for a deployment manager if administrative security is enabled on the deployment manager. Use this parameter with the -dmgrAdminPassword parameter and the -federateLater parameter.




-dmgrHost dmgr_host_name (Optional Parameter)

Identifies the machine where the deployment manager is running. Specify this parameter and the dmgrPort parameter to federate a custom profile as it is created. The host name can be the long or short DNS name or the IP address of the deployment manager machine. Specify this optional parameter directs the manageprofiles command to attempt to federate the custom node into the deployment manager cell as it creates the custom profile with the managed -templatePath parameter. The -dmgrHost parameter is ignored when creating a deployment manager profile or an Application Server profile.

If we federate a custom node when the deployment manager is not running or is not available because of security being enabled or for other reasons, the installation indicator in the logs is INSTCONFFAIL to indicate a complete failure. The resulting custom profile is unusable. We must move the custom profile directory out of the profile repository (the profiles installation root directory) before creating another custom profile with the same profile name.

If we have enabled security or changed the default JMX connector type, we cannot federate with the manageprofiles command. Use the addNode command instead.

The default value for this parameter is localhost. The value for this parameter must be a properly formed host name and must not contain spaces or characters that are not valid such as the following: *, ?, ", <, >,,, /, \, |, and so on. A connection to the deployment manager must also be available in conjunction with the dmgrPort parameter.




-dmgrPort dmgr_port_number

Identifies the SOAP port of the deployment manager. Specify this parameter and the dmgrHost parameter to federate a custom profile as it is created. The deployment manager must be running and accessible. If we have enabled security or changed the default JMX connector type, we cannot federate with the manageprofiles command. Use the addNode command instead. The default value for this parameter is 8879. The port that you indicate must be a positive integer and a connection to the deployment manager must be available in conjunction with the dmgrHost parameter.




-dmgrProfilePath dmgr_profile_path

Profile path to the deployment manager portion of the cell. Specify this parameter when we create the application server portion of the cell.




-enableAdminSecurity true | false

Enable administrative security. Valid values include true or false. The default is false.

When enableAdminSecurity is set to true, we must also specify the parameters -adminUserName and -adminPassword along with the values for these parameters. We cannot use the -enableAdminSecurity parameter to enable administrative security for a custom profile. For security to be enabled for a custom profile, the custom profile must be federated into a deployment manager. Administrative security enabled for the deployment manager is required to enable security for the federated custom profile.




(Linux) -enableService true | false

(Linux) Enables the creation of a Linux service. Valid values include true or false. The default value for this parameter is false.

When the manageprofiles command is run with the -enableService option set to true, the Linux service is created with the profile when the command is run by the root user. When a non-root user runs the manageprofiles command, the profile is created, but the Linux service is not. The Linux service is not created because the non-root user does not have sufficient permission to set up the service. An INSTCONPARTIALSUCCESS result is displayed at the end of the profile creation and the profile creation log app_server_root/logs/manageprofiles_create_profilename.log contains a message indicating the current user does not have sufficient permission to set up the Linux service.




-federateLater true | false

Indicates if the managed profile will be federated during profile creation or if we will federate it later using the addNode command. If the dmgrHost, dmgrPort, dmgrAdminUserName and dmgrAdminPassword parameters do not have values, the default value for this parameter is true. Valid values include true or false.




-getDefaultName

Return the name of the default profile.




-getPath

Get the file system location for a profile of a given name. Requires the -profileName parameter.




-getName

Get the name for a profile registered at a given -profilePath parameter.




-help

Displays command syntax.




-hostName host_name

Host name where we are creating the profile. This should match the host name specified during installation of the initial product. The default value for this parameter is the long form of the domain name system. The value for this parameter must be a valid IPv6 host name and must not contain spaces or any characters that are not valid such as the following: *, ?, ", <, >,,, /, \, |, and so on.




-ignoreStack (Optional Parameter)

An optional parameter used with the -templatePath parameter to unaugment a particular profile that has been augmented. See the -unaugment parameter.




-importPersonalCertKS keystore_path

Path to the keystore file used to import a personal certificate when we create the profile. The personal certificate is the default personal certificate of the server. When importing a personal certificate as the default personal certificate, import the root certificate that signed the personal certificate. Otherwise, the manageprofiles command adds the public key of the personal certificate to the trust.p12 file and creates a root signing certificate.bprac The -importPersonalCertKS parameter is mutually exclusive with the -personalCertDN parameter. If we do not specifically create or import a personal certificate, one is created by default. When we specify any of the parameters that begin with -importPersonal, specify them all.




-importPersonalCertKSAlias keystore_alias

Alias of the certificate that is in the keystore file specified on the -importPersonalCertKS parameter. The certificate is added to the server default keystore file and is used as the server default personal certificate. When we specify any of the parameters that begin with -importPersonal, specify them all.




-importPersonalCertKSPassword keystore_password

Password of the keystore file specified on the -importPersonalCertKS parameter. When we specify any of the parameters that begin with -importPersonal, specify them all.




-importPersonalCertKSType keystore_type

Type of the keystore file specified on the -importPersonalCertKS parameter. Values might be JCEKS, CMSKS, PKCS12, PKCS11, and JKS. However, this list can change based on the provider in the java.security file. When we specify any of the parameters that begin with -importPersonal, specify them all.




-importSigningCertKS keystore_path

Path to the keystore file used to import a root certificate when we create the profile. The root certificate is the certificate that we use as the server default root certificate. The -importSigningCertKS parameter is mutually exclusive with the -signingCertDN parameter. If we do not specifically create or import a root signing certificate, one is created by default. When we specify any of the parameters that begin with -importSigning, specify them all.




-importSigningCertKSAlias keystore_alias

Alias of the certificate that is in the keystore file specified on the -importSigningCertKS parameter. The certificate is added to the server default root keystore and is used as the server default root certificate. When we specify any of the parameters that begin with -importSigning, specify them all.




-importSigningCertKSPassword keystore_password

Password of the keystore file specified on the -importSigningCertKS parameter. When we specify any of the parameters that begin with -importSigning, specify them all.




-importSigningCertKSType keystore_path

Type of the keystore file specified on the -importSigningCertKS parameter. Valid values might be JCEKS, CMSKS, PKCS12, PKCS11, and JKS. However, this list can change based on the provider in the java.security file. When we specify any of the parameters that begin with -importSigning, specify them all.




-isDefault

That the profile identified by the accompanying -profileName parameter is to be the default profile once it is registered. When issuing commands that address the default profile, it is not necessary to use the -profileName attribute of the command.




-isDeveloperServer

That the server is intended for development purposes only. This parameter is useful when creating profiles to test applications on a nonproduction server before deploying the applications on their production application servers. This parameter is valid only for the default profile template. If we specify both the -isDeveloperServer and -applyPerfTuningSetting parameters, depending on the option selected for -applyPerfTuningSetting, -applyPerfTuningSetting might override -isDeveloperServer.




-keyStorePassword keystore_password

Password to use on all keystore files created during profile creation. Keystore files are created for the default personal certificate and the root signing certificate.




-listAugments

List the registered augments on a profile that is in the profile registry. Specify the -profileName parameter with the -listAugments parameter.




-listProfiles

List the profiles in the profile registry.




-nodeDefaultPorts

Defines a set of ports when creating a profile in conjunction with a cell template. If we specify this option, we cannot specify the -nodePortsFile or nodeStartingPort options at the same time.




-nodeName node

Node name for the node created with the new profile. Use a unique value within the cell or on the machine. Each profile that shares the same set of product binaries must have a unique node name. The default value for this parameter is based on the short host name, profile type, and a trailing number:

Application server profile	shortHostNameNodeNodeNumber
Custom profile	shortHostNameNodeNodeNumber
Management profile with the deployment manager server	shortHostNameCellManagerNodeNumber
Management profile with the job manager server	shortHostNameJobMgrNodeNumber
Management profile with the administrative agent server	shortHostNameAANodeNodeNumber
Cell profile, application server portion	shortHostNameNodeNodeNumber
Cell profile, deployment manager portion	shortHostNameCellManagerNodeNumber
Secure proxy profile	shortHostNameNodeNodeNumber

where NodeNumber is a sequential number starting at 01.

The value for this parameter must not contain spaces or any characters that are not valid such as the following: *, ?, ", <, >,,, /, \, |, and so on.




-nodePortsFile node_ports_path

Specifies ports for the node portion of the cell that we are creating. If we specify this option, we cannot specify the -nodeDefaultPorts or -nodeStartingPort options at the same time.




-nodeProfilePath node_profile_path

Profile path to the node portion of the cell. Specify this parameter when we create the deployment manager portion of the cell.




-omitAction feature1 feature2... featureN (Optional Parameter)

An optional parameter that excludes profile features.

Each profile template comes predefined with certain optional features. The following optional features can be used with the -omitAction parameter for the following profile templates:

• default - application server
  • deployAdminConsole
  • defaultAppDeployAndConfig
  • deployIVTApplication

• management - management profile for the deployment manager, administrative agent, or job manager
  • deployAdminConsole

• cell - deployment manager cell, which is composed of both a dmgr and a default profile template
  • cell_dmgr (dmgr created during cell profile creation)
    • deployAdminConsole
    • defaultAppDeployAndConfig




-personalCertDN distinguished_name

Distinguished name of the personal certificate that we are creating when we create the profile. Specify the distinguished name in quotes. This default personal certificate is located in the server keystore file. The -importPersonalCertKSType parameter is mutually exclusive with the -personalCertDN parameter. See the -personalCertValidityPeriod parameter and the -keyStorePassword parameter.




-portsFile file_path (Optional Parameter)

An optional parameter that specifies the path to a file that defines port settings for the new profile. Do not use this parameter when using the -startingPort or -defaultPorts parameter. During profile creation, the manageprofiles command uses an automatically generated set of recommended ports if we do not specify the -startingPort parameter, the -defaultPorts parameter or the -portsFile parameter. The recommended port values can be different than the default port values based on the availability of the default ports.




-profileName profile

Name of the profile. Use a unique value when creating a profile. Each profile that shares the same set of product binaries must have a unique name. The default profile name is based on the profile type and a trailing number, for example:

<profile_type><profile_number>

where

• <profile_type> is a value such as AppSrv, Dmgr, AdminAgent, JobMgr, or Custom
• <profile_number> is a sequential number that creates a unique profile name

The value for this parameter must not contain spaces or characters that are not valid such as any of the following: *, ?, ", <, >,,, /, \, |, and so on. The profile name chosen must not be in use.




-profilePath profile_root

Fully qualified path to the profile, which is referred to as the profile_root. Specify the full path to avoid an Ant scripting limitation that can cause a failure when federating the profile into a cell. For example:

-profilePath profile_root

(Windows) If the fully qualified path contains spaces, enclose the value in quotation marks. The default is based on the app_server_root directory, the profiles subdirectory, and the name of the profile. For example, the default is:

WS_WSPROFILE_DEFAULT_PROFILE_HOME/profileName

The WS_WSPROFILE_DEFAULT_PROFILE_HOME element is defined in the wasprofile.properties file in the app_server_root/properties directory.

The wasprofile.properties file includes the following properties:




WS_CMT_PI_MODPERMS

This property specifies if the post installer should modify the permissions of any files it creates. True or false. Any other value defaults to false. Removing this property from the file also causes it to default to false. When set to false, any files created by the post installer have permission based on the umask setting of the system.

The value for this parameter must be a valid path for the target system and must not be currently in use.

We must have permissions to write to the directory.




WS_CMT_PI_LOGS

This property specifies if and when the post installer should clean up its logs for each product located in the PROFILE_HOME/logs/service/productDir directory. The settings for this property allow us to specify the following log cleanup criteria:

• We can specify the number of logs we want to keep for each product in the PROFILE_HOME/logs/service/productDir directory. The specified value can be any integer between 1 and 999. For example, if we specify WS_CMT_PI_LOGS=5, the post installer keeps the five most recent logs for each product.

• We can specify the maximum amount of storage the logs can occupy. The specified value can be any integer between 1 and 999, followed by:
  • KB, if we are specifying the value in kilobytes.
  • MB, if we are specifying the value in megabytes.
  • GB, if we are specifying the value in gigabytes.

  For example, if we specify WS_CMT_PI_LOGS=10MB, when the amount of storage the logs occupy exceeds 10 megabytes, the post installer starts deleting the oldest logs.

  Because the values specified are case sensitive, the letters included in the specified value must be capital letters.

• We can specify the amount of time we want the post installer to keep the logs. The specified value can be any integer between 1 and 999, followed by:
  • D, if we are specifying the value in days.
  • W, if we are specifying the value inweeks.
  • M, if we are specifying the value in months.
  • Y, if we are specifying the value in years.

  For example, if we specify WS_CMT_PI_LOGS=2W, each log is kept for two weeks.

  Because the values specified are case sensitive, the letters included in the specified value must be capital letters.

• We can specify a specific date after which a log is deleted. The value must be specified using numeric values, separated by dashes in the format DD-MM-YYYY. For example, if we specify WS_CMT_PI_LOGS=12-31-2013, all of the logs are deleted on December31, 2013.

  If we do not specify the value in the indicated format, numbers separated by dashes, this property setting is ignored.




-response response_file

Accesses all API functions from the command line using the manageprofiles command.

The command line interface can be driven by a response file containing the input arguments for a given command in the properties file in key and value format. To determine which input arguments are required for the various types of profile templates and action, use the manageprofiles command with the -help parameter.

Use the following example response file to run a create operation:

create
profileName=testResponseFileCreate
profilePath=profile_root
templatePath=app_server_root/profileTemplates/default
nodeName=myNodeName
cellName=myCellName
hostName=myHostName
omitAction=myOptionalAction1,myOptionalAction2

When we create a response file, take into account the following set of guidelines:

• When we specify values, do not specify double-quote (") characters at the beginning or end of a value, even if that value contains spaces. This is a different rule than when we specify values on a command line.

• When we specify a single value containing a comma character, such as the distinguished names for the personalCertDN and signingCertDN parameters, use a double-backslash before the comma character. For example, here is how to specify the signingCertDN value with a distinguished name:
  signingCertDN=cn=testserver.ibm.com\\,ou=Root Certificate\\,ou=testCell\\,ou=testNode01\\,o=IBM\\,c=US

• When we specify multiple values, separate them with a comma character, and do not use double-backslashes. For example, here is how to specify multiple values for the omitAction parameter:
  omitAction=deployAdminConsole,defaultAppDeployAndConfig
• Do not specify a blank line in a response file. This can cause an error.
• (Windows) The path statement in the Windows operating system can use either forward slashes (/) or back slashes (\). If the path statement uses back slashes, then the response file requires double back slashes for the response file to correctly understand the path. Here is an example of a response file for a create operation that uses the double back slashes:
  create templatePath=C:\\WebSphere\\AppServer\\profileTemplates\\default

  Use forward slashes in order to reduce the chance of errors when switching between platforms.bprac




-restoreProfile

Important: The manageProfiles -restoreProfile command is only supported with a backup created at the same fixpack level. Restores a profile backup. Must be used with the -backupFile parameter, for example:

manageprofiles.sh -restoreProfile -backupFile file_name

To restore a profile...

1. Stop the server and the running processes for the profile to restore.
2. Manually delete the directory for the profile from the file system.
3. Run the -validateAndUpdateRegistry option of the manageprofiles command.
4. Restore the profile using the -restoreProfile option of the manageprofiles command.




-securityLevel security_level

The initial security level settings for the secure proxy server. Valid values are low, medium, and high. The default is high. The security level is based on startup user permissions, routing considerations, administration options, and error handling. We can optionally change our security settings after we create the secure proxy server profile.




-serverName server

Name of the server. Specify this parameter only for the default and secureproxy templates. If not specified when using the default or secureproxy templates, the default server name is server1 for the default profile, and proxy1 for the secure proxy profile.




-serverType DEPLOYMENT_MANAGER | ADMIN_AGENT | JOB_MANAGER

Type of management profile. Specify DEPLOYMENT_MANAGER for a deployment manager server, ADMIN_AGENT for an administrative agent server, or JOB_MANAGER for a job manager server. Required when we create a management profile.




(Linux) -serviceUserName service_user_ID

(Linux) User ID used during the creation of the Linux service so that the Linux service runs from this user ID. The Linux service runs whenever the user ID is logged on.




-setDefaultName

Set the default profile to one of the existing profiles. Must be used with the -profileName parameter, for example:

manageprofiles.sh -setDefaultName -profileName profile




-signingCertDN distinguished_name

Distinguished name of the root signing certificate that we create when we create the profile. Specify the distinguished name in quotes. This default personal certificate is located in the server keystore file. The -importSigningCertKS parameter is mutually exclusive with the -signingCertDN parameter. If we do not specifically create or import a root signing certificate, one is created by default. See the -signingCertValidityPeriod parameter and the -keyStorePassword.




-signingCertValidityPeriod validity_period (Optional Parameter)

An optional parameter that specifies the amount of time in years that the root signing certificate is valid. If not specified with the -signingCertDN parameter, the root signing certificate is valid for 15 years.




-startingPort startingPort

Starting port number for generating and assigning all ports for the profile. Port values are assigned sequentially from the -startingPort value, omitting those ports already in use. The system recognizes and resolves ports that are currently in use and determines the port assignments to avoid port conflicts. Do not use this parameter with the -defaultPorts or -portsFile parameters. During profile creation, the manageprofiles command uses an automatically generated set of recommended ports if we do not specify the -startingPort parameter, the -defaultPorts parameter or the -portsFile parameter. The recommended port values can be different than the default port values based on the availability of the default ports. Do not use this parameter if we are using the managed profile template.




-supportedProtocols supported_protocols

Protocols that are valid for the secure proxy server to proxy requests. Valid values are SIP, HTTP, and HTTP,SIP.




-templatePath /path/to/template

Path to the template files. Templates are located in:

app_server_root/profileTemplates

We can specify profile templates outside the installation root. The available templates are described in the Profile concepts topic.




-unaugment

Augmentation is the ability to change an existing profile with an augmentation template. To unaugment a profile that has been augmented, specify the -unaugment parameter and the -profileName parameter. If a series of manageprofiles augmentations were performed, and we specify only these two parameters to unaugment a profile, the unaugment action undoes the last augment action first. To unaugment a particular profile that has been augmented, additionally specify the -ignoreStack parameter with the -templatePath parameter. Normally, we would not unaugment a particular profile because ensure that we are not violating profile template dependencies. When using the -templatePath parameter, specify the fully qualified file path for the parameter. See also the augment parameter.




-unaugmentAll

Unaugments all profiles that have been augmented with a specific augmentation template. The -templatePath parameter is required with the -unaugmentAll parameter. When using the -templatePath parameter, specify the fully qualified file path for the parameter. Optionally, specify the -unaugmentDependents parameter with the -unaugmentAll parameter to unaugment all profiles that are prerequisites of the profiles that are being unaugmented. If we use this parameter when we have no profiles augmented with the profile templates, an error might be delivered. See also the augment parameter.




-unaugmentDependents

If specified, the parameter unaugments all the augmented profiles that are prerequisites to the profiles being unaugmented with the -unaugmentAll parameter. If not specified, it does not unaugment the augmented profiles that are prerequisites to the profiles being unaugmented.

Specify the -unaugmentDependents parameter with the -unaugmentAll parameter.




-validateAndUpdateRegistry

Checks all of the profiles listed in the profile registry to see if the profiles are present on the file system. Removes any missing profiles from the registry. Returns a list of the missing profiles that were deleted from the registry.




-validatePorts

Checks the ports to verify that they are not reserved or in use. This parameter helps you to identify ports that are not being used. If a port is determined to be in use, the profile creation stops and an error message displays. Use this parameter at any time on the create command line. IBM recommends that we use this parameter with the -portsFile parameter.




-validateRegistry

Checks all of the profiles listed in the profile registry to see if the profiles are present on the file system. Returns a list of missing profiles.




-webServerCheck true | false

Indicates if to set up web server definitions. Valid values include true or false. The default value for this parameter is false.




-webServerHostname webserver_host_name

The host name of the server. The default value for this parameter is the long host name of the local machine.




-webServerInstallPath webserver_installpath_name

The installation path of the web server, local or remote. The default value for this parameter is dependent on the operating system of the local machine and the value of the webServerType parameter. For example:

(Linux)

webServerType=IHS: webServerInstallPath defaulted to "/opt/IBM/HTTPServer"
webServerType=IIS: webServerInstallPath defaulted to "n\a"
webServerType=SUNJAVASYSTEM: webServerInstallPath defaulted to "/opt/sun/webserver"
webServerType=DOMINO: webServerInstallPath defaulted to ""
webServerType=APACHE: webServerInstallPath defaulted to ""
webServerType=HTTPSERVER_ZOS: webServerInstallPath defaulted to "n/a"

(AIX)

webServerType=IHS: webServerInstallPath defaulted to "/usr/IBM/HTTPServer"
webServerType=IIS: webServerInstallPath defaulted to "n\a"
webServerType=SUNJAVASYSTEM: webServerInstallPath defaulted to "/opt/sun/webserver"
webServerType=DOMINO: webServerInstallPath defaulted to "?"
webServerType=APACHE: webServerInstallPath defaulted to "?"
webServerType=HTTPSERVER_ZOS: webServerInstallPath defaulted to "n/a"




-webServerName webserver

The name of the web server. The default value for this parameter is webserver1.




-webServerOS webserver_operating_system

The operating system from where the web server resides. Valid values include: windows, linux, solaris, aix, hpux, os390, and os400. Use this parameter with the webServerType parameter.




-webServerPluginPath webserver_pluginpath

The path to the plug-ins that the web server uses. The default value for this parameter is WAS_HOME/plugins.




-webServerPort webserver_port

Indicates the port from where the web server will be accessed. The default value for this parameter is 80.




-webServerType webserver_type

The type of the web server. Valid values include: IHS, SUNJAVASYSTEM, IIS, DOMINO, APACHE, and HTTPSERVER_ZOS. Use this parameter with the webServerOS parameter.

>

Scenarios

• Create a deployment manager

  The following example uses the management template to create a deployment manager named Dmgr001. The deployment manager ports start at port number 20000.

  (Linux) (UNIX)

  app_server_root/bin/manageprofiles.sh -create 
     -profileName Dmgr001
     -profilePath profile_root
     -templatePath app_server_root/profileTemplates/management
     -serverType DEPLOYMENT_MANAGER
     -nodeName Dmgr001Node
     -cellName Dmgr001NodeCell
     -hostName localhost
     -isDefault
     -startingPort 20000
  

• Create an administrative agent

  The following example uses the management template to create an administrative agent named AdminAgent001. The administrative agent ports start at port number 24000.

  app_server_root/bin/manageprofiles.sh -create 
     -profileName AdminAgent001
     -profilePath profile_root
     -templatePath app_server_root/profileTemplates/management
     -serverType ADMIN_AGENT
     -nodeName AdminAgent001Node
     -hostName localhost
     -isDefault
     -startingPort 24000
  

• Create a job manager

  The following example uses the management template to create a job manager named JobMgr001. The job manager ports start at port number 25000.

  app_server_root/bin/manageprofiles.sh -create 
     -profileName JobMgr001
     -profilePath profile_root
     -templatePath app_server_root/profileTemplates/management
     -serverType JOB_MANAGER
     -nodeName JobMgr001Node
     -cellName JobMgr001NodeCell
     -hostName localhost
     -isDefault
     -startingPort 25000
  

• Create a secure proxy

  The following example uses the secureproxy template to create a secure proxy named SecureProxySrv001. The secure proxy ports start at port number 26000.

  app_server_root/bin/manageprofiles.sh -create 
     -profileName SecureProxySrv001
     -profilePath profile_root
     -templatePath app_server_root/profileTemplates/secureproxy
     -nodeName SecureProxySrv001Node
     -serverName secproxy1
     -hostName localhost
     -isDefault
     -startingPort 26000
  

• Create a custom profile

  The following example creates a custom profile and federates the profile into the deployment manager cell.

  app_server_root/bin/manageprofiles.sh -create 
     -profileName Custom01
     -profilePath profile_root
     -templatePath app_server_root/profileTemplates/managed
     -nodeName Custom01Node
     -cellName Custom01Cell
     -hostName myhost.mycity.mycompany.com
     -isDefault
     -dmgrHost myhost.mycity.mycompany.com
     -dmgrPort 8879
  

• Create an application server profile

  Create an application server profile named Default01 with the following command.

  (Linux) (UNIX)

  app_server_root/bin/manageprofiles.sh -create 
     -profileName Default01
     -profilePath profile_root
     -templatePath app_server_root/profileTemplates/default
     -nodeName Default01Node
     -cellName Default01Cell
     -hostName myhost.mycity.mycompany.com
     -isDefault
     -startingPort 21000
     -personalCertDN "cn=testa, ou=Rochester, o=IBM, c=US"     
     -signingCertDN "cn=testc, ou=Rochester, o=IBM, c=US"     
     -keyStorePassword ap3n9krw
  

• Create a cell profile

  Create a cell profile requires the creation of both the deployment manager and the application server portion of the cell profile. The two profiles are linked and some parameters must match between the creation parameters of the deployment manager and the application server portion of the cell profile.

  Important: For both the deployment manager and the application server portion of the cell profile, use the same values for the cellName, nodeName, and appServerNodeName parameters. If we did not specify names for these parameters when we created the deployment manager portion of the cell profile, use the default name that was assigned in the first command-line invocation. The following example illustrates the use of identical values for these parameters in the deployment manager and the application server portions of the cell profile.

  For Dmgr:                       
  -cellName host01Cell01          
  -nodeName host01CellManager01   
  -appServerNodeName host01Node01 
                                  
  For AppServer:                  
  -cellName host01Cell01          
  -nodeName host01CellManager01   
  -appServerNodeName host01Node01 
  

  The following example shows the creation of a cell profile named Dmgr001 having a cell name of Default01Cell and a node name of Default01Node. To create a full working cell, the -nodeProfilePath, -cellName, -appServerNodeName, -nodeName parameters are required to match between the cell_dmgr profile and the cell_node profile.

  1. Create the deployment manager portion of the cell profile.

     app_server_root/bin/manageprofiles.sh -create 
        -templatePath app_server_root/profileTemplates/cell/dmgr
        -nodeProfilePath app_server_root/profiles/AppSrv01
        -profileName Dmgr001
        -cellName Default01Cell
        -nodeName Default01Node
        -appServerNodeName Default02Node
     

  2. Create the application server portion of the cell profile.

     app_server_root/bin/manageprofiles.sh -create
        -templatePath app_server_root/profileTemplates/cell/default
        -dmgrProfilePath app_server_root/profiles/Dmgr001
        -portsFile app_server_root/profiles/Dmgr001/properties/portdef.props
        -nodePortsFile app_server_root/profiles/Dmgr001/properties/nodeportdef.props
        -profileName AppSrv01
        -cellName Default01Cell
        -nodeName Default01Node
        -appServerNodeName Default02Node
     

Logs

The manageprofiles command creates a log for every profile that it creates.

• The logs are in the app_server_root/logs/manageprofiles directory. The files are named in this pattern: profile_create.log.

• The command also creates a log for every profile that it deletes. The logs are in the app_server_root/logs/manageprofiles directory. The files are named in this pattern: profile_delete.log.

Example: Creating deployment manager profiles

We can create a deployment manager profile after installing our core product files. The deployment manager provides a single administrative interface to a logical group of application servers on one or more machines. Use the manageprofiles.sh -create command to create a deployment manager profile.

To create a deployment manager profile named shasti:

manageprofiles.sh -create
              -profileName shasti 
              -profilePath /shasti/WebSphere 
              -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/management
              -serverType DEPLOYMENT_MANAGER
              -cellName cell1
              -hostName planetaix 
              -nodeName dmgr1

The command creates a deployment manager profile named shasti in a cell named cell1 with a node name of dmgr1 in the following location:

/shasti/WebSphere

If we do not specify one of the port options during profile creation, a recommended set of port values will be used. The port conflict resolution algorithm determines these ports. The recommended set of ports must be free of conflict. To use the IBM default ports, use the -defaultPorts option when we create a profile.

Example: Incrementing default port numbers from a starting point

The manageprofiles command can assign port numbers based on a starting port value. We can provide the starting port value from the command line, using the -startingPort parameter. The command assigns port numbers sequentially from the starting port number value. However, if a port value in the sequence conflicts with an existing port assignment, the next available port value is used

The order of port assignments is arbitrary. Predicting assignments is not possible.

For example, ports created with -startingPort 20002 would appear similar to the following example:

Assigned ports for an application server profile

WC_defaulthost=20002
WC_adminhost=20003
WC_defaulthost_secure=20004
WC_adminhost_secure=20005
BOOTSTRAP_ADDRESS=20006
SOAP_CONNECTOR_ADDRESS=20007
IPC_CONNECTOR_ADDRESS=20008
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20009
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20010
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20011
ORB_LISTENER_ADDRESS=20012
DCS_UNICAST_ADDRESS=20013
SIB_ENDPOINT_ADDRESS=20014
SIB_ENDPOINT_SECURE_ADDRESS=20015
SIB_MQ_ENDPOINT_ADDRESS=20016
SIB_MQ_ENDPOINT_SECURE_ADDRESS=20017
SIP_DEFAULTHOST=20018
SIP_DEFAULTHOST_SECURE=20019
OVERLAY_UDP_LISTENER_ADDRESS=20020
OVERLAY_TCP_LISTENER_ADDRESS=20021

Assigned ports for a cell with a federated application server profile

WC_defaulthost=20002
WC_defaulthost_secure=20003
BOOTSTRAP_ADDRESS=20004
SOAP_CONNECTOR_ADDRESS=20005
IPC_CONNECTOR_ADDRESS=20006
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20007
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20008
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20009
ORB_LISTENER_ADDRESS=20010
DCS_UNICAST_ADDRESS=20011
SIB_ENDPOINT_ADDRESS=20012
SIB_ENDPOINT_SECURE_ADDRESS=20013
SIB_MQ_ENDPOINT_ADDRESS=20014
SIB_MQ_ENDPOINT_SECURE_ADDRESS=20015
SIP_DEFAULTHOST=20016
SIP_DEFAULTHOST_SECURE=20017
NODE_MULTICAST_DISCOVERY_ADDRESS=20018
NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS=20019
NODE_DISCOVERY_ADDRESS=20020
NODE_DCS_UNICAST_ADDRESS=20021
NODE_BOOTSTRAP_ADDRESS=20022
NODE_SOAP_CONNECTOR_ADDRESS=20023
NODE_ORB_LISTENER_ADDRESS=20024
NODE_SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20025
NODE_CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20026
NODE_CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20027
NODE_IPC_CONNECTOR_ADDRESS=20028
OVERLAY_UDP_LISTENER_ADDRESS=20029
OVERLAY_TCP_LISTENER_ADDRESS=20030
NODE_XDAGENT_PORT=20031
NODE_OVERLAY_UDP_LISTENER_ADDRESS=20032
NODE_OVERLAY_TCP_LISTENER_ADDRESS=20033

Assigned ports for a cell with a deployment manager profile

WC_adminhost=20002
WC_adminhost_secure=20003
BOOTSTRAP_ADDRESS=20004
SOAP_CONNECTOR_ADDRESS=20005
IPC_CONNECTOR_ADDRESS=20006
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20007
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20008
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20009
ORB_LISTENER_ADDRESS=20010
CELL_DISCOVERY_ADDRESS=20011
DCS_UNICAST_ADDRESS=20012
XDAGENT_PORT=20013
OVERLAY_UDP_LISTENER_ADDRESS=20014
OVERLAY_TCP_LISTENER_ADDRESS=20015
STATUS_LISTENER_ADDRESS=20016

Assigned ports for a management profile with a deployment manager server

WC_adminhost=20002
WC_adminhost_secure=20003
BOOTSTRAP_ADDRESS=20004
SOAP_CONNECTOR_ADDRESS=20005
IPC_CONNECTOR_ADDRESS=20006
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20007
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20008
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20009
ORB_LISTENER_ADDRESS=20010
CELL_DISCOVERY_ADDRESS=20011
DCS_UNICAST_ADDRESS=20012
DataPowerMgr_inbound_secure=20013
XDAGENT_PORT=20014
OVERLAY_UDP_LISTENER_ADDRESS=20015
OVERLAY_TCP_LISTENER_ADDRESS=20016
STATUS_LISTENER_ADDRESS=20017

Assigned ports for a management profile with a job manager server

WC_adminhost=20002
WC_adminhost_secure=20003
BOOTSTRAP_ADDRESS=20004
SOAP_CONNECTOR_ADDRESS=20005
IPC_CONNECTOR_ADDRESS=20006
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20007
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20008
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20009
ORB_LISTENER_ADDRESS=20010
STATUS_LISTENER_ADDRESS=20011

Assigned ports for a management profile with an administrative agent server

WC_adminhost=20002
WC_adminhost_secure=20003
BOOTSTRAP_ADDRESS=20004
SOAP_CONNECTOR_ADDRESS=20005
IPC_CONNECTOR_ADDRESS=20006
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20007
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20008
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20009
ORB_LISTENER_ADDRESS=20010

Assigned ports for a secure proxy profile

PROXY_HTTP_ADDRESS=20002
PROXY_HTTPS_ADDRESS=20003
PROXY_SIP_ADDRESS=20004
PROXY_SIPS_ADDRESS=20005
IPC_CONNECTOR_ADDRESS=20006

The following example uses the startingPort parameter of the manageprofiles command and creates ports from an initial value of 20002, with the content shown in the previous example:

app_server_root/bin/manageprofiles.sh -create
               -profileName shasti 
               -profilePath app_server_root/profiles/shasti 
               -templatePath app_server_root/profileTemplates/default 
               -nodeName W2K03 
               -cellName W2K03_Cell01
               -hostName planetnt 
               -startingPort 20002

Example: Creating cell profiles

To create the cell profile using the manageprofiles command, create both the cell management profile for a deployment manager server and the cell node profile using two different manageprofiles command-line invocations. The combination of these two profiles is the cell profile.

Two templates are used to create the cell profile: cell_dmgr and cell_node. The templates are linked and some parameters must match between the creation parameters in these two invocations. Verify that the invocations match.

From the command line, we can create the two halves of the cell in any order or at any time. It is a best practice to create the deployment manager portion of the profile first. After we create the cell, the cell contains a deployment manager and a federated node. The deployment manager portion and the node portion are in separate directories.

For each of the two profiles that we create, we can specify the fully qualified path to the resulting profile using the -profilePath parameter. If we do not specify the parameter, the default value for each profile path is based on the app_server_root directory, the profiles subdirectory, and the name of the profile.

The two templates that compose a cell profile have dependencies between one another which requires some parameter values to match between the two create invocations. To create a full working cell, the -nodeProfilePath, -cellName, -appServerNodeName, -nodeName parameters are required to have the same values for both the cell_dmgr profile and the cell_node profile. In the case of ports, and especially in the case of dynamically allocated ports, the creation of the second half of the cell must reference the ports used in the first half of the cell. Use the -portsFile and -nodePortsFile arguments with references to the following files of the profile that represents the first half of the cell:

• profile_root/properties/portdef.props
• profile_root/properties/nodeportdef.props

This approach ensures that the ports in the second half of the cell are created with the correct correlation to the first half of the cell.

For detailed help in creating a cell profile.:

app_server_root/bin/manageprofiles.sh -create -templatePath
app_server_root/profileTemplates/cell/dmgr -help

or

app_server_root/bin/manageprofiles.sh -create -templatePath
app_server_root/profileTemplates/cell/default -help

The output from the -help parameter specifies which parameters are required and which are optional when creating the cell deployment manager profile and the cell node profile.

The following example creates a cell profile named Dmgr001 having a cell name of Default01Cell and a node name of Default01Node.

1. Verify that the following path is available for use:

   The path must be available when we create the deployment manager and node portions of the cell as subdirectories are added for each portion.

   app_server_root/profiles

2. Create the deployment manager portion of the cell profile.

   app_server_root/bin/manageprofiles.sh  \
   -create \
   -templatePath app_server_root/profileTemplates/cell/dmgr \
   -nodeProfilePath app_server_root/profiles/AppSrv01 \
   -profileName Dmgr001 \
    -cellName Default01Cell \
    -nodeName Default01Node \
    -appServerNodeName federated_node\
   

3. Verify that the Dmgr001 profile exists as it must exist before creating the application server portion of the cell profile.

4. Create the application server portion of the cell profile.

   Important: We must use the same values for the cellName, nodeName, and appServerNodeName parameters that we used in the deployment manager portion of the cell profile. The following example illustrates the use of the same values for the cellName, nodeName, and appServerNodeName parameters in the deployment manager and application server portions of the cell profile.

   For Dmgr:                       
   -cellName host01Cell01          
   -nodeName host01CellManager01   
   -appServerNodeName host01Node01 
                                   
   For AppServer:                  
   -cellName host01Cell01          
   -nodeName host01CellManager01   
   -appServerNodeName host01Node01 
   

   If we did not specify names for these parameters when we created the deployment manager portion of the cell profile, use the default name that was assigned in the first command-line invocation.

   app_server_root/bin/manageprofiles.sh \
   -create  \
   -templatePath app_server_root/profileTemplates/cell/default  \
   -dmgrProfilePath app_server_root/profiles/Dmgr001  \
   -portsFile app_server_root/profiles/Dmgr001/properties/portdef.props  \
   -nodePortsFile app_server_root/profiles/Dmgr001/properties/nodeportdef.props  \
   -profileName AppSrv01  \
   -cellName Default01Cell  \
   -nodeName Default01Node  \
   -appServerNodeName federated_node 
   

After the creation of the deployment manager and node portions of the cell profile, a synchronization between the two servers must occur. By default, synchronization occurs automatically between the two servers at some specified interval. However, if synchronization is disabled, the interval is too long, or some problem occurs that keeps the synchronization from occurring in a timely manner, run the syncNode command to synchronize the deployment manager and the node.

We must either use the portsFile or the nodePortsFile parameter and the startingPort or the nodeStartingPort parameter.

If we use the manageprofiles command, we can choose the profile to be the default.

If we federate an application server node as part of cell profile creation using the -appServerNodeName parameter, the node does not have an original configuration. If we use the -removeNode command on a node created during cell profile creation, the command will indicate that the node removal utility is unable to remove the node and restore the node to a base configuration. To successfully remove a node that was federated as part of a cell profile creation, use the manageprofiles command to delete the profile for the node. Once the profile for the node is deleted, use the -cleanupNode command on Deployment Manager to remove the node configuration from the cell repository. A new profile can be created using the Profile Management Tool or the manageprofiles command.

Example: Using predefined port numbers

The manageprofiles command recommends initial port values when we do not explicitly set port values. Use predefined port values instead.

The manageprofiles command recommends port values when the options of -defaultPorts, -startingPort, or -portsFile are not specified.

Profile	File path
Application server	app_server_root/profileTemplates/default/actions/portsUpdate/portdef.props
Cell - application server portion	app_server_root/profileTemplates/cell/dmgr/actions/portsUpdate/nodeportdef.props
Cell - deployment manager portion	app_server_root/profileTemplates/cell/dmgr/actions/portsUpdate/portdef.props
Custom	app_server_root/profileTemplates/managed/actions/portsUpdate/portdef.props
Management profile for a deployment manager server	app_server_root/profileTemplates/management/actions/portsUpdate/dmgr.portdef.props
Management profile for an administrative agent server	app_server_root/profileTemplates/management/actions/portsUpdate/adminagent.portdef.props
Management profile for a job manager server	app_server_root/profileTemplates/management/actions/portsUpdate/jmgr.portdef.props
Secure proxy	app_server_root/profileTemplates/secureproxy/actions/portsUpdate/portdef.props

To customize the port values in the portdef.props file before creating your profile, perform the following steps. The following example creates the default profile. For other types of profiles, we must substitute the file path with the file path of the profile to create.

1. Copy the app_server_root/profileTemplates/default/actions/portsUpdate/portdef.props file from the default profile template path and place a copy of the file in an arbitrary temporary directory such as:
   /temp/ports

2. In the new file, modify the port settings to specify your port values.

3. Create your profile with the manageprofiles command. Use the modified port values. Specify the location of our modified portdef.props file on the -portsFile parameter. Specify the -validatePorts parameter to ensure that ports are not reserved or in use. Use the following example as a guide:

   manageprofiles.sh 
      -create
      -profileName Wow_Profile 
      -profilePath profile_root 
      -templatePath app_server_root\profileTemplates\default 
      -nodeName Wow_node 
      -cellName Wow_cell
      -hostName lorriemb 
      -portsFile \temp\ports\portdef.props
      -validatePorts
   

Suppose that the portdef.props file has the following values:

WC_defaulthost=39080
WC_adminhost=39060
WC_defaulthost_secure=39443
WC_adminhost_secure=39043
BOOTSTRAP_ADDRESS=32809
SOAP_CONNECTOR_ADDRESS=38880
IPC_CONNECTOR_ADDRESS=39633
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=39401
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=39403
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=39402
ORB_LISTENER_ADDRESS=39100
DCS_UNICAST_ADDRESS=39353
SIB_ENDPOINT_ADDRESS=37276
SIB_ENDPOINT_SECURE_ADDRESS=37286
SIB_MQ_ENDPOINT_ADDRESS=35558
SIB_MQ_ENDPOINT_SECURE_ADDRESS=35578
SIP_DEFAULTHOST=35060
SIP_DEFAULTHOST_SECURE=35061
OVERLAY_UDP_LISTENER_ADDRESS=35062
OVERLAY_TCP_LISTENER_ADDRESS=35063
STATUS_LISTENER_ADDRESS=35064

After running the manageprofiles command to create your profile with the user defined port values, a success or fail result displays.

The manageprofiles command creates a copy of the current portdefs.props file in...

profile_root\properties/portdefs.props

Use only one of the three port values parameters, -startingPort, -defaultPorts, or -portsFile with the manageprofiles command. The three parameters are mutually exclusive.