WebSphere Application Server Network Deployment, Version 6

򔻐򗗠򙳰

Administering applications and their environment

 Note
Before using this information, be sure to read the general information under “Notices” on page 2305.

Compilation date: January 20, 2005

© Copyright International Business Machines Corporation 2004. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
How to send your comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1. Overview and new features for administering applications and their environments .
. 1
Overview of administering applications and their environments . . . . . . . . . . . . . . .
. 2
Getting started with WebSphere Application Server . . . . . . . . . . . . . . . . . . .
. 3
Introduction: System administration . . . . . . . . . . . . . . . . . . . . . . . . .
. 3
Introduction: Administrative console . . . . . . . . . . . . . . . . . . . . . . . .
. 4
Introduction: Administrative scripting (wsadmin) . . . . . . . . . . . . . . . . . . . .
. 4
Introduction: Administrative commands . . . . . . . . . . . . . . . . . . . . . . .
. 5
Introduction: Administrative programs. . . . . . . . . . . . . . . . . . . . . . . .
. 5
Introduction: Administrative configuration data . . . . . . . . . . . . . . . . . . . .
. 6
Welcome to basic administrative architecture . . . . . . . . . . . . . . . . . . . . .
. 6
Introduction: Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 7
Introduction: Application servers . . . . . . . . . . . . . . . . . . . . . . . . .
. 8
Introduction: Web servers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 9
Introduction: Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Introduction: Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Introduction: Cell-wide settings. . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 2. How do I administer applications and their environments? . . . . . . . . . . . 13

Chapter 3. Setting up the application serving environment . . . . . . . . . . . . . . . .21

Planning the installation (diagrams) . . . . . . . . . . . . . . . . . . . . . . . . . .21
Planning to install Network Deployment . . . . . . . . . . . . . . . . . . . . . . .23
Planning to install Web server plug-ins . . . . . . . . . . . . . . . . . . . . . . .31
Planning to install WebSphere Application Server Clients . . . . . . . . . . . . . . . . .38
Planning to create application server environments . . . . . . . . . . . . . . . . . . .39
Example: Choosing a topology for better performance . . . . . . . . . . . . . . . . . .42
Queuing network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Configuring the product after installation . . . . . . . . . . . . . . . . . . . . . . . .47
firststeps command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Using the Profile creation wizard . . . . . . . . . . . . . . . . . . . . . . . . . .54
wasprofile command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Using the installation verification test . . . . . . . . . . . . . . . . . . . . . . . . 110
Configuring ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Port number settings in WebSphere Application Server versions . . . . . . . . . . . . . . 113
Communicating with Web servers . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Web server plug-in properties settings . . . . . . . . . . . . . . . . . . . . . . . 118
Web server plug-in custom properties . . . . . . . . . . . . . . . . . . . . . . . 126
Web server plug-in configuration service properties settings . . . . . . . . . . . . . . . 127
Application Server property settings for a Web server plug-in . . . . . . . . . . . . . . . 127
Web server plug-in configuration properties . . . . . . . . . . . . . . . . . . . . . 129
Web server plug-in connections . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Web server plug-in remote user information processing . . . . . . . . . . . . . . . . . 132
Web server plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Checking your IBM HTTP Server version . . . . . . . . . . . . . . . . . . . . . . 132
Web server tuning parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Gskit install images files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Plug-ins: Resources for learning . . . . . . . . . . . . . . . . . . . . . . . . . 137
Web server plug-in tuning tips . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Tuning Web servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Setting up the administrative architecture . . . . . . . . . . . . . . . . . . . . . . . 139
Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

© Copyright IBM Corp. 2004 iii

 Configuring cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Deployment managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Configuring deployment managers . . . . . . . . . . . . . . . . . . . . . . . . . 145
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Managing nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Node group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Managing node groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Managing node group members . . . . . . . . . . . . . . . . . . . . . . . . . 159
Administration service settings . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Node agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Managing node agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Remote file services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Configuring remote file services . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Administrative agents: Resources for learning . . . . . . . . . . . . . . . . . . . . 173
Configuring the environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Virtual hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Configuring virtual hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Configuring WebSphere variables . . . . . . . . . . . . . . . . . . . . . . . . . 181
Shared library files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Managing shared libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Environment: Resources for learning . . . . . . . . . . . . . . . . . . . . . . . . 191
Working with server configuration files . . . . . . . . . . . . . . . . . . . . . . . . 191
Configuration documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Configuration document descriptions . . . . . . . . . . . . . . . . . . . . . . . . 193
Object names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Configuration repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Handling temporary configuration files resulting from session timeout . . . . . . . . . . . . 196
Changing the location of temporary configuration files . . . . . . . . . . . . . . . . . 196
Changing the location of backed-up configuration files . . . . . . . . . . . . . . . . . 197
Changing the location of temporary workspace files . . . . . . . . . . . . . . . . . . 197
Backing up and restoring administrative configurations . . . . . . . . . . . . . . . . . 197
Transformation of configuration files . . . . . . . . . . . . . . . . . . . . . . . . 198
Server configuration files: Resources for learning . . . . . . . . . . . . . . . . . . . 198
Administering application servers . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Creating application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Managing application servers . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Creating generic servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Configuring transport chains . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Custom services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Developing custom services . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Process definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Defining application server processes . . . . . . . . . . . . . . . . . . . . . . . 240
Java virtual machines (JVMs) . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Using the JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Preparing to host applications . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Java memory tuning tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Configuring multiple network interface card support . . . . . . . . . . . . . . . . . . 264
Tuning application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Web services client to Web container optimized communication . . . . . . . . . . . . . . 266
Application servers: Resources for learning . . . . . . . . . . . . . . . . . . . . . 267
Balancing workloads with clusters . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Clusters and workload management . . . . . . . . . . . . . . . . . . . . . . . . 268
Clusters and node groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Workload management (WLM) for distributed platforms . . . . . . . . . . . . . . . . . 270

iv IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 Creating clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Creating cluster members . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Creating backup clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Starting clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Stopping clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Replicating data across application servers in a cluster . . . . . . . . . . . . . . . . . 283
Deleting clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Deleting cluster members . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Tuning a workload management configuration . . . . . . . . . . . . . . . . . . . . 296
Workload management run-time exceptions . . . . . . . . . . . . . . . . . . . . . 297
Clustering and workload management: Resources for learning . . . . . . . . . . . . . . 297
Setting up a high availability environment . . . . . . . . . . . . . . . . . . . . . . . 298
High availability manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
High availability network components . . . . . . . . . . . . . . . . . . . . . . . . 301
Transport protocol for a high availability manager . . . . . . . . . . . . . . . . . . . 302
Creating a new core group . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Changing a core group’s configuration . . . . . . . . . . . . . . . . . . . . . . . 311
Changing the configuration of a high availability group . . . . . . . . . . . . . . . . . 313
Creating a policy for a high availability group . . . . . . . . . . . . . . . . . . . . . 316
Changing the policy of a high availability group . . . . . . . . . . . . . . . . . . . . 323
Adding members to a core group . . . . . . . . . . . . . . . . . . . . . . . . . 324
Routing high availability group work to a different server . . . . . . . . . . . . . . . . . 326
Configuring the core group bridge service . . . . . . . . . . . . . . . . . . . . . . 328

Chapter 4. Using the administrative clients . . . . . . . . . . . . . . . . . . . . . 349

Using the administrative console . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Starting and stopping the administrative console . . . . . . . . . . . . . . . . . . . 349
Setting the session timeout for the administrative console . . . . . . . . . . . . . . . . 352
Administrative console areas . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Specifying console preferences . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Accessing help and product information from the administrative console . . . . . . . . . . . 362
Administrative console: Resources for learning . . . . . . . . . . . . . . . . . . . . 363
Using scripting (wsadmin) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Getting started with scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Deploying applications using scripting . . . . . . . . . . . . . . . . . . . . . . . 433
Managing deployed applications using scripting . . . . . . . . . . . . . . . . . . . . 435
Configuring servers with scripting . . . . . . . . . . . . . . . . . . . . . . . . . 462
Configuring connections to Webservers with scripting . . . . . . . . . . . . . . . . . . 479
Managing servers with scripting . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Clustering servers with scripting. . . . . . . . . . . . . . . . . . . . . . . . . . 489
Configuring security with scripting . . . . . . . . . . . . . . . . . . . . . . . . . 493
Configuring data access with scripting . . . . . . . . . . . . . . . . . . . . . . . 495
Configuring messaging with scripting . . . . . . . . . . . . . . . . . . . . . . . . 511
Configuring mail, URLs, and resource environment entries with scripting . . . . . . . . . . . 524
Troubleshooting with scripting . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Scripting reference material . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Using Ant to automate tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
ws_ant command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Ant tasks for deployment and server operation . . . . . . . . . . . . . . . . . . . . 810
Ant tasks for building application code . . . . . . . . . . . . . . . . . . . . . . . 810
Using administrative programs (JMX) . . . . . . . . . . . . . . . . . . . . . . . . . 810
Creating a custom Java administrative client program using WebSphere Application Server
administrative Java APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Extending the WebSphere Application Server administrative system with custom MBeans . . . . 816
Developing administrative programs for multiple Java 2 Platform, Enterprise Edition application
servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821

Contents v
 Deploying and managing a custom Java administrative client program with multiple Java 2
Platform, Enterprise Edition application servers . . . . . . . . . . . . . . . . . . . 824
Migrating Java Management Extensions V1.0 to Java Management Extensions V1.2 . . . . . . 825
Java Management Extensions interoperability . . . . . . . . . . . . . . . . . . . . 825
Managed object metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Managing applications through programming . . . . . . . . . . . . . . . . . . . . . 827
Using command line tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Example: Security and the command line tools . . . . . . . . . . . . . . . . . . . . 853
startServer command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
stopServer command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
startManager command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
stopManager command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
startNode command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
stopNode command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
addNode command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
serverStatus command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
removeNode command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
cleanupNode command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
syncNode command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868
backupConfig command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
restoreConfig command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
EARExpander command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
GenPluginCfg command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872

Chapter 5. Starting and stopping quick reference . . . . . . . . . . . . . . . . . . . 875

Chapter 6. Class loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877

Class loaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Configuring class loaders of a server . . . . . . . . . . . . . . . . . . . . . . . . . 881
Class loader collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Class loader ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Class loader mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Class loader settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Configuring application class loaders . . . . . . . . . . . . . . . . . . . . . . . . . 883
Configuring Web module class loaders . . . . . . . . . . . . . . . . . . . . . . . . 884
Configuring class preloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Class loading: Resources for learning . . . . . . . . . . . . . . . . . . . . . . . . 886

Chapter 7. Deploying and administering applications . . . . . . . . . . . . . . . . . 889

Enterprise (J2EE) applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
System applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Installing application files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Installable module versions . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Ways to install applications or modules . . . . . . . . . . . . . . . . . . . . . . . 892
Installing application files with the console . . . . . . . . . . . . . . . . . . . . . . 893
Example: Installing an EAR file using the default bindings . . . . . . . . . . . . . . . . 903
Installing J2EE modules with JSR-88 . . . . . . . . . . . . . . . . . . . . . . . . 904
Customizing modules using DConfigBeans . . . . . . . . . . . . . . . . . . . . . 905
Enterprise application collection . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Enterprise application settings . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Configuring an application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Application bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Mapping modules to servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Starting and stopping applications . . . . . . . . . . . . . . . . . . . . . . . . . . 918

vi IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 Disabling automatic starting of applications . . . . . . . . . . . . . . . . . . . . . 919
Target mapping collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Exporting applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
Exporting DDL files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Updating applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Ways to update application files . . . . . . . . . . . . . . . . . . . . . . . . . . 924
Preparing for application update settings . . . . . . . . . . . . . . . . . . . . . . 925
Hot deployment and dynamic reloading . . . . . . . . . . . . . . . . . . . . . . . 929
Uninstalling applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
Removing a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
Deploying and administering applications: Resources for learning . . . . . . . . . . . . . . 938

Chapter 8. Developing WebSphere applications . . . . . . . . . . . . . . . . . . . . 941

Web applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Task overview: Developing and deploying Web applications . . . . . . . . . . . . . . . 941
Task overview: Managing HTTP sessions . . . . . . . . . . . . . . . . . . . . . . 978
Modifying the default Web container configuration . . . . . . . . . . . . . . . . . . . 993
Configuring session management by level . . . . . . . . . . . . . . . . . . . . . . 998
Configuring session tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Configuring session tracking for Wireless Application Protocol (WAP) devices . . . . . . . . 1004
Configuring for database session persistence . . . . . . . . . . . . . . . . . . . . 1004
Configuring memory-to-memory replication for the peer-to-peer mode (default memory-to-memory
replication) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
Configuring memory-to-memory replication for the client/server mode . . . . . . . . . . . 1008
EJB applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
Task overview: Using enterprise beans in applications . . . . . . . . . . . . . . . . . 1010
Using access intent policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015
Managing EJB containers . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
Deploying EJB modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036
Client applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Using application clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Running application clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 1050
Installing Application Client for WebSphere Application Server . . . . . . . . . . . . . . 1068
Deploying J2EE application clients on workstation platforms . . . . . . . . . . . . . . . 1073
Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Implementing Web services applications . . . . . . . . . . . . . . . . . . . . . . 1151
Deploying Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163
Configuring Web service client bindings . . . . . . . . . . . . . . . . . . . . . . 1165
Configuring the scope of a Web service port. . . . . . . . . . . . . . . . . . . . . 1168
Web Services Invocation Framework (WSIF): Enabling Web services . . . . . . . . . . . 1170
Getting started with UDDI Registry . . . . . . . . . . . . . . . . . . . . . . . . 1174
Planning to use Web services . . . . . . . . . . . . . . . . . . . . . . . . . . 1176
Setting up and deploying a new UDDI Registry. . . . . . . . . . . . . . . . . . . . 1180
Publishing WSDL files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1191
Configuring endpoint URL information for JMS bindings . . . . . . . . . . . . . . . . 1194
Configuring Web services applications with the wsadmin tool . . . . . . . . . . . . . . 1196
WSIF system management and administration . . . . . . . . . . . . . . . . . . . . 1196
Using the UDDI Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
Removing and reinstalling UDDI Registry . . . . . . . . . . . . . . . . . . . . . . 1307
Configuring the UDDI Registry Application . . . . . . . . . . . . . . . . . . . . . 1309
Managing the UDDI Registry . . . . . . . . . . . . . . . . . . . . . . . . . . 1313
Data access resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325
Task overview: Accessing data from applications . . . . . . . . . . . . . . . . . . . 1325
Deploying data access applications . . . . . . . . . . . . . . . . . . . . . . . . 1355
Messaging resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443
Learning about messaging with WebSphere Application Server . . . . . . . . . . . . . . 1443

Contents vii
 Installing and configuring a JMS provider . . . . . . . . . . . . . . . . . . . . . . 1454
Using asynchronous messaging . . . . . . . . . . . . . . . . . . . . . . . . . 1456
Using JMS resources of WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . 1456
Using JMS resources of a generic provider . . . . . . . . . . . . . . . . . . . . . 1524
Maintaining Version 5 default messaging resources . . . . . . . . . . . . . . . . . . 1532
Administering support for message-driven beans . . . . . . . . . . . . . . . . . . . 1565
Mail, URLs, and other J2EE resources . . . . . . . . . . . . . . . . . . . . . . . . 1581
Using mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1581
Using URL resources within an application . . . . . . . . . . . . . . . . . . . . . 1585
Resource environment entries . . . . . . . . . . . . . . . . . . . . . . . . . . 1588
Configuring mail providers and sessions . . . . . . . . . . . . . . . . . . . . . . 1592
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1598
Securing applications and their environments . . . . . . . . . . . . . . . . . . . . 1598
Planning to secure your environment . . . . . . . . . . . . . . . . . . . . . . . 1599
Implementing security considerations at installation time . . . . . . . . . . . . . . . . 1611
Integrating IBM WebSphere Application Server security with existing security systems . . . . . 1616
Administering security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624
Deploying secured applications . . . . . . . . . . . . . . . . . . . . . . . . . 1984
Naming and directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1995
Using naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1995
Configuring name servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 2006
Configuring and viewing name space bindings . . . . . . . . . . . . . . . . . . . . 2006
Developing applications that use JNDI . . . . . . . . . . . . . . . . . . . . . . . 2010
Developing applications that use CosNaming (CORBA Naming interface) . . . . . . . . . . 2025
Object Request Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2030
Managing Object Request Brokers . . . . . . . . . . . . . . . . . . . . . . . . 2030
Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2047
Configuring transaction properties for an application server . . . . . . . . . . . . . . . 2047
Configuring transaction properties for peer recovery . . . . . . . . . . . . . . . . . . 2056
Using the transaction service . . . . . . . . . . . . . . . . . . . . . . . . . . 2057
Managing active and prepared transactions . . . . . . . . . . . . . . . . . . . . . 2070
Managing transaction logging for optimum server availability . . . . . . . . . . . . . . . 2071
Interoperating transactionally between application servers. . . . . . . . . . . . . . . . 2074
Using one-phase and two-phase commit resources in the same transaction . . . . . . . . . 2075
WebSphere programming extensions . . . . . . . . . . . . . . . . . . . . . . . . 2078
ActivitySessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2079
Application profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2093
Asynchronous beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2105
Dynamic cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2122
Dynamic query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2172
Internationalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2201
Object pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2211
Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2217
Startup beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2242
Work area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2243

Chapter 9. Troubleshooting deployment . . . . . . . . . . . . . . . . . . . . . . 2269

Errors or problems deploying, installing, or promoting applications . . . . . . . . . . . . . 2269
Troubleshooting testing and first time run problems . . . . . . . . . . . . . . . . . . . 2273
Errors starting an application . . . . . . . . . . . . . . . . . . . . . . . . . . . 2274
The application does not start or starts with errors . . . . . . . . . . . . . . . . . . . 2278
A web resource does not display . . . . . . . . . . . . . . . . . . . . . . . . . . 2279
Cannot uninstall an application or remove a node or application server . . . . . . . . . . . . 2281

Chapter 10. Troubleshooting administration . . . . . . . . . . . . . . . . . . . . . 2283

Administration and administrative console troubleshooting tips . . . . . . . . . . . . . . . 2283

viii IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Installation completes but the administrative console does not start . . . . . . . . . . . . . 2285
Errors connecting to the administrative console from a browser . . . . . . . . . . . . . . 2286
When a single user that uses multiple instances of the Mozilla browser logs into the
administrative console, the first user ID that logs into the administrative console is the current
user. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2286
A user on Mozilla browser Version 1.4 selects a check box on a collection table, presses Enter,
and receives an error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2287
A user on Mozilla browser Version 1.4 enters an invalid ID or password, presses Enter, and
receives an error message . . . . . . . . . . . . . . . . . . . . . . . . . . 2287
Web server plug-in troubleshooting tips . . . . . . . . . . . . . . . . . . . . . . . 2287
The server process does not start or starts with errors . . . . . . . . . . . . . . . . . . 2289
The stopServer.sh or administrative console stop server commandhangs and creates a Java core
dump (Red Hat Linux) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2290
Errors setting up multiserver environments . . . . . . . . . . . . . . . . . . . . . . 2291
Workload management component troubleshooting tips . . . . . . . . . . . . . . . . . 2293
Workload is not getting distributed . . . . . . . . . . . . . . . . . . . . . . . . . 2297
Problems starting or using the wsadmin command . . . . . . . . . . . . . . . . . . . 2300
Problems using tracing, logging or other troubleshooting features . . . . . . . . . . . . . . 2304

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2305

Trademarks and service marks . . . . . . . . . . . . . . . . . . . . . . . . . . 2307

Contents ix
x IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
How to send your comments
Your feedback is important in helping to provide the most accurate and highest quality information.
v To send comments on articles in the WebSphere Application Server Information Center
1. Display the article in your Web browser and scroll to the end of the article.
2. Click on the Feedback link at the bottom of the article, and a separate window containing an e-mail
form appears.
3. Fill out the e-mail form as instructed, and click on Submit feedback .
v To send comments on PDF books, you can e-mail your comments to: [email protected] or fax
them to 919-254-0206.
Be sure to include the document name and number, the WebSphere Application Server version you are
using, and, if applicable, the specific page, table, or figure number on which you are commenting.
When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information
in any way it believes appropriate without incurring any obligation to you.

© Copyright IBM Corp. 2004 xi

xii IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Chapter 1. Overview and new features for administering
applications and their environments
This topic summarizes the contents and organization of the administration documentation, including links
to conceptual overviews and descriptions of new features.
v Overview of administering applications and their environments
v What is new for administrators

Sections in the administration documentation:

Chapter 3, “Setting up the application serving environment,” on page 21
This section is for the administrator who is responsible for integrating application serving
capabilities into an existing network environment. It looks at the product as part of a larger system,
typically a production environment or realistic test environment. This section reiterates some
installation and customization activities, including topology planning and creating product
configurations. It carries the focus into the administrative realm, discussing port configuration and
other network concerns. See also ″Overview and new features for installing an application serving
environment″ in the information center.
This information expands the topology planning discussion by describing how to set up and
maintain logical administrative domains of cells and nodes, and how to balance workload through
clustering and high availability configurations.
Chapter 4, “Using the administrative clients,” on page 349
This section describes the many options available for administering your applications and the
servers to which the applications are deployed. Options include the graphical administrative
console; scripting with the wsadmin tool; programmatic administration using Java Management
Extensions (JMX) and MBeans; and a wide array of command-line tools, including ANT.
Chapter 5, “Starting and stopping quick reference,” on page 875
This section summarizes what can be started and stopped, including applications and the
application servers on which these applications are deployed.
Chapter 6, “Class loading,” on page 877
This section describes how to configure class loaders. It includes both configuration that is
performed during application assembly (packaging) and configuration performed at the server. The
product run-time environment uses class loaders to find and load new classes for an application.
Class loaders are part of the Java virtual machine (JVM) code and are responsible for finding and
loading class files.
Chapter 7, “Deploying and administering applications,” on page 889
This section describes how to deploy applications onto application servers, and then how to
administer the deployed applications. It includes installing applications, starting applications,
exporting application files, updating applications, removing applications, and other common tasks.
Administer WebSphere applications
This section provides administrative instructions that are specific to the various types of
applications. For example, you can focus on administering your Web applications in their Web
container; or aspects of Web services support; or the messaging or security subsystems.
Chapter 9, “Troubleshooting deployment,” on page 2269
This section describes how to identify and handle a variety of problems encountered during
development, assembly, and deployment activities.
Chapter 10, “Troubleshooting administration,” on page 2283
This section describes how to identify and handle a variety of problems encountered during
administrative activities.

© Copyright IBM Corp. 2004 1

Overview of administering applications and their environments
This topic provides links to conceptual overviews of administering your applications and application serving
environment.
What is new for administrators
This topic provides an overview of new and changed features of system administration.
“Introduction: System administration” on page 3
This topic describes the administration of WebSphere Application Server, Version 6 products and
the applications that run on them.
Presentations from Education on Demand
The following presentations provide a quick overview:
v System management architecture
v Administrative security
v Administrative clients overview
– Start, stop, and monitor processes
– Other commands
– Browser-based administrative console
– Scripting - wsadmin
– Custom Java administrative client (JMX)
v Topologies and logical administrative domains
– Resource scoping
– Cells, deployment managers, and node agents
– Build cells - Add and remove nodes
– Manage node groups
v Applications and application resources
– Application management overview
– JDBC
– Installing and uninstalling applications
– Managed application resources - Enhanced EAR files
– Fine grained application updates
v Servers
– Server templates
– Custom services
– Manage Web server nodes
– Application servers and cluster members
– Creating cluster members
v Configuration management
– Configuration repository
– Configuration archives
– File synchronization

2 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Getting started with WebSphere Application Server

Note: If you prefer to browse PDF versions of this documentation using Adobe Reader, see the
Getting Started PDF files that are available from
www.ibm.com/software/webservers/appserv/infocenter.html.

IBM WebSphere Application Server products provide a next-generation application server on an

industry-standard foundation. Each product addresses a distinct set of scenarios and needs. WebSphere
Application Server, Version 6 product offerings are described in ″Packaging″ in the information center.

Planning

See ″Task overview: Installing″ in the information center for a description of typical scenarios for each
WebSphere Application Server product.

Installing

See ″Task overview: Installing″ for a description of installing the WebSphere Application Server product
and other installable components on the product disc.

Configuring

See “Using the Profile creation wizard” on page 54 for a description of installing profiles that define a
deployment manager, a managed node, or a stand-alone Application Server.

Migrating

See ″Migration and coexistence overview″ and ″Migrating and coexisting″ in the information center for a
description of how to migrate applications and configuration data from a previous version of WebSphere
Application Server.

Using the Samples Gallery

See ″Accessing the Samples (Samples Gallery)″ in the information center for a description of the set of
Samples that ship with each product. The Samples demonstrate common Web application tasks.

Deploying applications

The information center describes a way to sample WebSphere Application Server functionality by quickly
deploying Web components, such as servlets and JSP files. The method is not recommended as an
official development method. See ″Fast paths for WebSphere Application Server″ in the information center
to get started.

Introduction: System administration

A variety of tools are provided for administering the WebSphere Application Server product:
v Console
The administrative console is a graphical interface that provides many features to guide you through
deployment and systems administration tasks. Use it to explore available management options.
For more information, refer to “Introduction: Administrative console” on page 4.
v Administrative agents

Chapter 1. Overview and new features for administering applications and their environments 3
 Servers, nodes and node agents, cells and the deployment manager are fundamental concepts in the
administrative universe of the product. It is also important to understand the various processes in the
administrative topology and the operating environment in which they apply.
For more information, refer to “Welcome to basic administrative architecture” on page 6.
v Scripting
The WebSphere administrative (wsadmin) scripting program is a powerful, non-graphical command
interpreter environment enabling you to run administrative operations in a scripting language. You can
also submit scripting language programs to run. The wsadmin tool is intended for production
environments and unattended operations.
For more information, refer to “Introduction: Administrative scripting (wsadmin).”
v Commands
Command-line tools are simple programs that you run from an operating system command-line prompt
to perform specific tasks, as opposed to general purpose administration. Using the tools, you can start
and stop application servers, check server status, add or remove nodes, and complete similar tasks.
For more information, refer to “Introduction: Administrative commands” on page 5.
v Programming
The product supports a Java programming interface for developing administrative programs. All of the
administrative tools supplied with the product are written according to the API, which is based on the
industry standard Java Management Extensions (JMX) specification.
For more information, refer to “Introduction: Administrative programs” on page 5.
v Data
Product configuration data resides in XML files that are manipulated by the previously-mentioned
administrative tools.
For more information, refer to “Introduction: Administrative configuration data” on page 6.

Introduction: Administrative console

The administrative console is a graphical interface for performing deployment and system administration
tasks. It runs in your Web browser. Your actions in the console modify a set of XML configuration files.

You can use the console to perform tasks such as:

v Add, delete, start, and stop application servers
v Deploy new applications to a server
v Start and stop existing applications, and modify certain configurations
v Add and delete Java 2 Platform, Enterprise Edition (J2EE) resource providers for applications that
require data access, mail, URLs, and so on
v Manage variables, shared libraries, and other configurations that can span multiple application servers
v Configure product security, including access to the administrative console
v Collect data for performance and troubleshooting purposes
v Find the product version information. It is located on the front page of the console.

See the Using the administrative clients PDF for information on how you begin using the console. See also
the Reference > Administrator > Settings section of the Information Center navigation. It lists the
settings or properties you can configure.

Introduction: Administrative scripting (wsadmin)

The WebSphere administrative (wsadmin) scripting program is a powerful, non-graphical command
interpreter environment enabling you to run administrative operations in a scripting language. The wsadmin
tool is intended for production environments and unattended operations. You can use the wsadmin tool to
perform the same tasks that you can perform using the administrative console.

4 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
The following list highlights the topics and tasks available with scripting. See the Administering applications
and their environment PDF for more information on how to perform these tasks.
v Getting started with scripting Provides an introduction to WebSphere Application Server scripting and
information about using the wsadmin tool. Topics include information about the scripting languages and
the scripting objects, and instructions for starting the wsadmin tool.
v Deploying applications Provides instructions for deploying and uninstalling applications. For example,
stand-alone Java archive files and Web archive files, the administrative console, remote enterprise
archive (EAR) files, file transfer applications, and so on.
v Managing deployed applications Includes tasks that you perform after the application is deployed. For
example, starting and stopping applications, checking status, modifying listener address ports, querying
application state, configuring a shared library, and so on.
v Configuring servers Provides instructions for configuring servers, such as creating a server, modifying
and restarting the server, configuring the Java virtual machine, disabling a component, disabling a
service, and so on.
v Configuring connections to Web servers Includes topics such as regenerating the plug-in, creating new
virtual host templates, modifying virtual hosts, and so on.
v Managing servers Includes tasks that you use to manage servers. For example, stopping nodes,
starting and stopping servers, querying a server state, starting a listener port, and so on.
v Clustering servers Includes topics about clusters, such as creating clusters, creating cluster members,
querying a cluster state, removing clusters, and so on.
v Configuring security Includes security tasks, for example, enabling and disabling global security,
enabling and disabling Java 2 security, and so on.
v Configuring data access Includes topics such as configuring a Java DataBase Connectivity (JDBC)
provider, defining a data source, configuring connection pools, and so on.
v Configuring messaging Includes topics about messaging, such as Java Message Service (JMS)
connection, JMS provider, WebSphere queue connection factory, MQ topics, and so on.
v Configuring mail, URLs, and resource environment entries Includes topics such as mail providers, mail
sessions, protocols, resource environment providers, reference tables, URL providers, URLs, and so on.
v Dynamic caching Includes caching topics, for example, creating, viewing and modifying a cache
instance.
v Troubleshooting Provides information about how to troubleshoot using scripting. For example, tracing,
thread dumps, profiles, and so on.
v Obtaining product information Includes tasks such as querying the product identification.
v Scripting reference material Includes all of the reference material related to scripting. Topics include the
syntax for the wsadmin tool and for the administrative command framework, explanations and examples
for all of the scripting object commands, the scripting properties, and so on.

Introduction: Administrative commands

Command-line tools are simple programs that you run from an operating system command-line prompt to
perform specific tasks, as opposed to general purpose administration. Using the tools, you can start and
stop application servers, check server status, add or remove nodes, and complete similar tasks.

See Reference > Commands in the information center navigation for the names and syntax of all the
commands that are available with the product. A subset of these commands are particular to system
administration purposes.

Introduction: Administrative programs

The product supports a Java programming interface for developing administrative programs. All of the
administrative tools supplied with the product are written according to the API, which is based on the
industry standard Java Management Extensions (JMX) specification. You can write a Java program that

Chapter 1. Overview and new features for administering applications and their environments 5
performs any of the administrative features of the WebSphere Application Server administrative tools. You
can also extend the basic WebSphere Application Server administrative system to include your own
managed resources.

Introduction: Administrative configuration data

Administrative tasks typically involve defining new configurations of the product or performing operations
on managed resources within the environment. IBM WebSphere Application Server configuration data is
kept in files. Because all product configuration involves changing the content of those files, it is useful to
know the structure and content of the configuration files.

The WebSphere Application Server product includes an implementation of the Java Management
Extension (JMX) specification. All operations on managed resources in the product go through JMX
functions. This setup means a more standard framework underlying your administrative operations as well
as the ability to tap into the systems management infrastructure programmatically.

Welcome to basic administrative architecture

This article discusses basic concepts in the administrative architecture to help you understand system
administration in a WebSphere Application Server environment. The fundamental concepts for WebSphere
Application Server administration include software processes called servers, topological units referenced
as nodes and cells, and the configuration repository used for storing configuration information.

Servers perform the actual running of the code. Several types of servers exist depending on the
configuration. Each server runs in its own Java virtual machine (JVM). The application server is the
primary run-time component in all WebSphere Application Server configurations. All WebSphere
Application Server configurations can have one or more application servers. In some configurations, each
application server functions as a separate entity. No workload distribution or common administration
among application servers exists. In other configurations, workload can be distributed between servers and
administration can be done from a central point.

A node is a logical group of WebSphere Application Server-managed server processes that share a
common configuration repository. A node is associated with a single WebSphere Application Server profile.
A WebSphere Application Server node does not necessarily have a one-to-one association with a system.
One computer can host arbitrarily many nodes, but a node cannot span multiple computer systems. A
node can contain zero or more application servers.

The configuration repository holds copies of the individual component configuration documents that define
the configuration of a WebSphere Application Server environment. All configuration information is stored in
.xml files.

A cell is a grouping of nodes into a single administrative domain. A cell can consist of multiple nodes, all
administered from a deployment manager server. When a node becomes part of a cell (a federated node),
a node agent server is installed on the node to work with the deployment manager server to manage the
WebSphere Application Server environment on that node.

When a node is a standalone node, not part of a cell, the configuration repository is fully contained on the
node. When a node is part of a cell, the configuration and application files for all nodes in the cell are
centralized into a cell master configuration repository. This centralized repository is managed by the
deployment manager server and synchronized to local copies that are held on each node. The local copy
of the repository that is given to each node contains just the configuration information needed by that
node, not the full configuration that is maintained by the deployment manager.

WebSphere Application Server types

This section discusses the three server types that interact to perform system administration.

6 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Application Server: A WebSphere Application Server provides the functions that are required to support
and host user applications. An application server runs on only one node, but one node can support many
application servers.

Node agent: When a node is federated, a node agent is created and installed on that node. The node
agent works with the deployment manager to perform administrative activities on the node.

Deployment manager: With the deployment manager, you can administer multiple application servers
from one centralized manager. The deployment manager works with the node agent on each node to
manage all the servers in a distributed topology.

The following diagram depicts the concepts that are discussed in this article.
IBM WebSphere Application Server Network Deployment package

Node
Cell
Deployment
manager

Adding a node to a cell

Node
WebSphere Application Server

Application Server
Enterprise Edition Node
lkdsjfkenroierithtrj
a;lkjdfoidicnvcnv
aodsfiidididid
agent
Node a;osidjfpapoidjuff

Application Server slkdjflkdj;lakjdf;lkjaslkdfgfgfdgfdgfdgfdg

sdlkfj;slkajflskjdf;lskdflkjfj;alkjfd ;lkjfd sd;jfdfgfdgf
jsafjs df;lskjfd ;lskjf sfksdf kjsdf ;slkdfg
as;dlfkj lkdsjf ;sjd;fk ja;lkjd f;lk

Node
agent
WebSphere Application Server
Enterprise Edition
Application Server

lkdsjfkenroierithtrj
a;lkjdfoidicnvcnv
aodsfiidididid
a;osidjfpapoidjuff

Application Server slkdjflkdj;lakjdf;lkjaslkdfgfgfdgfdgfdgfdg

WebSphere Application Server sdlkfj;slkajflskjdf;lskdflkjfj;alkjfd ;lkjfd sd;jfdfgfdgf

Enterprise Edition jsafjs df;lskjfd ;lskjf sfksdf kjsdf ;slkdfg

Application Server as;dlfkj lkdsjf ;sjd;fk ja;lkjd f;lk

lkdsjfkenroierithtrj
a;lkjdfoidicnvcnv
aodsfiidididid
a;osidjfpapoidjuff

Application Server slkdjflkdj;lakjdf;lkjaslkdfgfgfdgfdgfdgfdg

sdlkfj;slkajflskjdf;lskdflkjfj;alkjfd ;lkjfd sd;jfdfgfdgf
Node
jsafjs df;lskjfd ;lskjf sfksdf kjsdf ;slkdfg
as;dlfkj lkdsjf ;sjd;fk ja;lkjd f;lk

Node WebSphere Application Server

Enterprise Edition

= Network Deployment package is installed

Application Server

lkdsjfkenroierithtrj

agent
a;lkjdfoidicnvcnv
aodsfiidididid
a;osidjfpapoidjuff

Application Server slkdjflkdj;lakjdf;lkjaslkdfgfgfdgfdgfdgfdg

sdlkfj;slkajflskjdf;lskdflkjfj;alkjfd ;lkjfd sd;jfdfgfdgf
jsafjs df;lskjfd ;lskjf sfksdf kjsdf ;slkdfg
as;dlfkj lkdsjf ;sjd;fk ja;lkjd f;lk

= Application servers
WebSphere Application Server
Enterprise Edition
Application Server

lkdsjfkenroierithtrj
a;lkjdfoidicnvcnv
aodsfiidididid
a;osidjfpapoidjuff

Application Server slkdjflkdj;lakjdf;lkjaslkdfgfgfdgfdgfdgfdg

sdlkfj;slkajflskjdf;lskdflkjfj;alkjfd ;lkjfd sd;jfdfgfdgf
jsafjs df;lskjfd ;lskjf sfksdf kjsdf ;slkdfg
as;dlfkj lkdsjf ;sjd;fk ja;lkjd f;lk

The concepts that are discussed in this article form the basis of WebSphere Application Server
administration. More detailed descriptions can be found in other sections.

Introduction: Servers
Application servers

Application servers provide the core functionality of the WebSphere Application Server product family. They
extend the ability of a Web server to handle Web application requests, and much more. An application
server enables a server to generate a dynamic, customized response to a client request.

For additional overview, refer to “Introduction: Application servers” on page 8.

Clusters

Workload management optimizes the distribution of client processing tasks. Incoming work requests are
distributed to the application servers that can most effectively process the requests. Workload
management also provides failover when servers are not available, improving application availability.

Chapter 1. Overview and new features for administering applications and their environments 7
Clusters are sets of application servers that are managed together and participate in workload
management. The servers that are members of a cluster can be on different host machines, as opposed to
the servers that are part of the same node and must be located on the same host machine.

For additional overview, refer to “Introduction: Clusters” on page 10.

Introduction: Application servers

Overview

An application server is a Java Virtual Machine (JVM) that is running user applications. The application
server collaborates with the Web server to return a dynamic, customized response to a client request.
Application code, including servlets, JavaServer Pages (JSP) files, enterprise beans and their supporting
classes, runs in an application server. Conforming to the Java 2 platform, Enterprise Edition (J2EE)
component architecture, servlets and JSP files run in a Web container, and enterprise beans run in an
Enterprise JavaBeans (EJB) container.

To begin creating and managing an application server, see “Administering application servers” on page
198.

You can define multiple application servers, each running its own JVM. Enhance the operation of an
application server by using the following options:
v Configure transport chains to provide networking services to such functions as the service integration
bus component of IBM service integration technologies, WebSphere Secure Caching Proxy, and the
high availability manager core group bridge service. See “Configuring transport chains” on page 221 for
more information.
v Plug into an application server to define a hook point that runs when the server starts and shuts down.
See “Custom services” on page 237 for more information.
v Define command-line information that passes to a server when it starts or initializes. See the Using the
administrative clients PDF for more information.
v “Tuning application servers” on page 265
v Enhance the performance of the application server JVM. See “Using the JVM” on page 252 for more
information.
v Use an Object Request Broker (ORB) for RMI/IIOP communication. See the Developing and deploying
applications PDF for more information.

Asynchronous messaging

The product supports asynchronous messaging based on the Java Messaging Service (JMS) of a JMS
provider that conforms to the JMS specification version 1.1.

The JMS functions of the default messaging provider in WebSphere Application Server are served by one
or more messaging engines (in a service integration bus) that runs within application servers.

In a deployment manager cell, there can be WebSphere Application Server version 5 nodes. If a version 5
node is configured to use V5 Default Messaging (the version 5 Embedded Messaging), there can be at
most one JMS server on that node.

Generic Servers

In distributed platforms, the Generic Servers feature allows you create a generic server as an application
server instance within the WebSphere Application Server administration, and associate it with a
non-WebSphere server or process. The generic server can be associated with any server or process
necessary to support the application server environment, including:
v A Java server
v A C or C++ server or process

8 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
v A CORBA server
v A Remote Method Invocation (RMI) server

After you define a generic server, you can use the Application Server administrative console to start, stop,
and monitor the associated non-WebSphere server or process when stopping or starting the applications
that rely on them.

For more information, refer to “Creating generic servers” on page 219.

Introduction: Web servers

In the WebSphere Application Server product, an application server works with a Web server to handle
requests for dynamic content, such as servlets, from Web applications. Go to
http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html for the most current information
about supported Web servers.

The application server and Web server communicate using “Web server plug-ins” on page 132.
“Communicating with Web servers” on page 116 describes how to set up your Web server and Web server
plug-in environment and how to create a Web server definition. The Web server definition associates a
Web server with a previously defined managed or unmanaged node. After you define the Web server to a
node, you can use the administrative console to perform the following functions for that Web server.

If the Web server is defined to a managed node, you can:

v Check the status of the Web server
v Generate a plug-in configuration file for that Web server.
v Propagate the plug-in configuration file after it is generated.

If the Web server is an IBM HTTP Server (IHS) and the IHS Administration server is installed and properly
configured, you can also:
v Display the IBM HTTP Server Error log (error.log) and Access log (access.log) files.
v Start and stop the server.
v Display and edit the IBM HTTP Server configuration file (httpd.conf).

If the Web server it is defined to an unmanaged node, you can:

v Check the status of the Web server
v Generate a plug-in configuration file for that Web server.

If the Web server is an IBM HTTP Server (IHS) and the IHS Administration server is installed and properly
configured, you can also:
v Display the IBM HTTP Server Error log (error.log) and Access log (access.log) files.
v Start and stop the server.
v Display and edit the IBM HTTP Server configuration file (httpd.conf).
v Propagate the plug-in configuration file after it is generated.

You can not propagate an updated plug-in configuration file to a non-IHS Web server that is defined to an
unmanaged node. You must manually install an updated plug-in configuration file to a Web server that is
defined to an unmanaged node. Web servers defined to an unmanaged node are typically remote Web
servers. Remote Web servers are Web servers that are not located on the same machine as the
WebSphere Application Server.

After you set up your Web server and Web server plug-in, whenever you deploy a Web application, you
must specify a Web server as the deployment target that serves as a router for requests to the Web
application. The configuration settings in the plug-in configuration file (plugin-cfg.xml) for each Web server

Chapter 1. Overview and new features for administering applications and their environments 9
are based on the applications that are routed through that Web server. If the Web server plug-in
configuration service is enabled, a Web server plug-in’s configuration file is automatically regenerated
whenever a new application is associated with that Web server.

Note: Before starting the Web server, make sure you are authorized to run any Application Response
Measurement (ARM) agent associated with that Web server.

Refer to your Web server documentation for information on how to administer that Web server. For tips on
tuning your Web server plug-in, see “Web server plug-in tuning tips” on page 137.

Introduction: Clusters
Clusters are groups of servers that are managed together and participate in workload management. A
cluster can contain nodes or individual application servers. A node is usually a physical computer system
with a distinct host IP address that is running one or more application servers. Clusters can be grouped
under the configuration of a cell, which logically associates many servers and clusters with different
configurations and applications with one another depending on the discretion of the administrator and what
makes sense in their organizational environments.

Clusters are responsible for balancing workload among servers. Servers that are a part of a cluster are
called cluster members. When you install an application on a cluster, the application is automatically
installed on each cluster member.

Because each cluster member contains the same applications, you can distribute client tasks in distributed
platforms according to the capacities of the different machines by assigning weights to each server.

In distributed platforms, assigning weights to the servers in a cluster improves performance and failover.
Tasks are assigned to servers that have the capacity to perform the task operations. If one server is
unavailable to perform the task, it is assigned to another cluster member. This reassignment capability has
obvious advantages over running a single application server that can become overloaded if too many
requests are made.

Node groups bound clusters. All cluster members of a given cluster must be members of the same node
group. For more information about clusters and node groups, see “Clusters and node groups” on page
269.

To learn more about clusters, see “Clusters and workload management” on page 268 and “Balancing
workloads with clusters” on page 268 for more information.

Core groups

A group of clusters can be defined as a core group. All of the application servers defined as a member of
one of the clusters included in a core group are automatically members of that core group. Individual
application servers that are not members of a cluster can also be defined as a member of a core group.
The use of core groups enables WebSphere Application Server to provide high availability for applications
that must always be available to end users. You can also configure core groups to communicate with each
other using the core group bridge. The core groups can communicate within the same cell or across cells.

To learn more about core groups, see “Setting up a high availability environment” on page 298.

Introduction: Environment
The environment of the product applies to the configuring of Web server plug-ins, variables, and objects
that you want consistent throughout a cell.

10 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Web servers

In the WebSphere Application Server product, an application server works with a Web server to handle
requests for Web applications. The application Server and Web server communicate using a WebSphere
HTTP plug-in for the Web server.

For more information, refer to “Introduction: Web servers” on page 9.

Cell-wide settings

Cell-wide settings are sets of configuration data that are stored in files in the cell directory. These
configuration files are replicated to every node in the cell. Several different configuration settings apply to
the entire cell. These settings include the definition of virtual hosts, shared libraries, and any variables that
must be consistent throughout the entire cell.

For more information, refer to “Introduction: Cell-wide settings.”

Variables

A variable is a configuration property that can be used to provide a parameter for any value in the system.
A variable has a name and a value to use in place of that name wherever the variable name is located
within the system.

For more information, refer to “Configuring WebSphere variables” on page 181.

Introduction: Cell-wide settings

The configuration data for WebSphere Application Server is stored in XML files. The XML files exist in one
of several directories in the configuration repository tree.

The directory in which a configuration file exists determines its scope, or how broadly or narrowly that data
applies. Files in an individual server directory apply to that specific server only. Files in a node-level
directory apply to every server on that node. Files in the cell directory apply to every server on every node
within the entire cell.

Cell-wide settings are configuration files in the cell directory. The files are replicated to every node in the
cell. Several different configuration settings apply to the entire cell. These settings include the definition of
virtual hosts, shared libraries, and any variables that you want consistent throughout the entire cell.

Chapter 1. Overview and new features for administering applications and their environments 11
12 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Chapter 2. How do I administer applications and their
environments?
v Establish the application serving environment
v Secure the application serving environment - see Security
v Set up Web access for applications
v Set up resources for applications to use
v Configure class loaders - see development and deployment
v Deploy and administer applications
v Use the administrative clients
v Troubleshoot deployment and administration

Legend for ″How do I?...″ links

Documentation Show me Tell me Guide me Teach me

Refer to the detailed Watch a brief View the presentation Be led through the Perform the tutorial
steps and reference multimedia for an overview console pages with sample code
demonstration
Approximate time: Approximate time: 3 Approximate time: Approximate time: Approximate time: 1
Varies to 5 minutes 10 minutes+ 1/2 hour+ hour+

Establish the application serving environment

The following tasks involve establishing application serving capability in your network environment,
whether you use single or clustered application servers. Servers can be grouped into administrative
domains known as nodes and cells.

See also the overview:

v Version 6 topology and terminology

--------------------------------------------------------------------------
Create WebSphere profiles
Profiles are the files that define a stand-alone Application Server node, a managed node, or a
deployment manager node. A profile also includes all of the files that the node can change.

Documentation Show me: Tell me

v Standalone node
v Deployment
manager
v Managed node

--------------------------------------------------------------------------
Administer nodes
A node is a grouping of managed servers. Use this task to view information about and manage
nodes.

© Copyright IBM Corp. 2004 13

Documentation Show me Tell me:
v Add and remove
nodes
v Manage node
groups
v Cell, deployment
managers, nodes,
and node agents

--------------------------------------------------------------------------
Administer node agents
Node agents are administrative agents that represent a node to your system and manage the
servers on that node. Node agents monitor application servers on a host system and route
administrative requests to servers. A node agent is created automatically when a node is added to
a cell.

Documentation Show me Tell me

--------------------------------------------------------------------------
Administer cells
When you installed the WebSphere Application Server Network Deployment product, a cell was
created. A cell provides a way to group one or more nodes of your Network Deployment product.
You probably will not need to reconfigure the cell. Use this task to view information about and
manage a cell.

Documentation Show me Tell me

--------------------------------------------------------------------------
Administer configurations
Application server configuration files define the available application servers, their configurations,
and their contents. You should periodically save changes to your administrative configuration. You
can change the default locations of configuration files, as needed.

Documentation Tell me:

v Repository
v Archives

--------------------------------------------------------------------------
Configure remote file services
Configuration data for the WebSphere Application Server product resides in files. Two services
help you reconfigure and otherwise manage these files: the file transfer service and file
synchronization service. By default, the file transfer service is always configured and enabled at a
node agent, so you do not need to take additional steps to configure this service. However, you
might need to configure the file synchronization service.

Documentation Tell me

--------------------------------------------------------------------------
Administer application servers

14 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 Create, configure, and operate application server processes. An application server configuration
provides settings that control how an application server provides services for running enterprise
applications and their components.

Documentation: Show me Tell me

v Console
v Scripting -
configure
v Scripting -
administer

--------------------------------------------------------------------------
Administer other server types
One step in the process of creating an application server is to specify a template. A server
template is used to define the configuration settings of the new server. You have the option of
specifying the default server template or choosing a template that is based on a server that
already exists. The default template will be used if you do not specify a different template when
you create the server.
You can create other types of servers, to represent Web servers in your topology, or for other
purposes. There are two types of generic servers: (1) Non-Java applications or processes, or (2)
Java applications or processes. A custom service provides the ability to plug into a WebSphere
application server to define a hook point that runs when the server starts and shuts down.

Documentation: Tell me: Guide me (Web

v Generic servers v Generic servers servers)
v Server templates v Templates
v Custom services v Custom services

--------------------------------------------------------------------------
Balance workloads by clustering application servers
To monitor application servers and manage the workloads of servers, use server clusters and
cluster members provided by the Network Deployment product.

Documentation: Show me Tell me:

v Console v Server, cluster
v Scripting members
v Creating cluster
members
v WLM details
v Data replication
service

--------------------------------------------------------------------------
Establishing high availability (HA) for failover
Planning ahead for high availability support is important in order to avoid the risk of a failure
without failover coverage. The application server runtime of the infrastructure managed by a high
availability manager includes such entities as cells and clusters. These components relate closely
to core groups, high availability groups, and the policy that defines the high availability
infrastructure. In a properly configured high availability environment, a high availability manager
can reassess the environment it is managing and accept new components as they are added to
the environment.

Chapter 2. How do I administer applications and their environments? 15

Documentation Tell me:
v Overview
v Details, core
groups

--------------------------------------------------------------------------
Administer the UDDI registry
The UDDI Registry is supplied as a J2EE application file, uddi.ear. Change its configuration
properties using the assembly tools. You can use either the WebSphere Application Server
administrative console or the Java Management Extensions (JMX) management interface to
manage UDDI Registries.

Documentation: Show me Tell me Teach me

v Configure
v Administer

--------------------------------------------------------------------------

Set up Web access for applications

These tasks involve enabling HTTP requests for applications on the application server.

--------------------------------------------------------------------------
Administer communication with Web servers (plug-ins)
The product provides plug-ins for supported Web servers, to enable the Web servers to pass
requests to the application server, for applications running on the application server. See also the
Web server related tasks in How do I install an application serving environment?.

Documentation: Show me Tell me Guide me

v Console
v Scripting

--------------------------------------------------------------------------
Administer HTTP sessions
Configure the service that the product provides for managing HTTP sessions: Session Manager.

Documentation: Show me
v Console
v Scripting

--------------------------------------------------------------------------
Administer IBM HTTP Server Version 6.x
The product provides a complementary Web server with its own documentation that can be
installed into the information center.
--------------------------------------------------------------------------

16 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Set up resources for applications to use

Make a variety of resources available to your applications that are deployed on the application server.

--------------------------------------------------------------------------
Provide access to naming and directory resources (JNDI)
Configure naming. Naming is used by clients of WebSphere Application Server applications to
obtain references to objects related to those applications, such as Enterprise JavaBeans (EJB)
homes. These objects are bound into a mostly hierarchical structure, referred to as a name space.
The name space structure consists of a set of name bindings, each consisting of a name relative
to a specific context and the object bound with that name.

Documentation: Show me Tell me

v Name server
v Bindings

--------------------------------------------------------------------------
Provide access to relational databases (JDBC resources)
Configure data sources that applications use to access the data from databases.

Documentation: Show me: Tell me Guide me

v Console v Cloudscape
v Scripting v DB2
v Oracle

--------------------------------------------------------------------------
Provide access to messaging resources (default messaging provider)
Use one of various ways to implement a messaging provider for use with WebSphere Application
Server. A messaging provider enables use of the Java Messaging Service (JMS) and other
message resources in the product.

Documentation: Show me Tell me Teach me

v Console
v Scripting

--------------------------------------------------------------------------
Use IBM service integration technologies

Tell me: Teach me

v Overview
v Architecture
v Mediation

--------------------------------------------------------------------------
Establish workload balancing and high availability (HA) of messaging engines

Tell me

--------------------------------------------------------------------------

Chapter 2. How do I administer applications and their environments? 17

Access Service Integration (SI) bus resources

Show me Tell me:

v Service integration
bus resources
v JMS resources for
service integration
bus

--------------------------------------------------------------------------

Deploy and administer applications

These tasks involve deploying applications onto the application server, then administering the applications.

--------------------------------------------------------------------------
Install applications
Installable modules include enterprise archive (EAR), enterprise bean (EJB), Web archive (WAR),
resource adapter (connector or RAR), and application client files.

Documentation Show me Tell me

v Console
v Scripting

--------------------------------------------------------------------------
Start and stop applications
You can start an application that is not running (has a status of Stopped) or stop an application
that is running (has a status of Started).

Documentation: Show me Tell me

v Console
v Scripting

--------------------------------------------------------------------------
Update applications
Update deployed applications or modules using the administrative console or wsadmin scripting.
Learn which changes are candidates for hot deployment and dynamic reloading, in which you can
make various changes to applications and their modules without having to stop the server and
start it again.

Documentation: Tell me Teach me

v Console
v Scripting

--------------------------------------------------------------------------
Deploy applications rapidly (WebSphere Rapid Deployment)
Take advantage of new rapid deployment capabilities. WebSphere rapid deployment offers the
following advantages: You do not need to assemble your J2EE application files prior to
deployment. You do not need to use other installation tools mentioned in this table to deploy the
files. Refer to the Rapid deployment tools documentation in the information center.

18 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 --------------------------------------------------------------------------
Enhanced EAR files

Tell me Teach me

--------------------------------------------------------------------------
Deploy and administer Web services applications
To deploy Web services that are based on the Web Services for Java 2 platform, Enterprise
Edition (J2EE) specification, you need an enterprise application, also known as an enterprise
archive (EAR) file that has been configured and enabled for Web services. You can use either the
administrative console or the wsadmin scripting interface to deploy an EAR file.

Documentation Show me Tell me Teach me

--------------------------------------------------------------------------

Use the administrative clients

A variety of tools are provided for administering the product.

--------------------------------------------------------------------------
Choose an administrative client
Learn about and decide among the available administrative clients, including a graphical console,
scripting (wsadmin), command line tools, and Java Management Extensions (JMX) programs.

Documentation Tell me

--------------------------------------------------------------------------
Use the administrative console
The administrative console is a Web-based tool that you use to administer the product. The
administrative console supports a full range of product administrative activities.

Documentation Show me Tell me

--------------------------------------------------------------------------
Use scripting (wsadmin)
Scripting is a non-graphical alternative that you can use to configure and manage WebSphere
Application Server. The WebSphere Application Server wsadmin tool provides the ability to run
scripts. The tool supports a full range of product administrative activities.

Documentation Tell me

--------------------------------------------------------------------------

See also:
v Start, stop, monitor processes
v Other administrative commands
v Custom Java administrative clients (JMX)

Chapter 2. How do I administer applications and their environments? 19

Troubleshoot deployment and administration

Troubleshoot problems that occur when you are deploying applications onto the application server, or
when you are administering an established application serving environment.

--------------------------------------------------------------------------
Troubleshoot deployment
Troubleshoot problems that occur either during deployment or shortly afterwards, when you try to
access an application that you just deployed for the first time.

Documentation

--------------------------------------------------------------------------
Troubleshoot administration
Review some possible causes, based on the error you are seeing.

Documentation

--------------------------------------------------------------------------

20 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Chapter 3. Setting up the application serving environment
This topic summarizes the contents of the documentation that helps you set up your application serving
environment. This information is for administrators, particularly those performing installation, customization,
and maintenance of topologies.
“Planning the installation (diagrams)”
In preparation for installation, this topic describes common product topologies that you can install
with WebSphere Application Server, Version 6 products.
“Configuring the product after installation” on page 47
This topic describes what to do after installing the product.
If you are using Network Deployment, you must configure a profile.
You can display the First Steps tool, an easy way to get started with the product.
“Configuring ports” on page 113
This topic provides information about port number settings for Version 6 and previous versions, for
use in coexistence and interoperability situations.
“Communicating with Web servers” on page 116
This topic describes how to install and configure WebSphere plug-ins for Web servers, enabling
communication between Web servers and application servers.
“Setting up the administrative architecture” on page 139
This topic describes how to set up logical administrative domains, including cells and nodes.
“Configuring the environment” on page 174
This topic describes how to configure cell-wide settings for virtual hosts, variables and shared
libraries to assist in handling requests among Web applications, Web containers, and application
servers.
“Working with server configuration files” on page 191
This topic describes how to change the default locations of configuration files, as needed.
Application server configuration files define the available application servers, their configurations,
and their contents.
“Administering application servers” on page 198
This topic describes how to configure individual application servers to provides services for running
enterprise applications and their components.
“Balancing workloads with clusters” on page 268
This topic describes how to configure clusters, which are sets of servers that are managed
together and participate in workload management.
“Setting up a high availability environment” on page 298
This topic describes planning ahead for high availability support, which is important in order to
avoid the risk of a failure without failover coverage. In a properly setup high availability
environment, a high availability manager can reassess the environment it is managing and accept
new components as they are added to the environment.

Planning the installation (diagrams)

This topic describes common product topologies that you can install with the product.

© Copyright IBM Corp. 2004 21

Use this topic to understand the capabilities of your product package. Knowing what you can do with the
product might influence how you install the product and other installable components on the product disc.

This topic describes topology diagrams and shows you how to create the topologies by showing what
components to install for each topology.

Phased installation roadmap

To install a Version 6 production environment, you install the following components:

v The WebSphere Application Server product on your product CD
v A supported Web server, such as the IBM HTTP Server V6 on the product CD
v A binary plug-in module for your Web server from the product CD

You can also use the product CD to install an application client environment on a client machine. Running
Java 2 Platform, Enterprise Edition (J2EE) and thin application clients that communicate with WebSphere
Application Server requires that elements of the Application Server are installed on the machine on which
the client runs. However, if the machine does not have the Application Server installed, you can install
Application Server clients to provide a stand-alone client run-time environment for your client applications.

You can use the Application Server Toolkit CD in the primary packet of discs to install a development
environment. Or you can use the Rational Application Developer Trial CD in the supplemental packet of
discs to install a fully integrated development environment that includes an exact replica of the Application
Server for development testing.

Installation features

Installation features in V6 include:

Feature Description
The Network Deployment product You can use the Profile creation wizard to create deployment manager profiles,
includes Application Server and Application Server profiles, and custom profiles after installing the WebSphere
managed nodes. Application Server Network Deployment product. You do not have to install
another set of binary files to install an Application Server. All profiles on a
machine share the core product files of the Profile creation wizard. (If you install
again to create another set of core product files, there are two Profile creation
wizards. One for each set of core product files.)
The product CD includes all of the You can use the product CD to install the IBM HTTP Server, the Web server
installable components that are plug-ins, and the WebSphere Application Server Clients. You do not have to use
required to create an e-business separate CDs. Separate installation programs exist within component directories
environment. on the product CD.
Each installable component has its You can use the V6 launchpad to install any installable component on the
own installation program. product CD. Or you can install each component directly using the install
command in each component directory.
The launchpad can install any The launchpad can also install the Application Server Toolkit on Windows 2000
installable product in the primary and Linux (Intel) systems. The Application Server Toolkit is on a separate disc,
packet of compact discs. which requires you to change discs to launch the installation.

Review topology diagrams for each of the following installable components to determine which topology
best fits your needs. The diagrams and their accompanying procedures can serve as a roadmap for
installing a similar topology.

This topic describes installation scenarios for the following installable components:
v WebSphere Application Server Network Deployment
v Web server plug-ins

22 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
v Application clients

In addition to product installation diagrams for the installable components, this topic also links to a
roadmap for using the Profile creation wizard, which is new for Version 6. The Profile creation wizard lets
you create run-time environments for application server processes.

Each of the following installation scenarios includes topology diagrams and associated installation steps.
Each step links to a specific procedure for installing a component or to a description of a command or tool.
1. Review the installation scenarios for the Network Deployment product, as described in “Planning to
install Network Deployment.”
2. Review the installation scenarios for the WebSphere Application Server plug-ins, as described in
“Planning to install Web server plug-ins” on page 31.
3. Review the installation scenarios for the application clients, as described in “Planning to install
WebSphere Application Server Clients” on page 38.
4. Review the installation scenarios for the Profile creation wizard, as described in “Planning to create
application server environments” on page 39.
5. Optional: Review interoperability and coexistence diagrams to know what is possible with Version 6.
WebSphere Application Server V6 can interoperate with your other e-business systems, including other
versions of WebSphere Application Server. Interoperability provides a communication mechanism for
WebSphere Application Server nodes that are at different versions. Coexistence describes multiple
versions or instances running on the same machine, at the same time.
Interoperability support enhances migration scenarios with more configuration options. It often is
convenient or practical to interoperate during the migration of a configuration from an earlier
WebSphere Application Server version to a later one when some machines are at the earlier version
and some machines are at the later version. The mixed environment of machines and application
components at different software version levels requires interoperability and coexistence.
It is often impractical, or even physically impossible, to migrate all the machines and applications within
an enterprise at the same time. Understanding multiversion interoperability and coexistence is
therefore an essential part of a migration between version levels.
See the following topics for more information:
a. Interoperating
b. Setting up Version 4.0.x and Version 6 coexistence
c. Setting up Version 5 and Version 6 coexistence
d. Setting up Version 6 coexistence
6. Optional: Consider performance when designing your network, as described in “Example: Choosing a
topology for better performance” on page 42 and “Queuing network” on page 43.

You can review installation scenarios to identify the specific steps to follow when installing more than one
component on a single machine or on separate machines.

After determining an appropriate installation scenario, you are ready to install the necessary components
and to configure the products for the system that you selected.

Planning to install Network Deployment

This topic describes common installation scenarios and links to component installation procedures.

In Version 6.0, installing WebSphere Application Server Network Deployment is a two-step process. The
first step is using the installation wizard to install a shared set of core product files. The second step is
using the Profile creation wizard to create a deployment manager profile, an Application server profile, or a
custom profile.

Chapter 3. Setting up the application serving environment 23

A profile is a separate data partition that includes the files that define a run-time environment for an
application server process.

A running application server process, such as a deployment manager, can create, read, update, or delete
the configuration files, data files, and log files in its profile. The application server process has read-only
access to the system files, which include command files and other shared product binary files. System files
are updated only by installing refresh packs or fix packs, or by products that extend WebSphere
Application Server Network Deployment.

Machine A

WebSphere Application Server Network Deployment, Version 6.0

Step 1: Install Product Step 2: Create profiles

Shared product binaries

Profiles
( system files )

Scenarios for installation

The following information describes scenarios for installing the product in various topologies on one or
more machines. Two types of WebSphere Application Server topologies are possible using the Network
Deployment product:
v Topologies for a stand-alone application server
v Topologies for a managed group of application servers

Topologies for a stand-alone application server

Each stand-alone application server has its own administrative console and runs independently of other
application servers.

The following topologies are described in this topic.

v Scenario 1: Single-machine installation of a stand-alone application server
v Scenario 2: Single-machine installation of a stand-alone application server and a Web server
v Scenario 3: Two-machine installation of a stand-alone application server and a Web server
v Scenario 4: Two-machine installation of multiple stand-alone application servers and a Web server

Topologies for a managed group of application servers

A managed group of application servers is called a cell. A cell consists of one deployment manager and
one or more federated application servers, which are called managed nodes.

A node becomes a managed node in either of two ways:

v Federating the node within an Application Server profile into the cell
v Federating the node within a custom profile into the cell

The deployment manager is the single point of administration for all of the managed nodes in the cell. The
deployment manager maintains the configuration files for nodes that it manages and deploys applications
to those managed nodes.

The following topologies for a cell are described in this topic.

24 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
v Scenario 5: Single-machine installation of a cell of application servers
v Scenario 6: Single-machine installation of a cell of application servers and a Web server
v Scenario 7: Two-machine installation of a cell of application servers and a Web server
v Scenario 8: Three-machine installation of a cell of application servers and a Web server

Each of the following scenarios includes a diagram and a list of detailed installation steps.

Some scenarios are more typical in production environments. For example, Scenario 1 supports a lighter
workload than Scenario 3 or Scenario 4. However, Scenario 1 is a fully functional environment. Scenarios
3 and 4 are typical production environments for a stand-alone application server. Scenario 8 is a typical
production scenario for a cell environment.
v Scenario 1: Install a stand-alone application server on a single machine.
Installing WebSphere Application Server Network Deployment by itself on a single machine lets you
create a stand-alone Application Server profile. Each stand-alone application server profile includes a
server1 application server process. Installing Network Deployment creates the set of system files. The
Profile creation wizard creates the profile for the application server. The profile is a separate data
partition with files that define the stand-alone application server environment.
In this scenario, the application server uses its internal HTTP transport chain for communication, which
is suitable for handling an application with a relatively low request work load. For example, this type of
installation can support a simple test environment or a departmental intranet environment.

Machine A

WebSphere Application Server, Version 6.0

Shared product binaries Profile01

( system files )

1. Install WebSphere Application Server Network Deployment.

2. Create an Application Server profile using the Profile creation wizard.
v Scenario 2: Install a stand-alone application server and a Web server on a single machine.
Installing a Web server, such as IBM HTTP Server, on the same machine as the application server
provides a more robust Web server environment. Installing a Web server plug-in is a requirement for the
Web server to communicate with the application server. This type of installation supports rigorous
testing environments or production environments that do not require a firewall. However, this is not a
typical production environment.

Machine A Data tier, optional

Web client Web server

Application
(browser)
Server
Plug-in
Application
data

1. Install WebSphere Application Server Network Deployment.

2. Create an Application Server profile using the Profile creation wizard.
3. Install IBM HTTP Server or another supported Web server.
4. Install the Web server plug-ins and configure the Web server using the Plug-ins installation wizard.

Chapter 3. Setting up the application serving environment 25

v Scenario 3: Install a stand-alone application server and a Web server on separate machines.
In the typical production environment, the application server on one machine communicates with a Web
server on a separate (remote) machine through the Web server plug-in. Optional firewalls can provide
additional security for the application server machine.
Firewall Firewall

Machine B Machine A Data tier, optional

Web server
Web client Application
(browser) Machine A
Server
Plug-in

Application
data

Internet Intranet

1. Install WebSphere Application Server Network Deployment on Machine A.

2. Create an Application Server profile using the Profile creation wizard on Machine A.
3. Install IBM HTTP Server or another supported Web server on Machine B.
4. Install the Web server plug-ins and configure the Web server using the Plug-ins installation wizard.
5. The Plug-ins installation wizard creates a script named configureWeb_server_name in the
plugins_install_root/bin directory on Machine B. Copy the script to the install_root/bin directory on
Machine A.
6. Run the configureWeb_server_name script to create a Web server definition in the administrative
console. You can then use the administrative console to manage the Web server.
7. Propagate the plugin-cfg.xml file from the application server to the Web server using the
administrative console. Click Servers > Web server > Propagate Plug-in. (Web servers other than
IBM HTTP Server require manual propagation.)
v Scenario 4: Install multiple stand-alone application servers on one machine and a Web server on a
separate machine.
The Profile creation wizard can create a deployment manager profile, an application server profile, or a
custom profile. Each profile is a separate data partition containing the files that define the run-time
environment. After creating a profile and installing a dedicated Web server, use the Plug-ins installation
wizard to install a plug-in and to update the Web server configuration file. The Web server can then
communicate with the application server.
This topology lets each profile have unique applications, configuration settings, data, and log files, while
sharing the same set of system files. Creating multiple profiles creates multiple application server
environments that you can dedicate to different purposes.
For example, each application server on a Web site can serve a different application. In another
example, each application server can be a separate test environment that you assign to a programmer
or a development team.
Updating the core product files
Another feature of having multiple profiles is enhanced serviceability. When a refresh pack or a fix pack
updates the core product files on a machine, all of the application server profiles that were created from
the core product files begin using the updated files. In some situations, you might prefer to not update
all of the application servers on a machine. In such situations, simply install the product a second time
to create a second set of core product files. Create application server profiles from both installations to
manage the product updates incrementally.

26 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 Firewall Firewall

Machine B Machine A Data tier, optional

Profile01
Web server
Application
Server 1
Plug-in
application 1
Web client Application
(browser) Machine A data

Profile02
Web server
Application
Application
Server
Server2
Plug-in application 2
Machine A

Internet Intranet

1. Install WebSphere Application Server Network Deployment on Machine A.

2. Create the first Application Server profile using the Profile creation wizard on Machine A.
3. Install IBM HTTP Server or another supported Web server on Machine B.
4. On Machine B, install the Web server plug-ins and configure the first Web server using the
Plug-ins installation wizard.
5. The Plug-ins installation wizard creates a script named configureWeb_server_name in the
plugins_install_root/bin directory on Machine B. Copy the script to the install_root/bin directory on
Machine A.
6. Run the configureWeb_server_name script to create a Web server definition in the administrative
console. You can then use the administrative console to manage the Web server.
7. Propagate the plugin-cfg.xml file from the application server to the Web server using the
administrative console. Click Servers > Web server > Propagate Plug-in. (Web servers other
than IBM HTTP Server require manual propagation.)
8. Create the second Application Server profile using the Profile creation wizard on Machine A. Make
the profile the default profile during the profile creation by selecting the check box on the
appropriate panel.
The script that the Plug-ins installation wizard creates works on the default profile only. So, this
script can only create a Web server definition on the profile that is the default profile at the time
that the script runs.
9. Install a second IBM HTTP Server or another supported Web server on Machine B.
10. On Machine B, install the Web server plug-ins to configure the second Web server using the
Plug-ins installation wizard. Both Web servers share a single installation of the plug-in binaries but
must be configured individually.
11. The Plug-ins installation wizard creates a script named configureWeb_server_name for the second
Web server. The script is in the plugins_install_root/bin directory on Machine B. Copy the script to
the install_root/bin directory on Machine A.
12. Run the configureWeb_server_name script to create a Web server definition in the administrative
console. You can then use the administrative console to manage the Web server.
13. Propagate the plugin-cfg.xml file from the second application server to the Web server using the
administrative console. Click Servers > Web server > Propagate Plug-in. (Web servers other
than IBM HTTP Server require manual propagation.)
v Scenario 5: Install a cell of managed application server nodes on one machine.
WebSphere Application Server Network Deployment can create a cell of managed application servers
on a single machine from one installation of the core product files. The Profile creation wizard creates
the deployment manager. After starting the deployment manager, return to the Profile creation wizard to
create one or more application servers for the cell. Application server profiles have a default application

Chapter 3. Setting up the application serving environment 27

 server, called server1, and default applications. An Application Server node becomes a managed node
after federating the node into the deployment manager cell.
The deployment manager provides the administration for all managed nodes that are in its cell.
Periodically the configuration and application files on a managed node refresh from the master copy of
the files hosted on the deployment manager during synchronization.
In certain secure environments, the Profile creation wizard cannot federate a custom profile into a cell.
Such cases require you to use the addNode command instead. If you have configured the deployment
manager to use a JMX connector type other than the default SOAP connector, use the addNode
command to add the node to the cell.
The deployment manager provides the administration for all managed nodes that are in its cell.
Periodically the deployment manager refreshes the configuration files and application files on the
managed node. Copying the master version of the files hosted on the deployment manager to the
managed nodes is a process called synchronization.
In a cell environment, only the managed nodes serve applications, not the deployment manager. The
managed node in this scenario uses its internal HTTP transport chain for communication, which is
suitable for an application with a relatively low request work load. For example, this type of installation
can support a simple test environment or a departmental intranet environment.
Machine A

Profile02 Profile01

server1 dmgr
( managed Node ( deployment
node ) agent manager )

1. Install WebSphere Application Server Network Deployment.

2. Create a deployment manager profile using the Profile creation wizard.
3. Start the deployment manager using the First steps console or the startManager command.
4. Create an Application Server profile using the Profile creation wizard.
5. Start the application server using the First steps console or the startServer server1 command.
6. Add the application server node to the cell using the administrative console of the deployment
manager. Click System Administration > Nodes to add the node.
v Scenario 6: Install a cell of managed application server nodes and a Web server on one machine.
Installing a Web server, such as IBM HTTP Server, on the same machine as the application server
provides a richer set of configuration options. Installing a Web server plug-in is required for the Web
server to communicate with the server in the managed node. This type of installation can support either
rigorous testing in a cell environment or production environments that do not require a firewall.
Machine A

dmgr
( deployment
manager )

Data tier, optional

Node agent

Web client Web server server1

(browser) ( managed
Plug-in node ) Application
data

1. Install WebSphere Application Server Network Deployment.

28 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 2. Create a deployment manager profile using the Profile creation wizard.
3. Start the deployment manager using the First steps console or the startManager command.
4. Create an Application Server profile using the Profile creation wizard.
5. Start the application server using the First steps console or the startServer server1 command.
6. Add the application server node to the cell using the administrative console of the deployment
manager. Click System Administration > Nodes to add the node.
7. Install IBM HTTP Server or another supported Web server.
8. Install the Web server plug-ins and configure the Web server using the Plug-ins installation wizard.
9. The Plug-ins installation wizard creates a script named configureWeb_server_name in the
plugins_install_root/bin directory. Run the configureWeb_server_name script to create a Web server
definition in the administrative console. You can then use the administrative console to manage the
Web server.
v Scenario 7: Install a cell of managed application server nodes on one machine and a Web server on a
separate machine.
In a typical production environment, a managed node in a cell communicates with a Web server on a
separate (remote) machine through the Web server plug-in. An optional firewall can provide additional
security for the application server machine.

Firewall

Machine A

dmgr
(deployment
manager )

Data tier, optional

Machine B Node agent

Web client Web server

server1
(browser) ( managed
Plug-in Application
node )
data

Internet Intranet

1. Install WebSphere Application Server Network Deployment on Machine A.

2. Create a deployment manager profile using the Profile creation wizard on Machine A.
3. Start the deployment manager using the First steps console or the startManager command on
Machine A.
4. Create the Application Server profile and make this profile the default profile using the Profile
creation wizard on Machine A.
5. Start the application server using the First steps console or the startServer server1 command on
Machine A.
6. Add the application server node to the cell using the administrative console of the deployment
manager on Machine A. Click System Administration > Nodes to add the node.
7. Install IBM HTTP Server or another supported Web server on Machine B.
8. On Machine B, install the Web server plug-ins and configure the Web server using the Plug-ins
installation wizard.
9. The Plug-ins installation wizard creates a script named configureWeb_server_name in the
plugins_install_root/bin directory on Machine B. Copy the script from Machine B to the
install_root/bin directory on Machine A.

Chapter 3. Setting up the application serving environment 29

 You have the option of using the script to create the Web server definition in the configuration of
the deployment manager or using the administrative console of the deployment manager to create
the Web server definition.
10. Run the configureWeb_server_name script on Machine A to create a Web server definition or use
the administrative console of the deployment manager to create the definition. You can then use
the administrative console to manage the Web server.
11. Propagate the plugin-cfg.xml file from the deployment manager on Machine A to the Web server
on Machine B using the administrative console. Click Servers > Web server > Propagate Plug-in.
(Web servers other than IBM HTTP Server require manual propagation.)
v Scenario 8: Install a deployment manager on one machine, multiple managed application server nodes
on a second machine, and a Web server on a third machine.
The primary advantage of a cell over a stand-alone application server is its scalability. Managing a cell
to keep it in proportion with workload levels is possible. In this scenario, managed nodes exist on
Machine C. All of the managed nodes are federated into the same deployment manager. Depending on
your needs, an application server in each managed node could serve the same or different applications.
Having multiple machines and multiple application server profiles lets you use vertical and horizontal
scaling:
– Vertical scaling creates multiple managed nodes on the same physical machine.
– Horizontal scaling creates cell members on multiple physical machines.
The managed nodes in this scenario communicate with the same Web server. However, the preferred
strategy is to have a dedicated Web server for each managed node.

Firewall
Machine A

dmgr
(deployment
manager )

Node Node
agent agent

server1 Data tier, optional

Machine B ( managed
node )

Web client Web server

server1
(browser) ( managed
Plug-in Application
node )
data

Machine C
Internet Intranet

1. Install WebSphere Application Server Network Deployment on Machine A.

2. Create a deployment manager profile using the Profile creation wizard on Machine A.
3. Start the deployment manager using the First steps console or the startManager command on
Machine A.
4. Install WebSphere Application Server Network Deployment on Machine C.
5. Create the first Application Server profile using the Profile creation wizard on Machine C.
6. Start the first application server using the First steps console or the startServer server1 command
on Machine C.
7. Create the second Application Server profile and make this profile the default profile using the
Profile creation wizard on Machine C.
30 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 8. Start the second Application Server using the First steps console or the startServer server1
command on Machine C.
9. Add both application server nodes to the cell using the administrative console of the deployment
manager on Machine A. Click System Administration > Nodes to add the nodes.
10.
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.ihs.doc/info/aes/ae/tihs_install.
or another supported Web server on Machine B.
11. Install the Web server plug-ins and configure the Web server using the Plug-ins installation wizard
on Machine B.
12. The Plug-ins installation wizard creates a script named configureWeb_server_name in the
plugins_install_root/bin directory on Machine B. Copy the script from Machine B to the
install_root/bin directory on Machine A.
You have the option of using the script to create the Web server definition in the configuration of
the deployment manager or using the administrative console of the deployment manager to create
the Web server definition.
13. Run the configureWeb_server_name script on Machine A to create a Web server definition or use
the administrative console of the deployment manager to create the definition. You can then use
the administrative console to manage the Web server.
14. Propagate the plugin-cfg.xml file from the deployment manager on Machine A to the Web server
on Machine B using the administrative console. Click Servers > Web server > Propagate Plug-in.
(Web servers other than IBM HTTP Server require manual propagation.)

You can review common installation scenarios to find a possible match for the topology that you intend to
install. Each product installation diagram provides a high-level procedure for installing the components that
comprise the topology.

After determining a possible topology, follow the steps in the overall procedure. Useful links to the
installation procedures for each installable component are in the list of related topics.

Planning to install Web server plug-ins

This topic describes common installation scenarios and links to component installation procedures for each
scenario.

The primary production configuration is an application server on one machine and a Web server on a
separate machine. This configuration is referred to as a remote configuration. Contrast the remote
configuration to the local configuration, where the application server and the Web server are on the same
machine.

The Plug-ins installation wizard has four main tasks:

v Installs the binary plug-in module on the Web server machine.
v Configures the Web server configuration file on the Web server machine to point to the binary plug-in
module and to the XML configuration file for the binary module.
v Installs a temporary XML configuration file for the binary module (plugin-cfg.xml) on the Web server
machine in remote scenarios.
v Creates the configuration for a Web server definition on the application server machine. The wizard
processes the creation of the Web server definition differently depending on the scenario:
Web server plug-in installation for stand-alone application server environments
– Recommended remote stand-alone Application Server installation:
Creates a configuration script that you run on the application server machine. Install the Web server
and its plug-in on a different machine than the application server. This configuration is recommended
for a production environment.
– Local stand-alone Application Server installation:

Chapter 3. Setting up the application serving environment 31

 Detects the default profile on a local application server machine and creates the Web server
definition for it directly. Install the Web server and its plug-in on the same machine with the
application server. This configuration is for development and test environments.
Web server plug-in installation for distributed environments (cells)
– Recommended remote distributed installation:
Creates a configuration script that you run on the application server machine. Install the Web server
and its plug-in on a different machine than the deployment manager or managed node. This
configuration is recommended for a production environment.
– Local distributed installation:
Creates a configuration script that you run when the deployment manager is running. Install the Web
server and its plug-in on the same machine with the deployment manager or a managed node. This
configuration is for development and test environments.

Select a link to go to the appropriate steps in the following procedure.

v Set up a remote Web server installation.
The remote Web server configuration is recommended for production environments.
The remote installation installs the Web server plug-in on the Web server machine when the application
server is on a separate machine, such as shown in the following graphic:

Firewall
optional

Machine B Machine A

WebSphere
Web server Application
Server

Plug-in

Remote installation scenario

Table 1. Installation and configuration
Step Machine Task
1 A Install your WebSphere Application Server product. See ″Installing the product and
additional software″ in the information center.
2 A Create an application server profile. See “Using the Profile creation wizard” on page 54.
3 B Install IBM HTTP Server or another supported Web server. See ″Installing IBM HTTP
Server″ in the information center.
4 B Install the binary plug-in module using the Plug-ins installation wizard. See ″Configuring
a Web server and an application server on separate machines (remote)″ in the
information center.

The script for creating and configuring the Web server is created under the
plug-ins_install_root/ bin directory.
5 B Copy the configureWeb_server_name script to Machine A. If one machine is running
under Linux or UNIX and the other machine is running under Windows, copy the script
from the plug-ins_install_root/ bin/ crossPlatformScripts directory.
6 A Paste the configureWeb_server_name script from Machine B to the was_install_root/
bin directory on Machine A.
7 A Run the script from a command line.

32 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Table 1. Installation and configuration (continued)
Step Machine Task
8 A Verify that the application server is running. Open the administrative console and save
the changed configuration.
9 B
Run the plug-ins_install_root/setupPluginCfg.sh script for a
Domino Web Server before starting a Domino Web server.Otherwise, start the Web
server.
10 B Run the snoop servlet. See ″Troubleshooting installation″ in the information center.

To verify with your own application, regenerate and propagate the plugin-cfg.xml file
after installing the application.

Regeneration of the plugin-cfg.xml file

During the installation of the plug-ins, the temporary plugin-cfg.xml file is installed on Machine B in the
plug-ins_install_root/ config/ web_server_name directory.
The Web server plug-in configuration service regenerates the plugin-cfg.xml file automatically.
To use the real plugin-cfg.xml file from the application server, propagate the plugin-cfg.xml file as
described in the next section.
Propagation of the plugin-cfg.xml file
The Web server plug-in configuration service propagates the plugin-cfg.xml file automatically for IBM
HTTP Server 6.0 only.
For all other Web servers, propagate the plug-in configuration file manually. Copy the plugin-cfg.xml
file from the profiles_install_root/ config/ cells/ cell_name/ nodes/ Web_server_name_node/
servers/ web_server_name directory on Machine A. Paste the file into the plug-ins_install_root/
config/ web_server_name directory on Machine B.
v Set up a local Web server configuration.
The local Web server configuration is recommended for a development or test environment.
A local installation includes the Web server plug-in, the Web server, and the application server on the
same machine:

Machine A

WebSphere
Web server Application
Server

Plug-in

Local installation scenario

Table 2. Installation and configuration
Step Machine Task
1 A Install your WebSphere Application Server product. See ″Installing the product and
additional software″ in the information center.
2 A Create an application server profile. See “Using the Profile creation wizard” on page 54.
3 A Install IBM HTTP Server or another supported Web server. See ″Installing IBM HTTP
Server″ in the information center.

Chapter 3. Setting up the application serving environment 33

Table 2. Installation and configuration (continued)
Step Machine Task
4 A Install the binary plug-in module using the Plug-ins installation wizard. See See
″Configuring a Web server and an application server on separate machines (remote)″
in the information center.

The Web server definition is automatically created and configured during the installation
of the plug-ins.
5 A Verify that the application server is running. Open the administrative console and save
the changed configuration.
6 B
Run the plug-ins_install_root/setupPluginCfg.sh script for a
Domino Web Server before starting a Domino Web server.Otherwise, start the Web
server.
7 B Run the Snoop servlet.

To verify with your own application, regenerate and propagate the plugin-cfg.xml file
after installing the application.

Regeneration of the plugin-cfg.xml file

The Web server plug-in configuration service regenerates the plugin-cfg.xml file automatically.
The plugin-cfg.xml file is generated in the profiles_install_root/ profile_name/ config/ cells/
cell_name/ nodes/ Web_server_name_node/ servers/ web_server_name directory. The generation occurs
when the Web server definition is created.
Propagation of the plugin-cfg.xml file
The local file does not require propagation.
v Set up a remote Web server installation in a cell.
The remote Web server configuration is recommended for production environments.
The remote installation installs the Web server plug-in on the Web server machine when the application
server is on a separate machine, such as shown in the following graphic:

Firewall
optional

Machine C Machine A

Deployment
Web server Manager

Federate
Plug-in Machine B

WebSphere
Application
Server node

Remote installation scenario

Table 3. Installation and configuration
Step Machine Task
1 A Install WebSphere Application Server Network Deployment. See ″Installing the product
and additional software″ in the information center.

34 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Table 3. Installation and configuration (continued)
Step Machine Task
2 A Create a deployment manager profile. See “Using the Profile creation wizard” on page
54.
3 A Start the deployment manager with the ./profiles_install_root/ profile_name/ bin/
startManager.sh command or its Windows equivalent.
4 B Install WebSphere Application Server Network Deployment. See ″Installing the product
and additional software″ in the information center.
5 B Create an application server profile. See “Using the Profile creation wizard” on page 54.
6 B Federate the node with the ./profiles_install_root/ profile_name/ bin/
addNode.sh dmgrhost 8879 -includeapps command or its Windows equivalent.
7 C Install IBM HTTP Server or another supported Web server. See ″Installing IBM HTTP
Server″ in the information center.
8 C Install the binary plug-in module using the Plug-ins installation wizard. See ″Configuring
a Web server and an application server on separate machines (remote)″ in the
information center.

The script for creating and configuring the Web server is created under the
plug-ins_install_root/ bin directory.
9 C Copy the configureWeb_server_name script to Machine A.

If one machine is running under Linux or UNIX and the other machine is running under
Windows, copy the script from the plug-ins_install_root/ bin/
crossPlatformScripts directory.
10 A Paste the configureWeb_server_name script from Machine C to the was_install_root/
bin directory on Machine A.
11 A Run the script from a command line after verifying that the deployment manager is
running.

If you have enabled security or changed the default JMX connector type, edit the script
and include the appropriate parameters on the wsadmin command.
12 A/B Use the administrative console of the deployment manager on Machine A to start the
application server on Machine B. Wait for synchronization to occur and save the new
configuration.
13 C
Run the plug-ins_install_root/setupPluginCfg.sh script for a
Domino Web Server before starting a Domino Web server.Otherwise, start the Web
server.
14 C Run the Snoop servlet.

To verify with your own application, regenerate and propagate the plugin-cfg.xml file
after installing the application.

Regeneration of the plugin-cfg.xml file

During the installation of the plug-ins, the temporary plugin-cfg.xml file is installed on Machine C in the
plug-ins_install_root/ config/ web_server_name directory.
The Web server plug-in configuration service regenerates the plugin-cfg.xml file automatically.
To use the real plugin-cfg.xml file from the application server, propagate the plugin-cfg.xml file as
described in the next section.
Propagation of the plugin-cfg.xml file
The Web server plug-in configuration service propagates the plugin-cfg.xml file automatically for IBM
HTTP Server 6.0 only.

Chapter 3. Setting up the application serving environment 35

 For all other Web servers, propagate the plug-in configuration file, by manually copying the
plugin-cfg.xml file from the profiles_install_root/ profile_name/ config/ cells/ cell_name/
nodes/ node_name/ servers/ web_server_name directory on Machine A to the plug-ins_install_root/
config/ web_server_name directory on Machine C.
v Set up a local distributed Web server configuration.
The local Web server configuration is recommended for a development or test environment.
A local distributed installation includes the Web server plug-in, the Web server, and the managed
application server on the same machine:

Machine B Machine A

Deployment
Web server Manager

Federate

WebSphere
Plug-in Application
Server node

Local distributed installation scenario

Table 4. Installation and configuration
Step Machine Task
1 A Install WebSphere Application Server Network Deployment. See ″Installing the product
and additional software″ in the information center.
2 A Create a deployment manager profile. See ″Installing the product and additional
software″ in the information center.
3 A Start the deployment manager with the profiles_install_root/ profile_name/ bin/
startManager.sh command or its Windows equivalent.
4 B Install WebSphere Application Server Network Deployment. See ″Installing the product
and additional software″ in the information center.
5 B Create an application server profile. See ″Installing the product and additional software″
in the information center.
6 B Federate the node with the ./profiles_install_root/ profile_name/ bin/addNode.sh
dmgrhost 8879 -includeapps command or its Windows equivalent.
7 B Install IBM HTTP Server or another supported Web server. See ″Installing IBM HTTP
Server″ in the information center.
8 B Install the binary plug-in module using the Plug-ins installation wizard. See ″Configuring
a Web server and an application server on separate machines (remote)″ in the
information center.

The script for creating and configuring the Web server is created in the
plug-ins_install_root/ bin directory.
11 B After verifying that the deployment manager is running on Machine A, run the
configureWeb_server_name script from a command line in the plug-ins_install_root/
bin directory on Machine B.

If you have enabled security or changed the default JMX connector type, edit the script
and include the appropriate parameters.

36 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Table 4. Installation and configuration (continued)
Step Machine Task
12 A/B Use the administrative console of the deployment manager on Machine A to start the
application server on Machine B. Wait for synchronization to occur and save the new
configuration.
13 B
Run the plug-ins_install_root/setupPluginCfg.sh script for a
Domino Web Server before starting a Domino Web server.Otherwise, start the Web
server.
14 B Run the Snoop servlet.

Regeneration of the plugin-cfg.xml file

The Web server plug-in configuration service regenerates the plugin-cfg.xml file automatically.
The plugin-cfg.xml file is generated at the location profiles_install_root/ profile_name/ config/
cells/ cell_name/ nodes/ node_name/ servers/ web_server_name directory, when the Web server
definition is created.
Regenerate the plugin-cfg.xml file in the Web server definition in the application server whenever the
configuration changes. The Web server has immediate access to the file whenever it is regenerated.
When the Web server plug-in configuration service (an administration service) is enabled on Machine A,
the plugin-cfg.xml file is automatically generated for all Web servers.
Propagation of the plugin-cfg.xml file
Node synchronization is used to propagate the plugin-cfg.xml file from Machine A to Machine B.
When the Web server plug-in configuration service (an administration service) is enabled on Machine A,
the plugin-cfg.xml file is automatically propagated for all Web servers.
Alternate configuration
This procedure describes installing the plug-ins on two machines. However, you can perform this
procedure on a single machine as shown in the following graphic. A local distributed installation also
includes the Web server plug-in, the Web server, the Application Server, and the deployment manager
on the same machine:

Client Optional HTTP server Deployment

HTTP manager
Plug-in
requests

Optional Node agent

Application server

You can set up a remote or local Web server by installing Application Server, the Web server, and then the
Web server plug-ins.

See Web server configuration for more information about the files involved in configuring a Web server.

See ″Editing Web server configuration files″ in the information center for details for information about the
logic behind the processing scenarios for the Plug-ins installation wizard.

See Editing Web server configuration files for information about how the Plug-ins installation wizard
configures supported Web servers.

Chapter 3. Setting up the application serving environment 37

See Installing Web server plug-ins for information about other installation scenarios for installing Web
server plug-ins.

Planning to install WebSphere Application Server Clients

This topic helps you examine typical topologies and uses for WebSphere Application Server Clients.

This topic is one in a series of topics described in “Planning the installation (diagrams)” on page 21.
Consider all of the planning scenarios that are mentioned in the parent article to determine the best
approach to installing your e-business network. This topic describes installing and using the WebSphere
Application Server Clients.

In a traditional client server environment, the client requests a service and the server fulfills the request.
Multiple clients use a single server. Clients can also access several different servers. This model persists
for Java clients except that now these requests use a client run-time environment.

In this model, the client application requires a servlet to communicate with the enterprise bean, and the
servlet must reside on the same machine as the WebSphere Application Server.

The Application Client for WebSphere Application Server, Version 6 now consists of the following models:
v ActiveX application client
v Applet client
v J2EE application client
v Pluggable and thin application clients

The following graphic shows a topology for installing the Application Client and using client applications:

38 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
The example shows two types of application clients installed in a topology that uses client applications to
access applications and data on Machine A:
v The ActiveX application client on Machine B is a Windows only client that uses the Java Native
Interface (JNI) architecture to programmatically access the Java virtual machine (JVM) API. The JVM
code exists in the same process space as the ActiveX application (Visual Basic, VBScript, or Active
Server Pages (ASP) files) and remains attached to the process until that process terminates.
v The J2EE application client on Machine C is a Java application program that accesses enterprise
beans, Java Database Connectivity (JDBC) APIs, and Java Message Service message queues. The
application program must configure the execution environment of the J2EE application client and use
the Java Naming and Directory Interface (JNDI) name space to access resources.

Use the following procedure as a roadmap for installing the Application Client.
1. Install the WebSphere Application Server product from your product CD on Machine A to establish the
core product files.
2. Use the Profile creation wizard to create both stand-alone application server profiles.
3. Use the administrative console of each application server to deploy any user applications.
4. Use the administrative console of each application server to create a Web server configuration for the
Web server.
5. Use the administrative console of each application server to regenerate each plugin-cfg.xml file in the
local Web server configuration.
6. Install the IBM HTTP Server from the product CD on Machine A.
7. Use the Plug-ins installation wizard to install the plug-in for IBM HTTP Server on Machine A.
The wizard automatically configures the HTTP Server to communicate with the first application server.
8. Install the Application Client from your product CD on Machine B.
a. Select the Custom install type.
b. Select the ActiveX to EJB Bridge feature.
c. Select to add the Java run time to the system path.
d. Select the Java run time as the default JRE, which adds the Java run time path to the beginning of
the system path.
9. Install the Application Client from your product CD on Machine C.
a. Select the Custom install type.
b. Select the J2EE application client feature.

This topic can help you plan run-time environments for client applications.

See “Application Client for WebSphere Application Server” on page 1038 for information about creating
client applications.

Planning to create application server environments

Application server profiles are the run-time environments for application server processes. This topic
describes common scenarios for creating application server profiles and provides links to profile creation
procedures for each scenario.

Install the core product files for a WebSphere Application Server product before using the Profile creation
wizard to create additional application server run-time environments.

This topic describes how to use the Profile creation wizard to install deployment managers, managed
nodes, and stand-alone application servers. Each profile for a deployment manager or an application
server is a run-time environment, with data files, configuration files, applications, and an administrative
console. The profile for a managed node is a special case that is dependent on the deployment manager
profile that owns the managed node.

Chapter 3. Setting up the application serving environment 39

1. Create a deployment manager, as described in “Using the Profile creation wizard to create a
deployment manager” on page 58.

The installation procedure gives you the option of creating a deployment manager during installation.
However, you can use the Profile creation wizard to create a deployment manager when one was not
created during installation. Or, you can create another deployment manager on a machine where a
deployment manager already exists.
2. Create a managed node, as described in “Using the Profile creation wizard to create a custom profile”
on page 70.
The installation procedure gives you the option of creating a managed node during installation.
However, you can use the Profile creation wizard to create a managed node when one was not
created during installation. Or, you can use the wizard to create more managed nodes on a machine
where a managed node already exists.
The first part of the process is to install the Network Deployment product to create the core product
files. Then you can use the Profile creation wizard to create a managed profile.

The next part of the process is to federate the managed profile into the deployment manager cell. This
changes the managed profile into a managed node.

40 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
A managed node has a nodeagent process but does not have Sample applications or an application
server process in contrast to a stand-alone application server, which has a server1 process and
applications, but does not have a nodeagent process.

Chapter 3. Setting up the application serving environment 41

 Start the nodeagent process to allow the administrative console of the deployment manager to create
server processes on the managed node.
3. Create a stand-alone application server, as described in “Using the Profile creation wizard to create an
application server” on page 84.

The installation procedure gives you the option of creating a stand-alone application server during
installation. However, you can use the Profile creation wizard to create a stand-alone application server
when one was not created during installation. Or, you can use the wizard to create more stand-alone
application servers on a machine where an application server already exists.
4. Create a deployment manager and a managed node on the same machine.
The installation procedure gives you the option of creating a deployment manager and managed node
on the same machine during installation. However, you can also use the Profile creation wizard to
create a deployment manager and a managed node at any time after installation of the core product
files. Or, you can use the wizard to create a managed node on a machine where a deployment
manager already exists.
Any time that you create two or more application server processes on one machine, verify that the
machine is capable of hosting both processes. See the hardware prerequisites on the IBM WebSphere
Application Server supported hardware, software, and APIs Web site.
a. Create a deployment manager, as described in “Using the Profile creation wizard to create a
deployment manager” on page 58.
b. Create a managed node, as described in “Using the Profile creation wizard to create a custom
profile” on page 70.

Use the Profile creation wizard after installing the core product files to create:
v A stand-alone application server environment
v A deployment manager environment
v Managed nodes for the deployment manager cell

After installing the core product files and using the Profile creation wizard to create your e-business
environment, you are ready to deploy applications to test the environment.

Example: Choosing a topology for better performance

WebSphere Application Server provides various Workload Management (WLM) topologies. Two topologies
were compared to show how the type of topology you choose can affect performance.

In this comparison, Topology A contains a Web server and a WebSphere Application Server plug-in in front
of a cluster of WebSphere Application Servers. Each cluster member contains a Web container and an
Enterprise JavaBeans (EJB) container. Topology B includes a Web server, a plug-in, and a Web container
in front of a cluster of EJB containers. In both topologies, Object Request Broker (ORB) pass by reference
is selected and the backend database is on a dedicated machine.

42 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Result: Topology A had 10% to 20% higher throughput than Topology B when running the Java 2 Platform,
Enterprise Edition Benchmark sample for WebSphere (Trade).

Note: You can download the Benchmark sample for WebSphere (Trade) from the following Web site:

http://www-306.ibm.com/software/webservers/appserv/was/performance.html

Topology A has an advantage because the Web container and EJB container are running in a single Java
virtual machine (JVM). In Topology B, the ORB pass by reference option is ignored between the Web
container cluster member and the EJB container member. In Topology A, the EJB container uses the same
thread passed from the Web container. The request does not have to be passed from one thread in one
JVM to another thread in another JVM.

In this test environment, Topology A had the advantage. However, many factors related to the application
and environment can influence your results.

Queuing network
WebSphere Application Server contains interrelated components that must be harmoniously tuned to
support the custom needs of your end-to-end e-business application. These adjustments help the system
achieve maximum throughput while maintaining the overall stability of the system. This group of
interconnected components is known as a queuing network. These queues or components include the
network, Web server, Web container, EJB container, data source, and possibly a connection manager to a
custom back-end system. Each of these resources represents a queue of requests waiting to use that
resource. Various queue settings include:
v IBM HTTP Server: MaxClients for UNIX and ThreadsPerChild for Windows NT and Windows 2000
systems described in “Web server tuning parameters” on page 133.
v Web container: Maximum size described in “Thread pool settings” on page 209,
MaxKeepAliveConnections and MaxKeepAliveRequests described in “HTTP transport custom
properties” on page 227.
v Tuning Object Request Brokers explained in “Tuning application servers” on page 265.
v Data source connection pooling and statement cache size are explained in the Developing and
deploying applications PDF.

Clients
Network

Web Servlet EJB Data

server engine container source

Database

Figure Reference 1: WebSphere queuing network

Most of the queues that make up the queuing network are closed queues. A closed queue places a limit
on the maximum number of requests present in the queue, while an open queue has no limit. A closed
queue supports tight management of system resources. For example, the Web container thread pool
setting controls the size of the Web container queue. If the average servlet running in a Web container
creates 10MB of objects during each request, a value of 100 for thread pools limits the memory consumed
by the Web container to 1GB.

Chapter 3. Setting up the application serving environment 43

In a closed queue, requests can be active or waiting. An active request is doing work or waiting for a
response from a downstream queue. For example, an active request in the Web server is doing work,
such as retrieving static HTML, or waiting for a request to complete in the Web container. A waiting
request is waiting to become active. The request remains in the waiting state until one of the active
requests leaves the queue.

All Web servers supported by WebSphere Application Server are closed queues, as are WebSphere
Application Server data sources. You can configure Web containers as open or closed queues. In general,
it is best to make them closed queues. EJB containers are open queues. If there are no threads available
in the pool, a new one is created for the duration of the request.

If enterprise beans are called by servlets, the Web container limits the number of total concurrent requests
into an EJB container, because the Web container also has a limit. The Web container limits the number of
total concurrent requests only if enterprise beans are called from the servlet thread of execution. Nothing
prevents you from creating threads and bombarding the EJB container with requests. Therefore, servlets
should not create their own work threads.

Queuing and clustering

Cloning application servers can be a valuable asset in configuring highly-scalable production
environments, especially when the application is experiencing bottlenecks that are preventing full CPU
utilization of symmetric multiprocessing (SMP) servers. When adjusting the WebSphere Application Server
system queues in clustered configurations, remember that when a server is added to a cluster, the server
downstream receives twice the load.

Clients
Network
Servlet
engine
Web Data
server source

Servlet
engine

Database

Figure Reference 1: Clustering and queuing

Two servlet engines are located between a Web server and a data source. It is assumed that the Web
server, servlet engines and data source, but not the database, are all running on a single SMP server.
Given these constraints, the following queue considerations must be made:
v Double the Web server queue settings to ensure ample work is distributed to each Web container.
v Reduce the Web container thread pools to avoid saturating a system resource like CPU or another
resource that the servlets are using.
v Reduce the data source to avoid saturating the database server.
v Reduce Java heap parameters for each instance of the application server. For versions of the Java
virtual machine (JVM) shipped with WebSphere Application Server, it is crucial that the heap from all
JVMs remain in physical memory. For example, if a cluster of four JVMs is running on a system,
enough physical memory must be available for all four heaps.

44 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Queue configuration tips
The following section outlines a methodology for configuring the WebSphere Application Server queues.
Moving the database server onto another machine or providing more powerful resources, for example a
faster set of CPUs with more memory, can dramatically change the dynamics of your system.

There are four tips for queuing:

v Minimize the number of requests in WebSphere Application Server queues.
In general, requests wait in the network in front of the Web server, rather than waiting in WebSphere
Application Server. This configuration only supports those requests that are ready for processing to
enter the queuing network. Specify that the queues furthest upstream or closest to the client are slightly
larger, and queues further downstream or furthest from the client are progressively smaller.

Clients
Network Arriving requests Arriving requests
200 75 50

Web Servlet Data

25
server engine source
(N=75) (N=50) (N=25)

125 25 25
Waiting requests Waiting requests Waiting requests
Database

Figure Reference 1: Upstream queuing network

Queues in the queuing network become progressively smaller as work flows downstream. When 200
client requests arrive at the Web server, 125 requests remain queued in the network because the Web
server is set to handle 75 concurrent clients. As the 75 requests pass from the Web server to the Web
container, 25 requests remain queued in the Web server and the remaining 50 are handled by the Web
container. This process progresses through the data source until 25 user requests arrive at the final
destination, the database server. Because there is work waiting to enter a component at each point
upstream, no component in this system must wait for work to arrive. The bulk of the requests wait in the
network, outside of WebSphere Application Server. This type of configuration adds stability, because no
component is overloaded.
You can then use the Edge Server to direct waiting users to other servers in a WebSphere Application
Server cluster.
v Draw throughput curves to determine when the system capabilities are maximized.
You can use a test case that represents the full spirit of the production application by either exercising
all meaningful code paths or using the production application. Run a set of experiments to determine
when the system capabilities are fully stressed or when it has reached the saturation point. Conduct
these tests after most of the bottlenecks are removed from the application. The goal of these tests is to
drive CPUs to near 100% utilization. For maximum concurrency through the system, start the initial
baseline experiment with large queues. For example, start the first experiment with a queue size of 100
at each of the servers in the queuing network: Web server, Web container and data source. Begin a
series of experiments to plot a throughput curve, increasing the concurrent user load after each
experiment. For example, perform experiments with one user, two users, five, 10, 25, 50, 100, 150 and
200 users. After each run, record the throughput requests per second, and response times in seconds
per request. The curve resulting from the baseline experiments resembles the following typical
throughput curve shown as follows:

Chapter 3. Setting up the application serving environment 45

 Throughput curve
Saturation point
60
Throughput requests per second

50

40

30

20

10
A B C
0
Light load zone Heavy load zone Buckle zone

Concurrent users
The WebSphere Application Server throughput is a function of the number of concurrent requests
present in the total system. Section A, the light load zone, shows that the number of concurrent user
requests increases, the throughput increases almost linearly with the number of requests. At light loads,
concurrent requests face very little congestion within the WebSphere Application Server system queues.
At some point, congestion starts to develop and throughput increases at a much lower rate until it
reaches a saturation point that represents the maximum throughput value, as determined by some
bottleneck in the WebSphere Application Server system. The most manageable type of bottleneck
occurs when the WebSphere Application Server machine CPUs become fully utilized because adding
CPUs or more powerful CPUs fixes the bottleneck.
In the heavy load zone or Section B, as the concurrent client load increases, throughput remains
relatively constant. However, the response time increases proportionally to the user load. That is, if the
user load is doubled in the heavy load zone, the response time doubles. At some point, represented by
Section C, the buckle zone, one of the system components becomes exhausted. At this point,
throughput starts to degrade. For example, the system might enter the buckle zone when the network
connections at the Web server exhaust the limits of the network adapter or if the requests exceed
operating system limits for file handles.
If the saturation point is reached by driving CPU utilization close to 100%, you can move on to the next
step. If the saturation CPU occurs before system utilization reaches 100%, it is likely that another
bottleneck is being aggravated by the application. For example, the application might be creating Java
objects causing excessive garbage collection bottlenecks in the Java code.
There are two ways to manage application bottlenecks: remove the bottleneck or clone the bottleneck.
The best way to manage a bottleneck is to remove it. You can use a Java-based application profiler,
such as Rational Application Developer, Performance Trace Data Visualizer (PTDV), Borland’s
Optimizeit, JProbe or Jinsight to examine overall object utilization.
v Decrease queue sizes while moving downstream from the client.
The number of concurrent users at the throughput saturation point represents the maximum
concurrency of the application. For example, if the application saturates WebSphere Application Server
at 50 users, using 48 users might produce the best combination of throughput and response time. This
value is called the Max Application Concurrency value. Max Application Concurrency becomes the
preferred value for adjusting the WebSphere Application Server system queues. Remember, it is
desirable for most users to wait in the network; therefore, queue sizes should increase when moving
downstream farther from the client. For example, given a Max Application Concurrency value of 48, start

46 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 with system queues at the following values: Web server 75, Web container 50, data source 45. Perform
a set of additional experiments adjusting these values slightly higher and lower to find the best settings.
To help determine the number of concurrent users, view the Servlet Engine Thread Pool and
Concurrently Active Threads metric in the Tivoli Performance Viewer.
v Adjust queue settings to correspond to access patterns.
In many cases, only a fraction of the requests passing through one queue enters the next queue
downstream. In a site with many static pages, a number of requests are fulfilled at the Web server and
are not passed to the Web container. In this circumstance, the Web server queue can be significantly
larger than the Web container queue. In the previous example, the Web server queue was set to 75,
rather than closer to the value of Max Application Concurrency. You can make similar adjustments when
different components have different execution times.
For example, in an application that spends 90% of its time in a complex servlet and only 10% of its time
making a short JDBC query, on average 10% of the servlets are using database connections at any
time, so the database connection queue can be significantly smaller than the Web container queue.
Conversely, if the majority of servlet execution time is spent making a complex query to a database,
consider increasing the queue values at both the Web container and the data source. Always monitor
the CPU and memory utilization for both the WebSphere Application Server and the database servers to
verify that the CPU or memory are not saturating.

Configuring the product after installation

This topic summarizes how to configure the application serving environment.

Use the First steps console to configure and test the WebSphere Application Server environment after
installation.

This procedure starts the second and final step of Network Deployment installation. This second step
creates and configures server processes by creating profiles.
1. At the end of product installation, select the Launch the Profile creation wizard check box to create
a deployment manager profile.
This step creates the deployment manager and the cell. Later steps in this procedure create an
Application Server profile and optionally, a custom profile.
See “Using the Profile creation wizard to create a deployment manager” on page 58.
2. Start the First steps console by selecting the check box on the last panel of the wizard.
The First steps console for the deployment manager profile can start automatically at the end of profile
creation. Select the check box on the last panel of the Profile creation wizard.
The First steps console is an easy way to start using the product. The console provides one-stop
access to the administrative console, Samples Gallery, Profile creation wizard, installation verification
test, Migration wizard, and other activities.
See the description of the “firststeps command” on page 48 for more information.
3. Click Installation verification on the First steps console.
The installation verification test starts the deployment manager process named dmgr and runs several
tests to verify that the dmgr process can start without error.
See “Using the installation verification test” on page 110 for more information.
4. Click Profile creation wizard on the First steps console to create an Application Server profile.
See “Using the Profile creation wizard to create an application server” on page 84.
5. Start the First steps console by selecting the check box on the last panel of the Profile creation wizard.
This First steps console belongs to the Application Server profile that you just created. Each profile has
its own First steps console.
6. Click Installation verification on the First steps console.

Chapter 3. Setting up the application serving environment 47

 The installation verification test starts the new Application Server process named server1 and runs
several tests to verify that the server1 process can start without error.
7. Federate the Application Server into the deployment manager cell.
If both server processes are running, use the administrative console of the deployment manager to add
the Application Server node into the cell.
Point your browser at http://localhost:9060/ibm/console for example, to start the administrative console.
Or start it from the First steps console of the deployment manager profile.
Log in and click System administration > Nodes > Add Node and follow the wizard to add the node
into the cell. You can use localhost for the Host field if both processes are on the same machine. The
SOAP port for the Application Server node is 8880 unless you changed the port during profile creation.
If the deployment manager is running, you can use the addNode command instead. See ″addNode
command″ in the information center.
8. Optional: Click Profile creation wizard on the First steps console to create a custom profile.
Verify that the deployment manager is running. The Profile creation wizard can federate the custom
node for you if the deployment manger is running.
Supply the host name and the SOAP port for the deployment manager while creating the custom
profile.
Choose to federate the custom node into the deployment manager cell. A custom profile must be part
of a cell.
Use the deployment manager to customize the node at your leisure. Add servers, add clusters, and
install applications on the node, for example.
See “Using the Profile creation wizard to create a custom profile” on page 70.

This procedure results in configuring and testing the Application Server environment.

See “Planning to install Network Deployment” on page 23 for diagrams of topologies that you can create
using the First steps console and the Profile creation wizard.

firststeps command
The firststeps command starts the First steps console.

The First steps console

The First steps console is a post-installation ease-of-use tool for directing WebSphere Application Server
elements from one place. Options display dynamically on the First steps console, depending on features
you install. With all of the options present, you can use the First steps console to start or stop the
application server, verify the installation, access the information center, access the administrative console,
launch the Migration wizard, or access the Samples gallery.

The First steps console for the Network Deployment product has several forms. A First steps console
exists for the product itself before the creation of any profiles. This version lets you start the Profile
creation wizard to get started defining a deployment manager and application servers for the cell. You can
also define stand-alone application servers. Each stand-alone application server has its own First steps
console. Each deployment manager has its own First steps console.

A prompt to launch the First steps console displays on the last panel of the Profile creation wizard.

You can also start the First steps console from the command line as described later.

The First steps console for the Network Deployment product has several forms. A console exists for the
product itself before the creation of any profiles. Options that display on the First steps console in the core
product files of the Network Deployment product include the following entries:

48 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Profile creation wizard
This option starts the Profile creation wizard. The wizard lets you create a deployment manager
profile, an application server profile, or a custom profile. A profile consists of files that define the
run-time environment for the deployment manager or the application server. Each environment has
its own administrative interface. A custom profile is an exception. A custom profile is an empty
node that you can federate into a deployment manager cell and customize. No default server
processes or applications are created for a custom profile.
Each deployment manager or application server profile has its own First steps console. The
location of the command to launch the First steps console is within the set of files in the profile. A
prompt to launch the First steps console that is associated with a profile displays on the last panel
of the Profile creation wizard.
Information center for WebSphere Application Server
This option links you to the online information center at the
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp IBM Web address.
Migration wizard
This option starts the Migration wizard. The Migration wizard is a new graphical interface to the
migration tools. The migration tools are described in ″WASPreUpgrade command″ and
″WASPostUpgrade command″ in the information center.
See ″Using the Migration wizard″ in the information center for more information about the
Migration wizard.
Exit This option closes the First steps console.

In addition to the generic First steps console for the Network Deployment product, other First steps
consoles exist for the deployment manager profile and the application server profile that the Network
Deployment product can create. Options that display on the First steps console for a deployment manager
include the following entries:
Installation verification
This option starts the installation verification test. The test consists of starting and monitoring the
deployment manager during its start up.
If this is the first time that you have used the First steps console since creating a deployment
manager profile, click Installation verification to verify that all is well with your installation. The
verification process starts the deployment manager.
If you select the Installation verification option, the Start the deployment manager option is
grayed out while the IVT is running.
The IVT provides the following useful information about the deployment manager:
v The deployment manager server name: dmgr
v The name of the profile
v The profile file path
v The type of profile: dmgr
v The cell name
v The node name
v The current encoding
v The port number for the administrative console
v Various informational messages that include the location of the SystemOut.log file and how
many errors are listed within the file
v A completion message

Chapter 3. Setting up the application serving environment 49

Start the deployment manager
This option displays when you use the Profile creation wizard to create a deployment manager.
This option toggles to Stop the deployment manager when the deployment manager is running.
After selecting the Start the deployment manager option, an output screen displays with status
messages. The success message informs you that the deployment manager is open for
e-business. Then the menu item changes to Stop the deployment manager.
If you select the Start the deployment manager option, the Installation verification option is
grayed out while the deployment manager is running.
Administrative console
This option is grayed out until the application server is running.
The administrative console is a configuration editor that runs in a Web browser. The administrative
console lets you work with XML configuration files for the deployment manager and all of the
application servers that are in the cell. To launch the administrative console, click Administrative
console. You can also point your browser to http://localhost:9060/ibm/console to start the
administrative console. Substitute your own host name in the address if the localhost variable does
not resolve correctly. As the administrative console opens, it prompts you for a login name. This is
not a security item, but merely a tag to identify configuration changes that you make during the
session. Secure signon is also available.
Profile creation wizard
This option starts the Profile creation wizard. The wizard lets you create a deployment manager
profile, an application server profile, or a custom profile. A profile consists of files that define the
run-time environment for the deployment manager or the application server. Each environment has
its own administrative interface. A custom profile is an exception. A custom profile is an empty
node that you can federate into a deployment manager cell and customize. No default server
processes or applications are created for a custom profile.
Each deployment manager profile has its own First steps console. The location of the command to
launch the First steps console is within the set of files in the profile. A prompt to launch the First
steps console that is associated with a profile displays on the last panel of the Profile creation
wizard.
Information center for WebSphere Application Server
This option links you to the online information center at the
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp IBM Web address.
Migration wizard
This option starts the Migration wizard. The Migration wizard is a new graphical interface to the
migration tools. The migration tools are described in ″WASPreUpgrade command″ and
″WASPostUpgrade command″ in the information center.
See ″Using the Migration wizard″ in the information center for more information about the
Migration wizard.
Exit This option closes the First steps console.

In addition to the generic First steps console and the First steps console for the deployment manager,
another First steps console exists for stand-alone application servers that you create with the Profile
creation wizard. Options that display on the First steps console for an application server profile include the
following entries:
Installation verification
This option starts the installation verification test. The test consists of starting and monitoring the
application server during its start up.
If this is the first time that you have used the First steps console since creating an application
server profile, click Installation verification to verify that all is well with your installation. The
verification process starts the application server.

50 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 If you select the Installation verification option, the Start the server option is grayed out while
the IVT is running.
The IVT provides the following useful information about the application server:
v The server name: server1
v The name of the profile
v The profile file path
v The type of profile: default
v The cell name
v The node name
v The current encoding
v The port number for the administrative console
v Various informational messages that include the location of the SystemOut.log file and how
many errors are listed within the file
v A completion message
Start the server
This option toggles to Stop the server when the application server is running.
After selecting the Start the server option, an output screen displays with status messages. The
success message informs you that the server is open for e-business. Then the menu item
changes to Stop the server.
If you select the Start the server option, the Installation verification option is grayed out while
the application server is running.
Administrative console
This option is grayed out until the application server is running.
The administrative console is a configuration editor that runs in a Web browser. The administrative
console lets you work with XML configuration files for the deployment manager and all of the
application servers that are in the cell. To launch the administrative console, click Administrative
console. You can also point your browser to http://localhost:9060/ibm/console to start the
administrative console. Substitute your own host name in the address if the localhost variable does
not resolve correctly. As the administrative console opens, it prompts you for a login name. This is
not a security item, but merely a tag to identify configuration changes that you make during the
session. Secure signon is also available.
Profile creation wizard
This option starts the Profile creation wizard. The wizard lets you create a deployment manager
profile, an application server profile, or a custom profile. A profile consists of files that define the
run-time environment for the deployment manager or the application server. Each environment has
its own administrative interface. A custom profile is an exception. A custom profile is an empty
node that you can federate into a deployment manager cell and customize. No default server
processes or applications are created for a custom profile.
Each application server profile has its own First steps console. The location of the command to
launch the First steps console is within the set of files in the profile. A prompt to launch the First
steps console that is associated with a profile displays on the last panel of the Profile creation
wizard.
Samples gallery
This option starts the Samples gallery. The option is grayed out until you start the application
server. The option displays when you have installed the Samples during installation.
From the First steps console, click Samples gallery to explore the application Samples.
Alternatively you can point your browser directly to http://localhost:9080/WSsamples. Substitute

Chapter 3. Setting up the application serving environment 51

 your own host name in the address if the localhost variable does not resolve correctly. The Web
address is case sensitive. Substitute your own host name in the address.
Information center for WebSphere Application Server
This option links you to the online information center at the
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp IBM Web address.
Migration wizard
This option starts the Migration wizard. The Migration wizard is a new graphical interface to the
migration tools. The migration tools are described in ″WASPreUpgrade command″ and
″WASPostUpgrade command″ in the information center.
See ″Using the Migration wizard″ in the information center for more information about the
Migration wizard.
Exit This option closes the First steps console.

The First steps console for a managed node has the same options as the generic First steps console for
the Network Deployment product.

Location of the command file

The location of the firststeps.sh or firststeps.bat script for any profile is:
v install_root/profiles/profile_name/firststeps/firststeps.sh
v install_root\profiles\profile_name\firststeps\firststeps.bat

The location of the firststeps command for the generic First steps console for the Network Deployment
product is:
v install_root/firststeps/firststeps.sh
v install_root\firststeps\firststeps.bat

Parameters

No parameters are associated with this command.

Syntax for the firststeps command

Use the following syntax for the command:

v ./firststeps.sh

v firststeps.bat

Usage tips

The following links exist on one of the First steps consoles for the Network Deployment product. Not all
links display on each First steps console. For example, the First steps console for the deployment
manager does not have the Samples Gallery option or the Start the server option.

Option Link
Installation verification Calls the ivt command.

The location of the installation verification test varies per platform:

v install_root/profiles/profile_name/bin/ivt.sh

v install_root\profiles\profile_name\bin\ivt.bat

52 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Option Link
Start the server Calls the startServer command.

The location of the startServer command varies per platform:

server1 install_root/profiles/profile_name/bin/startServer.sh

v install_root\profiles\profile_name\bin\startServer.bat
server1

When you have more than one application server on the same machine, the
command starts the same application server that is associated with the First
steps console.
Stop the server Calls the stopServer command.

The location of the stopServer command varies per platform:

server1 install_root/profiles/profile_name/bin/stopServer.sh

v install_root\profiles\profile_name\bin\stopServer.bat
server1
Start the deployment manager Calls the startManager command.

The location of the startManager command varies per platform:

install_root/profiles/profile_name/bin/startManager.sh
v install_root\profiles\profile_name\bin\startManager.bat

When you have more than one deployment manager on the same machine,
the command starts the same deployment manager that is associated with
the First steps console.
Stop the deployment manager Calls the stopManager command.

The location of the stopManager command varies per platform:

install_root/profiles/profile_name/bin/stopManager.sh
v install_root\profiles\profile_name\bin\stopManager.bat
Administrative console Opens the default browser to the http://localhost:9060/ibm/console Web
address.

When you have more than one application server on the same machine, the
port varies. The First steps console starts the administrative console that is
associated with the First steps console.

Chapter 3. Setting up the application serving environment 53

Option Link
Profile creation wizard Calls the pctplatform command.

The command is in the install_root/bin/ProfileCreator directory. The name

of the command varies per platform:

v pctAIX.bin

v pctHPUX.bin

v 64-bit platforms: pctHPUXIA64.bin

v pctLinux.bin

v 64-bit platforms: pct.bin S/390 platforms: pctLinux390.bin

v Power platforms: pctLinuxPPC.bin

v pctSolaris.bin

v pctWindows.exe

v 64-bit platforms: pctWindowsIA64.exe

Samples Gallery Opens the default browser to the http://localhost:9080/WSsamples Web
address.

If you do not install Samples, the option does not appear on the First steps
console. If you do not install the Samples during the initial installation of the
product, the option does not display on the First steps console. You can
perform an incremental installation to add the Samples feature. After adding
the Samples, the options displays on the First steps console.

When you have more than one profile on the same machine, the port
varies. The First steps console starts the Samples gallery that is associated
with the First steps console.
Information center for WebSphere Opens the default browser to the online information center at the
Application Server products http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp Web address.
Migration wizard Calls the migration command.

The location of the migration command is:

v install_root/bin/migration.sh

v install_root\bin\migration.bat

The migration tools are also in the /migration folder on the product disc.

Using the Profile creation wizard

This topic describes how to create run-time environments for WebSphere Application Server. Each
run-time environment is created within a profile. A profile is the set of files that define the run-time
environment. The Profile creation wizard creates the profile for each run-time environment.

Before using the Profile creation wizard, install the core product files.

The Profile creation wizard is the wizard interface to the profile creation tool, wasprofile. See the
description of the “wasprofile command” on page 96 for more information.

54 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
An error can occur when you have not provided enough system temporary space to create a profile. Verify
that you have a minimum of 40 MB of temp space available before creating a profile.

You must have 200 MB of available disk space in the directory where you create an Application Server
profile.

Important:

You must have 30 MB of available disk space in the directory where you create a deployment
manager profile.

You must have 10 MB of available disk space in the directory where you create a custom
profile.

Manually verify that the required space for creating a profile is available on AIX. A known
problem in the underlying InstallShield for Multiplatforms (ISMP) code prevents proper space checking on
AIX systems at the time that the product disc was created.

Important: Concurrent profile creation is not supported at this time for one set of core product files.
Concurrent attempts to create profiles result in a warning about a profile creation already in
progress.

The installation procedure for the Network Deployment product does not create a run-time environment by
default because three possibilities exist. After installing the core product files for the Network Deployment
product, use the Profile creation wizard to create any combination of the following three profiles to have an
operational run-time environment:
v A deployment manager profile.
See “Using the Profile creation wizard to create a deployment manager” on page 58. Create this
run-time environment first, to create the administrative node for a multinode, multimachine group of
application server nodes that you create later. This logical group of application server processes is
known as a cell.
v An application server profile.
See “Using the Profile creation wizard to create an application server” on page 84.
When you create the application server profile, a default server1 process is created. The process has all
of the Sample applications and its own administrative console. You can federate the server1 node into
the deployment manager cell with the addNode command or from the administrative console of the
deployment manager. The server1 process must be running to begin the federation from the deployment
manager.
If you include all of the applications from the application server, the act of federation installs the
applications on the deployment manager where they can be redeployed.
Optionally, you can create stand-alone application servers by creating an application server profile and
not federating the node. If you remove a federated application server node from a deployment manager,
the application server returns to its original configuration, which is a stand-alone application server.
v A custom profile.
See “Using the Profile creation wizard to create a custom profile” on page 70. A custom profile is an
empty node that you can customize through the deployment manager to include application servers,
clusters, or other Java processes, such as a messaging server. Create a custom profile on a distributed
machine and add the node into the deployment manager cell to get started customizing the node.

Each use of the Profile creation wizard or the wasprofile command line tool creates one profile.
1. Install the product to create the core product files.
2. Start the Profile creation wizard to create a new run-time environment.

Chapter 3. Setting up the application serving environment 55

 Several ways exist to start the wizard. The initial way to start the wizard is at the end of installation by
selecting the check box to launch the Profile creation wizard.
One way to start the wizard is to issue the command directly from a command line.
The command is in the install_root/bin/ProfileCreator directory. The name of the command varies
per platform:

v pctAIX.bin

v pctHPUX.bin

v 64-bit platforms: pctHPUXIA64.bin

v pctLinux.bin

v 64-bit platforms: pct.bin S/390 platforms: pctLinux390.bin

v Power platforms: pctLinuxPPC.bin

v pctSolaris.bin

v pctWindows.exe

v 64-bit platforms: pctWindowsIA64.exe

Another way to start the Profile creation wizard is to select the wizard from the First steps console.
a. Open a command window.
b. Change directories to the firststeps directory in the installation root directory:
The installation root varies by platform:

v /usr/IBM/WebSphere/AppServer/firststeps

v /opt/IBM/WebSphere/AppServer/firststeps

v C:\Program Files\IBM\WebSphere\AppServer\firststeps
c. Issue the firststeps command to start the console:

v ./firststeps.sh

v firststeps.bat
d. Select the Profile creation wizard option on the console.
The Profile creation wizard is an InstallShield for Multiplatforms application. The wizard loads the
Java 2 SDK and then displays its Welcome panel.
See the description of the “firststeps command” on page 48 for more information.
3. Create a profile.
You can create profiles in any order. However, to create a functioning cell in the shortest possible time,
create a deployment manager profile first. Then create an application server profile and add it to the
deployment manager cell. You now have a functioning cell with a managed node that you can manage
from the administrative console of the deployment manager.
A custom profile requires a greater amount of customization. When you create a custom profile, you
must use the addNode command to federate it into the deployment manager cell. In contrast to an
application server profile, a custom profile does not have a default application server on its node. The
server1 application server does not exist by default on the custom node. Nor are there any default
applications on the custom node. Use the administrative console of the deployment manager to
customize the empty node for production or other uses. You can create application servers or clusters
on the node, for example.
Create any of the following profiles:
v Create a deployment manager.

56 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 See “Using the Profile creation wizard to create a deployment manager” on page 58.
Create a deployment manager to establish a cell. Although you can create an application server
profile and use it as a stand-alone application server, you must have a deployment manager to use
a custom profile. So there is no point in creating a custom profile until you have created a
deployment manager.
v Create an application server profile, as described in “Using the Profile creation wizard to create an
application server” on page 84.
Federate the application server into the deployment manager cell to create a federated server1
application server. A stand-alone application server has default applications. You can include the
applications as you federate the application server to install the default applications on the
deployment manager.
Two methods exist for federating application servers into a deployment manager cell:
– Start the deployment manager and the application server and use the administrative console of
the deployment manager to federate the node. Click System administration > Nodes > Add
node > Managed node > Next and identify the host name and the SOAP port of the machine
where you created the application server.
– Start the deployment manager. Go to the install_root/profiles/profile_name/bin directory of the
application server and issue the addNode command. See ″addNode command″ in the
information center for more information.
v Create a custom profile, as described in “Using the Profile creation wizard to create a custom
profile” on page 70.
The first part of the process is to install the Network Deployment product to create the core product
files. Then you can use the Profile creation wizard to create a managed profile.
The next part of the process is to federate the managed profile into the deployment manager cell.
This changes the custom profile into a managed node.
After federation, a custom profile has a nodeagent process but does not have an application server
process. Contrast this situation to an application server profile that has a server1 process, but does
not have a nodeagent process until you federate the node.
Start the nodeagent process to allow the administrative console of the deployment manager to
create server processes on the managed node.
Two methods exist for federating a custom node into a deployment manager cell:
– Federate the custom node during custom profile creation, either with the wizard or as the wizard
runs in silent mode.
The deployment manager must be running and accessible at the host address you supply. The
deployment manager must also use the default JMX connector type, which is SOAP. The
deployment manager must not have security enabled. If any of these conditions are not met, do
not federate the custom profile as you create it, but federate it later with the addNode command.
Otherwise, you create a faulty profile that you must move or delete from the profiles repository
directory before creating another profile.
– Use the addNode command to federate the custom node after you create the custom profile.
a. Start the deployment manager.
b. Go to the install_root/profiles/profile_name/bin directory of the custom profile and issue
the addNode command.
c. Within the same directory, issue the startNode command. See ″startNode command″ in the
information center for more information.
After federation, go to the administrative console of the deployment manager to customize the
empty node.
v Create a deployment manager and a managed node on the same machine:
a. Create a deployment manager, as described in “Using the Profile creation wizard to create a
deployment manager” on page 58.

Chapter 3. Setting up the application serving environment 57

 b. Start the deployment manager with the startManager command. See ″startManager command″
in the information center for more information.
c. Create an application server profile, as described in “Using the Profile creation wizard to create
an application server” on page 84.
d. Start the application server with the startServer command. See ″startServer command″ in the
information center for more information.
e. Use the administrative console of the deployment manager to add the application server node
into the deployment manager cell. Click System administration > Nodes > Add node >
Managed node > Next and identify the host name of the machine and the SOAP port of the
application server.
The SOAP port is identified in the
install_root/profiles/profile_name/config/cells/cell_name/nodes/node_name/serverindex.xml
file. You can also use the administrative console of the application server to view its SOAP port
setting. Click Servers > Application servers > server1 > Ports. The SOAP port is usually the
second port in the list.
Select the check box to include applications that are installed on the application server. The
default application has the snoop servlet and the hitcount servlet, which are useful for testing.
Adding the stand-alone application server node to the deployment manager node changes the
server1 process into a managed node. Use the administrative console of the deployment
manager to configure the server1 process.
You can also create a custom profile and federate the node during profile creation, or use the
addNode command to federate the empty node into the cell after the custom profile exists. A
managed node created from a custom profile requires customization to create an application
server and install applications. Use the administrative console of the deployment manager to
configure the custom node.

See the description of the “wasprofile command” on page 96 to learn more about the command-line
alternative method of creating a profile, and to see examples of using the command.

See “Planning the installation (diagrams)” on page 21 for examples of configurations that you can create
by creating profiles.

Using the Profile creation wizard to create a deployment manager

This topic describes creating a run-time environment for a deployment manager.

Before using the Profile creation wizard, install the core product files.

The Profile creation wizard is the wizard interface to the profile creation tool, wasprofile. See the
description of the “wasprofile command” on page 96 for more information.

An error can occur when you have not provided enough system temporary space to create a profile. Verify
that you have a minimum of 40 MB of temp space available before creating a profile.

You must have 200 MB of available disk space in the directory where you create an Application Server
profile.

You must have 30 MB of available disk space in the directory where you create a deployment manager
profile.

You must have 10 MB of available disk space in the directory where you create a custom profile.

Manually verify that the required space for creating a profile is available on AIX. A known
problem in the underlying InstallShield for Multiplatforms (ISMP) code prevents proper space checking on
AIX systems at the time that the product disc was created.

58 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
After installing the core product files, you must create one of the following profiles to have an operational
run-time environment:
v An application server that is described in this topic.
An application server profile has a default server (which is server1), the default application that includes
the snoop servlet and the hitcount servlet, and application Samples. You can federate the application
server or use it as a stand-alone application server.
v A deployment manager.
The deployment manager provides a single administrative interface to a logical group of application
servers on one or more machines.
v A custom profile that you must federate to make operational.
A custom profile is an empty node that you can customize to include application servers, clusters, or
other Java processes, such as a messaging server.

This procedure describes creating a deployment manager profile. The procedure uses the graphical user
interface provided by the Profile creation wizard. You can use the Profile creation wizard in silent mode
with a response file, without the graphical user interface. See “responsefile.pct.NDdmgrProfile.txt” on page
63 for examples of using the Profile creation wizard in silent mode.

You can also use the wasprofile command to create a deployment manager. See the description of the
“wasprofile command” on page 96 for more information.
1. Start the Profile creation wizard to create a new run-time environment.
Several ways exist to start the wizard. The initial way to start the wizard is at the end of installation by
selecting the check box to launch the Profile creation wizard.
One way to start the wizard is to issue the command directly from a command line.
The command is in the install_root/bin/ProfileCreator directory. The name of the command varies
per platform:

v pctAIX.bin

v pctHPUX.bin

v 64-bit platforms: pctHPUXIA64.bin

v pctLinux.bin

v 64-bit platforms: pct.bin S/390 platforms: pctLinux390.bin

v Power platforms: pctLinuxPPC.bin

v pctSolaris.bin

v pctWindows.exe

v 64-bit platforms: pctWindowsIA64.exe

Another way to start the Profile creation wizard is to select the wizard from the First steps console.
a. Open a command window.
b. Change directories to the firststeps directory in the installation root directory:
The installation root varies by platform:

v /usr/IBM/WebSphere/AppServer/firststeps

v /opt/IBM/WebSphere/AppServer/firststeps

v C:\Program Files\IBM\WebSphere\AppServer\firststeps
c. Issue the firststeps command to start the console:

Chapter 3. Setting up the application serving environment 59

 v ./firststeps.sh

v firststeps.bat
d. Select the Profile creation wizard option on the console.
The Profile creation wizard is an InstallShield for Multiplatforms application. The wizard loads the
Java 2 SDK and then displays its Welcome panel.
See the description of the “firststeps command” on page 48 for more information.
2. Click Next on the Welcome panel.
The wizard displays the Profile type selection panel.
3. Select the type of profile to create and click Next. In this example, select the option for creating a
deployment manager and click Next.
The wizard displays the Profile name panel.
4. Specify a name for the profile, then click Next.
Profile naming guidelines: The profile name can be any unique name with the following restrictions.
Do not use any of the following characters when naming your profile:
v Spaces
v Illegal special characters that are not allowed within the name of a directory on your operating
system, such as *&?
v Slashes (/) or (\)
Double-byte characters are allowed.
The default profile
The first profile that you create on a machine is the default profile. The default profile is the default
target for commands issued from the bin directory in the product installation root. When only one
profile exists on a machine, every command works on the only server process in the configuration.
Addressing a profile in a multi-profile environment
When two or more profiles exist on a machine, certain commands require that you specify the profile
to which the command applies. These commands use the -profileName parameter to identify which
profile to address. You might find it easier to use the commands that in the bin directory of each
profile.
A command in the profiles/profile_name/bin directory has two lines. The first line sets the
WAS_USER_SCRIPT environment variable for the command window. The variable sets up the
command environment to address the profile. The second line calls the actual command in the
install_root/bin directory.
The actual command queries the command shell to determine the calling profile and to autonomically
address the command to the calling profile.
The wizard then displays the Profile directory panel.
5. Accept the default directory, specify a non-default location, or click Browse to select a different
location. Click Next.
If you click Back and change the name of the profile, you must manually change the name on this
panel when it displays again.
The wizard displays the Node, host, and cell name panel.
6. Specify a unique node name, the actual host name of the machine, and a unique cell name. Click
Next.
The deployment manager node has the following characteristics.

60 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Field name Default value Constraints Description
Node name The name of your machine, Use a unique name for the The name is used for
or a unique derivation of the deployment manager. administration within the
machine name. deployment manager cell.
See the following note.
Host name The DNS name of your The host name must be Use the actual DNS name or IP
machine. addressable through your address of your machine to
network. enable communication with your
machine. See additional
See the following note. information about the host name
that follows this table.
Cell name The arbitrary name of the Use a unique name for the All federated nodes become
deployment manager cell. deployment manager cell. If you members of the deployment
The cell is a logical grouping plan to migrate a V5 manager cell, which you name
of managed nodes, under the deployment manager cell to this in this panel.
control of the deployment V6 deployment manager, use
manager. the same cell name as the V5
deployment manager.

See the following note.

Reserved names: Avoid using reserved folder names as field values. The use of reserved folder
names can cause unpredictable results. The following words are reserved:
v cells
v nodes
v servers
v clusters
v applications
v deployments
Node and cell name considerations

The profiles directory path must be no longer than 80 characters.

Host name considerations
The host name is the network name for the physical machine on which the node is installed. The host
name must resolve to a physical network node on the server. When multiple network cards exist in
the server, the host name or IP address must resolve to one of the network cards. Remote nodes use
the host name to connect to and to communicate with this node. Selecting a host name that other
machines can reach within your network is extremely important. Do not use the generic localhost
identifier for this value.
If you define coexisting nodes on the same computer with unique IP addresses, define each IP
address in a domain name server (DNS) look-up table. Configuration files for stand-alone Application
Servers do not provide domain name resolution for multiple IP addresses on a machine with a single
network address.
The value that you specify for the host name is used as the value of the hostName property in
configuration documents for the stand-alone Application Server. Specify the host name value in one of
the following formats:
v Fully qualified domain name servers (DNS) host name string, such as
xmachine.manhattan.ibm.com
v The default short DNS host name string, such as xmachine
v Numeric IP address, such as 127.1.255.3
The fully qualified DNS host name has the advantage of being totally unambiguous and also flexible.
You have the flexibility of changing the actual IP address for the host system without having to
change the Application Server configuration. This value for host name is particularly useful if you plan

Chapter 3. Setting up the application serving environment 61

 to change the IP address frequently when using Dynamic Host Configuration Protocol (DHCP) to
assign IP addresses. A format disadvantage is being dependent on DNS. If DNS is not available, then
connectivity is compromised.
The short host name is also dynamically resolvable. A short name format has the added ability of
being redefined in the local hosts file so that the system can run the Application Server even when
disconnected from the network. Define the short name to 127.0.0.1 (local loopback) in the hosts file to
run disconnected. A format disadvantage is being dependent on DNS for remote access. If DNS is
not available, then connectivity is compromised.
A numeric IP address has the advantage of not requiring name resolution through DNS. A remote
node can connect to the node you name with a numeric IP address without DNS being available. A
format disadvantage is that the numeric IP address is fixed. You must change the setting of the
hostName property in Express configuration documents whenever you change the machine IP
address. Therefore, do not use a numeric IP address if you use DHCP, or if you change IP addresses
regularly. Another format disadvantage is that you cannot use the node if the host is disconnected
from the network.
After specifying deployment manager characteristics, the wizard displays the Port value assignment
panel.
7. Verify that the ports specified for the deployment manager are unique and click Next.

The wizard displays the Windows service definition panel.

8. Choose whether to run the dmgr process as a Windows service on a Windows platform
and click Next.
Version 6 attempts to start Windows services for dmgr processes started by a startManager
command. For example, if you configure a deployment manager as a Windows service and issue the
startManager command, the wasservice command attempts to start the defined service.
If you chose to install a local system service, you do not have to specify your user ID or password. If
you create a specified user type of service, you must specify the user ID and the password for the
user who is to run the service. The user must have Log on as a service authority for the service to
run properly.
To perform this installation task, the user ID must not have spaces in its name. The ID must also
belong to the administrator group and must have the advanced user rights Act as part of the
operating system and Log on as a service. The Installation wizard grants the user ID the advanced
user rights if it does not already have them, if the user ID belongs to the administrator group.
You can also create other Windows services after the installation is complete, to start other server
processes. See “Automatically restarting server processes” on page 244 for more information.
The wizard displays the Profile summary panel.
9. Click Next to create the deployment manager or click Back to change the characteristics of the
deployment manager.
The wizard displays a Status panel during the creation of the profile. When the installation is
complete, the wizard displays the Profile creation is complete panel.
10. Click Finish to exit and then click Profile creation wizard on the First steps console to start the
wizard again, if you intend to create an application server profile.

You can create a deployment manager profile. The node within the profile has a deployment manager
named dmgr.

Refer to the description of the “wasprofile command” on page 96 to learn about creating this type of profile
using a command instead of a wizard.

Create an application server profile and add the node into the cell. Then you are ready to deploy an
application.

62 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Deploy an application to get started!

See Fast paths for WebSphere Application Server to get started deploying applications.

responsefile.pct.NDdmgrProfile.txt:

This topic describes the response file for creating a deployment manager profile.

Create a deployment manager profile with an options response file after logging on as root on a Linux or
UNIX platform, or as a user that belongs to the administrator group on a Windows platform. Some steps of
the installation procedure on a Windows platform require the user to belong to the administrator group and
to have the advanced user rights Act as part of the operating system and Log on as a service.

The response file is shipped with default values.

A common use for an options file is to run the Installation wizard in silent mode, which is referred to as
installing silently. The wizard reads the options file to determine responses and does not display the
graphical user interface. Issue the following command to use a copy of the options file named
myresponsefile.txt for a silent installation:
pctWindows.exe -options "myresponsefile.txt" -silent

Avoiding the use of the -silent option within the options response file

A problem occurs when the -silent option exists in the file. The file works with the option during a direct
call to the profile creation wizard, but fails when called from a silent product installation. See ″Customizing
the options response file for Network Deployment″ in the information center for information about creating
a profile silently during a silent product installation.

The option is unnecessary. Avoid using the option to avoid problems.

Response file locations

The example options response files are in two locations.

Example files:
v responsefile.pct.NDdmgrProfile.txt
v responsefile.pct.NDmanagedProfile.txt
v responsefile.pct.NDstandAloneProfile.txt

Location:
Table 5. Option response file locations
Product disc location Installed location
/WAS directory install_root/bin/ProfileCreator directory

Use the file on the product disc to install the Network Deployment product silently and create a profile.

After installing the Network Deployment product, you can use the installed response file with the -options
parameter on the Profile creation wizard command.

Chapter 3. Setting up the application serving environment 63

Required disk space

Profile Required disk space Required temp space

Deployment manager profile 30 MB 40 MB
Custom profile 10 MB 40 MB
Application server profile 200 MB 40 MB

Creating an operational environment during product installation

Version 6 installation of the Network Deployment product is a two-step process:

1. Installing the core product files and feature files.
2. Creating a deployment manager profile, a custom profile, or an application server profile.

The sample options response file, responsefile.nd.txt, controls the first part of the installation and can also
start the second part of the installation. To create a profile as part of installing the core product files, use
the option in the responsefile.nd.txt file that identifies the response file for creating a profile. The profile
response file lets you use the Profile creation wizard silently.

To edit and use the appropriate response file for creating a profile, perform the following procedure:
1. Copy the appropriate file from the WAS directory on the product disc to a place that you can easily
identify on your machine. The example files are:

To create a: Copy the following response file:

Deployment manager profile responsefile.pct.NDdmgrProfile.txt
Custom profile responsefile.pct.NDmanagedProfile.txt
Application server profile responsefile.pct.NDstandAloneProfile.txt

2. Edit the file to customize the values for your installation.

3. Verify that no -silent option exists in the response file for the Profile creation wizard. If the option
exists, the profile is not created.
4. Save the file.
5. Edit the responsefile.nd.txt file to identify the location and name of the profile response file. Change
the value of the -W pctresponsefilelocationqueryactionInstallWizardBean.fileLocation option to identify
the file. For example:
-W pctresponsefilelocationqueryactionInstallWizardBean.fileLocation=
"/opt/IBM/WebSphere/MyOptionFiles/customProfile.txt"
6. Start the installation. For example:
install -options "myresponsefile.txt" -silent
7. After the installation, examine the logs for success.

Creating a profile after installation

Version 6 installation of the Network Deployment product is a two-step process:

1. Installing the core product files and feature files
2. Creating a deployment manager profile, a custom profile, or an application server profile

When the core product files exist, create a profile at any time using the Profile creation wizard. Start the
wizard from the First steps console or directly using the Profile creation wizard command.

64 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
You can also use one of the following sample options response files for profiles to create a profile silently
using the Profile creation wizard in silent mode. To edit and use the appropriate response file for creating a
profile, perform the following procedure:
1. Copy the appropriate file from the install_root/bin/ProfileCreator directory to a place that you can
easily identify on your machine. The example files are:

To create a profile for a: Copy the following response file:

Deployment manager responsefile.pct.NDdmgrProfile.txt
Managed node responsefile.pct.NDmanagedProfile.txt
Stand-alone application server responsefile.pct.NDstandAloneProfile.txt

For example, copy the file as my_options_file.txt

2. Edit the file to customize the values for your installation.
3. Save the file.
4. Start the installation.
For example:

v ./pctAIX.bin -options my_options_file.txt -silent

v ./pctHPUX.bin -options my_options_file.txt -silent

v 64-bit platforms: ./pctHPUXIA64.bin -options my_options_file.txt -silent

v ./pctLinux.bin -options my_options_file.txt -silent

v 64-bit platforms: ./pct.bin -options my_options_file.txt -silent

v Power platforms: ./pctLinuxPPC.bin -options my_options_file.txt -silent

v S/390 platforms: ./pctLinux390.bin -options my_options_file.txt -silent

v ./pctSolaris.bin -options my_options_file.txt -silent

v pctWindows.exe -options my_options_file.txt -silent

v 64-bit platforms: pctWindowsIA64.exe -options my_options_file.txt -silent

5. After using the Profile creation wizard, examine the logs for success.

Logging

The following log files record information about profile creation:

v The install_root/logs/log.txt file records installation status.
v The install_rootprofiles/profile_name/logs/pctLog.txt file records installation events that occur when
creating profiles with the Profile creation wizard.
v The install_root/logs/wasprofile/wasprofile_create_profile_name.log file records installation events
that occur when creating profiles.
v The install_root/logs/wasprofile/wasprofile_delete_profile_name.log file records installation events
that occur when deleting profiles.

See ″Troubleshooting installation″ in the information center for more information.

Usage notes
v The file is not a read-only file.
v Edit this file directly with your flat file editor of choice, such as WordPad on a Windows platform.

Chapter 3. Setting up the application serving environment 65

v The file is updated when you specify the -options parameter when using the Profile creation wizard and
the file does not yet exist.
v The file must exist to perform a silent installation. The installation program reads this file to determine
installation option values when you install silently.
v Save the file in a location that you can identify when you specify the fully qualified path as part of the
profile creation command.

Naming considerations

Consider the following recommendations when supplying names for the profile and other objects.

Naming the profile

Use the following guidelines when supplying a value for the profile name directive:
-W profilenamepanelInstallWizardBean.profileName

Profile naming guidelines: The profile name can be any unique name with the following restrictions. Do
not use any of the following characters when naming your profile:
v Spaces
v Illegal special characters that are not allowed within the name of a directory on your operating system,
such as *&?
v Slashes (/) or (\)

Double-byte characters are allowed.

Avoiding reserved names

Avoid the following reserved folder names as values for the directives in the
responsefile.pct.NDstandAloneProfile.txt file and in the responsefile.pct.NDmanagedProfile.txt file:
-W nodehostnamepanelInstallWizardBean.nodeName=""
-W nodehostnamepanelInstallWizardBean.hostName=""
-W setnondmgrcellnameinglobalconstantsInstallWizardBean.value=""

Avoid the following reserved folder names as values for the directives in the
responsefile.pct.NDdmgrProfile.txt file:
-W nodehostandcellnamepanelInstallWizardBean.nodeName=""
-W nodehostandcellnamepanelInstallWizardBean.hostName=""
-W nodehostandcellnamepanelInstallWizardBean.cellName=

Reserved names: Avoid using reserved folder names as field values. The use of reserved folder names
can cause unpredictable results. The following words are reserved:
v cells
v nodes
v servers
v clusters
v applications
v deployments

Node and cell name considerations

The profiles directory path must be no longer than 80 characters.

Host name considerations

66 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
The host name is the network name for the physical machine on which the node is installed. The host
name must resolve to a physical network node on the server. When multiple network cards exist in the
server, the host name or IP address must resolve to one of the network cards. Remote nodes use the host
name to connect to and to communicate with this node. Selecting a host name that other machines can
reach within your network is extremely important. Do not use the generic localhost identifier for this value.

If you define coexisting nodes on the same computer with unique IP addresses, define each IP address in
a domain name server (DNS) look-up table. Configuration files for stand-alone Application Servers do not
provide domain name resolution for multiple IP addresses on a machine with a single network address.

The value that you specify for the host name is used as the value of the hostName property in
configuration documents for the stand-alone Application Server. Specify the host name value in one of the
following formats:
v Fully qualified domain name servers (DNS) host name string, such as xmachine.manhattan.ibm.com
v The default short DNS host name string, such as xmachine
v Numeric IP address, such as 127.1.255.3

The fully qualified DNS host name has the advantage of being totally unambiguous and also flexible. You
have the flexibility of changing the actual IP address for the host system without having to change the
Application Server configuration. This value for host name is particularly useful if you plan to change the IP
address frequently when using Dynamic Host Configuration Protocol (DHCP) to assign IP addresses. A
format disadvantage is being dependent on DNS. If DNS is not available, then connectivity is
compromised.

The short host name is also dynamically resolvable. A short name format has the added ability of being
redefined in the local hosts file so that the system can run the Application Server even when disconnected
from the network. Define the short name to 127.0.0.1 (local loopback) in the hosts file to run disconnected.
A format disadvantage is being dependent on DNS for remote access. If DNS is not available, then
connectivity is compromised.

A numeric IP address has the advantage of not requiring name resolution through DNS. A remote node
can connect to the node you name with a numeric IP address without DNS being available. A format
disadvantage is that the numeric IP address is fixed. You must change the setting of the hostName
property in Express configuration documents whenever you change the machine IP address. Therefore, do
not use a numeric IP address if you use DHCP, or if you change IP addresses regularly. Another format
disadvantage is that you cannot use the node if the host is disconnected from the network.

Example responsefile.pct.NDdmgrProfile.txt file

################################################################################
#
# Response file for Websphere Application Server 6.0 dmgr profile creation
#
# This options file is located in the CD_ROOT\WAS\ directory and in the
# install_root\bin\ProfileCreator directory.
#
# To use the options file under CD_ROOT\WAS\ directory, follow the instructions
# in CD_ROOT\WAS\responsefile.nd.txt. The WebSphere Application Server
# Network Deployment installer locates this file during silent installation
# and automatically runs the silent profile creation at the end of installation.
#
# To use the options file under install_root\bin\ProfileCreator for silent profile
# creation, you must change various values in the file and use the following
# command line arguments:
#
# -options "responsefile.pct.NDdmgrProfile.txt" -silent
#
################################################################################

Chapter 3. Setting up the application serving environment 67

################################################################################
#
# Profile name
#
# Set the profile name for installing a deployment manager profile. The profile
# name must be unique for this WebSphere Application Server installation.
#
-W profilenamepanelInstallWizardBean.profileName="profileDmgr"

################################################################################
# If you want to set this profile to be your default profile, set to "true".
# Otherwise set to "false". If this is the first profile being created, the profile
# automatically is the default.
#
-W profilenamepanelInstallWizardBean.isDefault="false"

################################################################################
#
# Profile location
#
# Specify a directory to contain the files that define the run-time environment,
# such as commands,configuration files, and log files. If the directory contains
# spaces, enclose it in double-quotes as shown in the Windows example below.
#
# Note that spaces in the install location is only supported on Windows
# operating systems.
#
# Default Install Location:
#
# -P installLocation="<WAS_HOME>\profiles\<PROFILE_NAME>"
#
-P installLocation="C:\Program Files\IBM\WebSphere\AppServer\profiles\profileDmgr"

################################################################################
#
# Node name
#
# Please select the node name for the Application Server. Node name under one cell
# has to be unique.
#
# Replace YOUR_NODE_NAME with the actual node name.
#
-W nodehostandcellnamepanelInstallWizardBean.nodeName="YOUR_NODE_NAME"

################################################################################
#
# Host name
#
# Specify the host name for the Application Server. The host name is the domain
# name system (DNS) name (short or long) or the IP address of this computer.
#
# Replace YOUR_HOST_NAME with the actual host name. Comment the line to use
# the default value.
#
-W nodehostandcellnamepanelInstallWizardBean.hostName="YOUR_HOST_NAME"

################################################################################
#
# Cell name
#
# Specify the cell name for the Application Server.
#
# If you plan to migrate a V5 deployment manager cell to this V6 deployment
# manager, specify the same cell name as the V5 cell.

68 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
#
# Replace YOUR_CELL_NAME with the actual cell name.
#
-W nodehostandcellnamepanelInstallWizardBean.cellName="YOUR_CELL_NAME"

################################################################################
#
# Port value assignment
#
# The following entries are used to reset port numbers used in the configuration
#
# They are currently set to the defaults.
# Please check to make sure there are no Port Conflicts.
# Port nubmers for each profile can be found in:
# <profile>/config/cells/<cell name>/nodes/<node name>/serverindex.xml
#
-W pctdmgrprofileportspanelInstallWizardBean.WC_adminhost="9060"
-W pctdmgrprofileportspanelInstallWizardBean.WC_adminhost_secure="9043"
-W pctdmgrprofileportspanelInstallWizardBean.BOOTSTRAP_ADDRESS="9809"
-W pctdmgrprofileportspanelInstallWizardBean.SOAP_CONNECTOR_ADDRESS="8879"
-W pctdmgrprofileportspanelInstallWizardBean.SAS_SSL_SERVERAUTH_LISTENER_ADDRESS="9404"
-W pctdmgrprofileportspanelInstallWizardBean.CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS="9406"
-W pctdmgrprofileportspanelInstallWizardBean.CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS="9405"
-W pctdmgrprofileportspanelInstallWizardBean.ORB_LISTENER_ADDRESS="9101"
-W pctdmgrprofileportspanelInstallWizardBean.CELL_DISCOVERY_ADDRESS="7277"
-W pctdmgrprofileportspanelInstallWizardBean.DCS_UNICAST_ADDRESS="9352"

################################################################################
#
# Windows service
#
# The following directives are to install services for WebSphere Application Server
# on Windows.
# Using Services, you can start and stop services,
# and configure startup and recovery actions.
# Set winServiceQuery="false" will turn off the function on windows system.
# You can ignore these or comment them out for other Operating Systems.
#
-W winservicepanelInstallWizardBean.winServiceQuery="true"

################################################################################
# Specify account type of the service. Legal values are:
#
# localsystem - Indicates that you choose to use Local System account.
# specifieduser - Indicates that you choose to use specified user account.
#
-W winservicepanelInstallWizardBean.accountType="localsystem"

################################################################################
# If you chose to install a service above with the accountType="localsystem",
# the userName and password below can be ignored. If the accountType was set to:
# accountType="specifieduser", then you must specify the User Name and Password
# which are required to install the Services. The current user must be admin or must
# have admin authority to install a Service. Also the username
# which is given here must have "Log On as a Service " authority
# for the service to run properly.
#
# Replace YOUR_USER_NAME with your username.
#
-W winservicepanelInstallWizardBean.userName="YOUR_USER_NAME"

################################################################################
# Replace YOUR_PASSWORD with your valid password.
#
-W winservicepanelInstallWizardBean.password="YOUR_PASSWORD"

Chapter 3. Setting up the application serving environment 69

################################################################################
# Set the startup type of the WebSphere Application Server on Windows.
# Valid values are "automatic", "manual", and "disabled".
#
-W winservicepanelInstallWizardBean.startupType="manual"

################################################################################
# Profile type
#
# Must be set to "dmgr" for installing a deployment manager Profile.
# Do not change this!
#
-W profiletypepanelInstallWizardBean.selection="dmgr"

Using the Profile creation wizard to create a custom profile

This topic describes creating a run-time environment for a custom profile.

Before using the Profile creation wizard, install the core product files.

The Profile creation wizard is the wizard interface to the profile creation tool, wasprofile. See the
description of the “wasprofile command” on page 96 for more information.

An error can occur when you have not provided enough system temporary space to create a profile. Verify
that you have a minimum of 40 MB of temp space available before creating a profile.

You must have 200 MB of available disk space in the directory where you create an Application Server
profile.

Manually verify that the required space for creating a profile is available on AIX. A known
problem in the underlying InstallShield for Multiplatforms (ISMP) code prevents proper space checking on
AIX systems at the time that the product disc was created.

After installing the core product files for the Network Deployment product, you must create one of the
following profiles to have an operational run-time environment:
v A custom profile.
This topic describes creating a custom profile. A custom profile is an empty node that you can
customize to include application servers, clusters, or other Java processes, such as a messaging
server.
You must have 10 MB of available disk space in the directory where you create a custom profile.
v A deployment manager.
See “Using the Profile creation wizard to create a deployment manager” on page 58. The deployment
manager provides a single administrative interface to a logical group of application servers on one or
more machines.
You must have 30 MB of available disk space in the directory where you create a deployment manager
profile.
v An application server profile.
See “Using the Profile creation wizard to create an application server” on page 84. An Application
Server profile has a default server (which is server1), the default application that includes the snoop
servlet and the hitcount servlet, and application Samples. You can federate the Application Server or
use it as a stand-alone Application Server.
You must have 200 MB of available disk space in the directory where you create an Application Server
profile.

70 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
This topic describes creating a custom profile using the Profile creation wizard. You can use the Profile
creation wizard in silent mode with a response file instead of the graphical user interface. See
“responsefile.pct.NDmanagedProfile.txt” on page 75 for examples of using the Profile creation wizard in
silent mode.

You can also use the wasprofile command to create a custom profile. See the description of the
“wasprofile command” on page 96 for more information.

After creating a custom profile, you must have access to a running deployment manager to federate the
node. Federating the custom profile makes the node operational. If the custom profile is on a machine that
does not have a deployment manager, the deployment manager must be accessible over the network to
allow the federation of the node.

You can federate the custom node as you create the custom profile, either with the Profile creation wizard
or when using the wasprofile command. If you choose to federate, but the deployment manager is not
running, the custom node is not usable. You must then either delete the profile directory or move the
directory out of the profiles repository (profiles installation root directory) before creating another profile
with the same name.
1. Install the product to create the core product files.
2. Start the Profile creation wizard to create a new run-time environment.
Several ways exist to start the wizard. The initial way to start the wizard is at the end of installation by
selecting the check box to launch the Profile creation wizard.
One way to start the wizard is to issue the command directly from a command line.
The command is in the install_root/bin/ProfileCreator directory. The name of the command varies
per platform:

v pctAIX.bin

v pctHPUX.bin

v 64-bit platforms: pctHPUXIA64.bin

v pctLinux.bin

v 64-bit platforms: pct.bin S/390 platforms: pctLinux390.bin

v Power platforms: pctLinuxPPC.bin

v pctSolaris.bin

v pctWindows.exe

v 64-bit platforms: pctWindowsIA64.exe

Another way to start the Profile creation wizard is to select the wizard from the First steps console.
a. Open a command window.
b. Change directories to the firststeps directory in the installation root directory:
The installation root varies by platform:

v /usr/IBM/WebSphere/AppServer/firststeps

v /opt/IBM/WebSphere/AppServer/firststeps

v C:\Program Files\IBM\WebSphere\AppServer\firststeps
c. Issue the firststeps command to start the console:

v ./firststeps.sh

Chapter 3. Setting up the application serving environment 71

 v firststeps.bat
d. Select the Profile creation wizard option on the console.
The Profile creation wizard is an InstallShield for Multiplatforms application. The wizard loads the
Java 2 SDK and then displays its Welcome panel.
See the description of the “firststeps command” on page 48 for more information.
3. Click Next on the Welcome panel.
The wizard displays the Profile type selection panel.
4. Select Create a custom profile and click Next.
The wizard displays the Custom-profile federation panel.
5. Specify the host name and SOAP port of the deployment manager and click Next.
After federation, the process in the custom profile is the nodeagent process. The nodeagent process
is the agent of the deployment manager for the custom node. The nodeagent responds to commands
from the deployment manager to perform tasks that include the following actions:
v Creating application server processes, clusters, and cluster members
v Starting and stopping application server processes
v Synchronizing configurations between the current edition on the deployment manager and the copy
that exists on the node
v Deleting application server processes
See the system administration section of the information center for more information about node
agents and their tasks.
Should you federate the node?
Federate the custom node at this time if the deployment manager is running. Select the check box to
federate the node at a later time if the deployment manager is not running.
If you are unsure whether the deployment manager is running, do not federate now. Federate the
node later.
If security is enabled on the deployment manager node, you must federate later using the addNode
command to enter a user ID and password on the command.
A possibility exists that the deployment manager is reconfigured to use the non-default remote
method invocation (RMI) as the preferred Java Management Extensions (JMX) connector. (Click
System Administration > Deployment manager > Administrative services in the administrative
console of the deployment manager to verify the preferred connector type.)
If RMI is the preferred JMX connector, you must use the addNode command to federate the custom
profile at a later time. Use the addNode command so that you can specify the JMX connector type
and the RMI port.
If the deployment manager uses the default SOAP JMX connector type, specify the host name and
SOAP port and federate the node now to create a functional node that you can customize.
Federating when the deployment manager is not available
If you 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. You 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.
Click Next to display the Profile name panel.
6. Specify a name for the profile, then click Next.
Profile naming guidelines: The profile name can be any unique name with the following restrictions.
Do not use any of the following characters when naming your profile:
v Spaces

72 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 v Illegal special characters that are not allowed within the name of a directory on your operating
system, such as *&?
v Slashes (/) or (\)
Double-byte characters are allowed.
The default profile
The first profile that you create on a machine is the default profile. The default profile is the default
target for commands issued from the bin directory in the product installation root. When only one
profile exists on a machine, every command works on the only server process in the configuration.
Addressing a profile in a multi-profile environment
When two or more profiles exist on a machine, certain commands require that you specify the profile
to which the command applies. These commands use the -profileName parameter to identify which
profile to address. You might find it easier to use the commands that in the bin directory of each
profile.
A command in the profiles/profile_name/bin directory has two lines. The first line sets the
WAS_USER_SCRIPT environment variable for the command window. The variable sets up the
command environment to address the profile. The second line calls the actual command in the
install_root/bin directory.
The actual command queries the command shell to determine the calling profile and to autonomically
address the command to the calling profile.
The wizard then displays the Profile directory panel.
7. Specify a location for the profile and click Next.
If you click Back and change the name of the profile, you must manually change the name on this
panel when it displays again.
The wizard displays the Node and host names panel.
8. Specify the node and host characteristics for the custom profile and click Next.
Migration considerations
If you plan to migrate an installation of V5.x Network Deployment to V6, use the same cell name for
the V6 deployment manager as you used for the V5.x cell.
After migrating the cell, the V5 managed nodes are now managed by the V6 deployment manager in
compatibility mode. You can migrate individual V5 managed nodes in the cell to V6. To do so, you
must create a V6 profile with the same node name as the V5 managed node.
Reserved names: Avoid using reserved folder names as field values. The use of reserved folder
names can cause unpredictable results. The following words are reserved:
v cells
v nodes
v servers
v clusters
v applications
v deployments

Chapter 3. Setting up the application serving environment 73

 The custom profile has the following characteristics:

Field Default value Constraints Description

name
Node The name of Avoid using the reserved The name is used for administration within the deployment
name your machine, words. manager cell to which the custom profile is added. Use a
or a unique unique name within the deployment manager cell.
derivation of the Use a unique name
machine name. within the deployment After migrating a V5 deployment manager cell to a V6
manager cell. deployment manager, you can migrate the V5 custom
profiles that are running in compatibility mode in the V6
If you plan to migrate a deployment manager.
V5 managed node, use
the same node name for
this V6 custom profile.
Host The DNS name The host name must be Use the actual DNS name or IP address of your machine to
name of your addressable through your enable communication with your machine. See additional
machine. network. information about the host name that follows this table.

Node name considerations

The profiles directory path must be no longer than 80 characters.

Host name considerations
The host name is the network name for the physical machine on which the node is installed. The host
name must resolve to a physical network node on the server. When multiple network cards exist in
the server, the host name or IP address must resolve to one of the network cards. Remote nodes use
the host name to connect to and to communicate with this node. Selecting a host name that other
machines can reach within your network is extremely important. Do not use the generic localhost
identifier for this value.
If you define coexisting nodes on the same computer with unique IP addresses, define each IP
address in a domain name server (DNS) look-up table. Configuration files for stand-alone Application
Servers do not provide domain name resolution for multiple IP addresses on a machine with a single
network address.
The value that you specify for the host name is used as the value of the hostName property in
configuration documents for the stand-alone Application Server. Specify the host name value in one of
the following formats:
v Fully qualified domain name servers (DNS) host name string, such as
xmachine.manhattan.ibm.com
v The default short DNS host name string, such as xmachine
v Numeric IP address, such as 127.1.255.3
The fully qualified DNS host name has the advantage of being totally unambiguous and also flexible.
You have the flexibility of changing the actual IP address for the host system without having to
change the Application Server configuration. This value for host name is particularly useful if you plan
to change the IP address frequently when using Dynamic Host Configuration Protocol (DHCP) to
assign IP addresses. A format disadvantage is being dependent on DNS. If DNS is not available, then
connectivity is compromised.
The short host name is also dynamically resolvable. A short name format has the added ability of
being redefined in the local hosts file so that the system can run the Application Server even when
disconnected from the network. Define the short name to 127.0.0.1 (local loopback) in the hosts file to
run disconnected. A format disadvantage is being dependent on DNS for remote access. If DNS is
not available, then connectivity is compromised.
A numeric IP address has the advantage of not requiring name resolution through DNS. A remote
node can connect to the node you name with a numeric IP address without DNS being available. A
format disadvantage is that the numeric IP address is fixed. You must change the setting of the
hostName property in Express configuration documents whenever you change the machine IP
74 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 address. Therefore, do not use a numeric IP address if you use DHCP, or if you change IP addresses
regularly. Another format disadvantage is that you cannot use the node if the host is disconnected
from the network.
After specifying custom profile characteristics, the wizard displays the Port value assignment panel.
9. Specify port assignments that do not conflict for the custom profile and click Next.
When federating a custom profile, the addNode command uses non-conflicting ports. This means
that you can take the default port assignments as you create the profile, and let the addNode
command specify non-conflicting ports as you federate the node. Port assignments must be unique
on a machine. application server processes on different machines can use the same port
assignments without conflict.
After specifying non-conflicting port assignments, the wizard displays the Profile summary panel.
10. Click Next to create the custom profile or click Back to change the characteristics of the custom
profile. The wizard displays a Status panel as the wizard creates the custom profile.
At the end of the installation, the wizard displays the Profile creation is complete panel.
11. Click Finish to exit the Profile creation wizard.

You can create a custom profile. The node within the profile is empty until you federate the node and use
the deployment manager to customize the node.

Refer to the description of the “wasprofile command” on page 96 to learn about creating this type of profile
using a command instead of a wizard.

Federate the node into the deployment manager cell if you have not already done so as you created the
node. Then use the deployment manager to create an application server on the node. Then you are ready
to deploy an application.

Deploy an application to get started!

See Fast paths for WebSphere Application Server to get started deploying applications.

responsefile.pct.NDmanagedProfile.txt:

This topic describes the response file for creating a custom profile. Federate the custom node into a
running deployment manager cell to make the node operational.

Create a custom node using the with an options response file after logging on as root on a Linux or UNIX
platform, or as a user that belongs to the administrator group on a Windows platform. Some steps of the
installation procedure on a Windows platform require the user to belong to the administrator group and to
have the advanced user rights Act as part of the operating system and Log on as a service.

The response file is shipped with default values.

A common use for an options file is to run the Installation wizard in silent mode, which is referred to as
installing silently. The wizard reads the options file to determine responses and does not display the
graphical user interface. Issue the following command to use a copy of the options file named
myresponsefile.txt for a silent installation:
pctWindows.exe -options "myresponsefile.txt" -silent

Federating the custom profile

Several directives in the file provide options for how the custom node is federated into the deployment
manager cell:
v -W pctfederationpanelInstallWizardBean.federateLater

Chapter 3. Setting up the application serving environment 75

 Set this value to true if the deployment manager is not running or is not accessible for any of the
reasons in the following description of federation.
v -W pctfederationpanelInstallWizardBean.hostname
Specify a value that resolves to the system where the deployment manager is running. See the
following description of host name considerations for more information.
v -W pctfederationpanelInstallWizardBean.port
Specify the value of the deployment manager SOAP port. You must specify the correct value. An
incorrect value prevents node federation and results in a total failure with an INSTCONFFAILED
indicator. The default SOAP port for the deployment manager is 8879.

Should you federate the node?

Federate the custom node if you can. However, if any of the parameters that you supply are faulty, you not
only do not federate the node, you create a faulty custom profile. Federate the node at the time that you
perform the silent creation of the node if, and only if, the deployment manager is running and is accessible
at the host name that you specify and over the SOAP port that you specify.

If you are unsure whether the deployment manager is running, do not federate now. Federate the node
later.

If security is enabled on the deployment manager node, you must federate later using the addNode
command to enter a user ID and password on the command.

A possibility exists that the deployment manager is reconfigured to use the non-default remote method
invocation (RMI) as the preferred Java Management Extensions (JMX) connector. (Click System
Administration > Deployment manager > Administrative services in the administrative console of the
deployment manager to verify the preferred connector type.)

If RMI is the preferred JMX connector, you must use the addNode command to federate the custom
profile at a later time. Use the addNode command so that you can specify the JMX connector type and
the RMI port.

If the deployment manager uses the default SOAP JMX connector type, specify the host name and SOAP
port and federate the node now to create a functional node that you can customize.

Federating when the deployment manager is not available

If you 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. You 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.

Avoiding the use of the -silent option within the options response file

A problem occurs when the -silent option exists in the file. The file works with the option during a direct
call to the profile creation wizard, but fails when called from a silent product installation. See ″Customizing
the options response file for Network Deployment″ in the information center for information about creating
a profile silently during a silent product installation.

The option is unnecessary. Avoid using the option to avoid problems.

76 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Response file locations

The example options response files are in two locations.

Example files:
v responsefile.pct.NDdmgrProfile.txt
v responsefile.pct.NDmanagedProfile.txt
v responsefile.pct.NDstandAloneProfile.txt

Location:
Table 6. Option response file locations
Product disc location Installed location
/WAS directory install_root/bin/ProfileCreator directory

Use the file on the product disc to install the Network Deployment product silently and create a profile.

After installing the Network Deployment product, you can use the installed response file with the -options
parameter on the Profile creation wizard command.

Required disk space

Profile Required disk space Required temp space

Deployment manager profile 30 MB 40 MB
Custom profile 10 MB 40 MB
Application server profile 200 MB 40 MB

Creating an operational environment during product installation

Version 6 installation of the Network Deployment product is a two-step process:

1. Installing the core product files and feature files.
2. Creating a deployment manager profile, a custom profile, or an application server profile.

The sample options response file, responsefile.nd.txt, controls the first part of the installation and can also
start the second part of the installation. To create a profile as part of installing the core product files, use
the option in the responsefile.nd.txt file that identifies the response file for creating a profile. The profile
response file lets you use the Profile creation wizard silently.

To edit and use the appropriate response file for creating a profile, perform the following procedure:
1. Copy the appropriate file from the WAS directory on the product disc to a place that you can easily
identify on your machine. The example files are:

To create a: Copy the following response file:

Deployment manager profile responsefile.pct.NDdmgrProfile.txt
Custom profile responsefile.pct.NDmanagedProfile.txt
Application server profile responsefile.pct.NDstandAloneProfile.txt

2. Edit the file to customize the values for your installation.

3. Verify that no -silent option exists in the response file for the Profile creation wizard. If the option
exists, the profile is not created.

Chapter 3. Setting up the application serving environment 77

4. Save the file.
5. Edit the responsefile.nd.txt file to identify the location and name of the profile response file. Change
the value of the -W pctresponsefilelocationqueryactionInstallWizardBean.fileLocation option to identify
the file. For example:
-W pctresponsefilelocationqueryactionInstallWizardBean.fileLocation=
"/opt/IBM/WebSphere/MyOptionFiles/customProfile.txt"
6. Start the installation. For example:
install -options "myresponsefile.txt" -silent
7. After the installation, examine the logs for success.

Creating a profile after installation

Version 6 installation of the Network Deployment product is a two-step process:

1. Installing the core product files and feature files
2. Creating a deployment manager profile, a custom profile, or an application server profile

When the core product files exist, create a profile at any time using the Profile creation wizard. Start the
wizard from the First steps console or directly using the Profile creation wizard command.

You can also use one of the following sample options response files for profiles to create a profile silently
using the Profile creation wizard in silent mode. To edit and use the appropriate response file for creating a
profile, perform the following procedure:
1. Copy the appropriate file from the install_root/bin/ProfileCreator directory to a place that you can
easily identify on your machine. The example files are:

To create a profile for a: Copy the following response file:

Deployment manager responsefile.pct.NDdmgrProfile.txt
Managed node responsefile.pct.NDmanagedProfile.txt
Stand-alone application server responsefile.pct.NDstandAloneProfile.txt

For example, copy the file as my_options_file.txt

2. Edit the file to customize the values for your installation.
3. Save the file.
4. Start the installation.
For example:

v ./pctAIX.bin -options my_options_file.txt -silent

v ./pctHPUX.bin -options my_options_file.txt -silent

v 64-bit platforms: ./pctHPUXIA64.bin -options my_options_file.txt -silent

v ./pctLinux.bin -options my_options_file.txt -silent

v 64-bit platforms: ./pct.bin -options my_options_file.txt -silent

v Power platforms: ./pctLinuxPPC.bin -options my_options_file.txt -silent

v S/390 platforms: ./pctLinux390.bin -options my_options_file.txt -silent

v ./pctSolaris.bin -options my_options_file.txt -silent

v pctWindows.exe -options my_options_file.txt -silent

v 64-bit platforms: pctWindowsIA64.exe -options my_options_file.txt -silent

78 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
5. After using the Profile creation wizard, examine the logs for success.

Logging

The following log files record information about profile creation:

v The install_root/logs/log.txt file records installation status.
v The install_rootprofiles/profile_name/logs/pctLog.txt file records installation events that occur when
creating profiles with the Profile creation wizard.
v The install_root/logs/wasprofile/wasprofile_create_profile_name.log file records installation events
that occur when creating profiles.
v The install_root/logs/wasprofile/wasprofile_delete_profile_name.log file records installation events
that occur when deleting profiles.

See ″Troubleshooting installation″ in the information center for more information.

Usage notes
v The file is not a read-only file.
v Edit this file directly with your flat file editor of choice, such as WordPad on a Windows platform.
v The file is updated when you specify the -options parameter when using the Profile creation wizard and
the file does not yet exist.
v The file must exist to perform a silent installation. The installation program reads this file to determine
installation option values when you install silently.
v Save the file in a location that you can identify when you specify the fully qualified path as part of the
profile creation command.

Naming considerations

Consider the following recommendations when supplying names for the profile and other objects.

Naming the profile

Use the following guidelines when supplying a value for the profile name directive:
-W profilenamepanelInstallWizardBean.profileName

Specify a name for the profile, then click Next.

Profile naming guidelines: The profile name can be any unique name with the following restrictions. Do
not use any of the following characters when naming your profile:
v Spaces
v Illegal special characters that are not allowed within the name of a directory on your operating system,
such as *&?
v Slashes (/) or (\)

Double-byte characters are allowed.

The default profile

The first profile that you create on a machine is the default profile. The default profile is the default target
for commands issued from the bin directory in the product installation root. When only one profile exists
on a machine, every command works on the only server process in the configuration.

Addressing a profile in a multi-profile environment

Chapter 3. Setting up the application serving environment 79

When two or more profiles exist on a machine, certain commands require that you specify the profile to
which the command applies. These commands use the -profileName parameter to identify which profile to
address. You might find it easier to use the commands that in the bin directory of each profile.

A command in the profiles/profile_name/bin directory has two lines. The first line sets the
WAS_USER_SCRIPT environment variable for the command window. The variable sets up the command
environment to address the profile. The second line calls the actual command in the install_root/bin
directory.

The actual command queries the command shell to determine the calling profile and to autonomically
address the command to the calling profile.

The wizard then displays the Profile directory panel.

Avoiding reserved names

Avoid the following reserved folder names as values for the directives in the
responsefile.pct.NDstandAloneProfile.txt file and in the responsefile.pct.NDmanagedProfile.txt file:
-W nodehostnamepanelInstallWizardBean.nodeName=""
-W nodehostnamepanelInstallWizardBean.hostName=""
-W setnondmgrcellnameinglobalconstantsInstallWizardBean.value=""

Avoid the following reserved folder names as values for the directives in the
responsefile.pct.NDdmgrProfile.txt file:
-W nodehostandcellnamepanelInstallWizardBean.nodeName=""
-W nodehostandcellnamepanelInstallWizardBean.hostName=""
-W nodehostandcellnamepanelInstallWizardBean.cellName=

Reserved names: Avoid using reserved folder names as field values. The use of reserved folder names
can cause unpredictable results. The following words are reserved:
v cells
v nodes
v servers
v clusters
v applications
v deployments

Node and cell name considerations

The profiles directory path must be no longer than 80 characters.

Host name considerations

The host name is the network name for the physical machine on which the node is installed. The host
name must resolve to a physical network node on the server. When multiple network cards exist in the
server, the host name or IP address must resolve to one of the network cards. Remote nodes use the host
name to connect to and to communicate with this node. Selecting a host name that other machines can
reach within your network is extremely important. Do not use the generic localhost identifier for this value.

If you define coexisting nodes on the same computer with unique IP addresses, define each IP address in
a domain name server (DNS) look-up table. Configuration files for stand-alone Application Servers do not
provide domain name resolution for multiple IP addresses on a machine with a single network address.

80 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
The value that you specify for the host name is used as the value of the hostName property in
configuration documents for the stand-alone Application Server. Specify the host name value in one of the
following formats:
v Fully qualified domain name servers (DNS) host name string, such as xmachine.manhattan.ibm.com
v The default short DNS host name string, such as xmachine
v Numeric IP address, such as 127.1.255.3

The fully qualified DNS host name has the advantage of being totally unambiguous and also flexible. You
have the flexibility of changing the actual IP address for the host system without having to change the
Application Server configuration. This value for host name is particularly useful if you plan to change the IP
address frequently when using Dynamic Host Configuration Protocol (DHCP) to assign IP addresses. A
format disadvantage is being dependent on DNS. If DNS is not available, then connectivity is
compromised.

The short host name is also dynamically resolvable. A short name format has the added ability of being
redefined in the local hosts file so that the system can run the Application Server even when disconnected
from the network. Define the short name to 127.0.0.1 (local loopback) in the hosts file to run disconnected.
A format disadvantage is being dependent on DNS for remote access. If DNS is not available, then
connectivity is compromised.

A numeric IP address has the advantage of not requiring name resolution through DNS. A remote node
can connect to the node you name with a numeric IP address without DNS being available. A format
disadvantage is that the numeric IP address is fixed. You must change the setting of the hostName
property in Express configuration documents whenever you change the machine IP address. Therefore, do
not use a numeric IP address if you use DHCP, or if you change IP addresses regularly. Another format
disadvantage is that you cannot use the node if the host is disconnected from the network.

Example responsefile.pct.NDmanagedProfile.txt file

Tip: A custom profile must be added into a deployment manager cell to become operational. Because of
this strong dependency on being a managed node, the profile is often referred to as a managed
profile or as a managed node.

Of course, until you federate the node into a cell, the node is not managed. Another thing to keep in
mind is that any federated node is a managed node, including federated nodes within Application
Server profiles.

The following response file refers to the term managed instead of the term custom in many directive
names. Even so, all of the directives in this response file help to define a custom profile.
################################################################################
#
# Response file for WebSphere Application Server v6.0 custom profile creation
#
# This options file is located in the CD_ROOT\WAS\ directory and in the
# install_root\bin\ProfileCreator directory.
#
# To use the options file under CD_ROOT\WAS\ directory, follow the instructions
# in CD_ROOT\WAS\responsefile.nd.txt. The WebSphere Application Server
# Network Deployment installer locates this file during silent installation
# and automatically runs the silent profile creation at the end of installation.
#
# To use the options file under install_root\bin\ProfileCreator for silent profile
# creation, you must change various values in the file and use the following command
# line arguments:
#
# -options "responsefile.pct.NDmanagedProfile.txt" -silent
#
################################################################################

Chapter 3. Setting up the application serving environment 81

################################################################################
#
# Profile name
#
# Set the name for this custom profile. The profile name must be unique for this
# WebSphere Application Server installation.
#
#
-W profilenamepanelInstallWizardBean.profileName="profileManaged"

################################################################################
# If you want to set this profile to be your default profile, set to "true".
# Otherwise set to "false". If this is the first profile being created, the profile
# automatically is the default.
#
-W profilenamepanelInstallWizardBean.isDefault="false"

################################################################################
#
# Profile location
#
# Specify a directory to contain the files that define the run-time environment,
# such as commands,configuration files, and log files. If the directory contains
# spaces, enclose it in double-quotes as shown in the Windows example below.
#
# Note that spaces in the install location is only supported on Windows
# operating systems.
#
# Default Install Location:
#
# -P installLocation="<WAS_HOME>\profiles\<PROFILE_NAME>"
#
-P installLocation="C:\Program Files\IBM\WebSphere\AppServer\profiles\profileManaged"

################################################################################
#
# Node name
#
# Please select the node name for the Application Server. Node name under one cell
# has to be unique.
#
# If you plan to migrate a V5 deployment manager cell, the V5 managed nodes are also
# migrated to the V6 cell. To incrementally migrate an individual V5 managed node
# to V6, you must use the same node name for the V6 Application Server profile.
#
# Replace YOUR_NODE_NAME with the actual node name.
#
-W nodehostnamepanelInstallWizardBean.nodeName="YOUR_NODE_NAME"

################################################################################
#
# Host name
#
# Specify the host name for the Application Server. The host name is the domain
# name system (DNS) name (short or long) or the IP address of this computer.
#
# Replace YOUR_HOST_NAME with the actual host name. Comment the line to use
# the default value.
#
-W nodehostnamepanelInstallWizardBean.hostName="YOUR_HOST_NAME"

82 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
################################################################################
#
# Cell name
#
# You should not Modify this, unless absolutely necessary
#
# The Wizard would set this to short local host name + "Node##Cell" by default.
#
# If you would like to override the resolved cell name value, uncomment the line and
# replace YOUR_CELL_NAME with <YOUR_OWN_VALUE>
#
# -W setnondmgrcellnameinglobalconstantsInstallWizardBean.value="YOUR_CELL_NAME"

################################################################################
#
# Ports value assignment
#
# The following entries are used to reset port numbers used in the configuration
#
# They are currently set to the defaults.
# Please check to make sure there are no port conflicts.
# Port nubmers for each profile can be find in:
# <profile>/config/cells/<cell name>/nodes/<node name>/serverindex.xml
#
# If you specify true for the value of
# the -W pctfederationpanelInstallWizardBean.federateLater
# directive, port numbers are assigned automatically when you federate the
# node with the addNode command. The following port numbers do not apply.
#
-W pctmanagedprofileportspanelInstallWizardBean.BOOTSTRAP_ADDRESS="2809"
-W pctmanagedprofileportspanelInstallWizardBean.SOAP_CONNECTOR_ADDRESS="8878"
-W pctmanagedprofileportspanelInstallWizardBean.SAS_SSL_SERVERAUTH_LISTENER_ADDRESS="9901"
-W pctmanagedprofileportspanelInstallWizardBean.CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS="9201"
-W pctmanagedprofileportspanelInstallWizardBean.CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS="9202"
-W pctmanagedprofileportspanelInstallWizardBean.ORB_LISTENER_ADDRESS="9100"
-W pctmanagedprofileportspanelInstallWizardBean.NODE_DISCOVERY_ADDRESS="7272"
-W pctmanagedprofileportspanelInstallWizardBean.NODE_MULTICAST_DISCOVERY_ADDRESS="5000"
-W pctmanagedprofileportspanelInstallWizardBean.NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS="5001"
-W pctmanagedprofileportspanelInstallWizardBean.DCS_UNICAST_ADDRESS="9353"

################################################################################
#
# Federation
#
# A custom profile contains an empty node that must be federated to a deployment
# manager to become a functional managed node. Identify a running deployment
# manager that will administer the node or choose to federate the node later
# using the addNode command.
#
# Set to "true" if you want to federate this custom node later using the addNode
# command. You must federate this node later if the deployment manager :
# - is not running.
# - has security enabled.
# - has the SOAP connector disabled
#
# If you want to federate it now, set to "" and fill in the entries for the host
# and port of the deployment manager.
#
-W pctfederationpanelInstallWizardBean.federateLater=""

################################################################################
# Specify the host name of the deployment manager for federation.
#
-W pctfederationpanelInstallWizardBean.hostname="YOUR_DEPLOYMENT_MANAGER_HOST_NAME"

Chapter 3. Setting up the application serving environment 83

################################################################################
# Specify the port number where the deployment manager (DMGR) is reachable on the
# above host. The default port value is "8879".
#
-W pctfederationpanelInstallWizardBean.port="YOUR_DEPLOYMENT_MANAGER_PORT_NUMBER"

################################################################################
#
# Profile type
#
# Must be set to "managed" for installing a custom profile. Do not change this!
#
-W profiletypepanelInstallWizardBean.selection="managed"

Using the Profile creation wizard to create an application server

The Profile creation wizard can create an application server profile on any machine where the core product
files exist.

Before using the Profile creation wizard, install the core product files.

The Profile creation wizard is the wizard interface to the profile creation tool, wasprofile. See the
description of the “wasprofile command” on page 96 for more information.

An error can occur when you have not provided enough system temporary space to create a profile. Verify
that you have a minimum of 40 MB of temp space available before creating a profile.

You must have 200 MB of available disk space in the directory where you create an Application Server
profile.

Important:

You must have 30 MB of available disk space in the directory where you create a deployment
manager profile.

You must have 10 MB of available disk space in the directory where you create a custom
profile.

Manually verify that the required space for creating a profile is available on AIX. A known
problem in the underlying InstallShield for Multiplatforms (ISMP) code prevents proper space checking on
AIX systems at the time that the product disc was created.

Important:

After installing the core product files, you must create one of the following profiles to have an
operational run-time environment:
v An application server that is described in this topic.
An application server profile has a default server (which is server1), the default application
that includes the snoop servlet and the hitcount servlet, and application Samples. You can
federate the application server or use it as a stand-alone application server.
v A deployment manager.
See “Using the Profile creation wizard to create a deployment manager” on page 58. The
deployment manager provides a single administrative interface to a logical group of
application servers on one or more machines.

84 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 v A custom profile that you must federate to make operational.
See “Using the Profile creation wizard to create a custom profile” on page 70. A custom
profile is an empty node that you can customize to include application servers, clusters, or
other Java processes, such as a messaging server.

This procedure describes creating an application server profile using the graphical user interface provided
by the Profile creation wizard.

You can use the Profile creation wizard in silent mode with a response file instead of a graphical user
interface. See “responsefile.pct.NDstandAloneProfile.txt” on page 88 for examples of using the Profile
creation wizard in silent mode.

You can also use the wasprofile command to create an application server profile. See the description of
the “wasprofile command” on page 96 for more information.
1. Start the Profile creation wizard to create a new run-time environment.
Several ways exist to start the wizard. The initial way to start the wizard is at the end of installation by
selecting the check box to launch the Profile creation wizard.
One way to start the wizard is to issue the command directly from a command line.
The command is in the install_root/bin/ProfileCreator directory. The name of the command varies
per platform:

v pctAIX.bin

v pctHPUX.bin

v 64-bit platforms: pctHPUXIA64.bin

v pctLinux.bin

v 64-bit platforms: pct.bin S/390 platforms: pctLinux390.bin

v Power platforms: pctLinuxPPC.bin

v pctSolaris.bin

v pctWindows.exe

v 64-bit platforms: pctWindowsIA64.exe

Another way to start the Profile creation wizard is to select the wizard from the First steps console.
a. Open a command window.
b. Change directories to the firststeps directory in the installation root directory:
The installation root varies by platform:

v /usr/IBM/WebSphere/AppServer/firststeps

v /opt/IBM/WebSphere/AppServer/firststeps

v C:\Program Files\IBM\WebSphere\AppServer\firststeps
c. Issue the firststeps command to start the console:

v ./firststeps.sh

v firststeps.bat
d. Select the Profile creation wizard option on the console.
The Profile creation wizard is an InstallShield for Multiplatforms application. The wizard loads the
Java 2 SDK and then displays its Welcome panel.

Chapter 3. Setting up the application serving environment 85

 See the description of the “firststeps command” on page 48 for more information.
2. Click Next on the Welcome panel.
The wizard displays the Profile type selection panel.
3. Select the application server profile, then click Next.
The wizard displays the Profile directory panel.
4. Specify a name for the profile, then click Next.
Profile naming guidelines: The profile name can be any unique name with the following restrictions.
Do not use any of the following characters when naming your profile:
v Spaces
v Illegal special characters that are not allowed within the name of a directory on your operating
system, such as *&?
v Slashes (/) or (\)
Double-byte characters are allowed.
The default profile
The first profile that you create on a machine is the default profile. The default profile is the default
target for commands issued from the bin directory in the product installation root. When only one
profile exists on a machine, every command works on the only server process in the configuration.
Addressing a profile in a multi-profile environment
When two or more profiles exist on a machine, certain commands require that you specify the profile
to which the command applies. These commands use the -profileName parameter to identify which
profile to address. You might find it easier to use the commands that in the bin directory of each
profile.
A command in the profiles/profile_name/bin directory has two lines. The first line sets the
WAS_USER_SCRIPT environment variable for the command window. The variable sets up the
command environment to address the profile. The second line calls the actual command in the
install_root/bin directory.
The actual command queries the command shell to determine the calling profile and to autonomically
address the command to the calling profile.
The wizard then displays the Profile directory panel.
5. Accept the default directory or specify a non-default location, then click Next. Or click Browse to
select a different location.
If you click Back and change the name of the profile, you must manually change the name on this
panel when it displays again.
The wizard displays the Node and host name panel.
6. Specify the characteristics for the application server, then click Next.
Use unique names for each application server that you create.
Reserved names: Avoid using reserved folder names as field values. The use of reserved folder
names can cause unpredictable results. The following words are reserved:
v cells
v nodes
v servers
v clusters
v applications
v deployments

86 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Field name Default value Constraints Description
Node name Name of your Avoid using the reserved Pick any name you want. To help organize
machine words. your installation, use a unique name if you
plan to create more than one application
server on the machine.
Host name DNS name of your Addressable through your Use the actual DNS name or IP address of
machine network. your machine to enable communication with
your machine. See additional information
about the host name following this table.

Node name considerations: If you plan to migrate an installation of V5.x Network Deployment to V6
and migrate one of the managed nodes in the cell, use the same node name for the V6 application
server as you used for the V5.x managed node.

The installation directory path must be no longer than 60 characters.

Host name considerations:
The host name is the network name for the physical machine on which the node is installed. The host
name must resolve to a physical network node on the server. When multiple network cards exist in
the server, the host name or IP address must resolve to one of the network cards. Remote nodes use
the host name to connect to and to communicate with this node. Selecting a host name that other
machines can reach within your network is extremely important. Do not use the generic localhost
identifier for this value.
If you define coexisting nodes on the same computer with unique IP addresses, define each IP
address in a domain name server (DNS) look-up table. Configuration files for stand-alone Application
Servers do not provide domain name resolution for multiple IP addresses on a machine with a single
network address.
The value that you specify for the host name is used as the value of the hostName property in
configuration documents for the stand-alone Application Server. Specify the host name value in one of
the following formats:
v Fully qualified domain name servers (DNS) host name string, such as
xmachine.manhattan.ibm.com
v The default short DNS host name string, such as xmachine
v Numeric IP address, such as 127.1.255.3
The fully qualified DNS host name has the advantage of being totally unambiguous and also flexible.
You have the flexibility of changing the actual IP address for the host system without having to
change the Application Server configuration. This value for host name is particularly useful if you plan
to change the IP address frequently when using Dynamic Host Configuration Protocol (DHCP) to
assign IP addresses. A format disadvantage is being dependent on DNS. If DNS is not available, then
connectivity is compromised.
The short host name is also dynamically resolvable. A short name format has the added ability of
being redefined in the local hosts file so that the system can run the Application Server even when
disconnected from the network. Define the short name to 127.0.0.1 (local loopback) in the hosts file to
run disconnected. A format disadvantage is being dependent on DNS for remote access. If DNS is
not available, then connectivity is compromised.
A numeric IP address has the advantage of not requiring name resolution through DNS. A remote
node can connect to the node you name with a numeric IP address without DNS being available. A
format disadvantage is that the numeric IP address is fixed. You must change the setting of the
hostName property in Express configuration documents whenever you change the machine IP
address. Therefore, do not use a numeric IP address if you use DHCP, or if you change IP addresses
regularly. Another format disadvantage is that you cannot use the node if the host is disconnected
from the network.
After specifying application server characteristics, the wizard displays the Port value assignment
panel.

Chapter 3. Setting up the application serving environment 87

 7. Verify that the ports specified for the stand-alone application server are unique, then click Next.

After specifying port assignments, the wizard displays the Windows service definition
panel, if you are installing on a Windows platform.

8. Choose whether to run the application server as a Windows service on a Windows

platform and click Next.
Version 6 attempts to start Windows services for application server processes started by a
startServer command. For example, if you configure an application server as a Windows service and
issue the startServer command, the wasservice command attempts to start the defined service.
If you chose to install a local system service, you do not have to specify your user ID or password. If
you create a specified user type of service, you must specify the user ID and the password for the
user who is to run the service. The user must have Log on as a service authority for the service to
run properly.
To perform this installation task, the user ID must not have spaces in its name. The ID must also
belong to the administrator group and must have the advanced user rights Act as part of the
operating system and Log on as a service. The Installation wizard grants the user ID the advanced
user rights if it does not already have them, if the user ID belongs to the administrator group.
You can also create other Windows services after the installation is complete, to start other server
processes. See “Automatically restarting server processes” on page 244 for more information.
The installation wizard shows which components are selected for installation in a pre-installation
summary panel.
9. Click Next to create the application server or click Back to change the characteristics of the
application server.
The wizard displays the Installation status panel that shows which components are installing.
When the installation is complete, the wizard displays the Profile creation is complete panel.
10. Click Finish to exit, then click Profile creation wizard on the First steps console to start the wizard
again to create other application servers.

You can create an application server profile. The node within the profile has an application server named
server1.

Refer to the description of the “wasprofile command” on page 96 to learn about creating this type of profile
using a command instead of a wizard.

Deploy an application to get started!

See Fast paths for WebSphere Application Server to get started deploying applications.

responsefile.pct.NDstandAloneProfile.txt:

This topic describes the response file for creating a stand-alone application server profile.

Create a stand-alone application server profile with an options response file after logging on as root on a
Linux or UNIX platform, or a user that belongs to the administrator group on a Windows platform. Some
steps of the installation procedure on a Windows platform require the user to belong to the administrator
group and to have the advanced user rights Act as part of the operating system and Log on as a service.

The response file is shipped with default values.

A common use for an options file is to run the Installation wizard in silent mode, which is referred to as
installing silently. The wizard reads the options file to determine responses and does not display the
graphical user interface. Issue the following command to use a copy of the options file named
myresponsefile.txt for a silent installation:

88 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
pctWindows.exe -options "myresponsefile.txt" -silent

Avoiding the use of the -silent option within the options response file

A problem occurs when the -silent option exists in the file. The file works with the option during a direct
call to the profile creation wizard, but fails when called from a silent product installation. See ″Customizing
the options response file for Network Deployment″ in the information center for information about creating
a profile silently during a silent product installation.

The option is unnecessary. Avoid using the option to avoid problems.

Response file locations

The example options response files are in two locations.

Example files:
v responsefile.pct.NDdmgrProfile.txt
v responsefile.pct.NDmanagedProfile.txt
v responsefile.pct.NDstandAloneProfile.txt

Location:
Table 7. Option response file locations
Product disc location Installed location
/WAS directory install_root/bin/ProfileCreator directory

Use the file on the product disc to install the Network Deployment product silently and create a profile.

After installing the Network Deployment product, you can use the installed response file with the -options
parameter on the Profile creation wizard command.

Required disk space

Profile Required disk space Required temp space

Deployment manager profile 30 MB 40 MB
Custom profile 10 MB 40 MB
Application server profile 200 MB 40 MB

Creating an operational environment during product installation

Version 6 installation of the Network Deployment product is a two-step process:

1. Installing the core product files and feature files.
2. Creating a deployment manager profile, a custom profile, or an application server profile.

The sample options response file, responsefile.nd.txt, controls the first part of the installation and can also
start the second part of the installation. To create a profile as part of installing the core product files, use
the option in the responsefile.nd.txt file that identifies the response file for creating a profile. The profile
response file lets you use the Profile creation wizard silently.

To edit and use the appropriate response file for creating a profile, perform the following procedure:
1. Copy the appropriate file from the WAS directory on the product disc to a place that you can easily
identify on your machine. The example files are:

Chapter 3. Setting up the application serving environment 89

To create a: Copy the following response file:
Deployment manager profile responsefile.pct.NDdmgrProfile.txt
Custom profile responsefile.pct.NDmanagedProfile.txt
Application server profile responsefile.pct.NDstandAloneProfile.txt

2. Edit the file to customize the values for your installation.

3. Verify that no -silent option exists in the response file for the Profile creation wizard. If the option
exists, the profile is not created.
4. Save the file.
5. Edit the responsefile.nd.txt file to identify the location and name of the profile response file. Change
the value of the -W pctresponsefilelocationqueryactionInstallWizardBean.fileLocation option to identify
the file. For example:
-W pctresponsefilelocationqueryactionInstallWizardBean.fileLocation=
"/opt/IBM/WebSphere/MyOptionFiles/customProfile.txt"
6. Start the installation. For example:
install -options "myresponsefile.txt" -silent
7. After the installation, examine the logs for success.

Creating a profile after installation

Version 6 installation of the Network Deployment product is a two-step process:

1. Installing the core product files and feature files
2. Creating a deployment manager profile, a custom profile, or an application server profile

When the core product files exist, create a profile at any time using the Profile creation wizard. Start the
wizard from the First steps console or directly using the Profile creation wizard command.

You can also use one of the following sample options response files for profiles to create a profile silently
using the Profile creation wizard in silent mode. To edit and use the appropriate response file for creating a
profile, perform the following procedure:
1. Copy the appropriate file from the install_root/bin/ProfileCreator directory to a place that you can
easily identify on your machine. The example files are:

To create a profile for a: Copy the following response file:

Deployment manager responsefile.pct.NDdmgrProfile.txt
Managed node responsefile.pct.NDmanagedProfile.txt
Stand-alone application server responsefile.pct.NDstandAloneProfile.txt

For example, copy the file as my_options_file.txt

2. Edit the file to customize the values for your installation.
3. Save the file.
4. Start the installation.
For example:

v ./pctAIX.bin -options my_options_file.txt -silent

v ./pctHPUX.bin -options my_options_file.txt -silent

v 64-bit platforms: ./pctHPUXIA64.bin -options my_options_file.txt -silent

v ./pctLinux.bin -options my_options_file.txt -silent

90 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 v 64-bit platforms: ./pct.bin -options my_options_file.txt -silent

v Power platforms: ./pctLinuxPPC.bin -options my_options_file.txt -silent

v S/390 platforms: ./pctLinux390.bin -options my_options_file.txt -silent

v ./pctSolaris.bin -options my_options_file.txt -silent

v pctWindows.exe -options my_options_file.txt -silent

v 64-bit platforms: pctWindowsIA64.exe -options my_options_file.txt -silent

5. After using the Profile creation wizard, examine the logs for success.

Logging

The following log files record information about profile creation:

v The install_root/logs/log.txt file records installation status.
v The install_rootprofiles/profile_name/logs/pctLog.txt file records installation events that occur when
creating profiles with the Profile creation wizard.
v The install_root/logs/wasprofile/wasprofile_create_profile_name.log file records installation events
that occur when creating profiles.
v The install_root/logs/wasprofile/wasprofile_delete_profile_name.log file records installation events
that occur when deleting profiles.

See ″Troubleshooting installation″ in the information center for more information.

Usage notes
v The file is not a read-only file.
v Edit this file directly with your flat file editor of choice, such as WordPad on a Windows platform.
v The file is updated when you specify the -options parameter when using the Profile creation wizard and
the file does not yet exist.
v The file must exist to perform a silent installation. The installation program reads this file to determine
installation option values when you install silently.
v Save the file in a location that you can identify when you specify the fully qualified path as part of the
profile creation command.

Naming considerations

Consider the following recommendations when supplying names for the profile and other objects.

Naming the profile

Use the following guidelines when supplying a value for the profile name directive:
-W profilenamepanelInstallWizardBean.profileName

Profile naming guidelines: The profile name can be any unique name with the following restrictions. Do
not use any of the following characters when naming your profile:
v Spaces
v Illegal special characters that are not allowed within the name of a directory on your operating system,
such as *&?
v Slashes (/) or (\)

Double-byte characters are allowed.

Avoiding reserved names

Chapter 3. Setting up the application serving environment 91
Avoid the following reserved folder names as values for the directives in the
responsefile.pct.NDstandAloneProfile.txt file and in the responsefile.pct.NDmanagedProfile.txt file:
-W nodehostnamepanelInstallWizardBean.nodeName=""
-W nodehostnamepanelInstallWizardBean.hostName=""
-W setnondmgrcellnameinglobalconstantsInstallWizardBean.value=""

Avoid the following reserved folder names as values for the directives in the
responsefile.pct.NDdmgrProfile.txt file:
-W nodehostandcellnamepanelInstallWizardBean.nodeName=""
-W nodehostandcellnamepanelInstallWizardBean.hostName=""
-W nodehostandcellnamepanelInstallWizardBean.cellName=

Reserved names: Avoid using reserved folder names as field values. The use of reserved folder names
can cause unpredictable results. The following words are reserved:
v cells
v nodes
v servers
v clusters
v applications
v deployments

Node and cell name considerations

The profiles directory path must be no longer than 80 characters.

Host name considerations

The host name is the network name for the physical machine on which the node is installed. The host
name must resolve to a physical network node on the server. When multiple network cards exist in the
server, the host name or IP address must resolve to one of the network cards. Remote nodes use the host
name to connect to and to communicate with this node. Selecting a host name that other machines can
reach within your network is extremely important. Do not use the generic localhost identifier for this value.

If you define coexisting nodes on the same computer with unique IP addresses, define each IP address in
a domain name server (DNS) look-up table. Configuration files for stand-alone Application Servers do not
provide domain name resolution for multiple IP addresses on a machine with a single network address.

The value that you specify for the host name is used as the value of the hostName property in
configuration documents for the stand-alone Application Server. Specify the host name value in one of the
following formats:
v Fully qualified domain name servers (DNS) host name string, such as xmachine.manhattan.ibm.com
v The default short DNS host name string, such as xmachine
v Numeric IP address, such as 127.1.255.3

The fully qualified DNS host name has the advantage of being totally unambiguous and also flexible. You
have the flexibility of changing the actual IP address for the host system without having to change the
Application Server configuration. This value for host name is particularly useful if you plan to change the IP
address frequently when using Dynamic Host Configuration Protocol (DHCP) to assign IP addresses. A
format disadvantage is being dependent on DNS. If DNS is not available, then connectivity is
compromised.

The short host name is also dynamically resolvable. A short name format has the added ability of being
redefined in the local hosts file so that the system can run the Application Server even when disconnected

92 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
from the network. Define the short name to 127.0.0.1 (local loopback) in the hosts file to run disconnected.
A format disadvantage is being dependent on DNS for remote access. If DNS is not available, then
connectivity is compromised.

A numeric IP address has the advantage of not requiring name resolution through DNS. A remote node
can connect to the node you name with a numeric IP address without DNS being available. A format
disadvantage is that the numeric IP address is fixed. You must change the setting of the hostName
property in Express configuration documents whenever you change the machine IP address. Therefore, do
not use a numeric IP address if you use DHCP, or if you change IP addresses regularly. Another format
disadvantage is that you cannot use the node if the host is disconnected from the network.

Example responsefile.pct.NDstandAloneProfile.txt file

################################################################################
#
# Response file for WebSphere Application Server v6.0 stand alone profile
# creation
#
# This options file is located in the CD_ROOT\WAS\ directory and in the
# install_root\bin\ProfileCreator directory.
#
# To use the options file under CD_ROOT\WAS\ directory, follow the instructions
# in CD_ROOT\WAS\responsefile.nd.txt. The WebSphere Application Server
# Network Deployment installer locates this file during silent installation
# and automatically runs the silent profile creation at the end of installation.
#
# To use the options file under install_root\bin\ProfileCreator for silent profile
# creation, you must change various values in the file and use the following
# command line arguments:
#
# -options "responsefile.pct.NDstandAloneProfile.txt" -silent
#
################################################################################

################################################################################
#
# Profile name
#
# Set the profile name for installing a stand alone profile. The profile
# name must be unique for this WebSphere Application Server installation.
#
-W profilenamepanelInstallWizardBean.profileName="profileStandAlone"

################################################################################
# If you want to set this profile to be your default profile, set to "true".
# Otherwise set to "false". If this is the first profile being created, the profile
# automatically is the default.
#
-W profilenamepanelInstallWizardBean.isDefault="false"

################################################################################
#
# Profile location
#
# Specify a directory to contain the files that define the run-time environment,
# such as commands,configuration files, and log files. If the directory contains
# spaces, enclose it in double-quotes as shown in the Windows example below.
#
# Note that spaces in the install location is only supported on Windows
# operating systems.
#
# Default Install Location:
#

Chapter 3. Setting up the application serving environment 93

# -P installLocation="<WAS_HOME>\profiles\<PROFILE_NAME>"
#
-P installLocation="C:\Program Files\IBM\WebSphere\AppServer\profiles\profileStandAlone"

################################################################################
#
# Node name
#
# Please select the node name for the Application Server. Node name under one cell
# has to be unique.
#
# If you plan to migrate a V5 deployment manager cell, the V5 managed nodes are also
# migrated to the V6 cell. To incrementally migrate an individual V5 managed node
# to V6, you must use the same node name for the V6 Application Server profile.
#
# Replace YOUR_NODE_NAME with the actual node name.
#
-W nodehostnamepanelInstallWizardBean.nodeName="YOUR_NODE_NAME"

################################################################################
#
# Host name
#
# Specify the host name for the Application Server. The host name is the domain
# name system (DNS) name (short or long) or the IP address of this computer.
#
# Replace YOUR_HOST_NAME with the actual host name. Comment the line to use
# the default value.
#
-W nodehostnamepanelInstallWizardBean.hostName="YOUR_HOST_NAME"

################################################################################
#
# Cell name
#
# You should not Modify this, unless absolutely necessary.
#
# The Wizard would set this to short local host name + "Node##Cell" by default.
#
# If you would like to override the resolved cell name value, uncomment the line and
# replace YOUR_CELL_NAME with <YOUR_OWN_VALUE>.
#
# -W setnondmgrcellnameinglobalconstantsInstallWizardBean.value="YOUR_CELL_NAME"

################################################################################
#
# Port value assignment
#
# The following entries are used to reset port numbers used in the configuration
#
# They are currently set to the defaults.
# Please check to make sure there are no Port Conflicts.
# Port numbers for each profile can be find in:
# <profile>/config/cells/<cell name>/nodes/<node name>/serverindex.xml
#
-W pctdefaultprofileportspanelInstallWizardBean.WC_defaulthost="9080"
-W pctdefaultprofileportspanelInstallWizardBean.WC_adminhost="9060"
-W pctdefaultprofileportspanelInstallWizardBean.WC_defaulthost_secure="9443"
-W pctdefaultprofileportspanelInstallWizardBean.WC_adminhost_secure="9043"
-W pctdefaultprofileportspanelInstallWizardBean.BOOTSTRAP_ADDRESS="2809"
-W pctdefaultprofileportspanelInstallWizardBean.SOAP_CONNECTOR_ADDRESS="8880"
-W pctdefaultprofileportspanelInstallWizardBean.SAS_SSL_SERVERAUTH_LISTENER_ADDRESS="9401"
-W pctdefaultprofileportspanelInstallWizardBean.CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS="9403"
-W pctdefaultprofileportspanelInstallWizardBean.CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS="9402"

94 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
-W pctdefaultprofileportspanelInstallWizardBean.ORB_LISTENER_ADDRESS="9100"
-W pctdefaultprofileportspanelInstallWizardBean.DCS_UNICAST_ADDRESS="9353"
-W pctdefaultprofileportspanelInstallWizardBean.SIB_ENDPOINT_ADDRESS="7276"
-W pctdefaultprofileportspanelInstallWizardBean.SIB_ENDPOINT_SECURE_ADDRESS="7286"
-W pctdefaultprofileportspanelInstallWizardBean.SIB_MQ_ENDPOINT_ADDRESS="5558"
-W pctdefaultprofileportspanelInstallWizardBean.SIB_MQ_ENDPOINT_SECURE_ADDRESS="5578"

################################################################################
#
# Windows service
#
# The following directives are to install services for
# WebSphere Application Server on Windows.
# Using Services, you can start and stop services,
# and configure startup and recovery actions.
# Set winServiceQuery="false" will turn off the function on windows system.
# You can ignore these or comment them out for other Operating Systems.
#
-W winservicepanelInstallWizardBean.winServiceQuery="true"

################################################################################
# Specify account type of the service. Legal values are:
#
# localsystem - Indicates that you choose to use Local System account.
# specifieduser - Indicates that you choose to use specified user account.
#
-W winservicepanelInstallWizardBean.accountType="localsystem"

################################################################################
# If you chose to install a service above with the accountType="localsystem",
# the userName and password below can be ignored. If the accountType was set to:
# accountType="specifieduser", then you must specify the User Name and Password
# which are required to install the Services. The current user must be admin or must
# have admin authority to install a Service. Also the username
# which is given here must have "Log On as a Service " authority
# for the service to run properly.
#
# Replace YOUR_USER_NAME with your username.
#
-W winservicepanelInstallWizardBean.userName="YOUR_USER_NAME"

################################################################################
# Replace YOUR_PASSWORD with your valid password.
#
-W winservicepanelInstallWizardBean.password="YOUR_PASSWORD"

################################################################################
# Set the startup type of the WebSphere Application Server on Windows.
# Valid values are "automatic", "manual", and "disabled".
#
-W winservicepanelInstallWizardBean.startupType="manual"

################################################################################
# Profile type
#
# This must be set to "default" for installing a stand alone profile
# Do not change this!
#
-W profiletypepanelInstallWizardBean.selection="default"

Deleting a profile
This topic describes how to manually delete a profile.

Chapter 3. Setting up the application serving environment 95

Before using the manual procedure to remove a profile, try the wasprofile command with the -delete
option. For example, issue one of the following commands:

./wasprofile.sh -delete
-profileName profile_name | -profilePath profile_path

wasprofile.bat -delete
-profileName profile_name | -profilePath profile_path

See “wasprofile command.”

If the command does not work, use this procedure to delete the profile.

This procedure describes how to manually delete a profile when the wasprofile -delete command results
in the following message:
INSTCONFFAILED: Cannot delete profile
1. Delete the profiles_install_root/profile_name directory.
2. If the install_root/properties/profileRegistry.xml file exists, edit the file in a flat-file editor to delete
the entry for the profile, if the entry is present.
The entry resembles the following example:
<profile isDefault="true"
name="BadProfile"
path="E:\IBM\WebSphere\AppServer\profiles\BadProfile"
template="E:\IBM\WebSphere\AppServer\profileTemplates\default"/>

3. Compare the two batch files, install_root/ properties/ fsdb/

_was_profile_default/ default.sh and install_root/ properties/ fsdb/ bad_profile_name.sh.
If the files are identical, delete the install_root/ properties/ fsdb/ _was_profile_default directory
and the install_root/ properties/ fsdb/ bad_profile_name.sh file.
If the files are not identical, delete only the install_root/ properties/ fsdb/ bad_profile_name.sh file.

4. Compare the two batch files, install_root\ properties\ fsdb\ _was_profile_default\

default.bat and install_root\ properties\ fsdb\ bad_profile_name.bat.
If the files are identical, delete the install_root\ properties\ fsdb\ _was_profile_default directory
and the install_root\ properties\ fsdb\ bad_profile_name.bat file.
If the files are not identical, delete only the install_root\ properties\ fsdb\ bad_profile_name.bat file.

See the description of the “wasprofile command” to learn more about the command-line method of working
with profiles.

See “Using the Profile creation wizard” on page 54 for more information about creating profiles with the
Profile creation wizard.

wasprofile command
The wasprofile command line tool creates all Application Server run-time environments in Version 6. The
command creates a profile, which is the set of files that define the run-time environment for a deployment
manager, a custom profile, or a stand-alone Application Server.

The wasprofile command is also referred to as the profile creation tool.

96 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Introduction to terms that describe Version 6 profiles
The wasprofile command creates the run-time environment for a WebSphere Application Server process
in a set of files called a profile. The profile defines the run-time environment and includes all of the files
that the server processes in the run-time environment can change. The profile creation tool and its
graphical user interface, the Profile creation wizard, are the only ways to create run-time environments in
V6.

The Profile creation wizard is an InstallShield for Multiplatforms (ISMP) application. You can use the wizard
to enter most of the parameters that are described in this topic. Some parameters, however, require you to
use the wasprofile command. You must use the wasprofile command to delete a profile, for instance,
because the Profile creation wizard does not provide a deletion function.

However, the Profile creation wizard also performs tasks that the wasprofile command does not. For
instance, the wizard can create a Windows service for each profile that it creates. It can also assign
non-conflicting ports based on previous Version 6 port assignments.

Core product files: The core product files are the shared product binaries. The binary files are shared
by all profiles.

The directory structure for V6 has two major divisions of files in the installation root directory for the
product:
v The core product files are shared product binary files that do not change unless you install a refresh
pack, a fix pack, or an interim fix. Some log information is also updated.
v The profiles directory is the default directory for creating profiles. The configuration for every defined
Application Server process is within the profiles directory unless you specify a new directory when you
create a profile. These files change as often as you create a new profile, reconfigure an existing profile,
or delete a profile.

All of the folders except for the profiles directory and a few others such as the logs directory and the
properties directory do not change unless you install service fixes. The profiles directory, however,
changes each time you add, change, or delete a profile. The profiles directory is the default repository for
profiles. However, you can put a profile anywhere on the machine provided there is enough available disk
space.

If you put a profile in another existing folder in the installation root directory, a risk exists that the profile
might be affected by the installation of a service fix that applies maintenance to the folder. Use a directory
outside of the installation root directory when using a directory other than the profiles directory for
creating profiles.

WebSphere Application Server profile: The wasprofile command line tool defines each Application
Server instance of a Version 6 product.

You must run the wizard or the command line tool each time that you want to create a stand-alone
Application Server. A need for more than one stand-alone Application Server on a machine is common.

Administration is greatly enhanced when using V6 profiles instead of multiple product installs. Not only is
disk space saved, but updating the product is simplified when you only maintain a single set of product
core files. Also, creating new profiles is faster and less prone to error than full product installs, allowing a
developer to create new disposable profiles of the product for development and testing.

You can run the Profile creation wizard or the profile creation tool to create a new Application Server
environment on the same machine as an existing one. Simply define unique characteristics (such as
profile name and node name) for the new profile. Each profile has its own administrative console and
administrative scripting interface. Each Application Server process shares all run-time scripts, libraries, the
Software Development Kit, and other core product files.

Chapter 3. Setting up the application serving environment 97

Profile types: Templates for each profile are located in the was_home/profileTemplates directory.

Within this directory are the default folder, the dmgr folder, and the managed folder. These are the paths
that you indicate while using the wasprofile command with the -templatePath option.

For example: -templatePath /usr/WebSphere/AppServer/profileTemplates/default

The wasprofile command in the Network Deployment product can create the following types of profiles:
Deployment manager profile
The basic function of the deployment manager is to deploy applications to a cell of Application
Servers, which it manages. Each Application Server that belongs to the cell is referred to as a
managed node.
Application Server profile
The basic function of the Application Server is to serve applications to the Internet or to an
intranet.
An important product feature for the Network Deployment product is the ability to scale up a
stand-alone Application Server profile by adding the Application Server node into a deployment
manager cell. Multiple Application Server processes in a cell can deploy an application that is in
demand. You can also remove an Application Server node from a cell to return the node to the
status of a stand-alone Application Server.
Each stand-alone Application Server has its own administrative console application, which you use
to manage the Application Server. You can also use the wsadmin scripting facility to perform every
function that is available in the administrative console application.
There is no node agent process for a stand-alone Application Server unless you decide to add the
Application Server node to a deployment manager cell. Adding the Application Server to a cell is
known as federation. Federation changes the stand-alone Application Server into a managed
node. At that point, you use the administrative console of the deployment manager to manage the
node. If you remove the node from the deployment manager cell, use the administrative console
and the scripting interface of the stand-alone Application Server to manage the process.
Custom profile
The basic function of this profile that belongs to a deployment manager cell is to serve
applications to the Internet or to an intranet under the management of the deployment manager.
The deployment manager changes a custom profile to a managed node by adding the node into
the cell. This is also true when you add an Application Server into a cell. When either node is
added to a cell, the node becomes a managed node. The nodeagent process is then instantiated
on the managed node. The node agent acts on behalf of the deployment manager to control
Application Server processes on the managed node. The node agent can start or stop Application
Servers, for example.
A deployment manager can create multiple Application Servers on a managed node so long as the
node agent process is running. Processes on the managed node can include cluster members that
the deployment manager uses to balance the work load for heavily used applications.
Use the administrative console of the deployment manger to control all of the nodes that the
deployment manager manages. You can also use the wsadmin scripting facility of the deployment
manager to control any of the managed nodes. A custom profile does not have its own
administrative console or scripting interface. You cannot manage the node directly with the
wsadmin scripting facility. You must use the administrative interface of the deployment manager to
manage a managed node.
A custom profile does not include default applications or a default server as the Application Server
profile does. A custom profile is an empty node. Add the node to the deployment manager cell.
Then you can use the administrative interface of the deployment manager to customize the
managed node by creating clusters and Application Servers.

98 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Installed file set: You decide where to install the files that define a profile. The default location is in the
profiles directory in the installation root directory. But you can change the location on the Profile creation
wizard or in a parameter when using the command line tool. For example, assume that you create two
profiles on a Linux platform with host name devhost1. The profile directories resemble the following
example if you do not relocate them:
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile02

Suppose that you specify a different directory, such as /opt/profiles, for the profile directory field in the
wizard. The profile directories resemble the following example:
/opt/profiles/devhost1Profile01
/opt/profiles/devhost1Profile02

The following directories exist within a profile. This example assumes that a profile named
devhost1Profile01 exists:
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/bin
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/config
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/etc
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/firststeps
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/installableApps
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/installedApps
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/installedConnectors
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/installedFilters
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/logs
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/properties
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/samples
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/temp
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/tranlog
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01/wstemp

The profile repository: The profile repository is the default location of profile-related metadata. The
repository is the default location for new profiles, which is often referred to as the profiles installation root
directory.

However, you can decide where to install a profile. The default location of the profile repository is the
install_root/profiles directory. In the earlier example, creating two profiles on a Linux platform with host
name devhost1 results in the following example directories in the profile repository:
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile01
/opt/IBM/WebSphere/AppServer/profiles/devhost1Profile02

When you specify a directory, such as /opt/profiles, the profiles are no longer in the default repository,
which is not a problem. For example, the following locations are valid:
/opt/profiles/devhost1Profile01
/opt/profiles/devhost1Profile02

Location of the command file

The command file is located in the install_root/bin directory. The command file is a script named
wasprofile.sh for Linux and UNIX platforms or wasprofile.bat for Windows platforms.

The Profile creation wizard is the graphical user interface to the command line tool. The file name of the
command that calls the Profile creation wizard varies per operating system platform. See “Using the Profile
creation wizard” on page 54 for more information.

Chapter 3. Setting up the application serving environment 99

Logging
The wasprofile command creates a log for every profile that it creates. The logs are in the
install_root/logs/wasprofile directory. The files are named in this pattern:
wasprofile_create_profile_name.log.

The command also creates a log for every profile that it deletes. The logs are in the
install_root/logs/wasprofile directory. The files are named in this pattern:
wasprofile_delete_profile_name.log.

Required disk space

Manually verify that the required space for creating a profile is available on AIX. A known
problem in the underlying InstallShield for Multiplatforms (ISMP) code prevents proper space checking on
AIX systems at the time that the product disc was created.

An error can occur when you have not provided enough system temporary space to create a profile. Verify
that you have a minimum of 40 MB of temp space available before creating a profile.

You must have 200 MB of available disk space in the directory where you create an Application Server
profile.

Network Deployment

Tip:

You must have 30 MB of available disk space in the directory where you create a deployment
manager profile.

You must have 10 MB of available disk space in the directory where you create a custom profile.

After installing the core product files, you must create one of the following profiles to have an
operational run-time environment:
v An application server that is described in this topic.
An application server profile has a default server (which is server1), the default application that
includes the snoop servlet and the hitcount servlet, and application Samples. You can federate the
application server or use it as a stand-alone application server.
v A deployment manager.
See ″Using the Profile creation wizard to create a deployment manager″ in the Installation PDF.
The deployment manager provides a single administrative interface to a logical group of
application servers on one or more machines.
v A custom profile that you must federate to make operational.
See ″Using the Profile creation wizard to create a custom profile″ in the Installation PDF. A custom
profile is an empty node that you can customize to include application servers, clusters, or other
Java processes, such as a messaging server.

Concurrent profile creation

Important: Concurrent profile creation is not supported at this time for one set of core product files.
Concurrent attempts to create profiles result in a warning about a profile creation already in
progress.

Entering lengthy commands on more than one line

The length of the wasprofile command can exceed the normal shell window limit for one line of 256
characters. If your command is longer than the limit, issue the command on multiple lines by ending a line
with a backward slash, pressing Enter, and continuing the command on the next line.

100 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
For example, on a Solaris system, the following command requires input on multiple lines:
./wasprofile.sh \
-create -profileName bladetcb6profile \
-profilePath /usr/IBM/WebSphere/AppServer/profiles/bladetcb6profile \
-templatePath /usr/WebSphere/AppServer/profileTemplates/default \
-nodeName bladetcb6node \
-cellName bladetcb6Cell \
-hostName bladetcb6.rtp.raleigh.ibm.com

Omit the line continuation character from the last line to signal the end of the command to the operating
system.

wasprofile.sh command syntax

List existing profiles:
# ./wasprofile.sh -listProfiles
[-debug]

Delete profiles:
# ./wasprofile.sh -delete
-profileName profile_name | -profilePath profile_path
[-debug]

Create new profiles:

wasprofile.sh -create
-profileName profile_name
-profilePath fully_qualified_profile_path
-templatePath template_path
-nodeName node_name
-cellName cell_name
-hostName host_name
-server iSeries_server_name
[-dmgrHost host_name]
[-dmgrPort SOAP port]
[-startingPort starting_port | -portsFile filepath]
-winserviceCheck true | false
-winserviceAccountType specifieduser | localsystem
-winserviceUserName yourusername
-winservicePassword yourpassword
-winserviceStartupType manual | automatic | disabled
[-debug]

Get name of existing profile from path:

# ./wasprofile.sh -getName
-profilePath profile_path
[-debug]

Get path of existing profile from name:

# ./wasprofile.sh -getPath
-profileName profile_name
[-debug]

Check the integrity of the profile registry:

# ./wasprofile.sh -validateRegistry
[-debug]

Check the integrity of the profile registry, removing profiles that are not found:
# ./wasprofile.sh -validateAndUpdateRegistry
[-backup file_name]
[-debug]

Chapter 3. Setting up the application serving environment 101

wasprofile.bat command syntax
List existing profiles:
wasprofile.bat -listProfiles
[-debug]

Delete profiles:
wasprofile.bat -delete
-profileName profile_name | -profilePath profile_path
[-debug]

Create new profiles:

wasprofile.bat -create
-profileName profile_name
-profilePath fully_qualified_profile_path
-templatePath template_path
-nodeName node_name
-cellName cell_name
-hostName host_name
-server iSeries_server_name
[-dmgrHost host_name]
[-dmgrPort SOAP port]
[-startingPort starting_port | -portsFile filepath]
-winserviceCheck true | false
-winserviceAccountType specifieduser | localsystem
-winserviceUserName yourusername
-winservicePassword yourpassword
-winserviceStartupType manual | automatic | disabled
[-debug]

When the -startingPort parameter is not used, the profile creation tool uses the default port settings
specified in the serverindex.xml file.

Get name of existing profile from path:

wasprofile.bat -getName
-profilePath fully_qualified_profile_path
[-debug]

Get path of existing profile from name:

wasprofile.bat -getPath
-profileName profile_name
[-debug]

Check integrity of profile registry:

wasprofile.bat -validateRegistry
[-debug]

Check integrity of profile registry, removing unfound profiles:

wasprofile.bat -validateAndUpdateRegistry
[-backup file_name]
[-debug]

Parameters
Supported arguments include:
-augment
Refreshes or augments the given profile using the template in the templatePath parameter.
-backup file_name
Backs up the profile registry file to a file with the file name specified.

102 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
-cellname file_name
Specifies the cell name of the profile.
-create
Creates the profile.
-debug
Turns on the debug function of the Ant utility, which the wasprofile command uses.
-delete
Deletes the profile.
-dmgrHost host_name
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.
Specifying this optional parameter directs the wasprofile command to attempt to federate the custom
node into the deployment manager cell as it creates the custom profile. This parameter is ignored
when creating a deployment manager profile or an Application Server profile.
Federating when the deployment manager is not available
If you 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. You 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.
-dmgrPort 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 you have enabled security or changed the default JMX connector type, you cannot federate with the
wasprofile command. Use the addNode command instead.
-getName
Gets the name for a profile registered at a given file system path. Requires the –profilePath parameter.
-getPath
Gets the file system location for a profile of a given name. Requires the –profileName parameter.
-hostName host_name
Specifies the host name where you are creating the profile. This should match the host name that you
specified during installation of the initial product.
-listProfiles
Llists all defined profiles.
-nodeName node_name
Specifies the node name for the node that is created with the new profile. Use a unique value within
the cellor on the machine. Each profile that shares the same set of product binaries must have a
unique node name.
-portsFile file_path
An optional parameter that specifies the path to a file that defines port settings for the new profile.
When omitted, the wasprofile tool looks for the install_root /profileTemplates/profile_type
/actions/portsUpdate/bin/portdef.props file.
Do not use this parameter when using the startingPort parameter.

Chapter 3. Setting up the application serving environment 103

-profileName profile_name
Specifies the 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.
-profilePath profile_path
Specifies the fully qualified path to the profile.

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 C:\IBM\WebSphere\AppServer\profiles\profile01

If the fully qualified path contains spaces, enclose the value in quotation marks.

Specifies the name of the server on an iSeries platform.

-startingPort startingPort
Specifies the starting port number for generating all ports for the profile. If not specified, the
wasprofile command uses default ports specified in the serverindex.xml file.
-templatePath template_path
Specifies the path to the templates in the shared binaries.
-validateAndUpdateRegistry registry_file backup_file
Checks all of the profiles that are 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 profile.
-validateRegistry registry_file
Checks all of the profiles that are listed in the profile registry to see if the profiles are present on the
file system. Returns a list of missing profiles.

-winserviceAccountType type_of_owner_account
The type of the owner account of the Windows service created for the profile can be either
specifieduser or localsystem. The Windows service can run under the local account of the user who is
creating the profile.

winserviceCheck value
The value can be either true or false. Specify true to create a Windows service for the server process
that is created within the profile. Specify false to not create the Windows service.

-winservicePassword yourpassword
Specify the password for the specified user or the local account that is to own the Windows service.

-winserviceStartupType startup_type
Possible startup_type values are:
v manual
v automatic
v disabled
See ″WASService command″ in the Installation PDF for more information about Windows services.

-winserviceUserName user_ID
Specify your user ID so that Windows can verify you as an ID that is capable of creating a Windows
service. Your user ID must belong to the administrator group and have the following advanced user
rights, Act as part of the operating system and Log on as a service

104 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Use case scenarios
Use cases are a description of common tasks for which the tool is used.

Scenario: Creating a deployment manager profile on a Linux or UNIX platform: To create a

deployment manager profile for user shasti:
wasprofile.sh -create
-profileName shasti
-profilePath ~/shasti/WebSphere
-templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/dmgr
-cellName shaix1
-hostName planetaix
-nodeName dmgr1

On an Express product or a base product installation, the command does not create anything because the
deployment manager template is not present.

On a Network Deployment product installation, the command creates a deployment manager profile
named shasti in a cell named shaix1 in location ~/shasti/WebSphere with a node name of dmgr1.

Scenario: Creating a deployment manager profile on a Windows platform: To create a server

process for user shasti:
wasprofile.sh -create
-profileName shasti
-profilePath G:\shasti\WebSphere
-templatePath C:\IBM\WebSphere\AppServer\profileTemplates\dmgr
-cellName shwindows1
-hostName planetnt
-nodeName dmgr1

On an Express installation or on a base WebSphere Application Server product installation, the command
does not create a deployment manager profile because the dmgr template does not exist in either product.

On a Network Deployment product installation, the command creates a deployment manager profile
named shasti in a cell named shwindows1 in location G:\shasti\WebSphere with a node name of dmgr1.

Scenario: Creating a deployment manager profile in a multiuser environment on a Linux or UNIX

platform: Follow these steps to create a server process for user shasti in a multiuser environment:
1. Create the server process:
wasprofile.sh -create
-profileName shasti
-profilePath ~/shasti/WebSphere
-templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/dmgr
-cellName shaix1
-hostName myhost
-nodeName dmgr1
-startingPort 12000
2. Change the owner of the folder:
chown -R shasti ~shasti2/WebSphere
3. As a convenience, add a call to script ~shasti/WebSphere/bin/setupCmdLine.sh in the profile of user
shasti to set the environment when user shasti logs in.
4. Give these folder permissions to user shasti:
install_root/bin --- rx (read and execute)
install_root/java --- rx
install_root/properties ----r (read)
install_root/deploytool ----r
install_root/config ----r
install_root/lib ----r

Chapter 3. Setting up the application serving environment 105

 install_root/classes ----r
install_root/null ----r
install_root/samples ----r
install_root/Web ----r

Scenario: Deleting a profile: The following command is on more than one line for clarity. Enter the
command on one line to delete the profile named shasti:
wasprofile.sh -delete
-profileName shasti

Scenario: Using predefined port numbers: When you use the wasprofile tool without the -startingPort
parameter, the tool uses the /profileTemplates/profile_type /actions/portsUpdate/bin/portdef.props
file to set the initial ports.

Example of using the -portsFile parameter

Copy the file, edit the port settings, and use your copy by using the -portsFile parameter as shown in the
following example:
wasprofile.bat
-create
-profileName Wow_Profile
-profilePath
C:\ExpressV6\IBM\WebSphere\AppServer\profiles\Wow_Profile
-templatePath
C:\ExpressV6\IBM\WebSphere\AppServer\profileTemplates\default
-nodeName Wow_node
-cellName Wow_cell
-hostName loyAllen
-portsFile C:\temp\ports\portdef.props

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

As you run the command, messages similar to the following appear in the output stream:
replaceRegExpAllInstancesOfGivenTokenWithGivenValueForTheGivenFile:
[echo] File C:\ExpressV6\IBM\WebSphere\AppServer\profiles\
Wow_Profile/config/templates/default/serverentry-template.xml:
setting CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS to 39403

...
replaceRegExpAllInstancesOfGivenTokenWithGivenValueForTheGivenFile:
[echo] File C:\ExpressV6\IBM\WebSphere\AppServer\profiles\
Wow_Profile/config/templates/default/serverentry-template.xml:
setting CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS to 39402
...

The resulting serverindex.xml file looks similar to the following example:

106 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
<?xml version="1.0" encoding="UTF-8"?>
<serverindex:ServerIndex xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
...
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="BOOTSTRAP_ADDRESS">
<endPoint xmi:id="EndPoint_..." host="IBMmachine" port="32809"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="SOAP_CONNECTOR_ADDRESS">
<endPoint xmi:id="EndPoint_..." host="IBMmachine" port="38880"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="SAS_SSL_SERVERAUTH_LISTENER_ADDRESS">
<endPoint xmi:id="EndPoint_..." host="IBMmachine" port="39401"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS">
<endPoint xmi:id="EndPoint_..." host="IBMmachine" port="39403"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS">
<endPoint xmi:id="EndPoint_..." host="IBMmachine" port="39402"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="WC_adminhost">
<endPoint xmi:id="EndPoint_..." host="*" port="39060"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="WC_defaulthost">
<endPoint xmi:id="EndPoint_..." host="*" port="39080"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="DCS_UNICAST_ADDRESS">
<endPoint xmi:id="EndPoint_..." host="IBMmachine" port="39353"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="WC_adminhost_secure">
<endPoint xmi:id="EndPoint_..." host="*" port="39043"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="WC_defaulthost_secure">
<endPoint xmi:id="EndPoint_..." host="*" port="39443"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="SIB_ENDPOINT_ADDRESS">
<endPoint xmi:id="EndPoint_..." host="*" port="37276"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="SIB_ENDPOINT_SECURE_ADDRESS">
<endPoint xmi:id="EndPoint_..." host="*" port="37286"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="SIB_MQ_ENDPOINT_ADDRESS">
<endPoint xmi:id="EndPoint_..." host="*" port="35558"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="SIB_MQ_ENDPOINT_SECURE_ADDRESS">
<endPoint xmi:id="EndPoint_..." host="*" port="35578"/>
</specialEndpoints>
<specialEndpoints xmi:id="NamedEndPoint_..."
endPointName="ORB_LISTENER_ADDRESS">
<endPoint xmi:id="EndPoint_..." host="IBMmachine" port="39100"/>
</specialEndpoints>
</serverEntries>
</serverindex:ServerIndex>

Chapter 3. Setting up the application serving environment 107

The wasprofile command creates a copy of the current portdefs.props file in the
install_root\profiles\profile_name\logs directory.

Do not use the portsFile parameter when using the startingPort parameter. The two parameters are
mutually exclusive.

Scenario: Incrementing default port numbers from a starting point: The wasprofile command can
assign port numbers based on a starting port value that you give on the command line, using the
-startingPort parameter. The tool assigns port numbers sequentially from the starting port number value.

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
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20008
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20009
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20010
ORB_LISTENER_ADDRESS=20011
DCS_UNICAST_ADDRESS=20012
SIB_ENDPOINT_ADDRESS=20013
SIB_ENDPOINT_SECURE_ADDRESS=20014
SIB_MQ_ENDPOINT_ADDRESS=20015
SIB_MQ_ENDPOINT_SECURE_ADDRESS=20016

Assigned ports for a custom profile

WC_defaulthost=20002
WC_adminhost=20003
WC_defaulthost_secure=20004
WC_adminhost_secure=20005
BOOTSTRAP_ADDRESS=20006
SOAP_CONNECTOR_ADDRESS=20007
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20008
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20009
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20010
ORB_LISTENER_ADDRESS=20011
CELL_DISCOVERY_ADDRESS=20012
DCS_UNICAST_ADDRESS=20013

Assigned ports for a deployment manager profile

CELL_DISCOVERY_ADDRESS=20010
BOOTSTRAP_ADDRESS=20004
DRS_CLIENT_ADDRESS=7989
SOAP_CONNECTOR_ADDRESS=20005
ORB_LISTENER_ADDRESS=20009
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=20006
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=20008
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=20007
WC_adminhost=20002
DCS_UNICAST_ADDRESS=20011
WC_adminhost_secure=20003

Example of startingPort parameter use

108 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
The following example of using the wasprofile command creates ports from an initial value of 20002, with
the content shown in the previous example:
wasprofile.bat -create
-profileName shasti
-profilePath G:\shasti\WebSphere
-templatePath template_path
-nodeName W2K03
-cellName W2K03_Cell01
-hostName planetnt
-startingPort 20002

Scenario: Setting up and using the profile environment: Most tasks that you perform in a profile are
done using the -profileName attribute on the command line tools that you use. Such a scenario might be:
1. Create the server process using the install_root/bin/wasprofile.sh (or wasprofile.bat) script from the
original installation. Assume that you create the Profile02 profile.
2. In that command window or in another, change directories to the /bin directory of the new server
process.
3. Establish a temporary override for the normal WebSphere Application Server environment by using the
-profileName attribute on a command you issue. In the same window, start server1 by changing
directories to the install_root/bin directory of the original installation and issuing the command.
There is no such command in the /bin directory of the server process:
startServer.sh server1 -profileName Profile02
4. Notice the changes in the environment. Display all of the ports for the machine to see the ports that
you set for the server process. For example, in a Linux bash shell or in the command window on a
Windows platform, type:
netstat -a
5. Open a browser window and point it at the port defined for the HTTP_TRANSPORT_ADMIN port of
the new process. For example, suppose the setting is HTTP_TRANSPORT_ADMIN=20003. Open the
administrative console for server1 by pointing your browser at:
http://hostname_orIP_address:20003/ibm/console/

Scenario: Profile creation for a non-root user: Two methods exist for a non-root user to create a
profile:
v The root user creates the profile and assigns ownership to the non-root user.
v A non-root user creates a profile after getting write permission to the appropriate directories.

Remember: An ease-of-use limitation exists for non-root users who create profiles. Mechanisms within
the Profile creation wizard that suggest unique names and port values are disabled for
non-root users. The non-root user must change the default field values in the Profile creation
wizard for the profile name, node name, cell name, and port assignments. Consider
assigning non-root users a range of values for each of the fields. You can assign
responsibility to the non-root profilers for adhering to their proper value ranges and for
maintaining the integrity of their own definitions.

Root creates the profile and assigns ownership to a non-root user: The root user can create a profile and
assigns ownership of the profile directory to a non-root user.
1. The root user creates the profile with the following command:
./wasprofile.sh -create -profileName profile01 -profilePath install_root/profiles/profile01
2. The root user changes ownership of the directory for the profile to the non-root user with the following
command:
chown -R user1 install_root/profiles/profile01

A non-root user creates the profile (advanced option): The root user can grant write permission to the
appropriate files and directories to a non-root user. The non-root user can then create the profile. You can

Chapter 3. Setting up the application serving environment 109

create a group for users who are authorized to create profiles. Or you can give everyone the ability to
create profiles. The following example shows how to create a group that is authorized to create profiles.
1. Log on to the Application Server system as root.
2. Create the profilers group that you can use to create profiles.
3. Create a user named user1 to create profiles.
4. Add users root and user1 to the profilers group.
5. Log off and back on as root to pick up the new group.
6. As root, use operating system tools to change file permissions.
The following example assumes that the installation root directory is /opt/IBM/WebSphere/AppServer:
mkdir /opt/IBM/WebSphere/AppServer/logs/wasprofile
chgrp profilers /opt/IBM/WebSphere/AppServer/logs/wasprofile
chmod g+wr /opt/IBM/WebSphere/AppServer/logs/wasprofile
chgrp profilers /opt/IBM/WebSphere/AppServer/properties
chmod g+wr /opt/IBM/WebSphere/AppServer/properties
chmod g+wr /opt/IBM/WebSphere/AppServer/properties/profileRegistry.xml
You might have to change the permissions on additional /opt/IBM/WebSphere/AppServer directories if
you encounter permission problems.
7. The non-root user who belongs to the profilers group can then create a profile in any directory to which
the non-root user has write permission.
If the non-root user does not have write access to any directories, it is up to the root user to change
that situation. If the non-root user does not have write access to the /tmp directory, it is up to the root
user to change that as well.
The commands listed in step 6 give users assigned to the profilers group the ability to write to the
/opt/IBM/WebSphere/AppServer/logs/wasprofile directory and to the
/opt/IBM/WebSphere/AppServer/properties directory. It is not necessary to write to any other
directories in the installation root of your WebSphere Application Server product.
Have non-root users create a profiles directory in their own area, not in the installation root directory
of the product.

Using the installation verification test

This topic describes how to use the installation verification test (IVT). The IVT verifies that the installation
of the application server or deployment manager profile was successful. A profile consists of files that
define the run-time environment for a deployment manager or an application server. Each profile has its
own IVT command.

After installing the Network Deployment product and creating a deployment manager or application server
profile, you are ready to use the installation verification test (IVT).

The IVT program scans product log files for errors and verifies core functionality of the product installation.

The Profile creation wizard creates profiles. After creating a profile, the Profile creation wizard displays a
prompt for starting the First steps console. The First steps console is unique for each profile. See
“firststeps command” on page 48 for more information.

Installation verification is the first option on the First steps console.

The IVT program for an application server profile starts and monitors the application server process, which
is the server1 process. The installation verification for a deployment manager profile starts and monitors
the deployment manager process, which is the dmgr process. The IVT works differently for the deployment
manager profile than for a stand-alone application server. On a stand-alone application server, the IVT
queries servlets from the ivtApp application. However, the deployment manager does not have the ivtApp
application, so the IVT looks at log files only.

110 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
1. Start the First steps console and select Installation verification after creating a deployment manager
profile or an application server profile.
No installation verification is possible for a custom profile. After federating the node and using the
deployment manager to create a server, you can start the server process to verify its functionality.
Select the check box to launch the First steps console at the end of profile creation. You can also start
the First steps console from the command line, as described in “firststeps command” on page 48.
You can also start the “ivt command” on page 112 directly from the bin directory of the profile:
v install_root/profiles/profile_name/bin/ivt.sh
v install_root\profiles\profile_name\bin\ivt.bat
If you create profiles in another location, the ivt script location is within the profile_home/bin directory.
2. Observe the results in the First steps status window.
The default log file for installation verification is the install_root/profiles/profile
name/logs/ivtClient.log. If you create profiles in another location, the file path is
profile_home/logs/ivtClient.log.
The IVT provides the following useful information about the application server:
v The application server name
v The name of the profile
v The profile file path
v The type of profile
v The node name
v The current encoding
v The port number for the administrative console
v Various informational messages that include the location of the SystemOut.log file and how many
errors are listed within the file
v A completion message
As the IVT starts the application server on a Windows platform, the IVT attempts to start the Windows
service for the application server, if a Windows service exists. This is true even though the Windows
service might have a manual startup type.
If you federate a stand-alone application server, you can still run the IVT on the server.
The IVT provides the following useful information about the deployment manager:
v The deployment manager server name: dmgr
v The name of the profile
v The profile file path
v The type of profile: dmgr
v The cell name
v The node name
v The current encoding
v The port number for the administrative console
v Various informational messages that include the location of the SystemOut.log file and how many
errors are listed within the file
v A completion message
As the IVT starts the deployment manager on a Windows platform, the IVT attempts to start the
Windows service for the deployment manager if a Windows service exists. This is true even though the
Windows service might have a manual startup type.
See “Automatically restarting server processes” on page 244 for more information.

Chapter 3. Setting up the application serving environment 111

3. If the log shows that errors occurred during the installation verification, correct the errors and run the
IVT again. If necessary, create a new profile after correcting the error, and run the IVT on the new
profile.

The IVT program starts the server process automatically if the server is not running. Once the server
initializes, the IVT runs a series of verification tests. The tool displays pass or fail status in a console
window. The tool also logs results to the profile_home/logs/ivtClient.log file. As the IVT verifies your
system, the tool reports any detectable errors in the SystemOut.log file.

Return to the ″Task overview: Installing″ topic in the information center to continue.

ivt command
The ivt command starts the installation verification test (IVT) program. The IVT verifies that the installation
of the application server or deployment manager profile was successful. A profile consists of files that
define the run-time environment for a deployment manager or an application server. Each profile has its
own IVT command.

The IVT program starts the application server or deployment manager automatically if the server process
is not already running. After the server process initializes, the IVT runs a series of verification tests and
displays pass or fail status in a console window.

The IVT program scans the SystemOut.log file for errors and verifies core functionality of the profile.

You can start the IVT program from the command line or from the First steps console.

Location of the command file

The location of the ivt.sh or ivt.bat script for any profile is:
v install_root/profiles/profile_name/bin/ivt.sh
v install_root\profiles\profile_name\bin\ivt.bat

Parameters

The following parameters are associated with this command.

server_name
Required parameter that identifies the name of the server process, such as server1 or dmgr.
profile_name
Required parameter that identifies the name of the profile that contains the server definition.
-p server_port_number
Optional parameter that identifies the default_host port when the port is not 9080, which is the default.
-host machine_host_name
Optional parameter that identifies the host machine of the profile to test. The default is localhost.

Syntax for the ivt command

Use the following syntax for the command:

v install_root/profiles/profile_name/bin/ivt.sh

v install_root\profiles\profile_name\bin\ivt.bat

Logging

The ivt command logs results to the install_root/profiles/profile name/logs/ivtClient.log file.

112 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Example

The following examples test the server1 process in the profile01 profile on the myhost machine using the
default_host on port 9081.

ivt.bat server1 profile01 -p 9081 -host myhost

ivt.sh server1 profile01 -p 9081 -host myhost

Configuring ports
This topic discusses configuring ports, particularly in coexistence scenarios.
1. Review “Port number settings in WebSphere Application Server versions.”
This topic provides reference information about identifying port numbers in versions of WebSphere
Application Server, as a means of determining port conflicts that might occur when you intend for an
earlier version to coexist with Version 6.
2. You can change port settings on the port assignment panel while using the Profile creation wizard.
See “Using the Profile creation wizard” on page 54 for more information.
3. After installation, edit the
profiles_install_root/profile_name/config/cells/cell_name/nodes/node_name/serverindex.xml file to
change the port settings, or use scripting to change the values.
See the Administering applications and their environment PDF for more information.

Port number settings in WebSphere Application Server versions

This topic provides reference information about identifying port numbers in versions of WebSphere
Application Server, as a means of determining port conflicts that might occur when you intend for an
earlier version to coexist or interoperate with Version 6.

Version 6 port numbers

Table 8. Port definitions for WebSphere Application Server Version 6
WebSphere
Network Deployment
Port name Application Server File
Value
HTTP_TRANSPORT 9080 9080
HTTP Admin Console Port
9060 9060
(HTTP_TRANSPORT_ADMIN)
serverindex.xml and
HTTPS Transport Port virtualhosts.xml
9443 9443
(HTTPS_TRANSPORT)
HTTPS Admin Console Secure Port
9043 9043
(HTTPS_TRANSPORT_ADMIN)

Chapter 3. Setting up the application serving environment 113

Table 8. Port definitions for WebSphere Application Server Version 6 (continued)
WebSphere
Network Deployment
Port name Application Server File
Value
BOOTSTRAP_ADDRESS 2809 9809
SOAP_CONNECTOR-ADDRESS 8880 8879
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS 9401 9401
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS9403 9403
CSIV2_SSL_MULTIAUTH_LISTENER_ADDRESS 9402 9402
ORB_LISTENER_ADDRESS 9100 9100
DCS_UNICAST_ADDRESS 9353 9352
SIB_ENDPOINT_ADDRESS 7276 7276
serverindex.xml
SIB_ENDPOINT_SECURE_ADDRESS 7286 7286
SIB_MQ_ENDPOINT_ADDRESS 5558 5558
SIB_MQ_ENDPOINT_SECURE_ADDRESS 5578 5578
Internal JMS Server
5557 Not applicable
(JMSSERVER_SECURITY_PORT)
IBM HTTP Server Port virtualhosts.xml,

80 Not applicable plugin-cfg.xml,

and IHSinstall_ro
IBM HTTPS Server Admin Port IHSinstall_root/conf/
8008 Not applicable
admin.conf
CELL_DISCOVERY_ADDRESS Not applicable 7277
CELL_MULTICAST_DISCOVERY_ADDRESS Not applicable 7272 serverindex.xml
NODE_MULTICAST_IPV6_DISCOVERY_ADDRESS
5001 5001

When you federate an Application Server node into a deployment manager cell, the deployment manager
instantiates the nodeagent server process on the Application Server node. The nodeagent server uses
these port assignments by default:
Table 9. Port definitions for the V6 nodeagent server process
Port name Value File
BOOTSTRAP_ADDRESS 2809
ORB_LISTENER_ADDRESS 9100
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS 9901
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS 9202
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS 9201
NODE_DISCOVERY_ADDRESS 7272 serverindex.xml
NODE_MULTICAST_DISCOVERY_ADDRESS 5000
NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS 5001
DCS_UNICAST_ADDRESS 9353
DRS_CLIENT_ADDRESS 7888
SOAP_CONNECTOR_ADDRESS 8878

114 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Version 5.x port numbers
Table 10. Port definitions for WebSphere Application Server Version 5.x
WebSphere
Network Deployment
Port name Application Server File
Value
HTTP_TRANSPORT 9080 Not applicable
HTTPS Transport Port
9443 Not applicable
(HTTPS_TRANSPORT)
server.xml and
HTTP Admin Console Port virtualhosts.xml
9090 9090
(HTTP_TRANSPORT_ADMIN)
HTTPS Admin Console Secure Port
9043 9043
(HTTPS_TRANSPORT_ADMIN)
Internal JMS Server
5557 Not applicable server.xml
(JMSSERVER_SECURITY_PORT)
JMSSERVER_QUEUED_ADDRESS 5558 Not applicable
serverindex.xml
JMSSERVER_DIRECT_ADDRESS 5559 Not applicable
BOOTSTRAP_ADDRESS 2809 9809 serverindex.xml
SOAP_CONNECTOR-ADDRESS 8880 8879 serverindex.xml
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS 0 9401 serverindex.xml
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS 0 9403
serverindex.xml
CSIV2_SSL_MULTIAUTH_LISTENER_ADDRESS 0 9402
IBM HTTP Server Port virtualhosts.xml,
plugin-cfg.xml, and
80 Not applicable
IHSinstall_root/conf/
httpd.conf
IBM HTTPS Server Admin Port IHSinstall_root/conf/
8008 Not applicable
admin.conf
CELL_DISCOVERY_ADDRESS Not applicable 7277
ORB_LISTENER_ADDRESS 9100 9100 serverindex.xml
CELL_MULTICAST_DISCOVERY_ADDRESS Not applicable 7272

When you federate an Application Server node into a deployment manager cell, the deployment manager
instantiates the nodeagent server process on the Application Server node. The nodeagent server uses
these port assignments by default:
Table 11. Port definitions for the V5.x nodeagent server process
Port name Value File
BOOTSTRAP_ADDRESS 2809
ORB_LISTENER_ADDRESS 9900
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS 9901
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS 9101
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS 9201 serverindex.xml
NODE_DISCOVERY_ADDRESS 7272
NODE_MULTICAST_DISCOVERY_ADDRESS 5000
DRS_CLIENT_ADDRESS 7888
SOAP_CONNECTOR_ADDRESS 8878

Chapter 3. Setting up the application serving environment 115

Version 4.0.x port numbers

For WebSphere Application Server Advanced Single Server Edition, Version 4.0.x: Inspect the
server-cfg.xml file to find the Web container HTTP transports port values for the configuration.

For WebSphere Application Server Advanced Edition, Version 4.0.x: When the administrative server is
running, use this command to extract the configuration from the database:
xmlConfig -export config.xml -nodeName theNodeName

Look for the Web container HTTP transports port assignments.

Table 12. Port definitions for WebSphere Application Server V4.0.x
IBM WebSphere Advanced Single
Business Integration Server Edition
Advanced Edition
Port name Value Server Foundation
Edition
File
bootstrapPort 900
lsdPort 9000 admin.config admin.config
LSDSSLPort 9001
HTTP transport port 9080
HTTPS transport port 9443 server-cfg.xml

Admin Console HTTP 9090

database database
transport port
ObjectLevelTrace 2102
diagThreadPort 7000

Communicating with Web servers

The WebSphere Application Server works with a Web server to route requests for dynamic content, such
as servlets, from Web applications. The Web servers are necessary for directing traffic from browsers to
the applications that run in WebSphere Application Server. The Web server plug-in uses the XML
configuration file to determine whether a request is from the Web server or the Application Server.

The Web server plug-ins for distributed platform Web servers are provided on a separate CD from the
WebSphere Application Server products. A Web Server Plug-in Installation Wizard is also provided on that
CD. Installing Web server plug-ins describes how to install a Web server plug-in and create a Web server
definition.
1. Install your Web server if it is not already installed. If you want to use an IBM HTTP Server, see
Installing IBM HTTP Server. Otherwise, see the installation information provided with your Web server.
2. Ensure that your Web server is configured to perform operations required by Web applications, such
as GET and POST. Typically, this involves setting a directive in the Web server configuration file (such
as the httpd.conf file for an IBM HTTP Server). Refer to the Web server documentation for instructions.
If an operation is not enabled when a servlet or JSP file requiring the operation is accessed, an error
message displays, such as this one from the IBM HTTP Server:
HTTP method POST is not supported by this URL.
3. Use the Plug-in Installation wizard to install the appropriate plug-in file to your Web server and run the
script configureWeb_server_name created by the wizard to create and configure the Web server

116 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 definition in the WebSphere configuration repository. The following substeps are performed during the
plug-in installation process. See the Plug-in Installation Roadmap for additional information.
a. A node is created. An unmanaged node is created when the Web server is on a different computer
from the Application Server. An unmanaged node is a node that does not have a WebSphere node
agent running on it. Using unmanaged nodes, WebSphere Application Server can represent
servers that are not application servers within its configuration topology. This representation
enables connection information between those servers and application servers to be maintained.
“Managing nodes” on page 149 describes how to create a node.
b. A Web server definitions is created. You can also use either use the administrative console or use
the ConfigureWebServerDefintion.jacl script to create a Web server definition.
If you use the administrative console:
1) Select the node that was created in the preceding step, and in the Server name field, enter the
local name of the Web server for which you are creating a Web server definition.
2) Use the wizard to complete the Web server definition.
c. An application or modules are mapped to a Web server. If an application that you want to use with
this Web server is already installed, the application is automatically mapped to the Web server. If
the application is not installed, select this Web server during the Map modules to servers step of
the application installation process.
d. Master repository is updated and saved.
4. Optional: Configure the plug-in. Use either the administrative console, or issue the “GenPluginCfg
command” on page 872 to create your plugin-cfg.xml file.
When setting up your Web server plug-in, you must decide whether or not to have the configuration
automatically generated in response to a configuration change. When the Web server plug-in
configuration service is enabled and any of the following conditions occur, the plug-in configuration file
is automatically generated:
v When the Web server is created or saved.
v When an application is installed.
v When an application is uninstalled.
v When the virtual host definition is updated
Generating or regenerating the configuration file might take a while to complete. After it finishes, all
objects in the administrative cell use their newest settings, which the Web server can access. If the
Application Server is on the same physical machine as the Web server, the regeneration usually takes
about 30 to 60 seconds to complete. The regeneration takes longer if they are not both on the same
machine.

Important: When the plug-in configuration file is first generated, it does not include admin_host on the
list of virtual hosts. ″Allowing Web servers to access the administrative console″ in the
information center describes how to add it to the list.
To use the administrative console:
a. Select Servers > Web Servers > webserver > plug-in properties.
b. Select Automatically generate plug-in configuration file or click on one or more of the following
topics to manually configure the plugin-cfg.xml file:
v Caching
v Request and response
v Request routing
v Service
Web server plug-in configuration properties maps each property to one of these topics.
c. Click OK.
d. You might need to stop the application server and then start the application server again to enable
the Web server to locate the plugin-cfg.xml file.

Chapter 3. Setting up the application serving environment 117

5. If you want to use Secure-socket layer (SSL) with this configuration, use the plug-in’s installation
wizard to install the appropriate GSKIT installation image file on your workstation. See “Configuring the
Web server plug-in for Secure Sockets Layer” on page 1908 for information on how to configure
GSKIT.
6. If you want to enable the Web server plug-in to use private headers, define an SSL configuration
repertoire that defines a trust file. Then in the administrative console, select Application servers >
server1 > Web Container Settings > Web Container Transport Chains > transport_chain > SSL
Inbound Channel (SSL_2) and specify this repertoire for that transport chain. If you try to use private
headers without setting up an SSL configuration repertoire that does not include a trust file definition,
the private headers will be ignored. If the private headers are ignored, the application server might not
locate the requested application.
After you enable the use of private headers, the transport chain’s SSL inbound channel trusts all
private headers it receives. Therefore, you must ensure that all paths to the transport chain’s SSL
inbound channel are trusted.
7. Tune your Web server with Web server tuning parameters.
8. Propagate the plug-in configuration. The plug-in configuration file (plugin-cfg.xml) is automatically
propagated to the Web server if the Web server plug-in configuration service is enabled, and one of
the following is true:
v The Web server is a local Web server. (It are located on the same machine as an application
server.)
v The Web server is a remote IBM HTTP Server (IHS) Version 6.0 that has a running IHS
Administrative server.
If neither of these conditions is true, the plugin-cfg.xml file must be manually copied to the remote Web
server’s installation location.
The remote Web server installation location is the location you specified when you created the node
for this Web server.

The configuration is complete. To activate the configuration, stop and restart the Web server. If you
encounter problems restarting your Web server, check the http_plugin.log file for information on what
portion of the plugin-cfg.xml file contains an error. The log file states the line number on which the error
occurred along with other details that might help you diagnose why the Web server did not start. You can
then use the administrative console to update the plugin-cfg.xml file.

If applications are infrequently installed or uninstalled, which is usually the situation in a production
environment, or if you can tolerate the performance impact of generating and distributing the plug-in
configuration file each time any of the previously listed actions occur, you should consider enabling this
service.

If you are making a series of simultaneous changes, like installing numerous applications, you might want
the configuration service disabled until after you make the last change. The Web server plug-in
configuration service is enabled by default. To disable this service, in the administrative console click elect
Servers > Application Servers > server_name > Administration Services >Web server plug-in
configuration service and then unselect the Enable automated Web server configuration processing
option.

Tip: If your installation uses a firewall, make sure you configure the Web server plug-in to use a port that
has been opened. (See your security administrator for information on how to obtain an open port.

Web server plug-in properties settings

Use this page to view or change the settings of a Web server plug-in configuration file. The plug-in
configuration file, plugin_cfg.xml, provides properties for establishing communication between the Web
server and the Application Server.

118 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
To view this administrative console page, click Servers > Web Servers >Web_server_name Plug-in
Properties.

On the Configuration tab, you can edit fields. On the Runtime tab, you can look at read-only information.

The Runtime tab is available only when this Web server has accessed applications running on application
servers and there is an http_plugin.log file.

Plug-in log file name

Specifies the fully qualified path to the log file to which the plug-in will write error messages. The default
file path is plugin_install_root/logs/web_server_name/http_plugin.log .

If the file does not exist then it will be created. If the file already exists, it will be opened in append mode
and the previous plug-in log messages will remain.

This field corresponds to the RequestMetrics loggingEnabled element in the plugin-cfg.xml file.

Data type String

Default for Linux and UNIX platforms plugin_install_root/logs/web_server_name/http_plugin.log

Default for Windows platforms plugin_install_root/logs/web_server_name/http_plugin.log

Plug-in installation location

Specifies the fully qualified path to where the plug-in configuration file is installed.

Data type String

Default The default value is the installation root directory.

If you select a Web server plug-in during installation, the installer program configures the Web server to
identify the location of the plugin-cfg.xml file, if possible. The Web server is considered installed on a
local machine if it is on the same machine as the application server. It is considered installed on a remote
machine if the Web server and the application server are on different machines.
v If the Web server is installed on a remote machine, the plug-in configuration file, by default, will be
installed in the plugin_install_root/config/web_server_name directory.
v If the Web server is installed on a local standalone machine, the plug-in configuration file, by default will
be installed in the profile_install_root/config/cells/cell_name/nodes/web_server_name
_node/servers/web_server_name directory.
v If the Web server is installed on a local distributed machine, the plug-in configuration file, by default will
be installed in the
profile_install_root/config/cells/cell_name/nodes/node_name/servers/web_server_name directory.

The installer program adds a directive to the Web server configuration that specifies the location of the
plugin-cfg.xml file.

For remote Web servers, you must copy the file from the local directory where the Application Server is
installed to the remote machine. This is known as propagating the plug-in configuration file. If you are
using an IBM HTTP Server (IHS) V6 for your Web server, WebSphere Application Server can automatically
propagate the plug-in configuration file for you to remote machines provided there is a working HTTP
transport mechanism to propagate the file.

Chapter 3. Setting up the application serving environment 119

Plug-in configuration file name
Specifies the file name of the configuration file for the plug-in. The Application Server generates the
plugin-cfg.xml file by default. The configuration file identifies applications, Application Servers, clusters,
and HTTP ports for the Web server. The Web server uses the file to access deployed applications on
various Application Servers.

Data type String

Default plugin-cfg.xml

If you select a plug-in during installation, the installer program configures the Web server to identify the
location and name of the plugin-cfg.xml file, if possible.

You can change the name of the plug-in configuration file. However, if you do change the file name, you
must also change the Web server configuration to point to the new plug-in configuration file.

Automatically generate plug-in configuration file

To automatically generate a plug-in configuration file to a remote Web server:
v This field must be checked.
v The plug-in configuration service must be enabled

When the plug-in configuration service is enabled, a plug-in configuration file is automatically generated for
a Web server whenever:
v The WebSphere Application Server administrator defines new Web server.
v An application is deployed to an Application Server.
v An application is uninstalled.
v A virtual host definition is updated and saved.

Clear the check box if you want to manually generate a plug-in configuration file for this Web server.

Important: When the plug-in configuration file is generated, it does not include admin_host on the list of
virtual hosts. ″Allowing Web servers to access the administrative console″ in the information
center describes how to add it to the list.

Automatically propagate plug-in configuration file

To automatically propagate a copy of a changed plug-in configuration file to a Web server:
v This field must be checked.
v The plug-in configuration service must be enabled
v A WebSphere Application Server node agent must be on the node that hosts the Web server associated
with the changed plug-in configuration file.

Note: The plug-in configuration file can only be automatically propagated to a remote Web server if that
Web server is an IHS V6.0 Web server and its administration server is running.

Ignore DNS failures during Web server startup

Specifies whether the plug-in ignores DNS failures within a configuration when starting.

This field corresponds to the IgnoreDNSFuilures element in the plugin-cfg.xml file.

When set to true, the plug-in ignores DNS failures within a configuration and starts successfully if at least
one server in each ServerCluster is able to resolve the host name. Any server for which the host name
can not be resolved is marked unavailable for the life of the configuration. No attempts to resolve the host
name are made later on during the routing of requests. If a DNS failure occurs, a log message is written to
the plug-in log file and the plug-in initialization continues rather than causing the Web server not to start.

120 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
When false is specified, DNS failures cause the Web server not to start.

Data type String

Default false

Refresh configuration interval

Specifies the time interval, in seconds, at which the plug-in should check the configuration file to see if
updates or changes have occurred. The plug-in checks the file for any modifications that have occurred
since the last time the plug-in configuration was loaded.

In a development environment in which changes are frequent, a lower setting than the default setting of 60
seconds is preferable. In production, a higher value than the default is preferable because updates to the
configuration will not occur so often. If the plug-in reload fails for some reason, a message is written to the
plug-in log file and the previous configuration is used until the plug-in configuration file successfully
reloads. If you are not seeing the changes you made to your plug-in configuration, check the plug-in log
file for indications of the problem.

Data type Integer

Default 60 seconds.

Plug-in logging
Specifies the location and name of the http_plugin.log file. Also specifies the scope of messages in the
log.

This field corresponds to the RequestMetrics traceLevel element in the plugin-cfg.xml file.

The log describes the location and level of log messages that are written by the plug-in. If a log is not
specified within the configuration file, then, in some cases, log messages are written to the Web server
error log.

On a distributed platform, if the log file does not exist then it will be created. If the log file already exists, it
will be opened in append mode and the previous plug-in log messages will remain.

Log file name - The fully qualified path to the log file to which the plug-in will write error messages.

Data type String

Default plugin_install_root/logs/web_server_name/http_plugin.log

Specify the file path of the http_plugin.log file.

Log level- The level of detail of the log messages that the plug-in should write to the log. You can specify
one of the following values for this attribute:
v Trace. All of the steps in the request process are logged in detail.
v Stats. The server selected for each request and other load balancing information relating to request
handling is logged.
v Warn. All warning and error messages resulting from abnormal request processing are logged.
v Error. Only error messages resulting from abnormal request processing are logged.

If a Log level is not specified, the default value Error is used.

Be careful when setting the level to Trace. A lot of messages are logged at this level which can cause the
disk space/file system to fill up very quickly. A Trace setting should never be used in a normally functioning
environment as it adversely affects performance.

Data type String

Chapter 3. Setting up the application serving environment 121

Default Error

Web server plug-in request and response optimization properties settings

Use this page to view or change the request and response optimization properties for a Web server
plug-in.

To view this administrative console page, click Servers > Web Servers >web_server_name Plug-in
Properties > Request and Response.

On the Configuration tab, you can edit fields. On the Runtime tab, you can look at read-only information.

The Runtime tab is available only when this Web server has accessed applications running on application
servers and there is an http_plugin.log file.

Maximum chunk size used when reading the response body:

Specifies the maximum chunk size the plug-in can use when reading the response body.

This field corresponds to the ResponseChunkSize element in the plugin-cfg.xml file.

The plug-in reads the response body in 64K chunks until all of the response data is read. This approach
causes a performance problem for requests whose response body contains large amounts of data.

If the content length of the response body is unknown, the values specified for this property is used as the
size of the buffer that is allocated. The response body is then read in this size chunks, until the entire body
is read. If the content length is known, then a buffer size of either the content length or the specified size
(whichever is less) is used to read the response body.

Data type Integer

Default 64 kilobytes

Specify the size in kilobytes (1024 byte blocks).

Enable Nagle algorithm for connections to the Application Server:

When checked, the Nagle algorithm is enabled for connections between the plug-in and the Application
Server.

This field corresponds to the ASDisableNagle element in the plugin-cfg.xml file.

The Nagle algorithm is named after engineer John Nagle, who invented this standard part of the
transmission control protocol/internet protocol (TCP/IP). The algorithm reduces network overhead by
adding a transmission delay (usually 20 milliseconds) to a small packet, which lets other small packets
arrive and be included in the transmission. Because communications has an associated cost that is not as
dependent on packet size as it is on frequency of transmission, this algorithm potentially reduces overhead
with a more efficient number of transmissions.

Clear the check box to disable the Nagle algorithm.

Enable Nagle Algorithm for the IIS Web Server:

When checked, the Nagle algorithm is used for connections from the Microsoft Internet Informations
Services (IIS) Web Server to the Application Server.

122 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
This field corresponds to the IHSDisableNagle element in the plugin-cfg.xml file. It only appears if you are
using the Microsoft Internet Informations Services (IIS) Web server. Clear the check box to disable the
Nagle algorithm for this connection.

Chunk response to the client:

When checked, responses to the client are broken into chunks if a Transfer-Encoding : Chunked
response header is present in the response.

This field corresponds to the ChunkedResponse element in the plugin-cfg.xml file. It only appears if you
are using a Microsoft Internet Informations Services (IIS) Web Server, a Java System Web server, or a
Domino Web server. The IHS Web server automatically handles breaking the response into chunks to
send to the client.

Clear the check box to if you do not want responses broken into chunks.

Accept content for all requests: This field corresponds to the AcceptAllContent element in the
plugin-cfg.xml file.

When selected, users can include content in POST, PUT, GET, and HEAD requests when a
Content-Length or Transfer-encoding header is contained in the request header.

Virtual host matching:

When selected, virtual host mapping is performed by physically using the port number for which the
request was received.

This field corresponds to the VHostMatchingCompat element in the plugin-cfg.xml file.

If this field is not selected, matching is done logically using the port number contained in the host header.

Use the radio buttons to make your physical or logical port selection.

Application server port preference:

Specifies which port number the Application Server should use to build URI’s for a sendRedirect.

This field corresponds to the AppServerPortPreference element in the plugin-cfg.xml file.

Specify:
v webserverPort if the port number from the host header of the HTTP request coming in is to be used.
v hostHeader if the port number on which the Web server received the request is to be used.

The default is webserverPort.

Priority used by the IIS Web server when loading the plug-in configuration file:

Specifies the priority in which the Microsoft Internet Informations Services (IIS) Web server loads the
WebSphere Web server plug-in.

This field corresponds to the IISPluginPriority element in the plugin-cfg.xml file. It only appears if you are
using the IIS Web server. Because the IIS Web server uses this value during startup, the Web server must
be restarted before a change to this field takes effect.

Select one of the following priorities:

v High

Chapter 3. Setting up the application serving environment 123

v Medium
v Low

The default value of High ensures that all requests are handled by the Web server plug-in before they are
handled by any other filter/extensions. If problems occur while using a priority of Medium or Low, you will
have to rearrange the order or change the priority of the interfering filter/extension.

Web server plug-in caching properties settings

Use this page to view or change the caching properties for a Web server plug-in.

To view this administrative console page, click Servers > Web Servers >Web_server_name Plug-in
Properties > Caching Properties.

On the Configuration tab, you can edit fields. On the Runtime tab, you can look at read-only information.

The Runtime tab is available only when this Web server has accessed applications running on application
servers and there is an http_plugin.log file.

Enable Edge Side Include (ESI) processing to cache the responses:

Specifies whether to enable Edge Side Include processing to cache the responses.

This field corresponds to the esiEnable element in the plugin-cfg.xml file.

When selected, Edge Side Include (ESI) processing is used to cache responses. If ESI processing is
disabled for the plug-in, the other ESI plug-in properties are ignored. Clear the checkbox to disable Edge
Side Include processing.

Enable invalidation monitor to receive notifications:

When checked, the ESI processor receives invalidations from the Application Server.

This field corresponds to the ESIInvalidationMonitor element in the plugin-cfg.xml file. It is ignored if Edge
Side Include (ESI) processing is not enabled for the plug-in.

Maximum cache size:

Specifies, in 1K byte units, the maximum size of the cache. The default maximum size of the cache is
1024K bytes (1 megabyte). If the cache is full, the first entry to be evicted from the cache is the entry that
is closest its expiration time.

This field corresponds to the esiMaxCacheSize element in the plugin-cfg.xml file.

Data type Integer

Default 1024 kilobytes

Specify the size in kilobytes (1024 byte blocks).

Web server plug-in request routing properties settings

Use this page to view or change the request routing properties for a Web server plug-in.

To view this administrative console page, click Servers > Web Servers >Web_server_name Plug-in
Properties > Plug-in server_cluster_name Properties.

On the Configuration tab, you can edit fields. On the Runtime tab, you can look at read-only information.

124 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
The Runtime tab is available only when this Web server has accessed applications running on application
servers and there is an http_plugin.log file.

Load balancing option:

Specifies the load balancing option that the plug-in uses in sending requests to the various application
servers associated with that Web server.

This field corresponds to the LoadBalanceWeight element in the plugin-cfg.xml file.

Select the appropriate load balancing option:

v Round robin
v Random

The Round Robin implementation has a random starting point. The first application server is picked
randomly. Round Robin is then used to pick application servers from that point forward. This
implementation ensures that in multiple process based Web servers, all of the processes don’t start up by
sending the first request to the same Application Server.

The default load balancing type is Round Robin.

Retry interval:

Specifies the length of time, in seconds, that should elapse from the time an application server is marked
down to the time that the plug-in retries a connection.

This field corresponds to the ServerWaitforContinue element in the plugin-cfg.xml file.

Data type Integer

Default 60 seconds

Maximum size of request content:

Select whether there is a limit on the size of request content. If limited, this field also specifies the
maximum number of bytes of request content allowed in order for the plug-in to attempt to send the
request to an application server.

This field corresponds to the PostSizeLimit element in the plugin-cfg.xml file.

When a limit is set, the plug-in fails any request that is received that is greater than the specified limit.

Select whether to limit the size of request content:

v No limit
v Set limit

If Set limit is selected, specify a limit size.

Data type Integer

Default -1, which indicates there is no limit for the post size.

Specify the size in kilobytes (1024 byte blocks).

Remove special headers:

Chapter 3. Setting up the application serving environment 125

When checked, the plug-in will remove any headers from incoming requests before adding the headers the
plug-in is supposed to add before forwarding the request to an application server.

This field corresponds to the RemoveSpecialHeaders element in the plugin-cfg.xml file.

The plug-in adds special headers to the request before it is forwarded to the application server. These
headers store information about the request that will need to be used by the application. Not removing the
headers from incoming requests introduces a potential security exposure.

Clear the check box to retain special headers.

Clone separator change:

When checked, the plug-in expects the plus character (+) as the clone separator.

This field corresponds to the ServerCloneID element in the plugin-cfg.xml file.

Some pervasive devices cannot handle the colon character (:) used to separate clone IDs in conjunction
with session affinity. If this field is checked, you must also change the configurations of the associated
application servers such that the application servers separates clone IDs with the plus character as well.

Clear the checkbox to use the colon character to separate clone IDs.

Web server plug-in custom properties

If you are using a Web server plug-in, you can add the following custom property to the configuration
settings for that plug-in.

To add a custom property:

1. In the administrative console, click In the administrative console, click Servers > Web Servers >
Web_server_name > Plug-in properties > Custom properties > New
2. Under General Properties specify the name of the custom property in the Name field and a value for
this property in the Value field. You can also specify a description of this property in the Description
field.
3. Click Apply or OK.
4. Click Save to save your configuration changes.
5. Restart the server.

Following is a list of Web server plug-in custom properties that are provided with the Application Server.
These properties are not shown on the properties settings pages for the plug-in.

StashfileLocation

Use this element to set a value for the stashfile initialization parameter.

Data type String

KeyringLocation

Use this element to set a value for the keyring initialization parameter.

Data type String

126 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Web server plug-in configuration service properties settings
Use this page to view or change the configuration settings for the Web server plug-in configuration service.

To view this administrative console page, click Application Servers >server_name > Administration
Services > Web server plug-in configuration service.

On the Configuration tab, you can edit fields. On the Runtime tab, you can look at read-only information.

Enable automated Web server configuration processing

When selected, the Web server plug-in configuration service automatically generates the plug-in
configuration file whenever the Web server environment changes. For example, the plug-in configuration
file is regenerated whenever one of the following activities occurs:
v A new application is deployed on an associated application server.
v The Web server definition is saved.
v An application is removed from an associated application server.
v A new virtual host is defined.

Application Server property settings for a Web server plug-in

Use this page to view or change application server settings for a Web server plug-in.

To view this administrative console page, click Application Servers >server_name > Web Server Plug-in.

On the Configuration tab, you can edit fields. On the Runtime tab, you can look at read-only information.

The Runtime tab is available only when this Web server has accessed applications running on application
servers and there is an http_plugin.log file.

Server role
Specifies the role this application server is assigned.

Select Primary to add this application server to the list of primary application servers. The plug-in initially
attempts to route requests to the application servers on this list.

Select Backup to add this application server to the list of backup application servers. The plug-in does not
load balance across the backup application servers. A backup server is only used if a primary server is not
available. When the plug-in determines that a backup application server is required, it goes through the list
of backup servers, in order, until no servers are left in the list or until a request is successfully sent and a
response received from one of the servers on this list.

Connect timeout
Specifies whether or not there is a limited amount of time the Application Server will maintain a connection
with the Web server.

You can select either No timeout or Set timeout. If you select Set timeout you, must specify, in seconds,
the length of time a connection with the Web server is to be maintained.

This property enables the plug-in to perform non-blocking connections with the application server.
Non-blocking connections are beneficial when the plug-in is unable to contact the destination to determine
whether or not the port is available. If no value is specified for this property, the plug-in performs a
blocking connect in which the plug-in sits until an operating system times out (which could be as long as 2
minutes depending on the platform) and allows the plug-in to mark the server unavailable.

Chapter 3. Setting up the application serving environment 127

A value of 0 causes the plug-in to perform a blocking connect. A value greater than 0 specifies the number
of seconds you want the plug-in to wait for a successful connection. If a connection does not occur after
that time interval, the plug-in marks the server unavailable and fails over to another application server
defined for the requested application.

Data type Integer

Maximum number of connections that can be handled by the Application Server

Specifies the maximum number of pending connections to an Application Server that can be flowing
through a Web server process at any point in time.

This field corresponds to the ServerMaxConnections element in the plugin-cfg.xml file.

You can select either No limit or Set limit. If you select Set limit you, must specify the maximum number
of connections that can exist between the Web server and the Application Server at any given point in
time.

For example, assuming that:

v The application server is fronted by 5 nodes that are running an IHS Web server.
v Each node starts 2 processes.
v This property is set to 50.

In this example, the application server could potentially get up to 500 connections. (You take the number
of nodes, 5, multiply it by the number of processes, 2, and then multiply that number by the number
specified for this property, 50, for a total of 500 connections.)

If this attribute is set to either zero or -1, there is no limit to the number of pending connections to the
Application Servers.

Data type Integer

Default -1

Use extended handshake to check whether Application Server is running

When selected, the Web server plug-in will use an extended handshake to check whether or not the
Application Server is running.

This field corresponds to the ServerExtendedHandshake element in the plugin-cfg.xml file.

Select this property if a proxy firewall is between the plug-in and the application server.

The plug-in marks a server as down when the connect() fails. However, when a proxy firewall is in
between the plug-in and the application server, the connect() will succeed, even though the back end
application server is down. This causes the plug-in to not failover correctly to other application servers.

If the plug-in performs some handshaking with the application server to ensure that it is started before it
sends a request it can failover to another application server if it detects that the application server with
which it is attempting to perform a handshake is down.

Send the header ″100 Continue″ before sending the request content
This field corresponds to the WaitForContinue element in the plugin-cfg.xml file.

When selected, the Web server plug-in will send the header ″100 Continue″ to the Application Server
before it sends the request content.

128 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Web server plug-in configuration properties
The following table indicates which panel in the administrative console you need to use to manually
configure a Web server plug-in property.
Table 13. Web server plug-in configuration properties
Administrative console panel Field name Configuration property name
In the administrative console, click Refresh configuration interval RefreshInterval
Servers > Web Servers
>Web_server_name > Plug-in
properties
In the administrative console, click Plug-in log file name Log->name
Servers > Web Servers >
Web_server_name > Plug-in
properties
In the administrative console, click Plug-in logging Log->LogLevel
Servers > Web Servers >
Web_server_name > Plug-in
properties
In the administrative console, click Ignore DNS failures during Web IgnoreDNSFailures
Servers > Web Servers > server startup
Web_server_name > Plug-in
properties
In the administrative console, click KeyringLocation Keyring
Servers > Web Servers >
Web_server_name > Plug-in
properties > Custom properties >
New
In the administrative console, click StashfileLocation Stashfile
Servers > Web Servers >
Web_server_name > Plug-in
properties > Custom properties >
New
In the administrative console, click Load balancing option LoadBalance
Servers > Web Servers >
Web_server_name > Plug-in
properties > Request routing
In the administrative console, click Clone separator change CloneSeparatorChange
Servers > Web Servers >
Web_server_name > Plug-in
properties > Request Routing
In the administrative console, click Retry interval RetryInterval
Servers > Web Servers >
Web_server_name > Plug-in
properties > Request Routing
In the administrative console, click Maximum size of request content PostSizeLimit
Servers >Web server_name >
Plug-in properties > Request
routing
In the administrative console, click Remove special headers RemoveSpecialHeaders
Servers > Web Servers >
Web_server_name > Plug-in
properties > Request routing

Chapter 3. Setting up the application serving environment 129

Table 13. Web server plug-in configuration properties (continued)
In the administrative console, click Server role PrimaryServers and BackupServers
Application Servers >server_name > list
Web server plug-in properties
In the administrative console, click Connect timeout Server ConnectTimeout
Application Servers >server_name >
Web server plug-in properties
In the administrative console, click Use extended handshake to check Server Extended Handshake
Application Servers >server_name > whether Application Server is running
Web server plug-in properties
In the administrative console, click Send the header ″100 Continue″ WaitForContinue
Application Servers >server_name > before sending the request content
Web server plug-in properties
In the administrative console, click Maximum number of connections that Server MaxConnections
Application Servers >server_name > can be handled by the Application
Web server plug-in properties Server
In the administrative console, click Application server port preference AppServerPortPreference
Servers > Web Servers >
Web_server_name > Plug-in
properties > Request and
Response
In the administrative console, click Enable Nagle algorithm for ASDisableNagle
Servers > Web Servers > connections to the Application Server
Web_server_name > Plug-in
properties > Request and
Response
In the administrative console, click Enable Nagle Algorithm for the IIS IISDisableNagle
Servers > Web Servers > Web Server
Web_server_name > Plug-in
properties > Request and
Response
In the administrative console, click Virtual host matching VHostMatchingCompat
Servers > Web Servers >
Web_server_name > Plug-in
properties > Request and
Response
In the administrative console, click Maximum chunk size used when ResponseChunkSize
Servers > Web Servers > reading the response body
Web_server_name > Plug-in
properties > Request and
Response
In the administrative console, click Accept content for all requests AcceptAllContent
Servers > Web Servers >
Web_server_name > Plug-in
properties > Request and
Response
In the administrative console, click Chunk response to the client ChunkedResponse
Servers > Web Servers >
Web_server_name > Plug-in
properties > Request and
Response

130 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Table 13. Web server plug-in configuration properties (continued)
In the administrative console, click Priority used by the IIS Web server IISPluginPriority
Servers > Web Servers > when loading the plug-in configuration
Web_server_name > Plug-in file
properties > Request and
Response
In the administrative console, click Enable Edge Side Include (ESI) ESIEnable
Servers > Web Servers > processing to cache the responses
Web_server_name > Plug-in
properties > Caching
In the administrative console, click Maximum cache size ESIMaxCacheSize
Servers > Web Servers >
Web_server_name > Plug-in
properties > Caching
In the administrative console, click Enable invalidation monitor to receive ESIInvalidationMonitor
Servers > Web Servers > notifications
Web_server_name > Plug-in
properties > Caching

Web server plug-in connections

The WebSphere Application Server Web server plug-ins are used to establish and maintain persistent
HTTP and HTTPS connections to Application Servers .

When the plug-in is ready to send a request to the application server, it first checks its connection pool for
existing connections. If an existing connection is available the plug-in checks its connection status. If the
status is still good, the plug-in uses that connection to send the request. If a connection does not exist, the
plug-in creates one. If a connection exists but has been closed by the application server, the plug-in closes
that connection and opens a new one.

After a connection is established between a plug-in and an application server, it will not be closed unless
the application server closes it for one of the following reasons:
v If the Use Keep-Alive property is selected and the time limit specified on the Read timeout or Write
timeout property for the HTTP inbound channel has expired.
v The maximum number of persistent requests which can be processed on an HTTP inbound channel has
been exceeded. (This number is set using the HTTP inbound channel’s Maximum persistent requests
property.)
v The Application Server is shutting down.

Even if the application server closes a connection, the plug-in will not know that it has been closed until it
tries to use it again. The connection will be closed if one of the following events occur:
v The plug-in receives a new HTTP request and tries to reuse the existing connection.
v The number of httpd processes drop because the Web server is not receiving any new HTTP requests.
(For the IHS Web server, the number of httpd processes that are kept alive depends on the value
specified on the Web server’s MinSpareServers directive.)
v The Web server is stopped and all httpd processes are terminated, and their corresponding sockets are
closed.

Note: Sometimes, if a heavy request load is stopped or decreased abruptly on a particular application
server, a lot of the plug-in’s connections to that application server will be in CLOSE_WAIT state.
Because these connections will be closed the first time the plug-in tries to reuse them, having a
large number of connections in CLOSE-WAIT state should not affect performance

Chapter 3. Setting up the application serving environment 131

Web server plug-in remote user information processing
You can configure your Web server with a third-party authentication module and then configure the Web
server plug-in to route requests to the Application Server. If an application calls the getRemoteUser()
method, it relies on a private HTTP header that contains the remote user information and is parsed by the
plug-in. The plug-in sets the private HTTP header value whenever a Web server authentication module
populates the remote user in the Web server data structure. If the private HTTP header value is not set,
the application’s call to getRemoteUser() returns a null value.
v In the case of an Apache and IBM HTTP Server (IHS) Web server, the plug-in builds the private header
from the information contained in the associated request record.
v In the case of a Sun One Web server, the plug-in builds the private header from the information
contained in the auth_user property associated with the request. The private header is usually set to
the name of the local HTTP user of the Web browser, if HTTP access authorization is activated for the
URL.
v In the case of a Domino Web server, the plug-in builds the private header from the information
contained in the REMOTE_USER environment variable. The plug-in sets this variable to anonymous
for users who have not logged in and to the username for users who are logged into the application.
v In the case of an Internet Information Services (IIS) Web server, the plug-in builds the private header
from the information contained in the REMOTE_USER environment variable. The plug-in sets this
variable to the name of the user as it is derived from the authorization header sent by the client.

If the private header is not being set in the Sun One, IIS, or Domino Web server plug-in, make sure the
request record includes information about the user requesting the data.

Note: If an application’s call to getRemoteUser() returns a null value, or if the correct remote user
information is not being added to the Web server plug-in’s data structure, make sure the remote
user parameter within the WebAgent is still set to YES. (Sometimes this parameter gets set to NO
when service is applied.)

Web server plug-ins

Web server plug-ins enable the Web server to communicate requests for dynamic content, such as
servlets, to the application server. A Web server plug-in is associated with each Web server definition. The
configuration file (plugin-cfg.xml) that is generated for each plug-in is based on the applications that are
routed through the associated Web server.

A Web server plug-in is used to forward HTTP requests from a supported Web server to an application
server. Using a Web server plug-in to provide communication between a Web server and an application
server has the following advantages:
v XML-based configuration file
v Standard protocol recognized by firewall products
v Security using HTTPS, replacing proprietary Open Servlet Engine (OSE) over Secure Sockets Layer
(SSL)

Each of the supported distributed platform Web server plug-ins run on a number of operating systems.
See Supported Hardware and Software at
http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.htmlfor the product for the most
current information about supported Web servers.

Checking your IBM HTTP Server version

At times, you might need to determine the version of your IBM HTTP Server installation.
1. Change directory to the installation root of the Web server. For example, this is /opt/IBMIHS on a
Solaris machine.

132 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
2. Find the subdirectory that contains apache.exe (on a Windows platforms) or apachectl (on a
UNIX-based platforms, such as z/OS, Solaris, Linux, and HP-UX)
3. On a Windows platform, issue:
apache.exe -V
4. On a UNIX-based platforms issue:
./apachectl -V 4

The version is shown in the ″Server version:″ field and will looks something like the following:
Server version: IBM_HTTP_Server/2.0.47 Apache/2.0.47
Server built: July 2 2004 20:38:36
Server’s Module Magic Number: 20020903:4.

Web server tuning parameters

WebSphere Application Server provides plug-ins for several Web server brands and versions. Each Web
server operating system combination has specific tuning parameters that affect the application
performance.
v IBM HTTP Server
The IBM HTTP Server V6.0 is a multi-process, multi-threaded server.
– Access logs
- Description: Collects all incoming HTTP requests. Logging degrades performance because IO
operation overhead causes logs to grow significantly in a short time.
- How to view or set:
1. Open the IBM HTTP Server httpd.conf file, located in the directory
IBM_HTTP_Server_root_directory/conf.
2. Search for a line with the text CustomLog.
3. Comment out this line by placing # in front of the line.
4. Save and close the httpd.conf file.
5. Stop and restart the IBM HTTP Server.
- Default value: Logging of every incoming HTTP request is enabled.
- Recommended value: Disable the access logs.
– MaxClients
- Description: The MaxClients directive controls the maximum number of simultaneous connections
or users that the web server can service at any one time. If, at peak usage, your web server
needs to support 200 active users at once, you should set MaxClients to 220 (200 plus an extra
10% for load growth). Setting MaxClients too low could cause some users to believe the web
server is not responding. You should have sufficient RAM in your web server machines to support
each connected client. For IBM HTTP Server V6.0 on UNIX, you should allocate around 1.5MB
MaxClients of RAM for use by the IBM HTTP Server. For IBM HTTP Server V6.0 on Windows,
you should allocate around 300KB MaxClients of RAM for use by the IBM HTTP Server. Some
third party modules can significantly increase the amount of RAM used per connected client.
- How to view or set: Edit the MaxClients directive in the IBM HTTP Server httpd.conf file,
located in the directory IBM_HTTP_Server_root_directory/conf.
- Default value: 150
- Recommended value: The maximum number of users normally simultaneously connected to your
web server, plus an additional 10% for buffer. Note: The KeepAliveTimeout setting can affect how
long a user is connected to the webserver.
– MinSpareServers, MaxSpareServers, and StartServers
- Description: Pre-allocates and maintains the specified number of processes so that few
processes are created and destroyed as the load approaches the specified number of processes.
Specifying similar values reduces the CPU usage for creating and destroying HTTPD processes.
Adjust this parameter if the time waiting for IBM HTTP Server to start more servers, so that it can
handle HTTP requests, is not acceptable.
- How to view or set: Edit the MinSpareServers, MaxSpareServers and StartServers directives in
the httpd.conf file located in the IBM_HTTP_Server_root_directory/conf directory.
- Default value: MinSpareServers 5, MaxSpareServers 10, StartServers 5
Chapter 3. Setting up the application serving environment 133
 - Recommended value: For optimum performance, specify the same value for the
MinSpareServers and the StartServers parameters. If MaxSpareServers is set to less than
MinSpareServers, IBM HTTP Server resets MaxSpareServer=MinSpareServer+1. Setting the
StartServers too high can cause swapping if memory is not sufficient, degrading performance.
– ListenBackLog
- Description: Sets the length of a pending connections queue. When several clients request
connections to the IBM HTTP Server, and all threads used, a queue exists to hold additional client
requests. However, if you use the default Fast Response Cache Accelerator (FRCA) feature of
IBM HTTP Server V6.0 on Windows, the ListenBackLog directive is not used since FRCA has its
own internal queue.
- How to view or set: For non-FRCA: Edit the IBM HTTP Server httpd.conf file. Then, add or
view the ListenBackLog directive.
- Default value: For HTTP Server V6.0: 1024 with FRCA enabled, 511 with FRCA disabled
- Recommended value: Use the defaults.
v IBM HTTP Server - Linux
– MaxRequestsPerChild
- Description: Sets the limit on the number of requests that an individual child server process
handles. After the number of requests reaches the value set for the MaxRequestsPerChild
parameter, the child process dies. Adjust this parameter if destroying and creating child processes
is degrading your Web server performance.
- How to view or set:
1. Edit the IBM HTTP server httpd.conf file located in the IBM_HTTP_Server_root_directory/conf
directory.
2. Change the value of the parameter.
3. Save the changes and restart the IBM HTTP server.
- Default value: 500
- Recommended value: Should normally be set to 0. Non-zero settings can be useful if child
memory usage is observed to steadly increase over time. Memory leaks have occasionally been
observed in third party modules and various OS runtime libraries used by the IBM HTTP Server.
v IBM HTTP Server - Windows 2000 and Windows 2003
– ThreadsPerChild
- Description: Sets the number of concurrent threads running at any one time within the IBM HTTP
Server.
- How to view or set: Edit the IBM HTTP Server file httpd.conf file located in the directory
IBM_HTTP_Server_root_directory/conf. Change the value of the parameter. Save the changes and
restart the IBM HTTP Server.
There are two ways to find how many threads are used under load:
1. Use the Windows 2000 and Windows 2003 Performance Monitor under the desktop Start
menu:
a. Right-click the status bar on your desktop. Click Task Manager.
b. Select the Processes tab.
c. Click View > Select Columns.
d. Select Thread Count.
e. Click OK.
The Processes tab shows the number threads for each process under the column name
Threads, including Apache.
2. Use the IBM HTTP Server server-status (this choice works on all platforms, not just
Windows):
a. Edit the IBM HTTP Server httpd.conf file as follows: Remove the comment character #
from the following lines: #LoadModule status_module, modules/ApacheModuleStatus.dll,
#<Location/server-status>, #SetHandler server-status, and #</Location>.
b. Save the changes and restart the IBM HTTP Server.
c. In a Web browser, go to the URL: http://yourhost/server-status. Alternatively,
d. Click Reload to update status.

134 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 e. (Optional) If the browser supports refresh, go to http://your_host/server-
status?refresh=5 to refresh every five seconds. You will see five requests currently
processing 45 idle servers.
- Default value: 250 for IBM HTTP Server V6.0.
- Recommended value: Set this value to prevent bottlenecks, allowing just enough traffic through
to the application server.
– Web server configuration reload interval
- Description: Tracks a variety of configuration information about WebSphere Application Server
resources. The Web server needs to understand some of this information, such as Uniform
Resource Identifiers (URIs) pointing to WebSphere Application Server resources. This
configuration data is pushed to the Web server through the WebSphere Application Server plug-in
at intervals specified by this parameter. Periodic updates add new servlet definitions without
having to restart any of the WebSphere Application Server servers. However, the dynamic
regeneration of this configuration information is costly in terms of performance. Adjust this
parameter in a stable production environment.
- How to view or set:Use the Refresh configuration interval Web server plug-in property to change
the current setting for this parameter. In the administrative console, click Servers > Web Servers
>Web_server_name > Plug-in properties.
- Default value: The default reload interval is 60 seconds.
- Recommended value: Increase the reload interval to a value that represents an acceptable wait
time between the servlet update and the Web server update.
For more information about the plugin-cfg.xml file see the topic “Web server plug-ins” on page 132.
v Sun Java System Web server, Enterprise Edition (formerly Sun ONE) - Solaris operating
environment
The default configuration of the Sun ONE Web server, Enterprise Edition provides a single-process,
multi-threaded server.
– Active threads
- Description: Specifies the current number of threads active in the server. After the server reaches
the limit set with this parameter, the server stops servicing new connections until it finishes old
connections. If this setting is too low, the server can become throttled, resulting in degraded
response times. To tell if the Web server is being throttled, consult its perfdump statistics. Look at
the following data:
v WaitingThreads count: If WaitingThreads count is getting close to zero, or is zero, the server
is not accepting new connections.
v BusyThreads count: If the WaitingThreads count is close to zero, or is zero, BusyThreads is
probably very close to its limit.
v ActiveThreads count: If ActiveThreads count is close to its limit, the server is probably limiting
itself.
- How to view or set: Use the Maximum number of simultaneous requests parameter in the
Enterprise Server Manager interface to control the number of active threads within Sun ONE Web
server, Enterprise Edition. This setting corresponds to the RqThrottle parameter in the
magnus.conf file.
- Default value: 512
- Recommended value: Increase the thread count until the active threads parameters show
optimum behavior.
v Microsoft Internet Information Server (IIS) - Windows NT and Windows 2000
– IIS permission properties
- Description: The Web server has several properties that dramatically affect the performance of
the application server. The default settings are usually acceptable. However, because other
products can change the default settings without user knowledge, make sure to check the IIS
settings for the Home Directory permissions of the Web server. The permissions should be set to
Script and not to Execute. If the permissions are set to Execute, no error messages are returned,
but the performance of WebSphere Application Server is decreased.
- How to view or set: To check or change these permissions, perform the following procedure in
the Microsoft management console:

Chapter 3. Setting up the application serving environment 135

 1. Select the Web site (usually default Web site).
2. Right-click and select the Properties option.
3. Click the Home Directory tab. To set the permissions of the Home Directory:
a. In the Application settings, select the Script check box in the Permissions list and clear
the Execute check box.
b. (Optional) Check the permissions of the sePlugin:
1) Expand the Web server.
2) Right-click the sePlugin and select Properties.
3) Confirm that the Execute permissions are set to Execute.
- Default value: Script
- Recommended value: Script
– Number of expected hits per day
- Description: Controls the memory that IIS allocates for connections.
- How to view or set: Using the performance window, set the parameter to More than 100000 in
the Web site properties panel of the Microsoft management console.
- Default value: Fewer than 100000
- Recommended value: More than 100000
– ListenBackLog parameter
- Description: Alleviates failed connections under heavy load conditions, if you are using IIS on
Windows NT and Windows 2000. Failure typically occurs when you are using more than 100
clients. ListenBackLog increases the number of requests that IIS keeps in its queue. Consider
raising this value if you see intermittent Unable to locate server errors in the Netscape
browser.
- How to view or set:
1. Use a command prompt to issue the regedit command to access the operating system
registry.
2. In the registry window, locate the parameter in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
InetInfo\Parameters\ListenBackLog directory.
3. Right-click the parameter to adjust the setting according to the server load.
- Default value: 25 (decimal)
- Recommended value: You can set the ListenBackLog parameter can be set as high as 200,
without negative impact on performance and with an improvement in load handling.

Modifying the WebSphere plug-in to improve performance

You can improve the performance of IBM HTTP Server V6.0 (with the WebSphere Web server plug-in) by
modifying the plug-in’s RetryInterval configuration. The RetryInterval is the length of time to wait before
trying to connect to a server that has been marked temporarily unavailable. Making this change can help
the IBM HTTP Server V6.0 to scale higher than 400 users.

The plug-in marks a server temporarily unavailable if the connection to the server fails. Although a default
value is 60 seconds, it is recommended that you lower this value in order to increase throughput under
heavy load conditions. Lowering the RetryInterval is important for IBM HTTP Server V6.0 on UNIX
operating systems that have a single thread per process, or for IBM HTTP Server 2.0 if it is configured to
have fewer than 10 threads per process.

How can lowering the RetryInterval affect throughput? If the plug-in attempts to connect to a particular
application server while the application server threads are busy handling other connections, which
happens under heavy load conditions, the connection times out and the plug-in marks the server
temporarily unavailable. If the same plug-in process has other connections open to the same server and a
response is received on one of these connections, the server is marked again. However, when you use
the IBM HTTP Server V6.0 on a UNIX operating system, there is no other connection since there is only
one thread and one concurrent request per plug-in process. Therefore, the plug-in waits for the
RetryInterval before attempting to connect to the server again.

136 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Since the application server is not really down, but is busy, requests are typically completed in a small
amount of time. The application server threads become available to accept more connections. A large
RetryInterval causes application servers that are marked temporarily unavailable, resulting in more
consistent application server CPU utilization and a higher sustained throughput.

Note: Although lowering the RetryInterval can improve performance, if all the application servers are
running, a low value can have an adverse affect when one of the application servers is down. In
this case, each IBM HTTP Server V6.0 process attempts to connect and fail more frequently,
resulting in increased latency and decreased overall throughput.

Gskit install images files

The Global Security Kit (GSKit) installation image files for the WebSphere Web server plug-ins are
packaged on the CD with the Web server plug-in files. You can download the appropriate GSKIT file to the
workstation on which your Web server is running. Use the following table to assist you in selecting the
correct GSKIT installation image file.

Operating system GSKit 7 Installation image file

Windows No image name
AIX gskta.rte
HP-UX gsk7bas
Solaris Operating Environment gsk7bas
Linux gsk7bas_7.0.3.1.i386.rpm
Linux390 gsk7bas-7.0.3.1.s390.rpm
LinuxPPC gsk7bas-7.0.3.1.ppc.rpm

Plug-ins: Resources for learning

See this topic in the V6 Information Center to find links links to relevant supplemental information about
Web server plug-ins. The information resides on IBM and non-IBM Internet sites, whose sponsors control
the technical accuracy of the information.

These links are provided for convenience. Often, the information is not specific to the IBM WebSphere
Application Server product, but is useful all or in part for understanding the product. When possible, links
are provided to technical papers and Redbooks that supplement the broad coverage of the release
documentation with in-depth examinations of particular product areas.

Web server plug-in tuning tips

Balancing workloads:

During normal operation, the backlog of connections pending to an application server is bound to grow.
Therefore, balancing workloads among application servers in a network fronted by a Web server plug-in
helps improve request response time.

In a distributed environment, you can limit the number of connections that can be handled by an
applications server. To do this:
1. Go to the Servers > Application Servers >server_name.
2. Under Additional Properties, click > Web Server Plug-in properties .
3. Select Set limit for the Minimum number of connections that can be handled by the Application Server
field.
4. Specify in the Connections field the maximum number of connections you want to allow.
5. Then click Apply and Save.

Chapter 3. Setting up the application serving environment 137

When this maximum number of connections is reached, the plug-in, when establishing connections,
automatically skips that application server, and tries the next available application server. If no application
servers are available, an HTTP 503 response code will be returned to the client. This code indicates that
the server is currently unable to handle the request because it is experiencing a temporary overloading or
because maintenance is being performed.

The capacity of the application servers in the network determines the value you specify for the maximum
number of connections. The ideal scenario is for all of the application servers in the network to be
optimally utilized. For example, if you have the following environment:
v There are 10 application servers in a cluster.
v All of these application servers host the same applications (that is, Application_1 and Application_2).
v This cluster of application servers is fronted by five IBM HTTP Servers.
v The IBM HTTP Servers get requests through a load balancer.
v Application_1 takes approximately 60 seconds to respond to a request
v Application_2 takes approximately 1 second to respond to a request.

Depending on the request arrival pattern, all requests to Application_1 might be forwarded to two of the
application servers, say Appsvr_1 and Appsvr_2. If the arrival rate is faster than the processing rate, the
number of pending requests to Appsvr_1 and Appsvr_2 can grow.

Eventually, Appsvr_1 and Appsvr_2 are busy and are not able to respond to future requests. It usually
takes a long time to recover from this overloaded situation.

If you want to maintain 2500 connections, and optimally utilize the Application Servers in this example, set
the number of maximum connections allowed to 50. (This value is arrived at by dividing the number of
connections by the result of multiplying the number of Application Servers by the number of Web servers;
in this example, 2500/(10x5)=50.)

Limiting the number of connections that can be established with an application server works best for Web
servers that follow the threading model instead of the process model, and only one process is started.

The IBM HTTP Server V6.0.x follows the threading model. To prevent the IBM HTTP Server from starting
more than one process, change the following properties in the Web server configuration file (httpd.conf)
to the indicated values:
ServerLimit 1
ThreadLimit 4000
StartServers 1
MaxClients 1024
MinSpareThreads 1
MaxSpareThreads 1024
ThreadsPerChild 1024
MaxRequestsPerChild 0

Improving performance in a high stress environment:

If you use the default settings for a Microsoft Windows operating system, you might encounter Web server
plug-in performance problems if you are running in a high stress environment. To avoid these problems,
consider tuning the the TCP/IP setting for this operating system. Two of the keys setting to tune are
TcpTimedWaitDelay and MaxUserPort.

To tune the TcpTimedWaitDelay setting, change the value of the tcp_time_wait_interval parameter from the
default value of 240 seconds, to 30 seconds:
1. Locate in the Windows Registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\TcpTimedWaitDelay

138 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 If this entry does not exist in your Windows Registry, create it by editing this entry as a new DWORD
item.
2. Specify, in seconds, a value between 30 and 300 inclusive for this entry. (It is recommended that you
specify a value of 30. )

To tune the MaxUserPort setting:

1. Locate in the Windows Registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\MaxUserPort

If this entry does not exist in your Windows Registry, create it by editing this entry as a new DWORD
item.
2. Set the maximum number of ports to a value between 5000 and 65534 ports, inclusive. (It is
recommended that you specify a value of 65534,)

See the Microsoft Web site for more information about these settings.

Tuning Web servers

“Web server tuning parameters” on page 133 lists tuning parameters specific to Web servers. The listed
parameters may not apply to all of the supported Web servers. Check your Web server documentation
before using any of these parameters.

Setting up the administrative architecture

After you install and set up the Network Deployment product, you mainly need to monitor and control
incorporated nodes and the resources on those nodes by using the administrative console or other
administrative tools. Use the following tasks to perform these activities.
1. Use the settings page for an administrative service to configure administrative services.
2. Configure cells.
3. Configure deployment managers.
4. Manage nodes.
5. Manage node agents.
6. Manage node groups.
7. Configure remote file services.

Cells
Cells are logical groupings of one or more nodes in a WebSphere Application Server distributed network.

A cell is a configuration concept, a way for administrators to logically associate nodes with one another.
Administrators define the nodes that make up a cell, according to the specific criteria that make sense in
their organizational environments.

Administrative configuration data is stored in XML files. A cell retains master configuration files for each
server in every node in the cell. Each node and server also have their own local configuration files.
Changes to a local node or to a server configuration file are temporary, if the server belongs to the cell.
While in effect, local changes override cell configurations. Changes to the master server and master node
configuration files made at the cell level replace any temporary changes made at the node when the cell
configuration documents are synchronized to the nodes. Synchronization occurs at designated events,
such as when a server starts.

Chapter 3. Setting up the application serving environment 139

Configuring cells
When you created a deployment manager profile, a cell was created. A cell provides a way to group one
or more nodes of your Network Deployment product. You probably will not need to re-configure the cell. To
view information about and manage a cell, use the settings page for a cell.
1. Access the settings page for a cell. Click System Administration > Cell from the navigation tree of
the administrative console.
2. If the protocol that the cell uses to retrieve information from a network is not appropriate for your
system, select the appropriate protocol. By default, a cell uses Transmission Control Protocol (TCP). If
you want the cell to use User Diagram Protocol, select UDP from the drop-down list for Cell
Discovery Protocol on the settings page for the cell. It is unlikely that you will need to change the
cell’s protocol configuration from TCP.
3. Click Custom Properties and define any name-value pairs needed by your deployment manager.
4. When you installed the WebSphere Application Server Network Deployment product, a node was
added to the cell. You can add additional nodes on the Node page. Click Nodes to access the Node
page, which you use to manage nodes.

Note: Both Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) are now
supported by WebSphere Application Server, but there are restrictions that apply to using both
IPv4 and IPv6 in the same cell. Note that when you add a node to a cell, the format in which
you specify the host name is based on the version of IP the node will be using. For details, see
“IP version considerations for cells.”

IP version considerations for cells

Internet Protocol Version 4 is no longer viable for many businesses. Because it is based on 32-bit
architecture, there is a growing shortage of Internet Protocol Version 4 (IPv4) addresses. Internet Protocol
Version 6 (IPv6) is based on 128-bit architecture, which allows a far greater number of addresses to be
available for use over the Internet.

In response, WebSphere Application Server Version 6 now includes support for IPv6, in addition to
continued support for IPv4. This means that nodes running WepSphere Application Server Version 6 can
use IPv6. (However, note that nodes running WebSphere Application Server Version 5.x cannot use IPv6.)

WebSphere Application Server Version 6 supports a dual mode environment in which you can have older
legacy applications running on IPv4 and IPv6-enabled applications running on IPv6. Note, however, that
there are restrictions on using IPv4 and IPv6 in the same cell. This article documents those restrictions as
well as outlines the ways in which you can set up your cells, depending on the version of IP that you will
be using.

From an IP perspective, you must adhere to one of the following scenarios:

Dual mode cell

In a dual mode cell, mixed IPv4 and IPv6 communications are supported. By default, a cell is set to dual
mode when it is created. Note, however, that only nodes running WebSphere Application Server Version 6
are valid in a dual mode cell.

IPv4 and IPv6 nodes cannot communicate with each other, so the purpose of the dual mode cell is to
enable this communication, thereby allowing you to use your existing applications, running over IPv4, with
newer applications that have been enabled for IPv6.

The following illustration shows a dual mode cell:

140 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Dual mode cell

Cell (dual mode)

Node A Node B Node C

WebSphere WebSphere WebSphere

IPv6 Application IPv6 Application IPv6 Application
Server v6.0 Server v6.0 Server v6.0

Node D Node E

WebSphere WebSphere
IPv4 Application IPv4 Application
Server v6.0 Server v6.0

IPv4-only cell

In an IPv4-only cell, all nodes must:

v Use IPv4
v Run WebSphere Application Server Version 5.x
v Have host names defined as strings or 32-bit numerical addresses.

IPv4-only cell

Cell (IPv4)

Node A Node B Node C

WebSphere WebSphere WebSphere

IPv4 Application IPv4 Application IPv4 Application
Server V5.x Server V5.x Server V5.x

Node D Node E

WebSphere WebSphere
IPv4 Application IPv4 Application
Server V5.x Server V5.x

Chapter 3. Setting up the application serving environment 141

It is important to note that, by default, a cell is set to dual mode. However, in order to run in an IPv4-only
environment, you will need to explicitly set the cell to IPv4. See the section on JVM settings, in this article,
for more information.

Note: If you want to run a combination of WebSphere Application Server Version 5.x and WebSphere
Application Server Version 6.0 nodes over IPv4, see the section on setting up a mixed node cell,
below.

Mixed node cell

A mixed node cell consists of some nodes running WebSphere Application Server Version 5.x and other
nodes running WebSphere Application Server Version 6. In a mixed node cell, all nodes must use IPv4.
When defining a node that will be used in a mixed node cell, you must specify the host name as a string
or as a 32-bit numerical address, regardless of whether the node is running WebSphere Application Server
Version 5.x or WebSphere Application Server Version 6. 128-bit numerical addresses may not be
specified.

Mixed node cell

Cell (IPv4)

Node A Node B Node C

WebSphere WebSphere WebSphere

IPv4 Application IPv4 Application IPv4 Application
Server V5.x Server V5.x Server V5.x

Node D Node E

WebSphere WebSphere
IPv4 Application IPv4 Application
Server V6.0 Server V6.0

In a mixed node cell, even though the WebSphere Application Server Version 6 nodes will be configured to
use IPv4, the operating system running on them can still support both IPv4 and IPv6. This is true as long
as the WebSphere Application Server Version 6 nodes are configured with string-based host names or
32-bit numerical addresses.

Note also, that you can only add Version 5.x nodes into a mixed node cell through migration. You first
need to migrate from a Version 5.x Deployment Manager to a Version 6.0 Deployment Manager, and then
either keep the Version 5.x nodes or migrate them to Version 6.0 nodes.

IPv6-only cell

In an IPv6-only cell, all nodes must:

v Use IPv6
v Run WebSphere Application Server Version 6
v Have host names defined as strings or 128-bit numerical addresses.
142 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
IPv6-only cell

Cell (IPv6)

Node A Node B Node C

WebSphere WebSphere WebSphere

IPv6 Application IPv6 Application IPv6 Application
Server V6.0 Server V6.0 Server V6.0

Node D Node E

WebSphere WebSphere
IPv6 Application IPv6 Application
Server V6.0 Server V6.0

Specifying host names

During the installation of WebSphere Application Server, you are asked to provide the host name or IP
address of the machine on which the installation is being carried out in the Host Name or IP address field.
The host name or IP address that you specify is used to advertise this installation to all other WebSphere
Application Server installations in the cell configurations. All nodes in the cell will use the host names or IP
addresses that are defined in this way to reach each other. In general, it is best to always use a host
name to identify a WebSphere Application Server installation. By using a host name, you will not have to
be concerned about which IP address is being used (32-bit versus 128-bit), whether it runs on IPv4 or
IPv6, and so on. As long as the DNS service is properly configured, the nodes should all be able to work
together.

However, if you prefer, you can control which IP stack or address is used. To do this, enter the specific IP
address (32-bit for IPv4 or 128-bit for IPv6) into the Host Name or IP Address field. This installation will
then be identified with this IP address and other WebSphere Application Server nodes will use this IP
address to communicate with this node.

When specifying IPv6 addresses, it is good practice to always surround them with protective square
brackets. For example, [fe80::202:57ff:fec4:2334]. The reason for this is that in system internal
processing, IP addresses are often combined with port numbers in the form of <IP address>:<port
number> , and the colons in IPv6 addresses could be confusing in such circumstances. Note that you
cannot use IPv6 addresses, including IPv6 addresses surrounded by square brackets, within the
administrative console or the install wizard.

Note that in scripting, the square brackets might have special meaning, depending on the language
binding used (for example, Jacl). You can work around this problem by using a special escape character in
front of the opening and closing brackets. Using the Jacl binding, for example, the same IPv6 address
cited earlier can be entered as \[fe80::202:57ff:fec4:2334\]

Chapter 3. Setting up the application serving environment 143

Note: While you cannot use square brackets with IPv6 addresses within the administrative console, you
must use square brackets to specify an IPv6 address as part of the adminstrative console’s URL in
a browser. This allows the browser to distinguish the IPv6 address from the port value.

Multicast configuration

WebSphere Application Server uses multicast broadcasting at the node level to allow a node agent to
discover the managed processes in the node. IPv4 and IPv6 addresses are not compatible. Therefore, to
allow a WebSphere Application Server node installation to run out-of-the-box, both IPv4 and IPv6 multicast
addresses are initially defined in the node agent configuration, and when a node agent starts, both
addresses will be tried in sequence. It is a good idea to delete either
NODE_MULTICAST_DISCOVERY_ADDRESS or NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS
after installation. By that time, you should know whether the node is running IPv4 or IPv6, so by limiting
multicast discovery to the known protocol, the node agent runs more efficiently.

To delete one of the multicast ports using the Administrative Console, do the following:
1. Click System Administration --> Node Agents.
2. Select the node agent.
3. On the next panel, under Additional Properties, select Ports. The next panel shows a list of existing
ports.
4. Select either NODE_MULTICAST_DISCOVERY_ADDRESS (to delete IPv4) or
NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS (to delete IPv6).
5. Click Delete.

JVM settings

Two system properties are related to IPv6 support. They are:

v java.net.preferIPv4Stack=<true|false>
v java.net.preferIPv6Addresses=<true|false>

In general, setting these properties is not recommended. In particular, setting java.net.perferIPv4Stack to

true will disable the dual mode support in the JVM which might, in turn, disrupt normal WebSphere
Application Server functions. Therefore, it is important to understand the full implications if you are
contemplating using this setting.

Cell settings
Use this page to set the discovery protocol and address end point for an existing cell. A cell is a
configuration concept, a way for an administrator to logically associate nodes according to whatever
criteria make sense in the administrator’s organizational environment.

To view this administrative console page, click System Administration > Cell.

Name:

Specifies the name of the existing cell.

Short Name:

Specifies the short name of the cell. The name is 1-8 characters, alphanumeric or national language. It
cannot start with a numeric.

The short name property is read only. It was defined during installation and customization.

Cell Discovery Protocol:

144 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Specifies the protocol that the cell follows to retrieve information from a network.

Select one of these protocol options:

UDP User Datagram Protocol (UDP)
TCP Transmission Control Protocol (TCP)

Default TCP

Deployment managers
Deployment managers are administrative agents that provide a centralized management view for all nodes
in a cell, as well as management of clusters and workload balancing of application servers across one or
several nodes in some editions.

A deployment manager hosts the administrative console. A deployment manager provides a single, central
point of administrative control for all elements of the entire WebSphere Application Server distributed cell.
Each cell contains one deployment manager.

Configuring deployment managers

When you created a deployment manager profile, a deployment manager was created. A deployment
manager provides a single, central point of administrative control for all elements in a WebSphere
Application Server distributed cell. You can run the deployment manager with its default settings. However,
you can follow this task to change the deployment manager configuration settings such as the ports the
process uses, custom services, logging and tracing settings, and so on. To view information about and
manage a deployment manager, use the settings page for a deployment manager.
1. Access the settings page for a deployment manager. Click System Administration > Deployment
Manager from the navigation tree of the administrative console.
2. Configure the deployment manager as desired by clicking on a property such as Custom Services
and specifying settings on the resulting pages.

Running the deployment manager with a non-root user ID

This article describes how to run the deployment manager with a non-root user ID on Linux and UNIX
platforms.

If global security is enabled, the user registry must not be Local OS. Using the Local OS user registry
requires the dmgr process to run as root. If you are attempting to run a deployment manager as root in
WebSphere Application Server Version 6 when you previously used a non-root user ID on Linux and UNIX
platforms in Version 5.x, see ″Migrating a previously non-root configuration to root″ in the information
center.

By default, the Network Deployment product on Linux platforms uses the root user to run the deployment
manager, which is the dmgr process. You can use a non-root user to run the deployment manager. You
might want to change to a non-root user ID for security or administrative reasons.

Perform this task to change the permissions for the deployment manager. Restart the deployment
manager for the changes to take effect.

For the steps that follow, assume that:

v wasadmin is the user to run all servers
v wasgroup is the user group
v dmgr is the deployment manager
v the installation root for Network Deployment is install_nd_root, for example
/opt/IBM/WebSphere/AppServer
v you created a run-time environment with a single profile or multiple profiles

Chapter 3. Setting up the application serving environment 145

To configure a user to run the deployment manager, complete the following steps:
1. Log on to the Network Deployment system as root.
2. Create user wasadmin with primary group wasgroup.
3. Start the deployment manager process as root with the startManager.sh script.
Issue the script command:
network deployment installation root/profiles/deployment manager profile name/bin/

./startManager.sh
4. Start the administrative console.
5. Define the dmgr process to run as a wasadmin process.
Click System Administration > Deployment manager > Server Infrastructure > Java and
Process Management > Process Definition > Additional Properties > Process Execution and
change all of these values:

Property Value
Run As User wasadmin
Run As Group wasgroup
UMASK 022

where the value 022 means the files the process creates
are writable by the group and by others as defined on the
Linux or UNIX platforms

6. Save the configuration.

7. Stop the deployment manager with the stopManager.sh script.
Issue the script command from the network deployment installation root/profiles/profile
name/bin directory:
./stopManager.sh
8. As root, use operating system tools to change file permissions on Linux and UNIX-based platforms.
The following example assumes /opt/IBM/WebSphere/AppServer is the installation root:
chgrp wasgroup /opt/IBM/WebSphere/AppServer/profiles/profile name
chgrp wasgroup /opt/IBM/WebSphere/AppServer/profiles/profile name
chgrp -R wasgroup /opt/IBM/WebSphere/AppServer/profiles/profile name/config
chgrp -R wasgroup /opt/IBM/WebSphere/AppServer/profiles/profile name/logs
chgrp -R wasgroup /opt/IBM/WebSphere/AppServer/profiles/profile name/wstemp
chgrp -R wasgroup /opt/IBM/WebSphere/AppServer/profiles/profile name/installedApps
chgrp -R wasgroup /opt/IBM/WebSphere/AppServer/profiles/profile name/temp
chgrp -R wasgroup /opt/IBM/WebSphere/AppServer/profiles/profile name/tranlog
chmod g+wr /opt/IBM/WebSphere
chmod g+wr /opt/IBM/WebSphere/AppServer/profiles/profile name
chmod -R g+wr /opt/IBM/WebSphere/AppServer/profiles/profile name/config
chmod -R g+wr /opt/IBM/WebSphere/AppServer/profiles/profile name/logs
chmod -R g+wr /opt/IBM/WebSphere/AppServer/profiles/profile name/wstemp
chmod -R g+wr /opt/IBM/WebSphere/AppServer/profiles/profile name/installedApps
chmod -R g+wr /opt/IBM/WebSphere/AppServer/profiles/profile name/temp
chmod -R g+wr /opt/IBM/WebSphere/AppServer/profiles/profile name/tranlog
9. Log in as wasadmin on the Network Deployment system.
10. Start the deployment manager process with the startManager.sh script.
Issue the script command:
network deployment installation root/profiles/deployment manager profile name/bin/

./startManager.sh

You can start a deployment manager process from a non-root user.

146 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Deployment manager settings
Use this page to stop the deployment manager from running, and to link to other pages which you can use
to define additional properties for the deployment manager. A deployment manager provides a single,
central point of administrative control for all elements of the entire WebSphere Application Server
distributed cell.

To view this administrative console page, click System Administration > Deployment Manager.

Name:

Specifies a logical name for the deployment manager. The name must be unique within the cell.

Data type String

Short name:

Specifies the short name of the deployment manager server.

The server short name must be unique within a cell. The short name identifies the server to the native
facilities of the operating system, such as Workload Manager (WLM), Automatic Restart Manager, SAF (for
example, RACF), started task control, and others.

The name is 1-8 characters, alpha numeric or national language. It cannot start with a numeric.

The system assigns a cell-unique, default short name.

Data type String

Unique Id:

Specifies the unique ID of this deployment manager server.

The unique ID property is read only. The system automatically generates the value.

Data type String

Process ID:

Specifies a string identifying the process.

Data type String

Default None

Cell Name:

Specifies the name of the cell for the deployment manager. The default is the name of the host computer
on which the deployment manager is installed with Cell## appended, where ## is a two-digit number.

Data type String

Default host_nameCell01

Node Name:

Chapter 3. Setting up the application serving environment 147

Specifies the name of the node for the deployment manager. The default is the name of the host computer
on which the deployment manager is installed with CellManager## appended, where ## is a two-digit
number.

Data type String

Default host_nameCellManager01

State:

Indicates the state of the deployment manager. The state is Started when the deployment manager is
running and Stopped when it is not running.

Data type String

Default Started

Node
A node is a logical grouping of managed servers.

A node usually corresponds to a logical or physical computer system with a distinct IP host address.
Nodes cannot span multiple computers. Node names usually are identical to the host name for the
computer.

Nodes in the network deployment topology can be managed or unmanaged. Two types of managed nodes
exist while one type of unmanaged node exists.

One type of managed node has a node agent which manages all servers on a node, whether the servers
are WebSphere Application Servers, Java Message Service (JMS) servers (on Version 5 nodes only), Web
servers, or generic servers. The node agent represents the node in the management cell. A deployment
manager manages this type of managed node. The other type of managed node has no node agent. This
type of managed node is defined on a standalone Application Server. The deployment manager cannot
manage this standalone Application Server. An standalone Application Server can be federated. When it is
federated, a node agent is automatically created. The node becomes a managed node in the cell. The
deployment manager manages this node.

An unmanaged node does not have a node agent to manage its servers. Unmanaged nodes can have
server definitions such as Web servers in the WebSphere Application Server topology. Unmanaged nodes
can never be federated. That is, a node agent can never be added to an unmanaged node.

A supported Web server can be on a managed node or an unmanaged node. You can define only one
Web server to a standalone WebSphere Application Server node. This Web server is defined on an
unmanaged node. You can define Web servers to the deployment manager. These Web servers can be
defined on managed or unmanaged nodes.

WebSphere Application Server supports basic administrative functions for all supported Web servers. For
example, generation of a plug-in configuration can be performed for all Web servers. However,
propagation of a plug-in configuration to remote Web servers is supported only for IBM HTTP Servers that
are defined on an unmanaged node. If the Web server is defined on a managed node, propagation of the
plug-in configuration is done for all the Web servers by using node synchronization. The Web server
plug-in configuration file is created according to the Web server definition and is created based on the list
of applications that are deployed on the Web server. You can also map all supported Web servers as
potential targets for the modules during application deployment.

148 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
WebSphere Application Server supports some additional administrative console tasks for IBM HTTP
Servers on managed and unmanaged nodes. For instance, you can start IBM HTTP Servers, stop them,
terminate them, display their log files, and edit their configuration files.

You can add managed and unmanaged nodes to a network deployment cell in one of the following ways:
v Administrative console
v Command line (managed nodes only)
v Administrative script
v Java program

Each of these methods for adding a managed node to a network deployment cell includes the option of
specifying a target node group for the managed node to join. If you do not specify a node group, or you do
not have the option of specifying a node group, the default node group of DefaultNodeGroup is the target
node group.

Whether you specify an explicit node group or accept the default, the node group membership rules must
be satisfied. If the node you are adding does not satisfy the node group membership rules for the target
node group, the add node operation fails with an error message.

Managing nodes
This article describes how to add a node, select the discovery protocol for a node, define a custom
property for a node, stop servers on a node, and remove a node.

A node is a grouping of managed or unmanaged servers. You can add both managed and unmanaged
nodes to the WebSphere Application Server topology. If you add a new node for an existing WebSphere
Application Server to the network deployment cell, you add a managed node. If you create a new node in
the topology for managing Web servers or servers other than WebSphere Application Servers, you add an
unmanaged node.

To view information about nodes and manage nodes, use the Nodes page. To access the Nodes page,
click System Administration > Nodes in the console navigation tree.

You can manage nodes on an application server through the wsadmin scripting tool, through the Java
application programming interfaces (APIs), or through the administrative console. Perform the following
tasks to manage nodes on an application server through the administrative console.
v Add a node.
1. Go to the Nodes page and click Add Node. Choose whether you want to add a managed or
unmanaged node, and click Next.
2. For a managed node, verify that an application server is running on the remote host for the node
that you are adding. On the Add Node page, specify a host name, connector type, and port for the
application server at the node you are adding.
3. For a managed node, do one of the following sets of actions in the table:

If the deployment manager is on And the node that you add to the Complete the appropriate set of
cell is on actions:
The distributed platform The distributed platform Optionally specify a node group and a
core group. Click OK.

Chapter 3. Setting up the application serving environment 149

The distributed platform A z/OS system Specify a node group that contains
nodes from the same sysplex as the
node you are now adding. If no such
node group exists, create a node
group and then specify that node
group. Optionally specify a core
group. Click OK.
A z/OS system The distributed platform Specify a node group that contains
distributed nodes. If no such node
group exists, create a node group
and then specify that node group.
Optionally specify a core group. Click
OK.

For the node group option to display, a group other than the default node group must first be
created. Likewise, for the core group option to display, a group other than the default core group
must first be created.
4. For managed nodes, another administrative console panel is displayed if the node to federate is on
a Windows operating system. Specify on the panel whether you want to register the node agent to
run as a Windows service. If security is enabled, you can optionally enter the local operating system
user name and password under which you will run the service. If you do not specify a user name
and password, the service runs under the local system identity. When you run remove the node, the
node agent is de-registered as a Window service.
5. For an unmanaged node, on the Nodes > New page, specify a node name, a host name, and a
platform for the new node. Click OK.
The node is added to the WebSphere Application Server environment and the name of the node is
displayed in the collection on the Nodes page.
Both Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) are now supported by
WebSphere Application Server, but restrictions do apply when using both IPv4 and IPv6 in the same
cell. When you add a node to a cell, the format in which you specify the name is based on the version
of IP that the node is using. For details, see IP version considerations for cells.
v Select the discovery protocol.
If the discovery protocol that a node uses is not appropriate for the node, select the appropriate
protocol. On the Nodes page, click the node to access the Settings for the node. Select a value for
Discovery Protocol. By default, a node uses Transmission Control Protocol (TCP). You probably not
need to change a node protocol configuration from TCP. However, if you do need to change the
discovery protocol value, some guidelines are provided:
– For a managed process, use multicast. A managed process supports multicast because by using
multicasting, all application servers in one node can listen to one port instead of to one port for each
server. A benefit of using multicast is that you do not have to configure the discovery port for each
application server or prevent port conflicts. A drawback of using multicast is that you must ensure
that your machine is connected to the network when application servers (not including the node
agent) launch because a multicast address is shared by the network and not by the local machine. If
your machine is not connected to the network when application servers launch, the multicast address
is not shared with the application servers.
– For a node agent or a deployment manager, use TCP or UDP. Do not use multicast.
v Define a custom property for a node.
1. On the Nodes page, click the node for which you want to define a custom property.
2. On the Settings for the node, click Custom Properties.
3. On the Property collection page, click New.
4. On the Settings page for a property instance, specify a name-value pair and a description for the
property, and click OK.
v Synchronize the node configuration.

150 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 If you added a managed node or changed a managed node’s configuration, synchronize the node’s
configuration. On the Node Agents page, ensure that the node agent for the node is running. Then, on
the Nodes page, put a check mark in the check box beside the node whose configuration files you want
to synchronize and click Synchronize or Full Resynchronize.
Clicking either button sends a request to the node agent for that node to perform a configuration
synchronization immediately, instead of waiting for the periodic synchronization to occur. This is
important if automatic configuration synchronization is disabled, or if the synchronization interval is set
to a long time, and a configuration change has been made to the cell repository that needs to be
replicated to that node. Settings for automatic synchronization are on the File Synchronization Service
page.
Synchronize requests that a node synchronization operation be performed using the normal
synchronization optimization algorithm. This operation is fast but might not fix problems from manual file
edits that occur on the node. So it is still possible for the node and cell configuration to be out of
synchronization after this operation is performed.
Full Resynchronize clears all synchronization optimization settings and performs configuration
synchronization anew, so there will be no mismatch between node and cell configuration after this
operation is performed. This operation can take longer than the Synchronize operation.
Unmanaged nodes cannot be synchronized.
v Stop servers on a node.
On the Nodes page, put a check mark in the check box beside the managed node whose servers you
want to stop running and click Stop.
v Remove a node.
On the Nodes page, put a check mark in the check box beside the node you want to delete and click
Remove Node. If you cannot remove the node by clicking Remove Node, remove the node from the
configuration by clicking Force Delete.
v View node capabilities.
Review the node capabilities, such as the product version through the administrative console. You can
also query them through the Application Server application programming interface (API) or the wsadmin
tool .

Node collection
Use this page to manage nodes in the WebSphere Application Server environment. Nodes group managed
servers.

To view this administrative console page, click System Administration > Nodes.

Name:

Specifies a name for a node that is unique within the cell.

A node corresponds to a physical computer system with a distinct IP host address. The node name is
usually the same as the host name for the computer.

Both Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) are now supported by
WebSphere Application Server, but there are restrictions that apply to using both IPv4 and IPv6 in the
same cell. Note that when you add a node to a cell, the format in which you specify the name is based on
the version of IP the node will be using.

Version:

Specifies the product version of the node.

The product version is the version of a WebSphere Application Server for managed nodes. For
unmanaged nodes, on which you can define Web servers, the version displays as unknown.

Chapter 3. Setting up the application serving environment 151

Discovery protocol:

Specifies the protocol that servers use to discover the presence of other servers on this node.

The possible protocol options follow:

UDP User Datagram Protocol (UDP)
TCP Transmission Control Protocol (TCP)
multicast
IP multicast protocol

Status:

Indicates the state of the node.

The state can beStarted, Stopped, Unavailable, Unknown, Partial Start, Partial Stop, Not applicable,
Synchronized, or Not synchronized.

Node settings:

Use this page to view or change the configuration or topology settings for either a managed node instance
or an unmanaged node instance.

A managed node is a node with an Application Server and a node agent that belongs to a cell. An
unmanaged node is a node defined in the cell topology that does not have a node agent running to
manage the process. Unmanaged nodes are typically used to manage Web servers.

To view this administrative console page, click System Administration > Nodes >node_name.

Name:

Specifies a logical name for the node. The name must be unique within the cell.

A node name usually is identical to the host name for the computer. However, you choose the node name.
You can make the node name some name other than the host name.

Data type String

Both Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) are now supported by
WebSphere Application Server, but there are restrictions that apply to using both IPv4 and IPv6 in the
same cell. Note that when you add a node to a cell, the format in which you specify the name is based on
the version of IP the node will be using.

Short Name:

Specifies the name of a node. The name is 1-8 characters, alphanumeric or national language. It cannot
start with a numeric.

The short name property is read only. It is defined during installation and customization.

Discovery Protocol:

Specifies the protocol that the node follows to retrieve information from a network. The Discovery protocol
setting is only valid for managed nodes.

Select from one of these protocol options:

UDP User Datagram Protocol (UDP)

152 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
TCP Transmission Control Protocol (TCP)
multicast
IP multicast protocol

Data type String

Default TCP
Range Valid values are UDP, TCP, or multicast.

UDP is faster than TCP, but TCP is more reliable than UDP because UDP does not guarantee delivery of
datagrams to the destination. Between these two protocols, the default of TCP is recommended.

Add managed Windows node:

Use this page to run the node agent as a Windows service.

To view this administrative console page, click System Administration > Nodes > Add node > managed
node > Add managed node .

Run the node agent as a Windows service:

Specifies whether to run a node agent as a Windows service.

Default false (cleared)

User name:

Specifies the ID for running the service process for the node agent. The user name and password fields
are only available if security is enabled. If you do not specify the user name, the node agent runs under
the authority of the local system. User name requirements are the requirements that the Windows
operating system imposes for a user ID.

Password:

Specifies the password for the user name that you supply. Password requirements are the requirements
that the Windows operating system imposes for a password.

Confirm password:

Specifies the same password that you typed for Password so that you can verify the correct password.

Add managed nodes

A managed node is a node with an Application Server and a node agent that belongs to a cell. Use this
page to add a managed node to a cell.

To view this administrative console page, click System Administration > Nodes > Add node > Next .

Node connection: Specifies connection information for WebSphere Application Server.

v Host
Specifies the host name or IP address of the node to add to the cell. A WebSphere Application Server
instance must be running on this machine.

Date type String

Default None

v JMX connector type

Chapter 3. Setting up the application serving environment 153

 Specifies the Java Management Extensions (JMX) connectors that communicate with the WebSphere
Application Server when you invoke a scripting process.
Select from one of these JMX connector types:

Simple Object Access Protocol (SOAP)

Use when the Application Server connects to a SOAP server.

Remote Method Invocation (RMI)

Use when the Application Server connects to an RMI server.

v JMX connector port

Specifies the port number of the JMX connector on the instance to add to the cell. The default SOAP
connector port is 8880.

Date type Integer

Default 8880

Options: Select from the following settings to further specify characteristics when adding a managed
node to a cell.
v Include Applications
Copies the applications installed on the remote instance into a cell. If the applications to copy have the
same name as the applications that currently exist in the cell, the Application Server does not copy the
applications.
v Include buses
Specifies whether to move the bus configuration at the node to the deployment manager.
v Starting port
Specifies the port numbers for the node agent process.

Use default Specifies whether to use the default node agent port
numbers.
Specify Allows you to specify the starting port number in the Port
number field. WebSphere Application Server
administration assigns the port numbers in order from the
starting port number. For example, if you specify 9950, the
administration program configures the node agent ports as
9950, 9951, 9952, and so on.

v Core Group
Specifies the group to which you can add a cluster or node agent. By default, clusters or node agents
are added to the DefaultCoreGroup group.
Select from one of the core groups if a list is displayed. The list displays if a core group in addition to
the default core group exists.
v Node group
Specifies the group to which you can add the node. By default, nodes are added to the
DefaultNodeGroup group.
Select from one of the node groups if a list is displayed. The list displays if a node group in addition to
the default node group exists.

Node installation properties

Use this page to view read-only installation properties for this node. These properties provide information
about the capabilities of the node that are collected during product installation time, such as the operating
system name, architecture and version, or WebSphere Application Server product levels that are installed
on the node.

154 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
To view this administrative console page, click System Administration > Nodes > node name > Node
installation properties.

Information about a node, such as operating system platform and product features, is maintained in the
configuration repository in the form of properties. As product features are installed on a node, new property
settings are added.

WebSphere Application Server system management uses the managed object metadata properties as
follows:
v To display the node version in the administrative console
v To ensure that new configuration types or attributes are not created or set on older release nodes
v To ensure that new resource types are not created on old release notes
v To ensure that new applications are not installed on old release nodes because the old run time cannot
support the new applications

For detailed information about the following properties, see the Application Server application programming
interface (API).

com.ibm.websphere.baseProductVersion:

The version of WebSphere Application Server that is installed.

com.ibm.websphere.nodeOperatingSystem:

The operating system platform on which the node runs.

com.ibm.websphere.nodeSysplexName:

The sysplex name on a z/OS operating system.

com.ibm.websphere.deployed.features:

A list of features that extends a profile. An example of a feature is an administrative console plug-in.

Node group
A node group is a collection of managed nodes. Managed nodes are WebSphere Application Server
nodes. A node group defines a boundary for server cluster formation.

Nodes that you organize into a node group should be enough alike in terms of installed software, available
resources, and configuration to enable servers on those nodes to host the same applications as part of a
server cluster. The deployment manager does no validation to guarantee that nodes in a given node group
have anything in common.

Node groups are optional and are established at the discretion of the WebSphere Application Server
administrator. However, a node must be a member of a node group. Initially, all Application Server nodes
are members of the default node group named DefaultNodeGroup.

A node can be a member of more than one node group.

On the z/OS platform, an Application Server node must be a member of a sysplex node group. Nodes in
the same sysplex must be in the same sysplex node group. A node can be in one sysplex node group
only.

A node on a distributed platform and a node on a z/OS platform cannot be members of the same node
group.

Chapter 3. Setting up the application serving environment 155

To delete a node group, the node group must be empty. The default node group cannot be deleted.

Node group membership rules

Nodes can be members of node groups if they meet certain requirements.

Node group membership must adhere to the following rules:

v A node in a node group must be a managed node.
v A managed node must be a member of at least one node group. If the node is on the z/OS platform,
the node group must be a sysplex node group.
v Nodes on a distributed platform and nodes on the z/OS platform must be members of different node
groups.
v Nodes on the z/OS platform that are in different sysplexes must be members of different groups.

Examples: Using node groups

Use node groups to define groups of nodes capable of hosting members of the same cluster. An
application deployed to a cluster must be capable of running on any of the cluster members. This means
that the node that hosts each of the cluster members must be configured with software and settings
necessary to support running of the application.

By organizing nodes that satisfy your application requirements into a node group, you establish an
administrative policy that governs which nodes can be used together to form a cluster. The people who
define the cell configuration and the people who create server clusters can operate with greater
independence from one another, if they are different people.

Example 1

Assume the following information:

v A cell is comprised of nodes 1 to 8.
v Each node is a managed node, which means that each node is configured with an Application Server.
v Nodes 6, 7, and 8 are additionally configured as WebSphere Business Integration Server Foundation
nodes.
v All nodes are either z/OS system nodes from the same sysplex, or distributed platform nodes.
v By default, all the nodes are in the default node group, DefaultNodeGroup.

Applications that exploit WebSphere Business Integration Server Foundation functions can run
successfully only on nodes 6, 7, and 8. Therefore, clusters that host these applications can be formed only
on nodes 6, 7, and 8. To define a clustering policy that guides users of your WebSphere cell into building
clusters that can only span predetermined nodes, create an additional node group called WBINodeGroup,
for example. Add to the node group nodes 6, 7, and 8. If you create a cluster on a node from the
WBINodeGroup node group, the system allows only nodes from the WBINodeGroup node group to be
members of the cluster.

Example 2

Assume the following information:

v A cell is comprised of nodes 1 to 6.
v Each node is a managed node, which means that each node is configured with an Application Server.
v Nodes 1 to 4 are on distributed platforms.
v Nodes 5 and 6 are nodes on the z/OS operating system and are in sysplex PLEX1.
v The deployment manager is on a distributed platform node.
v Nodes 1 to 4 are members of the DefaultNodeGroup node group by default.

156 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
v You created empty node group PLEX1NodeGroup to group the z/OS operating system nodes on the
PLEX1 sysplex.
v You joined the nodes on the z/OS operating system to the PLEX1NodeGroup node group when you
added them to the cell. You did this because nodes on the z/OS operating system cannot be in the
same node group as the distributed platform nodes.

Applications that exploit z/OS functions in the PLEX1 sysplex can run successfully only on nodes 5 and 6.
Therefore, clusters that host these applications can be formed only on nodes 5 and 6. The required
separation of distributed platform nodes from z/OS system nodes establishes a natural clustering policy
that guides users of your Application Server cell into building clusters that can only span predetermined
nodes. If you create a cluster on a node from the PLEX1NodeGroup node group, the system allows only
nodes from the PLEX1NodeGroup node group to be members of the cluster.

Managing node groups

Read about Nodes groups if you are unfamiliar with them.

Your WebSphere Application Server environment has a default node group. However, if you need
additional node groups to manage your Application Server environment, you can create and configure
additional node groups.
v View and configure node groups.
1. Click System Administration > Node groups in the console navigation tree.
2. To view additional information about a particular node group or to further configure a node group,
click on the node group name under Name.
v Create a node group.
1. Click System Administration > Node groups in the console navigation tree.
2. Click New.
3. Specify the node group name and description.
The node group is added to the WebSphere Application Server environment . The name of the node
group appears in the name column of the Node group page.

You can now add nodes to the node group.

Node group collection

Use this page to manage node groups. A node group is a collection of WebSphere Application Server
nodes. A node group defines a boundary for server cluster formation.

Nodes that are organized into a node group should be enough alike in terms of installed software,
available resources, and configuration to enable servers on those nodes to host the same applications as
part of a server cluster. The deployment manager does no validation to guarantee that nodes in a given
node group have anything in common.

Node groups are optional and are established at the discretion of the WebSphere administrator. However,
a node must be a member of a node group. Initially, all Application Server nodes are members of the
default node group. The default node group is DefaultNodeGroup.

A node can be a member of more than one node group.

On the z/OS platform, an Application Server node must be a member of a sysplex node group. Nodes in
the same sysplex must be in the same sysplex node group. A node can only be in one sysplex node
group. Sysplex node groups are special node groups that the system manages.

Chapter 3. Setting up the application serving environment 157

A node on a distributed platform and a node on a z/OS platform cannot be members of the same node
group.

To delete a node group, the node group must be empty. The default node group cannot be deleted.

To view this administrative console page, click System Administration > Node groups.

Name:

Specifies a name for a node group that is unique within the cell.

Members:

Specifies the number of members or nodes in the node group.

Description:

Specifies a description that you define for the node group.

Node group settings:

Use this page to view or change the configuration or topology settings for a node group instance.

To view this administrative console page, click System Administration > Node groups >node group
name.

Name:

Specifies a logical name for the node group. The name must be unique within the cell.

Data type String

Maximum length 64 characters

The name must contain alphanumeric or national language characters and cannot start with a number.

Short name:

Specifies the name of a node. The name must contain 1-8 characters, which are either alphanumeric or
national language. It cannot start with a number.

On the z/OS system the short name property is:

v Read-only
v Used only by sysplex node groups
v Defined during installation and customization

Sysplex:

Specifies the name of a node. The name is eight characters, alphanumeric or national language. It cannot
start with a numeric. It is used only by sysplex node groups on the z/OS platform. It is defined during
installation and customization on z/OS platforms only.

The Sysplex property is read only.

Members:

158 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Specifies the number of nodes within the node group.

Data type Integer

Description:

Specifies the description that you define for the node group. The description has no specific maximum
length.

Managing node group members

Read about Nodes groups and Node group membership rules if you are unfamiliar with them.

Group nodes that meet your application requirements into a node group.
v View node groups members.
1. Click System Administration > Node groups > node group name > Nodes > Node group
members in the console navigation tree.
2. To view additional information about a particular node group member for this node group, click on
the node group member name under Name.
v Add a node to a node group.
1. Click System Administration > Node groups > node group name > Nodes > Node group
members in the console navigation tree.
2. Click Add.
3. Select the node from a list. The node group member name is the node name.
The node group member is added to the node group specified on the bread crumb trail. The name of
the node group member appears in the name column of the Node group member page. You can add
additional nodes of similar characteristics to the node group by repeating the steps for adding a node to
a node group.
If the node you add does not satisfy the node group membership rules for the target node group, the
add node operation fails with an error message.
v Remove a node from a node group.
1. Click System Administration > Node groups > node group name > Nodes > Node group
members in the console navigation tree.
2. Select the box next to each node group member that you want to remove from the node group.
3. Click Remove.
Each node group member that you selected is removed from the node group specified on the bread
crumb trail.

Node group member collection

Use this page to manage node groups members. A node group member is a WebSphere Application
Server node.

Click Add to add node members to the node group. Click Remove to remove node members from the
node group.

To view this administrative console page, click System Administration > Node groups > node group
name > nodes > Node group members.

Name:

Specifies the name of a node group member.

Chapter 3. Setting up the application serving environment 159

Description:

Specifies a description that you previously defined for the node group member when you created the node
group member.

Node group member settings:

Use this page to view or change the configuration or topology settings for a node group member.

To view this administrative console page, click System Administration > Node groups > node group
name > nodes > Node group members > node group member name.

Name:

Specifies a logical name for the node group member. A node group member is a node. The name must be
unique within the cell.

A node group member name usually is identical to the host name for the computer.

Data type String

Maximum length 64 characters

The name must contain alphanumeric or national language characters and cannot start with a number.

Administration service settings

Use this page to view and change the configuration for an administration service.

To view this administrative console page, click Servers > Application Servers >server_name >
Administration > Administration Services

Standalone
Specifies whether the server process is a participant in a Network Deployment cell or not. If the box is
checked (true), the server does not participate in distributed administration. If the box is unchecked (false),
the server participates in the Network Deployment system.

The default value for base WebSphere Application Server installations is true. When addNode runs to
incorporate the server into a Network Deployment cell, the value switches to false.

Data type Boolean

Default true

Preferred Connector
Specifies the preferred JMX Connector type. Available options, such as SOAPConnector or RMIConnector,
are defined using the JMX Connectors page.

Data type String

Default SOAP

Extension MBean Providers collection

Use this page to view and change the configuration for JMX extension MBean providers.

You can configure JMX extension MBean providers to be used to extend the existing WebSphere
managed resources in the core administrative system. Each MBean provider is a library containing an
implementation of a JMX MBean and its MBean XML Descriptor file.

160 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
To view this administrative console page, click Servers > Application Servers >server_name >
Administration > Administration Services > Extension MBean Providers
Name The name used to identify the Extension MBean provider library.
Description
An arbitrary descriptive text for the Extension MBean Provider configuration.
Classpath
The path to the Java archive (JAR) file that contains the Extension MBean provider library. This
class path is automatically added to the Application Server class path.

Extension MBean Provider settings:

Use this page to view and change the configuration for a JMX extension MBean provider.

You can configure a library containing an implementation of a JMX MBean, and its MBean XML Descriptor
file, to be used to extend the existing WebSphere managed resources in the core administrative system

To view this administrative console page, click Servers > Application Servers >server_name >
Administration > Administration Services > Extension MBean Providers >provider_library_name

Classpath: The path to the Java archive (JAR) file that contains the Extension MBean provider library.
This class path is automatically added to the Application Server class path. The class loader needs this
information to load and parse the Extension MBean XML Descriptor file.

Description: An arbitrary descriptive text for the Extension MBean Provider configuration. Use this field for
any text that helps identify or differentiate the provider configuration.

Name: The name used to identify the Extension MBean provider library.

Extension MBean collection

You can configure Java Management Extension (JMX) MBeans to extend the existing WebSphere
Application Server managed resources in the administrative console. Use this page to register JMX
MBeans. Any MBeans that are listed have already been registered.

To view this administrative console page, click Servers > Application Servers >server name >
Administration > Administration Services > Extension MBean Providers > provider library name>
Extension MBean
DescriptorURI
Specifies the location, relative to the provider class path, where the MBean XML descriptor file is
located.
Type Specifies the type to use for registering this MBean. The type must match the type that is declared
in the MBean descriptor file.

Extension MBean settings:

Use this page to view and configure Java Management Extension (JMX) MBeans.

To view this administrative console page, click Servers > Application Servers >server name>
Administration > Administration Services > Extension MBean Providers > provider library name>
Extension MBean >Extension MBean name

descriptorURI: Specifies the location, relative to the provider class path, where the MBean XML
descriptor file is located.

type: Specifies the type to use for registering this MBean. The type must match the type that is declared
in the MBean descriptor file.

Chapter 3. Setting up the application serving environment 161

Java Management Extensions connector properties
A Java Management Extensions (JMX) connector can either be a Remote Method Invocation (RMI)
connector or a Simple Object Access Protocol (SOAP) connector.

Depending on the property, you can specify or set a property in the administrative console, the wsadmin
tool, Application Server commands, scripts run from a command line interface, or a custom Java
administrative client program that you write. You can also set SOAP connector properties in the
soap.client.props file.

For specific information on how to code the JMX connector properties for the wsadmin tool, the Application
Server commands, or scripts, see the particular tool or command. For specific information on how to code
the JMX connector properties for a custom Java administrative client program, see the ″Java API
documentation for Application Server″ topic in the Information Center.

For the administrative console, this article specifies the coding of the particular setting or property. Coding
of properties in the soap.client.props file that are specific to JMX connectors is specified. These
properties begin with com.ibm.SOAP. Other properties in the soap.client.props file that contain
information that can be set elsewhere in the Application Server are not documented here. The coding for
the com.ibm.ssl.contextProvider property, which can be set only in the soap.client.props file, is specified.

Each profile has a property file at installation root/profiles/profile

name/properties/soap.client.props. These property files allow you to set different properties, including
security and timeout properties. These properties are the default for all administrative connections that use
the SOAP JMX connector between processes executing in a particular profile. For instance, the wsadmin
program executing under a particular profile uses the property values from that file for the SOAP connector
behavior unless the properties are overridden by some other programmatic means.

To view the JMX connector custom properties administrative console panel that goes with this article, click
one of the following paths:
v Servers -> Application servers ->server name -> Server Infrastructure -> Administration ->
Administration Services -> Additional properties -> JMX Connectors->connector type -> Additional
Properties -> Custom properties
v System administration -> Deployment manager ->Additional Properties -> Administration
Services -> Additional Properties -> JMX Connectors->connector type-> Additional Properties ->
Custom properties
v System administration -> Node agents ->node agent name -> Additional Properties ->
Administration Services -> Additional Properties -> JMX Connectors->connector type-> Additional
Properties -> Custom properties

SOAP connector properties

This section discusses JMX connector properties that pertain to SOAP connectors.

SOAP Request timeout

Specifies the SOAP client request timeout. The value that you choose depends on a number of factors
such as the size and the number of the applications that are installed on the server, the speed of your
machine, and the level of usage of your machine.

The program default value for the request timeout is 600 seconds. However, other components that
connect to the SOAP client can override the default. Components that use the soap.client.props file have
a default value of 180 seconds.

You can set the property by using one of the following options:
v Scripts run from a command line interface.

162 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
v The soap.client.props file.

Property com.ibm.SOAP.requestTimeout
Data type Integer
Range in seconds 0 to n

If the property is zero (0), the request never times out.

Default 180

v The administrative console. Specify the property and the value as a name-value pair on the JMX
connector custom properties panel of the administrative console.

Property requestTimeout
Data type Integer
Range in seconds 0 to n

If the property is zero (0), the request never times out.

Default 600

v A Java administrative client. The property is AdminClient.CONNECTOR_SOAP_REQUEST_TIMEOUT.

Configuration URL

Specifies the Universal Resource Locator (URL) of the soap.client.props file. Specify the configuration
URL property if you want a program to read SOAP properties from this file. You can set the property by
using one of the following options:
v Scripts run from a command line interface. Scripts can pass the Configuration URL property to the
Application Server on the com.ibm.SOAP.ConfigURL system property.
v The administrative console. Specify the property and the value as a name-value pair on the JMX
connector custom properties panel of the administrative console.

Property ConfigURL
Data type String
Valid Value http://Path/soap.client.props
Default None

v A Java administrative client. The property is AdminClient.CONNECTOR_SOAP_CONFIG.

Security context provider

Specifies the Secure Sockets Layer (SSL) implementation to use between the Application Server and the
SOAP client. You can specify either IBM Java Secure Sockets Extension (IBMJSSE) or IBM Java Secure
Sockets Extension that has undergone Federal Information Processing Standards certification
(IBMJSSEFIPS).

You can set the property by using the soap.client.props file.

Property com.ibm.ssl.contextProvider
Data type String
Valid Values IBMJSSE
IBMJSSEFIPS
IBMJSSE2
Default IBMJSSE2

Secure Sockets Layer (SSL) security

Chapter 3. Setting up the application serving environment 163

Use this property to enable SSL security between Application Server and the SOAP client. You can set the
property by using one of the following options:
v Scripts run from a command line interface.
v The soap.client.props file.

Property com.ibm.SOAP.securityEnabled
Data type Boolean
Default False

v The administrative console. Specify the property and the value as a name-value pair on the JMX
connector custom properties panel of the administrative console.

Property securityEnabled
Data type Boolean
Default False

v A Java administrative client. The property is AdminClient.CONNECTOR_SECURITY_ENABLED.

SOAP and RMI connector properties

This section discusses JMX connector properties that pertain to both SOAP connectors and RMI
connectors.

Connector type

Specify a connector type of SOAP or RMI, depending on whether Application Server connects to a SOAP
server or an RMI server. You can set the property by using one of the following options:
v The wsadmin tool.
v Scripts run from a command line interface.
v The administrative console. Specify the property and the value as a name-value pair on the JMX
connector custom properties panel of the administrative console.

Property Type
Data type String
Valid values SOAPConnector
RMIConnector
Default SOAP

v A Java administrative client. The property is AdminClient.CONNECTOR_TYPE. Specify by using the

AdminClient.CONNECTOR_TYPE_RMI or the AdminClient.CONNECTOR_TYPE_SOAP constants.

Host

Use the host property to specify the host name or the IP address of the server to which Application Server
connects. The server can be a SOAP server or an RMI server. You can set the property by using one of
the following options:
v The wsadmin tool.
v Scripts run from a command line interface.
v The administrative console. Specify the property and the value as a name-value pair on the JMX
connector custom properties panel of the administrative console.

Property host
Data type String
Valid values Host name or IP address
Default None

164 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
v A Java administrative client. The property is AdminClient.CONNECTOR_HOST.

Port

Use the port property to specify the port number of the server to which Application Server connects. The
server can be a SOAP server or an RMI server. You can set the property by using one of the following
options:
v The wsadmin tool.
v Scripts run from a command line interface.
v The administrative console. Specify the property and the value as a name-value pair on the JMX
connector custom properties panel of the administrative console.

Property port
Data type Integer
Valid value Port number
Default None

v A Java administrative client. The property is AdminClient.CONNECTOR_PORT.

User name

Specifies the user name that Application Server uses to access the SOAP server or the RMI server. You
can set the property by using one of the following options:
v The wsadmin tool.
v Scripts run from a command line interface.
v The soap.client.props file.

Property com.ibm.SOAP.loginUserid
Data type String
Valid value The value must match the global SSL settings for SOAP
or RMI.
Default None

v The administrative console. Specify the property and the value as a name-value pair on the JMX
connector custom properties panel of the administrative console.

Property username
Data type String
Valid value The value must match the global SSL settings for SOAP
or RMI.
Default None

v A Java administrative client. The property is AdminClient.USERNAME.

Password

Specifies the password that Application Server uses to access the SOAP server or the RMI server. You
can set the property by using one of the following options:
v The wsadmin tool.
v Scripts run from a command line interface.
v The soap.client.props file.

Property com.ibm.SOAP.loginPassword

Chapter 3. Setting up the application serving environment 165

Data type String
Valid values The value must match the global SSL settings for SOAP
or RMI.
Default None

v The administrative console. Specify the property and the value as a name-value pair on the JMX
connector custom properties panel of the administrative console.

Property password
Data type String
Valid values The value must match the global SSL settings for SOAP
or RMI.
Default None

v A Java administrative client. The property is AdminClient.PASSWORD.

Java Management Extensions connectors

Use this page to view and change the configuration for Java Management Extensions (JMX) connectors.

To view this administrative console page, click one of the following paths:
v Servers > Application Servers >server_name > Administration > Administration Services > JMX
Connectors
v Servers > JMS Servers >server_name > Administration > Administration Services > JMX
Connectors

Java Management Extensions (JMX) connectors communicate with WebSphere Application Server when
you invoke a scripting process. There is no default for the type and parameters of a connector. The
wsadmin.properties file specifies the Simple Object Access Protocol (SOAP) connector and an appropriate
port number. You can also use the Remote Method Invocation (RMI) connector.

Use one of the following methods to select the connector type and attributes:
v Specify properties in a properties file.
v Indicate options on the command line.

Type:

Specifies the type of the JMX connector.

Data type Enum

Default SOAPConnector
Range SOAPConnector
For JMX connections using Simple Object Access
Protocol (SOAP).
RMIConnector
For JMX connections using Remote Method
Invocation (RMI).

JMX connector settings:

Use this page to view the configuration for a Java Management Extensions (JMX) connector.

To view this administrative console page, click one of the following paths:
v Servers > Application Servers >server_name > Administration > Administration Services > JMX
Connectors >connector_type
v Servers > JMS Servers >server_name > Administration > Administration Services > JMX
Connectors >connector_type

166 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Type:

Specifies the type of the JMX connector.

Data type Enum

Default SOAPConnector
Range SOAPConnector
For JMX connections using Simple Object Access
Protocol (SOAP).
RMIConnector
For JMX connections using Remote Method
Invocation (RMI).

Repository service settings

Use this page to view and change the configuration for an administrative service repository.

To view this administrative console page, click Servers > Application Servers >server_name >
Administration Services > Repository Service.

Audit Enabled:

Specifies whether to audit repository updates in the log file. The default is to audit repository updates.

Data type Boolean

Default true

Node agents
Node agents are administrative agents that route administrative requests to servers.

A node agent is a server that runs on every host computer system that participates in the WebSphere
Application Server Network Deployment product. It is purely an administrative agent and is not involved in
application serving functions. A node agent also hosts other important administrative functions such as file
transfer services, configuration synchronization, and performance monitoring.

Managing node agents

Node agents are administrative agents that represent a node to your system and manage the servers on
that node. Node agents monitor application servers on a host system and route administrative requests to
servers. A node agent is created automatically when a node is added to a cell.
1. View information about a node agent. Use the Node Agents page. Click System Administration >
Node Agents in the console navigation tree. To view additional information about a particular node
agent or to further configure a node agent, click on the node agent’s name under Name.

Note: Both Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) are now
supported by WebSphere Application Server, but there are restrictions that apply to using both
IPv4 and IPv6 in the same cell. Note that when a node is added to a cell, the format in which
the name is specified is based on the version of IP the node will be using. For details, see “IP
version considerations for cells” on page 140.
2. Stop and then restart the processing of a node agent. On the Node Agents page, place a check mark
in the check box beside the node agent you want to restart, then click Restart. It is important to keep
a node agent running because a node agent must be running in order for application servers on the
node managed by the node agent to run.

Chapter 3. Setting up the application serving environment 167

3. Stop and then restart all application servers on the node managed by the node agent. On the Node
Agents page, place a check mark in the check box beside the node agent that manages the node
whose servers you want to restart, then click Restart all Servers on Node.
Note that the node agent for the node must be processing (step 2) in order to restart application
servers on the node.
4. Stop the processing of a node agent. On the Node Agents page, place a check mark in the check box
beside the node agent you want to stop processing, then click Stop.

Node agent collection

Use this page to view information about node agents. Node agents are administrative agents that monitor
application servers on a host system and route administrative requests to servers. A node agent is the
running server that represents a node in a Network Deployment environment.

To view this administrative console page, click System Administration > Node Agents .

Name:

Specifies a logical name for the node agent server.

Node:

Specifies a name for the node. The node name is unique within the cell.

A node name usually is identical to the host name for the computer. That is, a node usually corresponds to
a physical computer system with a distinct IP host address.

However, the node name is a purely logical name for a group of servers. You can name the node anything
you please. The node name does not have to be the host name.

Both Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) are now supported by
WebSphere Application Server, but there are restrictions that apply to using both IPv4 and IPv6 in the
same cell. Note that when a node is added to a cell, the format in which the name is specified is based on
the version of IP the node will be using.

Version:

Specifies the product version of the node.

The product version is the version of a WebSphere Application Server node agent and Application Servers
that run on the node.

Status:

Indicates whether the node agent server is started or stopped.

Note that if the status of servers such application servers is Unavailable, the node agent is not running in
the servers’ node and you must restart the node agent before you can start the servers.

Node agent server settings:

Use this page to view information about and configure a node agent. A node agent coordinates
administrative requests and event notifications among servers on a machine. A node agent is the running
server that represents a node in a Network Deployment environment.

To view this administrative console page, click System Administraton > Node Agents
>node_agent_name.

168 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
A node agent must be started on each node in order for the deployment manager node to be able to
collect and control servers configured on that node. If you use configuration synchronization support, a
node agent coordinates with the deployment manager server to synchronize the node’s configuration data
with the master copy managed by the deployment manager.

You must initially start a node agent outside the administrative console. For information on how to initially
start a node agent, see the WebSphere Application Server Information Center.

The Runtime tab displays only when a node agent runs.

Name:

Specifies a logical name for the node agent server.

Data type String

Default NodeAgent Server

Short name:

Specifies the short name of the node agent server.

The name is 1-8 characters, alpha-numeric or national language. It cannot start with a numeric.

The system assigns a cell-unique, default short name.

Unique Id:

Specifies the unique ID of this node agent server.

The unique ID property is read only. The system automatically generates the value.

Process ID:

Specifies a string identifying the process.

Data type String

Cell Name:

Specifies the name of the cell for the node agent server.

Data type String

Default host_nameNetwork

Node Name:

Specifies the name of the node for the node agent server.

Both Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) are now supported by
WebSphere Application Server, but there are restrictions that apply to using both IPv4 and IPv6 in the
same cell. Note that when a node is added to a cell, the format in which the name is specified is based on
the version of IP the node will be using.

Data type String

Chapter 3. Setting up the application serving environment 169

State:

Indicates whether the node agent server is started or stopped.

Data type String

Default Started

Remote file services

Configuration documents describe the available application servers, their configurations, and their
contents. Two file services manage configuration documents: the file transfer service and the file
synchronization service.

The file services do the following:

File transfer service
The file transfer service enables the moving of files between the network manager and the nodes.
It uses the HTTP protocol to transfer files. When you enable security in the WebSphere
Application Server product, the file transfer service uses certificate-based mutual authentication.
You can use the default key files in a test environment. Ensure that you change the default key file
to secure your system.
The ports used for file transfer are defined in the Network Deployment server configuration under
its WebContainer HTTP transports.
File synchronization service
The file synchronization service ensures that a file set on each node matches that on the
deployment manager node. This service promotes consistent configuration data across a cell. You
can adjust several configuration settings to control file synchronization on individual nodes and
throughout a system.
This service runs in the deployment manager and node agents, and ensures that configuration
changes made to the cell repository are propagated to the appropriate node repositories. The cell
repository is the master repository, and configuration changes made to node repositories are not
propagated up to the cell. During a synchronization operation a node agent checks with the
deployment manager to see if any configuration documents that apply to the node have been
updated. New or updated documents are copied to the node repository, and deleted documents
are removed from the node repository.
The default behavior, which is enabled, is for each node agent to periodically run a
synchronization operation. You can configure the interval between operations or disable the
periodic behavior. You can also configure the synchronization service to synchronize a node
repository before starting a server on the node.

Configuring remote file services

Configuration data for the WebSphere Application Server product resides in files. Two services help you
reconfigure and otherwise manage these files: the file transfer service and file synchronization service.

By default, the file transfer service is always configured and enabled at a node agent, so you do not need
to take additional steps to configure this service. However, you might need to configure the file
synchronization service.
1. Go to the File Synchronization Service page. Click System Administration > Node Agents in the
console navigation tree. Then, click the node agent for which you want to configure a synchronization
server and click File Synchronization Service.
2. On the File Synchronization Service page, customize the service that helps make configuration data
consistent across a cell by moving updated configuration files from the deployment manager to the
node. Change the values for properties on the File Synchronization Service page. The file
synchronization service is always started, but you can control how it runs by changing the values.
170 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
File transfer service settings
Use this page to configure the service that transfers files from the deployment manager to individual
remote nodes.

To view this administrative console page, click System Administration > Node Agents
>node_agent_name > File Transfer Service.

Enable service at server startup:

Specifies whether the server attempts to start the specified service. Some services are always enabled
and disregard this property if set. This setting is enabled by default.

Data type Boolean

Default true

Retries count:

Specifies the number of times you want the file transfer service to retry sending or receiving a file after a
communication failure occurs.

Data type Integer

Default 3

If the retries count setting is blank, the file transfer service

sets the default to 3. If the retries count setting is 0, the
file transfer service does not retry. The default is the
recommended value.

Retry wait time:

Specifies the number of seconds that the file transfer service waits before it retries a failed file transfer.

Data type Integer

Default 10

If the retry wait time setting is blank, the code sets the
default to 10. If the retry wait time setting is 0, the file
transfer service does not wait between retries. The default
is the recommended value.

File synchronization service settings

Use this page to specify that a file set on one node matches that on the central deployment manager node
and to ensure consistent configuration data across a cell.

You can synchronize files on individual nodes or throughout your system.

To view this administrative console page, click System Administration > Node Agents
>node_agent_name > File Synchronization Service.

Enable service at server startup:

Specifies whether the server attempts to start the file synchronization service. This setting does not cause
a file synchronization operation to start. This setting is enabled by default.

Data type Boolean

Default true

Chapter 3. Setting up the application serving environment 171

Synchronization Interval:

Specifies the number of minutes that elapse between synchronizations. The default is 1 minute. Increase
the time interval to synchronize files less often.

Data type Integer

Units Minutes
Default 1

The minimum value that the application server uses is 1. If

you specify a value of 0, the application server ignores the
value and uses the default of 1.

Automatic Synchronization:

Specifies whether to synchronize files automatically after a designated interval. When this setting is
enabled, the node agent automatically contacts the deployment manager every synchronization interval to
attempt to synchronize the node’s configuration repository with the master repository owned by the
deployment manager.

If the Automatic synchronization setting is enabled, the node agent attempts file synchronization when it
establishes contact with the deployment manager. The node agent waits the synchronization interval
before it attempts the next synchronization.

Remove the check mark from the check box if you want to control when files are sent to the node.

Data type Boolean

Default true

Startup Synchronization:

Specifies whether the node agent attempts to synchronize the node configuration with the latest
configurations in the master repository prior to starting an application server.

The default is to not synchronize files prior to starting an application server. Enabling the setting ensures
that the node agent has the latest configuration but increases the amount of time it takes to start the
application server.

Note that this setting has no effect on the startServer command. The startServer command launches a
server directly and does not use the node agent.

Data type Boolean

Default false

Exclusions:

Specifies files or patterns that should not be part of the synchronization of configuration data. Files in this
list are not copied from the master configuration repository to the node, and are not deleted from the
repository at the node.

The default is to have no files specified.

172 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
iSeries users: The default is */plugin-cfg.xml, which excludes the Web Server plug-in configuration file
from synchronization.

To specify a file, use a complete name or a name with a leading or trailing asterisk (*) for a wildcard. For
example:

cells/cell name/nodes/node name/file name Excludes this specific file

*/file name Excludes files named file name in any context
dirname/* Excludes the subtree under dirname

Press Enter at the end of each entry. Each file name appears on a separate line.

Since these strings represent logical document locations and not actual file paths, only forward slashes are
needed no matter the platform.

Changes to the exclusion list are picked up when the node agent is restarted.

Data type String

Units File names or patterns

Administrative agents: Resources for learning

Use the following links to find relevant supplemental information about WebSphere Application Server
administrative agents and distributed administration. The information resides on IBM and non-IBM Internet
sites, whose sponsors control the technical accuracy of the information.

These links are provided for convenience. Often, the information is not specific to the IBM WebSphere
Application Server product, but is useful all or in part for understanding the product. When possible, links
are provided to technical papers and Redbooks that supplement the broad coverage of the release
documentation with in-depth examinations of particular product areas.

View links to additional information:

Administration
v IBM WebSphere Application Server Redbooks at http://publib-
b.boulder.ibm.com/Redbooks.nsf/portals/WebSphere.
This site contains a listing of all WebSphere Application Server Redbooks.
v IBM developerWorks WebSphere at http://www.software.ibm.com/wsdd/.
This site is the home of technical information for developers working with WebSphere products. You can
download WebSphere software, take a fast path to developerWorks zones, such as VisualAge Java or
WebSphere Application Server, learn about WebSphere products through a newcomers page, tutorials,
technology previews, training, and Redbooks, get answers to questions about WebSphere products, and
join the WebSphere community, where you can keep up with the latest developments and technical
papers.
v WebSphere Application Server Support page at
http://www.ibm.com/software/webservers/appserv/support.html.
Take advantage of the Web-based Support and Service resources from IBM to quickly find answers to
your technical questions. You can easily access this extensive Web-based support through the IBM
Software Support portal and search by product category, or by product name. For example, if you are
experiencing problems specific to WebSphere Application Server, click WebSphere Application Server
in the product list. The WebSphere Application Server Support page appears.

Chapter 3. Setting up the application serving environment 173

Configuring the environment
To assist in handling requests among Web applications, Web containers, and application servers, you can
configure cell-widesettings for virtual hosts, variables and shared libraries.
1. Configure virtual hosts.
2. Configure variables.
3. If your deployed applications use shared library files, define the shared library files needed.
See “Managing shared libraries” on page 184.

Virtual hosts
A virtual host is a configuration that enables a single host machine to resemble multiple host machines.
Resources associated with one virtual host cannot share data with resources associated with another
virtual host, even if the virtual hosts share the same physical machine.

Each virtual host has a logical name and a list of one or more DNS aliases by which it is known. A DNS
alias is the TCP/IP hostname and port number that is used to request the servlet, for example
yourHostName:80. When no port number is specified, 80 is assumed.

When a servlet request is made, the server name and port number entered into the browser are compared
to a list of all known aliases in an effort to locate the correct virtual host and serve the servlet. If no match
is found, an error is returned to the browser.

An application server provides a default virtual host with some common aliases, such as the machine’s IP
address, short host name, and fully qualified host name. The alias comprises the first part of the path for
accessing a resource such as a servlet. For example, it is localhost:80 in the request
http://localhost:80/myServlet.

A virtual host is not associated with a particular node (machine). It is a configuration, rather than a ″live
object,″ explaining why you can create it, but cannot start or stop it. For many users, creating virtual hosts
is unnecessary because the default_host is provided.

Adding a localhost to the virtual hosts adds the host name and IP address of the localhost machine to the
alias table. This allows a remote user to access the administrative console.

Why you would use virtual hosting

Virtual hosts let you manage a single application server on a single machine as if the application server
were multiple application servers each on their own host machine. Resources associated with one virtual
host cannot share data with resources associated with another virtual host. This is true even though the
virtual hosts share the same application server on the same physical machine.

Virtual hosts allow the administrator to isolate and independently manage multiple sets of resources on the
same physical machine.

Suppose an Internet service provider (ISP) has two customers with Internet sites hosted on the same
machine. The ISP keeps the two sites isolated from one another, despite their sharing a machine, by using
virtual hosts. The ISP associates the resources of the first company with VirtualHost1 and the resources of
the second company with VirtualHost2. Both virtual hosts map to the same application server.

Further suppose that both company sites offer the same servlet. Each site has its own instance of the
servlet, and is unaware of the same servlet on the other site. If the company whose site is organized on
VirtualHost2 is past due in paying its account with the ISP, the ISP can refuse all servlet requests that are
routed to VirtualHost2. Even though the same servlet is available on VirtualHost1, the requests directed at
VirtualHost2 do not go to the other virtual host.

174 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
The servlets on one virtual host do not share their context with the servlets on the other virtual host.
Requests for the servlet on VirtualHost1 can continue as usual. This is true even though VirtualHost2 is
refusing to fill requests for the servlet with the same name.

You associate a servlet or other application with a virtual host instead of the actual DNS address.

The default virtual host (default_host)

The product provides a default virtual host (named default_host).

The virtual host configuration uses wildcard entries with the ports for its virtual host entries.
v The default alias is *:80, using an internal port that is not secure.
v Aliases of the form *:9080 use the secure internal port.
v Aliases of the form *:9443 use the external port that is not secure.
v Aliases of the form *:443 use the secure external port.

Unless you specifically want to isolate resources from one another on the same node (physical machine),
you probably do not need any virtual hosts in addition to the default host.

How requests map to virtual host aliases

Virtual hosts let you manage a single application server on a single machine as if the application server
were multiple application servers that are each on their own host machine. Resources associated with one
virtual host cannot share data with resources associated with another virtual host, even though the virtual
hosts share the same application server on the same physical machine.

When you request a resource, WebSphere Application Server tries to map the request to an alias of a
defined virtual host.

Mappings are both case sensitive and insensitive. For example, the portion ″http://host:port/″ is case
insensitive, but the URL that follows is case sensitive. The match must be alphanumerically exact. Also,
different port numbers are treated as different aliases.

For example, the request http://www.myhost.com/myservlet maps successfully to

http://WWW.MYHOST.COM/myservlet but not to http://WWW.MYHOST.COM/MYSERVLET or
Www.Myhost.Com/Myservlet. In the latter two cases, these mappings fail due to case sensitivity. The
request http://www.myhost.com/myservlet does not map successfully to http://myhost/myservlet or to
http://myhost:9876/myservlet. These mappings fail because they are not alphanumerically correct.

You can use wildcard entries for aliases by port and specify that all valid host name and address
combinations on a particular port map to a particular virtual host.

If you request a resource using an alias that cannot be mapped to an alias of a defined virtual host, you
receive a 404 error in the browser that was used to issue the request. A message states that the virtual
host could not be found.

Two sets of associations occur for virtual hosts. Application deployment associates an application with a
virtual host. Virtual host definitions associate the network address of the machine and the HTTP transport
or Web server port assignment of the application server with the virtual host. Looking at the flow from the
Web client request for the snoop servlet, for example, the following actions occur:
1. The Web client asks for the snoop servlet: at Web address
http://www.some_host.some_company.com:9080/snoop
2. The some_host machine has the 9080 port assigned to the stand-alone WebSphere Application
Server, server1.
3. The server1 Application Server looks at the virtual host assignments to determine the virtual host that
is assigned to the alias some_host.some_company.com:9080.

Chapter 3. Setting up the application serving environment 175

4. The application server finds that no explicit alias for that DNS string exists. However, a wild card
assignment for host name * at port 9080 does exist. This is a match. The virtual host that defines the
match is default_host.
5. The application server looks at the applications deployed on the default_host and finds the snoop
servlet.
6. The application server serves the application to the Web client and the requester is able to use the
snoop servlet.

You can have any number of aliases for a virtual host. You can even have overlapping aliases, such as:

Virtual host Alias Port

default_host * 9080
localhost 9080
my_machine 9080
my_machine.my_company.com 9080
localhost 80

The Application Server looks for a match using the explicit address specified on the Web client address.
However, it might resolve the match to any other alias that matches the pattern before matching the
explicit address. Simply defining an alias first in the list of aliases does not guarantee the search order
when WebSphere Application Server is looking for a matching alias.

A problem can occur if you use the same alias for two different virtual hosts. For example, assume that
you installed the default application and the snoop servlet on the default_host. You also have another
virtual host called the admin_host. However, you have not installed the default application or the snoop
servlet on the admin_host.

Assume that you define overlapping aliases for both virtual hosts because you accidentally defined port
9080 for the admin_host instead of port 9060:

Virtual host Alias Port

default_host * 9080
localhost 9080
admin_host * 9060
my_machine.com 9080

Assume that a Web client request comes in for http://my_machine.com:9080/snoop.

If the application server matches the request against *:9080, the application is served from the
default_host. If the application server matches the request to my.machine.com:9080, the application cannot
be found. A 404 error occurs in the browser that issues the request. A message states that the virtual host
could not be found.

This problem is the result of not finding the requested application in the first virtual host that has a
matching alias. The correct way to code aliases is for the alias name on an incoming request to match
only one virtual host in all of your virtual host definitions. If the URL can match more than one virtual host,
you can see the problem just described.

176 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Configuring virtual hosts
Virtual hosts enable you to isolate and independently manage multiple sets of resources on the same
physical machine.
1. Create a virtual host using the “Virtual host collection” of the administrative console. Click
Environment > Virtual Hosts from the navigation tree of the console. Click New. On the “Virtual host
settings” on page 178 page that displays, specify an administrative name for the virtual host. When
you create a virtual host, a default set of 90 MIME entries is created for the virtual host.
2. There must be a virtual host alias corresponding to each port used by an HTTP transport. There is one
HTTP transport in each Web container, usually assigned to the virtual host named default_host. You
can change the default assignment to any valid virtual host.
You must create a virtual host for each HTTP port in the following cases:
v You are using the internal HTTP transport with a port other than the default of 9080. You must
define the port that you are using.
v You are using the default port 9080, but the port is no longer defined. You must define port 9080.
v You have created multiple Application Servers (either stand-alone servers or cluster members) that
use the same virtual host. Because each server must be listening on a different HTTP transport
port, you must define a virtual host alias for the transport port of each server.
If you define new virtual host aliases, identify the port values that the aliases use on the “HTTP
transport collection” on page 225 page.
3. If necessary, create a virtual host alias for each HTTP transport port.
From the “Virtual host collection” page, click your virtual host. On the “Virtual host settings” on page
178 page for the virtual host, click Host aliases. To define a virtual host alias on the “Host alias
collection” on page 178 page, click New. On the “Host alias settings” on page 179 page for the virtual
host alias, specify a host name and a port. Configure the virtual host to contain an alias for the port
number. For example, specify an alias of *:9082 if 9082 is the port number in use by the transport.
4. When you enter the URL for the application into a Web browser, include the port number in the URL.
For example, if 9082 is the port number, specify a URL such as
http://localhost:9082/wlm/SimpleServlet
5. If MIME entries are not specified at the Web module level, define MIME object types and their file
name extensions. For each needed MIME entry on the “MIME type collection” on page 180 page, click
New. On the “MIME type settings” on page 180 page, specify a MIME type and extension.
6. After you configure a virtual host alias or change a configuration, you must regenerate the Web server
plug-in configuration and restart WebSphere Application Server.

Virtual host collection

Use this page to create and manage configurations that each let a single host machine resemble multiple
host machines. Such configurations are known as virtual hosts.

To view this administrative console page, click Environment > Virtual Hosts.

Each virtual host has a logical name (which you define on this panel) and is known by its list of one or
more domain name system (DNS) aliases. A DNS alias is the TCP/IP host name and port number used to
request the servlet, for example yourHostName:80. (Port 80 is the default.)

You define one or more alias associations by clicking an existing virtual host or by adding a new virtual
host.

When a servlet request is made, the server name and port number entered into the browser are compared
to a list of all known aliases in an effort to locate the correct virtual host to serve the servlet. No match
returns an error to the browser.

Chapter 3. Setting up the application serving environment 177

An application server profile provides a default virtual host with some common aliases, such as the
internet protocol (IP) address, the DNS short host name, and the DNS fully qualified host name. The alias
comprises the first part of the path for accessing a resource such as a servlet.

For example, the alias is localhost:80 in the request http://localhost:80/myServlet.

A virtual host is not associated with a particular profile or node (machine), but is associated with a
particular server instead. It is a configuration, rather than a ″live object.″ You can create a virtual host, but
you cannot start or stop it.

For many users, creating virtual hosts is unnecessary because the default_host that is provided is
sufficient.

Adding the host name and IP address of the localhost machine to the alias table lets a remote user
access the administrative console.

Resources associated with one virtual host cannot share data with resources associated with another
virtual host, even if the virtual hosts share the same physical machine.

Name:

Specifies a logical name for configuring Web applications to a particular host name. The default virtual
host is suitable for most simple configurations.

Virtual hosts enable you to isolate, and independently manage, multiple sets of resources on the same
physical machine. Determine whether you need a virtual host alias for each port associated with an HTTP
transport channel or an HTTP transport. There must be a virtual host alias corresponding to each port
used by an HTTP transport channel or an HTTP transport. There is one HTTP transport channel or HTTP
transport associated with each Web container, and there is one Web container in each application server.

When you create a virtual host, a default set of 90 MIME entries is created for the virtual host.

You must create a virtual host for each HTTP port in the following cases:
v You use the internal HTTP transport with a port other than the default value of 9080, or for some reason
the virtual host does not contain the usual entry for port 9080.
v You create multiple application servers (stand-alone servers, managed servers, or cluster members) that
are using the same virtual host. Because each server must be listening on a different HTTP port, you
need a virtual host alias for the HTTP port of each server.

Virtual host settings:

Use this page to configure a virtual host instance.

To view this administrative console page, click Environment > Virtual Hosts >virtual_host_name.

Name:

Specifies a logical name for configuring Web applications to a particular host name. The default virtual
host is suitable for most simple configurations.

Data type String

Default default_host

Host alias collection:

178 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Use this page to manage host name aliases defined for a virtual host. An alias is the DNS host name and
port number that a client uses to form the URL request for a Web application resource.

To view this administrative console page, click Environment > Virtual Hosts >virtual_host_name > Host
Aliases.

Host Name:

Specifies the IP address, DNS host name with domain name suffix, or just the DNS host name, used by a
client to request a Web application resource (such as a servlet, JavaServer Pages (JSP) file, or HTML
page). For example, the host alias name is myhost in a DNS name of myhost:8080.

The product provides a default virtual host (named default_host). The virtual host configuration uses the
wildcard character * (asterisk) along with the port number for its virtual host entries. Unless you specifically
want to isolate resources from one another on the same node (physical machine), you probably do not
need any virtual hosts in addition to the default host.

Port:

Specifies the port for which the Web server has been configured to accept client requests. For example,
the port assignment is 8080 in a DNS name of myhost:8080. A URL refers to this DNS as:
http://myhost:8080/servlet/snoop.

Host alias settings:

Use this page to view and configure a host alias.

To view this administrative console page, click Environment > Virtual Hosts >virtual_host_name > Host
Aliases >host_alias_name.

Host name:

Specifies the IP address, domain name system (DNS) host name with domain name suffix, or the DNS
host name that clients use to request a Web application resource, such as a servlet, JSP file, or HTML
page.

For example, when the DNS name is myhost, the host alias is myhost:8080, where 8080 is the port. A URL
request can refer to the snoop servlet on the host alias as: http://myhost:8080/servlet/snoop.

When there is no port number specified for a host alias, the default port is 80. For existing virtual hosts,
the default host name and port reflect the values specified at product installation or configuration. For new
virtual hosts, the default can be * to allow any value or no specification.

Data type String

Default *

You can also use the IP address or the long or short DNS
name.

Port:

Specifies the port where the Web server accepts client requests. Specify a port value in conjunction with
the host name.

The default reflects the value specified at product setup. The default might be 80, 81, 9060 or a similar
value.

Chapter 3. Setting up the application serving environment 179

Data type Integer
Default 9060

MIME type collection:

Use this page to view and configure multi-purpose internet mail extensions (MIME) object types and their
file name extensions.

The list shows a collection of MIME type extension mappings defined for the virtual host. Virtual host
MIME entries apply when you do not specify MIME entries at the Web module level.

To view a list of current virtual host Mime types in the administrative console, click Environment > Virtual
Hosts >virtual_host_name > MIME Types.

MIME Type:

Specifies a MIME type, which can be application, audio, image, text, video, www, or x-world. An example
value for MIME type is text/html.

Extensions:

Specifies file extensions of files that map the MIME type. Do not specify the period before the extension.
Example extensions for a text/html MIME type are htm and html.

MIME type settings:

Use this page to configure a multi-purpose internet mail extensions (MIME) object type.

To view this administrative console page, click Environment > Virtual Hosts >virtual_host_name > MIME
Types >MIME_type.

MIME Type:

Specifies a MIME type, which can be application, audio, image, text, video, www, or x-world. An example
value for MIME type is text/html.

An example value for MIME type is text/html. A default value appears only if you are viewing the
configuration for an existing instance.

Data type String

Extensions:

Specifies file extensions of files that map the MIME type. Do not specify the period before the extension.
Example extensions for a text/html MIME type are htm and html.

File extensions for a text/html MIME type are .htm and .html. A default value appears only if you are
viewing the configuration for an existing MIME type.

Data type String

Variables
A variable is a configuration property that can be used to provide a parameter for some values in the
system. A variable has a name and a value.

180 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
WebSphere variables are used for:
v Configuring WebSphere Application Server path names, such as JAVA_HOME, and
APP_INSTALL_ROOT.
v Configuring certain cell-widecustomization values.

Each variable has a scope. A scope is the range of locations in the WebSphere Application Server network
where the variable is applicable.
v A variable with a cell-wide scope is available across the entire WebSphere Application Server cell.
v A variable with a node-level scope is available only on the node and the servers on that node. If a
node-level variable has the same name as a cell-wide variable, the node-level variable value takes
precedence.
v A server variable is available only on the one server process. A server variable takes precedence over a
variable with the same name that is defined at a higher level.

You can use variables in configuration values such as file system path settings. Use the following syntax
to refer to a variable:
${variable_name}

The value of a variable can contain a reference to another variable. The value of the variable is computed
by substituting the value of the referenced variable recursively.

Variables are useful when concatenating two path variables when the specification does not accept the
AND operator. For example, suppose that the following variables exist:

Variable name Variable value

ROOT_DIR /
HOME_DIR ${ROOT_DIR}home
USER_DIR ${HOME_DIR}/myuserdir

The variable reference ${USER_DIR} resolves to the value /home/myuserdir.

Configuring WebSphere variables

This topic describes how to create a WebSphere Application Server variable.

You can define a WebSphere Application Server variable to provide a parameter for some values in the
system. After you define the name and value for a variable, the value is used in place of the variable
name. Variables most often specify file paths. However, some system components also support the use of
variables.

WebSphere variables are used for:

v Configuring WebSphere Application Server path names, such as JAVA_HOME, and
APP_INSTALL_ROOT.
v Configuring certain cell-widecustomization values.

The scope of a variable can be cell-wide, node-wide, or applicable to only one server process.

Define variables on the Environment > WebSphere Variables console page.

Define the scope to apply a variable cell-wide, cluster-wide, node-wide or to only one server process. A
variable resolves to its new value when used in a component that supports the use of variables.
1. Click Environment > WebSphere Variables in the administrative console to define a new variable.

Chapter 3. Setting up the application serving environment 181

2. Specify the scope of the variable. Declare the new variable for the Cell, Cluster,Node or Server and
click Apply.
The variable exists at the level you specify. Define a variable at multiple levels to use multiple values.
The more granular definition overrides the higher level setting.
For instance, if you specify the same variable on a node and a server, the server setting overrides the
node setting. Similarly, a node level setting overrides a cluster or cell setting.
Scoping variables is particularly important when testing data source objects. Variable scoping can
cause a data source to fail the test connection, but to succeed at run time, or to pass the test
connection, but fail at run time.
See the Developing and deploying applications PDF for more information.
3. Click New on the WebSphere Variables page.
4. Specify a name, a value, and a description on the Variable page. Click OK.
5. Verify that the variable is displayed in the list of variables. The administrative console does not pick up
typing errors. The variable is ignored if it is referred to incorrectly.
6. Save your configuration.
7. Stop the server and start the server again to put the variable configuration into effect.

WebSphere variables collection

Use this page to view and change a list of substitution variables with their values and scope.

To view this administrative console page, click Environment > WebSphere Variables.

For information on a variable, click the variable and read the value in the Description field.

Name:

Specifies the symbolic name for a WebSphere Application Server variable. For example, a variable name
might represent a physical path or URL root used by WebSphere Application Server.

Value:

Specifies the value that the symbolic name represents. For example, the value might be an absolute path
value for a file or URL root.

Scope:

Specifies the level at which a WebSphere Application Server variable is visible on the administrative
console panel.

A resource can be visible in the administrative console collection table at the cell, cluster, node, or server
scope.

Variable settings:

Use this page to define the name and value of a WebSphere Application Server substitution variable.

To view this administrative console page, click Environment > WebSphere Variables
>WebSphere_variable_name.

Name:

Specifies the symbolic name for a WebSphere Application Server variable. For example, a variable name
might represent a physical path or URL root that is used by WebSphere Application Server.

182 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
WebSphere variables are used for:
v Configuring WebSphere Application Server path names, such as JAVA_HOME, and
APP_INSTALL_ROOT.
v Configuring certain cell-widecustomization values.

WebSphere Application Server substitutes the symbolic name wherever its value displays in the system.

For example, ″JAVA_HOME″ is the symbolic name representing the file system path to the installation
directory for the Java Virtual Machine (JVM). For example, the value is
/opt/IBM/WebSphere/AppServer/java for the WebSphere Application Server product on a Linux machine.

You can create new variables for use in WebSphere Application Server components that support the use
of variables.

Data type String

Value:

Specifies the value that the symbolic name represents. For example, the value might be an absolute path
value for a file or URL root.

For example, /opt/IBM/WebSphere/AppServer/java is the value on a Linux machine for a variable named
JAVA_HOME.

Data type String

Description:

Documents the purpose of a variable.

Data type String

IBM Toolbox for Java JDBC driver

WebSphere Application Server supports the IBM Toolbox for Java JDBC driver. The IBM Toolbox for Java
JDBC driver is included with the IBM Toolbox for Java product.

IBM Toolbox for Java is a library of Java classes that are optimized for accessing iSeries and AS/400 data
and resources. You can use the IBM Toolbox for Java JDBC driver to access local or remote DB2 UDB
for iSeries 400 databases from server-side and client Java applications that run on any platform that
supports Java.

IBM Toolbox for Java is available in these versions:

IBM Toolbox for Java licensed program
The licensed program is available with every OS/400 release, starting with Version 4 Release 2
(V4R2). You can install the licensed program on your iSeries 400 system, and then either copy the
IBM Toolbox for Java JAR file (jt400.jar) to your system or update your system classpath to locate
the server installation. Product documentation for IBM Toolbox for Java is available from the
iSeries information center: http://publib.boulder.ibm.com/iseries/v5r1/ic2924/index.htm
Locate the documentation by traversing the following path in the left-hand navigation window of
the iSeries information center: Programming > Java > IBM Toolbox for Java.
JTOpen
JTOpen is the open source version of IBM Toolbox for Java, and is more frequently updated than
the licensed program version. You can download JTOpen from http://www-

Chapter 3. Setting up the application serving environment 183

 1.ibm.com/servers/eserver/iseries/toolbox/downloads.htm. You can also download the JTOpen
Programming Guide. The guide includes instructions for installing JTOpen and information about
the JDBC driver.

The JDBC driver for both versions supports JDBC 2.0. For more information about IBM Toolbox for Java
and JTOpen, see the product Web site at http://www-
1.ibm.com/servers/eserver/iseries/toolbox/index.html.

Note: If you are using WebSphere Application Server on platforms other than iSeries, use the JTOpen
version of the Toolbox JDBC driver.

Configure and use the jt400.jar file

1. Download the jt400.jar file from the JTOpen URL at http://www-
1.ibm.com/servers/eserver/iseries/toolbox/downloads.htm. Place it in a directory on your
workstation such as C:\JDBC_Drivers\Toolbox.
2. Open the administrative console.
3. Select Environment.
4. Select Managed WebSphere Variables.
5. Set the managed variable OS400_TOOLBOX_JDBC_DRIVER_PATH at the Node level.
6. Double click OS400_TOOLBOX_JDBC_DRIVER_PATH.
7. Set the value to the full directory path to the jt400.jar file downloaded in step one. Do not include
jt400.jar in this value. For example,
OS400_TOOLBOX_JDBC_DRIVER_PATH == "C:\JDBC_Drivers\Toolbox"
When you choose a Toolbox driver from the list of possible resource providers the Classpath field
looks like:
Classpath == ${OS400_TOOLBOX_JDBC_DRIVER_PATH}/jt400.jar

Shared library files

Shared library files in WebSphere Application Server consist of a symbolic name, a Java class path, and a
native path for loading Java Native Interface (JNI) libraries.

You can define a shared library at the cell, node, or server level. Defining a library at one of the three
levels does not cause the library to be placed into the application server’s class loader. You must
associate the library to an application or server in order for the classes represented by the shared library
to be loaded in either a server-wide or application-specific class loader.

A separate class loader is used for shared libraries that are associated with an application server. This
class loader is the parent of the application class loader, and the WebSphere Application Server
extensions class loader is its parent. Shared libraries that are associated with an application are loaded by
the application class loader.

Managing shared libraries

Shared libraries are files used by multiple applications. Using the administrative console, you can define a
shared library at the cell, node, or server level. You can then associate the library to an application or
server to load the classes represented by the shared library in either a server-wide or application-specific
class loader. Using an installed optional package, you can associate a shared library to an application by
declaring the dependent library .jar file in the MANIFEST.MF file of the application. Refer to the Java 2
Platform, Enterprise Edition (J2EE) 1.4 specification, section 8.2 for an example.

If your deployed applications use shared library files, define shared libraries for the library files and
associate the libraries with specific applications or with an application server. Associating a shared library
file with a server associates the file with all applications on the server. Use the Shared Libraries page to
define new shared library files to the system and remove them.

184 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
v Use the administrative console to define a shared library.
1. Create a shared library for each library file that your applications need.
2. Associate each shared library with an application or a server.
– Associate a shared library with an application that uses the shared library file.
– Associate a shared library with an application server so every application on the server can use
the shared library file.
v Use an installed optional package to declare a shared library for an application.
v Remove a shared library.
1. Click Environment > Shared Libraries in the console navigation tree to access the Shared
Libraries page.
2. Select the library to be removed.
3. Click Delete.
The list of shared libraries is refreshed. The library file no longer displays in the list.

Creating shared libraries

Shared libraries are files used by multiple applications.

The first step for making a library file available to multiple applications deployed on a server is to create a
shared library for each library file that your applications need. When you create the shared libraries, set
variables for the library files.

Use the Shared Libraries page to create and configure shared libraries.
1. Go to the Shared Libraries page. Click Environment > Shared Libraries in the console navigation
tree.
2. Change the scope of the collection table to see what shared libraries are in a cell, node, or server.
a. Select the cell, a node, or a server.
b. Click Apply.
3. Click New.
4. Configure the shared library.
a. On the settings page for a shared library, specify the name, class path, and any other variables for
the library file that are needed.
b. Click Apply.
5. Repeat steps 1 through 4 until you define a shared library instance for each library file that your
applications need.

Using the administrative console, associate your shared libraries with specific applications or with the class
loader of an application server. Associating a shared library file with a server class loader associates the
file with all applications on the server.

Alternatively, you can use an installed optional package to associate your shared libraries with an
application.

Shared library collection

Use this page to define a list of shared library files that deployed applications can use.

To view this administrative console page, click Environment > Shared Libraries.

By default, a shared library is accessible to applications deployed (or installed) on the same node as the
shared library file. Use the Scope field to change the scope to a different node or to a specific server.

Name:

Chapter 3. Setting up the application serving environment 185

Specifies a name for the shared library.

Description:

Describes the shared library file.

Shared library settings:

Use this page to make a library file available to deployed applications.

To view this administrative console page, click Environment > Shared Libraries >shared_library_name.

Name:

Specifies a name for the shared library.

Data type String

Description:

Describes the shared library file.

Data type String

Classpath:

Specifies the class path used to locate the JAR files for the shared library support.

Data type String

Units Class path

Native Library Path:

Specifies the class path for locating platform-specific library files for shared library support; for example,
.dll, .so, or *SRVPGM objects.

Data type String

Units Class path

Associating shared libraries with applications

You can associate a shared library with an application. Classes represented by the shared library are then
loaded in the application’s class loader, making the classes available to the application.

This article assumes that you have defined a shared library at the cell, node, or server level. The shared
library represents a library file used by multiple deployed applications.

This article also assumes that you want to use the administrative console, and not an installed optional
package, to associate a shared library with an application.

To associate a shared library with an application, create and configure a library reference using the
administrative console. A library reference specifies the name of the shared library file.

If you associate a shared library with an application, do not associate the same shared library with a
server class loader.

186 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
1. Click Applications > Enterprise Applications >application_name > Libraries in the console
navigation tree to access the Library Ref page.
2. Click Add.
3. On the settings page for a library reference, specify variables for the library reference as needed. The
variables identify the shared library file that your application uses.
4. Click Apply.

The name of the library reference is shown in the list on the Library Ref page.

Repeat steps 2 through 4 until you define a library reference instance for each shared library that your
application requires.

Associating shared libraries with servers

You can associate shared libraries with the class loader of a server. Classes represented by the shared
library are then loaded in a server-wide class loader, making the classes available to all applications
deployed on the server.

This article assumes that you have defined a shared library at the cell, node, or server level. The shared
library represents a library file used by multiple deployed applications.

To associate a shared library with the class loader of a server, create and configure a library reference
using the administrative console. A library reference specifies the name of the shared library file.

If you associate a shared library with a server class loader, do not associate the same shared library with
an application.
1. Configure class loaders for applications deployed on the server.
a. Click Servers > Application Servers > server_name to access the settings page for the
application server.
b. Set values for the application Class loader policy and Class loading mode of the server. For
information on these settings, see “Application server settings” on page 204 and class loaders.
2. Create a library reference for each shared library file that your application needs.
a. Go to the settings page for a class loader.
b. Click Libraries to access the Library Ref page.
c. Click Add.
d. On the settings page for a library reference, specify variables for the library reference as needed.
The variables identify the shared library file that your application uses.
e. Click Apply. The name of the library reference is shown in the list on the Library Ref page.
Repeat the previous steps until you define a library reference for each shared library that your
application needs.

Installed optional packages

Installed optional packages enable applications to use the classes in Java archive (.jar) files without
having to include them explicitly in a class path. An installed optional package is a .jar file containing
specialized tags in its manifest file that enable the application server to identify it. An installed optional
package declares one or more shared library .jar files in the manifest file of an application. When the
application is installed on a server or cluster, the classes represented by the shared libraries are loaded in
the class loader of the application, making the classes available to the application.

When a Java 2 Platform, Enterprise Edition (J2EE) application is installed on a server or cluster,
dependency information is specified in its manifest file. WebSphere Application Server reads the
dependency information of the application (.ear file) to automatically associate the application with an

Chapter 3. Setting up the application serving environment 187

installed optional package .jar file. WebSphere Application Server adds the .jar files in associated
optional packages to the application class path. Classes in the installed optional packages are then
available to application classes.

Installed optional packages used by WebSphere Application Server are described in section 8.2 of the
J2EE specification, Version 1.4 at http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf.

WebSphere Application Server supports using the manifest file (manifest.mf) in shared library .jar files
and application .ear files. WebSphere Application Server does not support the Java 2 Platform Standard
Edition (J2SE) Installed Optional Package semantics used in the J2SE specification
(http://java.sun.com/j2se/1.3/docs/guide/extensions/spec.html), which primarily serve the applet
environment. WebSphere Application Server ignores applet-specific tags within manifest files.

Sample manifest.mf file

A sample manifest file follows for an application app1.ear that refers to a single shared library file
util.jar:
app1.ear:
META-INF/application.xml
ejb1.jar:
META-INF/MANIFEST.MF:
Extension-List: util
util-Extension-Name: com/example/util
util-Specification-Version: 1.4
META-INF/ejb-jar.xml

util.jar:
META-INF/MANIFEST.MF:
Extension-Name: com/example/util
Specification-Title: example.com’s util package
Specification-Version: 1.4
Specification-Vendor: example.com
Implementation-Version: build96

The syntax of a manifest entry depends on whether the entry applies to a member with a defining role (the
shared library) or a member with a referencing role (a J2EE application or a module within a J2EE
application).

Manifest entry tagging

Main tags used for manifest entries include the following:

Extension-List
A required tag with variable syntax. Within the context of the referencing role (application’s
manifest), this is a space delimited list that identifies and constructs unique Extension-Name,
Extension-Specification tags for each element in the list. Within the context of the defining role
(shared library), this tag is not valid.
Extension-Name
A required tag that provides a name and links the defining and referencing members. The syntax
of the element within the referencing role is to prefix the element with the <ListElement> string.
For each element in the Extension-List, there is a corresponding <ListElement>-Extension-Name
tag. The defining string literal value for this tag (in the above sample com/example/util1) is used
to match (in an equality test) the corresponding tags between the defining and referencing roles.
Specification-Version
A required tag that identifies the specification version and links the defining and referencing
members.

188 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Implementation-Version
An optional tag that identifies the implementation version and links the defining and referencing
members.

Further information on these tags is in the .jar file specification at

http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Manifest%20Specification.

Using installed optional packages

You can associate one or more shared libraries with an application using an installed optional package
that declares the shared libraries in the application’s manifest file. Classes represented by the shared
libraries are then loaded in the application’s class loader, making the classes available to the application.

Read about installed optional packages in “Installed optional packages” on page 187 and in section 8.2 of
the Java 2 Platform, Enterprise Edition (J2EE) specification, Version 1.4 at
http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf.

WebSphere Application Server does not support the Java 2 Platform Standard Edition (J2SE) Installed
Optional Package semantics used in the J2SE specification
(http://java.sun.com/j2se/1.3/docs/guide/extensions/spec.html), which primarily serve the applet
environment. WebSphere Application Server ignores applet-specific tags within manifest files.

Installed optional packages expand the existing shared library capabilities of an application server. Prior to
Version 6, an administrator was required to associate a shared library to an application or server. Installed
optional packages enable an administrator to declare a dependency in an application’s manifest file to a
shared library, with installed optional package elements listed in the manifest file, and automatically
associate the application to the shared library. During application installation, the shared library .jar file is
added to the class path of the application class loader.

If you use an installed optional package to associate a shared library with an application, do not associate
the same shared library with an application class loader or a server class loader using the administrative
console.
1. Assemble the library file, including the manifest information that identifies it as an extension. Two
sample manifest files follow. The first sample manifest file has application app1.ear refer to a single
shared library file util.jar:
app1.ear:
META-INF/application.xml
ejb1.jar:
META-INF/MANIFEST.MF:
Extension-List: util
util-Extension-Name: com/example/util
util-Specification-Version: 1.4
META-INF/ejb-jar.xml

util.jar:
META-INF/MANIFEST.MF:
Extension-Name: com/example/util
Specification-Title: example.com’s util package
Specification-Version: 1.4
Specification-Vendor: example.com
Implementation-Version: build96

The second sample manifest file has application app1.ear refer to multiple shared library .jar files:
app1.ear:
META-INF/application.xml
ejb1.jar:
META-INF/MANIFEST.MF:
Extension-List: util1 util2 util3
Util1-Extension-Name: com/example/util1
Util1-Specification-Version: 1.4

Chapter 3. Setting up the application serving environment 189

 Util2-Extension-Name: com/example/util2
Util2-Specification-Version: 1.4
Util3-Extension-Name: com/example/util3
Util3-Specification-Version: 1.4
META-INF/ejb-jar.xml

util1.jar:
META-INF/MANIFEST.MF:
Extension-Name: com/example/util1
Specification-Title: example.com’s util package
Specification-Version: 1.4
Specification-Vendor: example.com
Implementation-Version: build96

util2.jar:
META-INF/MANIFEST.MF:
Extension-Name: com/example/util2
Specification-Title: example.com’s util package
Specification-Version: 1.4
Specification-Vendor: example.com
Implementation-Version: build96

util3.jar:
META-INF/MANIFEST.MF:
Extension-Name: com/example/util3
Specification-Title: example.com’s util package
Specification-Version: 1.4
Specification-Vendor: example.com
Implementation-Version: build96
2. Create a shared library that represents the library file assembled in step 1. This installs the library file
as a WebSphere Application Server shared library.
3. Copy the shared library .jar file to the cluster members.
4. Assemble the application, declaring in the application manifest file dependencies to the library files
named the manifest created for step 1.
5. Install the application on the server or cluster.

During application installation, the shared library .jar files are added to the class path of the application
class loader.

Library reference collection

Use this page to view and manage library references that define how to use global libraries. For example,
you can use this page to associate shared library files with a deployed application.

To view this administrative console page, click Applications > Enterprise Applications
>application_name > Libraries.

If no shared libraries are defined, after you click Add a message is displayed stating that you must define
a shared library before you can create a library reference. A shared library is a container-wide library file
that can be used by deployed applications. To define a shared library, click Environment > Shared
Libraries and specify the scope of the container. Then, click New and specify a name and one or more
paths for the shared library. After you define a shared library, return to this page, click Add, and create a
library reference.

Library name:

Specifies a name for the library reference.

Library reference settings:

Use this page to define library references, which specify how to use global libraries.

190 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
To view this administrative console page, click Applications > Enterprise Applications
>application_name > Libraries >library_reference_name. A shared library must be defined to view this
page.

A shared library is a container-wide library file that can be used by deployed applications. To define a
shared library, click Environment > Shared Libraries and specify the scope of the container. Then, click
New and specify a name and one or more paths for the shared library.

Library name:

Specifies the name of the shared library to use for the library reference.

Data type String

Environment: Resources for learning

Use the following links to find relevant supplemental information about configuring the WebSphere
Application Server cell-wide environment. The information resides on IBM and non-IBM Internet sites,
whose sponsors control the technical accuracy of the information.

These links are provided for convenience. Often, the information is not specific to the IBM WebSphere
Application Server product, but is useful all or in part for understanding the product. When possible, links
are provided to technical papers and Redbooks that supplement the broad coverage of the release
documentation with in-depth examinations of particular product areas.

Programming instructions and examples

v WebSphere Application Server education at http://www.ibm.com/software/websphere/technical.

Administration
v Listing of all IBM WebSphere Application Server Redbooks at http://publib-
b.boulder.ibm.com/Redbooks.nsf/Portals/WebSphere.

Working with server configuration files

Application server configuration documents define the available application servers, their configurations,
and their contents.

You should periodically save changes to your administrative configuration. You can change the default
locations of configuration files, as needed.
1. Edit configuration files. The master repository is comprised of .xml configuration files. You can edit
configuration files using the administrative console, scripting, wsadmin commands, programming, or by
editing a configuration file directly.
2. Save changes made to configuration files. Using the console, you can save changes as follows:
a. Click Save on the taskbar of the administrative console.
b. Put a check mark in the Synchronize changes with Nodes check box.
c. On the Save page, click Save.
3. Handle temporary configuration files resulting from a session timing out.
4. Change the location of temporary configuration files.
5. Change the location of backed-up configuration files.
6. Change the location of temporary workspace files.
7. Back up and restore configurations.

Chapter 3. Setting up the application serving environment 191

Configuration documents
WebSphere Application Server stores configuration data for servers in several documents in a cascading
hierarchy of directories. The configuration documents describe the available application servers, their
configurations, and their contents. Most configuration documents have XML content.

Hierarchy of directories of documents

The cascading hierarchy of directories and the documents’ structure support multinode replication to
synchronize the activities of all servers in a cell. In a Network Deployment environment, changes made to
configuration documents in the cell repository, are automatically replicated to the same configuration
documents that are stored on nodes throughout the cell.

At the top of the hierarchy is the cells directory. It holds a subdirectory for each cell. The names of the cell
subdirectories match the names of the cells. For example, a cell named cell1 has its configuration
documents in the subdirectory cell1.

On the Network Deployment node, the subdirectories under the cell contain the entire set of documents for
every node and server throughout the cell. On other nodes, the set of documents is limited to what applies
to that specific node. If a configuration document only applies to node1, then that document exists in the
configuration on node1 and in the Network Deployment configuration, but not on any other node in the
cell.

Each cell subdirectory has the following files and subdirectories:

v The cell.xml file, which provides configuration data for the cell
v Files such as security.xml, virtualhosts.xml, resources.xml, and variables.xml, which provide
configuration data that applies across every node in the cell
v The clusters subdirectory, which holds a subdirectory for each cluster defined in the cell. The names of
the subdirectories under clusters match the names of the clusters.
Each cluster subdirectory holds a cluster.xml file, which provides configuration data specifically for that
cluster.
v The nodes subdirectory, which holds a subdirectory for each node in the cell. The names of the nodes
subdirectories match the names of the nodes.
Each node subdirectory holds files such as variables.xml and resources.xml, which provide
configuration data that applies across the node. Note that these files have the same name as those in
the containing cell’s directory. The configurations specified in these node documents override the
configurations specified in cell documents having the same name. For example, if a particular variable is
in both cell- and node-level variables.xml files, all servers on the node use the variable definition in the
node document and ignore the definition in the cell document.
Each node subdirectory holds a subdirectory for each server defined on the node. The names of the
subdirectories match the names of the servers. Each server subdirectory holds a server.xml file, which
provides configuration data specific to that server. Server subdirectories might hold files such as
security.xml, resources.xml and variables.xml, which provide configuration data that applies only to
the server. The configurations specified in these server documents override the configurations specified
in containing cell and node documents having the same name.
v The applications subdirectory, which holds a subdirectory for each application deployed in the cell. The
names of the applications subdirectories match the names of the deployed applications.
Each deployed application subdirectory holds a deployment.xml file that contains configuration data on
the application deployment. Each subdirectory also holds a META-INF subdirectory that holds a J2EE
application deployment descriptor file as well as IBM deployment extensions files and bindings files.
Deployed application subdirectories also hold subdirectories for all .war and entity bean .jar files in the
application. Binary files such as .jar files are also part of the configuration structure.

An example file structure is as follows:

192 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
cells
cell1
cell.xml resources.xml virtualhosts.xml variables.xml security.xml
nodes
nodeX
node.xml variables.xml resources.xml serverindex.xml
serverA
server.xml variables.xml
nodeAgent
server.xml variables.xml
nodeY
node.xml variables.xml resources.xml serverindex.xml
applications
sampleApp1
deployment.xml
META-INF
application.xml ibm-application-ext.xml ibm-application-bnd.xml
sampleApp2
deployment.xml
META-INF
application.xml ibm-application-ext.xml ibm-application-bnd.xml

Changing configuration documents

You can use one of the administrative tools (console, wsadmin, Java APIs) to modify configuration
documents or edit them directly. It is preferable to use the administrative console because it validates
changes made to configurations. ″“Configuration document descriptions”″ states whether you can edit a
document using the administrative tools or must edit it directly.

Configuration document descriptions

Most configuration documents have XML content. The table below describes the documents and states
whether you can edit them using an administrative tool or must edit them directly.

If possible, edit a configuration document using the administrative console because it validates any
changes that you make to configurations. You can also use one of the other administrative tools (wsadmin
or Java APIs) to modify configuration documents. Using the administrative console or wsadmin scripting to
update configurations is less error prone and likely quicker and easier than other methods.

However, you cannot edit some files using the administrative tools. Configuration files that you must edit
manually have an X in the Manual editing required column in the table below.

Document descriptions

(Locations split for publishing)

Configuration file Locations Purpose Manual editing required

admin-authz.xml config/cells/ Define a role for X
cell_name/ administrative operation
authorization.
app.policy config/cells/ Define security permissions X
cell_name/ for application code.
nodes/node_name/
cell.xml config/cells/ Identify a cell.
cell_name/

Chapter 3. Setting up the application serving environment 193

cluster.xml config/cells/ Identify a cluster and its
cell_name/ members and weights.
clusters/
cluster_name/ This file is only available
with the Network
Deployment product.
deployment.xml config/cells/ Configure application
cell_name/ deployment settings such
applications/ as target servers and
application_name/ application-specific server
configuration.
filter.policy config/cells/ Specify security X
cell_name/ permissions to be filtered
out of other policy files.
integral-jms- config/cells/ Provide security X
authorizations.xml cell_name/ configuration data for the
integrated messaging
system.
library.policy config/cells/ Define security permissions X
cell_name/ for shared library code.
nodes/node_name/
multibroker.xml config/cells/ Configure a data replication
cell_name/ message broker.
namestore.xml config/cells/ Provide persistent name X
cell_name/ binding data.
naming-authz.xml config/cells/ Define roles for a naming X
cell_name/ operation authorization.
node.xml config/cells/ Identify a node.
cell_name/
nodes/node_name/
pmirm.xml config/cells/ Configure PMI request X
cell_name/ metrics.
resources.xml config/cells/ Define operating
cell_name/ environment resources,
config/cells/ including JDBC, JMS,
cell_name/ JavaMail, URL, JCA
nodes/node_name/ resource providers and
config/cells/ factories.
cell_name/
nodes/node_name/
servers/
server_name/

security.xml config/cells/ Configure security, including

cell_name/ all user ID and password
data.
server.xml config/cells/ Identify a server and its
cell_name/ components.
nodes/
node_name/
servers/
server_name/

194 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
serverindex.xml config/cells/ Specify communication
cell_name/ ports used on a specific
nodes/ node.
node_name/
spi.policy config/cells/ Define security permissions X
cell_name/ for service provider libraries
nodes/ such as resource providers.
node_name/
variables.xml config/cells/ Configure variables used to
cell_name/ parameterize any part of
config/cells/ the configuration settings.
cell_name/
nodes/
node_name/
config/cells/
cell_name/
nodes/node_name/
servers/
server_name/

virtualhosts.xml config/cells/ Configure a virtual host and

cell_name/ its MIME types.

Object names
When you create a new object using the administrative console or a wsadmin command, you often must
specify a string for a name attribute. Most characters are allowed in the name string. However, the name
string cannot contain the following characters. The name string also cannot contain leading and trailing
spaces.

/ forward slash
\ backslash
* asterisk
, comma
: colon
; semi-colon
= equal sign
+ plus sign
? question mark
| vertical bar
< left angle bracket
> right angle bracket
& ampersand (and sign)
% percent sign
’ single quote mark
″ double quote mark
]]> No specific name exists for this character combination.
. period (not valid if first character; valid if a later character)

Configuration repositories
A configuration repository stores configuration data. By default, configuration repositories reside in the
config subdirectory of the product installation root directory.

A cell-level repository stores configuration data for the entire cell and is managed by a file repository
service that runs in the deployment manager. The deployment manager and each node have their own

Chapter 3. Setting up the application serving environment 195

repositories. A node-level repository stores configuration data needed by processes on that node and is
accessed by the node agent and application servers on that node.

When you change a WebSphere Application Server configuration by creating an application server,
installing an application, changing a variable definition or the like, and then save the changes, the cell-level
repository is updated. The file synchronization service distributes the changes to the appropriate nodes.

Handling temporary configuration files resulting from session timeout

If the console is not used for 15 minutes or more, the session times out. The same thing happens if you
close the browser window without saving the configuration file. Changes to the file are saved to a
temporary file when the session times out, after 15 minutes.

When a session times out, the configuration file in use is saved under the userid/timeout directory under
the ServletContext’s temp area. This is the value of the javax.servlet.context.tempdir attribute of the
ServletContext. By default, it is: install_root/temp/hostname/Administration/admin/admin.war

You can change the temp area by specifying it as a value for the tempDir init-param of the action servlet in
the deployment descriptor (web.xml) of the administrative application.

The next time you log on to the console, you are prompted to load the saved configuration file. If you
decide to load the saved file:
1. If a file with the same name exists in the install_root/config directory, that file is moved to the
userid/backup directory in the temp area.
2. The saved file is moved to the install_root/config directory.
3. The file is then loaded.

If you decide not to load the saved file, it is deleted from the userid/timeout directory in the temp area.

The configuration file is also saved automatically when the same user ID logs into the non-secured
console again, effectively starting a different session. This process is equivalent to forcing the existing user
ID out of session, similar to a session timing out.

Changing the location of temporary configuration files

The configuration repository uses copies of configuration files and temporary files while processing
repository requests. It also uses a backup directory while managing the configuration. You can change the
default locations of these files from the configuration directory to a directory of your choice using system
variables or the administrative console.

The default location for the configuration temporary directory is CONFIG_ROOT/temp. Change the location
by doing either of the following:
v Set the system variable was.repository.temp to the location you want for the repository temporary
directory. Set the system variable when launching a Java process using the -D option. For example, to
set the default location of the repository temporary directory, use the following option:
-Dwas.repository.temp=%CONFIG_ROOT%/temp
v Use the administrative console to change the location of the temporary repository file location for each
server configuration. For example, on the Network Deployment product, to change the setting for a
deployment manager, do the following:
1. Click System Administration > Deployment Manager in the navigation tree of the administrative
console. Then, click Administration Services, Repository Service, and Custom Properties.
2. On the Properties page, click New.
3. On the settings page for a property, define a property for the temporary file location. The key for this
property is was.repository.temp. The value can include WebSphere Application Server variables
such as ${WAS_TEMP_DIR}/config. Then, click OK.

196 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
The system property set using the first option takes precedence over the configuration property set using
the second option.

Changing the location of backed-up configuration files

During administrative processes like adding a node to a cell or updating a file, configuration files are
backed up to a backup location. The default location for the backup configuration directory is
CONFIG_ROOT/backup. Change the location by doing either of the following:
v Set the system variable was.repository.backup to the location you want as the repository backup
directory. Set the system variable when launching a Java process using the -D option. For example, to
set the default location of the repository backup directory, use the following option:
-Dwas.repository.backup=%CONFIG_ROOT%/backup
v Use the administrative console to change the location of the repository backup directory for each server
configuration. For example, on the Network Deployment product, do the following to change the setting
for a deployment manager:
1. Click System Administration > Deployment Manager in the navigation tree of the administrative
console. Then, click Administration Services, Repository Service, and Custom Properties.
2. On the Properties page, click New.
3. On the settings page for a property, define a property for the backup file location. The key for this
property is was.repository.backup. The value can include WebSphere Application Server variables
such as ${WAS_TEMP_DIR}/backup. Then, click OK.

The system property set using the first option takes precedence over the configuration property set using
the second option.

Changing the location of temporary workspace files

The administrative console workspace allows client applications to navigate the configuration. Each
workspace has its own repository location defined either in the system property or the property passed to
a workspace manager when creating the workspace: workspace.user.root or workspace.root, which is
calculated as %workspace.root%/user_ID/workspace/wstemp.

The default workspace root is calculated based on the user installation root: %user.install.root%/wstemp.
You can change the default location of temporary workspace files by doing the following:
v Distributed platforms: Change the setting for the system variable workspace.user.root or workspace.root
so its value is no longer set to the default location. Set the system variable when launching a Java
process using the -D option. For example, to set the default location the full path of the root of all users’
directories, use the following option:
-Dworkspace.user.root=full_path_for_root_of_all_user_directories

Backing up and restoring administrative configurations

WebSphere Application Server represents its administrative configurations as XML files. You should back
up configuration files on a regular basis.
1. Synchronize administrative configuration files.
a. Click System Administration > Nodes in the console navigation tree to access the Nodes page.
b. Click Full Resynchronize. The resynchronize operation resolves conflicts among configuration files
and can take several minutes to run.
2. Run the backupConfig command to back up configuration files.
3. Run the restoreConfig command to restore configuration files. Specify backup files that do not contain
invalid or inconsistent configurations.

Chapter 3. Setting up the application serving environment 197

Transformation of configuration files
The WebSphere Application Server master configuration repository stores configuration files for all the
nodes in the cell. When you upgrade the deployment manager from one release of WebSphere Application
Server to another, the configuration files that are stored in the master repository for the nodes on the old
release are converted into the format of the new release.

With this conversion, the deployment manager can process the configuration files uniformly. However,
nodes on an old release cannot readily use configuration files that are in the format of the new release.
WebSphere Application Server addresses the problem when it synchronizes the configuration files from the
master repository to a node on an old release. The configuration files are first transformed into the old
release format before they ship to the node. WebSphere Application Server performs the following
transformations on configuration documents:
v Changes the XML name space from the format of the new release to the format of the old release
v Strips out attributes of cell-level documents that are applicable to the new release only
v Strips out new resource definitions that are not understood by old release nodes

Server configuration files: Resources for learning

Use the following links to find relevant supplemental information about administering WebSphere
Application Server configuration files. The information resides on IBM and non-IBM Internet sites, whose
sponsors control the technical accuracy of the information.

These links are provided for convenience. Often, the information is not specific to the IBM WebSphere
Application Server product, but is useful all or in part for understanding the product. When possible, links
are provided to technical papers and Redbooks that supplement the broad coverage of the release
documentation with in-depth examinations of particular product areas.

View links to additional information:

Administration
v IBM WebSphere Application Server Redbooks at http://publib-
b.boulder.ibm.com/Redbooks.nsf/Portals/WebSphere.
This site contains a listing of all WebSphere Application Server Redbooks.
v IBM developerWorks WebSphere at http://www.software.ibm.com/wsdd.
This site is the home of technical information for developers working with WebSphere products. You can
download WebSphere software, take a fast path to developerWorks zones, such as VisualAge Java or
WebSphere Application Server, learn about WebSphere products through a newcomers page, tutorials,
technology previews, training, and Redbooks, get answers to questions about WebSphere products, and
join the WebSphere community, where you can keep up with the latest developments and technical
papers.
v WebSphere Application Server Support page at
http://www.ibm.com/software/webservers/appserv/support.html.
Take advantage of the Web-based Support and Service resources from IBM to quickly find answers to
your technical questions. You can easily access this extensive Web-based support through the IBM
Software Support portal at URL http://www-3.ibm.com/software/support/ and search by product
category, or by product name. For example, if you are experiencing problems specific to WebSphere
Application Server, click WebSphere Application Server in the product list. The WebSphere Application
Server Support page appears.

Administering application servers

An application server configuration provides settings that control how an application server provides
services for running enterprise applications and their components.

198 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
This section describes how to create and configure application servers in an existing application server
environment.

A WebSphere Application Server administrator can configure one or more application servers and perform
tasks such as the following:
1. Create application servers.
2. Manage application servers.
3. Configure transport chains.
4. Develop custom services.
5. Define processes for the application server. As part of defining processes, you can define:
6. Use the Java virtual machine.

After preparing a server, deploy an application or component on the server. See “Preparing to host
applications” on page 259 for a sample procedure that you might follow in configuring the application
server runtime and resources.

Application servers
Application servers extend a Web server’s capabilities to handle Web application requests, typically using
Java technology. An application server makes it possible for a server to generate a dynamic, customized
response to a client request.

For example, suppose--

1. A user at a Web browser on the public Internet visits a company Web site. The user requests to use
an application that provides access to data in a database.
2. The user request flows to the Web server.
3. The Web server determines that the request involves an application containing resources not handled
directly by the Web server (such as servlets). It forwards the request to a WebSphere Application
Server product.
4. The WebSphere Application Server product forwards the request to one of its application servers on
which the application is running.
5. The invoked application then processes the user request. For example:
v An application servlet prepares the user request for processing by an enterprise bean that performs
the database access.
v The application produces a dynamic Web page containing the results of the user query.
6. The application server collaborates with the Web server to return the results to the user at the Web
browser.

The WebSphere Application Server product provides multiple application servers that can be either
separately configured processes or nearly identical clones.

Understanding server templates

One step in the process of creating an application server is to specify a template. A server template is
used to define the configuration settings of the new server. You have the option of specifying the default
server template or choosing a template that is based on a server that already exists. The default template
will be used if you do not specify a different template when you create the server.

For information about creating server templates, see “Creating server templates” on page 201. For
information about listing server templates, see “Listing server templates” on page 201. For information
about deleting server templates, see “Deleting server templates” on page 201.

Chapter 3. Setting up the application serving environment 199

Creating application servers
For the Network Deployment and z/OS products, you can create a new application server using either the
createApplicationServer, createWebServer, or the createGenericServer wsadmin commands (see the
Administering applications and their environment PDF), or the Create New Application Server wizard in
the administrative console. You can also create a new application server when you add a cluster member
to a server cluster.

With WebSphere Application Server Version 6.0, you can now upgrade a portion of the nodes in a cell,
while leaving others at the older release level. This means that, for a period of time, you may be managing
servers that are at the current release and servers that are running the newer release in the same cell. In
this mixed environment, there are restrictions on what you can do with servers at the older release level.
They are:
v You can only create new server definitions on nodes that are running WebSphere Application Server
Version 6.0.
v When you create a new server definition, you must use a server configuration template, and that
template must be created from a WebSphere Application Server Version 6.0 server instance. You
cannot create (or use) a template from a WebSphere Application Server Version 5.x server instance.

There are no restrictions on what you can do with the servers running on the newer release level.

The steps below describe how to use the Create New Application Server page.
1. Go to the Application Servers page and click New. This brings you to the Create New Application
Server page. You can also create the new application server using the wsadmin
createApplicationServer command. For information, see “Commands for the AdminTask object” on
page 672.
2. Follow the instructions on the Create New Application Server page and define your application server.
a. Select a node for the application server.
b. Type in a name for the application server. The name must be unique within the node.
c. Select a template to be used in creating the new server. You can use a default application server
template for your new server or use an existing application server as a template. The new
application server will inherit all properties of the template server.
d. Select whether the new server will have unique ports for each HTTP transport. By default, this
option is enabled. If you select this option, you might need to update the alias list for the virtual
host that you plan to use with this server to contain these new port values. If you deselect this
option, ensure that the default port values do not conflict with other servers on the same physical
machine.
e. If you create the new server using an existing application server as a model, select whether to map
applications from the existing server to the new server. By default, this option is disabled.
3. To use multiple language encoding support in the administrative console, configure an application
server with UTF-8 encoding enabled.

The new application server appears in the list of servers on the Application Servers page.

Note that the application server created has many default values specified for it. An application server has
many properties that can be set and creating an application server on the Create New Application Server
page specifies values for only a few of the important properties. To view all of the properties of your
application server and to customize your application server further, click on the name of your application
server on the Application Servers page and change the settings for your application server as needed.

200 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Configuring application servers for UTF-8 encoding
To use multiple language encoding support in the administrative console, you must configure an
application server with UTF-8 encoding enabled.
1. Create an application server or use an existing application server.
2. On the Application Server page, click on the name of the server you want enabled for UTF-8.
3. On the settings page for the selected application server, under Server Infrastructure, click Java and
Process Management > Process Definition.
4. On the Process Definition page, click Java Virtual Machine.
5. On the Java Virtual Machine page, specify -Dclient.encoding.override=UTF-8 for Generic JVM
Arguments and click OK.
6. Click Save on the console task bar.
7. Restart the application server.

Note that the autoRequestEncoding option does not work with UTF-8 encoding enabled. The default
behavior for WebSphere Application Server is, first, to check if charset is set on content type header. If it
is, then the product uses content type header for character encoding; if it is not, then the product uses
character encoding set on server using the system property default.client.encoding. If charset is not
present and the system property is not set, then the product uses ISO-8859-1. Enabling
autoRequestEncoding on a Web module changes the default behavior: if charset it not present on an
incoming request header, the product checks the Accept-Language header of the incoming request and
does encoding using the first language found in that header. If there is no charset on content type header
and no Accept language header, then the product uses character encoding set on server using the system
property default.client.encoding. As with the default behavior, if charset is not present and the system
property is not set, then the product uses ISO-8859-1.

Creating server templates

The steps below describe how to create a server template.
1. In the administrative console, go to Servers --> Application Servers --> and then click Templates.
This brings you to the Server templates page.
Note that you can also create server templates using the createServerTemplate wsadmin command.
For more information, see the Administering applications and their environment PDF.
2. On the Server templates page, click New. This brings you to the Select a server page.
3. Select the server that you want to use to create the new template, then click OK. This brings you to
the Create new server template page.
4. On the Create new server template page, enter the name of the new template and, optionally, a
description, then click OK. This brings you to the Server templates page. You should see your new
template on the list.

Listing server templates

The step below describes how to list your server templates.

In the administrative console, go to Servers --> Application Servers --> and then click Templates. This
brings you to the Server templates page, which lists all of the existing templates.

Note that you can also list server templates using the listServerTemplates wsadmin command. For more
information, see the Administering applications and their environment PDF.

Deleting server templates

The steps below describe how to delete a server template.

Chapter 3. Setting up the application serving environment 201

1. In the administrative console, go to Servers --> Application Servers --> and then click Templates.
This brings you to the Server templates page.
Note that you can also delete server templates using the deleteServerTemplate wsadmin command.
For more information, see the Administering applications and their environment PDF.
2. On the Server templates page, select the template you want to delete, then click Delete. The template
you chose is removed from the list.

Managing application servers

To view information about an application server, use the Application Servers panel on the administrative
console.

You can use the Application Servers panel of the administrative console, the “Getting started with
scripting” on page 365, or command line tools such as startServer and stopServer to manage your
application servers.

Note: With WebSphere Application Server Version 6.0, you can now upgrade a portion of the nodes in a
cell, while leaving others at the older release level. This means that, for a period of time, you may
be managing servers that are at the current release and servers that are running the newer release
in the same cell. Note that in this mixed environment, there are some restrictions on what you can
do with servers that are running the older release level. There are no restrictions on what you can
do with the servers that are running on the newer release level. For details, see “Creating
application servers” on page 200 and “Creating clusters” on page 271.
1. Access the Application Servers page. Click Servers > Application Servers in the console navigation
tree.
2. View information about application servers.
The Application Servers page lists application servers in the cell and the nodes holding the application
servers. The Network Deployment product also shows the status of the application servers. The status
indicates whether a server is started, stopped, or unavailable.
To view additional information about a particular application server or to further configure an application
server, click on the application server name under Name. This accesses the settings page for an
application server.
To view product information for an application server:
a. Verify that the application server is running.
b. Display the Runtime tab on the settings page for an application server.
c. Click Product Information.
The Product Information page displayed lists the WebSphere Application Server products installed for
the application server, the version and build levels for the products, the build dates, and any interim
fixes applied to the application server.

Note: You can also get this information by using the versionInfo command. For more information, see
″versionInfo command″ in the information center.
3. Create an application server.
a. Click Servers > Application Servers in the console navigation tree to access the Application
Servers page.
b. Click New, and follow the instructions on the Create New Application Server page.
4. Start your application server.
5. Monitor the running of application servers.
6. Stop your application server.
7. Delete an application server.

202 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
 a. Click Servers > Application Servers in the console navigation tree to access the Application
Servers page.
b. Place a checkmark in the check box beside an application server to delete it.
c. Click Delete.
d. Click OK to confirm the deletion.

Server collection
Use this page to view information about and manage application servers, generic servers, Java Message
Service (JMS) servers, and Web servers.

Application Servers

The Application Servers page lists the application servers in the cell. You can use this page to create new
application servers, create application server templates, or delete existing application servers. You can
also use this page to start and stop these application servers.

The Network Deployment product also shows the status of the application servers. The status indicates
whether a server is running, stopped, or encountering problems.

To view this administrative console page, click Application Servers.

Generic Servers

The Generic Servers page lists the generic servers in the cell. You can use this page to create new
generic servers, create generic server templates, or delete existing generic servers. You can also use this
page to start and stop these generic servers.

The Network Deployment product also shows the status of the generic servers. The status indicates
whether a server is running, stopped, or encountering problems.

You can use this page to add or delete application servers.

To view this administrative console page, click Generic Servers.

Java Message Service (JMS) Servers

The JMS Servers page lists the JMS servers in the cell. You can use this page to start and stop these
JMS servers.

Each JMS server provides the functions of the JMS provider for a node in your administrative domain.
There can be at most one JMS server on each node in the administration domain, and any application
server within the domain can access JMS resources served by any JMS server on any node in the
domain.

Note: JMS servers apply only to WebSphere Application Server Version 5.x nodes. You cannot create a
JMS server on a node that is running WebSphere Application Server 6.0, but the existing Version
5.x JMS servers will continue to be displayed, and you can modify their properties. You can also
delete Version 5.x JMS servers.

To view this administrative console page, click JMS Servers.

Web Servers

Chapter 3. Setting up the application serving environment 203

The Web Servers page lists the Web servers in your administrative domain. You can use this page to
generate and propagate a Web server plug-in configuration file, create new Web servers, create new Web
server templates, or delete existing Web servers. You can also use this page to start and stop these Web
servers.

To view this administrative console page, click Web Servers.

Name:

Specifies a logical name for the server. For WebSphere Application Server, server names must be unique
within a node.

Node:

Specifies the name of the node holding the server.

Version:

Specifies the version of the WebSphere Application Server product on which the server runs.

Status:

Indicates whether the server is started or stopped. (Network Deployment only)

Note that if the status is Unavailable, the node agent is not running in that node and you must restart the
node agent before you can start the server.

Application server settings:

An application server is a server which provides services required to run enterprise applications. Use this
page to view or change the settings of an application server instance.

To view this administrative console page, click Servers > Application Servers >server_name.

On the Configuration tab, you can edit fields. On the Runtime tab, you can look at read-only information.
The Runtime tab is available only when the server is running.

Name:

Specifies a logical name for the server. Server names must be unique within a node. However, for multiple
nodes within a cluster, you may have different servers with the same server name as long as the server
and node pair are unique.

For example, a server named server1 in a node named node1 in the same cluster with a server named
server1 in a node named node2 is allowed. Configuring two servers named server1 in the same node is
not allowed. WebSphere Application Server uses the server name for administrative actions, such as
referencing the server in scripting.

Data type String

Default server1

Run in development mode:

204 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Enabling this option may reduce the startup time of an application server. This may include JVM settings
such as disabling bytecode verification and reducing JIT compilation costs. Do not enable this setting on
production servers. This setting is only available on application servers running WebSphere Application
Server Version 6.0 and later.

Specifies that you want to use the JVM settings -Xverify and -Xquickstart on startup. After selecting this
option, save the configuration and restart the server to activate development mode.

The default setting for this option is false, which indicates that the server will not be started in
development mode. Setting this option to true specifies that the server will be started in development
mode (with settings that will speed server startup time).

Data type Boolean

Default false

Parallel start:

Select this field to start the server on multiple threads. This might shorten the startup time.

Specifies that you want the server components, services, and applications to start in parallel rather than
sequentially.

The default setting for this option is true, which indicates that the server be started using multiple threads.
Setting this option to false specifies that the server will not be started in using multiple threads (which
may lengthen startup time).

Note that the order in which the applications start depends on the weights you assigned to each them.
Applications that have the same weight are started in parallel. You set an application’s weight with the
Starting weight option on the Applications > Enterprise Applications > application_name page of the
Administrative Console. For more information about the Starting weight option, see the Installing your
application serving environment PDF.

Data type Boolean

Default true

Class loader policy:

Select whether there is a single class loader to load all applications or a different class loader for each
application.

Class loading mode:

Specifies whether the class loader should search in the parent class loader or in the application class
loader first to load a class. The standard for Developer Kit class loaders and WebSphere Application
Server class loaders is Parent first.

If you select Parent last, your application can override classes contained in the parent class loader, but
this action can potentially result in ClassCastException or linkage errors if you have mixed use of
overridden classes and non-overridden classes.

Process Id:

The native operating system’s process ID for this server.

The process ID property is read only. The system automatically generates the value.

Chapter 3. Setting up the application serving environment 205

Cell name:

The name of the cell in which this server is running.

The Cell name property is read only.

Node name:

The name of the node in which this server is running.

The Node name property is read only.

State:

The run-time execution state for this server.

The State property is read only.

Ports collection:

Use this page to view and manage communication ports used by run-time components running within a
process. Communication ports provide host and port specifications for a server.

To view this administrative console page, click Servers > Application Servers >server_name
Communications > Ports.

Note that this page displays only when you are working with ports for application servers.

Port Name:

Specifies the name of a port. Each name must be unique within the server.

Host:

Specifies the IP address, domain name server (DNS) host name with domain name suffix, or just the DNS
host name, used by a client to request a resource (such as the naming service, or administrative service).

Port:

Specifies the port for which the service is configured to accept client requests. The port value is used in
conjunction with the host name.

Transport Details:

Provides a link to the transport chains associated with this port. If no transport chains are associated with
this port, the string ″No associated transports″ appears in this column.

Ports settings:

Use this to view and change the configuration for a communication port used by run-time components
running within a process. A communication port provides host and port specifications for a server.

For WebSphere Application Server for Network Deployment, you can view this administrative console page
by clicking one of the following paths:
v Servers > Application Servers >server_name > Ports >port_name
v Servers > JMS Servers >server_name > Security Port Endpoint
v Servers > JMS Servers >server_name > Ports >port_name

206 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Port Name:

Specifies the name of the port. The name must be unique within the server.

Note that this field displays only when you are defining a port for an application server. You can select a
radio button to:
Well-known Port
select a previously defined port from the drop down list
User-defined Port
create a port with a new name by entering the name in the text box

Data type String

Host:

Specifies the IP address, domain name server (DNS) host name with domain name suffix, or just the DNS
host name, used by a client to request a resource (such as the naming service, administrative service, or
JMS broker).

For example, if the host name is myhost, the fully qualified DNS name can be myhost.myco.com and the IP
address can be 155.123.88.201.

Host names on the ports can be resolvable names or IP addresses. The server will bind to the specific
host name or IP address that is supplied. That port will only be accessible through the IP address that is
resolved from the given host name or IP address. The IP address may be of the IPv4 (Internet Protocol
Version 4) format for all platforms, and IPv6 (Internet Protocol Version 6) format on specific operating
systems where the server supports IPv6.

Data type String

Default * (asterisk)

Port:

Specifies the port for which the service is configured to accept client requests. The port value is used in
conjunction with the host name.

Port numbers in the server can be reused among multiple ports as long as they have host names that
resolve to unique IP addresses and there is not a port with the same port number and a wildcard ( * ) host
name. A port number is valid in the range of 0 and 65535. 0 specifies that the server should bind to any
ephemeral port available.

Data type Integer

Default None
Range 1-65536

Custom property collection:

Use this page to view and manage arbitrary name-value pairs of data, where the name is a property key
and the value is a string value that can be used to set internal system configuration properties.

The administrative console contains several Custom Properties pages that work similarly. To view one of
these administrative pages, click a Custom Properties link.

Name:

Chapter 3. Setting up the application serving environment 207

Specifies the name (or key) for the property.

Do not start your property names with was. because this prefix is reserved for properties that are
predefined in WebSphere Application Server.

Value:

Specifies the value paired with the specified name.

Description:

Provides information about the name-value pair.

Custom property settings:

Use this page to configure arbitrary name-value pairs of data, where the name is a property key and the
value is a string value that can be used to set internal system configuration properties. Defining a new
property enables you to configure a setting beyond that which is available in the administrative console.

For Network Deployment and the z/OS platform, you can view this administrative console page by clicking
one of the following paths:
v Servers > Application Servers >server_name. Then, under Server Infrastructure, click Administration
> Custom Properties
v Servers >JMS Servers > server_name. Then, under Server Infrastructure, click Administration >
Custom Properties

Name:

Specifies the name (or key) for the property.

Do not start your property names with was. because this prefix is reserved for properties that are
predefined in WebSphere Application Server.

Data type String

Value:

Specifies the value paired with the specified name.

Data type String

Description:

Provides information about the name and value pair.

Data type String

Server component collection:

Use this page to view information about and manage server component types such as application servers,
messaging servers, or name servers.

To view this administrative console page, click Servers > Application Servers >server_name. Then,
under Server Infrastructure, click Administration > Server Components.

208 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
Type:

Specifies the type of internal server.

Server component settings:

Use this page to view or configure a server component instance.

To view this administrative console, click Servers > Application Servers >server_name. Then, under
Server Infrastructure, click Administration > Server Components >server_component_name.

Name:

Specifies the name of the component.

Data type String

Initial State:

Specifies the desired state of the component when the server process starts. The options are: Started and
Stopped. The default is Started.

Data type String

Default Started

Thread pool collection:

Use this page to select or create a group of threads that an application server uses. Requests are sent to
the server through any of the HTTP transports. A thread pool enables components of the server to reuse
threads to eliminate the need to create new threads at run time. Creating new threads expends time and
resources.

To view this administrative console page, click Servers > Application Servers >server_name > Thread
Pools. (You can reach this page through more than one navigational route.)

Thread pool settings:

Use this page to configure a group of threads that an application server uses. Requests are sent to the
server through any of the HTTP transport channels or HTTP transports. A thread pool enables components
of the server to reuse threads to eliminate the need to create new threads at run time. Creating new
threads expends time and resources.

To view this administrative console page, click Servers > Application Servers >server_name > Thread
Pools, then select the thread pool. (You can reach this page through more than one navigational route.)

Minimum size:

Specifies the minimum number of threads to allow in the pool.

Data type Integer

Default 10

Maximum size:

Specifies the maximum number of threads to allow in the pool.

Chapter 3. Setting up the application serving environment 209

If your Tivoli Performance Viewer shows the Percent Maxed metric to remain consistently in the double
digits, consider increasing the Maximum size. The Percent Maxed metric indicates the amount of time that
the configured threads are used. If there are several simultaneous clients connecting to the server-side
ORB, increase the size to support up to 1000 clients.

Data type Integer

Default 50
Recommended 50 (25 on Linux systems)

Thread inactivity timeout:

Specifies the number of milliseconds of inactivity that should elapse before a thread is reclaimed. A value
of 0 indicates not to wait and a negative value (less than 0) means to wait forever.

Note: The administrative console does not allow you to set the inactivity timeout to a negative number. To
do this you must modify the value directly in the server.xml file.

Data type Integer

Units Milliseconds
Default 3500

Allow thread allocation beyond maximum thread size:

Specifies whether the number of threads can increase beyond the maximum size configured for the thread
pool.

Data type Boolean

Default Not enabled (false)

Generic server settings:

Use this page to view or change the settings of a generic server.

A generic server is a server that is managed in the WebSphere Application Server administrative domain,
although it is not a server that is supplied by the WebSphere Application Server product. The generic
server can be any server or process that is necessary to support the Application Server environment,
including a Java server, a C or C++ server or process, or a Remote Method Invocation (RMI) server.

To view this administrative console page, click Servers > Generic Servers >server_name.

On the Configuration tab, you can edit fields. On the Runtime tab, you can look at read-only information.
The Runtime tab is available only when the server is running.

Name:

Specifies a logical name for the generic server.

Generic server names must be unique within a node. For multiple nodes within a cluster, you can have
different generic servers with the same server name as long as the server and node pair are unique. For
example, a server named server1 in a node named node1 in the same cluster with a server named
server1 in a node named node2 is allowed. Configuring two servers named server1 in the same node is
not allowed. WebSphere Application Server uses the server name for administrative actions, such as
referencing the server in scripting.

210 IBM WebSphere Application Server Network Deployment, Version 6: Administering applications and their environment
It is highly recommended that you use a naming scheme that makes it easy to distinguish your generic
application servers from regular WebSphere Application Servers. This will enable you to quickly determine
whether to use the Terminate or Stop button in the administrative console to stop a specific application
server.

You must use the Terminate button to stop a generic application server.

Data type String

Default

Starting servers
Starting a server starts a new server process based on the process definition settings of the current server
configuration. The node agent for the node on which the Application Server resides must be running
before you can start the Application Server.

If you need to restart a server, follow the directions in this article for starting servers. The procedure that
applies to starting servers also applies to restarting servers.

Note: If you created a new server definition using a base WebSphere Application Server, you cannot start,
stop, or manage the new server using the original base Application Server.

Note: After you start an Application Server, other processes might not discover the running Application
Server immediately. Application Servers are discovered by the node agent. Node agents are
discovered by the deployment manager. Node agents usually can discover local Application Servers
quickly but it can take a deployment manager from 2 to 60 seconds to discover a node agent.

Note: If you are using clusters, note that the Initial State property of the Application Server
subcomponent (Servers > Application Server > server_name > Administration > Server
Components > Application Server) is not intended to be used to control the state of individual
servers in the cluster at the time the cluster is started. It is intended only as a way to control the
state of the Application Server subcomponent of a server. It is best to start and stop the individual
servers of a cluster using the Server options of the Administrative Console or command line
commands (startServer and stopServer).

There are several options for starting an Application Server:

v If you are using Windows, you can use the Start menu to start the Application Server. If you
are using the Network Deployment version of the product, click Start > Programs > IBM WebSphere >
Network Deployment v6.0 > Start the Manager You can check that the server has successfully
started by checking the startServer.log file. If the server has successfully started, the last two lines of
the startServer.log file reads:
Server launched. Waiting for initialization status.
Server server1 open for e-business; process id is 1932.
The startServer.log file is located in the <drive>:\Program
Files\IBM\WebSphe