WebSphere Application Server Concepts For Sametime Users

Lotus ®
Version 1
Overview of IBM WebSphere

Application Server Concepts for IBM
Lotus Sametime Administrators

Overview of IBM WebSphere Application Server Concepts for
IBM Lotus Sametime Administrators
This document covers several WebSphere® Application Server concepts that come into play when
administering IBM® Lotus® Sametime®, such as terminology, common commands, and the servers
involved in a WebSphere Application Server deployment.
Time required
It should take approximately 80 minutes to complete this content.
Prerequisites and system requirements
There are no prerequisites or system requirements for this content. No prior WebSphere Application
Server knowledge is required.
Learning topics
The following learning topics are covered:

v Define terminology related to WebSphere Application Server architecture.
v Describe the function of a WebSphere Application Server Profile.
v Define WebSphere Application Server terminology related to Lotus Sametime topologies.
v Describe the key WebSphere Application Server profiles related to Lotus Sametime.
v Define which types of server components are installed in relation to other WebSphere Application
Server components.
v Discuss the WebSphere Application Server setting inheritance model, also known as resource scope.
v Start and stop WebSphere Application Servers using several methods.
v Log on to the WebSphere Application Server administrative console.
v Check the status of the server using the serverStatus command.
v Describe the servers that comprise a WebSphere Application Server environment.
v Describe the function of the WebSphere Application Server's Deployment Manager.
v Define WebSphere Application Server types in the context of Sametime.
v Explain the function of Deployment Manager and Integrated Solutions Console in the context of
Sametime.
v Troubleshoot issues with accessing Sametime System Console.
v Use WASServiceCmd utility to set up Sametime servers to load as Windows services
Agenda
Read through each of the sections in the order that they are listed in the following table:
Title Approximate Timing (in minutes)

“IBM WebSphere Application Server Terminology” on page 2 30
“Common WebSphere Application Server commands” on page 19 30
“WebSphere Application Server types in the context of Lotus 20
Sametime” on page 23
Total: 80
1
IBM WebSphere Application Server Terminology
In this document you will learn about IBM WebSphere Application Server terminology and how it is
used in an IBM Lotus Sametime environment.
Time needed
It will take approximately 30 minutes to complete this content.
Objectives
After reading this document, you should be able to:

v Define terminology related to WebSphere Application Server architecture.
v Describe the function of a WebSphere Application Server Profile.
v Define WebSphere Application Server terminology related to Lotus Sametime topologies.
v Describe the key WebSphere Application Server profiles related to Lotus Sametime.
v Define which types of server components are installed in relation to other WebSphere Application
Server components.
v Discuss the WebSphere Application Server setting inheritance model, also known as resource scope.
The ABC's of IBM WebSphere Application Server

In this section, you will learn about commonly used WebSphere Application Server architectural terms.
The following diagram shows one possible architecture of a WebSphere Application Server environment:
2 Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators
Below, you will find definitions for each of the terms shown in the graphic above.
Application Server
According to the WebSphere Application Server Glossary, an application server is "a server program
in a distributed network that provides the execution environment for an application program."
More specifically:
The application server is the primary runtime component in all configurations and is where
an application actually executes. All WebSphere Application Server configurations can have
one or more application servers. ... With Network Deployment, you can build a distributed
server environment consisting of multiple application servers maintained from a central
administration point. In a distributed server environment, you can cluster application
servers for workload distribution.
Source: WebSphere Application Server V6 Technical Overview

Cell
Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators 3
The WebSphere Application Server Glossary defines a cell as: "A group of managed processes that
are federated to the same deployment manager and can include high-availability core groups."
The IBM Redbooks® publication WebSphere Application Server V7: Concepts, Planning, and design
provides the following, more detailed, explanation:
A cell is a grouping of nodes into a single administrative domain. ... In a Network

Deployment environment, a cell can consist of multiple nodes (and node groups), which are
all administered from a single point, the deployment manager. If your cell configuration
contains nodes running on the same platform, it is called a homogeneous cell. It is also
possible to have a cell made up of nodes on mixed platforms. This is referred to as a
heterogeneous cell.
Cluster
A cluster is defined as "a group of application servers that collaborate for the purposes of
workload balancing and failover" in the WebSphere Application Server Glossary.
In other words:
... A cluster is a logical collection of application server processes that provides workload
balancing and high availability. Application servers that belong to a cluster are members of
that cluster and must all have identical application components deployed on them. Other
than the applications configured to run on them, cluster members do not have to share any
other configuration data. For example, one cluster member might be running on a large
multi-processor server while another member of that same cluster might be running on a
small mobile computer. The server configuration settings for each of these two cluster
members is very different, except in the area of the application components that are
assigned to them. In that area of configuration, they are identical. The members of a cluster
can be located on a single node (vertical cluster), across multiple nodes (horizontal cluster),
or on a combination of the two. When you install, update, or delete an application, the
updates are automatically distributed to all members in the cluster.

Deployment Manager
A Deployment Manager is "a server that manages operations for a logical group or cell of other
servers," as stated in the WebSphere Application Server Glossary.
A more detailed explanation is that the deployment manager is:
... the central administration point of a cell that consists of multiple nodes and node groups
in a distributed server configuration. ... The deployment manager uses the node agent to
manage the application servers within one node. A deployment manager provides
management capability for multiple federated nodes and can manage nodes that span
multiple systems and platforms. A node can only be managed by a single deployment
manager and must be federated to the cell of that deployment manager. The configuration
and application files for all nodes in the cell are centralized into a master configuration
repository. This centralized repository is managed by the deployment manager and
synchronized with local copies that are held on each of the nodes.
Source: WebSphere Application Server V7: Concepts, Planning, and design

Node
As defined in the WebSphere Application Server Glossary, a node is "a logical grouping of
managed servers."
In particular:
A node is an administrative grouping of application servers for configuration and
operational management within one operating system instance (virtualization allows
multiple operating systems on one machine). It is possible to create multiple nodes inside
one operating system instance, but a node cannot leave the operating system boundaries. In
a stand-alone application server configuration, there is only one node. With Network
Deployment, you can configure a distributed server environment consisting of multiple
nodes, which are managed from one central administration server.

