IBM Web Server Plug-in Analyzer for WebSphere Application Server

A tool that detects improper or ill-advised WebSphere Application Server plug-in configurations and corresponding HTTP request/response failures.

What is IBM Web Server Plug-in Analyzer for WebSphere Application Server? 

IBM® Web Server Plug-in Analyzer for WebSphere® Application Server helps discover potential problems with trace and configuration files during use of WebSphere Application Server. The tool parses both plug-in configuration and corresponding trace files and then applies pattern recognition algorithms in order to alert users of possible inconsistencies. 

The tool provides a list of HTTP return codes, URI and graphical presentations of available clusters, and server topologies from the configuration and trace files. 

The primary automatic capabilities of this tool are as follows: 

detection of incorrect or potentially problematic configurations that could cause service interruption or performance degradation 
identification of request failure or response failure 
HTTP return code tracking 
URI failure tracking 
graphical presentation of WebSphere Application Server and cluster topology 
cluster and cluster member tracking. 
The package includes the stand-alone code, documentation, and license files. 

How does it work?

The tool parses WebSphere Application Server plug-in configuration files and trace files. Based on results obtained from a pattern recognition engine, IBM Web Server Plug-in Analyzer provides information about any potential problems within the configuration. 
The pattern recognition engine maintains various patterns of configurations that are not usually recommended and provides warnings if these same patterns are detected in the configuration files. 

The tool takes the following approach: 

It parses configuration files. 
It provides warnings or clues to information when configurations appear to be set inappropriately. 
It collects WebSphere Application Server cluster and member topology information within the configuration file. 
It displays a visual mapping of the cluster and member topology. 
It parses the plug-in trace files and creating models based on HTTP request/response header/body information, HTTP return code, URI, start/end time, cluster name, and server name. 
It displays the requested trace information based on query. The trace information has HTTP return code analysis and HTTP request/response header/body analysis. 

References:
http://www.alphaworks.ibm.com/tech/wspa

Security Hardening of WebSphere Application Server Installations

It is a known fact that an out of the box a WAS installation with security enabled is not entirely secure. There is a number of steps that has to be taken in order to "harden" the installation. Most of the steps are documented in the WebSphere hardening guide, which should be closely studied and followed by any WAS administrator or developer. The hardening guide, however, is a little light on the specifics regarding how to secure WAS at the OS level. For example, hardening should normally include changing file and directory permissions to restrict access to sensitive configuration files.

Why bother hardening the installation at the OS level? This helps defend against external threats, i.e., a server hosting the installation is compromised and against internal threats, i.e., an unauthorized access from inside.

Here are some of the things you can do to secure your installation on a Unix/Linux platform:

•     If you installed WAS as a non-root account, make sure that this account is not part of the "users" group. Create a separate group for all administrators, say "wasadmins". If you're doing this the post-install, make sure that you changed the ownership of all WAS files and profiles. To do that, bring all WAS processes down and run chgrp -R wasadmins $WAS_INSTALL_ROOT.

•     Refrain from running WAS using root. There is no reason to do it on Unix/Linux, unless you absolutely have to use low ports. Yes, you can use sudo to tighten down access to root, but it is safer just to stay away from it. You can actually install WAS using root so it can be properly registered with the OS, but you can later change the installation to be owned by a non-root account.

•     Following the principle of least privilege, remove read access from "others". Why do you need to do it? There are many sensitive files that are part of WAS install, including files containing encoded passwords (see below). It's better to err on a side of caution and disallow general read access altogether. We should revoke execute access as well. On the other hand, we may want to grant write/execute to all members of wasadmins groups, assuming the membership in this group is going to be tightly controlled:

    chmod -R 770 $WAS_INSTALL_ROOT

•     You may want to allow access to logs to "others" so that developers can view logs. Since we just revoked read permissions from the root WAS install directory and from all profile directories, you can't just "chmod" the "logs" directory. You need to redirect logs to some other directory which is not under "$WAS_INSTLALL_ROOT" or profile roots. In order to do it, change LOG_ROOT WAS variable. You can do it from the console (Environment/WebSphere variables). By default, "LOG_ROOT" is defined at a node level. If the location is going to be the same on all nodes (which it should), just create LOG_ROOT at the cell level. You'll need to restart WAS servers after this. You can redirect logs to, say, /var/log/was. Make sure that "wasadmin" system account has write permissions to this directory.