Node Agent
A Node Agent is "an administrative agent that manages all application servers on a node and
represents the node in the management cell" according to the WebSphere Application Server
Glossary
In addition:
In distributed server configurations, each node has a node agent that works with the
deployment manager to manage administration processes... A node agent is created
automatically when you add (federate) a stand-alone node to a cell. It is not included in the
Base and Express® configurations.

In simpler terms, the node agent's purpose is to pass information between the deployment
manager and the application server.
Profile
A profile is "an instance of a WebSphere Application Server configuration."
More specifically:
Profiles are collections of user files. They share core product files. A profile contains its own set of
scripts, its own environment, and its own repository. Each profile is stored in a unique directory
path selected by the user at profile creation time. Profiles are stored in a subdirectory of the
installation directory by default, but they can be located anywhere.
WebSphere Profiles were introduced in WebSphere Application Server v6.0. One main advantage
of profiles is that they allow an administrator to have multiple application servers on a single
machine that all use the same binaries from one install of WebSphere Application Server.
Administration is greatly enhanced when using profiles instead of multiple product installations.
Not only is disk space saved, but updating the product is simplified when you maintain a single
set of product core files. Also, creating new profiles is more efficient and less prone to error than
full product installations, allowing a developer to create separate profiles of the product for
development and testing.
Templates for several types of profiles are provided with WebSphere Application Server Network
Deployment:
v Cell
– This environment creates two profiles:
- A management profile with a deployment manager
- An application server profile added (federated) to the management profile
v Management
– A management profile provides components for managing multiple application server
environments. Possible profiles are as follows:
- Deployment manager
- Administrative agent
- Job manager
v Application server
– An application server profile runs your enterprise applications and makes them available to
the internet or to an intranet. It contains a stand-alone application server.
v Custom
– A custom profile contains an empty node with no servers. However, a server can be added
after the profile is created.
v Secure proxy (configuration-only)
– A secure proxy (configuration-only) profile is for use with a DeMilitarized Zone (DMZ)
secure proxy server. This configuration-only profile is intended only to be used to configure
the profile using the Integrated Solutions Console. After you configure the profile, you can
export the profile configuration and then import it into the secure proxy profile in your
DMZ. Secure proxy (configuration-only) profile is only an administrative component.
For more information on profiles, watch the IBM Education Assistant module WebSphere Profiles
The following screen capture shows where profiles, cells, nodes, and servers are found in a
simple WebSphere Application Server deployment with no Lotus products installed:
Note: The colors of the boxes correspond to the color scheme of the first graphic.
The following screen capture shows where profiles, cells, nodes, and servers are found in a
WebSphere Application Server deployment, with no Lotus products installed, that uses a
Deployment Manager:
Note: The colors of the boxes correspond to the color scheme of the first graphic.
WebSphere Application Server terminology in the context of Lotus

Sametime
In this part you will learn how the WebSphere Application Server components that you learned about in
the previous part come into play with the Lotus Sametime System Console, Lotus Sametime Meeting
Server, Lotus Sametime Proxy Server, and the Sametime Media Manager.
You will explore the following configurations of Lotus Sametime:

v Standalone environment (installed using the Cell Profile option)
v Vertical Cluster
v Horizontal Cluster
The following graphics show how profiles, cells, nodes, and servers are used in a WebSphere Application
Server configuration with Lotus Sametime installed:
In the first graphic, Lotus Sametime is installed using the Cell Profile option with all servers installed on
the same machine. When you select the Cell Profile option during the configuration of Lotus Sametime,
two profiles are created in each cell: a Deployment Manager profile, <server name>DMProfile and a
federated Application Server profile, <server name>PNProfile. In this configuration, the Application
Server is federated to the cell of the Deployment Manager.
In the second graphic, Lotus Sametime is installed using the Network Deployment option with horizontal
clustering configured. Horizontal clustering is the most commonly used clustering topology for Lotus
Sametime configurations. As described in the Lotus Sametime Information Center topic Clustering
Sametime servers for high enterprise availability, "A horizontal cluster contains multiple physical machines (or
nodes), each with one type of Sametime server. A horizontal cluster distributes the load across servers on
multiple machines as needed. The advantage of a horizontal cluster is that users can still use the
Sametime application even if one machine in the cluster fails." Although this graphic shows the Lotus
Sametime System Console as the deployment manager, the clustering guided activity can use any
deployment manager visible to the Lotus Sametime System Console within its own product, ie: A Lotus
Sametime Meetings server can only use a deployment manager that has been installed for a Lotus
Sametime Meetings server. Using the Lotus Sametime System Console as the deployment manager is the
configuration recommended by IBM Lotus Development.
In the third image, Lotus Sametime is installed using the Network Deployment option with vertical
clustering configured. The Lotus Sametime Information Center topic Clustering Sametime servers for high
enterprise availability defines a vertical cluster as follows:
v A vertical cluster contains multiple instances of one type of Sametime server hosted on the same
physical machine (or node).
v A vertical cluster distributes the load as appropriate across servers. Machine maintenance in a
vertical cluster is easier and more convenient because everything is on one machine.
As is the case with horizontal clustering, although this graphic shows the Lotus Sametime System
Console as the deployment manager, the clustering guided activity can use any deployment manager
visible to the Lotus Sametime System Console within its own product, ie: A Lotus Sametime Meetings
server can only use a deployment manager that has been installed for a Lotus Sametime Meetings server.
Using the Lotus Sametime System Console as the deployment manager is the configuration
recommended by IBM Lotus Development.
WebSphere Application Server Profiles in Lotus Sametime
As described previously in this document, a profile is "an instance of a WebSphere Application Server
configuration." Each Lotus Sametime server installation uses several WebSphere Application Server
profiles, as shown in the following table:
Table 1. Profiles used by Lotus Sametime servers
Lotus Sametime Server WebSphere Application Server profiles
Lotus Sametime System Console v STSCAppProfile
v STSCDMgrProfile
Lotus Sametime Meeting Server v serverNameMediaDMProfile
v serverNameMediaPNProfile
Lotus Sametime Proxy Server v serverNameMeetingDMProfile
v serverNameMeetingPNProfile
Lotus Sametime Media Manager v serverNameProxyDMProfile
v serverNameProxyPNProfile
The following graphic shows where these profiles are found at the Operating System level for a Cell
Profile configuration:
Keep the location of these profiles in mind when examining log and configuration files. The files
associated with the server that you are troubleshooting will be located under the profile for that server.
For example, if you are troubleshooting an issue with the Lotus Sametime System Console, then you
would look for the log and configuration files under the profile for the Lotus Sametime System Console
deployment manager profile. On a Microsoft Windows machine using the default installation directories,
the log files for the Lotus Sametime System console are located in the C:\Program Files\IBM\WebSphere\
AppServer\profiles\STSCDMgrProfile\logs\dmgr directory, as shown in the following screen capture:
Keep the same thoughts in mind when troubleshooting the configuration files for a particular server. For
example, if you are trying to solve a problem with the Lotus Sametime System Console, the only place
that you should need to make a change to a configuration file is in the Lotus Sametime System Console
deployment manager profile. The security.xml file is located in the C:\Program Files\IBM\WebSphere\
AppServer\profiles\STSCDMgrProfile\config\cells\<cell name> directory on a Microsoft Windows
machine using the default installation directories, as shown in the following screen capture:
The wimconfig.xml file is located in the C:\Program Files\IBM\WebSphere\AppServer\profiles\
STSCDMgrProfile\config\cells\<cell name>\wim\config directory on a Microsoft Windows machine
using the default installation directories, as shown in the following screen capture:
The Websphere Application Server components, such as clusters, nodes, and cells need to be taken into
account when configuring resources for Lotus Sametime. Certain settings can be configured at multiple
levels, or scopes, using the Lotus Sametime System Console. This concept is referred to as resource scope.
The IBM Redbooks Publication WebSphere Application Server V7: Concepts, Planning, and design describes
resource scope as follows:
Resource scope is a powerful concept to prevent duplication of resources across lower-level scopes.
For example, if a data source can be used by multiple servers in a node, it makes sense to define
that data source once at the node level, rather than create the data source multiple times, possibly
introducing errors along the way. Also, if the data source definition needs to change (maybe due to
changes to an underlying database), the data source definition can be changed once and is visible to
all servers within the node. The savings in time and cost should be self-evident. Some thought
needs to be put toward outlining what resources you will need for all the applications to be
deployed and at what scope to define each. You select the scope of a resource when you create it.
The following list describes the scope levels, listed in order of granularity with the most general
scope first:
Cell scope
The cell scope is the most general scope and does not override any other scope. [It is]
recommended that cell scope resource definitions should be further granularized at a more
specific scope level. When you define a resource at a more specific scope, you provide
greater isolation for the resource. When you define a resource at a more general scope, you
provide less isolation. Greater exposure to cross-application conflicts occur for a resource
that you define at a more general scope.
The cell scope value limits the visibility of all servers to the named cell. The resource
factories within the cell scope are defined for all servers within this cell and are overridden
by any resource factories that are defined within application, server, cluster, and node
scopes that are in this cell and have the same Java Naming and Directory Interface (JNDI)
name. The resource providers that are required by the resource factories must be installed
on every node within the cell before applications can bind or use them.
Cluster scope
The cluster scope value limits the visibility to all the servers on the named cluster. The
resource factories that are defined within the cluster scope are available for all the members
of this cluster to use and override any resource factories that have the same JNDI name that
is defined within the cell scope. The resource factories that are defined within the cell scope
are available for this cluster to use, in addition to the resource factories that are defined
within this cluster scope.
Node scope (default)
The node scope value limits the visibility to all the servers on the named node. This is the
default scope for most resource types. The resource factories that are defined within the
node scope are available for servers on this node to use and override any resource factories
that have the same JNDI name defined within the cell scope. The resource factories that are
defined within the cell scope are available for servers on this node to use, in addition to the
resource factories that are defined within this node scope.
Server scope
The server scope value limits the visibility to the named server. This is the most specific
scope for defining resources. The resource factories that are defined within the server scope
are available for applications that are deployed on this server and override any resource
factories that have the same JNDI name defined within the node and cell scopes. The
resource factories that are defined within the node and cell scopes are available for this
server to use, in addition to the resource factories that are defined within this server scope.
Application scope
The application scope value limits the visibility to the named application. Application scope
resources cannot be configured from the Integrated Solutions Console. Use Rational
Application Developer Assembly and Deploy V7.5, or the wsadmin tool to view or modify
the application scope resource configuration. The resource factories that are defined within
the application scope are available for this application to use only. The application scope
overrides all other scopes.
You can define resources at multiple scopes but the definition at the most specific scope is used. When
selecting a scope, the following rules apply:
v The application scope has precedence over all the scopes.
v The server scope has precedence over the node, cell, and cluster scopes.
v The cluster scope has precedence over the node and cell scopes.
v The node scope has precedence over the cell scope.
When viewing resources, you can select the scope to narrow the list to just the resources defined at the
scope. Alternatively, you can select to view resources for all scopes. Resources are always created at the
currently selected scope. Resources created at a given scope might be visible to lower scopes. For
example, a data source created at a node level might be visible to servers within the node.
Be sure to keep this precedence structure in mind when configuring Lotus Sametime. Here is a screen
capture of one place where you will see resources configurable by scope:
For more information, consult the IBM Redbooks Publication WebSphere Application Server V7
Administration and Configuration Guide , Chapter 5.1.5.
Common WebSphere Application Server commands
In this section, you will learn about common server commands used when administering Lotus
Sametime.
Time needed
It will take approximately 30 minutes to complete this section.
Objectives
After reading this section, you should be able to:

v Start and stop WebSphere Application Servers using several methods.
v Log on to the WebSphere Application Server administrative console.
v Check the status of the server using the serverStatus command.
Starting and stopping WebSphere Application Server