•     Do not allow login to the system account used to run WAS. You can read this guide explaining how to do it for various login mechanisms. You also need to disable "sudo su wasadmin" and only allow sudo for the specific commands/scripts that are needed to run WAS. You will need to add something like this to the sudoers file:

    %wasadmins ALL=(wasadmin) WAS_INSTLALL_ROOT/bin/, PROFILE_ROOT/bin/
    This configuration allows all member of "wasadmins" group to run commands from "bin" using "sudo -u", e.g., sudo -u wasadmin ./startServer.sh server1.
    You may relax this a little bit by allowing sudo access without having to enter password every time:
    %wasadmins ALL=(wasadmin) NOPASSWD: WAS_INSTLALL_ROOT/bin/, PROFILE_ROOT/bin/
    It's a bit of a pain having to run all commands via sudo (although, of course, it can be scripted), but it gives you complete audit trail of who did what in the environment. By the way, by default sudo logs via syslog, but you can redirect sudo's log into its own file by adding this directive in sudoers:
    Defaults logfile=PATH_TO_LOG_FILE

•     Secure "sensitive" files. As any WAS administrator knows, passwords stored in WAS are not really encrypted, they are just encoded, so they can be decoded pretty easily (there is a way to plug in custom encryption, but that's a different story). Therefore, it is imperative to properly protect files containing encoded passwords. To do that, we're going to revoke any access to these files from "wasadmins" group. That way, only the "wasadmin" system account (which we can't even login into) or root can read these files. Encoded passwords are stored in "security.xml" and "wim/wimconfig.xml" (if you have LDAP configured). All these files reside under "$PROFILE_ROOT/config/cells/$CELL_NAME". "fileRegistry.xml" also contains passwords, although these passwords are properly encrypted.

You may also want to protect keystores (key.p12). Note that in addition to the cell key store, each node has its own keystore. You don't need to worry as much about trust stores (trust.p12), in fact it might be convenient to keep group-level access to trust stores so that administrators can modify them outside of WAS (e.g., by adding a signer cert using ikeyman). While you're on it, make sure that you don't use the default password (WebAS) for any of the keystores/truststores.

To revoke group access to any of the files mentioned above, just run "chmod 600" on them, e.g., chmod 600 security.xml. Note that you'll have to repeat it for each profile, including deployment manager and application server profiles (unless you have a standalone install).
    Node synchronization built into WAS fully supports changing permissions on config files. The changes will not disappear after node sync (provided you updated the DM profile).

•     If your environment has a DMZ utilizing IHS, make sure that you don't have WAS installation on the DMZ boxes. It is convenient to have node agents running on the IHS servers, so you can manage IHS from admin console, but, unfortunately, it is a security risk. Deployment manager pushes all configuration files, including "security.xml" to all nodes, and we certainly don't want this file sitting in the DMZ (even with "600" permissions).

•     Repeat all changes on every server containing WAS installation. You may want to script them or, better yet, use a tool like Puppet to automate OS-level configuration changes across multiple machines. For example, see this guide on how to centralize management of the sudoers file.

WebSphere MQ Security Vulnerability: potential buffer overflow on unsecured WebSphere MQ client connections

Abstract

WebSphere MQ Security Vulnerability: There is a potential buffer overflow which can occur when the MQ server is processing inbound data on a client connection.

Content

There is a potential buffer overflow which can occur when the MQ server is processing inbound data on a client connection.

This exposure applies to all WebSphere MQ V6 and higher queue managers and resolution will ship in 6.0.2.7 and 7.0.1.0. This issue is not present in releases prior to WebSphere MQ V6.

Links to associated interim fixes can be found here:
http://www.ibm.com/support/docview.wss?rs=171&uid=swg24023135

Vulnerability information:
http://xforce.iss.net/xforce/xfdb/50641

Unauthorized users are unable to exploit this on any queue manager which is secured with SSL and/or authentication security exits.

Specifying the userid in the SSL certificate label for an MQ client

Question

Does the standard WebSphere MQ SSL configuration require the personal certificates' label name with a special format as below?

WebSphere MQ Client: ibmwebspheremq + <User ID>
WebSphere MQ Server (queue manager): ibmwebspheremq + <QM Name>

Where the User ID or queue manager name must be folded to lower case in the label. For example, for a queue manager named QM1, the label is ibmwebspheremqqm1.

You want to know if you must comply with the rule for all of your MQ Clients, because you have many clients and it will be a big job to create unique certificates.
Cause

The original design and intent of MQ was that the answer to this question should be YES. It is still the intent that it is necessary to have a separate personal certificate with a label of 'ibmwebspheremq<username>' for each client connection. However, depending on what MQ maintenance level you are using, you may not see this working as designed in some circumstances. In certain scenarios, you may be able to get around the intended design.

Answer

The gsk6cmd command from GSKit provides -setdefault and -getdefault options to set or display a default certificate in a key repository. The behavior of this area of code has changed a few times, so here is a description of the expected behavior depending on your MQ maintenance level.

WebSphere MQ V5.3

    WebSphere MQ V5.3 CSD09 or earlier
    The default certificate will be used if: a default certificate is present, and there is no ibmwebspheremq certificate.
    This behavior was a defect which was corrected by APAR IC43762.
    WebSphere MQ V5.3 CSD10 through CSD12
    The default certificate will never be used. If you are at this level and require default certificate functionality, then you will need the fix for IC50156 and you must set the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable, as described in IC50156 APAR text.
    WebSphere MQ V5.3 CSD13 and later
    The default certificate will only be used if the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable is set, and the following conditions are both met: default certificate is present, and there is no ibmwebspheremq certificate

WebSphere MQ V6

    WebSphere MQ 6.0.0.0 through 6.0.1.1
    The default certificate will never be used. If you are at this level and require default certificate functionality, then you will need the fix for IC50156 and must set the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable.
    WebSphere MQ 6.0.2.0 and later
    The default certificate will only be used if the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable is set, and the following conditions are both met: default certificate is present, and there is no ibmwebspheremq certificate.

WebSphere MQ V7 & LATER Version

    WebSphere MQ 7.0.0.0 and later
    The default certificate will only be used if the AMQ_SSL_ALLOW_DEFAULT_CERT environment variable is set, and the following conditions are both met: default certificate is present, and there is no ibmwebspheremq certificate.


Notes:

1. All of the above holds true if you are using the MQ C client. If you are using MQ Java™ or MQ JMS clients the answer is NO, you do not need a unique certificate for every client userid. In the MQ Java and MQ JMS client environment the label is not used to do the certificate look up. However, a personal certificate for the queue manager end still needs a label of 'ibmwebspheremq<qmgrname>'.

2. The above information does not apply to platforms which do not use GSKit, such as z/OS for example or MQ v5.3 for Windows. MQ v6 for Windows does use GSkit, so the information is applicable on MQ V6 for Windows..

Warning:

Please note that the decision to remove default certificate support from WebSphere MQ was not made lightly, and was made for a number of security concerns. Although we have restored this in a limited way due to specific unique requests, this was not the functionality which we expected to see widely used. It is certainly not an approach which we recommend.

The administration of an SSL environment is something which we would advise you to consider carefully. Certificates are intended to provide a unique identification of a specific entity. The ability to establish a chain of trust from a trusted signer down to individual certificates allows for some of this administration to be delegated, however the use of default certificates makes it possible for far greater reuse and sharing of certificates to be achieved than is intended. In an extreme case, one default self-signed certificate could be used by every client and queue manager on a network, greatly increasing the risk of exposure to your network if the certificate becomes compromised.


If authentication of clients is not required, then you may find that setting SSLCAUTH to OPTIONAL in your channel definitions is a better solution for your needs. However, if authentication of clients is important, then you should consider whether wide reuse of a default certificate meets that need.

Basic Jython script to install an ear file

The script below will install on a local server. If Administrative security is on, then it will prompt for authentication.

#install the application
AdminApp.install('D:/workspace/java/jsfks/deploy/jsfks.ear', '[ -nopreCompileJSPs -distributeApp -nouseMetaDataFromBinary -nodeployejb -appname jsfks_test_ear -createMBeansForResources -noreloadEnabled -nodeployws -validateinstall warn -noprocessEmbeddedConfig -filepermission .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 -noallowDispatchRemoteInclude -noallowServiceRemoteInclude]' );
#save
AdminConfig.save();

Jython script to show WebSphere Application Server Cluster Status

Sample usage in unix:
wsadmin.sh -lang jython -f ./show_cluster_status.py <clusterName>
-----------------------------------------------------------------
possible improvement would be to check that cluster exists and that
a cluster name has been passed is as a command line paramter.
-----------------------------------------------------------------
i = 0
clusterName = sys.argv[i]
clusterId = AdminConfig.getid("/ServerCluster:"+clusterName+"/" )
print "ClusterName is: "+clusterName
if (len(clusterId) != 0):
clusterObject = AdminControl.completeObjectName("type=Cluster,name="+clusterName+",*" )
clusterStatus = AdminControl.getAttribute(clusterObject, "state" )
print "clusterStatus="+clusterStatus
running = "websphere.cluster.running"
partialstart = "websphere.cluster.partial.start"
starting = "websphere.cluster.starting"
stopped = "websphere.cluster.stopped"
if (cmp(clusterStatus, starting) == 0):
print "starting"
sys.exit()
#endIf
if (cmp(clusterStatus, stopped) == 0):
print "stopped"
sys.exit()
#endIf
if (cmp(clusterStatus, running) == 0):
print "running"
sys.exit()
#endIf
if (cmp(clusterStatus, partialstart) == 0):
print "partialstart "
sys.exit()
#endIf

else:
print "Error"
#endElse

Jython script to list all AdminApp commands

result=AdminApp.help()

print result

---------------- RESULT ------------------

WASX7209I: Connected to process "server1" on node T60Node03 using SOAP connector; The type of process is: UnManagedProcess

WASX7095I: The AdminApp object allows application objects to

be manipulated -- this includes installing, uninstalling, editing,

and listing. Most of the commands supported by AdminApp operate in two

modes: the default mode is one in which AdminApp communicates with the

WebSphere server to accomplish its tasks. A local mode is also

possible, in which no server communication takes place. The local

mode of operation is invoked by bringing up the scripting client with

no server connected using the command line "-conntype NONE" option

or setting the "com.ibm.ws.scripting.connectionType=NONE" property in

the wsadmin.properties.

The following commands are supported by AdminApp; more detailed

information about each of these commands is available by using the

"help" command of AdminApp and supplying the name of the command

as an argument.

deleteUserAndGroupEntries

Deletes all the user/group information for all

the roles and all the username/password information for RunAs

roles for a given application.

edit Edit the properties of an application

editInteractive Edit the properties of an application interactively

export Export application to a file

exportDDL Export DDL from application to a directory

help Show help information

install Installs an application, given a file name and an option string.

installInteractive

Installs an application in interactive mode, given a

file name and an option string.

isAppReady Checks whether the application is ready to be run

list List all installed applications

listModules List the modules in a specified application

options Shows the options available, for a given file, application,

or in general.

publishWSDL Publish WSDL files for a given application

searchJNDIReferences

List application that refer to the given JNDIName on a given node

taskInfo Shows detailed information pertaining to a given install task

for a given file

uninstall Uninstalls an application, given an application name and

an option string

update Updates an installed application

updateAccessIDs Updates the user/group binding information with accessID

from user registry for a given application

updateInteractive Updates an installed application interactively

view View an application or module,

given an application or module name

Changing a Node name in WebSphere

To change the name of a given node, use the following wsadmin command:
AdminTask.renameNode(‘[-nodeName <existing_node_name> -newNodeName <new_node_name>]‘)
This updates the name of the node specified by the nodeName parameter to the name specified by the newNodeName parameter.
Here is an example:
I have a cell where I wish to change the name of the deployment manager's node to dmgrnode01 as opposed to node01
The jython script I created has:
AdminTask.renameNode('[-nodeName node01 -newNodeName dmgrnode01]')


I am running the script from the <was_install_root</bin folder and the command to run the script is
./wsadmin.sh -lang jython -f /root/scripts/changeNodeName.py

How to delete and re-add a federated node with different ports

./removeNode.sh -help
Usage: removeNode [-force] [-quiet] [-nowait] [-logfile <filename>]
[-replacelog] [-trace] [-username <username>] [-password <password>]
[-profileName <profile>] [-help]
An example could be that a node was federated with the wrong ports and you may want to remove the node to correctly federate with a port offset. Looking at the node configuration in the administrative client I have ports that are not in the rage I want.



Removing Node:
./removeNode.sh -profileName node01 -username wasadmin -password wasadmin
ADMU0116I: Tool information is being logged in file
/var/apps/was61/node61_01/profiles/logs/removeNode.log
ADMU0128I: Starting tool with the node01 profile
ADMU2001I: Begin removal of node: node61_01
ADMU0009I: Successfully connected to Deployment Manager Server:
dmgr61.webspheretools.com:10004
ADMU0505I: Servers found in configuration:
ADMU0506I: Server name: nodeagent
ADMU2010I: Stopping all server processes for node node61_01
ADMU0510I: Server nodeagent is now STOPPED
ADMU2021I: Removing all servers on this node from all clusters in the cell.
ADMU2014I: Restoring original configuration.
ADMU2017I: The local original configuration has been restored.
ADMU9990I:
ADMU0306I: Note:
ADMU2031I: Any applications that were uploaded to the cell61 cell configuration
during addNode using the -includeapps option are not uninstalled by
removeNode.
ADMU0307I: You might want to:
ADMU2032I: Use wsadmin or the Administrative Console to uninstall any such
applications from the Deployment Manager.
ADMU9990I:
ADMU9990I:
ADMU0306I: Note:
ADMU2033I: Any buses that were uploaded to the cell61 cell configuration during
addNode using the -includebuses option are not uninstalled by
removeNode.
ADMU0307I: You might want to:
ADMU2034I: Use wsadmin or the Administrative Console to uninstall any such
buses from the Deployment Manager.
ADMU2024I: Removal of node node61_01 is complete.

Re-adding the node with a port offset

./addNode.sh dmgr61.<your_domain.com> 10004 -profileName node01 -username wasadmin -password wasadmin -startingport 11000
Result:
./addNode.sh dmgr61.webspheretools.com 10004 -profileName node01 -username wasadmin -password wasadmin -startingport 11000
ADMU0116I: Tool information is being logged in file
/var/apps/was61/node61_01/profiles/logs/addNode.log
ADMU0128I: Starting tool with the node01 profile
CWPKI0309I: All signers from remote keystore already exist in local keystore.
ADMU0001I: Begin federation of node node61_01 with Deployment Manager at
dmgr61.webspheretools.com:10004.
ADMU0001I: Begin federation of node node61_01 with Deployment Manager at
dmgr61.webspheretools.com:10004.
ADMU0009I: Successfully connected to Deployment Manager Server:
dmgr61.webspheretools.com:10004
ADMU0507I: No servers found in configuration under:
/var/apps/was61/node61_01/profiles/config/cells/node61_01/nodes/node61_01/servers
ADMU2010I: Stopping all server processes for node node61_01
ADMU0024I: Deleting the old backup directory.
ADMU0015I: Backing up the original cell repository.
ADMU0012I: Creating Node Agent configuration for node: node61_01
ADMU0014I: Adding node node61_01 configuration to cell: cell61
ADMU0016I: Synchronizing configuration between node and cell.
ADMU0018I: Launching Node Agent process for node: node61_01
ADMU0020I: Reading configuration for Node Agent process: nodeagent
ADMU0022I: Node Agent launched. Waiting for initialization status.
ADMU0030I: Node Agent initialization completed successfully. Process id is:
31996
ADMU9990I:
ADMU0300I: The node node61_01 was successfully added to the cell61 cell.
ADMU9990I:
ADMU0306I: Note:
ADMU0302I: Any cell-level documents from the standalone cell61 configuration
have not been migrated to the new cell.
ADMU0307I: You might want to:
ADMU0303I: Update the configuration on the cell61 Deployment Manager with
values from the old cell-level documents.
ADMU9990I:
ADMU0306I: Note:
ADMU0304I: Because -includeapps was not specified, applications installed on
the standalone node were not installed on the new cell.
ADMU0307I: You might want to:
ADMU0305I: Install applications onto the cell61 cell using wsadmin $AdminApp or
the Administrative Console.
ADMU9990I:
ADMU0003I: Node node61_01 has been successfully federated.



I could have used a ports definition file to specify actual ports, but you need to know all the port names required and takes time to set-up. In a large enterprise you would use a portsdef.props file.

WebSphere change Hostname

To change the host name for a given node, use the following wsadmin command:
AdminTask.changeHostName(‘[-nodeName <node_name> -hostName <new_host_name>]‘)

This updates the host name for the node specified in the nodeName parameter to the value specified in the hostName parameter.
These commands update all of the necessary WAS configuration, but do keep in mind they do not update any shell or batch files in the environment. This means you need to update the setupCmdLine script included in your WAS installation, and you obviously need to update any of your custom scripts that have hard coded values for cell, node, and host names.

Best way to log a WebSphere silent install

install -options "/opt/IBM/WebSphere/silentFiles/myresponsefile.txt" 

-silent -log # !/opt/IBM/WebSphere/myOptionFiles/log.txt @ALL

Applying a WebSphere 7 Fixpack

This example is for windows, but for 'Nix it is much the same process
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27014463#70011
We will have to go to fix central and download the latest FixPack



7.0.0-WS-WAS-WinX32-FP0000011.pak

To actually install the WebSphere Fixpack, it is required that the latest WebSphere update installer be used to apply the fix pack



Download update installer


=====================
Steps to apply Fix Pack 11 to WebSphere for Windows
Unpack the Fixpack (if required)
Install the latest version of the Update Installer


Accept License Agreement


The system prerequisite check will be run to ensure that the required environment is ready for an install


Select the appropriate installation directory


You will be presented with an installation summary click next


Click Finish as shown below



===============================

Applying the actual FixPack.
Before installing the FixPack, make sure that all the local WebSphere Services are not running.


Once run the Update installer will wish to know the root location of you WebSphere installation, ensure that it has guessed correctly.


Click Next and select Install Maintenance Package


You will be presented with the path to the maintenance packages, you can leave the default and copy in the fixpx.pk file to this location or browse for the actual fix pack.


I choose to move the downloaded pak file to the maintenance folder.


The following screen informs the user that The WebSphere profile will also be updated. Be mindful of other WebSphere feature packs,


In this case since I was using Windows 7 there was an issue with updating files?




Installation Complete

Update installation unsuccessful: The following maintenance package could not be installed:

• 7.0.0-WS-WAS-WinX32-FP0000011 - WebSphere Application Server 7.0.0.11 FixPack

on the following product:

• IBM WebSphere Application Server
  C:/WAS7/AppServer

For more information, refer to the following log file:

• C:\WAS7\AppServer\logs\update\7.0.0-WS-WAS-WinX32-FP0000011.install\updatelog.txt

Click Relaunch to reinstall or remove the maintenance package, or click Finish to exit the wizard.

Looking at the log...
19-Oct-2010 10:24:24), Install, com.ibm.ws.install.ni.ismp.actions.InstallNIFMaintenance, err, mkdirs failed for: file:/C:/WAS7/AppServer/systemApps/isclite.ear/isclite.war/WEB-INF/com.ibm.ws.console.sibws.sibusresources.wss/WEB-INF
(19-Oct-2010 10:24:24), Install, com.ibm.ws.install.ni.ismp.actions.InstallNIFMaintenance, err, The file systemApps/isclite.ear/isclite.war/WEB-INF/com.ibm.ws.console.sibws.sibusresources.wss/WEB-INF/web.xml could not be replaced.
(19-Oct-2010 10:24:24), Install, com.ibm.ws.install.ni.ismp.actions.InstallNIFMaintenance, err, com.ibm.ws.install.ni.framework.fileactions.NIFFileActionIOException: The file systemApps/isclite.ear/isclite.war/WEB-INF/com.ibm.ws.console.sibws.sibusresources.wss/WEB-INF/web.xml could not be replaced.
Windows popped up this dialog.



Solution
http://www-01.ibm.com/support/docview.wss?rs=1079&uid=swg21230924
Make the WebSphere Service Manual and restart the machine, and then re-try

=================================
Once installed it is a good habit to run versionInfo.bat
c:\WAS7\AppServer\bin>versionInfo.bat
WVER0010I: Copyright (c) IBM Corporation 2002, 2005, 2008; All rights reserved.
WVER0012I: VersionInfo reporter version 1.15.1.26, dated 8/9/08
--------------------------------------------------------------------------------
IBM WebSphere Application Server Product Installation Status Report
--------------------------------------------------------------------------------

Report at date and time 19 October 2010 11:39:08 BST
Installation
--------------------------------------------------------------------------------
Product Directory C:\WAS7\AppServer
Version Directory C:\WAS7\AppServer\properties\version
DTD Directory C:\WAS7\AppServer\properties\version\dtd
Log Directory C:\WAS7\AppServer\logs
Backup Directory C:\WAS7\AppServer\properties\version\nif\backup
TMP Directory C:\Users\SteveR\AppData\Local\Temp
Product List
--------------------------------------------------------------------------------
BASE installed
Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere Application Server
Version 7.0.0.11
ID BASE
Build Level cf111021.10
Build Date 5/27/10
--------------------------------------------------------------------------------
End Installation Status Report
--------------------------------------------------------------------------------

c:\WAS7\AppServer\bin>