There are several ways to start and stop WebSphere Application Server:
v From a command line
v From the WebSphere Application Server administrative console
v If you are using Microsoft® Windows®, from the Microsoft Windows Start Menu
v If you are using Microsoft Windows, by starting the Microsoft Windows Service if the application
server is registered as a service
Be sure to always start the servers in the correct order:

1. Deployment Manager
2. Node Agent
3. Application Server
Note: When stopping servers, the order does not matter if all will be shut down. However, as a best
practice, shut down the servers in the reverse of the order listed above.
Starting and stopping an application server using the command line

Use the following steps to start a server from a command line:
Procedure
1. If WebSphere Application Server Network Deployment is installed, you must first start the
deployment manager. To start the deployment manager, navigate to the bin directory under the
deployment manager profile from a command line. For example, C:\Program Files\IBM\WebSphere\
AppServer\profiles\MyDMgrProfile\bin
2. On Microsoft Windows systems, enter the command startManager.bat. On AIX®, Linux®, or Solaris
systems, the command is startManager.sh.
3. Next, start the node agent. Navigate to the bin directory under the profile for the server. For example,
C:\Program Files\IBM\WebSphere\AppServer\profiles\MyAppSvrProfile\bin.
4. On Microsoft Windows systems, enter the command startNode.bat. On AIX, Linux, or Solaris systems,
the command is startNode.sh.
5. After the node agent successfully starts, enter the command startServer.bat <server name> where
<server name> is the name of the application server. For example, startServer.bat MyAppSvr.
Note: On AIX, Linux, or Solaris systems, the command is startServer.sh

Attention: The name of the server is case sensitive, even for servers running on Microsoft Windows.
The results returned will resemble the following screen capture:
Note: Although this screen capture was taken from a Microsoft Windows system, the output will be
similar on other operating systems.
6. To stop the application server, enter the command stopServer.bat <server name> where <server
name> is the name of the application server. You can append the -username <WebSphere
administrator user name> and -password <password> parameters to the command or you will be
prompted to enter the credentials for your WebSphere Application Server administrator.
Note: On AIX, Linux, or Solaris systems, the command is stopServer.sh.

7. To stop the node, enter the command stopNode.bat. You can append the -username <user name> and
-password <password> parameters to the command or you will be prompted to enter the credentials
for your WebSphere Application Server administrator.
Note: On AIX, Linux, or Solaris systems, the command is stopNode.sh.

8. To stop the deployment manager, navigate to the bin directory under the deployment manager
profile. Enter the command stopManager.bat. You can use the -username <user name> and -password
<password> parameters or you will be prompted to enter the credentials for your WebSphere
Application Server administrator.
Note: On AIX, Linux, or Solaris systems, the command is stopManager.sh
What to do next
Note: When you start the servers you do not need to enter the WebSphere Application Server
administrator credentials. It is only when you stop the servers, or check the server status, that the
credentials are needed.
Starting a server using the Microsoft Windows Start Menu

On a Windows machine, you can start an application server using the Start Menu.
Procedure
1. First, start the deployment manager by clicking Start → All Programs → IBM WebSphere →
Application Server Network Deployment V7.0 (or the folder corresponding to your WebSphere
Application Server install) → Profiles → <Deployment Manager Profile Name> (such as
MyDmgrProfile) → Start the Deployment Manager
2. After the deployment manager starts, start the node agent by opening a command prompt and
navigating to the bin directory under the profile for the application server. For example, C:\Program
Files\IBM\WebSphere\AppServer\profiles\MyAppSvrProfile\bin.
3. Enter the command startNode.bat.
Note: On AIX, Linux, or Solaris systems, the command is startNode.sh.

4. Next, start the application server by clicking Start → All Programs → IBM WebSphere → Application
Server Network Deployment V7.0 (or the folder corresponding to your WebSphere Application
Server install) → Profiles → <Application Server Profile Name> (such as MyAppSvrProfile) →
<Application Server Profile Name> (such as MyAppSvrProfile) → Start the server.
Starting a server using the Windows Service

Procedure
1. All servers must be registered as Windows Services for the following steps to work. Open the
Windows Services utility by clicking Start → All Programs → Administrative Tools → Services.
Depending on your Operating System, the sequence to open the Windows Services utility may differ.
2. First, start the service corresponding to the deployment manager.
3. Next, start the service corresponding to the node agent for the server.
4. Last, start the service corresponding to the application server.
Starting a server using the IBM Integrated Solutions Console

Procedure
1. Start the administrative console server if it is not already running.
Tip: You will learn how to check the status of a server in the next part.
2. Launch the administrative console in a Web browser.
Tip: You will learn how to launch the administrative console in the last part.
3. In the administrative console, navigate to Servers > Server Types > WebSphere application servers.
4. Click the check box next to the server that you want to start, and then click the Start button.
Checking the status of a server

At times, you may need to check the status of a particular server. You can use the serverStatus command
to list the status of one or all servers of the servers configured in a node.
Procedure
1. Navigate to the bin directory under the profile for the server. For example, C:\Program
Files\IBM\WebSphere\AppServer\profiles\MyAppSvrProfile\bin
2. To view the status of all of the servers in the configuration, enter the command serverStatus.bat -all.
To view the status of a particular server in the configuration, enter the command serverStatus.bat
-<server name> where <server name> is the server.
Note: On AIX, Linux, or Solaris systems, the command is serverStatus.sh.
Tip: You can append the -username <WebSphere administrator user name> and -password
<password> parameters to the command. For example: serverStatus.bat -all -username wasadmin
-password waspassword. Otherwise, you will be prompted to enter the credentials for your WebSphere
Application Server administrator.
The status of the specified server(s) will be displayed on the command line.
3. Alternately, you can check the server status using the WebSphere Application Server administrative
console. Launch the administrative console and navigate to Servers → Server Types → WebSphere
application server. The status of each of the application servers in the configuration are displayed in
the status column. The following screen capture shows the results of running the serverStatus
command from both the Deployment Manager profile and the Sametime System System Console
Server profile:
Note: Although this screen capture was taken from a Microsoft Windows system, the output will be
similar on other operating systems.
Logging on to the IBM Integrated Solutions Console

The IBM Integrated Solutions Console (ISC) is a Web-based tool that is used to administer a WebSphere
Application Server environment.
Before accessing the IBM Integrated Solutions Console through the Web browser, you must first start the
server that is hosting the console. In a stand-alone environment, the console is hosted on the application
server. Therefore, you need to start the application server before attempting to access the console. In a
distributed environment, available with the use of the IBM WebSphere Application Server Network
Deployment, the console is hosted on the deployment manager server, which must be started before
accessing the console.
Use the following URL to access the WebSphere Administrative Console: http://:<WC_adminhost>/ibm/
console where WC_adminhost is the admin port.
If you are not sure of the admin port, locate the portdef.props file in the properties directory under the
profile for the server hosting the admin console. For example, C:\Program Files\IBM\WebSphere\
AppServer\profiles\MyDMgrProfile\properties. In the portdef.props file, WC_adminhost is the default
admin port and WC_adminhost_secure is the secure port used if administrative security enabled.
Note: If you use the default port and administrative security is enabled for the server, you will
automatically be redirected to the secure port.
WebSphere Application Server types in the context of Lotus Sametime
In this section you will learn about the servers that comprise a WebSphere Application Server
environment and where the Lotus Sametime servers/components fit into the WebSphere Application
Server structure.
Time needed
It will take approximately 30 minutes to complete this section.
Objectives
After reading this section, you will be able to:

v Describe the servers that comprise a WebSphere Application Server environment
v Describe the function of the WebSphere Application Server's Deployment Manager
v Define WebSphere Application Server types in the context of Sametime
v Describe the function of the Deployment Manager and the Integrated Solutions Console in the context
of Sametime
v Troubleshoot issues with accessing Sametime System Console
v Use WASServiceCmd utility to set up Sametime servers to load as Windows Services
Server types in a WebSphere Application Server environment

System requirements for IBM WebSphere Application Server, such as supported Database servers,
Directory servers, and Web servers, are found in: IBM WebSphere Application Server Detailed Requirements
and in WebSphere Application Server V7: Concepts, Planning, and design. This part briefly explains the
function of some of the server types that are used/required in a WebSphere Application Server
deployment. The graphic below represents the servers to be defined. Skip ahead to the next part if you
already know the function of these servers and want to see how they are used in a Lotus Sametime
deployment.
Application Server
The first section of this document defined an application server as follows:
The application server is the primary runtime component in all configurations and is where
an application actually executes. All WebSphere Application Server configurations can have
one or more application servers. ... With Network Deployment, you can build a distributed
server environment consisting of multiple application servers maintained from a central
administration point. In a distributed server environment, you can cluster application
servers for workload distribution.

Web Server
The function of the Web/HTTP server in the WebSphere Application Server environment is
explained in theWebSphere Application Server V7: Concepts, Planning, and design as follows:
WebSphere Application Server can work with a Web server (like the IBM HTTP Server
included in WebSphere Application Server) to route requests from browsers to the
applications that run in WebSphere Application Server. A WebSphere Web Server Plug-in is
provided for installation with supported Web servers. This plug-in directs requests to the
appropriate application server and performs workload balancing and fail-over among
servers in a cluster.
Although Web servers are products that are separate from WebSphere Application Server, they
can be defined in the WebSphere Application Server administration process, to enable the
administrator to associate applications with one or more defined Web servers in order to generate
the proper routing information for Web server plug-ins. In addition, Web server management
capabilities are available in some circumstances.
Source:WebSphere Application Server V6.1 Planning and Design
Database Server
The database server plays an integral role in the WebSphere Application Server environment. The
database server is defined on the IBM Terminology site as:
1. A software program that uses a database manager to provide database services to other
software programs or computers.
2. The server on which the database application and database are installed.
3. A computer that is dedicated to running a database manager to provide database
services to other software programs or computers. See also data server. ..A server that
provides services for the secure and efficient management of information.
Directory Server
The directory server is defined on the IBM Terminology site as:
A server that can add, delete, change or search directory information on behalf of a client.
A directory is a data structure that enables the look up of names and associated attributes
arranged in a hierarchical tree structure. In the context of enterprise application servers, this
enables applications to look up a user principal and determine what attributes the user has
and of which groups the user is a member. Decisions about authentication and authorization
can then be made using this information.
Source: WebSphere Application Server V6.1 Planning and Design
The common protocol used for the directory server is Lightweight Directory Access Protocol
(LDAP) which is defined on the IBM Terminology site as:
An open protocol that uses TCP/IP to provide access to directories that support an X.500
model and that does not incur the resource requirements of the more complex X.500
Directory Access Protocol (DAP). For example, LDAP can be used to locate people,
organizations, and other resources in an Internet or intranet directory.
Proxy Server
A Proxy server is defined on the IBM Terminology site as:
1. A server that receives requests intended for another server and that acts on the client's
behalf (as the client's proxy) to obtain the requested service. A proxy server is often used
when the client and the server are incompatible for direct connection. For example, the
client is unable to meet the security authentication requirements of the server but should
be permitted some services.
2. A server that acts as an intermediary for HTTP Web requests that are hosted by an
application or a Web server. A proxy server acts as a surrogate for the content servers in
the enterprise.
WebSphere Application Server types in the context of Lotus Sametime
8.5
The IBM Lotus Sametime 8.5 system requirements document, Detailed system requirements - Sametime 8.5
provides, among other requirements, the supported database servers, directory servers, HTTP servers, etc.
The previous section briefly explained the function of some of the key servers that comprise a WebSphere
Application Server environment. This section discusses those server types in the context of the Lotus
Sametime 8.5. Some of the servers cited in the requirements are shown in the graphic below .
Application Servers
Most of the Lotus Sametime 8.5 servers run on the IBM WebSphere Application Server platform,
and are application servers themselves. The purpose of each server is described briefly here:
v The IBM Lotus Sametime System Console provides a central location for installing, configuring
and administering the Sametime components.
v The IBM Lotus Sametime Meeting Server provides a central meeting place for community
members.
v The IBM Lotus Sametime Media Manager provides audio and visual services for Sametime
meetings and chats.
v The IBM Lotus Sametime Proxy Server hosts the Lotus Sametime client for browsers.
v The IBM Lotus Sametime Gateway Server provides the means of sharing awareness with
external instant messaging communities.
Note: The IBM Lotus Sametime Community server runs on IBM Lotus Domino® server rather than
WebSphere Application Server.
Database Server
Several of the Lotus Sametime servers/components require a Database server, specifically IBM
DB2®, which can be downloaded with the Lotus Sametime 8.5 installation. For more information
see the download document, IBM Lotus Sametime Standard 8.5. The Lotus Sametime System
Console, the Lotus Sametime Meeting Server, and the Lotus Sametime Gateway Server all require
DB2. The Lotus Sametime System Console requires DB2 to store user policy information and
deployment topology information; this information is fed to the installers when setting up servers
and also at runtime to connect to other servers. The Lotus Sametime Meeting Server requires DB2
for storing meeting room user data. The Sametime Gateway Server requires DB2 for policy
information.
Directory Server
The Lotus Sametime System Console, the Lotus Sametime Meeting Server and the Lotus
Sametime Gateway Server all require an LDAP directory server. The LDAP directory contains the
person records for the users in the local Lotus Sametime Community, and these servers can
search the LDAP directory and authenticate Lotus Sametime users when required.
Proxy Server
There are several roles for proxy servers in a Lotus Sametime deployment. One example is when
the IBM WebSphere Proxy Server is configured to handle routing and caching tasks for a cluster
of Lotus Sametime Meeting Servers. IBM WebSphere Proxy Server is distributed with the
WebSphere Application Server that is included with the Lotus Sametime installation. The Lotus
Sametime system requirements also lists several supported proxy servers that can be used for
secure networking.
Deployment Manager and the IBM Integrated Solutions Console

With the IBM WebSphere Application Server Network Deployment edition, you administer the servers
and components associated with the WebSphere Application Server environment using the deployment
manager. The environment where there are multiple servers being managed from a single deployment
manager is referred to as a Distributed server environment. The deployment manager itself is a server that
centrally manages and administers all servers and components in a given node(s) in a given WebSphere
Application Server cell.
The deployment manager also hosts powerful advanced deployment capabilities that are available in a
distributed server environment; including high availability, dynamic scalability, and advanced clustering
for workload balancing and failover. In a distributed server environment, the deployment manager
contains the master configuration files (such as .xml files) and Java™ EE application files to start and run
the WebSphere components and processes that run in the environment. The deployment manager
synchronizes its configuration files with those held locally on each node associated with that deployment
manager. Each node contains a node agent, and the deployment manager communicates with the node
agents to synchronize the configuration information and file transfer, and perform other administrative
activities on those nodes.
The file synchronization process that occurs between the deployment manager and the nodes that are
federated into the same cell where the deployment manager resides, is always one-way; from the
deployment manager to the nodes. Configuration changes made at the node level are temporary and will
be overwritten by the master configuration on the deployment manager during the next file
synchronization.
Federation is an important process in a distributed server environment, and it is handled by the

deployment manager. Federation is the process by which a node becomes a part of the deployment
manager cell. During federation, a node agent server is created on the node to manage WebSphere
Application Server environment on that node.
A tool that is hosted by the deployment manager and executes the management and administration tasks
in the WebSphere Application Server distributed server environment is the IBM Integrated Solution
Console. The IBM Integrated Solutions Console, which has been cited throughout this document, is
further defined in the WebSphere Application Server v7.0 Information Center topic Overview of Integrated
Solutions Console as follows:
Integrated Solutions Console provides a single, common interface for system administration. It
provides the main platform on which IBM and non-IBM products can build administrative user
interfaces as individual plug-ins to a common console framework. Standardizing product
administration functions to run on the Integrated Solutions Console platform gives them a more
common look and feel and a more consistent behavior, thereby reducing the learning curve and
adoption as new management components are introduced. Administrators can interact with multiple
IBM and non-IBM products from a single browser-based console.
Deployment Manager and the Lotus Sametime System Console

Lotus Sametime 8.5.x can be deployed in several ways, but a recommended method is to use the Lotus
Sametime System Console (SSC) as the central point of configuration for deployment planning. Once
Lotus Sametime is deployed its runtime features and functions can be administered mostly using the IBM
Integrated Solutions Console and the Lotus Sametime System Console. The document IBM WebSphere
Application Server Introduction for Lotus explains that the Lotus Sametime System Console is built on Java
EE technology and is a plug-in with a set of portlets within the IBM Integrated Solutions Console, which
is hosted on the Deployment Manager. Here we will dig a little deeper by explaining the following
image.
There are three application servers, or Java Virtual Machines (JVMs), that run in the Lotus Sametime
Console Server cell (labeled as SSC Cell in the diagram above): the Deployment Manager, Node Agent,
and the Lotus Sametime System Console Server. As mentioned previously in this document, the Lotus
Sametime System Console database (labeled as STSC DB in the diagram above), which runs on IBM DB2,
stores user policy data and much of the Lotus Sametime deployment topology data; it feeds this data to
the installers when setting up the Lotus Sametime servers, and at runtime to connect to the servers. The
node agent is used for communication between the Deployment Manager and the Sametime System
Console Server. The Deployment Manager hosts the Integrated Solutions Console, and Sametime System
Console Portlets (labeled as SSC Portlets in the diagram above) within the ISC provide the user interface
for administering the Sametime servers and components. The SSC Framework applications are used to
drive the REST APIs that the Sametime installers connect to and also provide policy and administrative
interfaces that the applications connect to in order to do necessary updates of information from the SSC.
One of the important functions of the ISC and the SSC is to make sure that changes made at the
deployment manager level are propagated to the nodes in the same cell as the deployment manager.
When you make a change on an the Sametime System Console Server, such as increase trace levels, it is
important to save the change to the master configuration, which is located on the deployment manager.
To make sure the nodes know of the changes you made, you then trigger file synchronization by
selecting System Administration → Save Changes to Master Repository → Synchronize Changes with
Nodes → Save . Once the synchronization has completed, you must then restart the server.
Things to check when you cannot access the Lotus Sametime System
Console
The Deployment Manager, Node Agent, and Lotus Sametime System Console application server must all
be running to access the Lotus Sametime System Console. Once all three of these servers are started, you
log into the IBM Integrated Solutions Console (ISC), and access the Sametime System Console within the
ISC, from your Web browser using http://<WC_adminhost>/ibm/console. Details on determining the
correct port to use were discussed previously in this document, in the section Logging on to the IBM
Integrated Solutions Console.
At times you may have trouble accessing the Lotus Sametime System Console; for example, you may not
be successful when logging into the IBM Integrated Solutions Console and you may see an error in your
browser such as "Unable to connect" or "Cannot display web page". In this case, these particular errors
normally occur if the deployment manager is not running. As a first step, it is a good practice to verify
that all three servers are running by executing the serverStatus command in your operating system's
command prompt. Refer to the topic in the previous section of this document titled, Checking the Status of
a Server for the proper syntax of the serverStatus command.
If the deployment manager is running, the results of the serverStatus command execution will state:
“ADMU0509I: The Deployment Manager "dmgr" is STARTED"
If the deployment manager is not running, the serverStatus command will state “ADMUxxxxI: The
Deployment Manager "dmgr" cannot be reached. It appears to be stopped."
Note: The numerical portion of the ADMUxxxxI code in the console messages will differ depending on
the server you are starting and its state.
If the deployment manager is not running, start it using the appropriate command for your operating
system. Refer to the previous section of this document titled Common WebSphere Application Server
Commands for step-by-step instructions on navigating to the proper location for checking server status
and starting not only the deployment manager server but also the node agent server and the Lotus
Sametime System Console application server.
At other times you may be able to successfully log into the ISC, but cannot access the specific Lotus
Sametime System Console options.. The image below shows an example of an error that occurs when the
deployment manager is running and you have successfully logged into the Integrated Solutions Console,
but you cannot access some of the options in the Sametime System Console. A likely cause of this
behavior is that the Lotus Sametime System Console application server is not running.
In this case, it is best to issue a serverStatus -all command in the proper directory to verify the status of
both the node agent and the Sametime System Console server. If either or both servers are not running,
start them accordingly. Again, a good place to verify your steps, and to see examples of the output you
will see from the serverStatus command and others, is the previous section of this document titled
Common WebSphere Application Server Commands.
If you have confirmed that all three servers are started, but are still experiencing issues with accessing the
Lotus Sametime System Console, first check the systemOut.log file located in the deployment manager
profile's log directory: <appserver_install_root>\profiles\STSCDMgrProfile\logs\dmgr for errors
starting with AIDSC. All Sametime System Console errors begin with these characters, followed by a 4
digit number. Then check the Sametime System Console application server's systemOut.log file for the
AIDSC errors; this systemOut.log is located in the Sametime System Console application server's log
directory: <appserver_install_root>\profiles\STSCAppProfile\logs\STConsoleServer.
If you attempt to log into the Integrated Solutions Console and instead see a blank screen, it could be
that the LDAP server is down or otherwise inaccessible. The SystemOut.log for the deployment manager
under <appserver_install_root>\profiles\STSCDMgrProfile\logs\dmgr (or trace.log in the same location,
if you have trace enabled) will contain an error that resembles:
"[date time] 0000002f exception E com.ibm.ws.wim.adapter.ldap.LdapConnection getDirContext

com.ibm.websphere.wim.exception.WIMSystemException: CWWIM4520E
The'java.naming.CommunicationException: <servername>:389 [Root exception is
java.net.ConnectException: Connection refused]' naming exception occurred during processing.
If you find this error in the logs, or otherwise suspect an issue with the LDAP server, add the parameter
allowOperationIfReposDown=true to the wimconfig.xml fie. The presence of this parameter in
wimconfig.xml allows you to log into the Integrated Solutions Console and access the Sametime System
Console even though the LDAP server is not accessible. If a defunct LDAP server is defined, you can
then make the necessary changes. As cited in the section of this document titled WebSphere Application
Server Profiles in Lotus Sametime, the wimconfig.xml file is located in the <appserver_install_root>\
profiles\ STSCDMgrProfile\config\cells\<cell name>\wim\config directory. Open the file in a text
editor and locate these lines:
Important note: Editing configuration files in general is not recommended. Extreme caution should be
used when making edits to the wimconfig.xml file; incorrect changes could render the servers
inaccessible.
<config:realmConfiguration defaultRealm="defaultWIMFileBasedRealm">
<config:realms delimiter="/" name="defaultWIMFileBasedRealm" securityUse="active">
Add the parameter allowOperationIfReposDown="true" in the exact location specified below, and save
the file:
<config:realmConfiguration defaultRealm="defaultWIMFileBasedRealm">
<config:realms delimiter="/" name="defaultWIMFileBasedRealm" securityUse="active"

allowOperationIfReposDown="true">
This change allows you to log into the Integrated Solutions Console as long as the credentials you enter
are accepted by a working/running LDAP server. Once you have logged in you can view the LDAP
repository configurations and make any needed changes (such as removing a defunct LDAP server that
WebSphere Application Server is trying to query on login and causing the login failure) by selecting to
Security → Global Security , and under the User Account Repository section, select Federated
Repositories for Available Realm Definitions and select Configure. You will see the defined repositories
in the realm. Make any necessary changes so that the settings reflect your current LDAP servers, then
select Manage Repositories and make any needed changes there. After you select OK, make sure that
you select Save at the top of the Global Security page to ensure the changes are saved to the master
configuration.
How to Set up Sametime servers to automatically load as Windows

Services
For Microsoft Windows operating systems, one way to ensure that the servers associated with the Lotus
Sametime System Console are started, thereby avoiding some of the access issues cited in the previous
section, is for the servers to be defined as Windows Services so that they always start on operating
system startup. However, there is an overall caveat where, by default, when you install any WebSphere
Application Server components, Windows Services are not automatically created for them. There are
several methods you can choose from to set up your Lotus Sametime servers to load as Windows
Services.
One method is to create and run batch files. Follow the instructions in the Lotus Sametime 8.5 wiki article
Sametime 8.5 Components as a Windows service .
As manual creation of the batch files can be susceptible to issues such as typos, another method is to use
of the WebSphere Application Server utility WASServiceCmd. Perform the following steps to use the
WASServiceCmd utility to set up the Sametime System Console servers as Windows services.
1. Detach the compressed file from the document, Using WASServiceCmd to create Windows services for
WebSphere Application Servers,
2. Open a Windows cmd prompt and switch to the <appserver_install_root>\bin directory.
3. Type wasservicecmd.bat and press ENTER. A list of menu options appears.
4. Type 1 to select the first menu option. A list of profiles, associated with the Application Server
directory you started the utility from, appears. The same list of profiles appears under the
<appserver_install_root>\profiles directory.
5. Type the number corresponding to the profile containing the servers you want to set up as services.
In this example, STSCDMgrProfile is the name of the profile associated with the Lotus Sametime
System Console server's deployment manager. When you select the number corresponding to the
profile, setupcmdLine.bat launches, which lists the Cell and Node associated with that profile as well
as the server(s) associated with that node. In the example, the Deployment Manager server, "1 dmgr"
is listed under Servers.
6. Type a desired service name for the server. Example: Since this server is the Deployment Manager
server, type STConsoleServerDM or ConsoleServerDM. The following image shows an example of
executing the steps above.
Once you have named the service, the utility will ask you several questions regarding your
preferences on service startup and security. The image below shows these questions and choices.
7. Select a desired Restart Policy.
8. Select a desired Start Type.
9. Indicate whether WebSphere Security is enabled.
10. An Execute command will appear; type Y to run the service creation process.
11. Once the command completes and you are again prompted to type a number corresponding to the
desired menu option, type 1 to initialize the steps to set up a Windows service for the node agent
12. Type the number corresponding to the profile containing the servers you want to set up as services.
In the example graphic in step 5 above, STSCAppProfile is the name of the profile associated with
the Lotus Sametime System Console server.
13. From the list of servers that appear select 2 nodeagent.
14. Type the desired service name . Example: ConsoleServerNodeagent.
15. Select a desired Restart Policy.
16. Select a desired Start Type.
17. Indicate whether WebSphere Security is enabled
18. Type Y to run the service creation process.
19. Repeat these steps once more for the Lotus Sametime System Console server.
You can check if the services were successfully created by selecting Start - Run and typing services.msc.
Look for a service starting with "IBM WebSphere Application Server v7.0 - ". The image below shows the
result of the steps taken above:
Repeat these steps to configure Windows services for the remaining Sametime servers associated with the
cell.
Note that with either method of setting up the services, the services will start with an operating system
start or restart, but may not always start after a crash. It is always best to check the logs such as
startServer.log for each server that is suspected of not starting or starting properly to determine
whether the server fully started. A startServer.log file exists for each server in the each profile, and is
located in the <appserver_install_root>\profiles\<profile name>\logs\<server> directory.

Printed in USA

WebSphere Application Server Concepts For Sametime Users

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WebSphere Application Server Concepts For Sametime Users

Uploaded by

Copyright:

Available Formats

Lotus ®

Overview of IBM WebSphere

It should take approximately 80 minutes to complete this content.

Prerequisites and system requirements

The following learning topics are covered:

Title Approximate Timing (in minutes)

It will take approximately 30 minutes to complete this content.

After reading this document, you should be able to:

The ABC's of IBM WebSphere Application Server

Source: WebSphere Application Server V6 Technical Overview

A cell is a grouping of nodes into a single administrative domain. ... In a Network

Source: WebSphere Application Server V6 Technical Overview

Source: WebSphere Application Server V7: Concepts, Planning, and design

Source: WebSphere Application Server V7: Concepts, Planning, and design

Source: WebSphere Application Server V7: Concepts, Planning, and design

WebSphere Application Server terminology in the context of Lotus

You will explore the following configurations of Lotus Sametime:

It will take approximately 30 minutes to complete this section.

After reading this section, you should be able to:

Starting and stopping WebSphere Application Server

Be sure to always start the servers in the correct order:

Starting and stopping an application server using the command line

Note: On AIX, Linux, or Solaris systems, the command is startServer.sh

Note: On AIX, Linux, or Solaris systems, the command is stopServer.sh.

Note: On AIX, Linux, or Solaris systems, the command is stopNode.sh.

Note: On AIX, Linux, or Solaris systems, the command is stopManager.sh

Starting a server using the Microsoft Windows Start Menu

Note: On AIX, Linux, or Solaris systems, the command is startNode.sh.

Starting a server using the Windows Service

Starting a server using the IBM Integrated Solutions Console

Checking the status of a server

Note: On AIX, Linux, or Solaris systems, the command is serverStatus.sh.

Logging on to the IBM Integrated Solutions Console

It will take approximately 30 minutes to complete this section.

After reading this section, you will be able to:

Server types in a WebSphere Application Server environment

Source: WebSphere Application Server V6 Technical Overview

Deployment Manager and the IBM Integrated Solutions Console

Federation is an important process in a distributed server environment, and it is handled by the

Deployment Manager and the Lotus Sametime System Console

"[date time] 0000002f exception E com.ibm.ws.wim.adapter.ldap.LdapConnection getDirContext

<config:realms delimiter="/" name="defaultWIMFileBasedRealm" securityUse="active">

<config:realms delimiter="/" name="defaultWIMFileBasedRealm" securityUse="active"

How to Set up Sametime servers to automatically load as Windows

You might also like