Sametime Installation and Integration

Front cover
Sametime 7.5.1
Best Practices for Enterprise
Scale Deployment
Building and deploying an Enterprise
Architecture
Integration with Portal and

Domino extended products
System administration
and maintenance
George Lambie
Charles Price, Jr.
Jim Puckett
Vineet Rohatgi
Stephen Shepherd
Jennifer Wales
Jeff Pinkston
Rob Fox
ibm.com/redbooks
International Technical Support Organization
Sametime 7.5.1 - Best Practices for Enterprise Scale

Deployment
September 2007
SG24-7410-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page xi.
First Edition (September 2007)
This edition applies to IBM Lotus Sametime 7.5 and subsequently Sametime 7.5.1.
© Copyright International Business Machines Corporation 2007. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Special acknowledgement to the following team members for their contributions
to this project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Additional Contributors to this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Chapter 1. Lotus Sametime 7.5.1 in the Enterprise . . . . . . . . . . . . . . . . . . . 1

1.1 About Lotus Sametime 7.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Understanding the distinguishing features within Sametime 7.5 and
Sametime 7.5.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Lotus Sametime Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Community services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Meeting services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Extendable Applications Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.1 Client extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2 Server extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Audio Visual Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 Key concepts: scalability, performance, and high availability . . . . . . . . . . 14
1.5.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.2 Scalability with Sametime Multiplexors . . . . . . . . . . . . . . . . . . . . . . . 15
1.5.3 Load balancing, server clustering, and failover . . . . . . . . . . . . . . . . . 15
1.6 Introduction to the Enterprise Deployment Scenario . . . . . . . . . . . . . . . . . 16
1.7 Overview of the deployment approach taken throughout this book . . . . . 18
Chapter 2. Planning a Sametime 7.5.1 Deployment . . . . . . . . . . . . . . . . . . 21

2.1 Population topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.1 Determining different classes of users . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Network topology considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Client considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Primary clients for Sametime 7.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2 Client PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4 Deployment options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.1 Deployment option - single Sametime server . . . . . . . . . . . . . . . . . . 29
2.4.2 Deployment option - dedicated Sametime servers . . . . . . . . . . . . . . 33
© Copyright IBM Corp. 2007. All rights reserved. iii

2.4.3 Deployment option - multiple Sametime servers. . . . . . . . . . . . . . . . 33
2.4.4 DeploymeNt Option: Separated Community Multiplexing . . . . . . . . . 38
2.4.5 Deployment option: SA mux in remote locations . . . . . . . . . . . . . . . 40
2.4.6 Deployment options for high availability . . . . . . . . . . . . . . . . . . . . . . 40
2.5 High-availability deployment option - Community Services clustering . . . 43
2.5.1 Deployment option - Sametime in the extranet . . . . . . . . . . . . . . . . . 46
2.6 Overview of the global architecture proposed for ITSO Corporation. . . . . 56
2.7 Directory considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.7.1 Types of directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.7.2 Choosing which type of Directory to use . . . . . . . . . . . . . . . . . . . . . . 59
2.7.3 How Sametime uses the directory . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.7.4 Directory components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.7.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.7.6 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.8 Sametime system requirements - minimum requirements and
recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.8.1 Sametime server requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.8.2 Client requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.8.3 Community Services multiplexer requirements . . . . . . . . . . . . . . . . . 68
2.9 Ports used by the Sametime server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Chapter 3. LDAP User Directory - foundation for Sametime . . . . . . . . . . . 79

3.1 Directory concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.1.1 What is a directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.1.2 Directory components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.2 Directory considerations specific to Sametime 7.5.1. . . . . . . . . . . . . . . . . 83
3.2.1 Types of directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.2.2 Choosing which type of directory to use . . . . . . . . . . . . . . . . . . . . . . 84
3.2.3 How Sametime uses the directory . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.2.4 Group considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.2.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.2.6 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.3 Tivoli Directory Server Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.3.1 Steps for installing Tivoli Directory Server . . . . . . . . . . . . . . . . . . . . 87
3.4 Administering and configuring the Directory Server . . . . . . . . . . . . . . . . . 99
3.4.1 Directory Server Web Administration Tool . . . . . . . . . . . . . . . . . . . 100
3.5 Directory information tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.6 Suffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.7 Populating the Directory Server using an LDIF file . . . . . . . . . . . . . . . . . 110
3.7.1 Steps to populate using the LDIF file . . . . . . . . . . . . . . . . . . . . . . . 111
3.8 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.8.1 Nested groups in a schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.9 Extending the LDAP schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
iv Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

3.9.1 Extending the schema to add SametimeServer attribute . . . . . . . . 116
3.9.2 Extending the schema to add NotesDN and NotesCon . . . . . . . . . 125
3.9.3 Extending the schema to add MailFile and MailServer attributes . . 126
3.10 Adding Attribute values via LDAPModify. . . . . . . . . . . . . . . . . . . . . . . . 128
Chapter 4. Deployment phase 1 -

implementing Community Services . . . . . . . . . . . . . . . . . . . . 129
4.1 What you build in this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.2 Perspective - how this fits into the overall enterprise infrastructure . . . . 132
4.3 Deploy clustered chat servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.3.1 Install/configure the first chat server . . . . . . . . . . . . . . . . . . . . . . . . 133
4.3.2 Sametime server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
4.3.3 Install/configure the second chat server . . . . . . . . . . . . . . . . . . . . . 172
4.3.4 Sametime setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
4.3.5 Create a Domino cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
4.3.6 Create a Sametime cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
4.4 Deploy stand-alone mux servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
4.5 Install and configure IBM Edge Load Balancer components. . . . . . . . . . 224
4.5.1 Overview of the steps within the basic load-balancing scenario . . . 225
4.5.2 Configure network to work with the Edge Network Dispatcher
Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
4.5.3 Configure NIC on mux servers to accept traffic for imcluster . . . . . 226
4.5.4 Configure NIC on load balancer to accept traffic for imcluster . . . . 242
4.5.5 Install Edge Network Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
4.5.6 Configure Edge Network Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . 259
Chapter 5. Deployment phase I -

implementing Meeting Services . . . . . . . . . . . . . . . . . . . . . . . 281
5.1 What you will be building in this chapter . . . . . . . . . . . . . . . . . . . . . . . . . 282
5.2 Deploy ITSO Corporation’s meeting infrastructure . . . . . . . . . . . . . . . . . 284
5.2.1 Domino setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
5.2.2 Sametime setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Chapter 6. Deployment phase II -

integration with other products . . . . . . . . . . . . . . . . . . . . . . . . 329
6.1 Navigating this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
6.2 Case fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
6.3 Business card integration in Connect client . . . . . . . . . . . . . . . . . . . . . . 334
6.3.1 What is the business card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
6.3.2 How the business card feature works . . . . . . . . . . . . . . . . . . . . . . . 335
6.3.3 Storage respositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
6.3.4 Business card and storage configurations . . . . . . . . . . . . . . . . . . . 337
6.3.5 Best practices for setting up the business card feature . . . . . . . . . 340
6.3.6 Set up business card feature for ITSO Corporation . . . . . . . . . . . . 341
Contents v
6.3.7 Testing the business card setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
6.4 Notes Client integration with Sametime . . . . . . . . . . . . . . . . . . . . . . . . . 353
6.4.1 How instant messaging works using a Notes Client . . . . . . . . . . . . 353
6.4.2 Add a Domino canonical name to LDAP Directory . . . . . . . . . . . . . 355
6.4.3 Add LDAP’s Domino Canonical Name field to resolve filter . . . . . . 356
6.4.4 Configure Notes Client to pass full canonical name format . . . . . . 358
6.4.5 Enable awareness in Notes Client . . . . . . . . . . . . . . . . . . . . . . . . . 360
6.5 Domino Web Access integration with Sametime. . . . . . . . . . . . . . . . . . . 365
6.6 Install Domino and register the DWA users . . . . . . . . . . . . . . . . . . . . . . 366
6.6.1 Install Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
6.6.2 Register users in Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
6.7 Configure DWA for awareness and chat . . . . . . . . . . . . . . . . . . . . . . . . . 383
6.7.1 How instant messaging works in DWA . . . . . . . . . . . . . . . . . . . . . . 383
6.7.2 Synchronize the directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
6.7.3 Configure SSO between DWA and Sametime . . . . . . . . . . . . . . . . 401
6.7.4 Configure DWA server document for awareness and chat . . . . . . . 406
6.7.5 DWA user settings to enable awareness and chat . . . . . . . . . . . . . 409
6.7.6 Change how names are passed to Sametime for awareness status413
6.8 QuickPlace integration with Sametime . . . . . . . . . . . . . . . . . . . . . . . . . . 421
6.9 Install QuickPlace and configure Security . . . . . . . . . . . . . . . . . . . . . . . . 421
6.9.1 Install Domino for QuickPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
6.9.2 Install QuickPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
6.9.3 Configure QuickPlace Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
6.10 Configure QuickPlace for awareness, chat, and meetings . . . . . . . . . . 447
6.10.1 How instant messaging works in QuickPlace . . . . . . . . . . . . . . . . 448
6.10.2 How online meetings work in QuickPlace . . . . . . . . . . . . . . . . . . . 450
6.10.3 Configure SSO between QuickPlace and Sametime . . . . . . . . . . 451
6.10.4 Configure QuickPlace for awareness and chat . . . . . . . . . . . . . . . 460
6.10.5 Configure QuickPlace for online meetings . . . . . . . . . . . . . . . . . . 464
6.11 WebSphere Portal Integration with Sametime . . . . . . . . . . . . . . . . . . . 474
6.12 Install WebSphere Portal and configure Security . . . . . . . . . . . . . . . . . 474
6.12.1 Install WebSphere Portal v6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
6.12.2 Enable security with realm support . . . . . . . . . . . . . . . . . . . . . . . . 478
6.13 Configure WebSphere Portal for awareness, chat, and meetings . . . . 485
6.13.1 How instant messaging works in WebSphere Portal . . . . . . . . . . 486
6.13.2 How online meetings work in WebSphere Portal . . . . . . . . . . . . . 488
6.13.3 Configure SSO between Portal and Sametime . . . . . . . . . . . . . . . 489
6.13.4 Enable awareness and chat in WebSphere Portal . . . . . . . . . . . . 499
6.13.5 Configure Sametime to trust Portal for the Sametime Contact List
portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
6.13.6 Configure the Web Conferencing Portlet . . . . . . . . . . . . . . . . . . . 512
6.14 Lotus Sametime 7.5.1 and Microsoft Office integration. . . . . . . . . . . . . 521
6.14.1 Install MS integration with Sametime . . . . . . . . . . . . . . . . . . . . . . 523
vi Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

6.14.2 Configure MS integration with Sametime . . . . . . . . . . . . . . . . . . . 529
Chapter 7. Deployment phase III -

securing the environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
7.1 Navigating this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
7.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
7.2.1 Overview of Basic Sametime security . . . . . . . . . . . . . . . . . . . . . . . 538
7.3 SSL encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
7.3.1 Overview of key steps involved in setting up SSL for Sametime . . 540
7.3.2 Setting up SSL using a self-signed certificate . . . . . . . . . . . . . . . . . 540
7.4 Setting up SSL using certificate from a trusted authority . . . . . . . . . . . . 564
7.4.1 Configuring the Domino certificate authority . . . . . . . . . . . . . . . . . . 565
7.4.2 Installing GSKit on Tivoli Director Server . . . . . . . . . . . . . . . . . . . . 574
7.5 Sametime and firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
7.5.1 Ports used by Sametime through firewalls . . . . . . . . . . . . . . . . . . . 599
7.6 HTTP tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
7.6.1 HTTP tunneling defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
7.6.2 HTTP tunneling at work - Meeting Room Client example . . . . . . . . 610
7.6.3 HTTP tunneling’s impact on performance . . . . . . . . . . . . . . . . . . . . 612
7.6.4 Best practices for HTTP tunneling . . . . . . . . . . . . . . . . . . . . . . . . . 615
7.6.5 HTTP tunneling and SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
7.6.6 HTTP tunneling tweaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
7.7 Protecting Sametime with reverse proxies . . . . . . . . . . . . . . . . . . . . . . . 618
7.7.1 Chat and awareness considerations with reverse proxies . . . . . . . 618
7.8 Introduction to the IBM Edge Server caching proxy . . . . . . . . . . . . . . . . 620
7.8.1 Reverse proxy (IP forwarding) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
7.8.2 Using multiple caching proxy servers . . . . . . . . . . . . . . . . . . . . . . . 623
7.9 Caching proxy installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
7.10 Configuration of IBM Edge Server caching proxy . . . . . . . . . . . . . . . . . 627
Chapter 8. Sametime Client deployment considerations . . . . . . . . . . . . 631

8.1 About Lotus Sametime 7.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
8.1.1 New features in Sametime 7.5 and Sametime 7.5.1 . . . . . . . . . . . . 632
8.1.2 Understanding the distinguishing features within Sametime 7.5 and
Sametime 7.5.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
8.2 Sametime 7.5.1 Client options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
8.2.1 Sametime 7.5.1 Connect client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
8.2.2 Overview of the features in the Sametime 7.5.1 Connect client . . . 636
8.2.3 Enhancements with rich text capabilities . . . . . . . . . . . . . . . . . . . . 640
8.2.4 Plug-in integration points and extensibility for Sametime 7.5.x Connect
client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
8.2.5 Integrated Sametime within the Notes Client . . . . . . . . . . . . . . . . . 651
8.2.6 Sametime Meeting Room Client and Recorded Meeting Client . . . 662
Contents vii
8.2.7 Sametime Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
8.3 Sametime Client deployment considerations . . . . . . . . . . . . . . . . . . . . . 668
8.3.1 Deployment phase 1: planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
8.3.2 Client employment phase II: implementation . . . . . . . . . . . . . . . . . 671
8.3.3 Sametime Meeting Room Client, Sametime Recorded Meeting Client.
684
8.4 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Chapter 9. Systems management and maintenance . . . . . . . . . . . . . . . . 691

9.1 Monitoring Sametime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
9.1.1 Sametime monitoring charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
9.1.2 Sametime logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
9.1.3 Domino Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
9.1.4 Clustered environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
9.2 Recommended maintenance activities for Sametime environments. . . . 700
Chapter 10. Enterprise Meeting Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 703

10.1 Introduction to Enterprise Meeting Server (EMS) . . . . . . . . . . . . . . . . . 704
10.2 Differences between Sametime and EMS. . . . . . . . . . . . . . . . . . . . . . . 704
10.3 For which environments is EMS appropriate. . . . . . . . . . . . . . . . . . . . . 705
10.3.1 When should you deploy EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
10.3.2 When you should not deploy EMS . . . . . . . . . . . . . . . . . . . . . . . . 706
10.4 What is EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
10.4.1 Understanding different models and scale factors between Community
and Meeting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
10.4.2 How EMS handles failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
10.4.3 EMS and clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
10.4.4 EMS Meeting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
10.5 Hardware and software requirements for EMS . . . . . . . . . . . . . . . . . . . 712
10.5.1 Software components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
10.6 The applications within EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
10.6.1 Why these need to exist as separate applications . . . . . . . . . . . . 714
10.7 EMS deployment - port diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
10.8 Installing and configuring EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
10.8.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
10.8.2 Sametime EMS installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
10.9 Troubleshooting EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Chapter 11. Sametime Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739

11.1 Overview of the Sametime Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
11.1.1 The business value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
11.2 Overview of Sametime Gateway architecture . . . . . . . . . . . . . . . . . . . . 742
11.2.1 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
11.2.2 Recommended installation configurations . . . . . . . . . . . . . . . . . . 745
viii Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

11.2.3 Recommended deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
11.3 Overview of the steps involved for installation . . . . . . . . . . . . . . . . . . . 749
11.4 Referring to the Sametime Information Center for installation and
configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
Appendix A. Directory considerations for Active Directory . . . . . . . . . . 751

Installing Active Directory on Windows 2003 . . . . . . . . . . . . . . . . . . . . . . . . . 752
Populating the Directory Server using an LDIF file . . . . . . . . . . . . . . . . . . . . 763
Configuring Microsoft Active Directory for SSL access . . . . . . . . . . . . . . . . . 764
Adding certificate authority to Microsoft Management Console . . . . . . . . 768
Install trusted root from Domino Certificate Authority . . . . . . . . . . . . . . . . 773
Requesting server certificate from a third-party certificate authority . . . . . 781
Verifying that SSL is enabled on Active Directory Server . . . . . . . . . . . . . 787
Extending the schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Install the Active Directory schema snap-in . . . . . . . . . . . . . . . . . . . . . . . 790
Extending the schema to add attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 792
Adding attribute values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
Appendix B. Directory considerations for Domino LDAP . . . . . . . . . . . . 799

Native Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
SSL issues with Native Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Domino LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Installing Domino LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
Setting up SSL for Domino LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
Dual directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Dual directories with Native Domino directory . . . . . . . . . . . . . . . . . . . . . . . . 805
Dual directories with Domino LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
Adding photos for use with business cards . . . . . . . . . . . . . . . . . . . . . . . . . . 808
Appendix C. Project management guide for an Enterprise Sametime

deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Business case for Sametime deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
Project approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
The Sametime 7.5.1 project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Sample Sametime deployment project plan. . . . . . . . . . . . . . . . . . . . . . . . . . 817
Appendix D. Introduction to load balancing - WebSphere Edge components

819
Introduction to load balancing - WebSphere Edge Components . . . . . . . . . . 820
Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Contents ix
Load Balancer overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
Content Based Routing (CBR) Component . . . . . . . . . . . . . . . . . . . . . . . 830
Site Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Cisco CSS Controller and Nortel Alteon Controller . . . . . . . . . . . . . . . . . . 831
Server affinity in Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Stickyness to source IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
Cross port affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Passive cookie affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
Active cookie affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
URI affinity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
SSL session ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
x Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information about the products and services currently available in your
area. Any reference to an IBM product, program, or service is not intended to state or imply that only that
IBM product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
© Copyright IBM Corp. 2007. All rights reserved. xi

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks (logo) ® Everyplace® QuickPlace®

developerWorks® IBM® Redbooks®
eServer™ Lotus Notes® RDN™
i5/OS® Lotus® Sametime®
AIX® MQSeries® System i™
Cloudscape™ Notes® Tivoli®
Domino® Passport Advantage® WebSphere®
DB2® PowerPC® Workplace™
The following terms are trademarks of other companies:
PostScript, and Portable Document Format (PDF) are either registered trademarks or trademarks of Adobe
Systems Incorporated in the United States, other countries, or both.
EJB, Java, JDBC, JNI, JRE, JVM, J2EE, J2SE, Solaris, Sun Java, and all Java-based trademarks are
trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Active Directory, Excel, Internet Explorer, Microsoft, Outlook, PowerPoint, Windows Mobile, Windows NT,
Windows Server, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United
States, other countries, or both.
Intel, Pentium, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks
of Intel Corporation or its subsidiaries in the United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
xii Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

Preface
With the release of IBM® Lotus Sametime® 7.5 and subsequently Sametime
7.5.1, IBM provides a family of enterprise-class collaboration products providing
real-time awareness, communication, screen-sharing capabilities, and IP
audio/video services. Lotus Sametime brings the flexibility and efficiency of
real-time communication to the enterprise by interconnecting employees,
customers, business partners, and suppliers.
Sametime is much more than just chat and Web conferences. It is an

open-standards-based platform for real-time collaboration. Businesses and IBM
Business Partners use Sametime 7.5.1 APIs and toolkits to build innovative new
real-time collaboration applications, and to improve any application, business
process, or third-party application.
The objective of this IBM Redbooks® publication is to provide a best practice

framework for an enterprise-scale deployment of Sametime 7.5.1. It covers a
range of business collaboration requirements that might typically be found within
many large enterprises with geographically dispersed user communities and
diverse business requirements for real-time collaboration.
Specifically, we discuss how to plan, install, and configure a Sametime 7.5.1

infrastructure that will scale to meet the needs of a large, globally distributed
enterprise. We approach the installation and configuration of Sametime in
deployment phases, beginning with implementing the community services (chat
functionality) and setting up load balancing. We next implement the online
meeting services. Building upon this infrastructure, we then discuss how to
integrate Sametime functionality with other IBM/Lotus products, including
Microsoft® Office. Finally, we complete the environment by discussing aspects of
security, administration, and recommended maintenance. Other topics covered
in this book include a discussion of the Enterprise Meeting Server and the
Sametime Gateway.
The team that wrote this book

This book was produced by a team of specialists from around the world working
at the International Technical Support Organization, Cambridge, MA, USA
Center.
© Copyright IBM Corp. 2007. All rights reserved. xiii

George Lambie is a Project Manager with IBM Software
Services for Lotus. His twenty years of IT experience include ten
years with IBM/Lotus. George joined the Lotus Development
Corporation in 1996 and has held a range of positions within
Lotus/IBM including Systems Engineer, Architect, and
Professional Services Manager. Prior to joining Lotus/IBM,
George co-founded the Lotus/IBM Business Partner Systems &
Networks Limited. He holds a master’s degree in Information
Management from the University of Strathclyde and Chartered IT Professional
(CITP) status with the British Computer Society. George is a member of the
Project Management Institute (PMI) and is a certified PRINCE2 Practitioner.
Charley Price is a Software Engineer in the IBM Software

Group, U.S. He has four years of experience in technical support
for IBM Lotus software, and two in the test organization
specializing in cross-product integration with Lotus, IBM, and
other third-party products. He holds a degree in Mathematics
Education from the University of Georgia and taught high school
mathematics for three years before joining IBM. His areas of
expertise include Lotus Domino® Integration, Lotus Domino
administration, and the Lotus collaborative portlets. He is an IBM Certified
Associate System Administrator - Lotus Collaborative Solutions (administering
QuickPlace®), a Principal Certified Lotus Professional for Domino system
administration, and an IBM Certified System Administrator for WebSphere®
Portal. In addition to this book, Charles has written numerous technotes on
cross-product integration, presented at Lotus and Portal technical conferences,
and co-authored theWebSphere Portal Collaboration Security Handbook,
SG24-6438, in 2004.
Jim Puckett works as a Senior Premium Services Manager in

North America. As a PSM, Jim works with many large
customers, recommending products, upgrades, and solutions
with all Lotus products to meet his client's business
requirements. Jim joined Lotus in 1999, and prior to becoming a
Premium Services Manager in 2005, he spent four years on the
Sametime support team in Austin, TX.
Vineet Rohatgi is an IBM Certified Software Engineer in the

Workplace™ Portal and Collaboration (WPLC) Services
division of the IBM Software Group. He has over three years of
experience supporting IBM customers using IBM Lotus
Sametime and Domino products. His areas of expertise include
Sametime and Notes/Domino.
xiv Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

Stephen Shepherd is a Senior Software Engineer in the IBM
Software Group, U.S. He has four years of experience working
on the Product Engineering team specializing in customer
cross-product integration issues and solutions and five years of
experience the Support Engineering team. He holds a master’s
degree in Mathematics from Lowell Technological Institute,
which now is the University of Massachusetts at Lowell. Prior to
joining IBM he spent twenty-two years in software development holding various
positions including Software Architect. His areas of expertise include LDAP,
Lotus Domino Integration, Lotus Domino administration and QuickPlace,
Sametime, the Lotus collaborative portlets, C, and C++. Stephen has written
numerous technotes on Domino, LDAP, and cross-product integration, and was
a contributor for WebSphere Portal Collaboration Security Handbook,
SG24-6438, in 2004.
Jennifer Wales is an IBM Certified Consulting IT Specialist in

the Workplace Portal and Collaboration (WPLC) services
division of the IBM Software Group. She has 19 years of
professional IT experience in the network integration business,
with duties ranging from systems consulting to project
management. She specializes in the design of complex and
demanding multi-system solutions based on Lotus
technologies. Her areas of expertise include Domino Server
architecture as well as Sametime Instant Messaging.
Jeff Pinkston is a Senior IT Specialist working in the West

Region for IBM Software Services for Lotus. He has more than
17 years of experience designing, installing, and managing
projects specifically using products from the Lotus portfolio.
Among his areas of expertise are Lotus Domino and Sametime
architectures, as well as migration and coexistence strategies
and implementations. He joined Lotus in 1998, and has worked
with ISSL in various parts of the organization, including consulting services and,
most recently, the Workplace Project Office. Jeff lives in the Dallas, TX, area with
his wife, Lisa, and two daughters, Cassidy and Makenzie.
Rob Fox is a Senior IT Specialist for Collaboration Products

for the Worldwide Technical Sales SWAT Team, specializing
in support and deployment of the Sametime Enterprise
Meeting Server. He has been working with Sametime since
the IBM/Lotus acquisition of Databeam. In addition to
experience with the Sametime Enterprise Meeting Server, Rob
also has experience with LDAP, Portal, and Mobile integration
with Sametime and Workplace. Rob also has gained
Preface xv
experience with Linux®, Mac OS X, WebSphere, DB2®, Single Sign-On,
Domino, and a host of other core technologies.
John Bergland is a Project Leader at the ITSO, Cambridge

Center. He manages projects that produce IBM Redbooks
about IBM and Lotus Software products. Before joining the
ITSO in 2003, John worked as an Advisory IT Specialist with
IBM Software Services for Lotus (ISSL), specializing in Notes
and Domino messaging and collaborative solutions.
Special acknowledgement to the following team

members for their contributions to this project
Andy Higgins works as a Senior IT Specialist in the
Competitive SWAT team and he has over 20 years of
experience in the computer communications business. He has
worked with e-mail systems since 1986 and with Instant
Messaging systems since 1999. His key expertise is in
interconnectivity and integration of these systems. In his current
role, he provides pre-sales consulting on Lotus products in a
competitive environment. Originally from Halifax, West
Yorkshire in the UK, he worked there for four years, moved to live and work in
Bern, Switzerland, for seven years, and most recently is to be found in the US,
where he has lived since 1996.
Jonathan Pepin is a Project Manager with IBM Software

Services for Lotus (ISSL) and leads services projects with
customers in the Americas. He specializes in projects utilizing
IBM WebSphere Portal, IBM Workplace, Lotus Notes/Domino,
and Lotus® Sametime. Prior to joining IBM in 1998 Jonathan
worked as a business consultant with Andersen
Consulting/Accenture.
Additional Contributors to this book

Thanks to the following people for their contributions to this project:
Carol Stout - Manager, Interoperability Solutions and Sametime SVT, IBM

Software Group, WPLC, Westford, MA
xvi Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

Ivan Dell'Era, Software Engineer - Product Engineering, IBM Software Group,
WPLC, Westford, MA
Wes Morgan, Consulting - Network Engineer, IBM Software Group, WPLC,

Lexington, KY
Konrad Lagarde, Software Engineer - Lotus Realtime Collaboration, IBM

Software Group, WPLC, Westford, MA
Nirmala Venkatraman, Software Engineer - Product Engineering, IBM Software

Group, WPLC, Westford, MA
William Link - Application and Integration Middleware Software, WebSphere

Application Server L2 Support, IBM Software Group, Durham, NC
Jennifer Heins - WPLC Technical Content Architect, IBM Software Group,

WPLC, IBM, Raleigh, NC
Jack Downing - Information Architect, Sametime, IBM Software Group, WPLC,

IBM, Westford, MA
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll have the opportunity to team with IBM
technical professionals, Business Partners, and Clients.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
Preface xvii
We want our Redbooks to be as helpful as possible. Send us your comments
about this or other Redbooks in one of the following ways:
򐂰 Use the online Contact us review redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbooks@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
xviii Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

1
Chapter 1. Lotus Sametime 7.5.1 in the

Enterprise
With the initial release of IBM Lotus Sametime 7.5 and subsequently Sametime
7.5.1, IBM provides a family of enterprise-class collaboration products providing
real-time awareness, communication, screen-sharing capabilities, and IP
audio/video services. Lotus Sametime brings the flexibility and efficiency of
real-time communication to the enterprise by interconnecting employees,
customers, business partners, and suppliers.
Sametime is much more than just chat and Web conferences. It is an

open-standards-based platform for real-time collaboration. Businesses and IBM
Business Partners use Sametime 7.5 APIs and toolkits to build innovative new
real-time collaboration applications, and to improve any application, business
process, or third-party application.
The objective of this book is to provide a best practice framework for an

enterprise-scale deployment of Sametime 7.5. It covers a range of business
collaboration requirements that might typically be found within many large
enterprises with geographically dispersed user communities and diverse
business requirements for real-time collaboration.
Specifically, we discuss how to plan, install, and configure a Sametime 7.5

infrastructure that will scale to meet the needs of a large, globally distributed
enterprise. We approach the installation and configuration of Sametime in
© Copyright IBM Corp. 2007. All rights reserved. 1

deployment phases, beginning with implementing the community services (chat
functionality) and setting up load balancing. We next implement the online
meeting services. Building upon this infrastructure, we then discuss how to
integrate Sametime functionality with other IBM/Lotus products, including
Microsoft Office. Finally, we complete the environment by discussing aspects of
security, administration, and recommended maintenance. Other topics covered
in this book include a discussion of the Enterprise Meeting Server and the
Sametime Gateway.
In this opening chapter, we summarize the new features of Lotus Sametime 7.5;
distinguish between the core services provided for instant messaging, presence,
and online meetings; and provide an overview of the methods used to achieve
scalability and high-availability in the enterprise environment.
2 Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

1.1 About Lotus Sametime 7.5.1
Millions of people worldwide use IBM Lotus Sametime 7.5.1 capabilities every
day to gain instant access to people and information, bring together
geographically dispersed teams, and improve individual and team productivity.
IBM's own internal deployment of Lotus Sametime serves more than 400,000
users including more than 320,000 employees across 65 countries. At the time of
writing there are an average daily number of one thousand online meetings per
day, with IBM involving more than four thousand meeting participants. The
average peak concurrency was almost 300 meetings involving 1,250
participants. Sixteen percent of all IBM online meetings involve external
participants including customers and business partners. Over 4 million instant
messages are sent each day within IBM, and there is a peak daily load of over
200,000 concurrent connections.
Apr, 2007
Lotus Sametime software 7.5.1 Lotus Sametime 7.5.1
History and Market Leadership Aug, 2006
7.5
Lotus Sametime 7.5
Widest and largest enterprise deployments 7.0
Aug, 2005
Has had almost 16 million corporate IM users Lotus Sametime 7.0
6.5.1 March, 2004
Proven deployments to 25 companies with
Lotus IMWC 6.5.1
100,000-350,000+ user deployments
3.1 Sept, 2003

27 of the Global Fortune 50 Lotus IMWC 3.1
8 out of the top 10 worldwide banks 3.0 Aug, 2002
8 out of the top 10 U.S. pharmaceutical firms Lotus Sametime 3.0
2.5
3 of the 4 most profitable companies Sept, 2001
in the world Lotus Sametime 2.5
2.0
Oct, 2000
Lotus Sametime 2.0
1.5
1999
Lotus Sametime 1.5
1.0
Dec, 1998
Lotus Sametime 1.0
June, 1998
IBM Lotus acquires DataBeam and Ubique
1998
Figure 1-1 Lotus Sametime software: history and market leadership
Chapter 1. Lotus Sametime 7.5.1 in the Enterprise 3

Lotus Sametime 7.5.1 provides instant, anytime access to people and
information through three on demand concepts:
򐂰 Presence awareness
򐂰 Business instant messaging
򐂰 Web conferencing
Lotus Sametime now uses audio integration from leading teleconferencing and
telecommunications providers to offer a single interface to both audio and Web
conferencing, as well as click-to-call functionality directly from the Lotus
Sametime Connect client.
Additionally, Lotus Sametime 7.5.1:

򐂰 Provides easy-to-use, intuitive technology that provides a rapid way to
resolve problems and settle questions through clear, high-quality
communications
򐂰 Allows quick access global teams
򐂰 Provides a cost-effective, consistent approach to real-time collaboration
within an encrypted, authenticated, and managed environment
򐂰 Offers integration with Microsoft Office and Microsoft Outlook® applications
򐂰 Includes a mobile client that can be deployed on multiple mobile platforms
and devices
Sametime services fall broadly into three areas:

򐂰 Community services
򐂰 Online meeting services
򐂰 Customization and integration services
For Customization and integration services see Extending Sametime 7.5
Building Plug-ins for Sametime, SG24-734646:
http://www.redbooks.ibm.com/abstracts/sg247346.html?Open
Community services and online meeting services are summarized in the sections
that follow.
1.1.1 Understanding the distinguishing features within Sametime 7.5

and Sametime 7.5.1
For the writing of this book we use Sametime 7.5.1 as the code base. Most of the
material written within this book applies to both Sametime 7.5 and the
subsequent release of Sametime 7.5.1.

Sametime 7.5 highlights
Highlights of Sametime 7.5 include:
򐂰 New Sametime Connect client
– Competitive UI and features
– Integrated voice chat
– Eclipse, Expeditor based
– Plug-in model for extensibility
򐂰 Server improvements
– Policies
– Performance
– Reliability
򐂰 Meeting improvements
– Significant UI update
– Improved welcome page
– Better meeting entry
– Tabbed layout
– Better handling for dropped connections
– New annotation tools
– Audio/video improvements
– Improved uploaded slides handling
򐂰 Sametime Gateway
– Written in Java™ and running in WebSphere system environment
– Provides federation among external IM systems and your local Lotus
Sametime deployment
Sametime 7.5.1 highlights

Released April, 2007, Sametime 7.5.1 builds upon the foundation of Sametime
7.5, but also includes the following enhancements and functionality:
򐂰 Linux server support
򐂰 Point-to-point video
򐂰 Tabbed chat
򐂰 Mac client for UIM and meetings
򐂰 Calendar auto-status change
򐂰 Windows® single sign-on
򐂰 Edge-to-edge view in meetings

򐂰 Office integration
򐂰 Telephony enablement
Figure 1-2 illustrates the new Tabbed Chat feature provided in Sametime 7.5.1.
Multiple chat sessions are presented in a

tabbed format
Figure 1-2 Illustrating the tabbed chat feature in Sametime 7.5.1
1.2 Lotus Sametime Services

Lotus Sametime is the first real-time collaboration product that offers a complete
range of integrated, real-time services while meeting enterprise and e-business
requirements for scalability, manageability, and security.
Sametime services fall into three areas:

򐂰 Community services: These services include awareness, instant messaging,
and chat. A buddy list makes Sametime users aware of who is available (and
who is online but unavailable) to receive an instant message or participate in
a chat with one or more people. The instant messaging traffic is encrypted.
򐂰 Online meeting services: These services include a shared whiteboard and the
ability to share programs and documents online. Sametime also offers a

server-based meeting center where users can schedule online meetings in
advance and store agendas and other meeting materials.
򐂰 Customization and integration services: Sametime also provides a
comprehensive API that enables customers to easily integrate real-time
collaborative capabilities into other applications, such as e-commerce sites,
help desks, and training/information delivery applications like customer
relationship management.
1.2.1 Community services

Most real-time communication is unscheduled and has nothing to do with
computer technology. For example, you hear the voice of a colleague outside
your office door, and you step out to speak to her face-to-face. Online, real-time
collaboration is also very convenient and most effective when it occurs
spontaneously, just like the hallway encounter. But like a face-to-face encounter,
you need to be aware of the opportunity to interact. Sametime recognizes this
fact and incorporates the ability to tell the server your availability. A user can tell
the server whether they are online, away from their computer, or they can even
ask not to be disturbed. The awareness capabilities of Sametime help make
spur-of-the-moment, online conversations as natural, convenient, and worthwhile
as a hallway chat. And, in situations where text chat may not be enough,
Sametime 7.5’s VoIP (Voice over IP) allows a much more personal and
productive tool to complement a typical text chat. Sametime makes users aware
of opportunities for online interaction via a sophisticated buddy list, used to
identify which members of a community are online and whether they are
available to interact. Sametime can obtain the identities of users directly from the
enterprise directory (such as an LDAP directory or Domino directory) or from its
own integrated directory.
Once users are aware of who is online, they can initiate interaction simply by
sending an instant message. A user might start an instant message, an online
meeting, or a telephone call — whatever suits the task at hand. For example, an
instant message is an efficient, low-bandwidth medium for the quick clarification
of an idea, but to explain the details of a design specification, a phone call may
be a more appropriate medium. Of course, nobody wants to be available for
spontaneous communication — read interruption — all the time. For this reason,
Sametime gives each user full control over their availability. Levels of
participation include active (online and available), away (offline or otherwise
unavailable), in a meeting, and do not disturb (online but unavailable).
The Sametime Community Services support all presence (or awareness), text
chat, and file transfer activity in a Sametime community. Any Sametime client
that contains a presence list must connect to the Community Services. The
Community Services clients include the Sametime Connect client, Participant

List, and public chat components of the Sametime Meeting Room Client, or
presence and chat applications developed from the Sametime Software
Development Kit.
Basic functionality supported by the Community Services includes:

򐂰 Handling client login requests.
򐂰 Handling connections from clients that access the Sametime server through a
direct TCP/IP connection, or through HTTP, HTTPS, or SOCKS proxy
servers.
򐂰 Providing directory access for user name search and display purposes.
򐂰 Providing directory access to compile lists of all Sametime servers and users
in the community.
򐂰 Dissemination of presence, chat, and file transfer data to all users connected
to Community Services.
򐂰 Maintenance and storage of privacy information, user preference settings,
and presence lists for online users.
򐂰 Interacting with the Meeting Services to create meetings in which
collaborative activities supported by the Community Services, Meeting
Services, and Audio/Video Services are simultaneously available.
򐂰 Handling connections from the Community Services on other Sametime
servers when multiple servers are installed. Server-to-server connections for
the Community Services occur on default TCP/IP port 1516.

1.2.2 Meeting services
Sametime online meeting or conferencing services provide the ability to share
objects (such as desktop applications, presentations, documents, and drawings)
online. Users can schedule an online meeting in advance, or move directly from
an instant message to a screen-sharing or whiteboard session such as the one
shown in Figure 1-3.
Figure 1-3 Sametime Meeting Center - Scheduled Meetings
Sametime allows any user to share any program from his or her desktop, such as
presentations, spreadsheets, and project management software. Other
participants are not required to have the same software in order to participate
and see what’s being shared. When appropriate, users can also pass control of
the application back and forth as necessary. The initiator can reassert control at
any time. Sametime’s shared whiteboard is the online equivalent of a typical
whiteboard in an office or classroom. Users can draw on it, show presentations,
and annotate documents on it. Sametime also converts popular file types into
pages for convenient display during whiteboard sessions.

As noted previously, Sametime fully supports both ad hoc and scheduled
meetings. Online meetings can be anything from a quick show me session
among two people, to team briefings on a new product, to a full-scale virtual
seminar involving hundreds of participants across both the WAN and the Web.
Meeting information is posted in a server-based Meeting Center, along with

agendas and preparatory materials. Invitees can access these materials anytime
before, during, or after the meeting. For maximum convenience and to eliminate
barriers to off-site invitees, users can participate in online meetings and
whiteboard sessions directly from Web browsers, without downloading and
installing special software or plug-ins. Users can also specify the type of meeting
to help manage bandwidth. For example, a user can have a meeting that is
designed to allow several people to collaborate on a specific application.

Sametime also allows a user to set up meetings that are designed for one
presenter and a large audience of observers, like an organizational or earnings
announcement. The meeting moderator decides which services (chat,
whiteboarding, audio/video, and so on) will be available to each participant. In
this way the user easily customizes the meeting based on their goals and
collaboration needs.
Figure 1-4 Sametime meeting room
The Meeting Services include the T.120 multipoint communications software that
supports screen sharing and the shared whiteboard, and the starting, stopping,
and deletion of meetings. Meeting Services also support connections for the
interactive audio/video components of the Sametime Meeting Room Client.

Basic functionality supported by the Meeting Services includes:
򐂰 Creating and destroying meeting objects.
򐂰 Handling connections from clients that access the Sametime server through a
direct TCP/IP connection, or through HTTP, or SOCKS proxy servers.
򐂰 Dissemination of T.120 screen-sharing and whiteboard data among multiple
users in a meeting.
򐂰 Maintaining lists of active, scheduled, and completed meetings.
򐂰 Starting and stopping instant and scheduled meetings at the appropriate
times.
򐂰 Interacting with the Community Services to create meetings in which
collaborative activities supported by the Community Services, Meeting
Services, and Audio/Video Services are simultaneously available.
򐂰 Allowing the administrator to control which collaborative activities are
available to end users of the Sametime server.
򐂰 Handling connections from the Meeting Services of other Sametime servers
when a community includes multiple Sametime servers. Meeting Services
server-to-server connections occur on TCP/IP ports 1503 and 1516.
򐂰 Provide the ability to record Sametime meetings in Sametime Record and
Playback (RAP) files so that users can replay meetings after the meetings
have ended.
1.3 Extendable Applications Platform

The IBM Lotus Sametime Connect 7.5.1 client is built on the Eclipse open source
platform. By building Lotus Sametime on top of Eclipse it becomes easier for
third-party developers to build plug-ins, applications, and extensions that
integrate directly into Lotus Sametime.
Eclipse is an open source community focused on building an open development

platform comprised of extensible frameworks, tools, and runtimes for building,
deploying, and managing software across the life cycle. A large and growing
community of major technology vendors, innovative start-ups, universities,
research institutions, and individuals extend, complement, and support the
Eclipse platform.
Originally developed by IBM, Eclipse is now managed by the Eclipse Foundation,

an independent not-for-profit consortium of software industry vendors. Many
notable software tool vendors have embraced Eclipse as a future framework for
their Integrated Development Environments (IDEs).

1.3.1 Client extensibility
Client extensibility includes the following:
򐂰 Plug-ins allow IBM, partner, and customer extensions, for example, support
both Sametime and SIP (Workplace).
򐂰 Built on open standards (Eclipse-based).
򐂰 Ability to integrate with advanced plug-ins, that is, LDAP, third-party
softphones, high quality video, calendar lookup, and so on.
򐂰 Broadcast Suite (skilltap, freejam, instant polls, and so on) introduces
collaborative tools that interact with the ST client.
򐂰 A client can work with any backward release of the Sametime server. You do
not need to upgrade your whole infrastructure to use the benefits of the new
ST 7.5 client.
1.3.2 Server extensibility

Server extensibility includes the following:
򐂰 Provided through the Sametime Gateway (discussed in Chapter 11,
“Sametime Gateway” on page 739)
򐂰 Interconnectivity with other IM products
򐂰 Federation with external IM services and domains
For more information about using the Eclipse framework to develop plug-ins for
Sametime see the see the IBM Redbooks publication Extending Sametime 7.5
Building Plug-ins for Sametime, SG24-7346:
1.4 Audio Visual Capabilities

Audio Visual (A/V) capabilities have been built into Sametime since the earliest
versions of the product. Lotus Sametime 7.5.1 includes integrated Voice over IP
(VoIP) and new options for telephony and video integration.
Business partners in the specialist audio and video areas are today working with
Sametime 7.5’s extensible Eclipse framework to integrate audio, video, and
PC-based collaboration tools. Supporting IBM in this area are a number of
industry leaders, such as Avaya, Avistar Communications Corporation, Nortel,
Polycom, PhoneSoft, Premiere Global Services, Siemens, and Tandberg.

The convergence of leading telephony capabilities with IBM collaboration
solutions will provide customers with click-to-call capabilities, so you can place a
phone call to a colleague directly from your inbox or buddy list.
The integration of video capabilities enables businesses to embed

business-quality video into their existing Web conferencing, instant messaging,
and e-mail infrastructure, helping organizations further enhance communications
and extend their existing investments.
1.5 Key concepts: scalability, performance, and high

availability
As we address the concept of enterprise-scale deployment, it is important to
clarify the terms and concepts for scalability, performance, and high availability.
1.5.1 Scalability
This book is written specifically with enterprise-scale deployments of IBM Lotus
Sametime in mind. By enterprise deployment we generally think in terms of
organizations involving collaboration between thousands or tens of thousands of
people, or more. Where these large-scale deployments differ from smaller scale
implementations is typically in the areas of the complexity, systems performance,
and availability. These aspects are less likely to be encountered within a small
enterprise environment. This is not to say that performance and availability are
not important to smaller organizations; patently they are, but these requirements
are more readily achieved for smaller user populations without the need for
complex architectures.
Scalability, high-availability, and systems performance inevitably come at a cost.

If cost were no object then we could design a system that could include multiple
layers of redundancy and would be massively over-engineered to support a
much greater number of users than actually required. In the real world, however,
most enterprise IT departments do not have the luxury of limitless funds and they
are subject to the budgets and spending constraints such that their choices
regarding levels of availability and performance must be appropriate to the level
of service demanded by the business. Most enterprises will therefore implement
systems architectures that are fit for purpose — designed to meet the quality
expectations that the service requires.
Organizations must also be mindful of how service requirements can change

over time. The usage of collaborative tools like IBM Lotus Sametime can grow
dramatically as users discover the powerful capabilities that they provide. A
solution that was regarded initially as a peripheral add-on to the enterprise

messaging and groupware service can itself come to be regarded as business
critical. Capacity requirements can also grow over time — organically as staffing
numbers increase steadily as a business grows or dramatically as when
organizations merge or when one business acquires another. The systems
infrastructure should therefore be designed with capacity in mind and should be
able to accommodate changing capacity requirements over time, either through
vertical scalability (scaling up by adding processors, storage, memory, and so
on) or through horizontal scalability (scaling out by connecting multiple
independent computers together so that they work as a single logical unit and
provide more processing power).
1.5.2 Scalability with Sametime Multiplexors

Scalability in a Sametime system is achieved both by vertical and horizontal
scalability methods. Sametime servers providing Community Services are made
vertically scalable by ensuring that the servers have more than adequate
resources of memory, processors, and storage. Horizontal scalability may be
achieved both by spreading the user load over multiple servers in a Sametime
server cluster and by off-loading the user connection management to a separate
Sametime Community Services multiplexer (or mux).
During a basic Sametime server installation, the Community Services multiplexer

is installed with all other Sametime components on the Sametime server
machine. The Sametime server CD provides an option to install only the
Community Services multiplexer component. This option enables the possibility
of installing the Community Services multiplexer on a different machine than the
Sametime server. When the Sametime Community Services multiplexer is
installed on a different machine from the Sametime server, the Sametime client
connects to the Community Services multiplexer machine, not the Sametime
server. This configuration frees the Sametime server from the burden of
managing the live client connections. The multiplexer machine is dedicated to
this task.
In the later chapters of this book we discuss how the Community Services
Multiplexor can be best deployed to provide improved scalability and efficiency
for Sametime Community Services.
1.5.3 Load balancing, server clustering, and failover

Load balancing aims to improve capacity and performance by equally distributing
the user loading over several devices. In an infrastructure supporting Lotus
Sametime, load balancing may be deployed at different levels and for different
purposes. Load balancing devices such as the IBM Edge Server or F5 Network’s

BIG-IP can be placed in front of either Sametime Multiplexors or Sametime
servers to achieve an even distribution of connections (IP Spraying).
Clustering of Sametime servers can also be implemented to achieve load

balancing. A Sametime Community Services cluster consists of multiple
Sametime servers configured to operate together, providing failover and load
balancing for the Sametime instant messaging and presence functionality.
Failover aims to ensure that a large community of Sametime users has

continuous access to the Community Services. If a server fails, the users in the
community are reconnected to a different Sametime server in the Community
Services cluster to receive the Community Services functionality.
In later chapters of this book we discuss in detail best practices for clustering
Sametime Community Services and also describe how the performance and
capacity of the infrastructure supporting the Sametime Meeting Services can be
improved by using an Invited Server Model and distributing users over multiple
regional servers. A specific chapter of this book is also dedicated to describing
how high availability can be achieved for Sametime Meeting Services by using
the IBM Lotus Enterprise Meeting Server (EMS).
1.6 Introduction to the Enterprise Deployment Scenario

The following chapters in this book discuss the deployment considerations that
would be appropriate to an enterprise deployment of Lotus Sametime 7.5.1
within a large organization. To facilitate this discussion, an example scenario is
referenced throughout the book to provide examples of how to plan for and
deploy the various services and functionality provided within Sametime 7.5.1 in
the context of the fictional ITSO Corporation.
The fictional ITSO Corporation is a global management consulting, technology

services, and outsourcing company. Its organizational structure includes
divisions based on client industry types and employee work forces. Industry
divisions, referred to as operating groups, include products, communications and
high technology, financial services, resources, and government. The employee
workforce divisions are respectively titled Consulting, Services, Enterprise, and
Solutions.

The ITSO Corporation is organized around three geographic regions: North
America, Europe, and Asia Pacific. These regional business units include the
consulting, services, enterprise, and solutions divisions. The group employs
approximately 120,000 people who are geographically dispersed as shown in
Figure 1-5.
Figure 1-5 ITSO Corporation geographic regions
A summary of ITSO Corporation's requirements for real-time collaboration is

listed below. In later chapters we expand upon these requirements and see how
they can be accommodated within the Sometime 7.5.1 architecture and
deployment. Also refer to 2.6, “Overview of the global architecture proposed for
ITSO Corporation” on page 56, for a more specific discussion of the Architecture
designed for ITSO Corporation’s Sametime infrastructure.
򐂰 The solution architecture must be scalable and extensible to accommodate
growth in the organization — both organic growth over time and also the

dramatic growth that would be expected in a situation where ITSO might
acquire another sizable consulting company.
򐂰 The solution must meet performance requirements and meet with ITSO
Corporation's specific response time requirements.
򐂰 The solution must be robust and stable and meet with the systems availability
metrics documented within ITSO Corporation's Service Level Agreements.
򐂰 The solution must be demonstrated to be secure and meet with ITSO
Corporation's corporate security policies.
򐂰 The solution must be capable of integration with other real-time collaboration
tools used within ITSO's clients, business partners, and suppliers.
1.7 Overview of the deployment approach taken

throughout this book
Throughout this book we provide detailed steps on how to plan, install, and
configure each of the components within a typical large-scale deployment. As
described in 1.6, “Introduction to the Enterprise Deployment Scenario” on
page 16, this is based on a fictitious company, ITSO Corporation. Section 2.6,
“Overview of the global architecture proposed for ITSO Corporation” on page 56,
builds upon this fictitious scenario and describes the proposed architecture.
Overview of Approach for Deployment
1 2 3
Deployment Deployment Deployment

Phase I Phase II - Integration Phase III – Advanced
- Community Services - Integration with other products - LDAP Extension to include
- SA Muxes - Domino / DWA - Business Cards
- Clustered Chat Servers - Quickplace - Security
- Load Balancer - Portal - Reverse Proxy
- Meeting Services - RTC Gateway - Single sign-on (SSO)
- ST Mobile - Firewalls
- ST Links
- Bots
- MS Office Product Integration
User Directory
Figure 1-6 Overview of the approach for deployment

Figure 1-6 on page 18 illustrates a conceptual approach in building the
environment in this book.
򐂰 Chapter 2, “Planning a Sametime 7.5.1 Deployment” on page 21, discusses
the key considerations and aspects of planning for a successful Sametime
Deployment.
򐂰 At the foundation of a Sametime Deployment lies the User Directory. In
Chapter 3, “LDAP User Directory - foundation for Sametime” on page 79, we
describe the role of the directory and the key concepts and attributes specific
to Sametime 7.5. Within this chapter, we also describe how install and
configure IBM Tivoli® Director V6.
򐂰 Deployment Phase I is covered in two chapters:
– Chapter 4, “Deployment phase 1 - implementing Community Services” on
page 129, focuses on building the community services (chat)
infrastructure and installing/configuring a load balancer.
– Chapter 5, “Deployment phase I - implementing Meeting Services” on
page 281, builds directly upon this chapter and discusses how to
implement the meeting services infrastructure.
򐂰 Chapter 6, “Deployment phase II - integration with other products” on
page 329, expands that Sametime infrastructure by integrating Sametime
with applications such as Portal, Domino Web Access, and Microsoft Office
Applications.
򐂰 Chapter 7, “Deployment phase III - securing the environment” on page 537,
illustrates the considerations and techniques for securing the environment.
򐂰 Chapter 8, “Sametime Client deployment considerations” on page 631,
discusses the features of the Sametime 7.5.x client and outlines
recommended approaches for client deployment.
򐂰 Chapter 9, “Systems management and maintenance” on page 691, provides
a look at some of the recommended practices for managing and maintaining
your Sametime environment.
򐂰 Chapter 10, “Enterprise Meeting Server” on page 703, discusses the
architecture of EMS, and discusses how to install and configure it.
򐂰 Chapter 11, “Sametime Gateway” on page 739, describes the architecture
and features of the Sametime Gateway and describes how to configure it.
Finally, the following appendices deal with specific considerations for other
directories.
򐂰 Appendix A, “Directory considerations for Active Directory” on page 751.
򐂰 Appendix B, “Directory considerations for Domino LDAP” on page 799.

򐂰 Appendix C, “Project management guide for an Enterprise Sametime
deployment” on page 811, discusses key aspects of how to successfully
manage a large scale Sametime Deployment effort.
򐂰 Appendix D, “Introduction to load balancing - WebSphere Edge components”
on page 819, is a follow on from the earlier information that specifically
discussed how to install and configure the load balancer.

2
Chapter 2. Planning a Sametime 7.5.1

Deployment
The deployment of any product is always made easier by asking as many
questions as possible before starting. The installation of Sametime 7.5.1 is not as
complicated as that of many other software products, though it still requires good
planning for a smooth start.
This chapter discusses the issues you should consider while planning your
Sametime deployment.
The major items to consider are:

򐂰 User population
򐂰 Clients
򐂰 Servers
򐂰 Networking
򐂰 Service availability
򐂰 The directory service you choose
To help frame the deployment discussion within the context of a realistic

enterprise scale deployment, we introduce and build upon a fictitious scenario
using ITSO Corporation.

2.1 Population topology
To begin planning your Sametime Deployment Architecture and necessary
topology, we begin by addressing basic questions about your user community.
These basic questions include, but are not limited to:
򐂰 How many people in your organization will use Sametime?
򐂰 From how many different physical locations?
򐂰 How many people do you expect will be using Sametime concurrently?
򐂰 What types of Sametime services will they be using? Chat? Instant and
Scheduled Meetings?
򐂰 What type of users are they? Basic users or power users? Basic users
primarily exercise only the core awareness and chat functions of the Connect
client, while advanced users make frequent use of features such as
voice/video chat, file transfer, and inline images.
򐂰 What types of clients will you be supporting? Will your users be connecting to
Sametime with multiple clients concurrently?
These seem like pretty basic questions, but they often get overlooked, or not
properly considered until too late in the planning process. Through out this book
we describe and make reference to our fictitious company ITSO Corp. We
introduced ITSO in Chapter 1, “Lotus Sametime 7.5.1 in the Enterprise” on
page 1, and continue to discuss the details of our company to better demonstrate
the reasons behind our deployment strategy. The examples we provide make it
easier to understand how this can be applied to many other types of
deployments.
Always keep the following sentence in mind when you are going through this
book, and even write it out on your whiteboard where everyone can see it: There
is no single best deployment option when it comes to Sametime. Why? Each
company has its own specific needs and business considerations. It is as simple
as that. Sametime is an extremely flexible product and offers many different
types of integration points. This makes the product very simple and also complex
for often the exact same reasons. One useful way to get started is to think in
terms of what Sametime functions you will be supporting for your deployment,
and estimate the number of users that will need those functions at any given time
(concurrent usage).
Important: There is no one-size-fits-all when it comes to planning a Sametime

deployment.

Since each Sametime service will have a different impact to your networks,
servers, and clients, looking at your population of users in terms of how they will
be using Sametime and where those users are located will help in going through
the planning considerations in this chapter.
2.1.1 Determining different classes of users

Let us look at a one way of breaking down your users into different categories or
classes of users, which will make it much easier to build your Sametime
architecture.
For example, our fictitious company, ITSO Corporation, is a consulting company

with 120,000 employees world wide. Of those, there are 75,000 in the U.S.,
30,000 in Europe, and 15,000 in Asia Pacific. So now let us break down that total
into classifications of users. This is going to help us in two ways:
򐂰 Job function or classification can help us decide what functions of Sametime
users may be interested in. Since the services impact the planning, this is
going to be useful. This could also be used if you are introducing Sametime
for the first time, and want to stage the roll-out into the company.
򐂰 This breakdown can also be useful for determining number or users
connecting to Sametime. Concurrent usage is the key concept for sizing your
deployment for your user community.
Table 2-1 Analysis of different classes of users for ITSO Corporation

ITSO Corp North America Europe Asia Pacific
Executives 2000 1000 1000
Sales 9000 4000 2000
Tech Support/Help 1000 1000 0

desk
Administrative 7000 2000 1000
Field 34000 10000 6000

Personal/outside
sales
Staff/Other 22000 12000 5000
For ITSO Corp, for example, we would look at this chart and go through the
following thought process in our planning stage.
By the nature of our business, we can expect that nearly all of our 120,000
employees are in the potential for Sametime usage. However, for our planning
Chapter 2. Planning a Sametime 7.5.1 Deployment 23

purposes we want to look at areas like field personal/outside sales. This is our
group that spends more time traveling and working remotely, such as at a
customer site. We would plan for these 40,000 employees to not spend the
majority of the work day connected to our network or using Sametime. This is
also a group of users that we might look at to provide with Sametime Mobile
Clients. Since we also know how many of this category of users are in each
region, we use this information to size the servers in our deployment plan.
We also want to think of the groups that would be the heaviest users of
Sametime chat and On-line Meetings. We expect that the sales team,
executives, and outside sales would fall into this category. Our help desk is also
using Sametime On-line Meetings to assist in working on many different types of
problems. If your help desk personnel are not already using Sametime in this
manner, start thinking about it now.
Therefore, our estimates of Sametime usage at ITSO Corp would look like in
Table 2-2.
Table 2-2 Classifications of users - types and population within ITSO Corporation
ITSO Corp Americas Europe Asia Pacific
Number of users in 75,000 30,000 15,000

region
Projected number 60,000 25,000 10,000

of community
connections per
day
Projected peak 40,000 18,000 7,500

concurrency of
community
connections per
day
Projected 3,000 1,250 500

concurrency of
n-way chat
sessions
Projected number
of Basic Chat users
Projected number
of Power Chat
users

ITSO Corp Americas Europe Asia Pacific
Projected average 120 80 30

for number of
scheduled
meetings per day
Projected number 60 35 15
or peak
concurrency of
scheduled
meetings
Percentage of 10% 10% 10%

scheduled
meetings expected
to involve
participants from
two or more
geographic regions
You will see later in this chapter that our Europe and Asia Pacific numbers will
need to be merged. We show the deployment option we chose, and how it works
for our current needs, and how this approach makes it very easy for us to scale
the deployment to support a larger capacity, as our company grows in both of
those regions.
Important: When architecting your Sametime environment, be sure to include

additional capacity to handle your company growth. Sametime tends to be
viral in nature and once your users begin to use it and see how it changes the
way they work, you may find that you have exceeded your projected usage.
2.2 Network topology considerations

Sametime is a real-time communication product and only as good as the network
is runs on. When planning your Sametime deployment, keep your users’
networking capacity in mind. Consider questions such as:
򐂰 Are you using low-bandwidth connections from remote sites?
򐂰 Are all your users in one site, or are they scattered across the world?
򐂰 How congested is your current network?
Sametime does not use a peer-to-peer network model that some other
conference tools do, so all communications must be routed through a Sametime

server. The advantages of this become apparent once you move beyond small
meetings and into larger interactive meetings.
Note that even low-speed connections function very well for online status and
text IM functions. Instant message data transmissions are usually measured in
mere bytes (far less than 1 K per message), and any lag encountered usually
occurs because of routing delays rather than the time required to actually
transmit the data.
At ITSO Corporation, the North American users and European users are mostly
using fast network connections, while Asia Pacific is connected via a relatively
slow connection (see Figure 2-1).
Figure 2-1 Network topology
We also have a large group of users that are in the field. Sales personal will
often be working from home offices, customer sites, or even WI-FI hot spots. Will
this work for Sametime? Of course. Our experience to date has shown that text
IM is the single most popular function of Sametime, and the lightest one in terms
of impact on your network. Therefore, you should have no reluctance
implementing IM clients at the end of even the slowest network connection or for
users on wireless networks.
For meetings, the Sametime 7.5.1 Meeting Room Client (MRC) has been
improved to better handle slower connections. It does this in part by making
re-connection attempts behind the scenes, so that there is no need for an
interaction from the user, unless the re-connect fails three times in a row. During

the re-connection attempts and then finally the actual reconnection, the user
does not drop out of the MRC, so in some cases, it can be a fairly seamless
event. We still need a good solid network for optimal performance, but with these
types of improvements in managing connections, we lessen the negative impact
to the users compared to earlier versions.
It is also important to note that setting prioritization for Sametime traffic on your
networks could have a big performance improvement for your users that are
coming across slow links, or already crowded connections. In a later section you
will see which ports Sametime uses. This information will be useful for you if you
need to discuss prioritization or firewall configurations with your network team.
2.3 Client considerations

Beyond just knowing how many users you have, you need to look at the types of
clients that you will be supporting for connecting to the Sametime servers.
2.3.1 Primary clients for Sametime 7.5.1

The primary clients are:
򐂰 The 7.5.1 Connect client is the latest and most feature rich client available for
Sametime and the one we expect the majority of customers to deploy.
򐂰 Notes 8 Integrated Instant Messaging Client. The new Notes 8 client now
includes a full version of the Sametime 7.5.1 Connect client. This will have all
of the same features and functions that the stand-alone version has.
򐂰 Notes 7.0.x and 6.5.x Integrated Instant Messaging client. These pre-Notes 8
clients have less functionality than the ones listed above. They provide chat,
presence awareness, and in the later versions an option to get to meetings.
However, all the new 7.5.x features and functions are not available.
򐂰 Java Connect client. This Web-based client can still be used with the
Sametime 7.5.1 servers, however, it is no longer provided as part of the
Sametime 7.5.1 install files. See Chapter 9, “Systems management and
maintenance” on page 691, for more information about how to install this
client if required in your environment.
򐂰 ST Mobile Client. This new Mobile Client is a much richer experience for your
mobile users than what was available in previous versions. There is a limited
emoticon pallet, chat history, and Quick find function.
򐂰 Other client types:
– Domino Web Access (DWA) Sametime Integration
– Contact List Portlet available with WebSphere Portal

Supporting and deploying all of the Clients is not required. However, you can
expect that you may need more than one type of client to meet the needs of your
users. It is also important to know that if your users are going to be using two (or
more) clients at the same time, this does impact your capacity planning. For
example, if a user logs into the 7.5.1 Connect client, and also uses a Notes client
for Notes IM, this does count as two connections to the server. There is more on
this later in the chapter where we discuss details on capacity planning. Also, in
Chapter 8, “Sametime Client deployment considerations” on page 631, we get
into the details of each of the Sametime Client types.
2.3.2 Client PC
Desktops and mobile computers are the primary means that your users will use
to interact with the Sametime server. These machines need to have enough
power to support the demands placed on them by Sametime and any of the other
applications that are deployed for your users. If using Sametime Meetings, they
also need to download and execute the signed Java Applets. For the Meeting
Room Client (MRC), the user no longer has to have administrator rights to the
local machine. Many of the pop-up style windows have also been removed so
that the MRC is much easier to install and use for your end users.
The Sametime software and hardware requirements for the client PC are fairly
modest. But with the number of new features, functions, and other products that
your client machines may need to host, it is best to have machines that are
above the system requirement minimum specs. If you are planning to have A/V
integration or make use of many of the new plug-ins for the clients (in Sametime
7.5.1 or in Notes 8) you will find that 1 GB of RAM is more of the minimum
configuration for an improved end-user experience. See 2.9, “Ports used by the
Sametime server” on page 70, for full system requirements. And also keep in
mind that the third-party plug-ins that are now available for Sametime 7.5 and
Sametime 7.5.1 may have separate recommendations posted by the vendors.
2.4 Deployment options

The following section discusses several different deployment options, allowing
you to understand the key advantages for each, and to help identify the
deployment approach that will best meet the needs of your organization.

The deployment options discussed are as follows:
򐂰 “Deployment option - single Sametime server” on page 29
򐂰 “Deployment option - dedicated Sametime servers” on page 33
򐂰 “Deployment option - multiple Sametime servers” on page 33
򐂰 “DeploymeNt Option: Separated Community Multiplexing” on page 38
򐂰 “Deployment option: SA mux in remote locations” on page 40
򐂰 “Deployment options for high availability” on page 40
򐂰 “High-availability deployment option - Community Services clustering” on
page 43
򐂰 “Deployment option - Sametime in the extranet” on page 46
2.4.1 Deployment option - single Sametime server

A Sametime server provides the Community and Meeting Services necessary to
support the collaborative activities of the end user.
Community Services provide for a number of capabilities including online

awareness, support for one-to-one instant messaging sessions, and n-way chat
conferences. An n-way chat conference is an instant messaging session
involving three or more users. Previous releases of Sametime allowed only
text-based instant messaging sessions, but with Sametime 7.5.1, end users can
also participate in video and voice chats, send rich text such as inline images and
emoticons, and transfer files.
Meeting Services provide online meeting capabilities including screen-sharing,

whiteboard, interactive audio/video, send Web page, and polling meeting
activities. The Sametime recorded meeting functionality is also considered a
Meeting Service.
Sametime meetings can be instant or scheduled in advance within the

Web-based Meeting Center. Instant meetings are initiated on-the-fly from within
an active chat session and are provided by the Community Services portion of
Sametime. Scheduled meetings can be created to start now or at a specified
time on one or more servers in the community depending on your configuration.

Capacity
Important: This data is intended to be used as a general guideline.

򐂰 Actual performance and scalability may vary based on other infrastructure
variables and factors specific to your organization.
򐂰 These capacity numbers need to be reviewed and considered within the
context of each specific deployment option. Refer to 2.4, “Deployment
options” on page 28, and the subsequent scenarios to better understand
influencing factors.
When planning for capacity of your Sametime environment, you must first decide
what functions the server will provide. Will the server be dedicated to a single
function or will the server be providing a combination of both Chat and Meeting
Services?
Dedicated chat servers

A single dedicated Sametime server can provide sufficient capacity to support
chat for between 25,000 and 30,000 connections depending on the planned
usage patterns as described below. When sizing for chat, we use the term
connections instead of users, as you may have a single user connecting to
Sametime from multiple clients. For example, you may have one connection for
your Sametime Connect client, another for your Sametime-enabled Lotus
Notes® client, or yet another while browsing a Sametime-enabled application on
your Intranet. Each of these clients represents a separate connection to
Sametime and must be accounted for in your planning.
Another consideration when planning your Sametime environment for chat is the
usage patterns of your end users. Basic users who have a modest size buddylist
and utilize only the core chat functions of online awareness and chatting have
less of an impact on the Sametime server than an advanced user who, in
addition to the basic functions, will make frequent use of features such as
voice/video chat, file transfer, and inline images.
Be sure to consider how Sametime will be utilized when deciding how many
simultaneous chat connections you will plan to support on a single server.
Tip: Server-based file transfer is a CPU-intensive activity that puts a

tremendous load on the Sametime server. When considering using this
capability with virus scanning, be sure to consider how this activity will affect
your overall server capacity and plan for ample processing power to handle
this additional load.

Dedicated meeting servers
A single dedicated meeting server can provide sufficient capacity to support
either 200 simultaneous meetings or 1,000 concurrent meetings users,
whichever comes first. These recommendations are not derived from limits
hard-coded into the product, but they do represent best practice
recommendations for overall server sizing. Your mileage may vary greatly
depending on what tools are used by your end users, as described below:
򐂰 Presentation mode is the term used when slides are uploaded and shared
during a Sametime meeting. This type of meeting will yield the best
performance since the resolution and color depth are set at the Sametime
server and will be optimal for a meeting with a large number of participants.
򐂰 In application sharing mode, the meeting moderator is sharing an application
on her screen. This mode has a greater impact on capacity since the
bandwidth required for the meeting is going to be impacted by the screen
depth and resolution set on the moderator’s machine.
When an end user is creating a Sametime meeting, he does not have a choice
for presentation or application sharing mode. However, the tools that are chosen
have a direct impact on server capacity.
Tip: Be sure to educate your users about the available meeting modes and
the performance implications of their choices to ensure that they have the best
possible user experience.
Combination chat and meeting server

When sizing a single Sametime server, you may find that you require a different
mix of chat connections and concurrent meeting users. To make it easier for you
to model what you can support in your organization, imagine that a Sametime
server has a total number of capacity points available and each individual service
or connection uses a particular number of those points.

For a fully loaded combination chat and meeting server, the total number of
capacity points is 30,000. Each client type that accesses the Sametime server is
represented by a point, as shown in Figure 2-2 on page 33. Remember that an
increase in the use of one service reduces the capacity in another service area.
Also, keep in mind that your users may be accessing Sametime from more than
one client at a time, thus increasing the overall number of connections and
capacity points used on the Sametime server.
Client type Per connection

point
Basic user (Legacy Client or 7.5.1/Notes 8 1

Integrated Client with modest buddylist, using core
chat functionality)
Advanced user (7.5.1 Client/Notes 8 Integrated 1.2

Instant Messaging Client using advanced features:
voice/video chat, file transfer, and inline images)
Sametime links user (Web browser user browsing 1

Sametime-enabled Web site)
Meeting user (no A/V) 30
For example, in your environment, you may require only 20,000 basic
Sametime 7.5.1 connections for your chat users. Using the information in
Figure 2-1 on page 26, you can see that 20,0000 users equals 20,000 points and
that you will have 10,000 capacity points remaining that can be used for
additional client connections or meeting users.
Keep in mind that these are guidelines to help you plan for capacity in your
environment. With capacity planning, you cannot simply set it and forget it. You
must monitor and continue to tune your environment to ensure that you are
achieving acceptable performance levels. In addition, these guidelines assume a
dedicated Sametime server. While it is possible to install Sametime on top of
other Domino servers (such as a mail or application server already installed), we
do not recommend this practice.
It goes without saying that a single Sametime server has no redundancy. If you
require high availability for your Chat or Meeting Services, you will have to plan
for chat clustering or Enterprise Meeting Servers (EMS). We discuss these
advanced topics later in this book. For chat clustering, see 4.3, “Deploy clustered
chat servers” on page 133. For EMS, see Chapter 10, “Enterprise Meeting
Server” on page 703.

2.4.2 Deployment option - dedicated Sametime servers
Sametime does not limit you to using a single server. You can connect multiple
servers together within a single community to create a Sametime environment
that matches your company’s business requirements. There are no defined
upper limits on how many Sametime servers you can have linked together, but
there are practical limits imposed by your network design and server locations.
When designing your Sametime infrastructure, you may decide to configure your
servers in a dedicated fashion, handling only chat or scheduled meetings, but not
both. By dedicating servers to a particular function, you can more accurately plan
for and scale the environment because the workload is consistent and
predictable.
For example, in your environment, you may require your Sametime environment
to support 30,000 chat connections and 1,000 concurrent meeting users. Rather
than having two individual full service Sametime servers to handle the planned
load, you could instead set up your servers to be dedicated to chat or meetings,
as shown in Figure 2-2.
Sametime Web Browser

Connect Meeting
Client Room Client
Chat Meeting
Server Server
Server 1 Server 2
Figure 2-2 Example - servers to be dedicated to chat or meeting servers
2.4.3 Deployment option - multiple Sametime servers

Another popular option for deploying Sametime is to locate servers on opposite
sides of a Wide Area Network (WAN). This allows you to provide service to the

local users with minimal delay and minimal impact to your network. The choice to
deploy servers in this configuration depends highly on where the users are and
the network that connects them.
Consider this example: Let us suppose that you are planning a Sametime
environment for 20,000 7.5.1 users and a nominal amount of meetings. In the
United States (U.S.) you have roughly two-thirds of the population across 15
cities that are connected with high-speed connections. The remaining one-third
of the users reside in Asia Pacific (AP) with high-speed connections from their
home country to the AP hub site.
From a capacity standpoint, you could easily support this entire load on a single
server in the U.S., but in this configuration, 7,000 AP users would be required to
maintain individual chat and meeting connections across the WAN. In this
scenario, you may want to consider deploying a full Sametime server in AP
instead, as shown in Figure 2-3.
North America Asia Pacific

13,000 Users 7,000 Users
Instant Instant
Messaging Messaging
Users Users
Multiplexer Multiplexer
Community Services
1516 Community Services
1503
Meeting Services 1352 Meeting Services
Sametime 7.5 Sametime 7.5

Server 1 Server 2
Figure 2-3 Example - deploying a full Sametime server in AP
Positioning the Sametime servers this way allows the 7,000 AP users to connect
locally to server 2, thus condensing traffic between the regions over very few
TCP/IP connections.

Note: Connectivity requirements when connecting Sametime servers across
an internal firewall between sites include TCP/IP ports 1352 for Domino RPC,
1516 for Community Services, and 1503 for Meeting Services.
The other benefit to this model is that it insulates the AP location from outages
that are caused by the Wide Area Network. In the event of a network outage
between the U.S. and AP, both sites would continue to have Sametime services,
although they would not have awareness between the regions. This model also
allows each region to be able to perform scheduled maintenance without
impacting the entire community.
In this multiple-server example, it is important to note that the U.S. and AP

servers are providing both Chat and Meeting Services. From a conceptual
standpoint it is the same as having four functional servers, as shown in
Figure 2-4.

Web Browser Sametime Sametime Web Browser

Meeting Connect Connect Meeting
Room Client Client Client Room Client
Multiplexer Community Services Multiplexer

Community Services 1515 Community Services
Meeting Services
Meeting Services 1503 Meeting Services
Domino
Sametime 7.5 1352 Sametime 7.5
Server1 Server2
Figure 2-4 Conceptual example - same as having four functional servers
When connecting two community servers together in a standard fashion (not

clustered) users are configured to be homed to one of the available servers.
Homing a user simply means that you designate a home server for each user in
the Sametime directory, in our example, either Server1 (North America) or
Server 2 (Asia Pacific). North America users log in with a Sametime client to

server 1 and Asia Pacific users log in with a Sametime client to server 2. Once
logged into Sametime, they have awareness of all users and can initiate a chat
with other online users regardless of the server they connect to.
Meeting servers function a bit differently than Community Servers do. They can
be set up to be isolated or connected together depending on your business
requirements. Isolated servers are best for a group of users who rarely need to
collaborate with users outside of their group. Connecting servers together in a
fashion known as inviting gives you additional flexibility, allowing a meeting to be
dynamically shared across all meeting servers for access by a large population
across different locations. The invitation process can be configured for all
meetings or individually set at meeting creation time, as shown in Figure 2-5.
Figure 2-5 Configuring invitation process
Using Meeting Services in this way allows you the flexibility to support both local
and global meetings and preserves the WAN bandwidth by providing a local
entry point to Meeting Services for all users.

Given the setup in the previous example, you can continue the pattern and
establish servers for each logical area of your business, and then link all of the
servers together. Figure 2-6 illustrates a case where users are concentrated in
three regional locations.
Europe
10,000 Users
Instant
North America Messaging
Asia Pacific
13,000 Users Users 7,000 Users
Instant Instant
Messaging Messaging
Users Users
Multiplexer
Community Services
Meeting Services
1516 Sametime 7.5 1516

1503 Server3 1503
1352 1352
Multiplexer Multiplexer
Community Services
1516 Community Services
1503
Meeting Services
1352 Meeting Services

Server1 Server2
Figure 2-6 A case where users are concentrated in three regional locations
Each of these three sites operates a local Sametime server. They are linked
together via the WAN. Each server provides Sametime community and meeting
services for the local population, and relays any required connections or meeting
data over the WAN to remote users. Should a WAN link be broken, local services
would not be affected. Users would still have access to chat and meeting
services within their region. Any remote meeting attendees or chat sessions
would, of course, be lost until the links are re-established.
As you get into larger Sametime deployments, the options and setup naturally
grow more complex, but by keeping the essentials in mind, you should be able to
design a system that will fit your network’s strengths.

2.4.4 DeploymeNt Option: Separated Community Multiplexing
One deployment option to consider is not part of a standard Sametime server
setup, but is a documented feature in the administration guide under “Deploying
a Community Services multiplexer on a separate machine.”
Each Sametime server contains a Community Services multiplexer (or mux)

component. The function of the mux is to handle and maintain connections from
Sametime clients to the Community Services of the Sametime server.
You can offload this function of managing client connections to a specialized

server called the standalone multiplexer (SA mux). See Figure 2-7.
In an environment where the SA mux is broken out from the Sametime server, all
chat clients connect directly to the SA mux. The SA mux in turn connects to
Sametime over a single TCP/IP connection over port 1516. By handling the client
connections, the SA mux reduces the overall load on the Sametime server, which
allows for greater overall capacity, as you will see in the upcoming examples.
Client PCs Client PCs
Sametime Sametime
MUX1 MUX2
1516 1516
Multiplexer
Sametime 7.5 Server
Figure 2-7 SA mux reduces overall load on Sametime server

Note: The SA mux machine dedicates its system resources to handling client
connections but does not perform other Community Services processing.
Other services such as those used by Instant meetings, and so on, all directly
connect back to the Sametime server that is hosting the meeting.
Using SA muxes with Sametime has several benefits for large communities, but
the most notable is one of capacity. Earlier we said that a single dedicated
Sametime server can provide sufficient capacity to support chat for between
25,000 and 30,000 connections. When adding one or more SA muxes to the
environment, our formula changes. Because the SA mux only handles client
connections and none of the other Sametime services, it can handle significantly
more client connections (30,000–50,000).
It is possible to scale your Sametime environment by adding additional

Sametime servers, as we have previously mentioned, but when scaling only chat
services, the SA mux is especially attractive since it does not require the full suite
of services found on a Sametime server. It simply runs a single mux service and
thus can be used to increase your capacity on less powerful equipment than a
full server. It is also quite a bit easier to manage and configure with just a single
service and function.
Note: Sametime multiplexing services are transparent to the client PC. They
provide the active port for a client to connect to, and then channel the data
down a single IP port to the server. The servers still perform all community
and meeting services. If a server goes offline, the multiplexers can do nothing
on their own.
When capacity planning a Sametime environment using the SA mux, the

individual capacity of both the Sametime server and SA mux must be
considered. Although you can support 30,000–50,000 connections per SA mux,
the back-end Sametime server at some point will run out of resources with too
many total connections even with the SA mux handling them. For planning
purposes, if you require more than two SA muxes for the number of client
connections, add another Sametime server to handle the overall load. The only
exception to this rule is when you are adding muxes for spare capacity in a
clustered environment. For more information see “Expanding a Community
Services cluster with the SA mux” on page 44.
Note: Plan for no more than two SA muxes to a single Sametime server.

2.4.5 Deployment option: SA mux in remote locations
As mentioned earlier, all Sametime servers have an internal multiplexer or mux
component. When we front-end Sametime with a SA mux, this internal mux is
still active. Figure 2-8 shows another way to utilize the SA mux.

Instant Instant
Messaging Messaging
Users Users
Multiplexer
Community Services Sametime
1516 MUXServices
Community
Meeting Services
Sametime 7.5
Server 1
Figure 2-8 Another way to utilize the SA mux
As in the previous multiple server example, we are planning a Sametime

environment for 20,000 7.5.1 users and a nominal amount of meetings (13,000 in
the U.S. and 7,000 in Asia Pacific (AP)). Because users in AP also required
meeting services, we planned to deploy a full Sametime server to that location. If
this was a chat-only infrastructure, we could optionally deploy a SA mux to AP,
simplifying the hardware and management requirements to that of a full server
while still getting all of the benefits of speed and localization.
Note: Connecting a SA mux to a Sametime server across an internal firewall

requires only port 1516 for Community Services.
2.4.6 Deployment options for high availability

High availability is a method of computing that provides continuous,
uninterrupted access to services in spite of individual server failures that may

occur. As Sametime services become critical to your work, high availability
features become a non-negotiable requirement for all deployments.
In Sametime, there are two primary methods for providing redundancy to your
Sametime environment: Community Services clustering and the Enterprise
Meeting Server.
򐂰 Community Services clustering is a configuration option that allows the joining
of dedicated chat servers in to a logical cluster for the purposes of providing
redundancy and scalability for Sametime instant messaging and presence
functionality.
򐂰 The Enterprise Meeting Server (EMS) provides failover and load balancing for
the Sametime Meeting Services infrastructure. EMS is a separately
purchased product that runs on WebSphere Application Server. The EMS
and dedicated meeting or room Sametime servers operate together to
provide failover and load balancing for Sametime online meetings, including
screen-sharing/whiteboard meetings, interactive audio/video meetings, and
recorded meetings.

When adding redundancy to your Sametime infrastructure, Community Services
clustering and EMS are options that can be used individually or together, as
shown in the Figure 2-9. The ability to cluster the services separately provides
the flexibility to manage the services according to the needs of your community.
Note: Fault-tolerant solutions in Sametime require that servers are dedicated

to a particular function, either chat or meetings.
Sametime Web Browser

Connect Meeting
Client Room Client
Load
EMS
Balancer

Chat Chat
Room Room
Server Server
Server Server
COMMUNITY SERVICES CLUSTER
Chat Infrastructure Meeting Infrastructure
Figure 2-9 Adding redundancy to your Sametime infrastructure
Next we focus on Community Services clustering. For more information about

EMS refer to Chapter 10, “Enterprise Meeting Server” on page 703.

2.5 High-availability deployment option - Community
Services clustering
A Community Services or chat cluster is a method of grouping dedicated chat
servers so that they appear to end users as a single logical entity. Sametime
clustering relies on Domino clustering to keep key databases like vpuserinfo.nsf
(Buddylist) and stpolicy.nsf (ST Policies) synchronized in real time. Because of
this reliance on Domino Clustering the maximum size of a community services
cluster is limited to six Sametime servers. There is no limit to the number of
clusters that can be created within a Sametime community.
Load balancing in Community Services clusters

A chat cluster requires a method to distribute the user requests to the back-end
chat servers. This is typically done with an intelligent load balancer such as the
IBM Edge Server or other third-party products such as F5 Networks' BIG-IP, but
can also be accomplished with a simple round-robin or rotating DNS. As each
client connects, the load balancer or rotating DNS system distributes the client
connections to the servers in the Community Services cluster.
Note: Round-robin works by responding to DNS requests with a list of the chat
server IP addresses. It is not considered the best choice for load balancing
since it merely alternates the order of the addresses each time a query is
made. There is no consideration for the actual status of the back-end
Sametime server. If a server in the chat cluster goes down, the round-robin
DNS will continue to hand out the address, and clients will attempt to reach
the dead service.
Failover in Community Services clusters

Failover ensures that the Sametime user has continuous access to Community
Services. If a server in a Community Services cluster fails, the Sametime
Connect client attempts a reconnection to Sametime via the load balancer that is
specified in their client configuration. Community Services clustering enables
users to then be re-connected for Community Services functionality to any
available server in the cluster.
Note: Sametime clients provided by IBM contain the reconnect logic

mentioned above. When planning your Sametime deployment with third-party
clients, be sure to check with your manufacturer to see whether they support
this failover behavior.

Capacity planning within a community services cluster
When architecting a community services cluster, you should plan for capacity for
normal operation as well as during a services outage. The amount of extra
capacity to include depends on the level of redundancy that is required.
For example, earlier we said that a single Sametime server can provide sufficient
capacity to support chat for between 25,000 and 30,000 connections. Without
redundancy, this could be handled with a single Sametime server. To add
redundancy for a user group of this size, you would add an additional chat
server, as shown in Figure 2-10, to ensure that adequate capacity is available in
the event of a server outage.
Instant
Messaging
User
Load
Balancer

Server Server
COMMUNITY SERVICES CLUSTER
Figure 2-10 Adding redundancy through two chat servers
Expanding a Community Services cluster with the SA mux

If your capacity requirements for a chat cluster surpass that of two dedicated
chat servers, you may want to consider using the Community Services
multiplexer or SA mux. As mentioned previously, this configuration option frees
the back-end chat servers from the job of managing individual client connections.
When used in conjunction with a chat cluster, you get the best of both worlds:
scalability and redundancy.
For example, let us assume that you are architecting a redundant Sametime
environment for chat only (no meetings) for approximately 100,000 total users.

Assuming that your network is substantial enough to support the entire user load,
you decide on a centralized deployment for the chat cluster. When planning for
capacity, you require the cluster to support the client load not only during normal
operation, but also in case of a system failure. You understand that during an
outage the environment may slow down, but must be able to maintain the entire
user load without failure.
Figure 2-11 shows an environment that can support your requirements. This is a
highly redundant architecture that could support 100,000 Sametime chat-only
users while sustaining a multiple service outage where both a SA mux and a chat
server were temporarily unavailable.
Instant
Messaging
User
Load
Balancer
Sametime Sametime Sametime

MUX1 MUX2 MUX3

Server Server
COMMUNITY SERVICES
CLUSTER
Figure 2-11 Example of a highly redundant architecture
The two-server chat cluster is front-ended with three SA muxes that will handle
the client connections. The servers are properly sized and dedicated to chat only
(no instant meetings). The environment can support 90,000 –150,000 chat

clients during normal operation with no outages. This assumes that a mux would
handle between 30,000 and 50,000 client connections each, and a back-end
Sametime server would handle between 45,000 and 75,000 users each.
You can see from this example that we have planned approximately one-third
more capacity then needed to ensure that the environment is highly available. By
using SA muxes in conjunction with Community Services clustering, Sametime
can easily be expanded to support a large number of users with multiple levels of
redundancy for high availability.
2.5.1 Deployment option - Sametime in the extranet

The following section provides a high-level overview of deployment options for
Sametime in the extranet. We discuss deployment options for both Community
Services and Meeting Services under separate sub-sections.
Sametime in the extranet - Community Services

In addition to their internal enterprise deployments, many businesses have
realized added value by extending their use of Lotus Sametime to real-time
communications and collaboration with external contacts and organizations
including customers, business partners, and suppliers.
The real-world examples of how organizations have realized the business

benefits of deploying Sametime in the extranet include businesses that have
significantly reduced the travel costs for product design meetings by holding Web
conferences, service companies who now provide better customer service
through online communication, and organizations that have removed the need
for thousands of chargeable telephone calls and are replacing these with instant
messaging and voice over IP (VoIP).
The infrastructure deployment options and security considerations for an

extranet deployment of Sametime are largely determined by the intended
functionality and scalability that the solution requires.

For communications with external organizations that already have their own
Sametime service, the recommended approach to facilitate B2B instant
messaging would be to use the Lotus Sametime Gateway. For this solution both
organizations would implement their own Lotus Sametime Gateway behind their
own company firewall, as show in Figure 2-12. The Lotus Sametime Gateway is
discussed in detail later in this book.
Company A RTC RTC Company B

Sametime Company A Internet Company B Sametime
Server Server
Community Community
Lotus Sametime Lotus Sametime
Gateway Gateway
Figure 2-12 B2B instant messaging - connecting directly to the other company's Lotus Sametime Gateway
For communications with external contacts who do not have their own
organization's Sametime service, the recommended approach is for the
company to implement the Lotus Sametime Gateway and to direct external users
to make use of public instant messaging such as AOL Instant Messenger,
Yahoo!, or GoogleTalk. Sametime customers can use the AOL IM Clearinghouse
for federation with other enterprise IM users (see http://www.aol.com/aimpro).
This arrangement is depicted in Figure 2-13.
AOL Messenger®
User
RTC Yahoo!®
Internal
Company A Internet User
Server
Community
Lotus Sametime
Gateway
GoogleTalk®
Internal Firewall External Firewall User
Figure 2-13 Instant messaging (B2C) - individual external contacts

If the requirement is for the organization to host online meetings and instant
messaging with external contacts, the recommended approach would be to
deploy a separate Sametime server (or multiple Sametime servers) in the
organization’s DMZ. A Lotus Sametime Gateway can also be implemented to
provide instant messaging and awareness between the internal users connected
to internal Sametime servers and external users connected to the Sametime
server in the DMZ. A separate directory (LDAP or native Domino) can also be
established in the DMZ that holds the user credentials and attributes of the
external contacts. The corporate security policies of most organizations would
not permit external users to be given access to a corporate LDAP directory (or
DMZ replica of the corporate LDAP directory), and so the most secure approach
would be to hold separate credentials and attributes of those internal users who
have a requirement to participate in online meetings with external users. In this
situation there is no connection between the internal corporate LDAP directory
and the external directory established in the DMZ, and the internal users who
participate in online meetings with external users have an entirely separate user
record in the external directory. For details regarding the LDAP directory
configuration see Chapter 3, “LDAP User Directory - foundation for Sametime”
on page 79.

The capacity requirements of the external Sametime service (that is, number of
concurrent meetings, number of concurrent IM sessions) dictate the required
number of Sametime servers in the DMZ and whether it is necessary to have
distinctly separate IM servers and meeting servers. This configuration
summarized in the diagram below shows the infrastructure for a relatively small
capacity of external meetings or IM sessions in which it has not been necessary
to have separate IM and meeting servers.
External Internal users conduct

Sametime 7.5 their online meetings
Sametime 7.5 with external contacts
Meeting Server
Meeting Server here (...using their
"External Alias"
credentials)
Sametime 7.5
Chat Server
External
SIP
Sametime 7.5
Connector
Chat Server
Sametime 7.5 Lotus Sametime

Chat Server Gateway
External user records

here (...and "External
Alias" entries for
internal people (i.e.,
Internal LDAP External LDAP employees,
Directory Directory contractors)
Figure 2-14 Online meetings and instant messaging - Sametime servers in the DMZ
Note: For additional security, consider housing the External LDAP directory in
the protected zone (Intranet) or optionally including another external firewall.
Finally, for organizations that wish to provide connectivity for their employees to
participate in instant messaging and online meetings via the Internet, then the
recommended approach would be to make use of a virtual private network (VPN)
and securely access their organization’s Sametime services as they would do if
the were connecting via an internal network.
Sametime in the Extranet - Meeting Services

When providing an online meeting services that allows internal employees to
participate in meetings with external contacts such as customers, business
partners, and suppliers, a number of factors should be taken into consideration

including corporate security policies and requirements. The following is a
summary of the infrastructure configuration options that are possible for
providing an external meeting service:
򐂰 Option 1: isolated external sametime meeting environment
򐂰 Option 2: separate external Sametime meeting environment in the DMZ with
selective directory replication
򐂰 Option 3: internal and external meeting servers using invited meeting server
model and separate directories
򐂰 Option 4: isolated external Sametime meeting environment and using reverse
proxy access
򐂰 Option 5: Separate External Sametime Meeting Server with Selective
Directory Replication and using reverse proxy access
򐂰 Figure on page 55
Option 1: isolated external sametime meeting environment

The description, advantages, and disadvantages are:
򐂰 Description
As shown in Figure 2-15, isolated Sametime community is deployed in the
DMZ for all external meetings. An external community is maintained with its
own directory that is not shared with the internal community. All meeting
participants (internal and external) require an ID in the external directory in
order to use the external meeting server.
Internal Corporate Network DMZ

Instant
Messaging
User
Load
Balancer
(Primary)
Load
Balancer
(Backup)
ST 7.5
Meeting
Sametime
MUX1
Sametime
MUX3
Sametime
MUX3
Server
Sametime Sametime
7.5 7.5
Server Server
ST
CLUSTER
Directory
Load Load
Balancer Balancer
(Primary) (Backup)
LDAP Server LDAP Server

1 2

Meeting Meeting
Server1 Server2
Figure 2-15 Isolated external Sametime meeting environment
򐂰 Advantages
This is the most secure option for external meeting services, as there is no
external access to the internal corporate directory.

򐂰 Disadvantages
Internal users making use of the external services to meet online with external
contacts require two identities: their normal internal Sametime identity and
the identity that they use in the external community. This is likely to be
cumbersome to use and involves the additional overhead of managing the
separate directory in the DMZ.
Option 2: separate external Sametime meeting environment in the

DMZ with selective directory replication
򐂰 Description
As shown in Figure 2-16, a separate Sametime server community is deployed
in the DMZ. The directory in the DMZ is a selective replica of the corporate
(internal) directory and holds external account identities and also replicas of
the internal identities for employees who require to take part in online
meetings with external contacts. External contact details are added directly to
the external directory in the DMZ. The selective replication formula ensures
that the external user records do not replicate into the internal directory
replica.
ST 7.5
Meeting
Server
Selective Replication of Internal User Accounts from Corporate

LDAP directory to Replica Copy in the DMZ (i.e. only internal
Directory users who are authorized to participate in on -line meeting with Directory
external contacts )
Figure 2-16 Separate external Sametime Meeting environment in DMZ with selective directory replication
򐂰 Advantages
Unlike the previous example, this solution avoids the issue of internal users
requiring you to have two identities (internal and external). Directory records
for the selected internal users are replicated through the internal firewall to
the replica directory in the DMZ.

򐂰 Disadvantages
The main disadvantage of this approach is the administrative overhead that
will be necessary to maintain the external directory replica and to manage the
selective replication formula.
Option 3: internal and external meeting servers using invited

meeting server model and separate directories
򐂰 Description
Figure 2-17 illustrates internal and external meeting servers using the invited
meeting server model and separate directories. In this configuration there are
separate Sametime communities defined: internal and external. Online
meetings between internal and external participants are supported using the
invited meeting servers model.
ST 7.5 ST 7.5
Meeting Meeting
Server Server
Internal External
Directory Invited Meeting Server Model Directory
Figure 2-17 Internal and external meeting servers using invited meeting server model and separate
directories
򐂰 Advantages
This avoids the issue of internal users being required to have two identities
(internal and external) and avoids the necessity to establish and maintain
selective replication between internal and external directory replicas.
򐂰 Disadvantages
The main disadvantage of this approach is the administrative overhead that is
necessary to manage two Sametime meeting server communities and two
separate directories.

Option 4: isolated external Sametime meeting environment and
using reverse proxy access
򐂰 Description
Figure 2-18 illustrates the option for isolated external Sametime meeting
environment and using reverse proxy access. A separate Sametime
community is deployed for all external meetings. An external community is
maintained with its own directory that is not shared with the internal
community. All meeting participants (internal and external) require an ID in
the external directory in order to use the external meeting server.
The external Sametime meeting server can be deployed behind the reverse
proxy server. End users can connect to the Sametime server through the
reverse proxy server to participate in any type of Sametime meeting activity,
with the exception of interactive audio/visual (AV).
Internal Corporate Network DMZ Internet
External
ST Reverse
Meeting Proxy
Server
External Users Directory
Figure 2-18 Isolated external Sametime meeting environment and using reverse proxy access
򐂰 Advantages
It is secure because there is no external access to the internal corporate
directory.
It reduces the number of ports required to be open on the external firewall. It
allows access to clients from external communities where client connectivity
is restricted to port TCP/IP 80 traffic.
򐂰 Disadvantages
The reverse proxy is Sametime's worst-performing connectivity method
(HTTP polling). Reverse proxies introduce very significant latency. If the client
has to negotiate a proxy on its side then performance may drop to a
near-unusable level. This solution may not scale up.

Internal users making use of the external services to meet online with external
contacts require two identities: their normal internal Sametime identity and
the identity that they use in the external community. This is likely to be
cumbersome to use and involves the additional overhead of managing the
separate directory.
Option 5: Separate External Sametime Meeting Server with

Selective Directory Replication and using reverse proxy access
򐂰 Description
Figure 2-19 illustrates the next option, namely a separate Sametime meeting
server and separate directory replica to hold identities of external contacts
and employees who require taking part in online meetings with external
contacts. The external directory is a is a selective replica of the corporate
(internal) directory. External contact details are added directly to the external
directory in the DMZ. The selective replication formula ensures that the
external user records do not replicate into the internal directory replica.
External
ST Reverse
Meeting Proxy
Server
Selective replication
of internal users
to external directory
Internal Directory External Users Directory
Figure 2-19 Separate external Sametime meeting server with selective directory replication and using
reverse proxy access
򐂰 Advantages
Reverse proxy reduces the number of ports required to be open on the
external firewall and allows access to clients from external communities
where client connectivity is restricted to port TCP/IP 80 traffic.

Unlike the previous example, this solution avoids the issue of internal users
being required to have two identities (internal and external). Directory records
for the selected internal users are replicated through the internal firewall to
the replica directory in the DMZ.
򐂰 Disadvantages
(HTTP polling). Reverse proxies introduce significant latency. If the client has
to negotiate a proxy on its side then performance may drop to a
near-unusable level. This solution may not scale up.
A further disadvantage of this approach is the administrative overhead that is
necessary to maintain the external directory replica and to manage the
selective replication formula.
Option 6: separate external Sametime meeting server using invited

meeting server model with separate directories and using reverse
proxy access
򐂰 Description
As shown in Figure 2-20, separate Sametime communities are defined:
internal and external. Online meetings between internal and external
participants are supported using the invited meeting servers model.
Internal External
ST ST Reverse
Meeting Meeting Proxy
Invited Meeting
Server Server
Server Model
Internal Directory External Users Directory
Figure 2-20 Separate external Sametime meeting server using invited meeting server model with separate
directories and using reverse proxy access

򐂰 Advantages
This avoids the issue of internal users being required to have two identities
(internal and external) and avoids the necessity of establishing and
maintaining selective replication between internal and external directory
replicas.
This reduces the number of ports required to be open on the external firewall
and allows access to clients from external communities where client
connectivity is restricted to port TCP/IP 80 traffic.
򐂰 Disadvantages
With this solution it is necessary to manage two Sametime meeting server
communities and two separate directories.
(HTTP polling). Reverse proxies introduce significant latency. If the client has
to negotiate a proxy on its side then performance may drop to a
near-unusable level. This solution may not scale.
2.6 Overview of the global architecture proposed for

ITSO Corporation
Now that we have discussed various options for Sametime deployment, we once
again tie this into the context of the fictitious scenario for ITSO Corp.
ITSO Corp. planned Sametime Services for its global user population of 120,000
users across three regions (U.S. - 75,000, EMEA - 30,000, and AP - 15,000).
ITSO Corp. required an infrastructure that could support both instant messaging
and scheduled meetings across all regions. Instant messaging should be highly
available and be able to withstand a multi-system failure. Finally, ITSO Corp.
planned the infrastructure to support the current needs of today with ample
headroom in the configuration for growth over the next few years.
The architectural overview diagram for ITSO Corporation's Sametime

infrastructure (Figure 2-21 on page 57) shows a deployment of infrastructure to
each of the organization's three geographic regions: US, EMEA, and AP. ITSO
Corp. deployed dedicated Sametime chat clusters in both the U.S. and EMEA,
each fronted by standalone multiplexors and load balancers. In the AP region,
ITSO Corp. decided instead to leverage the spare capacity of the EMEA server
cluster and deploy remote standalone multiplexers to support the community
services for AP. This configuration made the best use of the slow bandwidth link
between EMEA and AP while minimizing the overall number of servers for ITSO
to manage.

United States EMEA Asia Pacific
75,000 Users 30,000 Users 15,000 Users
Instant Messaging and Awareness

Instant Instant Instant
Messaging Messaging Messaging
User User User
(Community Services)
Load Load Load Load Load Load
Balancer Balancer Balancer Balancer Balancer Balancer
(Primary) (Backup) (Primary) (Backup) (Primary) (Backup)
Sametime Sametime Sametime Sametime Sametime Sametime Sametime

MUX1 MUX2 MUX3 MUX1 MUX2 MUX1 MUX2
Sametime 7.5 Sametime 7.5 Sametime 7.5 Sametime 7.5

Server Server Server Server
ST ST
CLUSTER CLUSTER
Load Load Load Load

Directory
Directory
Balancer Balancer Balancer Balancer
(Primary) (Backup) (Primary) (Backup)
LDAP Server LDAP Server LDAP Server LDAP Server LDAP Server
1 2 1 2 1
LDAP Replication LDAP Replication
Invited Meeting Server Model Invited Meeting Server Model
Meeting Services
Meeting Services

Meeting Meeting Meeting Meeting
1 2 3 4
External Sametime infrastructure shown on separate diagram
Figure 2-21 Overview of global architecture proposed for ITSO Corporation
Dedicated meeting servers were deployed in each region in an invited server

model. In this configuration, local meeting traffic is contained within region,
reducing the overall network traffic used by Meeting Services, while allowing
ITSO Corp. to hold global meetings when necessary.
The server hardware supporting community services for ITSO Corp. across the
regions are roughly similar. Three standalone multiplexors were used in the U.S.
to support the 75,000 users with ample headroom for failover and growth. Two
standalone multiplexors were used in both EMEA and AP, primarily for
redundancy. A single mutiplexor in each location could have easily handled the
existing client load but would lack the headroom required for automatic failover
as well as future growth.

For the sake of clarity, Figure 2-22 illustrates a more focused view of just the
United States portion of the architecture.
Instant
Messaging
User
Load Load
Balancer Balancer
(Primary) (Backup)

MUX1 MUX2 MUX3

Server Server
ST
CLUSTER
Load Load
Balancer Balancer
(Primary) (Backup)

1 2
Invited Meeting Server

Model

Meeting Meeting
Server1 Server2
Figure 2-22 Specific overview of the architecture in the US

2.7 Directory considerations
In many respects, the user directory can be considered as the foundation of
Sametime. The directory is the resource that contains information describing the
users, applications, files, printers, and other resources.
The directory for this information is to be maintained and accessed in a

consistent and controlled manner. It also provides a focal point for integrating a
distributed environment into a consistent and seamless system.
2.7.1 Types of directories

When deploying Sametime you need to consider what type of user directory to
use. You most likely already have some information stores in your corporation.
These stores might contain information about your employees, your corporate
reporting hierarchy, or resources, to name few. Theses stores are directories.
Remember that a directory can contain virtually any type of object.
Sametime 7.5.1 testing was done with the following directories servers:
򐂰 IBM Directory Server V5.1, V5.2
򐂰 Tivoli Directory Server V6.0
򐂰 Lotus Domino V6.5.x - Native
򐂰 Lotus Domino V6.5.x - LDAP server
򐂰 Microsoft Active Directory® 2003, except i5/OS®
򐂰 Sun ONE Directory 5 (iPlanet 5.1, 5.2), except i5/OS
Sametime also supports any V3-compliant LDAP Directory Server. Refer to RFC
2251 - Light weight directory access protocol version 3 for more information.
2.7.2 Choosing which type of Directory to use

Before you choose which directory type to use you need to look at the big picture.
You need to figure out what applications are currently deployed and how they are
going to collaborate and make use of Sametime Services. Applications currently
deployed may include combinations of the following:
򐂰 WebSphere Portal
򐂰 Lotus QuickPlace
򐂰 Domino Mail Server
Each of the above applications utilize one or more directories. In the ideal world it
would be nice if all the applications that need to collaborate used the same

directory type. This is recommended if you are building your entire infrastructure
from scratch. The reality is that the world is not so simple, and there may already
be more than one type of application and directory deployed.
So what type of directory are those applications using? For example,

WebSphere Portal may be using Tivoli Directory Server or Lotus QuickPlace
may be using Domino LDAP, and there may be thousands of places deployed.
Changing the directory type for QuickPlace is simple, but correcting all the
members’ information takes time and considerable planning.
There is one rule to whatever directory you chose: namely, both QuickPlace and
Sametime must use the same directory for Chat and Meeting Services.
So if QuickPlace is currently authenticating with native Domino then Sametime

must use Native Domino. Similarly, if QuickPlace authenticates with TDS, then
Sametime must then work with the same TDS.
Finally, it is possible (and supported) for WebSphere Portal to use a non-Domino

LDAP and for Sametime and QuickPlace to use Domino LDAP or a native
Domino directory. You cannot, however, have WebSphere using a non-Domino
LDAP and Sametime and QuickPlace using a separate non-Domino LDAP.
2.7.3 How Sametime uses the directory

Sametime uses the directory information in the following ways
򐂰 Authentication
򐂰 Authorization
򐂰 Searching for attributes for users and groups
򐂰 Home server assignment
Authentication
When Sametime needs to know who you are, it asks you to log in with your name
and password. This is called being challenged for credentials. Once your name
and password are entered, then Sametime queries the directory to obtain the
user objects that match the name entered. For each name Sametime attempts to
determine whether the password entered matches. How it does this depends on
whether Sametime is using an LDAP Directory Server on native Domino. Once
the password matches you are authenticated. If there is no match you will be
challenged again to enter credentials.
Authorization
Once authenticated, Sametime may need to determine whether you are
authorized to perform the task you are trying to do. This consists of getting your
unambiguous name and any groups you belong to. It then checks either the

policies or the ACL of the resource. If you are not authorized an error is displayed
to you saying that you are not authorized.
Searching
Searching consists of looking up objects to get unique names and attributes
value associated. Searching occurs during the authentication phase as well as
the authorization. It also occurs once authenticated and authorized to get
additional attribute values depending on what Sametime components you are
using.
Home server assignment

Sametime environments with more than a single Sametime server require the
designation of a home server for every user. In Domino or Domino LDAP
directories this field already exists in the user’s person entry and can easily be
modified. In Sametime implementations using a non-Domino LDAP directory, you
must designate an available attribute to use for this information.
In non-clustered Sametime environments, the home server field should be

populated with the canonical name of the end user’s Sametime server, for
example, CN=SametimeServer/OU=Servers/O=Orgname. In clustered
Sametime environments, the home server field should be populated with the
name of the end user’s Sametime cluster as defined in the Stconfig.nsf
database.
2.7.4 Directory components

A directory contains a collection of objects organized in a tree structure. The
directory naming model defines how entries are identified and organized. Entries
are organized in a tree-like structure called the directory information tree (DIT).
Entries are arranged within the DIT based on their distinguished names (DNs). A
DN is a unique name that unambiguously identifies a single entry. DNs are made
up of a sequence of relative distinguished names (RDNs). Each RDN™ in a DN
corresponds to a branch in the DIT leading from the root of the DIT to the
directory entry. A DN is composed of a sequence of RDNs separated by
commas, such as uid=sshepherd,cn=users,dc=itso,dc=com. Every object in the
user directory has a distinguished name. Each object in a user directory has an
objectclass. A few examples of objectclasses would be:
򐂰 Domains
򐂰 Organizations
򐂰 Organizational units
򐂰 Containers
򐂰 Persons
򐂰 Groups

Each objectclass has mandatory and optional attributes. Examples of some
common attributes are:
򐂰 cn - common name
򐂰 givenname - first name
򐂰 sn - last name
򐂰 uid - user ID
The collection of objects and their respective attributes is call the schema.
Schema can be extended to include additional attributes. We discuss schemas
and extending schema in Chapter 5, “Deployment phase I - implementing
Meeting Services” on page 281.
Group considerations
Sametime, as well as all applications based on Sametime technology, often use
groups within a directory. A group is an object that contains a list of members. So
in Sametime you can add a directory group as a single entry your buddy list and
then the group is expandable to show the members. This is clearly much more
desirable than explicitly adding all the members. Similarly, when using the
Meeting Service it is nice to be able to restrict the meeting to a group or groups.
There are some things you need to consider when using groups. During the
authorization process Sametime queries the directory to find all groups that the
authenticated user belongs to. If the authenticated user is a member of a large
number of groups and nested groups are being used, another search is
conducted to identify which sub-groups containing the authenticated user are
associated with the parent group. This then happens and again until are all of the
searches return no results.
So you can see that there could be performance considerations when using
groups and nested groups. We discuss groups in more detail in Chapter 5,
“Deployment phase I - implementing Meeting Services” on page 281.
2.7.5 Security
There are several things that you need consider when it comes to security:
򐂰 What information do you want to be visible on the Internet?
򐂰 What information do you want to be visible on the intranet?
򐂰 Are you encrypting the information being transmitted over the wire?
򐂰 Who is accessing the directory, servers, or clients (and most likely all)?
In Chapter 5, “Deployment phase I - implementing Meeting Services” on

page 281, we discuss in detail these security issues when we talk about firewalls,
access control lists, and SSL encryption.

2.7.6 Single sign-on
With all the applications in your infrastructure it would be very cumbersome if you
had to keep re-entering your credentials. So you will definitely what to make use
of single sign-on. In Chapter 6, “Deployment phase II - integration with other
products” on page 329, we show how to set up SSO for your example.
2.8 Sametime system requirements - minimum

requirements and recommendations
In this section we discuss Sametime system requirements - minimum
requirements and recommendations.

2.8.1 Sametime server requirements
Table 2-3 illustrates the recommended Sametime hardware specifications to
support chat for between 25,000 and 30,000 connections or meeting services for
1,000 concurrent meeting users.
Important: This data is intended to be used as a general guideline:

򐂰 These recommended configurations represent a maxed-out configuration
to support the largest amount of users and services. If you are not planning
to load up your environment in this manner, you should scale down the
configuration accordingly.
򐂰 Actual performance and scalability may vary based on other infrastructure
variables and factors specific to your organization.
򐂰 These capacity numbers need to be reviewed and considered within the
context of each specific deployment option. Refer to 2.4, “Deployment
options” on page 28, and the subsequent scenarios to better understand
influencing factors.
򐂰 Plan for as much hardware as you can comfortably afford so that you have
ample capacity ready as your needs change.
Table 2-3 Hardware server specifications to support Chat or Meeting Services

Server requirements Minimum Real recommendation
Windows platform
CPU Single Intel® Pentium® III Four 2 Ghz or better CPUs

800 MHz or higher. (4 cores total.
OS Windows 2003 SP1 or Windows 2003 SP1 or

later. later.
Memory 1 GB. 4 GB recommended.
Disk free 2 GB minimum. 10 GB recommended free

space, as this allows for
debugging, logging, etc.
Swap 1GB minimum. 5 GB recommended.
Video requirements Video card installed. The Video card installed. The
setting must be higher than setting must be higher than
256 colors. 256 colors. Recommended
video display color setting
is 16-bit color.

AIX® platform
CPU Dual 375 MHz PowerPC® Four 1 GHz or higher, IBM

processor minimum. Power4 processor
recommended.
OS AIX 5.3 Technical Level 5 AIX 5.3 Technical Level 5.

(for 7.5.1 release).

Swap 1 GB minimum. 5 GB RAM recommended.
Video requirements Video card installed. The Video card installed. The
setting must be higher than setting must be higher than
256 colors. 256 colors. Recommended
is 16-bit color.
i5/OS
CPU IBM eServer™ iSeriesTM, IBM eServer iSeriesTM,
IBM eServerTM i5, or IBM IBM eServerTM i5, or IBM
System i5TM server System i5TM server
models capable of running models capable of running
IBM i5/OS V5R3. IBM i5/OS V5R3.
OS i5/OS Version 5 Release 3 i5/OS Version 5 Release 3

and Version 5 Release 4. and Version 5 Release 4.
For more details see
“Installing and Managing
Lotus Sametime 7.5 for
i5/OS" (stinstall.nsf).
Memory Minimum 1 GB for each

Sametime and Domino
server.
Disk free Minimum 500MB free disk 10 GB recommended free

space, minimum of 4 disk space, as this allows for
drives (arms). debugging, logging, etc.
Swap
Video requirements

Solaris™
CPU UltraSPARC III 550 MHz Four UltraSPARC IV

processor minimum. 1 GHz processor or higher
recommended.
OS Solaris 9 and 10. Solaris 9 and 10.
Memory 1 GB minimum. 4 GB recommended.

Swap 5 GB RAM recommended.
Video requirements The setting must be higher Video card installed. The
than 256 colors. setting must be higher than
256 colors. Recommended
is 16-bit color.
Linux x86
CPU Intel Pentium III 800 MHz. Four 2 Ghz or better CPUs
(4 cores total).
OS Red Hat Enterprise Linux Red Hat Enterprise Linux

4.0 Update 4 4.0 Update 4
SUSE Linux Enterprise SUSE Linux Enterprise
Server 10.0. Server 10.0.
Disk free 500 MB minimum. 10 GB recommended free

Swap 1 GB minimum. 5 GB recommended.
Video requirements The setting must be higher Video card installed. The
than 256 colors. setting must be higher than
256 colors. Recommended
is 16-bit color.

Attention: Generally, you will gain more improvement in Sametime
performance by having a good network design, and more server RAM, rather
than having faster or more CPUs.
2.8.2 Client requirements

The client system requirements for operation with the Sametime 7.5.x server
(and Multimedia Services) are listed in Table 2-4.
Table 2-4 Client requirements

Client requirement Minimum Real recommendation
Windows/Linux platforms
CPU Pentium 2 - 266 MHz (or CPU - Pentium 3 800 MHz

higher) (or higher)
RAM 512 MB RAM or higher 1 GB recommended
Macintosh
OS Macintosh OSX 10.4.6 Macintosh OSX 10.4.6

(Tiger) with JVM™ 1.5, (Tiger) with JVM 1.5,
including patches for including patches for
PowerPC and Intel J2SE™ PowerPC and Intel J2SE
5.0 Release 4a 5.0 Release 4b
Memory 512 MB 1 GB recommended
Disk free 500 MB minimum 1 GB free disk space

recommended to allow
space for meetings
Swap N/A N/A
Video requirements Higher than 256 colors Higher than 256 colors
required by Tiger required by Tiger
a. This is Java 1.5 and may have already been acquired through the MacOS auto
update. It is also available at:
http://developer.apple.com/java/download/SWT
Compatibility Libraries for J2SE 5.0 Release 4. These are available through
http://developer.apple.com/ for people registered on the Apple Developer site.
Log in and select Downloads → Java from the menu on the right. Java for Mac
OS X 10.4, Release 5 Developer Preview 2.

b. This is Java 1.5 and may have already been acquired through the MacOS auto
update. It is also available at:
http://developer.apple.com/java/download/SWT
Compatibility Libraries for J2SE 5.0 Release 4. These are available through:
http://developer.apple.com/
for people registered on the Apple Developer site. Log in and select
Downloads → Java from the menu on the right. Java for Mac OS X 10.4, Release
5 Developer Preview 2.
Client software requirements for meetings

Table 2-5 lists client software requirements for meetings.
Table 2-5 Client software requirements for meetings

Client - Browsers supported for meetings
Windows
򐂰 Internet Explorer® 6.0, 7.0 on Windows Professional, Windows XP Professional

64-bit
򐂰 Mozilla 1.7.12 on Windows XP
򐂰 Firefox 1.5 on Windows XP
򐂰 Firefox 2.0
Client JDK/JRE™:
򐂰 IBM or Sun JRE 1.4.2 and 1.5 for Web Conferencing - Internet Explorer 6.0 or 7.0
on Windows XP Professional
Linux
򐂰 Mozilla 1.7.12 RedHat Enterprise Linux 4.0, and Novell Linux Desktop 9.0
򐂰 Firefox 1.5 on RedHat Enterprise Linux 4.0, SUSE Linux Enterprise Desktop 10
򐂰 Firefox 2.0
Client JDK/JRE:
򐂰 IBM or Sun JRE 1.4.2 and 1.5 for Web conferencing - RedHat Enterprise Linux 4.0
and Novell Linux Desktop 9.0
Macintosh
򐂰 Safari 2.0 on Macintosh OSX 10.4.x
2.8.3 Community Services multiplexer requirements

A Community Services multiplexer or mux can be installed on a variety of
platforms including AIX, Solaris, Linux, and Windows. A mux cannot be installed
on an IBM System i™ server. However, Sametime on i5/OS supports the use of
a separate multiplexer installed on a Windows system.

Table 2-6 illustrates the minimum and recommended requirements for the
Community Services multiplexer machine to support chat for between 30,000
and 50,000 users.
Important: Both the Solaris and Linux platforms require a hotfix for correct
operation. Reference SPR #IDEA6W6SSS for Solaris and IDEA6ZRNYB for
Linux when calling support.
Table 2-6 Standalone mux hardware specifications

Mux requirements Minimum Real recommendation
Windows platform
CPU Single Intel Pentium III 800 Two 2 Ghz or better CPUs
MHz or higher (2 cores total)
OS Windows 2003 SP1 or later Windows 2003 SP1 or later
Memory 1 GB 2 GB recommended
Disk free 2 GB minimum 10 GB recommended free

Swap 1 GB minimum 3 GB recommended
AIX Platform
CPU Dual 375 MHz PowerPC Two 1 GHz or higher, IBM

processor minimum Power4 processor
recommended
OS AIX 5.3 Technical Level 5 AIX 5.3 Technical Level 5

(for 7.5.1 release)
Memory 1 GB 2 GB recommended

Swap 1 GB Minimum 3 GB RAM recommended
Solaris
CPU UltraSPARC III 550 MHz Two UltraSPARC IV

processor minimum 1 GHz processor or higher
recommended

Mux requirements Minimum Real recommendation
OS Solaris 9 and 10 Solaris 9 and 10
Memory 1 GB minimum 2 GB recommended

Swap 3 GB RAM recommended
Linux x86
CPU Intel Pentium III 800 MHz Two 2 Ghz or better CPUs
(2 cores total)
OS Red Hat Enterprise Linux Red Hat Enterprise Linux

4.0 Update 4 4.0 Update 4
SUSE Linux Enterprise SUSE Linux Enterprise
Server 10.0 Server 10.0
Memory 1GB 2 GB recommended
Disk free 500 MB minimum 10 GB recommended free

Swap 1GB minimum 3 GB recommended
2.9 Ports used by the Sametime server

The tables below list the default ports used by all Sametime services, including:
򐂰 HTTP Services, Domino Services, LDAP Services, and Sametime intraserver
ports
򐂰 Community Services ports
򐂰 Meeting Services ports
򐂰 Recorded Meeting Broadcast Services ports
򐂰 Audio/Video Services ports

HTTP Services, Domino Services, LDAP Services, and Sametime
intraserver ports
The following ports (Table 2-7) are used by the Sametime HTTP Services,
Domino Application Services, and LDAP Services.
Table 2-7 Ports used by Sametime HHTP, Domino Application, and LDAP Services
Default port Purpose
Port 80 If the administrator allows HTTP tunneling on port 80 during the

Sametime installation, the Community Services multiplexer on the
Sametime server listens for HTTP connections from Web browsers,
Sametime Connect clients, Sametime Meeting Room Clients, and
Sametime Broadcast clients on port 80.
If the administrator does not allow HTTP tunneling on port 80 during
the Sametime installation, the Domino HTTP server listens for HTTP
connections on this port.
Alternate If the administrator allows HTTP tunneling on port 80 during the

HTTP port Sametime installation (or afterward), the Domino HTTP server on
(8088) which Sametime is installed must listen for HTTP connections on a
port other than port 80. The Sametime installation changes the
Domino HTTP port from port 80 to port 8088 if the administrator
allows HTTP tunneling on port 80 during a Sametime server
installation.
Note that if the administrator allows HTTP tunneling on port 80

during the Sametime installation, Web browsers make HTTP
connections to the Community Services multiplexer on port 80, and
the Community Services multiplexer makes an intraserver
connection to the Sametime HTTP server on port 8088 on behalf of
the Web browser.
This configuration enables the Sametime server to support HTTP
tunneling on port 80 by default following the server installation.
Port 389 If you configure the Sametime server to connect to an LDAP server,
the Sametime server connects to the LDAP server on this port.
Port 443 The Domino HTTP server listens for HTTPS connections on this port
by default. This port is used only if you have set up the Domino HTTP
server to use Secure Sockets Layer (SSL) for Web browser
connections.
Port 1352 The Domino server on which Sametime is installed listens for
connections from Notes clients and Domino servers on this port.
Port 9092 The Event Server port on the Sametime server is used for
intraserver connections between Sametime components. This port
cannot be used by other applications on the server.

Port 9094 The Token Server port on the Sametime server is used for
Community Services ports

The following ports (Table 2-8) are used by the Sametime Community Services.
Most of these ports are configurable.
Table 2-8 Community Services ports

Port 1516 The Community Services listen for direct TCP/IP connections from
the Community Services of other Sametime servers on this port. If
you have installed multiple Sametime servers, this port must be open
for presence, chat, and other Community Services data to pass
between the servers.
The communications that occur on port 1516 also enable one
Sametime server to start a meeting on another server (or invite the
other server to the meeting).
Port 1533 The Community Services listen for direct TCP/IP connections and
HTTP-tunneled connections from the Community Services clients
(such as Sametime Connect and Sametime Meeting Room Clients)
on this port.
Note that the term direct TCP/IP connection means that the
Sametime client uses a unique Sametime protocol over TCP/IP to
establish a connection with the Community Services.
The Community Services also listen for HTTPS connections from the
Community Services clients on this port by default. The Community
Services clients attempt HTTPS connections when accessing the
Sametime server through an HTTPS proxy server. If a Community
Services client connects to the Sametime server using HTTPS, the
data on this connection is not encrypted.

the Sametime installation, the Community Services clients attempt
HTTP-tunneled connections to the Community Services on port 1533
by default.


Sametime installation, the Community Services clients can make
HTTP-tunneled connections to the Community Services multiplexer
on port 80.
Note that when HTTP tunneling on port 80 is allowed during the
Sametime installation, the Community Services multiplexer listens for
HTTP-tunneled connections on both port 80 and port 1533. The
Community Services multiplexer simultaneously listens for direct
TCP/IP connections on port 1533.
Port 8082 When HTTP tunneling support is enabled, the Community Services
clients can make HTTP-tunneled connections to the Community
Services multiplexer on port 8082 by default. Community Services
clients can make HTTP-tunneled connections on both ports 80 and
8082 by default.
Port 8082 ensures backward compatibility with previous Sametime
releases. In previous releases, Sametime clients made
HTTP-tunneled connections to the Community Services only on port
8082. If a Sametime Connect client from a previous Sametime
release attempts an HTTP-tunneled connection to a Sametime 7.5.1
server, the client might attempt this connection on port 8082.

Meeting Services ports
The following default ports (Table 2-9) should be open for Sametime Meeting
Services. These ports are configurable.
Table 2-9 Meeting Services ports

Port 8081 The Meeting Services listen for Sametime protocol over TCP/IP
connections from the Sametime Meeting Room Client on this port.
The screen-sharing, whiteboard, send Web page, and
question-and-answer polling components of the Sametime Meeting
Room Client exchange data with the server over this connection.
For AIX/Solaris, if you are specifying a DNS name for the host name
in “Address for client connections” and in “Address for
HTTP-tunneled client connections,” you must specify a dotted IPv4
address that your fully qualified domain name resolves to.
Steps: Start the Sametime server, log in, and click Administer the
server. Choose Configuration -Connectivity. Enter the dotted IPv4
in the corresponding text fields.
The Meeting Room Client can make the TCP/IP connection directly
to the Meeting Services or through a SOCKS proxy server.
The interactive audio and video components of the Sametime

Meeting Room Client also exchange call control information over a
direct TCP/IP connection on this port.
Sametime client uses a unique Sametime protocol operating over
TCP/IP to establish a connection with the Meeting Services.

the Sametime installation, the Meeting Services clients attempt
HTTP-tunneled connections to the Meeting Services on port 8081 by
default.


Sametime installation, the Meeting Room Client can make
on port 80.
When the Meeting Room Client makes an HTTP-tunneled connection

to the Community Services multiplexer, the Community Services
multiplexer makes an intraserver connection to the Meeting Services
on behalf of the Meeting Room Client. The intraserver connection
occurs on port 8081 by default.
The Meeting Room Client attempts the Sametime protocol over

TCP/IP connection (or direct TCP/IP connection) on port 8081 before
attempting an HTTP-tunneled connection on port 80.
Port 1503 The Meeting Services listen for T.120 connections from the Meeting
Services of other Sametime servers on this port. If you have installed
multiple Sametime servers, this port must be open between the two
servers for the servers to exchange screen-sharing, whiteboard, and
other Meeting Services data.
Port 1516 In a multiple Sametime server environment, a single Sametime

meeting can be simultaneously active on multiple Sametime servers.
This functionality is sometimes called invited servers. Port 1516 must
be open between two Sametime servers to enable one server to
extend a meeting invitation to another server in support of the invited
server’s functionality.

Recorded Meeting Broadcast Services ports
The following default ports (Table 2-10) are used by the Sametime Recorded
Meeting Broadcast Services. These ports are configurable.
Table 2-10 Recorded Meeting Broadcast Services ports

Port 554 The Recorded Meeting Broadcast Services listen for Real-Time
Streaming Protocol (RTSP) call control connections over TCP/IP on
this TCP/IP port. (RTSP uses TCP as the transport service.) The
Recorded Meeting client can make the RTSP TCP/IP connection
directly to the Recorded Meeting Broadcast Services or through a
SCOKS proxy server. This port is specific to AIX/Solaris. By default,
the Broadcast server will bind only to a single IP address and port. If
multiple IP addresses resolve to the same DNS name, then you will
need to configure a specific IPv4 dotted IP address to use.
Steps: Log in to the Sametime server, click Administer the server,

and choose Configuration-connectivity. In Broadcast Gateway
Address for Client Connections, enter the specific IPv4 Dotted IP
address you want for the broadcast connection or specify that the
broadcast server should bind to all IP addresses on the server.
(Open meetingserver.ini, and under
[Software\Lotus\Sametime\Broadcast Gateway\DBNL], change the
entry “IPBindAll=0” to IPBindAll=1”.

the Sametime installation, the Recorded Meeting clients attempt
HTTP-tunneled connections to the Recorded Meeting Broadcast
Services on port 554 by default.

Sametime installation, the Recorded Meeting clients can make
on port 80.
When the Recorded Meeting client makes an HTTP-tunneled

connection to the Community Services multiplexer, the Community
Services multiplexer makes an intraserver connection to the
Broadcast Gateway on behalf of the Recorded Meeting client. The
intraserver connection occurs on port 554 by default.
The Recorded Meeting client attempts the RTSP TCP/IP connection

on port 554 before attempting an HTTP-tunneled connection on port
80.

Dynamic UDP The Recorded Meeting Broadcast Services streams meeting data in
Ports RTP format from the server to the client over UDP ports. The specific
UDP ports are chosen randomly by the Recorded Meeting client and
cannot be controlled by the administrator.
Note that the Recorded Meeting Broadcast Services can also stream
audio and video data to Recorded Meeting clients. A meeting might
include three separate streams (one each for audio, video, and
screen-sharing/whiteboard data). If the client or server network, or
any network between the Sametime server and the client, does not
allow UDP traffic, the Recorded Meeting Broadcast Services tunnels
the streamed data over the initial RTSP TCP/IP control connection
that occurs on port 554.
If the call-control connection was established using HTTP-tunneling

on port 80, the client attempts to tunnel the UDP data through the
HTTP-tunneled connection on port 80 or another port specified by the
administrator.
Port 8083 The Recorded Meeting Broadcast Services use this port for internal
control connections between Recorded Meeting Broadcast Services
components. You should change this port only if another application
on the Sametime server is using port 8083.
1–65535 (UDP The Recorded Meeting Broadcast Services can take advantage of
ports for the bandwidth efficiency provided by multicast-enabled networks. If
multicast) your network supports multicast, the Recorded Meeting Broadcast
Services transmit multicast data over UDP ports within the 1 to 65535
range.
Note that multicast uses multicast IP addresses, not the IP address

of the Sametime server.
Audio/Video Services ports

The following default ports (Table 2-11) are used by the Audio/Video Services.
These ports are configurable.
Table 2-11 Audio/Video Services ports

Port 8081 The Sametime Meeting Room Client establishes a TCP/IP

connection with the Sametime server Meeting Services on this port.
The Audio/Video Services and audio/video components of the
Sametime Meeting Room Client use this connection to the Meeting
Services for call-control functions.

49252–65535 The Sametime Audio/Video Services listen for inbound audio and
(dynamic UDP video streams from Sametime Meeting Room Clients on a range of
port range) UDP ports specified by the administrator. The UDP ports are selected
by the Sametime Audio/Video Services dynamically from within the
range of ports specified by the administrator.
The administrator can configure the range of available UDP ports

from the MMP UDP port numbers start at/end at settings available
from the Interactive Audio/Video Services "Networks and Ports"
settings of the Sametime Administration Tool.
Port 8084 If UDP is unavailable between a Sametime Meeting Room Client and
a Sametime server, Sametime uses this TCP port when attempting
to tunnel the RTP audio and video streams using the TCP transport.
Port 9093 The Interactive Audio/Video Services use this port for internal control
connections between Interactive Audio/Video Services components.
You should change this port only if another application on the
Sametime server is using port 9093.
For more information about ports used by the Sametime server Services, see the
Sametime 7.5.1 Administrators Guide:
http://www-10.lotus.com/ldd/notesua.nsf/find/sametime

3
Chapter 3. LDAP User Directory -

foundation for Sametime
The user directory serves as the foundation for Sametime. This chapter
addresses the following topics:
򐂰 It provides an overview of key LDAP directory concepts and discusses how
Sametime uses the directory.
򐂰 It illustrates how to install and configure an LDAP user directory for
Sametime. In this specific case, we base the example on IBM Tivoli Directory
Server.
򐂰 It illustrates “Administering and configuring the Directory Server” on page 99.
򐂰 It discusses the “Directory information tree” on page 106.
򐂰 It describes “Populating the Directory Server using an LDIF file” on page 110.
򐂰 Finally, it discusses “Extending the LDAP schema” on page 115.
Note: If you are using a different LDAP Directory than IBM Tivoli Directory
Server, namely Active Directory or Domino LDAP, refer to one of the following
appendices:
򐂰 Appendix A, “Directory considerations for Active Directory” on page 751
򐂰 Appendix B, “Directory considerations for Domino LDAP” on page 799

Important: Regardless of which specific LDAP directory you are using, you
may also wish to refer to 3.7, “Populating the Directory Server using an LDIF
file” on page 110, and 3.8, “Schema” on page 111, to better understand key
LDAP attributes used by Sametime.

3.1 Directory concepts
People and businesses increasingly rely on networked computer systems to
support distributed applications. These distributed applications might interact
with computers on the same local area network (LAN), within a corporate
intranet, or anywhere in the world on the Internet. To improve functionality,
provide ease of use, and enable cost-effective administration of distributed
applications, information about the services, resources, users, and other objects
accessible from the applications needs to be organized in a clear and consistent
manner. Much of this information can be shared among many applications, but it
must also be protected to prevent unauthorized modification or the disclosure of
private information. Security, however, is not the only consideration when
applying a service policy to a piece of communication. The quality of service to
be delivered is another major element, and directories today are capable of
holding millions of objects.
Information describing the various users, applications, files, printers, and other
resources accessible from a network is often collected into a special database
that is sometimes called a directory. As the number of different networks and
applications has grown, the number of specialized directories of information has
also grown. This growth results in islands of information that are difficult to share
and manage. If all of this information could be maintained and accessed in a
consistent and controlled manner, it would provide a focal point for integrating a
distributed environment into a consistent and seamless system.
LDAP is an open industry standard that has evolved to meet these needs. LDAP
defines a standard method for accessing and updating information in a directory.
LDAP is gaining wide acceptance as the directory access method of the Internet
and is therefore also becoming strategic within corporate intranets. It is being
supported by a growing number of software vendors and is being increasingly
incorporated into applications. For example, the two most popular Web
browsers, Netscape Navigator/Communicator and Microsoft Internet Explorer,
support LDAP as a base feature.
3.1.1 What is a directory

A directory is a listing of information about objects arranged in some order that
gives details about each object. Common examples are a city telephone
directory and a library card catalog. For a telephone directory, the objects listed
are people; the names are arranged alphabetically, and the details given about
each person are address and telephone number. Books in a library card catalog
are ordered by author or by title, and information such as the ISBN number of the
book and other publication information is given.
Chapter 3. LDAP User Directory - foundation for Sametime 81

In computer terms, a directory is a specialized database, also called a data
repository, that stores typed and ordered information about objects. A particular
directory might list information about printers (the objects) consisting of typed
information such as location (a formatted character string), speed in pages per
minute (numeric), print streams supported (for example, PostScript® or ASCII),
and so on.
Directories allow users or applications to find resources that have the

characteristics needed for a particular task. For example, a directory of users can
be used to look up a person's e-mail address or fax number. A directory can be
searched to find a nearby PostScript color printer. Finally, a directory of
application servers could be searched to find a server that can access customer
billing information.
The terms white pages and yellow pages are sometimes used to describe how a
directory is used. If the name of an object (such as a person or printer) is known,
its characteristics (such as phone number or pages per minute) can be retrieved.
This is similar to looking up a name in the white pages of a telephone directory. If
the name of a particular individual object is not known, the directory can be
searched for a list of objects that meet a certain requirement. This is like looking
up a listing of hairdressers in the yellow pages of a telephone directory.
However, directories stored on a computer are much more flexible than the
yellow pages of a telephone directory because they can usually be searched by
specific criteria, not just by a predefined set of categories.
A directory is often described as a database, but it is a specialized database that

has characteristics that set it apart from general-purpose relational databases.
One special characteristic of directories is that they are accessed (read or
searched) much more often than they are updated (written). Just as hundreds of
people might look up an individual's phone number, thousands of print clients
might look up the characteristics of a particular printer. However, the phone
number or printer characteristics rarely change.
Because directories must be able to support high volumes of read requests, they
are typically optimized for read access. Write access might be limited to system
administrators or to the owner of each piece of information. A general-purpose
database, on the other hand, needs to support applications, such as airline
reservations and banking applications, with relatively high-update volumes.
Because directories are meant to store relatively static information and are
optimized for that purpose, they are not appropriate for storing information that
changes rapidly. For example, the number of jobs currently in a print queue
probably should not be stored in the directory entry for a printer because that
information would have to be updated frequently to be accurate. Instead, the
directory entry for the printer can contain the network address of a print server.
The print server can be queried to get the current queue length if desired. The

information in the directory (the print server address) is static, while the number
of jobs in the print queue is dynamic.
3.1.2 Directory components

A directory contains a collection of objects organized in a tree structure. The
directory naming model defines how entries are identified and organized. Entries
are organized in a tree-like structure called the directory information tree (DIT).
Entries are arranged within the DIT based on their distinguished name (DN). A
DN is a unique name that unambiguously identifies a single entry. DNs are made
up of a sequence of relative distinguished names (RDNs). Each RDN in a DN
corresponds to a branch in the DIT leading from the root of the DIT to the
directory entry. A DN is composed of a sequence of RDNs separated by
commas, such as uid=sshepherd,cn=users,dc=itso,dc=com. Every object in the
user directory has a distinguished name. Each object in a user directory has an
object class. A few examples of object classes would be:
򐂰 Domains
򐂰 Organizations
򐂰 Organizational units
򐂰 Containers
򐂰 Persons
򐂰 Groups
Each object class has mandatory and optional attributes. Examples of some
common attributes are:
򐂰 cn - common name
򐂰 givenname - first name
򐂰 sn - last name
򐂰 uid - user ID
The collection of objects and their respective attributes is called the schema. The
schema can be extended to include additional objects and attributes. We discuss
schemas and extending schema to include additional attributes in the following
sections:
򐂰 “Schema” on page 111
򐂰 “Extending the LDAP schema” on page 115
3.2 Directory considerations specific to Sametime 7.5.1

This section describes the different directories supported by Sametime 7.5.1, as
well as describing in detail how Sametime 7.5.1 uses the directory for
authentication, security, and searching for user attributes.

3.2.1 Types of directories
When deploying Sametime you need to consider what type of user directory to
use. You most likely already have some information stores in your corporation.
These stores might contain information about your employees, your corporate
reporting hierarchy, or resources, to name few. Theses stores are directories.
Remember that a directory can contain virtually any type of object.
Sametime 7.5.1 testing was done with the following directories servers:
򐂰 IBM Directory Server V5.1, V5.2
򐂰 Tivoli Directory Server V6.0
򐂰 Microsoft Active Directory 2003, except i5/OS
򐂰 Sun ONE Directory 5 (iPlanet 5.1, 5.2), except i5/OS
Sametime also supports any V3-compliant LDAP Directory Server. Refer to RFC
2251 - Light weight directory access protocol version 3 for more information.
3.2.2 Choosing which type of directory to use

Before you choose which directory type to use you need to look at the big picture.
You need to figure out what applications are currently deployed and how they are
going to collaborate and make use of Sametime Services. Applications currently
deployed may include combinations of the following:
򐂰 WebSphere Portal
򐂰 Lotus QuickPlace
򐂰 Domino Mail Server
Each of the above applications utilizes one or more directories. In an ideal world
it would be nice if all the applications that needed to collaborate used the same
directory type. This clearly would be recommended if you are building your entire
infrastructure from scratch. The reality is that the world is not so simple, and
there may already be more than one type of application and directory deployed.
So what type of directory are those applications using? For example,

WebSphere Portal may be using Tivoli Directory Server or Lotus QuickPlace
may be using Domino LDAP, and there may be thousands of places deployed.
Changing the directory type for QuickPlace is simple, but correcting all the
members’ information takes time and considerable planning.

There is one rule to whatever directory you chose: namely, both QuickPlace and
Sametime must use the same directory for chat and Meeting Services.
So if QuickPlace is currently authenticating with native Domino then Sametime

must use Native Domino within the same Domino Domain. Similarly, if
QuickPlace authenticates with TDS, then Sametime must work with the same
TDS.
Finally, it is possible (and supported) for WebSphere Portal to use a non-Domino

LDAP and for Sametime and QuickPlace to use Domino LDAP or native Domino
directory. You cannot, however, have WebSphere using a non-Domino LDAP
and Sametime and QuickPlace using a separate non-Domino LDAP.
3.2.3 How Sametime uses the directory

Sametime uses the directory information in the following ways:
򐂰 Authentication
򐂰 Authorization
򐂰 Searching for attributes for users and groups
򐂰 Home server assignment
Authentication
When Sametime needs to know who you are, it asks you to log in with your name
and password. This is called being challenged for credentials. Once your name
and password are entered, Sametime queries the directory to obtain the user
objects that match the name entered. For each user object returned, Sametime
attempts to determine whether the password entered matches. How it does this
depends on whether Sametime is using an LDAP Directory Server on a native
Domino directory. Once the password matches for a returned user object you are
authenticated. If there is no match you will be challenged again to enter
credentials.
Authorization
Once authenticated, Sametime may need to determine if you are authorized to
perform the task you are trying to do. This consists of getting your unambiguous
name and any groups you belong to. It then check either the policies or the ACL
of the resource. If you are not authorized an error is displayed to you saying you
are not authorized.
Searching
Searching consists of looking up objects to get unique names and attributes
value associated. Searching occurs during the authentication phase as well as
the authorization. It also occurs once authenticated and authorized to get

additional attribute values depending on what Sametime components you are
using.
Home server assignment

Sametime environments with more than a single Sametime server require the
designation of a home server for every user. In Domino or Domino LDAP
directories this field already exists in the user’s person entry and can easily be
modified. In Sametime implementations using a non-Domino LDAP directory, you
must designate an available attribute to use for this information.
In non-clustered Sametime environments, the home server field should be

populated with the Canonical name of the end user’s Sametime server, for
example, CN=SametimeServer/OU=Servers/O=Orgname. In clustered
Sametime environments, the home server field should be populated with the
name of the end user’s Sametime cluster as defined in the Stconfig.nsf
database.
3.2.4 Group considerations

Sametime, as well all applications that make use of directories, uses groups,.A
group is an object that contains a list of members. In Sametime you can add a
directory group as a single entry to your buddy list and then the group is
expandable to show the members. This is much more desirable than explicitly
adding all the members. Similarly, when using Meeting Service it is nice to be
able to restrict the meeting to groups.
There are some things you need to consider when using groups. During the
authorization process Sametime queries the directory to find all groups the
authenticated user belongs to. If that user belongs to a large number of groups
and nested groups are being used, each group that the authenticated user
belongs to produces another search to find out what group that group belongs.
This happens and again until are all the searches return no results.
So you can see that there could be performance considerations when using
groups and nested groups. We discuss groups in more detail in Chapter 5,
“Deployment phase I - implementing Meeting Services” on page 281.
3.2.5 Security
There are several things you need to consider when it comes to security:
򐂰 What information do you want to be visible from the Internet?
򐂰 What information do you want to be visible from the intranet?
򐂰 Are you encrypting the information being transmitted over the wire?
򐂰 Who is accessing the directory, servers, or clients (most likely all)?

In Chapter 5, “Deployment phase I - implementing Meeting Services” on
page 281, we discuss in detail these security issues when we talk about firewalls,
access control lists, and SSL encryption.
3.2.6 Single sign-on

With all the applications in your infrastructure it would be very cumbersome if you
had to keep re-entering your credentials, so you definitely what to make use of
single sign-on. In Chapter 5, “Deployment phase I - implementing Meeting
Services” on page 281, we show how to set up SSO for your example.
3.3 Tivoli Directory Server Installation

The Tivoli Directory Server Version 6.0 Info Center can be found at:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?toc=/
com.ibm.IBMDS.doc/toc.xml
We now install Tivoli Directory Server Version 6.0. Refer to the appendices for
Microsoft Active Directory and Domino LDAP information (Appendix A, “Directory
considerations for Active Directory” on page 751, and Appendix B, “Directory
considerations for Domino LDAP” on page 799).
3.3.1 Steps for installing Tivoli Directory Server

To install Tivoli Directory Server:
1. Insert the Tivoli Directory Install CD. Navigate to the ITDS subdirectory and
run setup.exe. Once the install shield initialization is complete you will be
asked to select the language.
2. Select the correct language and click the OK button (Figure 3-1).
Figure 3-1 TDS language selection

3. Click the Next button and the software licence will be shown (Figure 3-2).
Figure 3-2 TDS Welcome Page

4. Read the software license and then click the Next button to continue
(Figure 3-3).
Figure 3-3 TDS license

5. Specify the directory in which to install the software and then click the Next
button (Figure 3-4).
Figure 3-4 TDS software installation path

6. Uncheck the GSKit feature. We install GSKit in Chapter 7, “Deployment
phase III - securing the environment” on page 537 (specifically “Install GSKit
on Tivoli Directory Server” on page 541). See Figure 3-5.
Figure 3-5 TDS features selection
7. Click the Next button.

8. Enter the DB2 administrator’s user ID and password and click Next
(Figure 3-6).
Figure 3-6 DB2 administrator and password

9. Click Next to continue or Back to add or remove a feature. Two screens will
be displayed before the following is displayed. The first shows that DB2 was
being installed and the second shows that the embedded WebSphere
Application server is being installed. See Figure 3-7.
Figure 3-7 TDS features to install confirmation window
10.Click the Create button to create the Directory Server instance (Figure 3-8).
Figure 3-8 Creating the Directory Server instance

11.Select Create new directory server instance and click the Next button
(Figure 3-9).
Figure 3-9 Create new directory server instance
12.Enter the user name, installation location, encryption string, and an instance
description. The user name is a user account and must exist, and that
account has to be a member of the administration group. See Figure 3-10.
Figure 3-10 New directory server instance

13.Enter or select the DB2 Instance name. This name should be the same as an
existing user. Click Next to continue. See Figure 3-11.
Figure 3-11 Create directory server instance
14.Check Listen on all configured IP address or select the one of the

addresses listed and then click Next (Figure 3-12).
Figure 3-12 Select IP address to listen on

15.Accept the default TCP /IP ports or change them. If you change the server
port and or secure server port make sure that all the applications that are
communicating with TDS use those same ports. Click Next to continue. See
Figure 3-13.
Figure 3-13 TDS IP ports
16.Enter the Administrator’s distinguished name (DN) and password. Make sure
that the DN is entered in LDAP DN format. Click Next to continue. See
Figure 3-14.
Figure 3-14 TDS administrator’s DN and password

17.Enter the DB2 administrator’s user name and password. Click Next to
continue. See Figure 3-15.
Figure 3-15 DB2 Administrator’s user name and password
18.Chose the location and accept the character set. Click Next to continue. See
Figure 3-16.
Figure 3-16 Database location and character set option

19.Click Finish if everything is correct or Back to make changes (Figure 3-17).
Figure 3-17 Verify new directory server instance
20.Click OK (Figure 3-18).
Figure 3-18 Create directory server instance task completion

21.Click Close. The Tivoli Directory Server is now installed. See Figure 3-19.
Figure 3-19 Directory Server instance - results
3.4 Administering and configuring the Directory Server

In order administer the Tivoli Directory Server you need to use the Directory
Server Web Administration tool.

3.4.1 Directory Server Web Administration Tool
In order to launch and use this tool, follow these steps:
1. Open services and navigate to the Tivoli Directory Server Admin Daemon
task and the IBM Tivoli Directory Server instance task, as shown in
Figure 3-20.
Figure 3-20 Starting and stopping service
2. Locate the two services mentioned above, and if not started right-click and
chose Start.
3. Now start the embedded WebSphere Application server. Open a command
prompt window and navigate to the bin directory under the appsrv
subdirectory (that is, c:\IBM\LDAP\appsrv\bin).

4. Enter the command startServer.bat server1 and wait until server1 is
started, as shown in Figure 3-21.
Figure 3-21 Starting embedded WebSphere server
5. Open a Web browser and enter the URL and press Enter.
In the case of our environment, the URL to the Web admin tool is:
http://tds.cam.itso.ibm.com:12100/IDSWebApp/IDSjsp/Login.jsp
Figure 3-22 Directory Server Administration Tool

6. The first time this tool is run you need to add the console server for this
Directory Server instance. Chose console Admin, enter superadmin for the
user name, and the password is secret.
7. Click Login to continue. Expand Console Administration and then click
Manage Console Servers.
8. Click the Add button. See Figure 3-23.
Figure 3-23 Manage console servers

Figure 3-24 Adding server to Web Administration Tool

9. Enter the LDAP host, port, and administration port, These ports must be the
same as the ports specified in Figure 3-13 on page 96. Then click OK. See
Figure 3-25.
Figure 3-25 Directory Server successfully added to Web Administration Tool

10.Click OK and the Directory Server instance will be shown in the Manage
Console server list.
Figure 3-26 Added console server
11.Select Logout in the left-hand navigation pane and return to the Web
Administration login page.

3.5 Directory information tree
Figure 3-27 shows a portion of the directory information tree that we are going to
be defining.
Domain Suffix:
dc=itso, d=com
objectclass=domain
cn=users cn=groups
objectClass=container objectClass=container
uid=sshepherd cn: wpsadmins

objectClass=inetOrgPerson uniquemember:
uid=wpsadmin,cn=users,dc=itso,dc=com
objectclass: groupOfUniqueNames
uid=jbergland
objectClass=inetOrgPerson
cn: Sales
uniquemember:
uid=sshepherd,cn=users,dc=itso,dc=com
uniquemember:
uid=jwales uid=cprice,cn=users,dc=itso,dc=com
objectClass=inetOrgPerson objectclass: groupOfUniqueNames
cn: Sales and Marketing

uniquemember:
cn: Marketing
uid=glambie uid=eshepherd,cn=users,dc=itso,dc=com
uniquemember:
objectClass=inetOrgPerson ibm-memberGroup:
cn=Sales,cn=groups,dc=itso,dc=com uid=glambie,cn=users,dc=itso,dc=com
ibm-memberGroup: uniquemember:
cn=Marketing,cn=groups,dc=itso,dc=com uid=jwales,cn=users,dc=itso,dc=com
objectclass: groupOfUniqueNames uniquemember:
uid=ahiggins,cn=users,dc=itso,dc=com
uid=wpsadmin objectclass: ibm-NestedGroup
objectClass=inetOrgPerson
Figure 3-27 Directory information tree
3.6 Suffixes
Before any information can be added to the Tivoli Directory Server at least one
suffix must be defined. A suffix (also known as a naming context) is a DN that
identifies the top entry in a locally held directory hierarchy. Because of the
relative naming scheme used in LDAP, this DN is also the suffix of every other
entry within that directory hierarchy. A Directory Server can have multiple
suffixes, each identifying a locally held directory hierarchy, for example,

dc=itso,dc=ibm and ou=Tivoli,o=ibm could be defined. Sametime can only use
one directory hierarchy.
Adding a suffix
To add the base suffix:
1. Using the Directory Server Web Administration Tool, pull down the list in the
LDAP hostname field, select the Directory Server instance, and enter the
Administator’s LDAP DN in the username field and corresponding password,
Figure 3-28 Enter username and password

2. Click Login. In the left-hand navigation pane expand Server Administration
and then click Manage server properties (Figure 3-29).
Figure 3-29 Manage server properties

3. Click Suffixes (Figure 3-30).
Figure 3-30 Adding suffixes
4. Enter the suffix and then scroll down and click the Add button.
5. Restart the Directory Server.

3.7 Populating the Directory Server using an LDIF file
Directory objects such as domains, containers, users, and groups can be added
to the Directory Server using a LDAP Import File (LDIF). Example 3-1 is a
excerpt of the LDIF file we used to populate our Directory with the necessary
objects. Note that even though you have defined a suffix as in our example
DC=itso,DC=com, you still need to add a domain object for DC=itso,dc=com
before objects can be added into the directory tree.
Example 3-1 Sample LDIF

dn: dc=itso,dc=com
dc: itso, dc=com
objectclass: domain
objectclass: top
dn: cn=users,dc=itso,dc=com
cn: users
objectClass: container
objectClass: top
dn: cn=groups,dc=itso,dc=com
cn: groups
objectClass: container
objectClass: top
dn: uid=sshepherd,cn=users,dc=itso,dc=com
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: ePerson
givenname: Stephen
sn: shepherd
cn: Stephen Shepherd
uid: sshepherd
userPassword: password
dn: uid=wpsadmin,cn=users,dc=itso,dc=com
objectclass: person
objectclass: top
objectclass: ePerson
givenname: wps

sn: admin
cn: wps admin
uid: wpsadmin
userPassword: password
dn: cn=wpsadmins,cn=groups,dc=itso,dc=com
objectclass: top
objectclass: ibm-appuuidaux
cn: wpsadmins
uniquemember: uid=wpsadmin,cn=users,dc=ibm,dc=com
3.7.1 Steps to populate using the LDIF file

To do this:
1. Stop the Directory Server and open a command prompt window.
2. Navigate to the LDAP bin directory. In our example it is c:\IBM\LDAP\bin.
3. Enter the following command:
ldif2db -i path to ldif file such as
ldid2db -i c:\tds.ldif
4. The output will tell you the outcome of this operation.
5. Restart the Directory Server.
3.8 Schema
All the objects and attributes with their characteristics are defined in schemas.
The schema specifies what can be stored in the directory. Schema-checking
ensures that all required attributes for an entry are present before an entry is
stored. Schema-checking also ensures that attributes not in the schema are not
stored in the entry. Optional attributes can be filled in at any time. A schema also
defines the following:
򐂰 Inheritance
򐂰 Subclassing of objects
򐂰 Where in the DIT structure (hierarchy) objects may appear
Information about the IBM Tivoli Directory Schema schema can be found at:
http://publib.boulder.ibm.com/tividd/td/IBMDS/IDSschema52/en_US/HTML/
schema.html

Schemas can be extended to add additional object classes and additional
attributes. In 3.9, “Extending the LDAP schema” on page 115, we show you how
to add additional attributes that are necessary for Sametime integration.
It is beyond the scope of this document to discuss in detail the Tivoli Directory
Server schema, but we discuss groups (in particular, nested groups).
The TDS 6.0 Info Center was used as a basis for the following:
3.8.1 Nested groups in a schema

The nesting of groups enables the creation of hierarchical relationships that can
be used to define inherited group membership. A nested group is defined as a
parent group entry that has members that are group entries. A nested group is
created by extending one of the structural group object classes by adding the
ibm-nestedGroup auxiliary object class. After nested group extension, zero or
more ibm-memberGroup attributes may be added, with their values set to the
DNs of nested child groups. See Example 3-2.
Example 3-2 Sample LDIF for nested groups
dn: cn=Level1,cn=groups,dc=itso,dc=com
objectclass: GroupofUniqueNames
objectclass: ibm-nestedGroup
objectclass: top
cn: Level1
description: Group composed of static and nested members
uniquemember: uid=sshepherd,cn=users,dc=itso,dc=com
uniquemember: uid=vrohatgi,cn=users,dc=itso,dc=com
ibm-memberGroup: cn=Level2,cn=groups,dc=itso,dc=com
dn: cn=level3,cn=groups,dc=itso,dc=com
objectclass: top
cn: Level3
uniquemember: uid=jbergland,cn=users,dc=itso,dc=com
uniquemember: uid=cprice,cn=users,dc=itso,dc=com
uniquemember: uid=jpuckett,cn=users,dc=itso,dc=com
uniquemember:
dn: cn=level3,cn=groups,dc=itso,dc=com

objectclass: top
cn: Level3
uniquemember: uid=jbergland,cn=users,dc=itso,dc=com
uniquemember: uid=jpuckett,cn=users,dc=itso,dc=com
To further illustration, look at the following two LDAP searches (Example 3-3 and
Example 3-4).
Example 3-3 ldapsearch for uniquemember

ldapsearch -h tds.cam.itso.ibm.com -D cn=root -w redb00k -s base -b
"cn=level1,cn=groups,dc=itso,dc=com" objectclass=* uniquemember
cn=Level1,cn=groups,dc=itso,dc=com
uniquemember=uid=sshepherd,cn=users,dc=itso,dc=com
uniquemember=uid=vrohatgi,cn=users,dc=itso,dc=com
If the search uses attribute ibm-allmembers, then all members including the
members of the nested groups are returned in one search, as shown in
Example 3-4.
Example 3-4 ldapsearch for attribute ibm-allmembers

"cn=level1,cn=groups,dc=itso,dc=com" objectclass=* ibm-allmembers
cn=Level1,cn=groups,dc=itso,dc=com
ibm-allmembers=uid=sshepherd,cn=users,dc=itso,dc=com
ibm-allmembers=uid=vrohatgi,cn=users,dc=itso,dc=com
ibm-allmembers=uid=glambie,cn=users,dc=itso,dc=com
ibm-allmembers=uid=jwales,cn=users,dc=itso,dc=com
ibm-allmembers=uid=ahiggins,cn=users,dc=itso,dc=com
ibm-allmembers=uid=jbergland,cn=users,dc=itso,dc=com
ibm-allmembers=uid=cprice,cn=users,dc=itso,dc=com
ibm-allmembers=uid=jpuckett,cn=users,dc=itso,dc=com
When setting up Sametime, you can use ibm-allmembers as the attribute in the
group object class that has the names of the group members.

Note: This capability to get all the group members including the members of
the nested groups in one search is a feature in the Tivoli Directory Server.
This is not a feature in Microsoft’s Active Directory 2003, nor is it a feature of
Domino LDAP server.
Another feature in the Tivoli Directory Server is the ability to get all the groups
that a particular user belongs to by using the ibm-allgroups attribute. Consider
the following groups (Example 3-5).
Example 3-5 LDIF nested groups to illustrate searching for attribute ibm-allgroups
dn: cn=Sales,cn=groups,dc=itso,dc=com
objectclass: top
cn: Sales
uniquemember: uid=sshepherd,cn=users,dc=itso,dc=com
dn: cn=Marketing,cn=groups,dc=itso,dc=com
objectclass: top
cn: Marketing
uniquemember: uid=glambie,cn=users,dc=itso,dc=com
uniquemember: uid=jwales,cn=users,dc=itso,dc=com
uniquemember: uid=ahiggins,cn=users,dc=itso,dc=com
dn: cn=Sales and Marketing,cn=groups,dc=itso,dc=com

objectclass: top
cn: Sales and Marketing
uniquemember: uid=eshepherd,cn=users,dc=itso,dc=com
ibm-memberGroup: cn=Sales,cn=groups,dc=itso,dc=com
ibm-memberGroup: cn=Marketing,cn=groups,dc=itso,dc=com

Using ldapsearch, it produced the results shown in Example 3-6.
Example 3-6 ldapsearch for attribute ibm-allgroups

"uid=sshepherd,cn=users,dc=itso,dc=com" objectclass=* ibm-allgroups
uid=sshepherd,cn=users,dc=itso,dc=com
ibm-allgroups=cn=Level1,cn=groups,dc=itso,dc=com
ibm-allgroups=cn=Sales,cn=groups,dc=itso,dc=com
ibm-allgroups=cn=Sales and Marketing,cn=groups,dc=itso,dc=com
Note: The attribute ibm-allgroups is specific to the Tivoli Directory Server.

Microsoft’s Active Directory 2003 supports the memberof attribute, which
provides the same functionality.
3.9 Extending the LDAP schema

In some cases, depending upon which LDAP server you are using, it may be
necessary to create additional Sametime-specific attributes to the LDAP schema.
This section discusses the attributes you need and the process for adding these
to the LDAP schema.
Sametime integration with an LDAP Directory Server requires you to modify the
schema if there is not an available attribute to use in your LDAP directory for the
home server. (Note that this is not necessary if the Domino LDAP server is being
used by Sametime.) The attributes that need to be added depend on what
additional applications are being deployed. We cover all the attributes that need
to be added to our Tivoli Directory Server LDAP schema.
Note: If you are using Domino LDAP, you do not need to add these attributes
to the LDAP schema.

In upcoming chapters, as we configure and integrate our test environment we
need to add attributes to the person records of each user in our LDAP directory.
Specifically, we add the attributes described in Table 3-1.
Table 3-1 Attributes to be added to an LDAP directory

Attribute name Description
SametimeServer This contains the cluster name as

specified in the cluster information
document in stconfig.nsf. Refer to “Home
server assignment” on page 86.
NotesCon Notes full canonical name. For example,

CN=Stephen Shepherd/O=ITSO.
NotesDN Notes name in LDAP DN format. For

example, CN=Stephen
Shepherd,O=ITSO.
Mailfile Notes mail file needed for auto-mail

detection when using WebSphere Portal
Server mail portlets. For example,
mail\sshepher.nsf.
Mailserver DNS name of Domino mail server. For

example, dwa,cam.itso.ibm.com.
3.9.1 Extending the schema to add SametimeServer attribute

In this section we extend the schema to include the SametimeServer attribute.
This attribute allows us to take advantage of the Home Sametime server feature
within Sametime. In a clustered environment, we use this attribute to specify
which chat cluster the user will connect to. The name specified in this attribute is
the name of the cluster as defined in the cluster information document in
stconfig.nsf.

The following steps describe how to do this:
1. Specify the name attribute that will be added the schema on the Sametime
chat server. The name of this attribute is configurable and is specified in the
LDAP server document in stconfig.nsf.
Figure 3-31 LDAP server document in STConfig.nsf

2. Use IBM Tivoli Directory Server Web Administration. (See 3.4, “Administering
and configuring the Directory Server” on page 99.) Select the LDAP host
name from the pull-down list and log in as the directory administrator.
Figure 3-32 Directory Server Web Administration Tool

3. Expand the schema management twistie in the left navigation pane. Click
Add an attribute and enter field values (as shown in Figure 3-33) to add an
attribute SametimeServer.
Figure 3-33 Adding attribute SametimeServer
4. You may need to scroll down. Click OK to add the SametimeServer attribute
to the schema.

5. This attribute needs to be added to an object class, so we add this attribute to
the inetOrgPerson object class. In the left-hand navigation click Manage
object classes. Find the object class inetOrgPerson, as shown in
Figure 3-34.
Figure 3-34 Manage object classes

6. Click the Edit button.
Figure 3-35 Edit object class: InetOrgPerson
7. Click Attributes in the left pane of the Edit object class frame (Figure 3-36).
Figure 3-36 Adding attributes to inetOrgPerson

8. In the list of available attributes find and highlight SametimeServer. Then
click Add to optional. Then click OK to add the attribute to the object class.
Note: Do not add the attribute as a required attribute if the directory has
already been populated with inetOrgPerson objects, as this will cause a
schema violation.
9. This field now needs to be populated with the value specified in the cluster
name specified in the cluster information document in stconfig, as shown in
Figure 3-37.
Figure 3-37 Sametime cluster information document
10.The value stchatcluster needs to be added to each inetOrgPerson document.

This can be done via LDAPModify, but for our example we show adding this
attribute manually to an inetOrgPerson object from the Web administration
tool.

11.Click the twistie for Directory Management in the left-hand navigation pane
and click Manage Entries. Expand the levels within the directory information
tree and select the desired object.
Figure 3-38 Manage user entries

12.Click the Edit Attributes button.
Figure 3-39 Edit attributes for an inetOrgPerson object

13.Click Optional Attributes in the left navigation of the Edit attributes frame
and enter the chat cluster into the SametimeServer attribute value.
Figure 3-40 Entering the SametimeServer attribute value
14.Scroll down and click the OK button at the bottom of the frame.
3.9.2 Extending the schema to add NotesDN and NotesCon

In this section we extend the schema to include NotesCon and NotesDN. We
add these attributes to support awareness and SSO in Domino Web Access, the
Notes Client, and Microsoft Office. More detailed information about how these
attributes are used is detailed in Chapter 6, “Deployment phase II - integration
with other products” on page 329.

The attributes NotesDN and NotesCon would be added to the schema and
added as optional attributes to the inetOrgPerson object the same way the
SametimeServer attribute was added. Additionally, the values in an
inetOrgPerson object would be populated the same way as the SametimeServer
attribute.
Figure 3-41 Adding attribute values for NotesCon and NotesDN
3.9.3 Extending the schema to add MailFile and MailServer attributes

In this section we extend the schema to include the mailfile and mailserver
attributes. These attributes are used to allow auto-detection of the mail file
against your IDS server for the DWA portlet in Portal. We do not specifically
detail how to configure the DWA portlet, but we think it a good idea to explain
how to add these attributes for customers wanting to configure the DWA portlet in
Portal.
TDS already supports the attributes mailfile and mailserver. These are optional
attributes for the eDominoAccount object. Therefore, you do not need to add
those attributes to the schema. All you have to do is add those attributes to the
inetOrgObject Class.
1. Edit the inetOrgPerson object, as shown in Figure 3-35 on page 121.
2. Click Attributes, as shown in Figure 3-36 on page 121.
3. Find mailfile in the available attributes list and click Add to optional.

4. Find mailserver and click Add to optional.
5. Scroll down if necessary and click OK to add those two attributes to the
inetOrgPerson object class.
6. Manage entries again, as shown in Figure 3-38 on page 123, and find the
user object and click Edit Attributes.
7. Click Optional Attributes and scroll down to find the mailfile and mailserver
attributes and enter values (Figure 3-42).
Figure 3-42 Adding values to mailfile and mailserver attributes

3.10 Adding Attribute values via LDAPModify
Instead of using the Tivoli Directory Server WEB Administration tool you can use
LDAPModify to add the attribute values.
Example 3-7 Example

dn: uid=cprice,cn=users,dc=itso,dc=com
notescon: CN=Charles Price/O=ITSO
notesdn: CN=Samuel Palmisano,O=ITSO
Mailfile: mail\SPalmisano.nsf
mailserver: dwa.cam.itso.ibm.com
SametimeServer: stchatcluster
To add the values to Charles Price’s object we used the command:

C:\IBM\LDAP\V6.0\bin>ldapmodify -h tds.cam.itso.ibm.com -D cn=root -w
redb00k c:\download\charles.ldif

4
Chapter 4. Deployment phase 1 -

implementing Community
Services
This chapter details step-by-step instructions on how to build the basic
foundational components of an enterprise-level Sametime infrastructure.
Chapter 5, “Deployment phase I - implementing Meeting Services” on page 281,
covers the meeting services portion of the basic infrastructure, while subsequent
chapters go into more detail on how to integrate other IBM products into this
Sametime infrastructure and how to secure the environment.
For now, we walk through building the community services portion of ITSO
Corp.’s base Sametime environment. Additionally, we address the issue of load
balancing.
Keep in mind that each enterprise has its own specific business requirements.
However, the basics of a Sametime infrastructure remain the same across all
types of environments. Sametime’s basic building blocks, in which we go into in
great detail, provides the best in terms of stability, availability, and scalability for
your collaboration infrastructure. Throughout this chapter we identify specific
points of interest that can be used for the decision-making process in regards to
how to best optimize Sametime for your own environment.

4.1 What you build in this chapter
Our goal throughout this chapter is to walk you through the step-by-step process
of building ITSO Corp.’s planned chat environment, as illustrated in Figure 4-1.
ITSO s Sametime Community Infrastructure
ITSO's Sametime Community Infrastructure
Instant
Messaging
User
Load
Balancer
1533 1533 1533

8082 8082 8082

MUX1 MUX2 MUX3
1516 1516
1352
1516
Server Server
ST
CLUSTER
Load
Balancer

1 2
Figure 4-1 ITSO Corporation’s Sametime community infrastructure

We follow the general steps outlined below to create ITSO Corporation’s chat
environment:
1. Deploy clustered chat servers.
2. Deploy stand-alone mux servers.
3. Install and configure IBM Edge Load Balancer components.
Building the Community Infrastructure
1 2 3
Deploy
Deploy Deploy
WebSphere
Clustered Stand-Alone
Edge
Chat servers MUX servers
Load Balancer
– Install Domino – Deploy Mux – Setup the

– Install Sametime servers Load Balancer
– Setup Domino – Sanity checks – Sanity checks
Cluster
– Setup Sametime
cluster
– Sanity checks
Figure 4-2 Process of building the community infrastructure
Chapter 4. Deployment phase 1 - implementing Community Services 131

4.2 Perspective - how this fits into the overall enterprise
infrastructure
As mentioned in 4.1, “What you build in this chapter” on page 130, the focus of
this chapter is to illustrate, step-by-step, the planned chat environment for ITSO
Corporation. Keep in mind that this is only one component of their overall global
infrastructure. As shown in Figure 4-3, this is the portion we focus on.
Chat cluster within one of the geographies
United States EMEA Asia Pacific

75,000 Users 30,000 Users 15,000 Users

Instant Instant Instant

Messaging Messaging Messaging
User User User
Load Load Load Load Load Load

Balancer Balancer Balancer Balancer Balancer Balancer
(Primary) (Backup) (Primary) (Backup) (Primary) (Backup)
Sametime Sametime Sametime Sametime Sametime Sametime Sametime

MUX1 MUX2 MUX3 MUX1 MUX2 MUX1 MUX2

ST ST
CLUSTER CLUSTER
Load Load Load Load
Directory
Directory
Balancer Balancer Balancer Balancer

(Primary) (Backup) (Primary) (Backup)
LDAP Server LDAP Server LDAP Server LDAP Server LDAP Server
1 2 1 2 1
LDAP Replication LDAP Replication
Invited Meeting Server Model Invited Meeting Server Model
Meeting Services
Meeting Services

Meeting Meeting Meeting Meeting
1 2 3 4
External Sametime infrastructure shown on separate diagram
Figure 4-3 Overall corporate Sametime global architecture for ITSO Corporation

4.3 Deploy clustered chat servers
What are the true benefits of deploying clustered chat servers?
򐂰 High availability for instant messaging users
򐂰 Increased stability for chat environment
򐂰 Unlimited scalability with growth of the enterprise
To take advantage of these great benefits, we have to start from the beginning:
setting up the chat servers.
Section overview
In this section we describe the step-by-step process of setting up and deploying
the clustered Sametime servers for the ITSO Corporation’s chat environment.

Server Server
ST
CLUSTER
Figure 4-4 ITSO Corporation’s Sametime clustered chat servers
The following steps are taken to set up ITSO Corporation’s clustered chat
servers:
1. Install/configure the first chat server.
2. Install/configure the second chat server.
3. Create a Domino cluster.
4. Create a Sametime cluster.
4.3.1 Install/configure the first chat server

Before we begin:
򐂰 Make sure that all of the required software is available:
– Notes/Domino 7.0.1
– Sametime 7.5.x
򐂰 Verify that the LDAP directory is ready for use.
򐂰 All of the required hardware is available: five Windows server machines.

Domino Server setup
Pre-Domino install checklist:
򐂰 Make sure that the required hardware and software components are in place
and working.
Read the Domino server release notes for operating system and network
protocol requirements and for any last-minute changes or additions to the
documentation. Refer to the following URL for additional Lotus Domino
documentation:
http://www.lotus.com/ldd/notesua.nsf/find/domino
򐂰 Temporarily disable any screen savers and turn off any virus-detection
software.
򐂰 Before running any Domino setup command, be sure to complete any
pending reboot actions you may have from installing other applications.
򐂰 Make sure that all other applications are closed. Otherwise, you may corrupt
any shared files, and the install program may not run properly.
򐂰 We prefer if you do not use terminal services (Remote desktop) to perform the
installation. If you must use Remote Desktop to perform the Domino
installation, run it using the console option. See the following technote for
more details:
http://www.ibm.com/support/docview.wss?rs=899&uid=swg21165114
򐂰 The operating system date, time, and time zone information should be
updated to reflect the correct information.
򐂰 This server should have a static IP and host name that is resolvable via DNS.
Install Domino
To install Lotus Domino on a Windows platform, follow these steps:
1. Run the install program (setup.exe), which is on the Domino server
installation CD.
2. On the Welcome to the InstallShield Wizard for Lotus Domino screen, click
Next.
3. On the Software License Agreement screen, select the I accept the terms in
the license agreement option and click Next.

4. Choose the program directory in which to copy the Lotus Domino software
(that is, C:\Lotus\Domino). Click Next.
Figure 4-5 Choosing the program directory for Lotus Domino
Attention: Do not check the Install Domino Partitioned servers option.

5. Choose the data directory in which to copy the Lotus Domino data files (that
is, C:\Lotus\Domino\data). Click Next.
Figure 4-6 Choosing the data directory for Lotus Domino

6. On the "Choose the setup type that best suits your needs" screen, select
Enterprise Server and click Next.
Figure 4-7 Domino server type: Enterprise Server

7. On the following screen is a summary of your selections. After a careful
review, click Next to begin the installation. See Figure 4-8.
Figure 4-8 Summary of selected installation options

8. Once completed, click Finish to complete the installation and exit the
installer. See Figure 4-9.
Figure 4-9 Installation complete
Configure Domino
To configure Domino:
1. Select Start → Programs → Lotus Applications → Lotus Domino Server.
2. Select Start Domino as a Windows service and click OK (Figure 4-10).
Figure 4-10 Start Domino as a Windows service
3. On the Welcome to Domino Server Setup screen, click Next.

4. On the First or additional server screen (Figure 4-11), select Set up the first
server or a stand-alone server and click Next.
Figure 4-11 Set up the first server or a stand-alone server
5. On the Provide a server name and title screen, fill in the fields, as shown in
Table 4-1.
Table 4-1 Providing the Domino server name and description

Field Value
Server name chat1
Server title (optional) Sametime Chat Server 1

6. Click Next to continue (Figure 4-12).
Figure 4-12 Provide a server name and title
7. On the Choose your organization name screen, fill in the fields, as shown in
Table 4-2.
Important: The password entered on this screen is for the certifier ID

(cert.id), which will be used to register additional servers. Make sure to
remember the password that is provided. In addition, the certifier ID gets
stored in the Domino data directory (that is, c:\Lotus\Domino\data) after
this setup is completed.
Table 4-2 Domino organization setup

Field Value
Organization Name ITSO
Organization password
Certifier Password
Confirm Password password

Figure 4-13 Choose your organization name
9. On the Choose the Domino domain name screen, enter the name for the
Domino domain and click Next to continue. (In general, the Domino domain
name is set to the same value as the Domino organization name. In our case,
it is ITSO.)
10.On the Specify an Administrator name and password screen, fill in the fields
as in Table 4-3.
Table 4-3 Specify an administrator name and password

Field Value
First Name Sametime
Last Name Admin
Administrator password
password
Confirm password password

11.Check the "Also save a local copy of the ID file" option.
Important: By default, this option will store the administrator’s ID file

(admin.id) in the Domino data directory. This ID will be used to manage the
Sametime/Domino server via a Lotus Notes client. Make sure to keep a
backup of this file.
12.Click Next to continue (Figure 4-14).
Figure 4-14 Specify an administrator name and password
13.On the "What Internet services should this Domino Server provide" screen, do
the following:
a. Check Web Browsers (HTTP services).
b. Uncheck Directory services (LDAP services).

Important: We do not recommend running the LDAP server task on a
Sametime server. The LDAP server task allows the Domino server to act
as an LDAP serer to allow for information within the Domino directory to be
accessed via the LDAP protocol. However, running Sametime on a Domino
LDAP server is not a supported configuration and that is why we
recommend that the LDAP server task not be loaded on this server.
14.Then click Customize and uncheck the following Domino server tasks:
– Mail Router
– Calendar Connector
– Schedule Manager
– DOLS Domino Off Line Services
– Rooms and Resources Manager
Tip: Only the following Domino server tasks should still be checked:
򐂰 Database Replicator
򐂰 Agent Manager
򐂰 Administration Process
򐂰 HTTP Server

15.Click OK, then Next to continue (Figure 4-15).
Figure 4-15 What Internet services should this Domino server provide

16.On the Domino network settings screen, click Customize and do the
following:
a. Uncheck NetBIOS over TCP/IP.
b. For the TCP/IP Notes Port Driver, enter the fully qualified host name for
the Domino server in the Host Name (Editable) field.
c. In the text field on the bottom of the screen, enter in the same fully
qualified host name for the Domino server.
Figure 4-16 Advanced Network Settings
17.Click OK and then Next to continue.

18.On the Secure your Domino Server screen, uncheck "Prohibit Anonymous
access to all databases and templates" and then click Next.
19.On the "Please review and confirm your chosen server setup options" screen,
confirm the options you have selected and then click Setup to initiate the
Domino Server setup process.
20.Once completed, a Setup Summary screen will be displayed. Click Finish to
complete the setup process.
Post-Domino installation/configuration steps

You have now successfully installed and configured the Lotus Domino server
that will be used as the base for the Sametime server component. However,
before Sametime can be installed, the Domino server needs to run at least once
so that it can be properly initialized to allow for a successful Sametime
installation.

At this time, start the Lotus Domino Server (LotusDominodata) service and let
the server run for at least 10 full minutes to allow the Domino server enough time
to initialize properly. (Ten minutes is generally longer than actually needed, but to
be on the safe side, we recommend that the Domino server run for a full 10
minutes during this step.)
To start the Lotus Domino Server (LotusDominodata) service, do the following:

1. Click Start → Run and enter the following:
services.msc
2. Right-click Lotus Domino Server (LotusDominodata) and select Start.
Important: The above step is a mandatory step prior to installing Sametime. If

the Domino server is not properly initialized, the Sametime installation could
result in a failure.
Verification checkpoint - Domino server setup

At this point we recommend that you perform some sanity checks to verify that
your Domino server setup was successful and that its current configuration will
not pose any issues for the anticipated Sametime server setup. To validate the
Domino server setup:
1. Verify local network configuration:
a. On the server, click Start → Run and enter:
cmd
b. In the command prompt window that appears, enter the following
command (substitute chat1.cam.itso.ibm.com for your fully qualified host
name):
ping chat1.cam.itso.ibm.com
Figure 4-17 The ping test should reply back with the correct IP

c. In the same command prompt window, you should also enter the following
command and verify that your server is listening on the correct IP address:
ipconfig
2. Verify that the Domino HTTP server starts successfully. Launch an Internet
browser on the server machine and point it to the Domino server (that is,
http://chat1.cam.itso.ibm.com). You should expect to see the default Domino
home page.
Figure 4-18 Default Domino home page
3. Verify access to the Domino server via a Notes client.

4. From a Lotus Notes client, select the following from the menu bar: File →
Database → Open. Type the fully qualified host name into the Server field
(that is, chat1.cam.itso.ibm.com) and click Open. If a list of databases
populates the Database list box, then you have successfully connected to the
Domino server via a Notes client.
This completes the Domino Server setup section.

4.3.2 Sametime server setup
The pre-Sametime installation steps:
1. If applicable, turn off Windows Data Execution Prevention (DEP) for
Sametime per the following technote:
2. Set the startup type for the Lotus Domino Server (LotusDominodata) service
to manual.
3. Reboot the operating system.
Pre-Sametime install checklist:

and working.
򐂰 Make sure that the Domino server.id does not have a password. When you
installed Lotus Domino, if you provided a password for the server.id, you
should remove the password. To remove a password from a server.id, log in
to the Lotus Notes client using the server.id. Then choose File → Security →
User Security and reset the password to be empty.
򐂰 Make sure that the Domino server has the HTTP server task enabled.
Attention: While it is not required to remove the password from the

server's ID file, we recommend it from a best practices point of view with
regards to Sametime. Having a password on a server ID prevents the
server from coming up automatically without user intervention.
򐂰 Make sure that you have an Internet password. You must have an Internet
password in order to access the Lotus Sametime components of the server
during installation.
򐂰 Make sure that you know the name of the Domino server. If you do not know
the Domino server name, you can find it in the Server document. Verify that
the Domino server has a fully qualified host name, for example,
chat1.cam.itso.ibm.com.
򐂰 Make sure that the client computers can ping the Sametime server using the
fully qualified name. This ensures that the computer is registered in DNS or
the name is in a hosts file. For example, from a command prompt execute the
following command:
ping sametime.itso.com
򐂰 Make sure that you know the location of the Domino program and data
directories.

򐂰 Make sure that you know the type of directory (Domino directory or LDAP
directory) that you are going to use. We use an LDAP directory for ITSO
Corporation.
software on the server computer reserved for Sametime server installation.
򐂰 Make sure that all applications on the computer reserved for Lotus Sametime
installation (including the Domino Server Administrator and the Web browser)
are closed. Otherwise, you might corrupt any shared files and the installation
program might not run properly.
򐂰 Make sure that the Domino services are stopped.
򐂰 Back up all customized data files (.ntf, .mdm, .scr, .bmp, .mac, .smi, .tbl).
򐂰 Make backup copies of all ID files, names.nsf, notes.ini, desktop.dsk, and
pubnames.ntf.
򐂰 Make sure that the Domino server has been started at least once. This is
necessary to ensure that the required databases are successfully created and
initialized.
򐂰 Read the Lotus Sametime Release Notes for last-minute changes or
additions that may impact the server install. The release notes for Sametime
can be found at:
http://www.lotus.com/ldd/notesua.nsf/find/sametime
򐂰 Before running any Sametime setup command, complete any pending reboot
actions that you may have from installing other applications.
Install Sametime
To install Lotus Sametime on Microsoft Windows:
1. Shut down the Domino server.
2. Insert the Sametime installation CD. If the autorun program does not start, run
demo32.exe to start the installation program.
3. Select the language to install and click OK.
4. At the Welcome screen click Next.
5. Read and accept the license agreement and then click Next.
6. Select LDAP Directory and fill in the fields as shown in Table 4-4.
Table 4-4 LDAP Directory settings

Field Value
LDAP Server Name tds.cam.itso.ibm.com
Port Number for LDAP 389

Tip: If Active Directory is used for directory services, we recommend using
the Active Directory’s Global Catalog on port 3289. This is necessary when
the LDAP directory spans multiple domain controllers because Sametime
will not follow LDAP referrals. The Global Catalog stores a condensed
version of the full LDAP directory, which allows all users within that
directory to participate in Sametime.
Figure 4-19 Select the directory to use for collaboration
9. Uncheck the Enable HTTP tunneling field and click Next.
Note: For more information about HTTP tunneling see 7.6, “HTTP
tunneling” on page 609.
10. Review the summary information and then click Install.
11. Once completed, click Finish to exit the installation wizard.
12. Reboot the operating system to complete the installation.

Verification checkpoint - Sametime server installation
Before configuring Sametime, it is a good idea to perform a sanity check to
validate that the Sametime installation was successful. We recommend the
following:
1. Ascertain that all Sametime services were registered successfully:
a. Click Start → Run and enter:
services.msc
b. In the Windows services panel, verify that all of the following exist:
• Lotus Domino Server (LotusDominodata)
• Sametime Meeting Server
• Sametime server
• ST Admin Service
• ST Buddylist
• ST Capabilities
• ST Chat Logging
• ST Community
• ST Community Launch
• ST Conference
• ST Configuration
• ST Directory
• ST File Transfer
• ST Links
• ST Logger
• ST mux
• ST OnlineDir
• ST Places
• ST Policy
• ST Polling
• ST Privacy
• ST Reflector
• ST Resolve
• ST Security
• ST User Storage
• ST Users

2. Confirm that Sametime’s configuration file (sametime.ini) was created
properly. Using your favorite text editor, open up sametime.ini located in the
Domino program directory (that is, c:\Lotus\Domino\sametime.ini). Verify that
all of the settings below exist are set accordingly respective to your local
environment (Example 4-1).
Example 4-1 Sametime.ini after Sametime installation

# Sametime configuration file
[Config]
VP_PRIV_SYM=1
VPS_IGNORE_UNKNOWN_CLIENT_IP=1
VPMX_CAPACITY=20000
SAKeyMapper=ConfigurationKeyMapperStandalone.properties
RSKeyMapper=ConfigurationKeyMapperRoomserver.properties
ST_JAVA_CLASS_PATH=C:\Lotus\Domino\java;C:\Lotus\Domino\StConfig.jar;C:
\Lotus\Domino\StConfigXml.jar
ST_CONFIG_XML=C:\\Lotus\\Domino\\StCommunityConfig.xml
ST_JAVA_BB_CLASS_NAME=com.lotus.sametime.configxml.ConfigXmlManager
VP_SECURITY_LEVEL=25
HTMLRootDirectory=C:\Lotus\Domino\data\Domino\html
EnableStaticInvites=0
ClusterGroupAffinity=Isolation
VPS_NAME=CN=chat1/O=ITSO
[STLinks]
STLINKS_MAX_USERS=2500
STLINKS_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause
STLINKS_MAX_OPEN_CONNECTION_TIME=600000
[Policy]
POLICY_DB_BB_IMPL=com.ibm.sametime.policy.databasebb.notes.DbNotesBlack
Box
POLICY_ADAPTER_IMPL=com.ibm.sametime.policy.calculateservice.PolicyDefa
ultAdapter
POLICY_DIRECTORY_BB_IMPL=com.ibm.sametime.policy.directorybb.ldap.DirLd
apBlackBox
POLICY_UNIQUE_TRACE_FILES=1
POLICY_MAX_THREADS=5
POLICY_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause
[Debug]
POLICY_DEBUG_LEVEL=1
VPDIR_IGNORE_BROWSE=1
[STReflector]
STREFLECTOR_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause
[STCapabilities]
STCAPABILITIES_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause

Note: After starting Sametime for the first time, additional parameters will
be added to sametime.ini under the [Config] section. For your reference,
they are:
[Config]
SametimeCluster=CN=chat1/O=ITSO
SametimeDirectory=C:\Lotus\Domino\data
ConfigurationPort=80
ConfigurationHost=chat1.cam.itso.ibm.com
SametimeEventServerPort=9092
ConfigurationChangeListener.count=1
ConfigurationChangeListener.classname.1=com.lotus.sametime.config
uration.EventPublisherConfigurationChangeListener
ConfigurationChangeNotifier.count=1
ConfigurationChangeNotifier.classname.1=com.lotus.sametime.config
uration.EventListenerConfigurationChangeNotifier
Locale=en
3. Verify that all of the Sametime servlets initialize successfully:

a. Using a text editor, open the notes.ini configuration file located in the
Domino program directory (that is, c:\Lotus\Domino\notes.ini).
b. Remove STAddin from the ServerTasks notes.ini parameter and save the
notes.ini configuration file.
Example 4-2 notes.ini with STAddin removed

ServerTasks=Update,Replica,AMgr,AdminP,HTTP
c. Start the Lotus Domino Server (LotusDominodata) service from the

Windows services panel, and do the following.
Note: To start the Lotus Domino Server (LotusDominodata) service:

services.msc
2. Right-click Lotus Domino Server (LotusDominodata) and select
Start.

i. Verify that each of the Sametime servlets initializes successfully. As
each servlet initializes, a debug print is written to the Domino server
console. See Example .
Example 4-3 Domino bootstrap servlet successful initialization example

02/12/2007 03:52:09 PM HTTP JVM:
com.lotus.sametime.configuration.DominoBootstrapServlet:init
Note: The Sametime servlets that will load on server startup are:
򐂰 Domino Bootstrap Servlet
򐂰 Domino Configuration Servlet
򐂰 Access Control Servlet
򐂰 Domino Admin XPath Request Servlet JAXP
򐂰 MMAPI Servlet
򐂰 Notes Calendar Servlet
򐂰 File Upload Servlet
򐂰 RAP File Servlet
򐂰 Statistics Servlet
򐂰 Conversion Servlet
򐂰 Policy Servlet
򐂰 Name Change Servlet
򐂰 Meeting Servlet
򐂰 Telephony Servlet
򐂰 UserInfo Servlet
ii. Verify that the Domino HTTP server starts successfully.

Launch an Internet browser on the server machine and point it to the
Domino server (that is, http://chat1.cam.itso.ibm.com). You should
expect to see the default Domino home page.
At this point, we are ready to configure Sametime.
Configure Sametime
To configure Sametime:
1. Launch a Lotus Notes client and log in using the Sametime administrator ID.

2. From the menu bar, select File → Database → Open and open the Domino
directory (names.nsf) (Figure 4-20).
Figure 4-20 Open the Domino directory
3. Expand Configuration → Servers → All Server Documents.

4. Double-click the Sametime server document to open it.

5. Check the following fields to make sure that they have the appropriate values
(Table 4-5).
Table 4-5 Sametime server document - Basics

Basics
Field Value
Fully Qualified Internet host name (FQHN) chat1.cam.itso.ibm.com
This value should be the host name that

your end users use to access the server.
Load Internet Configurations from disabled

Server\Internet Sites documents
Sametime is not designed to retrieve

Internet configurations from Internet site
documents, and therefore this should be
disabled.
Is this a Sametime server? Yes
This setting indicates whether the Domino

server is a Sametime server. It is used by
each Sametime server to determine which
servers are part of the Sametime
community.
Directory assistance database name da.nsf
When you install Sametime to use an

LDAP directory, a directory assistance
database is created, and, by default, it is
named da.nsf. If you have another
database that you prefer to use, update
this field to point to that one.
Run This Script After Server Fault/Crash c:\Lotus\Domino\stdiagzip.bat
If a server crashes, it would run this batch

file, which collects all the pertinent
diagnostics used by IBM Support.
Directory Type Primary Domino directory

Basics
Field Value
Security
Run unrestricted methods and operations Sametime Development/Lotus

Notes companion products
This field should contain the value on the
right for proper operation of the Sametime
server.
Administrators LocalDomainAdmins
This field should not be empty. It should at

the very least contain an administrator’s
group.
Internet authentication Fewer name variations with

higher security
Provides more security when logging into
the Domino Web server.
Ports/Notes network ports
On this tab with a fresh install, you should only have one line item. The fields
and respective values are listed below.
Port TCPIP
Protocol TCP
This is populated by the administration

process.
Notes Network TCPIP Network
This is an arbitrary value, but it is used for

Domino Messaging. We recommend
keeping this value matching on all
Sametime servers in the same community.
Net Address chat1.cam.itso.ibm.com
We recommend setting this value to the

fully qualified host name. It should match
the Fully Qualified Internet host name field
on the Basics tab.
Enabled Enabled

Basics
Field Value
Ports/Internet ports
TCP/IP port number 80
By default the Domino HTTP Web server

will listen on all IPs for this port. Make sure
that there are no other products that will
interfere with this port.
TCP/IP port status Enabled
Authentication options Yes
Name and password.
Anonymous.
SSL port number 443
SSL port status Disabled
Internet Protocols/HTTP
Home URL /stcenter.nsf?Open
Internet Protocols/Domino Web Engine
Session Authentication Multiple Servers (SSO)
Web SSO Configuration LtpaToken
Java Servlet Support Domino Servlet Manager
Servlet URL path /servlet
Class path Domino\servlet
6. If any changes were made, click Save & Close.

7. Expand Configuration → Web → Web configurations → * - Web SSO
Configuration.
8. Highlight the Web SSO Configuration for LtpaToken document, press the
Delete key, and press F9 to permanently delete the document.
10.Select Web → Create Web SSO Configuration from the Action bar.

11.Fill in the fields as listed in Table 4-6.
Table 4-6 Web SSO configuration for LtpaToken

Field Value
Configuration Name LtpaToken
Organization (Leave blank)
DNS Domain .cam.itso.ibm.com
Note the dot preceding the

Internet domain suffix:
.domain.com
Map names in LTPA Disabled
tokens
Domino Server Names chat1/ITSO
From the address book,

select the Sametime
server.
Figure 4-21 Web SSO configuration for LtpaToken

12.From the action bar, click Keys → Create Domino SSO Key.
You will be prompted with a message Successfully created Domino SSO key
(Figure 4-22).
Figure 4-22 Creating Domino SSO key
13.Click Save & Close to save the document.

14.Confirm administrative access to the Sametime server for the LDAP account
that will be used to administer the server:
a. Click the Groups view.
b. Double-click the LocalDomainAdmins group.
c. In the Members field, enter the distinguished name (DN) of the LDAP
account that will be used to administer the Sametime server. See
Table 4-7 for examples on how to enter the DN into the Members field.
Table 4-7 Typical LDAP DN formats

LDAP What to enter Directory type
distinguished
name (DN)
1 cn=administrator,c cn=administrator/ Active Directory

n=users,dc=ibm,dc cn=users/dc=ibm/d
=com c=com
2 uid=stadmin,cn=us uid=stadmin/cn=us Tivoli Directory

ers,dc=itso,dc=co ers/dc=itso/dc=co Server
m m
3 cn=Sametime Sametime Domino LDAP

Administrator,ou=A Administrator/Aus Directory
ustin,O=IBM tin/IBM

Note: Make sure that you change the commas to slashes when
entering the distinguished name into the Members field.
In the third example above (Sametime Administrator), note that the

canonical format changes to the hierarchical format. Since the LDAP
hierarchical structure matches that of native Domino's, the name
automatically normalizes to the hierarchical format.
For example, if you enter cn=Sametime

Administrator/ou=Austin/O=IBM, the name automatically normalizes to
Sametime Administrator/Austin/IBM. This behavior is most commonly
seen when using the Domino LDAP directory.
d. Click Save & Close for the group document.

e. While still in the Groups view, select File → Database → Access Control
from the Notes menu bar.
f. Verify that the administrative group (LocalDomainAdmins) is listed in the
ACL with manager access. If not, add the group as needed with the
settings shown in Table 4-8.
Table 4-8 LocalDomainAdmins ACL access to names.nsf

Field Value
User Type Person Group
Access Manager
Privileges Check All
Roles Check All

Figure 4-23 Access Control List to: ITSO Corporation’s Directory
g. Click OK to close the ACL for the Domino directory (names.nsf).

h. From the menu bar, select File → Database → Open and open the
Sametime Configuration database (stconfig.nsf).
Figure 4-24 Open Sametime Configuration Database
i. From the Notes menu bar, select File → Database → Access Control.
j. Verify that the administrative group (LocalDomainAdmins) is listed in the
settings given in Table 4-9.
Table 4-9 LocalDomainAdmins ACL access to stconfig.nsf

Field Value
Access Manager
Roles Check All

Figure 4-25 Access Control List to: Sametime Configuration
15.Configure directory assistance to allow for LDAP authentication to the Domino

Web server:
a. From the menu bar, select File → Database → Open and open the
directory assistance database (da.nsf).
b. Double-click the LDAP document to open it.
c. Fill in the fields as shown in Table 4-10.
Table 4-10 Directory assistance - LDAP

Basics
Field Value
Domain type LDAP
Domain name LDAP
Company name LDAP

Basics
Field Value
Search order 1
Make this domain available to Notes Clients and Internet authentication/

authorization
Group Authorization Yes
Nested Group Expansion No
Enabled Yes
Attribute to be used as name in an SSO (Leave blank.)

token (map to Notes LTAP_UsrNm)
Naming contexts (rules)
Trusted for Credentials Yes

Use only the first rule.
LDAP
Hostname tds.cam.itso.ibm.com
Provide the host name of the LDAP server.
Username cn=root
Provide a valid LDAP account that will be
used by Domino to bind to the LDAP
server. This account will make requests
on behalf of the Domino server to perform
Web authentication.
Password password
The password for the account listed
above.
Base DN for search dc=itso,dc=com
Channel encryption None
16.Click Save & Close.

17.Restart the Domino server.

Tip: Never use the restart server command to restart the Sametime
server. It does not provide enough time for all of the Sametime processes
to shut down cleanly before the Domino server attempts to start back up.
This can cause many problems which we would like to avoid. In order to
restart the Sametime server, we recommend splitting the process: 1) quit
the server first, and then 2) start it back up.
18.When the Domino server is back up, we update Sametime’s LDAP settings
via the Sametime administration interface:
a. Launch an Internet browser and point it to:
http://chat1.cam.itso.ibm.com/stcenter.nsf
b. Click Administer the server.
c. Enter the user name and password for the LDAP account that you
specified in the LocalDomainAdmins group.
d. Expand LDAP Directory → Connectivity and fill in the fields as shown in
Table 4-11.
Table 4-11 LDAP Directory - connectivity settings

Field Value
Host name or IP address of the LDAP tds.cam.itso.ibm.com

server
Position of this server in the search order 1
Port 389
Administrator distinguished name cn=root
Administrator password password
Use SSL to authenticate and encrypt the (Leave blank for now)
connection between the Sametime server
and the LDAP server
LDAP SSL Port 636
e. Click Update if you made any changes.

f. Expand LDAP Directory → Basics and fill in the fields as shown in
Table 4-12.
Table 4-12 LDAP Directory - basics

Field Value
Where to start searching for people (base cn=users,dc=itso,dc=com

object for person entries)
Scope for searching for a person (the recursive

number of levels below the base object,
for example, subtree or one level)
The attribute of the person entry that cn

defines the person’s name (for example,
cn or mail)
Attribute used to distinguish between two uid

similar person names
Attribute of a person entry that defines the mail

person’s e-mail address
The object class used to determine if an organizationalPerson

entry is a person (for example,
organizationalPerson)
Where to start searching for groups (base cn=groups,dc=itso,dc=com

object for group entries)
Scope for searching for groups (the recursive

number of levels below the base object)
Attribute of the group that defines the cn

group name (for example, cn or mail)
Attribute used to distinguish between two

similar group names
The group object class used to determine groupOfUniqueNames

if an entry is a group (for example,
groupOfNames or groupOfUniqueNames)
g. Click Update if you made any changes.

h. Expand LDAP Directory → Authentication and fill in the fields as shown
in Table 4-13.
Table 4-13 LDAP Directory - authentication

Field Value
Search filter to use when resolving a user (&(objectclass=organizationalPerson)(|(c

name to a distinguished name (Modifying n=%s)(givenname=%s)(sn=%s)(mail=%s
this field affects the name people use to )))
authenticate.)
Home Sametime server stserver
i. Click Update if you made any changes

j. Expand LDAP Directory → Searching and fill in the fields as shown in
Table 4-14.
Table 4-14 LDAP Directory - searching

Field Value
Search filter for resolving person names (&(objectclass=organizationalPerson)(|(c

n=%s*)(givenname=%s*)(sn=%s*)(mail=
%s*)))
Search filter for resolving group names (&(objectclass=groupOfUniqueNames)(c

n=%s*))
Policy search filters
Base Membership
Group Membership ibm-allgroups
k. Click Update.
l. Expand LDAP Directory → Group Contents and fill in the fields as
shown in Table 4-15.
Table 4-15 LDAP Directory - group contents

Field Value
Attribute in the group object class that has ibm-allmembers

the names of the group members (for
example, member or uniqueMember)
m. Click Update.

19.Shut down the Domino server.
We have completed configuring Sametime. We now need to proceed with

validating this configuration.
Verification checkpoint - Sametime server configuration

The steps are:
1. Load the Windows services panel.
2. Click Start → Run and enter:
services.msc
3. Right-click the Sametime Meeting Server service and select Properties.
4. Click the Log On tab and check Allow service to interact with desktop.
Click Apply and then OK.
Tip: This step provides the administrator with the ability to monitor the
Sametime Meeting server’s start up process. From a troubleshooting
perspective, we recommend enabling this. By allowing the service to
interact with the desktop, the next time the server is started, you will see
three console windows:
򐂰 Lotus Domino server console
򐂰 Sametime Meeting server console (../nstmeetingserver.exe)
This console window shows the startup process for the Sametime
Meeting server and its services.
򐂰 Sametime Gateway service console (STGWService.exe)
This console window will appear but will remain blank. Do not close this
window because if you do it will terminate the process improperly. This
is not the same as the new 7.5.1 Sametime product known as
Sametime Gateway.
5. Using your favorite text editor, open the notes.ini configuration file located in
the Domino program directory (that is, c:\Lotus\Domino\notes.ini).
6. Add STAddin back to the ServerTasks notes.ini parameter and save the
Example 4-4 notes.ini with STAddin added back in

ServerTasks=Update,Replica,AMgr,AdminP,HTTP,STAddin
7. Start the Lotus Domino Server (LotusDominodata) service from the Windows
services panel.

Tip: To start the Lotus Domino Server (LotusDominodata) service:
a. Click Start → Run and enter the following:
services.msc
b. Right-click Lotus Domino Server (LotusDominodata) and select
Start.
8. As the Sametime server loads, you should expect to see three console
windows, as previously described. If you do not see three console windows,
then the Sametime Meeting services most likely failed to load. For more
information about how to resolve that, see the following technote:
9. Verify that all of the Sametime-related services are running:
a. Launch an Internet browser and direct it to:
http://chat1.cam.itso.ibm.com/
Note: When Sametime is configured to use single-sign on at the Web

server layer, it is important to note that the URL that is specified in the
browser’s address bar should always be the fully qualified host name.
b. Click Administer the server on the left-hand side.

c. Log in with the LDAP account that has manager access to stconfig.nsf.
Important: If you have configured Sametime to use an LDAP directory,

as we have done, you should always make sure to log in using an LDAP
account when administering the Sametime server. If you do not, you will
not be able to manage and assign Sametime policies.
d. On the Server-Overview page, you will see a complete list of all the
Sametime services and their respective statuses. Verify that all of the
Sametime services are running.
Notes: The Telephony Services (sttelephonyservice.exe) will not be

running by default. This is okay and should not be a point of concern.
It takes two minutes before Sametime’s community services start to

load. The delay in their startup should not be a point of concern either.

4.3.3 Install/configure the second chat server
In this section we install and configure the second chat server.
Domino setup
In this section we discuss the Domino setup.
Register second chat server

To do this:
1. Launch the Domino Administrator client.
2. From the menu bar, select File → Open Server, enter in the host name of the
first server that was set up (in our case, it was (chat1.cam.itso.ibm.com)), and
click OK.
3. Click the Configuration tab.
4. On the right-hand side, select Tools → Registration → Server.
Figure 4-26 Register Domino server

5. In the Choose a Certifier dialog window, click the Server button and enter the
Domino name of the first server in your Domino domain (that is, chat1/ITSO).
6. Choose the Supply certifier ID and password option, click the Certifier ID
button, and browse to the certifier ID file (cert.id).
7. Click OK to continue.
Figure 4-27 Choose a certifier
8. Enter the password for the certifier ID file and click OK.
Figure 4-28 Certifier password

9. You may be prompted with a Certifier Recovery Information Warning dialog
window. If you are, click OK to continue (Figure 4-29).
Figure 4-29 Certifier Recovery Information Warning
10.On the Register Servers dialog window, confirm that the registration server
(chat1/ITSO) and certifier (/ITSO) are correct. Click Continue to proceed.
Figure 4-30 Register Servers

11.On the Register New Server(s) dialog window, enter the fields as shown in
Table 4-16.
Table 4-16 Register new servers

Field Value
Server name chat2
Server title (optional) sametime community server 2
Domino domain name ITSO
Server administrator name Sametime Admin/ITSO
Location for storing server ID Uncheck In Domino Directory.

Check In file.
If you store the ID in the Domino directory,
you are forced to provide a password for
the server ID. We do not recommend
having a password on the server ID.
12.Click Set ID File and browse to the location of where the ID file should be
stored (that is, C:\Lotus\Domino\data\ids\servers\chat2.id).

13.Click the green check mark button to add the server to the registration queue
(Figure 4-31).
Figure 4-31 Register New Server(s) - Add to registration queue

14.Highlight the new server and click the Register button to complete the server
registration (Figure 4-32).
Figure 4-32 Register New Server(s) - Register
15.Click Done to close the Register New Server(s) dialog window.
You have successfully registered the second Sametime server. Proceed to the
next section.
Pre-Domino install checklist

The checklist is:
and working.
documentation:

software.
򐂰 We prefer if you do not use terminal services (Remote Desktop) to perform
the installation. If you must use Remote Desktop to perform the Domino
more details:
Install Domino
installation CD.
Next.

(that is, C:\Lotus\Domino) (Figure 4-33). Click Next.

is, C:\Lotus\Domino\data) (Figure 4-34). Click Next.

6. On the Choose the setup type that best suits your needs screen, select
Enterprise Server and click Next (Figure 4-35).

7. On the following screen is a summary of your selections. After a careful
review, click Next to begin the installation (Figure 4-36).

8. Once completed, click Finish to complete the installation and exit the installer
(Figure 4-37).
Configure Domino
To configure Domino:
2. Select Start Domino as a Windows service and click OK.

4. On the First or additional server screen, select Set up an additional server
and click Next (Figure 4-39).
Figure 4-39 Set up an additional server

5. On the Where is the ID file for this additional Domino server screen, select the
location of the server ID file and click Next.
Note: In previous steps, we stored the chat2’s server ID on chat1’s local

file system and not in the Domino directory. For this step within the setup
program, chat2’s server ID needs to be made accessible. We could map a
drive to chat1 or simply copy the file from chat1 to chat2. For this step, we
will copy chat2’s server ID from chat1’s local file system onto the Desktop
of chat2.
Figure 4-40 Where is the ID file for this additional Domino server?
6. On the Provide the registered name of this additional Domino server screen
click Next.

7. On the What Internet services should this Domino Server provide screen, do
the following:

access via the LDAP protocol. However, running Sametime on a Domino

8. Click Customize and uncheck the following Domino server tasks:
– Mail Router
– DOLS Domino Off Line Services
– Rooms and Resources Manager
򐂰 Agent Manager
򐂰 HTTP Server

9. Click OK, then Next to continue.
Figure 4-41 What Internet services should this Domino server provide?

following:
b. For the TCP/IP Notes Port Driver, enter in the fully qualified host name for

12.On the Provide the system databases for this Domino server screen enter the
fields shown in Table 4-17 and click Next.
Table 4-17 System databases for Domino

Field Value
Other Domino server name chat1/ITSO
Optional network address chat1.cam.itso.ibm.com
Use a proxy server to connect to the other Leave unchecked

Domino server

Field Value
Use a dialup connection Leave Unchecked
Get system databases from CD or other Leave Unchecked

media
13.On the Specify the type of Domino directory for this server screen, select Set
up as a primary Domino Directory and click Next.
14.On the Secure your Domino Server screen, uncheck “Prohibit Anonymous
access to all databases and templates” and click Next.
15.On the Please review and confirm your chosen server setup options screen,
confirm the options you have selected and then click Setup to initiate the
Post Domino installation/configuration steps

so it can be properly initialized to allow for a successful Sametime installation.
Being a second server within the environment, there are also a few extra steps
that should be taken to ensure a successful installation of Sametime:
1. At this time, start the Lotus Domino Server (LotusDominodata) service and let
the server run for at least 10 full minutes to allow the Domino server enough
time to initialize properly (10 minutes is generally longer than actually needed,
but to be on the safe side, we recommend that the Domino server run for a full
10 minutes during this step.)
To start the Lotus Domino Server (LotusDominodata) service, do the
following:
a. Click Start → Run, and enter the following:
services.msc
b. Right-click Lotus Domino Server (LotusDominodata) and select Start.
2. Issue the following commands on the chat2’s Domino server console to
perform an immediate synchronization between the two chat servers:
replicate chat1/ITSO names.nsf
replicate chat1/ITSO admin4.nsf
3. To ensure that these system databases stay in synch, create a connection
document so that these databases replicate on schedule.

Note: For more details on creating and configuring a connection document,
see the topic Scheduling server-to-server replication located in the Domino
Administrator Help file at:
http://doc.notes.net/domino_notes/7.0/help7_admin.nsf
Important: The above steps are mandatory prior to installing Sametime. If the
Domino server is not properly initialized the Sametime installation could result
in a failure.

At this point we recommend that you perform some sanity checks to verify that
your Domino server setup was successful and that its current configuration will
not pose any issues for the anticipated Sametime server setup. To validate the
1. Verify the local network configuration:
cmd
name):
ping chat2.cam.itso.ibm.com
ipconfig
2. Verify that the Domino HTTP server starts successfully.

Launch an Internet browser on the server machine and point it to the Domino
server (that is, http://chat2.cam.itso.ibm.com). You should expect to see the
default Domino home page, as in Figure 4-44.

Database → Open. Type in the fully qualified host name into the Server field
(that is, chat2.cam.itso.ibm.com) and click Open. If a list of databases
populate the Database list box, then you have successfully connected to the
4.3.4 Sametime setup

In this section we discuss Sametime setup.

Pre-Sametime installation steps
The steps are:
to manual.
Pre-Sametime install checklist

Check the following:
and working.

the Domino server name, you can find it in the server document. Verify that
the Domino server has a fully qualified host name, for example
chat1.cam.itso.ibm.com.
following command:
directories.

directory) that you are going to use. We use an LDAP directory for ITSO
Corporation.
pubnames.ntf.
initialized.
can be found at:
actions you may have from installing other applications.
Install Sametime

Field Value

will not follow LDAP referrals. The Global Catalog stores a condensed
7. Click Next to continue.
9. Uncheck the Enable HTTP tunneling field blank and click Next.
Note: For more information about HTTP tunneling see 7.6, “HTTP
tunneling” on page 609
11. Once completed, click Finish to exit the installation wizard.
12. Reboot the operating system to complete the installation.

following:
1. Ascertain that all Sametime services were registered successfully:
services.msc
b. In the Windows services panel, verify that all of the following exists:
• Sametime server
• ST Buddylist
• ST Capabilities
• ST Chat Logging
• ST Community
• ST Conference
• ST Directory
• ST Links
• ST Logger
• ST mux
• ST OnlineDir
• ST Places
• ST Policy
• ST Polling
• ST Privacy
• ST Reflector
• ST Resolve
• ST Security
• ST User Storage
• ST Users

all of the settings below exist and are set accordingly respective to your local
environment (Example 4-5).

[Config]
VP_PRIV_SYM=1
VPMX_CAPACITY=20000
[STLinks]
[Policy]
Box
ultAdapter
apBlackBox
[Debug]
[STReflector]
[STCapabilities]

Note: After starting Sametime for the first time, additional parameters will
be added to the sametime.ini under the [Config] section. For your
reference, they are:
[Config]
Locale=en
3. Verify that all of the Sametime servlets initialize successfully.


ServerTasks=Update,Replica,AMgr,AdminP,HTTP

Windows services panel, and do the following:

services.msc
2. Right-click Lotus Domino Server (LotusDominodata) and
select Start.

i. Verify that each of the Sametime servlets initialize successfully. As
console. See Example 4-7.
Example 4-7 Domino Bootstrap servlet successful initialization example

02/12/2007 03:52:09 PM HTTP JVM:
򐂰 MMAPI Servlet
򐂰 Policy Servlet
ii. Verify that the Domino HTTP server starts successfully. Launch an
Internet browser on the server machine and point it to the Domino
server (that is, http://chat2.cam.itso.ibm.com). You should see the
default Domino home page.
Configure Sametime
To configure Sametime:
1. Launch a Lotus Notes client and log in using the Sametime administrator’s ID.

directory (names.nsf).


5. Check the following fields (Table 4-19) to make sure that they have the
appropriate values.
Table 4-19 Sametime server document - basics

Basics
Field Value
Fully Qualified Internet host name (FQHN) chat2.cam.itso.ibm.com



disabled.

community.

database is created, and, by default, is


Basics
Field Value
Security

Notes Companion Products
server.

group.

higher security
Ports/notes network ports

Port TCPIP
Protocol TCP

process.

Domino Messaging. We recommend
keeping this value matching on all
Sametime servers in the same community.
Net Address chat2.cam.itso.ibm.com

on the Basics tab.
Enabled Enabled

Basics
Field Value
Ports/Internet ports

will listen on all IPs for this port. Make sure
Name and password.
Anonymous.
SSL port number 443
Internet Protocols/Domino Web engine
Class path Domino\servlet

Configuration.
8. Double-click the Web SSO Configuration for LtpaToken document to open
it.

9. Update the Domino Server Names field to include the second chat server
(chat2/ITSO).
Figure 4-47 Web SSO Configuration for LtpaToken
11.You will be prompted with a warning dialog with the following message:
This Web SSO Configuration has already been in initialized. Creating
new keys will overwrite existing SSO keys. Continue?
Click OK to continue.
Figure 4-48 Creating new Domino Web SSO keys

12.You will then be prompted with the message (Figure 4-49):
Successfully created Domino SSO key.
13.Click Save & Close to save the LtpaToken Web SSO document.
that will be used to administer the server.
Table 4-7 on page 161 for examples on how to enter the DN into the
Members field.

distinguished
name (DN)
1 cn=administrator,c cn=administrator/ Active Directory

n=users,dc=ibm,dc cn=users/dc=ibm/d
=com c=com

m m

Administrator,ou=A Administrator/Aus Directory
ustin,O=IBM tin/IBM

Notes: Make sure that you change the commas to slashes when
entering the distinguished name into the members field.


d. Click Save & Close.

settings shown in Table 4-21.

Field Value
Access Manager
Roles Check All

Figure 4-50 Access Control List to: ITSO’s Directory

Sametime Configuration database (stconfig.nsf).

following settings (see Table 4-9 on page 164).

Field Value
Access Manager
Roles Check All
15.Click OK to close the ACL for stconfig.nsf.

Web server.

c. Fill the fields in as in Table 4-23.

Basics
Field Value
Domain type LDAP
Domain name LDAP
Company name LDAP
Search order 1
Make this domain available to Notes Clients & Internet Authentication/

Authorization
Enabled Yes
Attribute to be used as name in an SSO (Leave blank.)

Naming contexts (rules)

Use only the 1st rule
LDAP
Username cn=root

Web authentication.

Basics
Field Value
Password password

above.

This can cause many problems that we would like to avoid. In order to
19.When the Domino server is back up, we update Sametime’s LDAP settings
via the Sametime administration interface.
Table 4-24.

Field Value

server.
Position of this server in the search order. 1
Port. 389
Administrator distinguished name. cn=root

Field Value
Administrator password. password
Use SSL to authenticate and encrypt the (Leave blank for now.)
and the LDAP server.
LDAP SSL Port. 636

Table 4-25.

Field Value



cn or mail)







similar group names

Field Value


h. Expand LDAP Directory → Authentication and fill in the fields as shown
in Table 4-26.
Table 4-26 LDAP Directory - authentication

Field Value

authenticate.)
i. Click Update if you made any changes.

j. Expand LDAP Directory → Searching and fill in the fields as shown in
Table 4-27.

Field Value

%s*)))

n=%s*))
Base Membership
k. Click Update.

l. Expand LDAP Directory → Group Contents and fill in the fields as
shown in Table 4-28.

Field Value

m. Click Update.
We have successfully completed configuring Sametime. We now can proceed to

validate this configuration.
Verification checkpoint - Sametime server configuration

The steps are:
2. Click Start → Run and enter:
services.msc
Tip: This step provides the administrator with the ability to monitor
Sametime Meeting server’s startup process. From a troubleshooting
This console window appears but remains blank. Do not close this
window because if you do, it will terminate the process improperly. This
Sametime Gateway.


ServerTasks=Update,Replica,AMgr,AdminP,HTTP,STAddin
services panel.

a. Click Start → Run, and enter the following:
services.msc
Start.
then the Sametime Meeting services most likely failed to load. For more
9. Verify that all of the Sametime-related services are running.


Important: If you have configured Sametime to use an LDAP directory,

like we have done, you should always make sure to log in using an
LDAP account when administering the Sametime server. If you do not,
you will not be able to manage and assign Sametime policies.

Sametime services and their respective status. Verify that all of the
Sametime services are running.
Notes: The Telephony Services (sttelephonyservice.exe) are not running

by default. This is okay and should not be a point of concern.
It takes two minutes before Sametime’s community services start to load.

The delay in their startup should not be a point of concern either.
4.3.5 Create a Domino cluster

We now have two Sametime chat servers in ITSO Corporation’s environment.
We tested basic functionality and confirmed server-to-server awareness between
chat1 and chat2. However, before we proceed with creating the Domino cluster,
we need to complete couple of steps to ensure basic best practices in terms of
Domino database replication.
1. Create a connection document between the two chat servers to schedule
replication every 60 minutes for the following databases: names.nsf,
admin4.nsf, vpuserinfo.nsf, stnamechange.nsf, and stauths.nsf.
2. After creating the connection document, manually replicate names.nsf and
admin4.nsf between the chat servers. On chat2’s Domino server console,
issue the following commands:
Configure Domino cluster

To do this:
2. From the menu bar, select File → Open Server and enter in the host name of
the first server that was set up (in our case, (chat1.cam.itso.ibm.com)) and
click OK.
4. Expand Server → All Server Documents.

5. Select both chat server documents by placing a check mark on both
documents, and click Add to Cluster from the action bar (Figure 4-53).
Figure 4-53 Add to Domino cluster
6. On the Verification dialog window, click Yes to continue.
Figure 4-54 Verification
7. On the Cluster Name dialog, select *Create new Cluster and click OK.
Figure 4-55 Cluster Name

8. On New Cluster Name dialog, enter a name for the Domino cluster in the
Enter the name of the new cluster field. The Domino cluster name is an
arbitrary name and does not have to match the Sametime cluster’s name,
which we set later in this chapter (that is, dominoCluster).
Figure 4-56 New Cluster Name
9. On the Immediate or Via Administration Process dialog, click Yes to perform

the action immediately.
Figure 4-57 Immediate or Via Administration Process
10.Click OK on the Request Successful dialog window.
Figure 4-58 Request Successful
11.Manually replicate the changes between the chat servers by issuing the
following commands on chat2’s Domino server console window:
12.Within a few minutes, the cluster-related processes initiates and creates the
databases necessary to facilitate cluster replication between these two chat
servers.

13.Once cldbdir.nsf has been created, configure it to only cluster replicate the
following databases: names.nsf, admin4.nsf, vpuserinfo.nsf, stauths.nsf,
stnamechange.nsf, cldbdir.nsf, and clubusy.nsf.
14.From the Notes client menu bar, select File → Database → Open, and open
the Cluster Directory database (cldbdir.nsf) on chat1/ITSO.
15.Disable cluster replication for all databases except for names.nsf, admin4.nsf,
vpuserinfo.nsf, stauths.nsf, stnamechange.nsf, cldbdir.nsf, and clubusy.nsf.
16.Repeat steps 14 through 15 on the second chat server (that is, open the
cldbdir.nsf database on chat2/ITSO and repeat the steps).
Verification checkpoint - test Domino cluster

At this point the Domino cluster is now configured, but should be tested to verify
that it has been configured correctly. An easy test is to make a small change to a
user’s person document on chat1/ITSO and see if the change automatically
replicates to the same person document on chat2/ITSO.
After completing this test and verifying that the Domino cluster is working, we can
proceed with creating the Sametime cluster.
4.3.6 Create a Sametime cluster

A Sametime cluster is a logical grouping of Sametime servers. In short, it allows
a user to physically connect to multiple servers within the Sametime community
without getting kicked out. For example, if a user is logged into chat1, but attends
an instant meeting on chat2, the user would normally get kicked out of Sametime
for having logged into two different servers in the same community. By creating a
Sametime cluster, a user can log into chat1 and attend an instant meeting on
chat2 without getting kicked out.
Create the Sametime cluster

To do this:
1. From the Notes client menu bar, select File → Database → Open and open
the Sametime Configuration database (stconfig.nsf) on chat1/ITSO.
2. Click the All By Form and Date view.

3. From the menu bar, select Create → Cluster Information and fill in the fields
shown in Table 4-29 in the document that appears.
Table 4-29 Cluster Information

Field Value
Cluster Name stchatcluster
This value is used as the users’ Home

Sametime server. It is specified in an
attribute in the LDAP directory.
DNS Name lb.cam.itso.ibm.com
Specify the DNS host name of the load

balancer that will be placed in front of the
stand-alone mux servers.
List of servers in the cluster. cn=chat1/o=itso; cn=chat2/o=itso
4. Press the Esc key and save the document.

5. Update the configuration to allow the stand-alone mux servers to connect to
the Sametime server. Modify the CommunityConnectivity document by filling
in the field shown in Table 4-30.
Table 4-30 CommunityConnectivity

Field Value
Community Trusted IPs 9.33.85.66; 9.33.85.67
Specify the IPs of both mux servers.
6. Press the Esc key and save the document.

7. Close the stconfig.nsf database and the Notes client.
8. Restart the Sametime server for these changes to take effect.

9. Repeat steps 1 through 8 for all chat servers in the cluster. In our case, repeat
the steps for chat2/ITSO.
4.4 Deploy stand-alone mux servers

Why are we deploying stand-alone mux servers? What does a stand-alone mux
server really buy us? It buys us scalability. Each mux server can comfortably
handle 40,000 to 60,000 TCP connections. By deploying a stand-alone mux
server, we are essentially moving the overheard of handling the connections
from the Sametime server to the mux server in order to free up resources on the
Sametime server to more effectively handle its other functions. Mux servers allow
us to scale our environment without necessarily having to increase the number of
Sametime servers.
In this section we discuss the step-by-step deployment of two stand-alone mux

servers for ITSO Corporation’s environment.
Building the Community Infrastructure
1 2 3
Deploy
Deploy Deploy
WebSphere
Clustered Stand-Alone
Edge
Chat servers MUX servers
Load Balancer
– Install Domino – Deploy Mux – Setup the

– Install Sametime servers Load Balancer
– Setup Domino – Sanity checks – Sanity checks
Cluster
– Setup Sametime
cluster
– Sanity checks
Figure 4-59 Deploy stand-alone mux servers

Install stand-alone mux server
To install a stand-alone mux server on Windows:
1. Run the Community mux setup program (setupwin32.exe) located within the
Sametime components CD or download package from Passport Advantage®.
2. Select the language and click OK.
Figure 4-60 Select a language
3. On the welcome screen, click Next.

4. Review and accept the license agreement and click Next.
5. Choose the installation directory (that is, C:\Lotus\SametimeMux) and click
Next.
Figure 4-61 Directory name

6. On the next screen, enter a fully qualified host name for one of the chat
servers (that is, chat1.cam.itso.ibm.com) (Figure 4-62). We recommend not
entering an IP address for administrative purposes.
Figure 4-62 Fully qualified host name for Sametime server

7. On the summary screen, click the Install button.
Figure 4-63 Install summary
8. Once completed, click Finish to complete the installation.
Configure stand-alone mux server

After the mux server has been installed, we need to configure it so that it:
򐂰 Can handle the appropriate load
򐂰 Can handle failover if the primary sametime server is down
To configure:
1. Using your favorite text editor, open up sametime.ini (by default, located at
c:\Lotus\SametimeMux\sametime.ini).
2. Update the following fields:
– VPMX_CAPACITY=80000
This increases the max capacity of the stand-alone mux to 80,000 TCP
connections. While a mux can comfortably handle 40,000 to 60,000
connections, it is important to allow each stand-alone mux to handle
potential influx of connections if a mux server faults.
For example, let us suppose that there are two mux servers, where mux1
has 20,000 connections and mux2 has 30,000 connections. Because of
some hardware-related problem, mux2 goes down. Mux1 needs to be able
to handle the influx of 30,000 connections. This is why the capacity on a

mux is set higher than the normal expected capacity, so that it can handle
the influx of TCP connections from mux servers that may potentially go
down.
– VPS_HOST=chat1.cam.itso.ibm.com, chat2.cam.itso.ibm.com
During the install, we provided the host name of the Sametime server that
the mux will connect to. This VPS_HOST parameter defines the Sametime
server from which the mux server will retrieve the community-specific
information it needs to forward packets. However, we need to provide
failover redundancy in the event the Sametime server that the mux points
to is down. If mux could only connect to one server and that server was
down, it would render the mux useless. This is why we need to allow the
mux server to connect to another server if the primary server is down. By
adding a second server to VPS_HOST, the mux can connect to chat2 if
chat1 is down in order to retrieve community specific information.
Example 4-9 Example

# Sametime.ini Configuration
[Config]
VPMX_CAPACITY=80000
[Connectivity]
VPS_HOST=chat1.cam.itso.ibm.com, chat2.cam.itso.ibm.com
3. Set the startup type for the ST mux service to automatic.

services.msc
b. Right-click ST Mux and select Properties.
c. Change startup type to automatic.
d. Click Apply and then OK.
4. Make sure that the Sametime servers are running.
4.5 Install and configure IBM Edge Load Balancer

components
Note: This section focuses on the step-by-step implementation of installing

and configuring the load balancer. For a conceptual overview of the load
balancer, refer to Appendix D, “Introduction to load balancing - WebSphere
Edge components” on page 819.

In this section we describe how we configured and set up the load balancer in
our test environment. This would be described as a basic load-balancing
scenario.
Attention: For more information about other commonly used scenarios in the
Edge Load Balancer, including a high-availability scenario, NAT scenario, or
how to use sample custom advisors, see Chapter 5 in the IBM Redbooks
publication WebSphere Application Server V6 Scalability and Performance
Handbook, SG24-6392, at:
For more possibilities refer to the WebSphere Application Server

Administration Guide Load Balancer Administration Guide Version 6.0,
GC31-6858, at:
http://www-1.ibm.com/support/docview.wss?uid=pub1gc31685801
Or see other WAS documentation available at:
http://www-306.ibm.com/software/webservers/appserv/was/library/index
.html
4.5.1 Overview of the steps within the basic load-balancing scenario

Installing and configuring the basic load-balancing scenario consists of the
following steps:
1. Configure network to work with the Edge Network Dispatcher Component.
2. Configure NIC on mux servers to accept traffic for imcluster.
3. Configure NIC on load balancer to accept traffic for imcluster.
4. Install Edge Network Dispatcher.
5. Configure Edge Network Dispatcher.
4.5.2 Configure network to work with the Edge Network Dispatcher

Component
To prepare the network:
1. In our environment we have the following network adapters on the three
workstations (Table 4-31 on page 226).

Table 4-31 LB network configuration
Machine functionality Machine name IP address
Stand Alone mux mux1.cam.itso.ibm.com 9.33.85.66
Stand Alone mux mux2.cam.itso.ibm.com 9.33.85.67
Load Balancer (NFA) lb.cam.itso.ibm.com 9.33.85.68
Each of these servers contains only one standard Ethernet network interface
card (NIC).
We then set up another IP address for this LAN segment in the DNS.
Table 4-32 shows the address that everyone will use to access our chat
cluster.
Table 4-32 DNS config for chat cluster address

Machine functionality Machine name IP address
Chat cluster address imcluster.cam.itso.ibm.com 9.33.85.78
In 4.5.3, “Configure NIC on mux servers to accept traffic for imcluster” on

page 226, and 4.5.4, “Configure NIC on load balancer to accept traffic for
imcluster” on page 242, we configure each machine above to accept traffic for
imcluster.cam.itso.ibm.com.
2. The load balancer can ping both mux servers.
3. Both mux servers can ping the load balancer.
4. Content is identical on mux1 and mux2, as they are pointing to the clustered
chat servers chat1 and chat2. (See 4.3.6, “Create a Sametime cluster” on
page 218.)
5. mux1, mux2, chat1, and chat2, as described in earlier sections, are
operational prior to beginning this section.
4.5.3 Configure NIC on mux servers to accept traffic for imcluster

On the mux servers you need to configure the loopback adapter to accept traffic
for your cluster address (imcluster.cam.itso.ibm.com) in our environment. There
are two processes in setting this up:
򐂰 Install loopback adapter.
򐂰 Configure loopback adapter for cluster IP address.

Install loopback adapter
If you are using Windows 2000 server, this procedure may add a new route to
your routing table, so we recommend that you save output of your current routing
table to use later. See Example 4-10, taken from the WebSphere Application
Server V6 Scalability and Performance Handbook
(http://www.redbooks.ibm.com/abstracts/SG246392.html). In this example
10.20.10.100 is the cluster IP address, while 10.20.10.103 is the mux server IP
address. If you are using a Windows 2003 server, the routing table should not be
affected.
Example 4-10 Original routing table

C:\> route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x1000003 ...00 02 55 91 4b 4c ...... AMD PCNET Family Ethernet Adapter
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.20.10.1 10.20.10.103 1
10.20.10.0 255.255.255.0 10.20.10.103 10.20.10.103 1
10.20.10.103 255.255.255.255 127.0.0.1 127.0.0.1 1
9.255.255.255 255.255.255.255 10.20.10.103 10.20.10.103 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 224.0.0.0 10.20.10.103 10.20.10.103 1
255.255.255.255 255.255.255.255 10.20.10.103 10.20.10.103 1
Default Gateway: 10.20.10.1
===========================================================================
Persistent Routes:
None

The following steps were taken in our environment for a Windows 2003 server:
1. Click Start → Settings → Control Panel → Add New Hardward.
2. On the Add Hardware Wizard Screen click Next.
3. Select Yes, I have already connected the hardware, then click Next.
Figure 4-64 Add new hardware

4. Scroll down and select Add a new hardware device (Figure 4-65).
Figure 4-65 Add a new hardware device

5. Select Install the hardware that I manually select from a list (Advanced)
and click Next.
Figure 4-66 Install the hardware that I manually select from a list

6. Scroll down and select Network adapters and click Next (Figure 4-67).
Figure 4-67 Network adapters

7. Under Select Network Adapter select Microsoft for Manufacturer, Microsoft
Loopback Adapter for Network Adapter, and click Next (Figure 4-68).
Figure 4-68 Select loopback adapter

8. Click Next to install the Microsoft Loopback Adapter (Figure 4-69).
Figure 4-69 Install Loopback adapter

9. Click Finish when you have completed installing Microsoft Loopback adapter
(Figure 4-70).
Figure 4-70 Completing the Add Hardware Wizard
Now that the loopback adapter in installed, configure the adapter to accept
requests for the cluster (imcluster.cam.itso.ibm.com) IP address (9.33.85.78).
Configure loopback adapter for cluster IP address

To configure the adapter to accept requests for the cluster
(imcluster.cam.itso.ibm.com) IP address (9.33.85.78) complete the following
steps:
1. Go into Properties of My Network Places.

2. In the Network Connections menu bar click Advanced → Advanced
Settings (Figure 4-71).
Figure 4-71 Advanced Settings
3. Under Connections, select the Loopback Adapter (Local Area Connection

2) and click the down arrow to move the network card to the top connection
(Figure 4-72).
Figure 4-72 Advanced Settings
4. Click OK.

5. Right-click the Microsoft Loopback adapter (Local Area Connection 2) and
chose Properties (Figure 4-73).
Figure 4-73 Configure Loopback adapter

6. In the Local Area Connections 2 Properties box, select Internet Protocol
(TCP/IP) and click Properties (Figure 4-74).
Figure 4-74 Loopback adapter properties

For the next step you need to know the subnet mask for all servers in the
cluster. If you are unsure what this is you can run ipconfig /all on any server in
the cluster. Figure 4-75 is the ipconfig /all command from the load balancer
machine.
Figure 4-75 ipconfig /all

7. Using the default Gateway set the:
– IP address: This should be the IP address cluster address (9.33.58 in our
environment).
– Subnet mask: This should be the subnet mask for all servers in the cluster
(255.255.255.128 in our environment).
– Preferred DNS server: On Windows 2003 this should be 127.0.0.1. On
Windows 2000 this should be left blank.
Figure 4-76 Internet Protocol (TCP/IP) Properties
8. Click OK.
9. Click OK on Local Area Connection Properties.
10.Close the Network Connections window.

If you are using a Windows 2003 server, the following steps should not be
necessary, and you can skip to step 11 on page 242. If you are using
Windows 2000 Server, check the routing table. Compare it to the one you
saved in the beginning of this configuration (see the original routing table in
Example 4-10 on page 227 and the new routing table in Example 4-11).
Remember, for these examples, the mux IP address is 10.20.10.103 and the
cluster IP address is 10.20.10.100. We need to remove references to
10.20.10.100.
Example 4-11 Routing table after adding the loopback adapter

C:\> route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x1000003 ...00 02 55 91 4b 4c ...... AMD PCNET Family Ethernet Adapter
0x3000004 ...02 00 4c 4f 4f 50 ...... MS LoopBack Driver
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.20.10.1 10.20.10.103 1
10.20.10.0 255.255.255.0 10.20.10.100 10.20.10.100 1
10.20.10.0 255.255.255.0 10.20.10.103 10.20.10.103 1
10.20.10.100 255.255.255.255 127.0.0.1 127.0.0.1 1
10.20.10.103 255.255.255.255 127.0.0.1 127.0.0.1 1
10.255.255.255 255.255.255.255 10.20.10.100 10.20.10.100 1
10.255.255.255 255.255.255.255 10.20.10.103 10.20.10.103 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 224.0.0.0 10.20.10.100 10.20.10.100 1
224.0.0.0 224.0.0.0 10.20.10.103 10.20.10.103 1
255.255.255.255 255.255.255.255 10.20.10.103 10.20.10.103 1
Default Gateway: 10.20.10.1
===========================================================================
Persistent Routes:
None
Note that after the loopback adapter was added, the system also added three
extra routes to the routing table. Now there are three sets of routes to the
same destination using two different gateways: first, the cluster IP address
that was added to the loopback (10.20.10.100), and second the Ethernet
adapter IP address (10.20.10.103).
From the three sets of repeated routes, the one that may cause routing
problems is the one that was created for the local network, using the cluster
IP address as the gateway:
10.20.10.0 255.255.255.0 10.20.10.100 10.20.10.100 1

The gateway is incorrect, and you need to remove this route. You can use the
following command in a command prompt window:
C:\> route delete 10.20.10.0 10.20.10.100
This command must also be run after each reboot, because every time the
loopback adapter is activated, the route is added back to the system.
Therefore, we create a batch file, C:\routedel.bat, and add the following lines
to it:
@echo off
route delete 10.20.10.0 10.20.10.100
exit
In order to run this batch file automatically after a reboot, we add it to the
registry. Run the command regedit and locate the key
HKEY_LOCAL_MACHINE → SOFTWARE → Microsoft → Windows →
CurrentVersion → Run. On the menu bar, select Edit → New → String
Value. Rename the new string value name to a name that makes sense to
you, then double-click it so that you can change the value data field. Enter
C:\routedel.bat and click OK.
This batch file will be run after a reboot and it will delete that second route. If
you need to add more aliases to the loopback, add the route delete for each
alias to this same batch file.
Note: Due to a characteristic of the operating system, this batch file added
to the run registry entry will only run after a user logs in.
In order to have this batch file run after a reboot even if no user logs in, you
need to create a Windows service for it. Refer to the operating system
documentation for more information about how to create services.

11.Now for both Windows 2000 and 2003, an ipconfig should show both the mux
server IP address (9.33.85.66 in our environment) and cluster IP address
Figure 4-77 ipconfig
Complete the same steps for any additional mux servers in your environment.
4.5.4 Configure NIC on load balancer to accept traffic for imcluster

On the load balancer server you need to configure the network card to accept
traffic for both your load balancer address (lb.cam.itso.ibm.com, 9.33.85.68 in
our environment) and the cluster address (imcluster.cam.itso.ibm.com,
9.33.85.78 in our environment). There are two processes in setting this up:
򐂰 Set load balancer machine with static IP address.
򐂰 Set NIC to listen for imcluster address traffic.
Set load balancer machine with static IP address

To do this:
1. Go into Properties of My Network Places.

2. Right-click your network connection (Local Area Connection) and chose
Properties (Figure 4-78).
Figure 4-78 Network Connections
3. Select Internet Protocol (TCP/IP) and click Properties (Figure 4-79).
Figure 4-79 Local Area Connection Properties

4. Select Use the following IP address and enter the information for your
environment. If you are unsure of the IP address, subnet mask, or default
gateway, running ipconfig /all from a command prompt will tell you this
information:
– IP address: This should be the IP address of the load balancer machine,
the non forward address (9.33.85.68 in our environment).
– Subnet mask: This should be the subnet mask for your environment
– Default gateway: This should be the default gateway for your environment
– Select use the following DNS server addresses: This should be the DNS
servers for your environment (9.33.85.3 and 9.33.10.20 in our
environment).
Example 4-12 Load balancer ipconfig /all

C:\Documents and Settings\Administrator>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : lb
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : .cam.itso.ibm.com
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : cam.itso.ibm.com

Description . . . . . . . . . . . : Intel(R) PRO/100 VE Desktop
Connection
Physical Address. . . . . . . . . : 00-02-55-BF-AC-D6
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 9.33.85.68
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . : 9.33.85.1
DHCP Server . . . . . . . . . . . : 9.33.85.3
DNS Servers . . . . . . . . . . . : 9.33.85.3
9.33.10.20
9.0.5.1
9.33.10.21
9.12.6.7

Lease Obtained. . . . . . . . . . : Friday, February 09, 2007
12:11:52 PM
Lease Expires . . . . . . . . . . : Saturday, February 10, 2007
6:11:52AM
5. Click OK.
6. Close the Local Area Connection Properties window.

Set NIC to listen for imcluster address traffic
To do this:
1. Right-click Local Area Connection and chose Properties (Figure 4-81).
Figure 4-81 Local Area Connection - Properties
2. Select Internet Protocol (TCP/IP) and click Properties (Figure 4-82).

3. In the Internet Protocol (TCP/IP) Properties window click Advanced.

4. Under IP Settings - IP address click Add (Figure 4-84).
Figure 4-84 Advanced TCP/IP Settings

5. Set the parameters as follows (Figure 4-85):
– IP address: This should be the IP address of the cluster address
(imcluster.cam.itso.ibm.com, 9.33.85.78 in our environment).
– Subnet mask: This should be the subnet mask for your environment
Figure 4-85 TCP/IP Address

6. In Advanced TCP/IP Settings, you should now see both the load balancer
NFA address (9.33.85.68) and the cluster IP address (9.33.85.78). Click OK
(Figure 4-86).
Figure 4-86 Advanced TCP/IP Settings

7. In the Internet Protocol (TCP/IP) Properties window, click OK (Figure 4-87).

8. In Local Area Connection Properties, click Close (Figure 4-88).
At this point the ipconfig command should show the server listening on both the
load balancer non forwarding IP address (9.33.85.68 in our environment), as well
as the cluster IP address (9.33.85.78 in our environment).
Example 4-13 Load balancer machine ipconfig

C:\Documents and Settings\Administrator>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :

IP Address. . . . . . . . . . . . : 9.33.85.78
Subnet Mask . . . . . . . . . . . : 255.255.255.128
IP Address. . . . . . . . . . . . : 9.33.85.68
Subnet Mask . . . . . . . . . . . : 255.255.255.128

Default Gateway . . . . . . . . . : 9.33.85.1
You are now ready to install and configure the WebSphere Edge Network
Dispatcher Component.
4.5.5 Install Edge Network Dispatcher

You can install the WebSphere Edge Components product using either the
common installation wizard or the operating system tools and commands.
We describe the installation on a Windows 2003 server using the wizard. Before
starting the installation, refer to Load Balancer Administration Guide Version 6.0,
GC31-6858, for the prerequisites and supported operating systems:

The Edge components installation media provides an installation wizard for all
platforms so the installation is similar for all supported operating systems.
Important: Before starting with the installation, you should have Java Runtime
(V1.4.2 or later) installed on your system.
1. Start LaunchPad by running launchpad.bat.

The LaunchPad window opens, as shown in Figure 4-89.
Figure 4-89 LaunchPad window

2. Click WebSphere Application Server Edge Components Installation
(Figure 4-90).
Figure 4-90 WebSphere Application Server Edge Components installation
3. Click Launch the installation wizard for WebSphere Application Server -

Edge Components.
4. Click Next on the Welcome screen and click Yes to accept the product
license.

5. In the Component Selection window, you can select which components you
want to install. Select the Load Balancer check box, and we changed the
install folder to C:\ibm\edge\lb, as shown in Figure 4-91.
Figure 4-91 Component Selection window

6. (Optional) Click Change Subcomponent. The Subcomponent Selection
window opens. Select the subcomponents you want to install. The
administration and license subcomponents are mandatory. By default, all
subcomponents are selected and we installed all subcomponents in our test
environment, as shown in Figure 4-92. Click OK to return to the Component
Selection window.
Figure 4-92 Subcomponent Selection window
7. Click Next to continue the installation.

8. Verify that the selected options are listed in the Installation Selection
Summary, and click Finish to start the installation, as shown in Figure 4-93.
Figure 4-93 Installation confirmation window
9. At the end of the installation, you have the option to reboot the server. Make
sure you do so before using the product.

4.5.6 Configure Edge Network Dispatcher
This scenario represents the most simple example of load balancing, where load
balancer is configured on one system only and load balances the traffic between
two mux servers, as shown in Figure 4-94.
Instant
Messaging
User
Configuring this
load balancer
and ports
Load
Balancer
1533 1533 1533

8082 8082 8082

MUX1 MUX2 MUX3
1516 1516
1352
1516
Server Server
ST
CLUSTER
Load
Balancer

1 2
Figure 4-94 America’s chat cluster scenario

This scenario shows the Dispatcher component using the MAC forwarding
method. Configuring the load balancer is a four-step process:
1. Set up the cluster.
2. Configure the Manager component.
3. Configure the sticky bits.
4. Save the configuration.
Set up the cluster

The configuration can be done using the load balancer graphical user interface
(lbadmin) or using the command line interface (dscontrol). We first explain how
to set up using the GUI, and later we show the commands (which give you the
same result).
In order to send commands through the GUI or through the command-line

interface to load balancer, you need to start the component element that receives
those commands and executes them.
In this scenario, we only use the Dispatcher component.

1. Start the Dispatcher server in order to start configuring it. To do so, start the
windows service IBM Dispatcher or run the following command:
dsserver

2. Open the load balancer GUI by clicking Start → Programs → IBM
WebSphere → Edge Components → Load Balancer → Load Balancer or
by running the following command:
lbadmin
The load balancer GUI is a Java client that can also be installed on a client
machine, so the administrator can work remotely.
Figure 4-95 Load Balancer window

3. When the load balancer administration tool comes up, right-click Dispatcher
in the left pane and select Connect to Host, as shown in Figure 4-96.
Figure 4-96 Connect to Host
4. A pop-up window is displayed, prompting you for the load balancer server that
you want to connect to. Select the host name of the load balancer server, as
Figure 4-97 Selecting the load balancer server
After connecting to the load balancer server, a new entry is added to the GUI
window in the left pane, containing the host name of the selected server. All
the configuration we perform from now on is added to this element in a tree
structure.

5. Now we need to start the Executor component, which is the component that
actually distributes the load to the servers. Right-click
Host:lb.cam.itso.ibm.com and select Start Executor, as shown in
Figure 4-98.
Figure 4-98 Starting Executor

If Executor is started successfully, a new item named Executor is added to
the left pane. In our scenario, the load balancer IP address is 9.33.85.68, so
this IP address is shown with the Executor, as seen in Figure 4-99.
Figure 4-99 Executor started
Tip: For every action you perform, you can see a message in the bottom
pane of the GUI window that confirms whether the action was performed
successfully.
6. The next thing we need to do is to add our cluster. In our scenario, we have a
cluster called imcluster.itso.ibm.com (9.33.85.78), and this cluster contains
two mux servers, mux1 (9.33.85.66) and mux2 (9.33.85.67).

Right-click Executor: 9.33.85.78 and select Add Cluster, as shown in
Figure 4-100.
Figure 4-100 Adding a cluster
7. A new window is displayed, prompting for the necessary information to add

the new cluster. Type the name of the cluster in the Cluster field (we
recommend using the host name). Then type the cluster IP address or host
name in the Cluster address field, and make sure that the load balancer’s IP
address is selected in the Primary host for the cluster field, as shown in
Figure 4-101.
Optionally, check Configure this cluster?, as shown in Figure 4-101. This
option is used to create an IP alias in the operating system for the cluster IP
address. You can also uncheck this option and add the IP alias manually
using operating system tools or commands.
Figure 4-101 Filling in the information to add a cluster

8. If you checked the Configure this cluster? check box, another window is
displayed. Enter the interface identification in the Interface name field and the
network mask in the Netmask field, as shown in Figure 4-102.
Figure 4-102 Configuring the interface
Although these fields are optional, IBM support recommends that you provide
them. Otherwise, load balancer uses the default values, which may not be
correct for your system.
Note: If you have only one Ethernet card in your machine, the interface
name will be en0. Likewise, if you have only one Token Ring card, the
interface name will be tr0. If you have multiple cards of either type, you will
need to determine the mapping of the cards. Use the following steps: Click
Start → Run and run regedit. Expand HKEY_LOCAL_MACHINE →
Software → Microsoft → Windows NT® → Current Version →
NetworkCards.
The network interface adapters are listed under Network Cards. Click each
one to determine the interface type. The type of interface is listed in the
Description column. The names assigned by the executor configure
command map to the interface types. For example, the first Ethernet
interface in the list is assigned to en0, the second to en1, and so on. The
first Token Ring interface is assigned to tr0, the second to tr1, and so on.

A new item that identifies your cluster is added to the left pane of the GUI, as
seen in Figure 4-103.
Figure 4-103 Cluster added

9. Add each port that will be load balanced by the Dispatcher. Right-click
Cluster: cluster.itso.ibm.com and select Add Port (Figure 4-104).
Figure 4-104 Adding a port
The ports that we are adding refer to the port that the clients will access. In
our scenario, we use port 8082 for STLinks clients (WebSphere Portal, Lotus
QuickPlace, and Domino Web Access) and 1533 for Connect clients
(Sametime Connect client, Lotus Notes client, and Java Connect client).
STMobile can use either port 1533 or 8082.
Fill in the number of the port in the Port number field and select MAC Based
Forwarding in the Forwarding method field, as shown in Figure 4-105.
Figure 4-105 Port information

A new item representing port 1533 is added to the left pane of the GUI.
Repeat this step for port 8082. The updated ports appear in the left pane, as
Figure 4-106 Ports 1533 and 8082 added

10.Add the servers that will receive the load for port 80 of cluster
cluster.itso.ibm.com. Right-click Port:1533 and select Add Server, as shown
in Figure 4-107.
Figure 4-107 Adding a server
The next window prompts you for the information of the first server. Fill in the
host name of your mux server in the Server field and enter its IP address in
the Server address field, as shown in Figure 4-108.
The first server we add in our scenario is mux1.cam.itso.ibm.com, and its IP
address is 9.33.85.166.
Figure 4-108 Adding the first balanced server
Note that the Network router address check box is disabled because we
selected MAC Based Forwarding and this forwarding method does not allow
load balancing to remote servers. Click OK. The server should then appear
under port 1533 in the left pane of the GUI.

Repeat step 10 on page 270 for all servers in the cluster, and then for port
8082 as well.
We also add our second server. The host name of this server is
mux2.cam.itso.ibm.com and the IP address is 9.33.85.67.
All servers should eventually appear under each port in the left pane of the
GUI, as seen in Figure 4-109.
Figure 4-109 Balanced servers added to each port in cluster
The load balancing part of the configuration is done. All the information that
Dispatcher needs to provide load balancing for our cluster is now configured. But
we also need the Manager component because we want to work with dynamic
weight values and failure detection.

Configure the Manager component
To do this:
1. Start the Manager component. Right-click Host: lb.cam.itso.ibm.com and
select Start Manager, as shown in Figure 4-110.
Figure 4-110 Starting Manager
2. A window is displayed in which you can select the name of the Manager log
file and the metric port, as shown in Figure 4-111. We chose the default
options. Click OK.
Figure 4-111 Manager options
3. The Manager needs advisors in order to generate a weight value based on

the response time from each server in the cluster. The advisor is also needed
in order to detect a failure in the service of any balanced server (in our case, a
failure in the mux server service).
Due to the importance of the advisor, when you start Manager, the load
balancer GUI automatically displays a pop-up window prompting you to start
an advisor.

The load balancer product offers advisors for specific protocols and services,
and a generic advisor called Connect.
In our scenario, we are load balancing a mux server using the Sametime
protocols. Therefore, we use Connect in the Advisor name field and port 1533
in the Port number field, as seen in Figure 4-112.
Figure 4-112 Starting the advisor for port 1533
You can also choose a specific cluster with which to associate this advisor.
By leaving the optional Cluster to advise on field blank, this advisor is
automatically associated with all clusters that are load balancing port 1533.
If you want to specify a log file name for this advisor, type in the desired name
in the Log filename field. Click OK to close.

The advisor for port 1533 should appear under Manager in the left-hand
pane, as seen in Figure 4-113.
Figure 4-113 Advisor: Connect 1533

4. Next we need to create an advisor for port 8082. Right-click Manager and
click Start Advisor, as seen in Figure 4-114.
Figure 4-114 Start Advisor
Again, we enter Connect in the Advisor name field and port 8082 in the Port
number field, as seen in Figure 4-115.
Figure 4-115 Starting the advisor for port 8082

All ports should now appear under the Manager section in the left pane of the
GUI, as seen in Figure 4-109 on page 271.
Figure 4-116 All advisors started
We have configured the cluster and advisors, and now we need enable sticky
affinity across both Sametime ports in the cluster.
Configure the sticky bits

First configure the sticky time for ports 1533 and 8082 in your cluster
(imcluster.cam.itso.ibm.com in our environment).
1. To do this run the following command from the command prompt in the load
balancer install directory (C:\ibm\edge\lb in our environment):
dscontrol port set imcluster.cam.itso.ibm.com:1533 stickytime 600
You should receive the following message in the console:
Port field(s) successfully set.

Note: The stickytime is the number of seconds.
2. Next run the same command for port 8082:

3. Finally, run the cross port parameter so all traffic over 1533 and 8082 will be
routed to the same mux server for any given user:
dscontrol port set imcluster.cam.itso.ibm.com:1533 crossport 8082
Again, you should receive the following message in the console:
Port field(s) successfully set.
We have completed setting up the environment. Now we simply need to save the
configuration.
Save the configuration

We will use the load balancer GUI to save the configuration we just created.
1. Right-click Host: lb and select Save Configuration File As (Figure 4-117).
Figure 4-117 Save file
2. A pop-up window is displayed. In the Filename field, you can either select an
existing configuration file (which will be overwritten) or you can enter a new
file name.
The file name default.cfg is the default name for load balancer. This means
that when you start the Dispatcher server (dsserver), it will look for the file
default.cfg and, if it exists, it will load it. default.cfg is stored in
<LB_install_path>/servers/configurations/dispatcher
(C:\IBM\edge\lb\servers\configurations\dispatcher in our environment).

3. Click Yes to overwrite the existing file.
The resulting configuration file is shown in Example 4-14. Note that each
individual command has to be one line in the configuration file. However,
because of size limitations, some lines might be printed on two lines in our
examples.
Example 4-14 Configuration file for the basic scenario

dscontrol set loglevel 1
dscontrol executor start
dscontrol cluster add imcluster.cam.itso.ibm.com address 9.33.85.78

primaryhost 9.33.85.68
dscontrol cluster set imcluster.cam.itso.ibm.com proportions 49 50 1 0
dscontrol executor configure 9.33.85.78 en0 255.255.255.128
dscontrol port add imcluster.cam.itso.ibm.com:8082 reset no

dscontrol server add

imcluster.cam.itso.ibm.com:8082:mux2.cam.itso.ibm.com address
9.33.85.67
dscontrol server set
imcluster.cam.itso.ibm.com:8082:mux2.cam.itso.ibm.com weight 14

9.33.85.66
dscontrol port add imcluster.cam.itso.ibm.com:1533 reset no


9.33.85.67

9.33.85.66

dscontrol port set imcluster.cam.itso.ibm.com:1533 crossport 8082
dscontrol manager start manager.log 10004
dscontrol advisor start Connect 8082 Connect_8082.log
dscontrol advisor start Connect 1533 Connect_1533.log
If you do not want to use the load balancer GUI to configure the scenario
described here, you can copy the commands shown in Example 4-14 on
page 278 into your own default.cfg file, and when you run dsserver, it will
automatically be loaded.
You can also type those commands into the operating system prompt, one by
one.
Note that in either case, you need to change the host names and IP addresses
shown here to the appropriate ones for your environment.

5
Chapter 5. Deployment phase I -

implementing Meeting
Services
This chapter builds directly upon Chapter 4, “Deployment phase 1 - implementing
Community Services” on page 129, and discusses how to install and configure
the Sametime Meeting Services.

5.1 What you will be building in this chapter
In Chapter 4, “Deployment phase 1 - implementing Community Services” on
page 129, we focused on building the community chat services within the
scenario infrastructure.

Our goal throughout this chapter is to walk you through the step-by-step process
of building ITSO Corporation’s planned meeting environment, as illustrated in
Figure 5-1.
ITSO's Sametime Meeting Services Infrastructure
Instant
Messaging
User
Load Load
Balancer Balancer
(Primary) (Backup)

MUX1 MUX2 MUX3

Server Server
ST
CLUSTER
Load Load
Balancer Balancer
(Primary) (Backup)

1 2
Invited Meeting Server

Model

Meeting Meeting
Server1 Server2
Figure 5-1 ITSO Corporation’s Sametime community infrastructure
Chapter 5. Deployment phase I - implementing Meeting Services 283

We follow the general steps outlined below to create ITSO Corporation’s Meeting
Services environment:
򐂰 Domino setup
򐂰 Sametime setup
5.2 Deploy ITSO Corporation’s meeting infrastructure

This section provides you with step-by-step details for deploying the meeting
services within the infrastructure.
5.2.1 Domino setup

In this section we discuss Domino setup.
Register meeting server

To do this:
the first server that was setup (in our case (chat1.cam.itso.ibm.com)), and
click OK.

4. On the right-hand side, select Tools → Registration → Server (Figure 5-2).

7. Click OK to continue (Figure 5-3).
Figure 5-3 Choose a Certifier
8. Enter the password for the certifier ID file and click OK (Figure 5-4).

window (Figure 5-5). Click OK to continue.
(chat1/ITSO) and certifier (/ITSO) are correct (Figure 5-6). Click Continue to
proceed.

11.On the Register New Server(s) dialog window, enter the fields shown in
Table 5-1.

Field Value
Server name meeting1
Server title (optional) meeting server
Location for storing server ID Uncheck In Domino directory.

Check In file.
12.Click Set ID File and browse to the location where the ID file should be stored
(that is, C:\Lotus\Domino\data\ids\servers\meeting1.id).

13.Click the green check mark button to add the server to the registration queue
(Figure 5-7).
Figure 5-7 Register New Server(s) - Add to registration queue

registration (Figure 5-8).
Figure 5-8 Register New Server(s) - Register
You have successfully registered the Sametime meeting server. Proceed to the
next section.
Pre-Domino install checklist

and working.
documentation:

software.
more details:
Install Domino
installation CD.
Next.



6. On the Choose the setup type that best suits your needs screen, select
Enterprise Server and click Next (Figure 5-11).

7. On the following screen you will see a summary of your selections
(Figure 5-12). After a careful review, click Next to begin the installation.

8. Once completed, click Finish to complete the installation and exit the
installer.
Configure Domino
To do this:

4. On the First or additional server screen, select Set up an additional server
and click Next (Figure 5-15).

location of the server ID file and click Next (Figure 5-16).
Note: In previous steps we stored chat2’s server ID on chat1’s local file

system and not in the Domino directory. For this step within the setup
program, chat2’s server ID needs to be made accessible. We could map a
drive to chat1 or simply copy the file from chat1 to chat2. For this step, we
will copy chat2’s server ID from chat1’s local file system onto the Desktop
of chat2.
6. On the Provide the registered name of this additional Domino server screen,
click Next.

the following:

accessed via the LDAP protocol. However, running Sametime on a Domino

8. Click Customize and uncheck the following Domino server tasks: DOLS
Domino Off Line ServicesRooms and Resources Manager.
򐂰 Mail Router
򐂰 Agent Manager
򐂰 Calender Connector
򐂰 Schedule Manager
򐂰 HTTP Server
򐂰 Rooms and Resources Manager

9. Click OK and then Next to continue (Figure 5-17).
Figure 5-17 What Internet services should this Domino server provide?

following:

12.On the Provide the system databases for this Domino server, enter the fields
shown in Table 5-2 and click Next.

Field Value
Use a proxy server to connect to the other Leave Unchecked

Domino server

Field Value
Use a dialup connection Leave Unchecked
Get system databases from CD or other Leave Unchecked

media
access to all databases and templates” and then click Next.
confirm the options you have selected, and then click Setup to initiate the

that should be taken to ensure a successful installation of Sametime.
time to initialize properly. (10 minutes is generally longer than actually
needed, but to be on the safe side, we recommend that the Domino server
run for a full 10 minutes during this step.)
following:
services.msc
2. Issue the following commands on chat2’s Domino server console to perform
an immediate synchronization between the two chat servers:
3. To ensure that these system databases stay in synch, create a connection
document so that these databases replicate on schedule.

Administrator Help file:
Important: The above steps are mandatory prior to installing Sametime. If the
Domino server is not properly initialized the Sametime installation could result
in a failure.
Verification Checkpoint - Domino server setup

At this point, we recommend that you perform sanity checks to verify that your
Domino server setup was successful and its current configuration will not pose
any issues for the anticipated Sametime server setup. To validate the Domino
server setup, we recommend the following:
1. Verify local network configuration.
cmd
name):
ping meeting1.cam.itso.ibm.com
ipconfig

server (that is, http://meeting1.cam.itso.ibm.com). You should expect to see
the default Domino home page, as in Figure 5-20.

Database → Open. Type the fully qualified host name into the Server field
(that is, meeting1.cam.itso.ibm.com) and click Open. If a list of databases
populate the Database list box, then you have successfully connected to the

5.2.2 Sametime setup
In this section we discuss Sametime setup.
Pre-Sametime installation steps

Do the following:
to manual.
Pre-Sametime install checklist

and working.

the Domino server name, you can find it in the Server document. Verify that
the Domino server has a fully qualified host name, for example,
meeting1.cam.itso.ibm.com.

following command:
directories.
directory) that you are going to use. We use an LDAP directory for ITSO Corp.
pubnames.ntf.
initialized.
can be found at:
actions that you may have from installing other applications.
Install Sametime


Field Value

does not follow LDAP referrals. The Global Catalog stores a condensed
8. Uncheck Enable HTTP tunneling and click Next. For more information about
HTTP tunneling see 7.6, “HTTP tunneling” on page 609.
10.Once completed, click Finish to exit the installation wizard.

11.Reboot the operating system to complete the installation.

following:
1. Ascertain that all Sametime services were registered successfully.
services.msc
b. In the Windows services panel, verify that all of the following exist:
• Sametime server
• ST Buddylist
• ST Capabilities
• ST Chat Logging
• ST Community
• ST Conference
• ST Directory
• ST Links
• ST Logger
• ST Mux
• ST OnlineDir
• ST Places
• ST Policy
• ST Polling
• ST Privacy
• ST Reflector
• ST Resolve
• ST Security
• ST User Storage
• ST Users
all of the settings below exist and are set accordingly respective to your local
environment (Example 5-1 on page 309).

[Config]
VP_PRIV_SYM=1
VPMX_CAPACITY=20000
VPS_NAME=CN=meeting1/O=ITSO
[STLinks]
[Policy]
Box
ultAdapter
apBlackBox
[Debug]
[STReflector]
[STCapabilities]

Note: After starting Sametime for the first time, additional parameters are
added to sametime.ini under the [Config] section. For your reference, they
are:
[Config]
SametimeCluster=CN=meeting1/O=ITSO
ConfigurationHost=meeting1.cam.itso.ibm.com
Locale=en
3. Verify that all of the Sametime servlets initialize successfully.


ServerTasks=Update,Replica,Router,AMgr,AdminP,CalConn,Sched,HTTP,RnRMgr

Windows services panel, and do the following:

services.msc
2. Right-click Lotus Domino Server (LotusDominodata) and
select Start.

i. Verify that each one of the Sametime servlets initialize successfully. As
console. See Example 5-3.
Example 5-3 Domino bootstrap servlet successful initialization example

02/12/2007 03:52:09 PM HTTP JVM:
򐂰 MMAPI Servlet
򐂰 Policy Servlet
ii. Verify that the Domino HTTP server starts successfully.

Launch an Internet browser on the server machine and point it to the
Domino server (that is, http://meeting1.cam.itso.ibm.com). You should
expect to see the default Domino home page.
Configure Sametime
To do this:
1. Launch a Lotus Notes client and log in using the Sametime administrator’s ID.

directory (names.nsf) (Figure 5-22).


5. Check the following fields (Table 5-4) to make sure that they have the
appropriate values.
Table 5-4 Sametime server document - basics

Basics
Field Value
Fully Qualified Internet host name (FQHN) meeting1.cam.itso.ibm.com



disabled.

Community.

database is created, and, by default, is


Basics
Field Value
Security

Notes Companion Products
server.

group.

higher security
Ports/Notes Network Ports

Port TCPIP
Protocol TCP

process.

Domino messaging. We recommend that
this value matches all Sametime servers in
the same community.
Net Address meeting1.cam.itso.ibm.com

on the Basics tab.
Enabled Enabled

Basics
Field Value
Ports/Internet Ports

listens on all IPs for this port. Make sure
Name and password.
Anonymous.
SSL port number 443
Internet Protocols/Domino Web Engine
Class path domino\servlet

Configuration.
8. Double-click the Web SSO Configuration for LtpaToken document to open
it.

9. Update the Domino Server Names field to include the meeting server
(chat2/ITSO) (Figure 5-23).
Figure 5-23 Web SSO configuration for LtpaToken
11.You will be prompted with a Warning dialog with the following message
(Figure 5-24):
This Web SSO Configuration has already been initialized. Creating
new keys will overwrite existing SSO keys. Continue?
Figure 5-24 Creating new Domino Web SSO keys

12.You will then be prompted with a message:
Successfully created Domino SSO key.
Click OK to continue (Figure 5-25).
13.Click Save & Close to save the LtpaToken Web SSO document.
that will be used to administer the server:
Table 5-5 for examples of how to enter the DN into the Members field.

distinguished
name (DN)
1 cn=administrator,c cn=administrator/c Active Directory

n=users,dc=ibm,dc n=users/dc=ibm/dc
=com =com

m m

Administrator,ou=A Administrator/Austi Directory
ustin,O=IBM n/IBM

Notes: Make sure that you change the commas to slashes when
entering the distinguished name into the members field.


d. Click Save & Close.

following settings (Table 5-6).

Field Value
Access Manager
Roles Check All

Figure 5-26 Access Control List to: ITSO’s Directory

Sametime Configuration database (stconfig.nsf) (Figure 5-27).
following settings (see Table 5-7).

Field Value
Access Manager
Roles Check All

15.Click OK to close the ACL for stconfig.nsf.

Web server:

c. Fill in the fields as shown in Table 5-8.

Basics
Field Value
Domain type LDAP
Domain name LDAP
Company name LDAP
Search order 1
Make this domain available to Notes Clients & Internet Authentication/

Authorization
Enabled Yes
Attribute to be used as name in an SSO (leave blank)

Naming Contexts (Rules)
Use only the first rule.
LDAP
Username cn=root

Web authentication.
Password password

above.

Basics
Field Value

to shut down cleanly before the Domino server attempts to start backup.
restart the Sametime server, we recommend splitting out the process: 1)
quit the server first, and then 2) start it back up.
19.When the Domino server is back up, update Sametime’s LDAP settings via
the Sametime administration interface:
Table 5-9.

Field Value

server
Position of this server in the search order 1
Port 389
Administrator distinguished name cn=root
Administrator password password
Use SSL to authenticate and encrypt the (Leave blank for now.)
and the LDAP server

Field Value
LDAP SSL Port 636

Table 5-10.

Field Value



cn or mail)







similar group names


h. Expand LDAP Directory → Authentication and fill in the fields shown in
Table 5-11.
Table 5-11 LDAP Directory - Authentication

Field Value

authenticate.)
i. Click Update if you made any changes.

j. Expand LDAP Directory → Searching and fill in the fields shown in
Table 5-12.

Field Value

%s*)))

n=%s*))
Base Membership
k. Click Update.
l. Expand LDAP Directory → Group Contents and fill in the fields shown in
Table 5-13.

Field Value

m. Click Update.

We have successfully completed configuring Sametime. We now can proceed to

validate this configuration.
Verification Checkpoint - Sametime server configuration

To configure:
2. Click Start → Run, and enter:
services.msc
Tip: This step provides the administrator with the ability to monitor
Sametime Meeting server’s startup process. From a troubleshooting
This console window appears but remains blank. Do not close this
window because if you do, it will terminate the process improperly. This
Sametime Gateway.
notes.ini configuration file (Example 5-4).

,STAddin

services panel.

services.msc
Start.
then the Sametime Meeting Services most likely failed to load. For more
9. Verify that all of the Sametime-related services are running:


Important: If you configured Sametime to use an LDAP directory, as

we have done, you should always make sure to log in using an LDAP
account when administering the Sametime server. If you do not, you will
not be able to manage and assign Sametime policies.
Sametime services and their respective status. Verify that all of the
Sametime services are indeed running.
Notes: The Telephony Services (sttelephonyservice.exe) will not be

running by default. This is okay and should not be a point of concern.
It takes two minutes before Sametime’s community services start to load.

The delay in their startup should not be a point of concern either.

6
Chapter 6. Deployment phase II -

integration with other
products
Now that you have a robust Sametime infrastructure in place, how can you
extend it to integrate the capabilities of Sametime with other products?
This chapter describes how to Leverage Sametime presence awareness, chat,

and meeting capabilities from your existing business applications.
Specifically, this chapter covers the following topics:

򐂰 Extend the Connect client using the business card: “Business card integration
in Connect client” on page 334.
򐂰 Extend the Notes Client: “Notes Client integration with Sametime” on
page 353.
򐂰 Extend Domino Web Access: “Domino Web Access integration with
Sametime” on page 365:
– “Install Domino and register the DWA users” on page 366
– “Configure DWA for awareness and chat” on page 383

򐂰 Extend QuickPlace: “QuickPlace integration with Sametime” on page 421:
– “Install QuickPlace and configure Security” on page 421
– “Configure QuickPlace for awareness, chat, and meetings” on page 447
򐂰 Extend WebSphere Portal: “WebSphere Portal Integration with Sametime” on
page 474:
– “Install WebSphere Portal and configure Security” on page 474
– “Configure WebSphere Portal for awareness, chat, and meetings” on
page 485
The chapter is written as though you have not completed each main topic above
it. (Connect client, Notes Client, Domino Web Access, QuickPlace, WebSphere
Portal, and Microsoft products). There you can pick can chose what sections
from this chapter you want to use, and only complete those sections. For
example, if you only want to add Sametime capabilities to the Connect client,
Domino Web Access, and WebSphere Portal, you can simply complete those
sections.
There is one exception to this. No matter what business applications you chose
to integrate, everyone should read 6.2, “Case fixes” on page 331, to make
Sametime case insensitive for easier integration with the rest of the products.

6.1 Navigating this chapter
Due to the size of this chapter, we wanted to help the reader understand how to
best navigate to the section he needs. As mentioned above, this chapter is
written where each main topic (Connect client, Notes Client, Domino Web
Access, QuickPlace, WebSphere Portal and Microsoft products) does not
assume that you have completed the sections above it. Accordingly, the main
sections can be found on the following pages:
򐂰 “Case fixes” on page 331
򐂰 “Business card integration in Connect client” on page 334
򐂰 “Notes Client integration with Sametime” on page 353
򐂰 “Domino Web Access integration with Sametime” on page 365
򐂰 “QuickPlace integration with Sametime” on page 421
򐂰 “WebSphere Portal Integration with Sametime” on page 474
Important: everyone should read 7.1, “Case Fixes” on page 297, to make
Sametime case insensitive for easier integration with the rest of the products.
6.2 Case fixes

Internally within Sametime, a user is know by her distinguished name as returned
from LDAP. For example, see the following LDIF file from our test environment
(Example 6-1).
Example 6-1 Charles Price ldif

uid=cprice,cn=users,dc=itso,dc=com
objectclass=inetOrgPerson
objectclass=organizationalPerson
objectclass=person
objectclass=top
objectclass=ePerson
objectclass=ibm-appuuidaux
givenname=Charles
sn=Price
cn=Charles Price
uid=cprice
userpassword=password
stserver=stchatcluster
mail=Charles.Price@itso.com
Chapter 6. Deployment phase II - integration with other products 331

uid=cprice,cn=users,dc=itso,dc=com is the distinguished name of this user, and
is how Sametime saves the user internally with her current status (active, away,
do not disturb, or not online). When other products integrate with Sametime,
many times they will send the user’s distinguished name to Sametime requesting
the status. By default Sametime does a case-sensitive compare on that name,
meaning that if another product sends UID=cprice,CN=users,DC=itso,DC=com,
the case-sensitive compare will not match because the name is not entirely
lowercase as it is in ldap (uid=cprice,cn=users,dc=itso,dc=com). Therefore,
when integrating other products with Sametime you should configure Sametime
to use case-insensitive name comparisons, where
UID=cprice,CN=users,DC=itso,DC=com and
uid=cprice,cn=users,dc=itso,dc=com will be treated as the same user.
To configure Sametime to do case-insensitive compares you need to complete

the following steps.
Update sametime.ini
To do this:
1. Open Sametime.ini from all chat servers in a text editor (located in
C:\Lotus\Domino\ in our test environment).
2. In the [Config] section add the following flag:
AWARENESS_CASE_SENSITIVE=0
3. In the [STLINKS] section append -DAWARENESS_CASE_SENSITIVE=0 to
the STLINKS_VM_ARGS as follows:
-DAWARENESS_CASE_SENSITIVE=0
Note: This should appear on one line in your sametime.ini.
The sametime.ini from our test environment after making these changes is
shown in Example 6-2
Example 6-2 sametime.ini

[Config]
VP_PRIV_SYM=1
VPMX_CAPACITY=20000

ConfigurationChangeListener.classname.1=com.lotus.sametime.configuratio
n.EventPublisherConfigurationChangeListener
ConfigurationChangeNotifier.classname.1=com.lotus.sametime.configuratio
n.EventListenerConfigurationChangeNotifier
Locale=en
AWARENESS_CASE_SENSITIVE=0
[STLinks]
-DAWARENESS_CASE_SENSITIVE=0
[Policy]
Box
ultAdapter
apBlackBox
Update stlinks.js
To do this:
1. Open stlinks.js in all chat servers in a text editor (located in
C:\Lotus\Domino\data\domino\html\sametime\stlinks in our test environment).
2. In the variable section set the variable STlinksCaseSensitive to false:
var STlinksCaseSensitive=false;

Part of the variable section from our test environment is shown in Example 6-3.
Example 6-3 stlinks.js

var
STLANGS="en,zh,sv,pt,no,nl,ko,ja,it,fr,fi,es,de,da,zh_TW,pl,ru,pt_BR,cs
,el,hu,tr,ar,he,iw";
var STDEF_LANG="en";
var ll_loggedIn=false;
var STlinksCaseSensitive=false;
//flag that indicates if the Web page need to pass the reverse proxy
for using the sametime
//server - do not change this variable.
var isRProxy=false;
Restart the chat servers for the changes to take effect.
6.3 Business card integration in Connect client

The business card is a new and popular feature of Sametime 7.5. This section
describes how the feature works and covers various scenarios for how to deploy
and configure this feature.
6.3.1 What is the business card

The business card is a new feature of Sametime 7.5. Simply stated, the
Sametime business card is exactly what you think it is: a business card. It
provides a quick and handy summary of details of a specific individual. In the
world of ever-increasing collaboration, this is a key feature to have at your side.
With a quick glance, you could know everything you would ever want to know
about a person: where he is located, what his phone/fax number is, what he
looks like, and much more. Overall, it strengthens the communication and
collaboration between users and helps increase productivity.
Figure 6-1 Example business card

6.3.2 How the business card feature works
In this section we provide a high-level overview of how the business card feature
works within the Sametime Connect client.
1. From within a Connect client, user A requests to view user B’s business card
(Figure 6-2).
Figure 6-2 View business card
2. To view user B’s business card information, user A’s Connect client sends an
HTTP request to the UserInfo servlet on user A’s home Sametime server:
http://[hostname]/servlet/UserInfoServlet?paramX=value...
3. The UserInfo servlet parses the request and instantiates a UserInfo black box
(BB) to search for the requested user’s details within the available storage
repositories. The UserInfo BB is essentially a search engine designed to find
users within the available storage repositories.
4. The UserInfo BB search results are provided back to the UserInfo servlet,
which then responds back to the requesting client in an XML format.

5. The requesting client, user A’s Connect client, then parses the response and
displays user B’s information in the business card.
Figure 6-3 Business card request/response flow diagram

6.3.3 Storage respositories
Key terms: Some key terms are:

򐂰 Sametime directory
The directory that Sametime is configured to use (either a Domino
directory or an LDAP directory).
򐂰 Storage repository
A container that stores user-related information. Types of containers
include Domino directory (a Notes database based off the Domino
directory template - pubnames.ntf), LDAP directory, or custom Notes
database.
򐂰 Primary storage repository
This always refers to the Sametime directory.
򐂰 Secondary Storage Repository
A storage repository that is not the Sametime directory.
Business cards display information about users, but where exactly does this
information come from? The information is retrieved from storage repositories.
For most typical environments, all business card-related information is stored in

the Sametime directory, the primary storage repository. However, there are cases
where certain user information is not stored in the Sametime directory. In fact,
there are some use cases where it is beneficial not to store certain information in
the Sametime directory (for example, users’ photos). Therefore, the need to pull
data from multiple data sources arises. With good foresight, the UserInfo
application is designed to handle this need and can pull data (that is, user
information) from multiple storage repositories for a single user.
In summary, the data displayed in a business card is retrieved from storage

repositories. With Sametime 7.5.1, there are three different types of repositories:
a Domino directory, an LDAP directory, or a custom notes database.
6.3.4 Business card and storage configurations

In this section we examine several possible configurations for the business card
and its storage repositories. You should be able to identify similarities between
your environment and at least one the examples described below. The goal of
this section is to help you understand what is and what is not possible when
setting up business cards.

Use case 1- business card-related information is stored in
the Sametime directory
The simplest of all cases is when all business card-related information is stored
in the Sametime directory (whether it is a Domino directory or an LDAP directory)
such that all information displayed in the business card is retrieved from a single
data source, the primary storage repository (that is, the Sametime directory).
Example 6-4 All data stored in Sametime directory - Domino directory

Primary Storage (Sametime directory) type: Domino Directory
User information stored in the Primary Storage:

Name, Address, Email, Phone number, & User’s Photo
Example 6-5 All data stored in Sametime directory - LDAP directory

Sametime directory type: LDAP directory

Name, Address, Email, Phone number, & User’s Photo
Use case 2 - business card information for a single user

spread across two separate and distinct storage repositories
Business card-related information for a single user is spread across two separate
and distinct storage repositories. The UserInfo application can retrieve
information for a single user from two separate data sources and therefore once
configured properly, both sets of data will merge together and display into a
single business card.
Example 6-6 Data spread across two storage repositories (Domino/custom database)
Primary Storage (Sametime directory) type: Domino directory
Secondary Storage type: Custom Notes Database

Name, Address, Email
User information stored in the Secondary Storage:

Email, Phone number, & User’s Photo

Example 6-7 Data spread across two storage repositories (LDAP/custom database)
Primary Storage (Sametime directory) type: LDAP directory
Secondary Storage type: Custom Notes Database


Example 6-8 Data spread across two storage repositories (Domino/LDAP)

Secondary Storage type: LDAP directory


Example 6-9 Data spread across two storage repositories (LDAP/Domino)

Secondary Storage type: Domino directory


Attention: The following use cases demonstrate unsupported configurations.

This is a must read to fully understand what the UserInfo application can and
cannot do.

Use case 3 - information is spread across two separate
yet similar storage types
The UserInfo application is not designed to retrieve information for a single user
(that is, a single business card) when the information is spread across two
separate yet similar storage types. Therefore, the primary storage and the
secondary storage can never be of the same storage type. The following
configurations are not supported (Example 6-10 and Example 6-11).
Example 6-10 Data spread across two storage repositories (Domino/Domino)

Secondary Storage type: Domino directory


Example 6-11 Data spread across two storage repositories (LDAP/LDAP)

Secondary Storage type: LDAP directory


6.3.5 Best practices for setting up the business card feature

There are few basic rules of thumb that should be adhered to when setting up the
business card feature:
򐂰 In most cases, all user information should be retrieved from the primary
storage repository (that is, the Sametime directory).
򐂰 Business card photos
– The LDAP directory supports only the JPEG/JPG format for photos.
– The Domino directory supports both the GIF and JPG formats for photos.
– Maximum size for photo: 64 Kbytes.
– Recommended size for photo: < 10 Kbytes.
– Photos should be Web-optimized as if for display on the Web.

Tip: If you want to display photos in the business card, there are couple
of questions that you need to ask yourself:
򐂰 How large will the directory grow to?
For example, with ITSO there are 120,000 Sametime users. If we
assume that the average picture size is 10 KB, then the size of the
directory can potentially grow by 1.12 GB. This is not a minor
growth. You must evaluate whether your directory can handle this
growth effectively and efficiently.
򐂰 Can the network handle the extra load of pictures being transmitted?
With business cards readily accessible from within the Connect
client, there will be an extra load on the network due to transmitting
the photos. This is why we recommend keeping the size of the
picture small. GIFs are a good way to optimize pictures without
much loss of quality.
– If the primary storage repository is a Domino directory or a Domino LDAP

directory and your enterprise is quite large like ITSO Corporation’s, we
recommend storing photos in a secondary repository. If you were to store
all photos in the Domino Address Book (names.nsf), the size could get
very large very fast. You could then expect delays in opening, viewing,
and searching data within the address book. You also increase your risk of
database corruption by increasing the size of the address book. This
needs to be evaluated in your own environment to see if this is a valid
concern.
6.3.6 Set up business card feature for ITSO Corporation

In our environment, we configured Sametime to use Tivoli Directory Server
(TDS) as our Sametime directory. After evaluating the potential impact of
business card photos, we decided that the Sametime directory (that is, the
primary storage repository) can handle it, and therefore, we decided to store
users’ photos in the LDAP directory and not in a secondary storage repository.

Import user photo into the TDS LDAP directory
To do this:
1. Launch the Tivoli Directory Server Web Administration Tool
(http://tds.cam.itso.ibm.com:12100/IDSWebApp/IDSjsp/Login.jsp) and
log in with the admin account (Figure 6-4).
Figure 6-4 Tivoli Directory Server Web Administration Tool

2. Expand Directory Management → Manage entries (Figure 6-5).
Figure 6-5 Directory Management → Manage entries

3. Select dc=itso,dc=com and click Expand (Figure 6-6).
Figure 6-6 Expand containers

4. Select cn=users and click Expand (Figure 6-7).
Figure 6-7 Expand containers

5. Select the appropriate user and click Edit attributes (Figure 6-8).
Figure 6-8 Edit attributes

6. Click Optional attributes (Figure 6-9).
Figure 6-9 Optional attributes
7. In the jpegPhoto field, click Binary data (Figure 6-10).
Figure 6-10 jpegPhoto - Binary data

8. Click Import (Table 6-11).
Figure 6-11 Manage binary data - Import
9. Click Browse, and browse to the JPG picture that you want to import
(Figure 6-12).
Figure 6-12 Import binary data - Browse

10.Click Submit file (Figure 6-13).
Figure 6-13 Import binary data - Submit file
11.You will see the message File uploaded. Click Close (Figure 6-14).
Figure 6-14 Import binary data - File uploaded

12.Click OK on the Manage binary data screen (Figure 6-15).
Figure 6-15 Manage binary data
13.In the jpegPhoto field, you will now see Binary data 1 (Figure 6-16).
Figure 6-16 jpegPhoto field - Binary data
14.Click OK at the bottom of the screen to complete the process (Figure 6-17).
Figure 6-17 OK to complete the import process
Checkpoint - Verify photo is available via LdapSearch

To do this:
1. Open a command prompt on a Sametime server and navigate to the Domino
program directory (that is, c:\Lotus\Domino\).

2. Issue the following command:
ldapsearch -h tds.cam.itso.ibm.com -b dc=itso,dc=com -D cn=root -w
password “uid=cprice”
Tip: The results should display the jpegPhoto attribute, as it does in

Figure 6-18. This confirms the photo was imported correctly and is ready for
use.
Figure 6-18 ldapsearch test
Configure business card to display information

To do this:
1. Open your favorite Internet browser, and direct it to a chat server:
http://chat1.cam.itso.ibm.com
2. Click Administer the Server, and enter the LDAP account used to administer
Sametime.
3. Expand Configuration → Business Card Setup.
4. On the Business Cards page, you can select and deselect what information is
displayed on the business card. You can also change the mapping for each
attribute to make it appropriate for own directory. For TDS, we do not have to
do anything at all. The default settings work for our environment.

Tip: For more details on how to set up business cards to retrieve data from
secondary repositories, see the Sametime 7.5.1 InfoCenter:
http://publib.boulder.ibm.com/infocenter/sametime/v7r5m1/index.jsp
6.3.7 Testing the business card setup

As described above, data for the business card is requested from the UserInfo
servlet. In order to verify that our setup is correct, we need to make certain that
the UserInfo servlet will return data we specifically request. We can do this by
bypassing the Connect client completely, which is recommended for this test.
Tip: To test the UserInfo servlet, we have to construct an HTTP request (that
is, a URL) to request the business card details for the user we just set up. The
HTTP request consists of four components:
򐂰 Protocol
򐂰 Host name
򐂰 Path to servlet
򐂰 Parameters
In order to compose a request for business card details just like the Connect
client would, we have to provide three parameters:
򐂰 An operation ID that identifies the type of service required from the servlet.
The Connect client uses an operation ID of 3 in the retrieval of business
card data. Therefore, so do we.
򐂰 A unique user ID whose details are being queried for in the data sources.
The user’s distinguished name is provided (example user DN =
{uid=cprice,cn=users,dc=itso,dc=com}).
򐂰 A set ID that identifies a predefined set of user details for which to retrieve
values. To get business card data, the Connect client uses the predefined
set with an ID of 1. Therefore, in testing we use the same (example set =
{name, address, phone, photo}).
The syntax to construct the URL is:

http://[hostname]/servlet/UserInfoServlet?operation=3&userId=[user
DN]&setid=1
In our case, the URL looks like:

http://chat1.cam.itso.ibm.com/servlet/UserInfoServlet?operation=3&us
erId=uid=cprice,cn=users,dc=itso,dc=com&setid=1

Output of our test URL looks like Figure 6-19.
Figure 6-19 Business card data retrieval test - UserInfo servlet
6.4 Notes Client integration with Sametime

In this section we walk through the steps to integrate awareness and chat in your
Notes client.
Everyone should read 6.4.1, “How instant messaging works using a Notes Client”
on page 353, to understand how the Notes Client will interact with your
Sametime infrastructure.
At the end of that section we go into more detail on what sections you will need to
complete depending on the directory Sametime authenticates against.
6.4.1 How instant messaging works using a Notes Client

Instant Messaging is always a two-step process:
1. Log in user from client.
2. Resolve user list to show awareness status.

Log in user from client
Through the Notes Client, there are two ways to log into Sametime:
򐂰 Enter and save your name and password, the same as you would do with a
This option works just as the Connect client does. When setting up the Notes
client for instant messaging, the client first displays a login screen asking for
user name and password, with the option to save the password.
򐂰 Configure SSO between the Notes client and the Sametime server.
Note: This option only works when Sametime authenticates against Native
Domino or Domino LDAP.
This option uses your user.id file for the client to open a request to the
Domino server that Sametime is running on. Domino verifies the ID with the
person document in names.nsf, and generates an LTPA token that is passed
back to the Notes Client. The Notes client then sends this to Sametime to log
the user in.
Resolve user list to show awareness status

Once you have logged into Sametime, you can now access awareness-enabled
databases. The database will have a column that is configured to generate
awareness on. The mail file is one of these databases. It uses the who column,
pulling out the from field, to generate awareness. In the from field, an e-mail sent
by a Notes user will have the following value: John Bergland/ITSO. There are
two options for how to send this name to Sametime to generate awareness:
Abbreviated canonical format John Bergland/ITSO
Full canonical format CN=John Bergland/O=ITSO
If Sametime is authenticating against Native Domino, either of these formats will

work fine. You simply need to complete the following section to configure instant
messaging in the Notes clients: 6.4.5, “Enable awareness in Notes Client” on
page 360.
If, however, you authenticate against a Domino LDAP directory, the full canonical
format will work best for you. You will need to complete the following sections to
configure instant messaging in the Notes clients:
򐂰 6.4.4, “Configure Notes Client to pass full canonical name format” on
page 358
򐂰 6.4.5, “Enable awareness in Notes Client” on page 360

Finally, if Sametime authenticates against a non-Domino LDAP directory either
format will work for you depending on which format you add to a field in the
non-Domino LDAP directory. In this environment, which is the environment ITSO
is using, you will need to complete the following sections to configure instant
messaging in the Notes clients:
򐂰 6.4.2, “Add a Domino canonical name to LDAP Directory” on page 355
򐂰 6.4.3, “Add LDAP’s Domino Canonical Name field to resolve filter” on
page 356
򐂰 6.4.4, “Configure Notes Client to pass full canonical name format” on
page 358
򐂰 6.4.5, “Enable awareness in Notes Client” on page 360
6.4.2 Add a Domino canonical name to LDAP Directory

Decide what name format to add from Table 6-1 that will be the easiest to add to
your LDAP directory. Once that is decided extend the schema in the Tivoli
Directory Server to add an attribute to contain the Domino distinguished name of
a user. For details on how to extend the schema see 3.9, “Extending the LDAP
schema” on page 115.
Table 6-1 Possible configuration names to pass

Type Name passed
Abbreviated canonical John Bergland/ITSO
Full canonical CN=John Bergland/O=ITSO
In our test environment we added the attribute notescon.
This field was populated with full canonical format of the Domino distinguished
name. So for the person records in our test environment for John Bergland, we
set the notescon field to the following:
notescon: CN=John Bergland/O=itso
Now the person record in TDS is updated. You will need to add the LDAP
Domino Canonical Name field (notescon) to the Sametime filter used to resolve
users’ distinguished names.

6.4.3 Add LDAP’s Domino Canonical Name field to resolve filter
Note: This section should only need to be completed if Sametime

authenticates against a Non-Domino LDAP directory.
To update the resolve filter in Sametime to include the notescon field complete
the following:
1. On each chat cluster server open the Sametime Configuration database
(stconfig.nsf) in a Notes client.
2. Open the LDAP document, as shown in Figure 6-20.
Figure 6-20 stconfig.nsf - LDAP document

3. Update the Search filter for resolving person names field to include notescon.
In our test environment the filter is:
($(objectclass=organizationalPerson)(|(cn=%s*)(givenname=%s*)(sn=%s*
)(mail=%s*)(notescon=%s)
This is shown in Figure 6-21.
Figure 6-21 updated resolve filter including notescon
4. Restart the Sametime server for the changes to take effect.
Sametime is now able to resolve the full Notes name in LDAP, and awareness is
ready to work in a Notes Client.

6.4.4 Configure Notes Client to pass full canonical name format
Note: This step should only need to be completed if Sametime authenticates

against an LDAP directory (Domino or non-Domino).
However, if Sametime authenticates against a non-Domino LDAP directory

and in step 6.4.2, “Add a Domino canonical name to LDAP Directory” on
page 355, you added the abbreviated canonical format of the name (John
Bergland/ITSO) instead of the full canonical format (CN=John
Bergland/O=ITSO), you should not complete this step. Instead, skip this step
and go to 6.4.5, “Enable awareness in Notes Client” on page 360.

By default the Notes client sends the abbreviated canonical format of user
names to generate awareness for users showing in the who column of the mail
database (John Bergland/ITSO in our text environment). In our LDAP directory
we imported the full canonical format (CN=John Bergland/O=ITSO), so by
default the names in the who column do not display awareness. To configure the
Notes client to send the full canonical format of the names to Sametime, the end
users must complete the following steps:
1. In the Notes client, click File → Preferences → User Preferences, as shown
in Figure 6-22.
Figure 6-22 Notes Client - User Preferences
2. In the User Preferences pop-up window open Instant Messaging.

3. Click General.

4. Select the check box Use canonical name for instant messaging status
lookup, as shown in Figure 6-23.
Figure 6-23 Use canonical name for instant messaging status lookup
5. Click OK.
The Notes client will now send the correct format in our test environment (full
canonical name) to build awareness for users in your awareness-enabled
databases. The end users now need to tell the Notes client what Sametime
server to connect to, and enter the user name and password.
6.4.5 Enable awareness in Notes Client

To enable awareness in the Notes client, the end users must complete the
following steps.

Provide Sametime server host name
To do this:
1. Edit the location document where you want awareness enabled, as shown in
Figure 6-24.
Figure 6-24 Edit office location document

2. On the Servers tab set IBM Lotus Sametime server to the host name of your
Sametime server (imcluster.cam.itso.ibm.com in our test environment), as
Figure 6-25 Location document - Server tab

3. Click the Instant Messaging tab and ensure that the settings are correct for
your environment. You can see the settings for our environment in
Figure 6-26.
Figure 6-26 Location document - Instant Messaging tab
4. Click Save & Close.
Now log on to instant messaging to see awareness.

Log on to instant messaging
To do this:
1. In the Notes Status bar you should see an instant messaging menu saying
Disconnected (next to the Location menu). Click Disconnected and select
Log OnTo Instant Messaging, as shown in Figure 6-27.
Figure 6-27 Log on to instant messaging
2. Enter your name and password (cprice:password), as shown in Figure 6-28.
Figure 6-28 Enter your instant messaging user name and password

3. The awareness menu should now show I Am Active. You are now logged
into Sametime, and people can start chatting with you. If you now open your
mail file, you will see awareness for the people in your inbox, as shown in
Figure 6-29.
Figure 6-29 awareness in inbox
6.5 Domino Web Access integration with Sametime

In this section we discuss how to integrate chat and awareness capabilities for
your Domino Web Access (DWA) users.
To configure DWA with Sametime:

1. “Install Domino and register the DWA users” on page 366.
Note: If you already have Domino installed and users on the DWA
template, you can skip the install and register section and move to 6.7,
“Configure DWA for awareness and chat” on page 383.

2. “Configure DWA for awareness and chat” on page 383.
In this section we discuss the following topics. The directory Sametime
authenticates against determines what topics you need to do. Details on
which topics needed to cover per directory are discussed at the end of 6.7.1,
“How instant messaging works in DWA” on page 383.
– 6.7.1, “How instant messaging works in DWA” on page 383.
– 6.7.2, “Synchronize the directories” on page 384.
– 6.7.3, “Configure SSO between DWA and Sametime” on page 401.
– 6.7.4, “Configure DWA server document for awareness and chat” on
page 406.
– 6.7.5, “DWA user settings to enable awareness and chat” on page 409.
– (Optional) 6.7.6, “Change how names are passed to Sametime for
awareness status” on page 413.
6.6 Install Domino and register the DWA users

In this section we do the minimum install of Domino to integrate DWA with
Sametime. This topic is designed to show you what steps are needed and how
DWA integrates with Sametime. It is not a guide for Enterprise Scale DWA
deployments. For more information about deploying DWA, refer to the official
product documentation at:
http://www-128.ibm.com/developerworks/lotus/documentation/domino/
Or see the Redpaper Lotus Notes and Domino 7 Enterprise Upgrade Best
Practices, REDP-4120:
http://www.redbooks.ibm.com/abstracts/redp4120.html?Open
6.6.1 Install Domino

Before you install DWA, you need to install DWA into the same Domino domain
as Sametime. To install and configure Domino into the Sametime domain follow
the following steps:
1. Register the server.
2. Pre-Domino Install Checklist.
3. Install Domino.
4. Configure Domino.
5. Do the post Domino installation/configuration steps.
6. Verification checkpoint - set up the Domino server.

Register the server
To do this:
the first server that was set up. In our case, it was (chat1.cam.itso.ibm.com),
and click OK.

7. Click OK to continue (Figure 6-31).
8. Enter the password for the certifier ID file and click OK (Figure 6-32).

9. You may get prompted with a Certifier Recovery Information Warning dialog
window. Click OK to continue (Figure 6-33).
(chat1/ITSO) and certifier (/ITSO) are correct. Click Continue to proceed
(Figure 6-34).

11.On the Register New Server(s) dialog window, enter the following fields
(Table 6-2).

Field Value
Server name dwa
Server title (optional) Domino Web Access server 2

Check In file.
12.Click Set ID File and browse to the location where the ID file should be stored
(that is, C:\Lotus\Domino\data\ids\servers\dwa.id).
13.Click the green check mark button to add the server to the registration queue.
14.Highlight the new server, and click the Register button to complete the server
registration.
You have successfully registered the second Domino server. Proceed to the next
section to install the Domino server.
Check the pre-Domino install checklist

and working.
documentation:
software.

more details:
Install Domino
To install Lotus Domino on a Windows platform:
installation CD.
Next.



6. On the Choose the setup type that best suits your needs screen
(Figure 6-37), select Enterprise Server and click Next.

7. On the following screen you will a summary of your selections (Figure 6-38).
After a careful review, click Next to begin the installation.

(Figure 6-39).
Configure Domino
To do this:

4. On the First or additional server screen (Figure 6-41), select Set up an
additional server and click Next.
Note: In previous steps we stored the DWA’s server ID on chat1’s local file
program, DWA’s server ID needs to be made accessible. We could map a
drive to chat1 or simply copy the file from chat1 to DWA. For this step, we
will copy DWA’s server ID from chat1’s local file system onto the desktop of
DWA.
6. On the Provide the registered name of this additional Domino server, click
Next.

7. On the What Internet services should this Domino Server provide screen
(Figure 6-42), do the following:
8. Click OK, then click Next to continue.
9. On the Domino network settings screen, click Customize and do the

following:
the Domino server in the Host Name (Editable) field
(dwa.cam.itso.ibm.com in our test environment).
qualified host name for the Domino server (dwa.cam.itso.ibm.com).

11.On the Provide the system databases for this Domino server, enter the
following fields (Table 6-3), and click Next.

Field Value
Use a proxy server to connect to the other Leave unchecked.

Domino server
Use a dialup connection Leave unchecked.
Get system databases from CD or other Leave unchecked.

media
confirm the options that you have selected, and then click Setup to initiate the
Do the post Domino installation/configuration steps

time to initialize properly. (Ten minutes is generally longer than actually
needed, but to be on the safe side, we recommend that the Domino server

following:
services.msc
2. Issue the following commands on the DWA’s Domino server console to
perform an immediate synchronization between the two Domino servers:
3. To ensure that these system databases stay in sync, create a connection
document so that these databases will replicate on schedule.

see the topic “Scheduling server-to-server replication” located in the Domino
Verification checkpoint - set up the Domino server

At this point, we recommend that you perform sanity checks to verify that your
Domino server setup was successful and that its current configuration will not
pose any issues for the anticipated QuickPlace server setup. To validate the
cmd
b. On the command prompt window that appears, enter the following
command (substitute qp.cam.itso.ibm.com for your fully qualified host
name):
ping dwa.cam.itso.ibm.com
c. On the same command prompt window, you should also enter the
following command and verify that your server is listening on the correct IP
address:
ipconfig

server (that is, http://dwa.cam.itso.ibm.com). You should expect to see the

4. From a Lotus Notes client, from the menu bar select File → Database →
Open. Type the fully qualified host name into the Server field (that is,
dwa.cam.itso.ibm.com) and click Open. If a list of databases populate the
Database list box, then you have successfully connected to the Domino
server via a Notes client.

6.6.2 Register users in Domino
To register new Domino Web Access users:
1. Start the administration client by selecting Start → Programs → Lotus
Applications → Lotus Domino Administrator.
2. Close the Welcome window if it opens.
4. On the right side, open Tools → Registration → Person.
5. If this is the first time you have done this, complete the following steps
(otherwise, enter the certifier password and skip to the next step):
a. Click the Server button in the Choose a Certifier window.
For the Registration Server, chose your first Domino server. Click OK.
b. Click Certifier ID.
Browse to the certifier ID (located in C:\Lotus\Domino\Data on the first
server install by default).
c. Click OK and enter the certifier password.
6. Click OK in the Certifier Recovery Information Warning window if it opens.
7. In the Register Person -- New Entry window:
a. Ensure that the registration server is your first Domino server.
b. Enter the first name, last name, UID in the Short name field, and the
password.
c. Select Password Options:
i. Select Set Internet password. (This is the password the user will use
to log in to the database over the Web.)
ii. Click OK.
d. Select the Advanced options. Select the Mail tab and change the
following values:
i. Change your mail server to the DWA mail server (dwa/ITSO in our test
environment).
ii. Change the mail file template to Domino Web Access (R7).
e. Select the green check box.
f. Select the user and click Register to register the user and create the
user’s mail file.

6.7 Configure DWA for awareness and chat
Once the Domino mail users are registered in Domino, you are ready to integrate
DWA with Sametime.
Everyone should read 6.7.1, “How instant messaging works in DWA” on

page 383, to understand how the Notes Client will interact with your Sametime
infrastructure.
At the end of that section we go into more detail on what sections you will need to
complete depending on the directory Sametime authenticates against.
6.7.1 How instant messaging works in DWA

Instant messaging is always a two-step process:
1. Log user into Sametime from DWA client.
2. Resolve user list to show awareness status
Log user into Sametime from DWA client

Through DWA, there are two ways to log into Sametime:
򐂰 Configure DWA to pass a user’s distinguished name with an STToken.
We cover this option in this book. Using an LTPAToken provides better
performance and more security than STTokens.
򐂰 Configure DWA to pass a user’s distinguished name with an LTPAToken.
This option uses settings configured in the DWA server configuration
document, detailed in 6.7.4, “Configure DWA server document for awareness
and chat” on page 406, to determine the Sametime distinguished name of the
user for your environment, and an LTPAToken created by the DWA server to
log the user into Sametime.

Once you have logged into Sametime, you can now access awareness-enabled
databases. The database will have a column that is configured to generate
awareness on. The mail file is one of these databases. It uses the who column,
pulling out the from field, to generate awareness. In the from field, an e-mail sent
by a Notes user will have the following value: John Bergland/ITSO. In DWA there
are four options of how to send this name to Sametime to generate awareness:
򐂰 Abbreviated canonical format: John Bergland/ITSO
򐂰 Full canonical format: CN=John Bergland/O=ITSO
򐂰 Full LDAP canonical format: CN=John Bergland,O=ITSO
򐂰 Common name format: John Bergland

If Sametime is authenticating against Native Domino, any of these formats will
work. However, abbreviated canonical is typically used. You simply need to
complete the following sections to configure instant messaging in DWA:
򐂰 6.7.3, “Configure SSO between DWA and Sametime” on page 401
򐂰 6.7.4, “Configure DWA server document for awareness and chat” on
page 406
򐂰 6.7.5, “DWA user settings to enable awareness and chat” on page 409
You may want to also read through and decide what name format to use
(discussed in 6.7.6, “Change how names are passed to Sametime for awareness
status” on page 413).
If, however, Sametime authenticates against a Domino LDAP directory, the full
canonical or full LDAP canonical format will work best for you. You will need to
page 406
You may want to also read through and decide what name format to use,
discussed in 6.7.6, “Change how names are passed to Sametime for awareness
status” on page 413.
Finally, if Sametime authenticates against a non-Domino LDAP directory you will

need to synchronize the directories, explained in detail in the next section, and
򐂰 6.7.2, “Synchronize the directories” on page 384
page 406
You may want to also read through and decide what name format to use, as
discussed in 6.7.6, “Change how names are passed to Sametime for awareness
status” on page 413.
6.7.2 Synchronize the directories

In our test environment, where Sametime authenticates against a non-Domino
LDAP directory, there is a very important concept of dual directories we need to

cover to help you understand why some of the following steps are necessary.
Again, if in your environment you have Sametime authenticating against Native
Domino or Domino LDAP, instead of a third-party LDAP directory (TDS, AD, Sun
One, and so on) you can skip this explanation and step and move on to 6.7.3,
“Configure SSO between DWA and Sametime” on page 401.
The DWA users are registered in Domino and resolve to the Domino canonical
name from the person document for that user. Figure 6-44 shows a sample
person document from our test environment.
Figure 6-44 DWA user person document
From this figure, DWA resolves the user as CN=Charlie Price/O=ITSO, the
canonical name of Charlie Price/ITSO, if your organization uses organizational
units (Charlie Price/Atlanta/ITSO - the canonical name would be CN=Charlie

Price/OU=Atlanta/O=ITSO). Note how this is different from Sametime. Sametime
authenticates against the TDS LDAP distinguished name, and therefore resolves
the user as uid=cprice/cn=users/dc=itso/dc=com in our test environment,
causing us to run into a problem where a single user, Charlie Price, is resolved
as a different distinguished name depending on the product they are accessing.
See Table 6-4.
Table 6-4
DWA distinguished name Sametime distinguished name
CN=Charlie Price/O=IBM uid=cprice,cn=users,dc=ibm,dc=com
When integrating DWA with Sametime it is necessary for DWA to pass the
Sametime distinguished name to Sametime when logging in the user.
To configure DWA to pass the distinguished name used by Sametime (the TDS
LDAP distinguished name) to Sametime, we must synchronize the directories.
Meaning, we need to do one of the following:
򐂰 Add the Domino distinguished names as an attribute in the user’s person
record of Tivoli Directory Server.
򐂰 Add the Tivoli Directory Server distinguished name to the user’s person
document in Domino.
The decision of what directory you update is completely up to you.
Add Domino DN to Tivoli Directory Server
Important: You do not need to add names into both directories. These steps
are for updating the Tivoli Directory Server directory. If you prefer to update
Domino go to “Add LDAP DN to Domino person document” on page 397.
Adding the Domino distinguished name into Tivoli Directory Server is a

three-step process:
1. Extend TDS schema.
2. Configure directory assistance on DWA servers.
3. Add directory assistance db to server doc.
Extend TDS schema

First extend the schema in the Tivoli Directory Server to add an attribute to
contain the Domino distinguished name of a user. For details on how to extend
the schema see 3.9, “Extending the LDAP schema” on page 115.
In our test environment we added the attribute NotesDN.

This field should be populated with LDAP canonical format of the Domino
distinguished name. So for the person document in our test environment, Charlie
Price/IBM, we set the NotesDN field to the following:
NotesDN: CN=Charlie Price,O=ibm
Now that the person record in TDS is updated, we need to tell DWA what server
to go to find the LDAP distinguished name needed to pass to Sametime. To do
that we configure directory assistance.
Configure directory assistance on DWA servers

To tell DWA where to find the LDAP distinguished name used by Sametime we
configure directory assistance.
1. If you do not have directory assistance already configured on your server
create a new one by choosing File → Database → New in your Notes client
(Figure 6-45).
Figure 6-45 Create new database

2. In the pop-up window set
– Server: dwa/itso
– Title: Directory Assistance
– File name: da.nsf
Under Specify Template for New Database set the server as dwa/ITSO.
Check Show advanced templates at the bottom and chose Directory
Assistance (7) as the template.
Click OK, as seen in Figure 6-46.
Figure 6-46 New directory assistance database
3. Click Escape to close the About Directory Assistance page.

4. In the directory assistance database, click Add Directory Assistance, as
Figure 6-47 Add directory assistance document
5. On the Basics tab set the fields as follows:

– Domain Type: This should always be LDAP for this configuration.
– Domain name: This needs to be anything (other than Domino) used by the
address book on the DWA server. In our test environment we cannot use
ITSO. Set this to ITSO corp.
– Company name: Again, this needs to be anything (other than Domino)
used by the address book on the DWA server. In our test environment we
cannot use ITSO. Set this to ITSO corp.
– Search order: This is used when multiple directory assistance documents
exist, to determine order in which the document will be searched.

– Make this domain available to: You must select Notes Clients & Internet
Authentication/Authorization in this environment.
– Group Authorization: This determines whether Directory Assistance (DA)
will search for groups that the LDAP directory person belongs to during
authorization. For this specific configuration, this is not needed.
– Enabled: This must be set to yes.
– Attribute to be used as name in an SSO token (map to Notes
LTPA)_UsrNm): Set this to $DN in this environment. We discuss this field
further in “Configure SSO between DWA and Sametime” on page 401.
How we set this up in our test environment is shown in Figure 6-48.
Figure 6-48 Directory Assistance Basic tab
6. Click the Naming Contexts (Rules) tab.

7. Set Trusted for Credentials to Yes, as seen in Figure 6-49.
Figure 6-49 Directory Assistance Naming Contexts (Rules) tab
8. Select the LDAP tab.

9. Set the fields as follows. Under LDAP Configuration:
– Hostname: host name of the LDAP server that Sametime authenticates
with.
– Username: The bind user to the LDAP server specified under Hostname.
– Password: The password for the bind user specified by Username.
– Base DN for search: This is the base of the LDAP.
– Channel encryption: Set to SSL or none depending on how the LDAP
server is configured. We recommend setting this up without SSL first,
once everything is working, then enabling SSL.
– Port: The port that the LDAP server is listening on.

Advanced options:
– Timeout: maximum number of seconds directory assistance will wait for a
response from the LDAP directory.
– Maximum number of entries returned: maximum results from a single
search.
– Dereference alias on search: Whether directory assistance request LDAP
to search alias references.
– Preferred mail format: used if LDAP has fields for Internet and Notes
e-mail addresses.
– Attribute to be used as Notes distinguished name: This should be set to
the attribute you used to extend the schema in TDS.
– Type of search filter to use: Specify the directory you are using: Standard
LDAP, Active Directory, or custom to build your own search filter.

The settings used in our test environment are shown in Figure 6-50.
Figure 6-50 Directory Assistance LDAP tab

11.Close the directory assistance database.
Now that the directory assistance database is set up and configured, you need to
tell the server to use this database.
Add directory assistance db to server doc

To do this:
1. Open names.nsf in a Notes client.

2. Go to the Configuration → Servers → All server documents view, as show
in Figure 6-51 on page 394.
3. Select the dwa server and click Edit Server as show in Figure 6-51 on
page 394.
Figure 6-51 All server documents view

4. On the Basics tab, under Directory Information, set the directory assistance
database name to the database you just created (da.nsf in our test
environment), as seen in Figure 6-52.
Figure 6-52 Server document, Basic tab
Any time you make changes to the server document here or the directory
assistance database you will need to restart the Domino server for the changes
to take effect. We wait at this point to restart, however, as we will make additional
changes to the server document, and just restart when all are complete.

How this works
Once this is complete, when you log into Domino and access your Domino Web
Access mail file, DWA will authenticate you as CN=Charlie Price/O=ITSO.
1. As it goes to log you into Sametime, DWA will look to the directory assistance
database to see if it has NotesDN populated in the Attribute to be used as
notes distinguished name field, as set in Figure 6-50 on page 393.
2. DWA does an LDAP search using the setting in directory assistance, as set in
Figure 6-50 on page 393, with the filter:
filter: notesDN=CN=Charlie Price,O=ITSO
3. If the schema was extended and attributed updated correctly (as explained in
“Extend TDS schema” on page 386), the LDAP directory will return the LDAP
distinguished name of the user (uid=cprice,cn=users,dc=itso,dc=com in our
example) to DWA.
4. DWA will then use this name to log the user into Sametime.
DWA Mail Server
Cprice.nsf ACL 4
Writestlinksapplet(uid=cprice,
1
Charlie Price/ITSO cn=users, dc=itso,dc=com;
<LTPAToken>); Sametime Server
2 Filter:
3 Return:
notesDN= uid=cprice,cn=users,
CN=Charlie Price, dc=itso,dc=com
O=ITSO
TDS LDAP Server

uid=cprice,cn=users,dc=itso,dc=com
cn: Charlie Price
uid: cprice
mail: charlie.price@itso.com
notesDN: CN=Charlie Price,O=itso
Figure 6-53 How awareness works in DWA

Add LDAP DN to Domino person document
Important: You do not need to add names into both directories. These steps
are for updating the Domino directory. If you prefer to update the Tivoli
Directory Server go to “Add Domino DN to Tivoli Directory Server” on
page 386.
Adding the Tivoli Directory Server distinguished name into the Domino directory
should be done in two places:
򐂰 Add LDAP DN to user name field.
򐂰 Add LDAP DN to LTPA user name field.
Add LDAP DN to user name field
Note: You can add this Tivoli Directory Server distinguished name to the
username or shortname field. How to do this in the username field is
described below, but either is acceptable.

2. Go to the People view, select a user, and click Edit Person, as shown in
Figure 6-54.
Figure 6-54 Person view

3. As the third entry or later in the username field, add the Tivoli Directory Server
distinguished name using the Domino slash (/) separator instead of the
comma (,) separator. In our test environment this would be entered as
uid=cprice/cn=users/dc=itso/dc=com, as shown in Figure 6-55.
Figure 6-55 add LDAP DN to username field
Note: This cannot be one of the first two entries of the username field. The
first is reserved for the Domino distinguished name, and must stay Charlie
Price/ITSO in this example. The second is reserved for the user’s common
name in Domino (Charlie Price in this example).
Do not save and close the person document yet. We need to add the
distinguished name to one more field in the person document, described in the
next section.

Add LDAP DN to LTPA user name field
To do this:
1. Click the Administration tab.
2. Under the Client Information section add the Tivoli Directory Server
distinguished name using the Domino slash (/) separator instead of the
comma (,) separator. Again, in our test environment this would be entered as
uid=cprice/cn=users/dc=itso/dc=com, as shown in Figure 6-56.
Figure 6-56 LTPA User name field
3. Save and close the person document.
How it works
Once this is complete, when you log into Domino and access your Domino Web
Access mail file, DWA will authenticate you as CN=Charlie Price/O=ITSO.
1. As it goes to log you into Sametime DWA will recognize that the distinguished
name it contains is not the correct name.

2. DWA will look to the person document for the user Charlie Price/ITSO
requesting the LTPA UsrNm field, as set in Figure 6-56 on page 400.
3. If the field was updated correctly, as shown in Figure 6-56 on page 400, the
Domino directory will return the LDAP distinguished name of the user in
LDAP format (uid=cprice,cn=users,dc=itso,dc=com in our example) to DWA.
4. DWA will then use this name to log the user into Sametime.
DWA Mail Server
cprice.nsf ACL
1
Charlie Price/ITSO
4
Writestlinksapplet(
uid=cprice,cn=users,
3
Return: dc=itso,dc=com;
2
Charlie Price/ITSO uid=cprice,cn=users,
dc=itso,dc=com
<LTPAToken>);
Sametime Server
Domino Directory
UserName:
Charlie Price/ITSO
Charlie Price
uid=cprice/cn=users/dc=itso/dc=com
LTPA UsrNm:
uid=cprice/cn=users/dc=itso/dc=com
Figure 6-57 How awareness works in DWA
6.7.3 Configure SSO between DWA and Sametime

The next step to Integrate DWA and Sametime is to get single sign-on (SSO)
working between the user’s Domino Web Access mail file and Sametime. To
configure SSO:

2. Go to the Web → Web Configuration view, select Web SSO Configuration
for LtpaToken, and click Edit Document, as seen in Figure 6-58.
Figure 6-58 Web Configurations view

3. Edit the following parameters as follows:
– Domino Server Names: Add the DWA servers.
– Map names in LTPA tokens: If Sametime authenticates against a
third-party LDAP directory (TDS, AD, Sun One, and so on), set this to
enabled. If Sametime authenticates against Domino LDAP or Native
Domino, you can leave this as disabled.
Figure 6-59 Web SSO configuration document

5. Go to the Configuration → Servers → All Server Documents view.

6. Select the DWA server and click Edit Server, as shown in Figure 6-60.
Figure 6-60 All Server Documents view

7. Click the Internet Protocols - Domino Web Engine tab and set:
– Session authentication: Multiple Servers (SSO).
– (Optional) Web SSO Configuration: LtpaToken (same as Configuration
Name field in Web SSO document, as shown in Figure 6-59 on page 403).
If the configuration name is anything other than LtpaToken, you must set
this field.
Figure 6-61 Enable MSSSO in server document
Normally, you would replicate this change out to the DWA server and restart the
server before SSO will work with Sametime. However, there is one additional
step in the Domino directory that we need to complete to get awareness and chat
working in DWA, so we will not replicate and restart at this point, but move on to
the next section.

6.7.4 Configure DWA server document for awareness and chat
To do this:
1. If you do not have the Domino directory open, open names.nsf in a Notes
client.
2. Go to the Configuration → Servers → Configurations view.
– If a document exists for your server, edit this document.
– If a document exists for all servers, you can edit this document or create
one specifically for this DWA server.
– If no document exists, click Add Configuration, as shown in Figure 6-62.
Figure 6-62 Configurations view

3. Either select Use these settings as the default settings for all servers or
add the DWA server into the Group or Server name field. We added the DWA
server (dwa/ITSO) in our test environment, as shown in Figure 6-63.
Figure 6-63 Configuration Settings: Basics tab
4. Click the Domino Web Access tab.

5. Under the Instant Messaging section set the options as follows:
– Instant messaging features: Set this to enabled.
– Online Awareness: Set this to enabled.
– Allow secrets and tokens authentication: Set this to disabled. We will use
LTPA tokens for authentication.
– Set an IBM Lotus Sametime server hostname for all DWA users: Set this
to the cluster address for Sametime (imcluster.cam.itso.ibm.com:8082 in

our test environment). If Sametime was configured for tunnelled
connections, you would use port 80 here.
– Loading \stlinks from the Domino application server: where DWA will
download the stlinks applet (stlinks.jar, .cab, stlinks.js, and son on) files
from. Disabled downloads stlinks from the Sametime server. Enabled
downloads stlinks files from the Domino server.
Note: If you set this to enabled you need to copy the stlinks folder from
the Sametime server to the Domino Web Access folder, located in the
<Domino_Data>\domino\html\sametime directory.
– Prefer Sametime Connect for browsers: Set to enabled to use Java

Connect downloaded from the Sametime server.
– Pass the Organization name: Set to disabled.
– Directory Type used by Sametime: Set this to the Directory Sametime
Authenticates against. We authenticate against TDS in our test
environment, so we use non-Domino LDAP. If Sametime authenticates
against Native Domino, select Domino Directory. If Sametime
authenticates against a Domino LDAP directory select Domino LDAP
here.

Figure 6-64 Configuration Document: Domino Web Access tab
At this point all server settings are complete. You should replicate these changes
to the DWA server, and restart the DWA server.
6.7.5 DWA user settings to enable awareness and chat

The Domino Server is now ready for awareness and chat. At this point the users
simply need to enable it in the DWA client. Each user should follow the following
process to enable awareness:
1. Access their mail fine in a browser
(http://dwa.cam.itso.ibm.com/mail/cprice.nsf in our test environment).

2. Sign in and click Preferences, as shown in Figure 6-65.
Note: If you synchronized the directories by adding the Domino Name into
the Tivoli Directory Server, the user can sign in with her IDS name and
password. If you added the TDS DN into Domino, you will need to sign in
with your Domino name and password from the Internet password field in
the person document.
Figure 6-65 DWA Welcome page

3. On the Basic tab, near the bottom, select the check box to Enable Instant
messaging, as shown in Figure 6-66.
Figure 6-66 DWA preferences

4. Click Save, and you name should now show awareness, as seen in
Figure 6-67.
Figure 6-67 awareness in DWA
If administrators would prefer to have Enable Instant messaging set by default for
the users, there are some customizations you can make to the mail template to
accomplish this. Section 5.5.8 of the Domino Web Access 7 Customization
Redpaper gives excellent examples of how this can be accomplished. You can
find the redpaper here:

6.7.6 Change how names are passed to Sametime for awareness
status
At this point a user can sign into DWA and will get signed into Sametime and see
their status as active, as shown in Figure 6-67 on page 412. When the user clicks
on the Mail tab, her inbox appears, and DWA attempts to determine the status of
each mail message using the from field, as show in Figure 6-68.
Figure 6-68 Inbox with awareness
All users in Table 6-5 used Notes to send messages to Charlie Price. The inbox,
therefore, has the following set in the from field (Table 6-5).
Table 6-5 names sent to STLinks for awareness

Who From field
John Bergland John Bergland/ITSO@ITSO
George Lambie George Lambie/ITSO@ITSO
Jim Puckett Jim Puckett/ITSO@ITSO
Stephen Shepherd Stephen Shepherd/ITSO@ITSO
Vineet Rohatgi Vineet Rohatgi/ITSO@ITSO

Who From field
Jennifer Wales Jennifer Wales/ITSO@ITSO
Andy Higgins Andy Higgins/ITSO@ITSO
As discussed in 6.7.1, “How instant messaging works in DWA” on page 383,

DWA can be configured to take these Domino names (John Bergland/ITSO) and
pass them in one of four ways to STLinks to generate awareness, as shown in
Table 6-6.

Type Name passed
Abbreviated Canonical John Bergland/ITSO
Full LDAP canonical CN=John Bergland,O=ITSO
Common Name John Bergland
If Sametime authenticates against Native Domino or Domino LDAP, go to

“Configure iNotes_WA_SametimeNameFormat” on page 416 to determine what
is currently being passed to Sametime to generate awareness, and how to
change it.
If Sametime authenticates against a non-Domino LDAP, you should have

selected non-Domino LDAP as the LDAP directory used by Sametime in the
configuration document. By default, DWA will pass a common name to stlinks.
This will work well, unless the LDAP directory used by Sametime has cn fields
that are identical for different users. For example, if your company has two users
named John Bergland, you may have the following ldif’s in your directory
(Example 6-12).
Example 6-12 ldif’s

1st John Bergland user:
uid: jbergland,cn=users,dc=itso,dc=com
cn: John Bergland
cn: John A. Bergland
uid: jbergland
notesdn: John Bergland/Marketing/ITSO
....
2nd John Bergland user:

uid=jbergland2,cn=users,dc=itso,dc=com

cn: John Bergland
cn: John B. Bergland
uid: jbergland2
notesdn: John Bergland/Sales/ITSO
....
So from here we have two John Bergland’s in our company, one in marketing,
the other in sales. Therefore, sending just the common name to sametime would
resolve to two users (uid: jbergland,cn=users,dc=itso,dc=com and uid:
jbergland2,cn=users,dc=itso,dc=com). Sametime will be unable to uniquely
determine which users you need status for, and so will show the user as offline.
To resolve this you should use one of the other available formats.
Configure LDAP for Notes formats

Decide what format to use from Table 6-7 will be easiest to add to your LDAP
directory. Once that is decided extend the schema in the Tivoli Directory Server
to add an attribute to contain the Domino distinguished name of a user. For
details on how to extend the schema see 3.9, “Extending the LDAP schema” on
page 115.

Type Name passed
Abbreviated canonical John Bergland/ITSO
Full LDAP canonical CN=John Bergland,O=ITSO
Common name John Bergland
In our test environment we added the attribute NotesDN.
This field should be populated with LDAP canonical format of the Domino
distinguished name. So for the person document in our test environment, John
Bergland/ITSO, we set the NotesDN field to the following:
NotesDN: CN=John Bergland,O=itso
Now that the person record in TDS is updated, we need to tell DWA what server
to go to find the LDAP distinguished name needed to pass to Sametime.

Configure iNotes_WA_SametimeNameFormat
To configure DWA to pass names in the abbreviated canonical, full canonical, or
full LDAP canonical, you can specify a parameter in the notes.ini of the
Sametime server using Example 6-13 as a guide.
Example 6-13 iNotes_WA_SametimeNameFormat

iNotes_WA_SametimeNameFormat
Syntax: iNotes_WA_SametimeNameFormat=value
Description: Allows you to adjust the format of the name that is

passed to Sametime for login, for awareness checking, and whether to
pass RFC821 names. The value can contain up to 4 numeric digits in
sequence.
For example:
iNotes_WA_SametimeNameFormat=1011
where the following values apply:
First digit (left most) -- controls the format of the name passed to
Sametime to determine awareness status for users in who column:
0 = Abbreviated canonical format (for example, John Bergland/ITSO)
1 = Full canonical format (for example, CN=John Bergland/O=ITSO)
2 = Full LDAP canonical format (for example, CN=John Bergland,O=ITSO)
3 = Use only the common name (for example, John Bergland)
2nd digit -- controls whether RFC821 addresses (for example, Joe

User@acme.com) should be sent to Sametime:
0 = No, do not send
1 = Yes, do send [the default]
3rd digit -- controls the format of the name passed to Sametime to

login the user:
0 = Abbreviated canonical format (for example, John Bergland/ITSO)
1 = Full canonical format (for example, CN=John Bergland/O=ITSO)
2 = Full LDAP canonical format (for example, CN=John Bergland,O=ITSO)
3 = common name (for example, John Bergland)
4 = non-Domino LDAP format (uid=jbergland,cn=users,dc=itso,dc=com) if
non-Domino LDAP format can not be found, use common name (John Bergland)
4th digit -- a debug aide that when the users hovers over a link, the
name that displays is identical to the name sent to Sametime. Use any
character in the fourth position to enable this.

By default, we use the following settings depending on how you configure the
“Directory type used by the IBM Lotus Sametime server” field in the Instant
Messaging section under the DWA tab of the configuration document for your
DWA server, as shown in Figure 6-69.
Figure 6-69 Directory type used by Sametime options
The defaults for each option are shown in Table 6-8.
Table 6-8 iNotes_WA_SametimeNameFormat defaults

Directory type selected iNotes_WA_SametimeNameFormat
Domino directory iNotes_WA_SametimeNameFormat=011
Domino LDAP iNotes_WA_SametimeNameFormat=111
Domino LDAP for xSP iNotes_WA_SametimeNameFormat=311
Non-Domino LDAP iNotes_WA_SametimeNameFormat=314
In our test environment, we are using non-Domino LDAP. Using the setting
above iNotes_WA_SametimeNameFormat=314 we will interact with Sametime
using the following settings:
򐂰 Login user to Sametime: (3rd digit - 4) use non-Domino LDAP format.
򐂰 Generate awareness for who column: (1st digit - 3) common name.

We want to change the name passed to Sametime to generate awareness for
the who column, from the common name (John Bergland) to the full LDAP
canonical format (CN=John Bergland,O=ITSO). To do this we force the first digit
in the iNotes_WA_SametimeNameFormat to a 2, but add the following to the
notes.ini on the DWA server:
If you wanted to pass the abbreviated canonical format (John Bergland/ITSO)

you would use:
If you wanted to pass the full canonical format (CN=John Bergland/O=ITSO) you
would use:
You will need to restart the DWA server for this change to take effect.
Now that DWA is passing a unique name to Sametime to generate awareness

(CN=John Bergland,O=ITSO), we need to make sure that the field containing
this information (NotesDN in our test environment) will be searched during a
resolve in Sametime.
Update resolve filter in Sametime
Note: This should only need to be completed if Sametime authenticates

against a non-Domino LDAP directory.
To update the resolve filter in Sametime to include the NoteDN field complete the
following:
1. On each chat cluster server open the Sametime Configuration database
(stconfig.nsf) in a Notes client.

2. Open the LDAP document, as shown in Figure 6-70.
Figure 6-70 stconfig.nsf - LDAP document

3. Update the “Search filter for resolving person names” field to include
NotesDN. In our test environment the filter is:
($(objectclass=organizationalPerson)(|(cn=%s*)(givenname=%s*)(sn=
%s*)(mail=%s*)(NotesDN=%s*)
This is shown in Figure 6-71.
Figure 6-71 Updated resolve filter including NotesDN
4. If you used the full LDAP canonical format, add the following to the
sametime.ini to force Sametime to try to resolve the name:
[Directory]
ST_DB_LDAP_BROWSE_BY_RESOLVE_FILTER=1
ST_DB_LDAP_ALLOW_SEARCH_ON_DN=1
5. Restart the Sametime server for the changes to take effect.

Sametime is now able to resolve the full Notes name in LDAP.
6.8 QuickPlace integration with Sametime

In this topic we talk about how to integrate our Sametime environment into Lotus
QuickPlace.
To configure QuickPlace with Sametime follow these steps:

1. Install QuickPlace and configure Security.
a. Install Domino for QuickPlace.
b. Install QuickPlace.
c. Configure QuickPlace Security.
2. Configure QuickPlace for awareness, chat, and meetings.
a. How instant messaging works in QuickPlace.
b. Configure QuickPlace for awareness and chat.
c. Configure QuickPlace for online meetings.
6.9 Install QuickPlace and configure Security

In this section we do the minimum install of QuickPlace to integrate with
Sametime. This topic is designed to show you what steps are needed and how
QuickPlace integrates with Sametime. It is not a guide for Enterprise Scale
QuickPlace deployments. For more information about deploying QuickPlace and
the many other options of QuickPlace see the product documentation at:
http://www-10.lotus.com/ldd/notesua.nsf/find/quickplace
To install QuickPlace you need to complete the following steps:

1. Install Domino for QuickPlace.
2. Install QuickPlace.
3. Configure QuickPlace Security.
6.9.1 Install Domino for QuickPlace

Before you install QuickPlace, you need to install QuickPlace into the same
Domino domain as Sametime. To install and configure Domino into the
Sametime domain follow these steps:
1. Register a server.
2. Pre-Domino Install Checklist.
3. Install Domino.

4. Configure Domino.
5. Post Domino installation/configuration steps.
6. Verification checkpoint - Domino server setup.
Register a server
To do this:
the first server that was set up (in our case (chat1.cam.itso.ibm.com)), and
click OK.

6. Choose the Supply certifier ID and password option, and click the Certifier ID
button and browse to the certifier ID file (cert.id).
7. Click OK to continue.
8. Enter the password for the certifier ID file and click OK.

window. Click OK to continue (Figure 6-75).
10.On the Register Servers dialog window (Figure 6-76), confirm that the
registration server (chat1/ITSO) and certifier (/ITSO) are correct. Click
Continue to proceed.
Figure 6-76 Register servers

11.On the Register New Server(s) dialog window, enter the following fields
(Table 6-9).
Table 6-9 Register New Servers

Field Value
Server name qp
Server title (optional) QuickPlace server 2

Check In file.
12.Click Set ID File and browse to the location of where the ID file should be
stored (that is, C:\Lotus\Domino\data\ids\servers\qp.id).
13.Click the green check mark button to add the server to the registration queue.
registration.
You have successfully registered the second Domino server. Proceed to the next
section to install the Domino for the QuickPlace machine.
Pre-Domino Install Checklist

and working.
documentation:
software.

more details:
򐂰 This server should have a static IP and host name that are resolvable via
DNS.
Install Domino
To install Lotus Domino on a Windows platform:
installation CD.
Next.

(that is, C:\Lotus\Domino). Click Next.
Attention: Do not check the “Install Domino Partitioned servers” option.


6. On the Choose the setup type that best suits your needs screen
(Figure 6-79), select Enterprise Server and click Next.

7. On the following screen you see will a summary of your selections
(Figure 6-80). After a careful review, click Next to begin the installation.

(Figure 6-81).
Configure Domino
To do this:

4. On the First or additional server screen (Figure 6-83), select Set up an
additional server, and click Next.

Note: In previous steps, we stored the qp’s server ID on chat1’s local file
program, qp’s server ID needs to be made accessible. We could map a
drive to chat1 or simply copy the file from chat1 to qp. For this step we
copy qo’s server ID from chat1’s local file system onto the desktop of qp.
6. On the Provide the registered name of this additional Domino server screen,
click Next.
the following:

8. Then, click Customize, and uncheck the following Domino server tasks:
9. Click OK, then Next to continue (Figure 6-85).
following:
the Domino server in the Host Name (Editable) field (qp.cam.itso.ibm.com
in our test environment).
qualified host name for the Domino server (qp.cam.itso.ibm.com).

12.On the Provide the system databases for this Domino server screen, enter
the following fields (Table 6-10) and click Next.

Field Value
Use a proxy server to connect to the other Leave unchecked.

Domino server
Use a dialup connection Leave unchecked.
Get system databases from CD or other Leave unchecked.

media
confirm the options you have selected, and then click Setup to initiate the

time to initialize properly. (Ten minutes is generally longer than actually
needed, but to be on the safe side, we recommended that the Domino server

following:
services.msc
2. Issue the following commands on the qp’s Domino server console to perform
an immediate synchronization between the two Domino servers:
3. To ensure that these system databases stay in sync, create a connection
document so that these databases will replicate on schedule.

Important: The above steps are mandatory prior to installing QuickPlace. If

the Domino server is not properly initialized the QuickPlace installation could
result in a failure.

At this point we recommend that you perform sanity checks to verify that your
Domino server setup was successful and that its current configuration will not
pose any issues for the anticipated QuickPlace server setup. To validate the
Domino server setup, we recommend the following:
cmd
command (substitute qp.cam.itso.ibm.com for your fully qualified host
name):
ping qp.cam.itso.ibm.com
ipconfig

server (that is, http://qp.cam.itso.ibm.com). You should expect to see the

Database → Open. Type in the fully qualified host name into the Server field
(that is, qp.cam.itso.ibm.com) and click Open. If a list of databases populate
the Database list box, then you have successfully connected to the Domino
server via a Notes client.

Shut down the Domino Server prior to installing QuickPlace in the following
section.
6.9.2 Install QuickPlace

One the Domino server is installed and running, we install QuickPlace. Make
sure that Domino has been stopped prior to installing QuickPlace.
1. Start the install of QuickPlace, and click Accept for the license agreement.
2. Click Next on the Welcome screen.
3. In the Chose Destination Location screen select the folder the Lotus Domino
server QuickPlace will install on top of (C:\Lotus\Domino in our test
environment), as seen in Figure 6-87. Then click Next to begin the install.
Figure 6-87 Install Destination Location

4. Once QuickPlace finishes installing, there are a few configuration steps that
need to be done. Click Next to begin the QuickPlace Server Configuration, as
Figure 6-88 QuickPlace Server Configuration
5. On the Specify name and password screen, specify a local QuickPlace user
who will be used to administer QuickPlace.
Note: This user should not exist in the LDAP directory you will configure
QuickPlace with.

In our test environment, we set the user name to qpadmin and the password
password, as seen in Figure 6-89. Click Next.
Figure 6-89 Specify name and password
6. Click Finish on the Congratulations screen.
6.9.3 Configure QuickPlace Security

When setting up QuickPlace Security, there are two options:
򐂰 Enable QuickPlace against an LDAP directory. (We use TDS in the example
below.)
򐂰 Enable QuickPlace against Native Domino.
Important: In deciding what directory you want to point QuickPlace to, it is

important to note that QuickPlace and Sametime must use the same directory
and protocol. So if Sametime authenticates against Native Domino,
QuickPlace must authenticate against Native Domino for awareness to work.
Because Sametime authenticates against Tivoli Directory Server in our test
environment, we configure QuickPlace to authenticate against the Tivoli
Directory Server as well.

There are two places where you will make configuration changes to set up Lotus
Team Workplace with Tivoli Directory Server:
򐂰 The QuickPlace administration place
򐂰 The qpconfig.xml file
Then you need to test the user directory.
The following sections show the configuration changes and explanations done
for our example. For more detailed explanations for all of the settings in the
QuickPlace administration place and qpconfig.xml file, see the IBM Lotus Team
Workplace Administrator’s Guide, available at:
http://www.lotus.com/ldd/notesua.nsf/find/quickplace

Changing the QuickPlace administration place
To change the QuickPlace administration place, complete the following steps:
1. Go to the main QuickPlace page (http://qp.cam.itso.ibm.com/quickplace)
and click Sign in as the QuickPlace administrator specified while installing
QuickPlace in step 5 on page 439 (qpadmin:password in our test
environment).
2. From the table of contents, click Server Settings, as seen in Figure 6-90.
Figure 6-90 QuickPlace administration place
3. Then click User Directory.

4. Click Change Directory. Fill in the values as follows:
– Type: Set to Domino Directory or LDAP Server depending on what
Sametime authenticates against. We chose LDAP Server, so all other
options below discuss the LDAP server option.

– Name: The server name of the LDAP server (tds.cam.itso.ibm.com).
– Port number: The default is 389, and for an SSL connection it is 636.
– Search base: search base for users (cn=users,dc=itso,dc=com in our test
environment).
– Username: user to bind to directory (cn=root in our test environment).
– New users: Select Allow if you want place managers to have the ability to
add local QuickPlace users that do not exist in the LDAP directory. Select
Disallow new users if you want to restrict the access to each place to
users in your LDAP directory.
The options we chose in our test environment are shown in Figure 6-91.
Figure 6-91 User directory from QuickPlace administration place

5. Click Next. Make sure to do this or your settings will not take effect.
Note: After clicking Next, you should see your user directory along with OK
with Anonymous access, as shown in Figure 6-92 on page 444. If you see
Not OK, click Change Directory and correct the incorrect settings until you
see OK with Anonymous access.
Figure 6-92 Saved user directory: OK with Anonymous access
6. Close the browser window.
Creating the qpconfig.xml file

You will also need to enable more user directory settings for QuickPlace to work
correctly with Tivoli Directory Server. These settings are made in the
qpconfig.xml file. To create the qpconfig.xml file, complete the following steps:
1. Copy the qpconfig_sample.xml file from the Domino data directory.

2. Edit the qpconfig.xml file. Find the User Directory section and remove the
following lines from the beginning and end of the <User_Directory> section,
respectively:

3. Modify the appropriate sections of this section for your user directory. The
changes made to our example are shown in Example 6-14.
Important: When changing the object class, make sure that the value you
use is the exact same case as that saved in your LDAP directory. For
example, in our example, the object class for users is inetOrgPerson.
Setting this value to inetorgperson will cause problems in QuickPlace.
Example 6-14 qpconfig.xml user directory section

<user_directory>
<ldap>
<base_dn>
<group>cn=groups,dc=itso,dc=com</group>
</base_dn>
<schema>
<object_class>objectClass</object_class>
<user>
<object_class_value>inetOrgPerson</object_class_value>
<common_name>cn</common_name>
<display_name>cn</display_name>
<first_name>givenname</first_name>
<last_name>sn</last_name>
<email>mail</email>
<phone>telephoneNumber</phone>
</user>
<group>
<object_class_value>groupOfUniqueNames</object_class_value>
<common_name>cn</common_name>
<display_name>cn</display_name>
<member>uniqueMember</member>
<attribute_in_person_record>ibm-allgroups</attribute_in_person_record>
</group>
<secondary_cn_component enabled="true"/>

<maintain_escape_character enabled="false"/>
</schema>
<search_filters>
<authentication>
<![CDATA[
(|(cn={0})(uid={0}))
]]>
</authentication>
<user_lookup>
<![CDATA[
(&(objectclass=person)(sn={0})(givenname={1}))
]]>
</user_lookup>
<group_lookup>
<![CDATA[
(&(objectclass=groupOfUniqueNames)(cn={0}))
]]>
</group_lookup>
<group_membership>
<![CDATA[
(&(objectclass=groupOfUniqueNames)(uniqueMember={0}))
]]>
</group_membership>
</search_filters>
<member_lookup_ui>
<column_name>
<person>sn, givenname</person>
</column_name>
<column_disambiguate>
<person>dn</person>
</column_disambiguate>
</member_lookup_ui>
<search_ui_hint>
<![CDATA[
( enter <B>last name, first name</B>)
]]>
</search_ui_hint>
<search_ui_index>sn</search_ui_index>
<ssl protocol="3" accept_expired_certs="true"

verify_servername="true"/>

</ldap>
</user_directory>
4. After these changes have been made, restart the HTTP task in Domino for
Team Workplace to recognize them by issuing the following commands on
the Domino console:
tell http q
load http
Testing the user directory

To make sure that the changes you made to the user directory are set correctly,
you can easily test a few settings.
First, test the search functionality by signing into the QuickPlace administration
place as the local QuickPlace administrator. Select Server Settings → Security.
Under either Who can create new place on this server? or Who can administer
this server?, click the Add button. Next click the Directory button and search for
a user and group from your LDAP directory. If an expected user or group is not
returned, double check the directory settings in the Administration Console and
the qpconfig.xml file as previously documented.
Second, test the authentication by signing in to the QuickPlace administration

place as anyone from the LDAP directory. After you sign in, look at the source of
the HTML page and search for the string haiku.canonicalName. You should see
the following in the view source:
haiku.loginName = 'Charles Price';
haiku.userName = 'Charles Price';
haiku.canonicalName = 'uid=cprice/cn=users/dc=itso/dc=com';
haiku.AbbrevUserName = 'Charles Price';
Ensure that the DN listed is correct for your environment. If it is not, single
sign-on will not work, and you need to double check the settings in the
Administration Console and the qpconfig.xml file as previously documented.
At this point you are ready to configure QuickPlace to work with your Sametime
server.
6.10 Configure QuickPlace for awareness, chat, and

meetings
In this topic we discuss how to integrate awareness, chat, and meeting
capabilities for your QuickPlace users.

To configure QuickPlace with Sametime:
1. Configure SSO between QuickPlace and Sametime.
2. Configure QuickPlace for awareness and chat.
3. Configure QuickPlace for online meetings.
Note: You can Configure QuickPlace for awareness, chat, or meetings (or all
of these). You do not have to set up QuickPlace for both awareness and
meetings. However, whatever combination of awareness, chat, and meetings
you decide on, you must configure SSO between QuickPlace and Sametime
as the initial step to integrating the products.
6.10.1 How instant messaging works in QuickPlace

1. Log user into Sametime from QuickPlace client
2. Resolve user list to show awareness status
Log user into Sametime from QuickPlace client

Through QuickPlace, there is one way users are logged into Sametime.
QuickPlace passes the distinguished name of the user signed into QuickPlace
and an LTPAToken generated by the QuickPlace server to the Sametime server
to authenticate and log in the user.

Once you have logged into Sametime, QuickPlace will now send any names in
the difference views of QuickPlace to Sametime requesting the user status (for
example, the Members view) QuickPlace will take the distinguished name of all
users in the place and send this list to Sametime. Sametime will then check the
current status for each user (active, away, do not disturb, not online) and pass
this information back to the page, and the names will show their current statuses,
Figure 6-93 Members view with awareness
Continue with the following sections to configure awareness in QuickPlace:

򐂰 Configure SSO between QuickPlace and Sametime.
򐂰 Configure QuickPlace for awareness and chat.

6.10.2 How online meetings work in QuickPlace
When a user creates a new meeting in QuickPlace, QuickPlace uses the
Sametime Java toolkit to open a connection to the meeting APIs, sending the
information set by the customer for the meeting (meeting name, start time,
duration, tools, and so on). Sametime then creates the meeting and sends back
a URL to attend the meeting. QuickPlace then saves this information in a
document on the calendar for this place, as shown in Figure 6-94.
Figure 6-94 Online meeting details in QuickPlace

The following sections describe how to configure QuickPlace to allow users to
create online meetings in their places:
򐂰 Configure SSO between QuickPlace and Sametime.
򐂰 Configure QuickPlace for online meetings.
6.10.3 Configure SSO between QuickPlace and Sametime

The first step to integrate QuickPlace and Sametime is to get single sign-on
(SSO) working between QuickPlace and Sametime. To configure SSO complete
the following steps:

2. Go to the Web → Web Configuration view, select Web SSO Configuration
for LtpaToken, and click Edit Document, as seen in Figure 6-95.

3. Edit the parameters as follows: Domino Server Names. Add the QuickPlace
server, as seen in “Web SSO configuration document” on page 453.
Figure 6-96 Web SSO configuration document

5. Go to the Configuration → Servers → All Server Documents view.

6. Select the QuickPlace server and click Edit Server, as shown in Figure 6-97.
Figure 6-97 All Server Documents view
7. Click the Internet Protocols - Domino Web Engine tab and set:
– Session authentication: Multiple Servers (SSO)
– Web SSO Configuration: LtpaToken (same as Configuration Name field in
Web SSO document, as shown in Figure 6-97). If the configuration name
is anything other than LtpaToken, you must set this field.

Our test server configuration can be seen in Figure 6-98.
Figure 6-98 Enable MSSSO in server document
8. Click Save& Close.
Multiple Server SSO is not configured on the QuickPlace server. After setting up
Multiple Server SSO, you need to update the login form to work correctly with
QuickPlace.
Update the SSO login form for QuickPlace

To set the correct SSO login form:
1. Create the Domino Web Server Configuration database, domcfg.nsf:
a. From a Notes client, select File → Database → New.
b. We use the following properties:
• Server: qp/Itso (QuickPlace server)

• Title: domcfg
• File name: domcfg.nsf
• Template: Domino Web Server Configuration (7) (domcfg5.ntf). This
template is shown with the Advanced templates, as shown in
Figure 6-99.
Figure 6-99 Creating Domino Web Server Configuration database
c. Click OK.
d. Open the newly created Web Server Configuration database.
e. Click Add Mapping.

f. In the Mapping document, fill in the following:
• Applies to: All Web Sites/Entire Server (You can also restrict SSO to
specific virtual servers.)
• Target Database: quickplace/resources.nsf
• TargetForm: QuickPlaceLoginForm (as shown in Figure 6-100)
Figure 6-100 ‘Sign In’ form mapping
g. Click Save & Close.

2. Update the Notes.ini file:
a. Open the Notes.ini file in the \Lotus\Domino directory of your QuickPlace
server in a text editor.
b. Add the directive NoWebFileSystemACLs=1 to the file. Do not place this as
the last line of the file.
3. Restart the Domino server for the changes to take effect.

Testing single sign-on
Perform the following steps to test single sign-on between WebSphere Portal
and your Domino mail or application server.
1. Sign into QuickPlace (http://qp.cam.itso.ibm.com/quickplace) as an LDAP
user (cprice in our test environment).
Note: If you set up the Domino Web Configuration (domcfg.nsf) database

correctly (as shown in Figure 6-100 on page 457) you should see the login
screen shown when accessing QuickPlace.
Figure 6-101 QuickPlace SSO login page

2. Change the URL to the Sametime server’s stcenter.nsf
(http://imcluster.cam.itso.ibm.com:8082/stcenter.nsf). You should see
Logged in as <your name>, as shown in Figure 6-102.
Figure 6-102 Sametime stcenter.nsf
If you do not see Logged in as <your name>, and instead you see Log on to
Sametime, then SSO is failing between QuickPlace and Sametime, and one of the
above steps was done incorrectly. You will need to correct this before continuing.
You should now be ready to configure QuickPlace for awareness, chat, and
online meetings. If you only want to configure QuickPlace to create meetings in
Sametime, skip the next section and move on to 6.10.5, “Configure QuickPlace
for online meetings” on page 464.

6.10.4 Configure QuickPlace for awareness and chat
To enable online awareness and chat for Team Workplace users, complete the
following steps:
򐂰 Copy Java files required for chat and online awareness.
򐂰 Specify the Sametime server in QuickPlace.
Copy Java files required for chat and online awareness

To copy the Java files required for chat and online awareness, complete the
following steps:
1. Install the Sametime Java Toolkit:
a. Download the Lotus Sametime 7.0 Java Toolkit from the following URL:
http://www-128.ibm.com/developerworks/lotus/downloads/toolkits.html#2
b. Extract the downloaded file into the directory <domino
data>\domino\html\sametime\toolkits\st70javatk
(C:\Lotus\Domino\Data\domino\html\sametime\toolkits\st70javatk in our
example).
2. In the Domino data directory of the Sametime server, create the subdirectory
<domino data>\Domino\html\QuickPlace\peopleonline
(C:\Lotus\Domino\Data\domino\html\QuickPlace\peopleonline in our
example).
3. Copy the STComm.jar, CommRes.jar, and PeopleOnline31.jar files to the
QuickPlace\peopleonline subdirectory you created in the previous step.
These files can be found in the following locations:
– Files from the Instant Messaging and Web Conferencing server:
STComm.jar and CommRes.jar: <domino
data>\domino\html\sametime\toolkits\st70javatk \bin
(C:\Lotus\Domino\Data\domino\html\sametime\toolkits\st70javatk\bin in
our example)
– Files from the QuickPlace server: PeopleOnline31.jar: <Domino
data>\QuickPlace (C:\Lotus\Domino\Data\QuickPlace in our example)
Specify the Sametime server in QuickPlace

To specify the Lotus Sametime server in Lotus QuickPlace, complete the
following steps:
1. In a browser, type the URL of the QuickPlace server administration console
(http://qp.cam.itso.ibm.com/quickplace in our example).
2. Click Sign In and sign in as a QuickPlace server administrator (qpadmin in
our example).

3. Click Server Settings in the table of contents, as shown in Figure 6-103.
Figure 6-103 QuickPlace administration - server settings
4. Click Other Options in the table of contents.

5. Click Edit Options, as shown in Figure 6-104.
Figure 6-104 QuickPlace administration - Other Options

6. Under the Sametime servers heading, make sure that the Sametime chat
cluster URL and port are in the community field. Use the full name of the
server (http://imcluster.cam.itso.ibm.com:8082 in our example), as
Figure 6-105 QuickPlace administration - Edit options
7. Click Next and then sign out of QuickPlace.
Note: The QuickPlace server is not immediately integrated with Sametime

for awareness and chat. Wait a few minutes for the setting to take effect, or
restart the QuickPlace server to integrate it.
Testing online awareness

To test online awareness, complete the following steps:
1. In a browser, type the URL of the QuickPlace server administration console
(http://qp.cam.itso.ibm.com/quickplace in our example).
2. Click Sign In and sign in as a user from the LDAP directory (cprice in our
example). You must log in as an external user. Sametime features are not
available to local users such as qpadmin.

3. Shortly after the page paints a green dot should appear next to the user you
signed in with, as shown in Figure 6-106.
Figure 6-106 awareness in QuickPlace
You are now ready to configure QuickPlace for online meetings.
6.10.5 Configure QuickPlace for online meetings

To enable online meetings for Team Workplace users, complete the following
steps:
򐂰 Copy the Java files required for online meetings
򐂰 Specify the Web Conferencing authentication name
򐂰 Specify Sametime Community server in Team Workplace
Copy the Java files required for online meetings

To copy the Java files, complete the following steps:
1. Copy the STMtgManagement.jar, STCore.jar, ServiceLocator.properties, and
sametime.ini files from the Domino program directory of the Sametime
Meeting server (C:\Lotus\Domino on meeting1.cam.itso.ibm.com in our
example) to the Domino Program directory on the QuickPlace server
(C:\Lotus\Domino on qp.cam.itso.ibm.com in our example).

2. Open Notes.ini from the Domino program directory on the QuickPlace server
in a text editor.
3. Modify the Notes.ini setting JavaUserClassesExt to add
STMtgManagement.jar and STCore.jar, as shown in Example 6-15.
Example 6-15 Notes.ini JavaUserClassesExt section

JavaUserClassesExt=QPJC1,QPJC2,QPJC3,QPJC4
QPJC1=C:\LOTUS\DOMINO\quickplace.jar
QPJC2=C:\LOTUS\DOMINO\log4j-118compat.jar
QPJC3=C:\LOTUS\DOMINO\STCore.jar
QPJC4=C:\LOTUS\DOMINO\STMtgManagement.jar
Specify the Web Conferencing authentication name

To specify the Web Conferencing authentication name, complete the following
steps:
1. Open the qpconfig.xml, located in the domino_data directory
(C:\Lotus\Domino\Data in our test environment) file created in “Creating the
qpconfig.xml file” on page 444 in a text editor.
2. Scroll down to the Sametime section.
Remove the following lines from the beginning and end of the
<Search_Places> section, respectively:

3. Modify the Search Places tags for your environment. Example 6-16 shows
our example.
Example 6-16 The qpconfig.xml file for the Online Meetings section
<sametime local_users=”false” ldap=”true”>
<meetings invite_servers=”true”>
<tools>
<audio enabled=”true”/>
<video enabled=”true”/>
</tools>
<credentials>
<dn>cn=domino admin/o=itso</dn>
<password>passw0rd</password>
</credentials>
</meetings>
</sametime>

Note: The user you specify in credentials <dn> and <password> must
satisfy the following conditions:
򐂰 The user should exist only in the Domino directory of Sametime. The
user should not be listed in the LDAP used by Sametime.
򐂰 The user should be an administrator of Sametime.
To test this, go to:

http://meeting1.cam.itso.ibm.com/stcenter.nsf
Click Administer the Server. For the user name and password that you
enter here, you will need to enter the Domino canonical user name and
password into the credentials section of the qpconfig.xml file.
4. Click Save and Close to save the XML file.
Specify Sametime Community server in Team Workplace

To specify the Sametime Community server in Team Workplace, complete the
following steps:
1. Open a browser and enter the URL of the QuickPlace server administration
console (http://qp.cam.itso.ibm.com/quickplace in our environment).
2. Click Sign In on the left side of the page.
3. Enter the user name and password of a QuickPlace server administrator
(qpadmin:password in our environment).
4. Click Server Settings in the table of contents.
5. Click Other Options in the table of contents.
6. Click Edit Options.

7. Under Sametime Servers, type the full URL of the Sametime meeting server
(http://meeting1.cam.itso.ibm.com in our environment), as shown in
Figure 6-107.
Figure 6-107 QuickPlace administration: other options
8. Click Next.
9. Restart the Team Workplace server for the changes to take effect.

Testing online meetings
To test a user’s ability to create an online meeting, complete the following steps:
1. Sign in to a place you have created on the QuickPlace server.
2. Click New, as shown in Figure 6-108.
Figure 6-108 Create new meeting

3. Select Online Meeting. Click New, as shown in Figure 6-109.
Figure 6-109 Online meeting

4. Give the meeting a name and click Publish, as shown in Figure 6-110.
Figure 6-110 New meeting page details

5. In the In Selected folder field select Calendar. Click Next, as shown in
Figure 6-111.
Figure 6-111 Save meeting to

6. This will take you to the calendar view, as shown in Figure 6-112.
Figure 6-112 Meeting created in calendar

7. Click the meeting you just created. You should see something similar to
Figure 6-113, with a URL to attend the meeting and details about the options
you selected for the meeting.
Figure 6-113 Meeting detail
If you see an error stating that the meeting was not created, see the Technote
Knowledge Collection: QuickPlace Issues Related to Sametime, 1115409, to
help you troubleshoot the problem, available at:

6.11 WebSphere Portal Integration with Sametime
In this topic we discuss how to integrate our Sametime environment into
WebSphere Portal. For the purpose of this book we installed a very basic install
of WebSphere Portal, then configured it with Sametime. In your environment,
you will likely need a more robust portal solution. The following IBM Redbooks
publication will help you to configure Portal Clusters: WebSphere Portal Version
6 Enterprise Scale Deployment Best Practices, SG24-7387. This can be
downloaded at:
As well as the Portal InfoCenter, located at:
http://www-128.ibm.com/developerworks/websphere/zones/portal/proddoc.html#1
To config Portal with Sametime follow the following steps:

1. Install WebSphere Portal and configure Security.
a. Install WebSphere Portal v6.
b. Enable security with realm support.
2. Configure WebSphere Portal for awareness, chat, and meetings.
a. Configure SSO between Portal and Sametime.
b. Enable awareness and chat in WebSphere Portal.
c. Configure Sametime to trust Portal for the Sametime Contact List portlet.
d. Configure the Web Conferencing Portlet.
6.12 Install WebSphere Portal and configure Security

In the following two section we:
򐂰 Install WebSphere Portal.
򐂰 Enable Security with Realm Support.
6.12.1 Install WebSphere Portal v6

The install steps are:
1. The CD should automatically start the installation program, if it does not run
install.bat.
2. Chose a language and click OK.
3. Click Next on the WebSphere Portal Version 6.0 Installer.
4. Accept the software license agreement and click Next.

5. Chose Typical install and click Next.
6. Set the install location (C:\IBM\WebSphere\AppServer in our test
environment), as seen in Figure 6-114, and click Next.
Figure 6-114 Install Location
7. Enter the:
– Cell Name: wps in our test environment
– Node name: wps in our test environment
Note: The cell and node name should be four characters or less.
– Host name: wps.cam.itso.ibm.com in our test environment

8. Enter the WebSphere Application server user name and password
(wasadmin:password in our environment), as seen in Figure 6-115.
Figure 6-115 WAS administrator
9. On the Select to install business process support screen, we selected not to

install it. Click Next.
10.Select the install directory for WebSphere Portal
(C:\IBM\WebSphere\PortalServer in our test environment).
11.Enter the WebSphere Portal administrator user name and password
(wpsadmin:password in our test environment) and click Next.
12.Enter the Windows Administrator name and password. Click Next.

13.Review the products you want to install, as shown in Figure 6-116.
Figure 6-116 Portal is ready to install
14.WebSphere should begin installing. This can take up to four hours depending
on the processor speed and amount of memory.

15.Once Installation completes, you should see the page shown in Figure 6-117.
Figure 6-117 Installation was successful
6.12.2 Enable security with realm support

Refer to the following InfoCenter link for the details of LDAP/security
configuration:
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp
.ent.doc/wpf/intr_ldap.html
Note that this section recommends the use of the enable-security-wmmur-ldap

task because overall Portal now recommends using this task to enable security
so you can have the flexibility to configure realm support and virtual portals in the
future. If you have no plans for these features running this task will not cause a
problem. Or you can choose to implement other security types at this step by
running other tasks, such as enable-security-ldap, and so on.

Ensure that the Portal server has been stopped. Also, because security comes
enabled by default with Portal v6, we are now required to run the disable-security
task before enabling any type of additional Portal security.
1. Stop WebSphere_Portal Server using the following command:
C:\ibm\WebSphere\AppServer\bin>stopserver WebSphere_Portal -user
wasadmin -password
2. Open wpconfig.properties (C:\ibm\WebSphere\PortalServer\config) and set
the WebSphere and Portal admin’s passwords:
WasPassword=password PortalAdminPwd=password
3. Run the following command to disable security:
C:\ibm\WebSphere\PortalServer\config>wpsconfig disable-security
4. After the disable-security task finishes, ensure that the Portal server is
stopped. From C:\ibm\WebSphere\AppServer\bin type:
stopserver WebSphere_PortalServer
5. Browse to the helper file /<wp_root>/config/helpers/ and create a backup
copy of the original security helper file. Edit the security helper file to change
all the LDAP values to match your LDAP configuration (in our environment
IBM Directory Server, as shown in Table 6-11).
Table 6-11 Security helper file properties

Property Description
IBM WebSphere Application Server properties
WasUserid The distinguished name in the LDAP directory for the WebSphere
Application Server administrator. This can be the same name as the
WebSphere Portal server administrator (PortalAdminId).
Example: uid=wasadmin,cn=users,dc=itso,dc=com
WasPassword The password for the WasUserid name.

Example: password
Database properties
wmm.DbPassword Connection information for wmm db
WebSphere Portal server configuration properties

PortalAdminId The distinguished name of the WebSphere Portal server

administrator in the LDAP directory. This name must be a member of
the WebSphere Portal server administrators group defined by the
PortalAdminGroupId property.
Note: This account must include a value for the mail attribute. If the
account does not have a value for the mail attribute, enabling LDAP
security will fail.
Example: uid=wpsadmin,cn=users,dc=itso,dc=com
PortalAdminPWD Password for the WebSphere Portal server administrator.

Note: Do not include the following characters in the password
because they can cause authentication failures:
!@()#$%
Example: password
PortalAdminGroupIdShort The short form of the WebSphere Portal server administrators group
name.
Example: wpsadmins
WebSphere Portal server security properties
LTPAPassword The password used to encrypt and decrypt the LTPA keys.
Example: password
LTPATImeout Time period in minutes at which an LTPA token expires.
Example: 120
SSORequiresSSL Indicates whether single sign-on is enabled only for HTTPS Secure
Socket Layer (SSL) connections. Type false.
If you want to configure SSL, do so only after you have enabled LDAP
security and verified the LDAP directory configuration.
Example: False
SSODomainName The domain name for all single sign-on hosts.
Example: cam.itso.ibm.com
General global security properties
useDomainQualifiedUserNames Indicates whether to qualify user names with the security domain
within which they reside (true or false). The default value (false) is
recommended for most environments.
Example: false

cacheTimeout Timeout for the security cache. The default value (600) is
Example: 600
issuePermissionWarnings Indicates whether during application deployment and application

start, the security run time emits a warning if applications are granted
any custom permissions (true or false). The default value (true) is
Example: true
activeProtocol The authentication protocol for RMI/IIOP requests when security is

enabled. The default value (BOTH) is recommended for most
environments.
Example: both
activeAuthmechanism The authentication mechanism when security is enabled. The default

value (LTPA) is recommended for most environments.
Example: LTPA
LDAP properties
LookAside You can either install with LDAP only or with LDAP using a Lookaside
database. The purpose of a Lookaside database is to store attributes
that cannot be stored in your LDAP server. This combination of LDAP
plus a Lookaside database is needed to support the database user
registry.
Value type:
* true - LDAP + Lookaside database
* false - LDAP only
Default value: false
Example: true
Note: Set to true to use CPP portlets.
LDAPHostName The host name for your LDAP server.
Example: tds.cam.itso.ibm.com
LDAPPort The LDAP server port number. Typically, you type 389. Do not type
636, the port typically used for SSL connections. If you want to
configure an SSL port for LDAP, do so after you have enabled LDAP
security and verified the LDAP directory configuration.
Example: 389

LDAPAdminUId The distinguished name in the LDAP directory that WebSphere Portal
server and WebSphere Member Manager use to bind to the directory.
The level of access given this name determines the level of access
that Workplace Collaboration Services has to the directory. This
name does not have to contain a uid attribute.
Note: Give this account read-only access to prevent users from using
the Sign-up link to register accounts in the directory and from using
the Edit My Profile link to change attributes in the directory, such as
their e-mail addresses.
Example: cn=root
LDAPAdminPwd The password for the name assigned to the LDAPAdminUId property.
Example: password
LDAPServerType Do not change. Leave as IBM_DIRECTORY_SERVER.
LDAPBindID Distinguished name that the WebSphere Application Server uses to

bind to the directory.
Example: cn=root
LDAPBindPassword The password for the LDAPBindID name.

Example: password
Advanced LDAP properties
LDAPSuffix The LDAP suffix for your Directory Server. This property determines
the naming context at which to begin directory searches for users and
groups. Tip: For Domino as LDAP this value is typically empty.
Example: dc=itso,dc=com
LDAPUserPrefix The leftmost attribute of user names in the directory. Type the value
in lowercase characters.
Example: uid
LDAPUserSuffix The naming context at which to begin searches for user names in the
directory.
Example: cn=users
Do not include the LDAPSuffix value as part of this value.

For example, do not type cn=users,dc=itso,dc=com.
LDAPGroupPrefix The leftmost attribute of group names in the directory. Type the value
in lowercase characters.
Example: cn

LDAPGroupSuffix The naming context at which to begin searches for group names in
the directory. Tip: For Domino as LDAP this value is typically empty.
Example: cn=groups
Do not include the LDAPSuffix value as part of this value.

For example, do not type cn=groups,dc=itso,dc=com.
LDAPUserObjectClass The object class used for users.
Example: inetOrgPerson
LDAPGroupObjectClass The object class used for groups.
Example: groupOfUniqueNames
LDAPGroupMember The attribute used for the members of groups.
Example: uniqueMember
LDAPUserFilter The filter used to search for user accounts. The filter must include the
following text: (&(|(<userprefix>=%v)(mail=%v))(objectclass=
<userobjectclass>)), where <userprefix> is the value specified for the
LDAPUserPrefix property and <userobjectclass> is the value
specified for the LDAPUserObjectClass property.
Example: (&(|(uid=%v)(mail=%v))(objectclass=inetOrgPerson))
LDAPGroupFilter The filter used to search for groups accounts. The filter must include
the following text:
(&(<groupprefix>=%v)(objectclass=<groupobjectclass>)), where
<groupprefix> is the value specified for the LDAPGroupPrefix
property and <groupobjectclass> is the value specified for the
LDAPGroupObjectClass property.
Example: (&(cn=%v)(objectclass=groupOfUniqueNames))
LDAPGroupMinimumAttributes Attributes loaded for group searches and related to performance.

Leave this property blank.
LDAPUserBaseAttributes Attributes loaded for user login related to performance. Type

givenName,sn,preferredLanguage. Also type the following values to
allow users, for example, calendar users, to set international time and
date preferences in the Edit My Profile page:
,ibm-regionalLocale,ibm-timeZone,
ibm-preferredCalendar,ibm-firstDayOfWeek,
ibm-firstWorkDayOfWeek

LDAPUserMinimumAttributes Attributes loaded for user searches and related to performance.

Leave this property blank.
LDAPsearchTimeout Value in seconds for the amount of time the LDAP server has to
respond before canceling a request.
Example: 120
LDAPreuseConnection Indicates whether LDAP connections are reused (true or false). If your
environment uses a front-end server to spray requests to multiple
back-end LDAP Directory Servers, type false.
If your environment does not use an intermediate server but instead

authenticates directly with the LDAP Directory Server, type true.
LDAPIgnoreCase Indicates whether LDAP searches are case-sensitive (true or false).
PDM LDAP properties
WpsContentAdministrators The group ID for the WebSphere Content Administrator group.

Example: cn=wpsadmins,cn=groups,dc=itso,dc=com
WpsContentAdministratorsShort The WebSphere Content Administrators group ID.

Example: wpsadmins
WpsDocReviewer The group ID for the WebSphere Document Reviewer group.

WpsDocReviewerShort The WebSphere Document Reviewer group ID.

Example: wpsadmins
WCM LDAP properties
WcmAdminGroupId The group ID for the Web Content Management Administrators

group. This should be the fully qualified distinguished name (DN) of a
current administrative user for the WebSphere Application Server.
For LDAP configuration this value should not contain spaces.
WcmAdminGroupIdShort The Web Content Management Administrators group ID.

Example = wpsadmins
6. Import the contents of the helper file into the wpconfig.properties file by
issuing this command from C:\ibm\WebSphere\PortalServer\config:
WPSconfig -DparentProperties="<full_path_to_helper_file>"
-DSaveParentProperties=true
WPSconfig
-DparentProperties="C:\ibm\WebSphere\PortalServer\config\helpers\sec

urity_ibm_dir_server.properties" -DSaveParentProperties=true in our
environment
7. Open the wpconfig.properties file and make sure that the WpsHostName and
WpsHostPort are correct.
8. Run the following task to validate the LDAP values:
WPSconfig.bat validate-wmmur-ldap
9. Run the following task on the primary node only to configure the LDAP
security settings for both WSAS/WP nodes and the DMGR. This will enable
security on the entire cluster:
WPSconfig.bat enable-security-wmmur-ldap >enable.log
Hint: For enabling LDAP with realm support you cannot use the Configuration
Wizard.
6.13 Configure WebSphere Portal for awareness, chat,

and meetings
In this topic we discuss how to integrate our Sametime environment into
WebSphere Portal.
WebSphere Portal users can integrate with Sametime in two ways:

򐂰 Online awareness and chat.
Online awareness and chat are built into many of the portlets out of the box,
including:
– Sametime Contact List: Portlet displays users’ saved buddy lists and
allows users to add and remove members or groups.
– Who Is Here: dynamic list of people who are on the same page in portal as
you are.
– MyTeamWorkPlace: shows list of places a person is a member of, and
also allows users to search, find current tasks, see what is new, and
opens places from portal.
– Common Mail: portlet that shows a user’s mail from different back-end
mail servers (Domino, Exchange, POP3 or IMAP).
– Notes View: portlet that can show any view in a Domino Web enabled
application.
– People Finder: portlet that allows users to search the corporate LDAP
directory for users in the company using configurable search parameters.

򐂰 Create and search for online meetings.
Creating and searching for online meetings is done through the Lotus Web
Conferences portlet.
6.13.1 How instant messaging works in WebSphere Portal

1. Log user into Sametime from WebSphere Portal.
2. Resolve user list to show awareness status.
Log user into Sametime from WebSphere Portal

In WebSphere Portal, there are two ways users can be logged into Sametime:
򐂰 Pass the Sametime distinguished name of the user with an STToken
generated by Sametime.
This option in not discussed in this book, and typically is only used when
Siteminder is configured in the environment to protect the Sametime servers.
򐂰 Pass the Sametime distinguished name of the user with an LTPAToken
generated by Portal.
With this option, there are two possibilities as to how Portal will determine the
Sametime distinguished name of the user. When Sametime and Portal
authenticate against the same LDAP directory, as is done in our test
environment, Portal simply takes the distinguished name as known by Portal
and passes this to Sametime. You can see how Portal is trying to log the user
into Sametime by looking for the following in a view source of any Portal
page:
writeSTLinksApplet("uid=cprice,cn=users,dc=itso,dc=com", <Token>
,true);
If, however, Sametime and Portal authenticate against different directories
(Sametime authenticates against Native Domino, while Portal authenticates
against Tivoli Directory Server, for example), Portal opens a server-to-server
connection to Sametime, passing the distinguished name it knows
(uid=cprice,cn=users,dc=itso,dc=com) to Sametime. Sametime then resolves
this name in its directory to find the Sametime distinguished name
(CN=Charlie Price/O=itso) and passes this back to Portal. WebSphere Portal
then uses this name to pass to STLinks to log the user into Sametime for
awareness. You can see how Portal is trying to log the user into Sametime by
looking for the following in a view source of any Portal page:
writeSTLinksApplet("CN=Charlie Price/O=itso",<Token>,true);

This process is built through the default theme in Portal, so it does not matter if
you have an awareness-enabled portlet on the page or not — you will be logged
into Sametime once you log into Portal, and users can start chatting with you.
The next section describes how you are able to chat with users.

Once you have logged into Sametime, any portlet that is awareness enabled will
send the list of names to Sametime to determine status. How the list is sent to
Sametime depends on the portlet. If possible, it is best to send the distinguished
name of the user and bypass the resolve task, as is done in the Sametime
Contact List and People Finder portlets. Other portlets will send what you see in
the column specified for awareness, usually common name, as is done in
common mail and notesview.
Continue with the following sections to configure awareness in the WebSphere

Portal:
򐂰 6.13.3, “Configure SSO between Portal and Sametime” on page 489
򐂰 6.13.4, “Enable awareness and chat in WebSphere Portal” on page 499
򐂰 (Optional) 6.13.5, “Configure Sametime to trust Portal for the Sametime
Contact List portlet” on page 506

6.13.2 How online meetings work in WebSphere Portal
When a user creates a new meeting in the Lotus WebConferencing portlet, Portal
open a connection to the meeting APIs, sending the information set by the user
for the meeting (meeting name, start time, duration, tools, and so on). Sametime
then creates the meeting and sends back a URL to attend the meeting. Portal
then displays the meeting detail and URL in the Portal, as shown in Figure 6-118.
Figure 6-118 Online meeting details in Portal
The following sections describe how to configure Portal and Sametime so users
have the ability to create online meetings within Portal:
򐂰 6.13.3, “Configure SSO between Portal and Sametime” on page 489
򐂰 6.13.6, “Configure the Web Conferencing Portlet” on page 512

If you want users to have the ability to do awareness, chat, and online meetings,
complete all sections below.
6.13.3 Configure SSO between Portal and Sametime

To configure single sign-on between WebSphere Portal and Sametime you need
to complete these steps:
1. Create the WebSphere LTPA key.
2. Import the key into Domino.
3. Test SSO between WebSphere Portal and Sametime
Create the WebSphere LTPA key

To do this:
1. On the WebSphere Portal machine, make sure that server1 is started using
the following command from the WAS install directory:
C:\IBM\WebSphere\AppServer\bin>startserver server1
Note: If you have not configured WebSphere Portal with a database other
than Cloudscape™, you will need to stop WebSphere Portal before you
start server1. Otherwise, you will be unable to log in to the WAS admin
console. To stop Portal run the following command:
C:\IBM\WebSphere\AppServer\bin>stopserver WebSphere_Portal -user
wasadmin -password password
2. Go to the WebSphere Administration Console

(http://wps.cam.itso.ibm.com:10001/admin) and log in as the WebSphere
administrator (wasadmin:password in our test environment).

3. Open Security → Global Security, as shown in Figure 6-119.
Figure 6-119 Security - Global Security

4. On the right-hand side open Authentication mechanisms → LTPA, as
Figure 6-120 Authentication mechanisms - LTPA

5. If you cannot remember the password you set when enabling security, type a
password, set timeout to the number of seconds you want the LTPA token
valid for, and provide a name path and file name for the key file (c:\ltpa.key in
our test environment), as shown in Figure 6-121.
Tip: Remember this password, because you must enter it when you import
the LTPA key into the Domino server and when you create LTPA junctions
in Tivoli Access Manager.
Figure 6-121 LTPA Configuration page
6. Click the Export Keys button.

7. Click Save to save the changes to the workspace.
8. Click Save in the next window to apply the changes to the master
configuration.
9. Log out of the WebSphere Administration Console.
10.Copy the key file that you created to a location that is accessible by the
Domino server.

You can now stop server1 with the following command:
C:\IBM\WebSphere\AppServer\bin\stopserver server1 -user wasadmin -
password password
Import the key into Domino

To do this:
2. Go to the Web - Web Configuration view, select Web SSO Configuration for
LtpaToken, and click Edit Document, as seen in Figure 6-122.

3. Select Keys → Import WebSphere LTPA keys, as shown in Figure 6-123.
Figure 6-123 Import WebSphere LTPA Keys
4. Click OK on the This Web SSO Configuration has already been initialized
warning pop-up.

5. Enter the path and name of LTPA key file and click OK, as shown in
Figure 6-124.
Figure 6-124 Enter import file name
6. Enter the password for the LTPA key and click OK.
7. Click OK in the message window that states that the key import is successful.
8. On the Basics tab you should now see WebSphere Information below the
Participation Servers section of the document.

9. If you enabled Security in Portal without realm support you should see the
ldapserver.domain.com:port (tds.cam.itso.ibm.com would show in our test
environment). If this is the case, you can skip to step 10 on page 497. If you
enabled security in Portal as we did in our test environment with realm
support, you will see null for the LDAP Realm, as shown in Figure 6-125.
Figure 6-125 LDAP realm set to null

If this is case (again this is only if you enabled security with realm support),
correct the realm to WMMRealm, as seen in Figure 6-126.
Figure 6-126 LDAP Realm - corrected to WMMRealm
Important: The realm setting is case sensitive, so you must have

WMMRealm. (wmmrealm will not work.)
10.Set the expiration (minutes) to the same number of seconds you set
WebSphere Portal to (120 by default), as shown in Figure 6-126.
11.Click Save and Close.

12.Replicate this change to all servers in the Participating Servers field, and
restart those server for the change to pick up.
At this point SSO should work between WebSphere Portal and Sametime.
Test SSO between WebSphere Portal and Sametime

Perform the following steps to test single sign-on between WebSphere Portal
and your Domino mail or application server.
1. Sign into WebSphere Portal
(http://wps.cam.itso.ibm.com:10038/wps/portal) as an LDAP user (cprice
2. Change the URL to the Sametime server’s stcenter.nsf
(http://imcluster.cam.itso.ibm.com:8082/stcenter.nsf). You should see
Logged in as <your name>, as shown in Figure 6-102 on page 459.
Figure 6-127 Sametime stcenter.nsf

If you do not see Logged in as <your name>, and instead you see Log on to
Sametime, then SSO is failing between Portal and Sametime, and one of the
above steps was done incorrectly. You will need to correct this before continuing.
If you are unable to determine why SSO is failing, the following technote will
provide troubleshooting steps that can help resolve the issue: Troubleshooting
WebSphere Portal, Domino Extended Products, and Domino SSO Issues:
http://www-1.ibm.com/support/docview.wss?uid=21158269
6.13.4 Enable awareness and chat in WebSphere Portal

To set up awareness and chat in WebSphere Portal you need to update the
collaboration services properties file (csenvironment.properties) with connection
information about your Sametime server. The following steps are how we did this
in the test environment:
1. Open CSEnvironment.properties (located in the
<wps_root>\shared\app\config directory,
C:\IBM\WebSphere\PortalServer\shared\app\config in our test environment)
in a text editor.
Example 6-17 shows the settings used in our test environment.
Example 6-17 Settings

##############################################################
#
# SAMETIME properties
# If Sametime is enabled, the required settings must be filled in.
##############################################################
#
# Required settings
#
CS_SERVER_SAMETIME.enabled=true
CS_SERVER_SAMETIME_1.hostname=imcluster.cam.itso.ibm.com
CS_SERVER_SAMETIME_1.version=7.5.1
# The protocol and port that the ST server uses
# to serve up HTML, CSS and JavaScript files, etc.
CS_SERVER_SAMETIME_1.protocol=http
CS_SERVER_SAMETIME_1.port=8082
#
# Optional advanced settings
#

# Class that provides the ST user login name, token, and whether ST is
enabled for this user
#
CS_SERVER_SAMETIME_1.initclass=com.ibm.wkplc.people.tag.AwarenessInitLw
p
# Specify whether to use the LTPA token for logging into Sametime from
the browser.
# If the CS_SERVER_CUSTOM_CRED is enabled and the ssoTokenAttrib is
specified,
# it will be used instead of the LTPA token.
# This option should only be turned on if your Sametime server supports
tokens
# produced by the portal server.
# By default an LTPA token is enabled (preferred).
CS_SERVER_SAMETIME_1.useLTPAToken=true
# The following Sametime settings pertain to the server-to-server

connection
# between the portal server and the ST server. This connection exists
for the
# sole purpose of obtaining Sametime tokens for users. These tokens
are then
# used to log users into Sametime from their Web browsers.
# Port that the ST server app should connect through.

# The default connection is configured to connect through the Sametime
# mux. If you want to connect directly to the server, set the port
explicitly.
CS_SERVER_SAMETIME_1.serverappPort=8082
Note: This is the port used by Portal to connect to the Sametime server to get
a user’s buddy list.
# Sametime reconnect interval (in seconds).

# How often to attempt a reconnect to the Sametime server after being
# disconnected, or not connected.
# Use 0 to indicate that we should not attempt to reconnect.
# If not set, the internal default of 30 seconds is used.
# Lowering this value will allow the portal server to reconnect to the
Sametime
# server more quickly when the Sametime server comes back online.
# However, this may increase the portal server workload and network
traffic.

# CS_SERVER_SAMETIME_1.reconnect=10
# Sametime timeout value (in seconds).

# The maximum amount of time to wait for a response from the Sametime
server.
# If not set, the internal default of 15 seconds is used.
# Lowering this value will decrease the potential amount of time that a
user
# might have to wait to login to the portal.
# However, if the Sametime server is slow to respond or the network is
slow,
# increasing this value will allow portal users to have Sametime
connectivity.
# CS_SERVER_SAMETIME_1.timeout=50
# Specify the name format to use when resolving the WPS

# logged in user with the Sametime server. Note that use of this flag
will
# force the name to be resolved even if the useLTPAToken flag is set to
true.
# This resolved name will be used to login to Sametime.
# Valid values are cn/dn/loginName
# CS_SERVER_SAMETIME_1.nameFormatForResolve=dn
# Specify the character to use to separate distinguished names. This

# character will be used when resolving names with the Sametime server,
# and also for the name used to login to Sametime from the browser.
# Valid values are the single character comma (,) or slash (/)
# CS_SERVER_SAMETIME_1.dnNameSeparator=,
CS_SERVER_SAMETIME_1.dnAuthorSeparator=/
# Tells the person tag what name format to send to Sametime.

# If the Sametime server is configured to accept only the name format
email or dn,
# specify email or dn as the value. If the server is configured to
accept cn, this setting is unnecessary.
# Default is to use the common name.
# Valid values are cn/dn/email.
CS_SERVER_SAMETIME_1.watchnameformat=dn
Note: This is how names are passed from the People Finder to the STLinks
applet to determine status. dn provides the best performance.

# Tells the Sametime server whether the names that the person tag sends
need to be resolved.
# For better performance, set to false.
# Only set to false if you are sure that Sametime will accept the name
format (the CN by default or, if specified,
# the watchnameformat setting) without having to resolve the name
further.
# For greatest compatability with various LDAP setups, the default is
true.
CS_SERVER_SAMETIME_1.resolveNames=false
Note: This can only be uncommented if watchnameformat is set to dn above.

This causes names passed by people finder to stlinks to bypass the resolve
task, causing much less traffic on the LDAP server, and quicker performance
in the people finder.

3. Restart WebSphere Portal for the changes to take effect.

Test awareness in Portal
After Portal has started, awareness should not work in all portlets explained
before except the Sametime Contact List Portlet. There is one additional
configuration step detailed in 6.13.5, “Configure Sametime to trust Portal for the
Sametime Contact List portlet” on page 506. Therefore, we can test awareness
in another portlet like Who Is Here or People Finder. The following steps use
People Finder to test awareness in Portal.
1. Log in to Portal (http://wps.cam.itso.ibm.com:10038/wps/portal) as an
LDAP user (cprice in our test environment), as seen in Figure 6-128.
Figure 6-128 WebSphere Portal Login window

2. Click the People Palette icon at the top right, as shown in Figure 6-129.
Figure 6-129 People Palette

3. In People Finder search for your name (Charles in our test environment), as
Figure 6-130 Search for Charles

4. Your name should appear in the results, and a short time later awareness
should appear, as shown in Figure 6-131.
Figure 6-131 Awareness in People Finder
6.13.5 Configure Sametime to trust Portal for the Sametime Contact

List portlet
For the Sametime Contact List portlet WebSphere Portal connects to the
Sametime server to retrieve a user’s buddy list from the database
(vpuserinfo.nsf) where Sametime stores each user’s list. Sametime must allow
the Portal server to connect. To do this we need to configure the Sametime
server to allow the server application on Portal to connect. The following steps
explain how to do this:
1. From each chat server (chat1 and chat2 in our test environment) open
stconfig.nsf in a Notes client.

2. Open the Community Connectivity document, as shown in Figure 6-132.
Figure 6-132 stconfig.nsf - Community Connectivity

3. In the Community Trusted IPS field add the IP address of the Portal server
(9.33.85.119 in our test environment), as shown in Figure 6-133.
Figure 6-133 Community Trusted IPS
4. Press Esc and save the changes.

5. Close the Sametime Configuration database (stconfig.nsf).
6. Restart the Sametime servers for the change to take effect.

Test the Sametime Contact List portlet
Ensure that awareness is working in Portal before testing the Sametime Contact
List portlet. This portlet will fail unless awareness is working. To set up and test
awareness you need to follow the instructions in 6.13.3, “Configure SSO between
Portal and Sametime” on page 489, and 6.13.4, “Enable awareness and chat in
WebSphere Portal” on page 499.
1. Log in to Portal (http://wps.cam.itso.ibm.com:10038/wps/portal) as an
LDAP user (cprice in our test environment), as seen in Figure 6-128 on
page 503.
Figure 6-134 WebSphere Portal Login window

2. Click Launch - Domino Integration, as shown in Figure 6-135.
Figure 6-135 Launch - Domino Integration

3. Click the My Work tab, as shown in Figure 6-136.
Figure 6-136 Welcome to Domino Integration

4. The Contact List Portlet should appear, showing your current contact list, as
Figure 6-137 Working Contact List Portlet
If the Portlet still fails for you, try restarting WebSphere Portal to reset the
connection to Sametime, and try these steps again.
6.13.6 Configure the Web Conferencing Portlet

The ability to create, search, and attend meetings from Portal is provided through
the Web Conferencing portlet. In this section we configure this portlet to work
with our primary Sametime Meeting server (meeting1.cam.itso.ibm.com).
1. Sign in to WebSphere Portal as the portal administrator (wpsadmin:password

2. Click Launch -- Administration, as shown in Figure 6-137 on page 512.
Figure 6-138 Launch - Administration

3. Open Portlet Management → Portlets, as shown in Figure 6-139.
Figure 6-139 Portlet Management - Portlets
4. Select Title starts with and lotus and click Search.

5. Click the wrench (Configure portlet) icon next to Lotus Web Conferencing, as
Figure 6-140 Configure Lotus Web Conferencing portlet
6. Click the pencil (Edit parameter) icon and configure the following parameters:
– SametimeServerName1: Set to your Sametime meeting server
(meeting1.cam.itso.ibm.com in our test environment).
– SametimeUserName1: Set to Sametime administrator (Sametime
Admin/ITSO in our test environment).

Note: The user you specify in credentials <dn> and <password> must
satisfy the following conditions:
򐂰 The user should exist only in the Domino directory of Sametime. The
user should not be listed in the LDAP used by Sametime.
򐂰 The user should be an administrator of Sametime.
To test this, go to:

http://meeting1.cam.itso.ibm.com/stcenter.nsf
Click Administer the Server. For the user name and password that
you enter here, you will need to enter the Domino canonical user name
and password into the credentials section of the qpconfig.xml file.
– SametimePassword1: password of user set in SametimeUserName1

above.

7. Click OK to save the portlet settings. You should see a message indicating
Successfully saved changes to portlet Lotus Web Conferencing, as
Figure 6-141 Successfully saved Web Conferencing parameters
The portlet should now be ready to allow users to create, search for, and attend
meetings through the portlet. We will use wpsadmin to ensure that the portlet is
configured correctly.
Test Lotus Web Conferencing portlet

To do this:
1. Click Launch → Domino Integration.

2. Select the My Team tab, as shown in Figure 6-142.
Figure 6-142 My Team page
3. In the Lotus Web Conferencing portlet click New Meeting.

4. The portlet opens to the Scheduling a New Meeting page. This is very similar
to going to stcenter and clicking Create a new meeting. Fill out the
parameters you want. The settings for our meeting are shown in Figure 6-143.
Figure 6-143 Schedule a new meeting page

5. Click Save. You should go to the Meeting Details page, where you can see
information about the meeting, with a link to the meeting when it is time to
attend, as shown in Figure 6-144.
Figure 6-144 Meeting details

6.14 Lotus Sametime 7.5.1 and Microsoft Office
integration
There are currently three places where Sametime integration is present within
MS office:
򐂰 In the Outlook client
򐂰 In the Office Suite of Products
򐂰 Using SmartTags
Each of these features is discussed in greater detail in this section:

򐂰 In the Outlook client
The integration is through an added toolbar, which appears at the top of the
client.
Presence awareness is thus available depending on which e-mail is being
viewed or is focused. The integration requires the installation of the full ST
client on the same desktop.
Figure 6-145 illustrates an example of the Sametime toolbar in Outlook 2003.
Built in presence awareness
Figure 6-145 Example of the Sametime toolbar in Outlook 2003
򐂰 In the Office suite, in products such as Word, Excel®, and PowerPoint®,

where the drop-down menu includes the Online Collaboration option. The
integration piece allows the users of Office to share any document that they
are currently viewing in a Instant Meeting session run through Sametime with
someone else who is online. This functionality allows the users to view the
document and to pass control to other users, thus allowing them to make

modifications in a controlled manner. Figure 6-146 shows the Online
Collaboration drop-down menu displaying Sametime sharing options.
Figure 6-146 Online Collaboration drop-down menu displaying Sametime sharing

options

򐂰 Smart Tags, a feature available within Office, allows a name to be tagged and
recognized. When this happens, a right-click drop-down menu appears with
extra Sametime options, such as chat with user, click to call, and so on.
Additional options could be voice chat, alert when available, or any other
options available through the Sametime client. Figure 6-147 illustrates an
example of Smart tag integration based on name Miles Montgomery in a word
document.
Figure 6-147 Smart tag integration based on name Miles Montgomery in word document
6.14.1 Install MS integration with Sametime

Essentially, there are two parts to the installation of MS integration with
Sametime:
򐂰 The first part is a Java Native Interface (JNI™) DLL that comes automatically
with any install of Sametime. This allows for the inside-out integration such as
enabling Smart Tag to read the Outlook Calendar or allowing the chats to be
saved in an Outlook folder.
򐂰 The other part of the integration requires a specific install script
"sametime751_OI_setup.bat", listed here:
@ECHO OFF
REM *** Use this batch file to execute the Sametime Connect 7.5.1
REM *** With the correct command line to enable the MS Office
Integation features
vcredist_x86.exe /Q

sametime-connect-win-7.5.1.exe /V"/Lv install.log
STOFFICEINTEGDLGFLAG=1"
The file VCREDIST_x86.exe is to be found with this script in the same directory
as the Sametime clients. Running this script enables the second and main part of
Office integration to be installed (that is, the Toolbar, Web conferencing, and
Smart Tags).
Install process
In this install, the files were copied to a temporary directory on the Outlook user's
PC and then the file "sametime751_OI_setup.bat" was run from within that
temporary directory (Figure 6-148).
Figure 6-148 Example
After pressing Enter and after a couple of informational pop-up screens, the
following screen appears (Figure 6-149).
Figure 6-149 Choose Setup Language

Select your language and the install shield will startup (Figure 6-150).
Figure 6-150 InstallShield Wizard
Figure 6-151 Windows Installer

Then Sametime will be installed (Figure 6-152).
Figure 6-152 Install location
Click Next.

Accept the terms and license and click Next (Figure 6-153).
Figure 6-153 Launch Information Center

Figure 6-154 Select Sametime features
Figure 6-153 on page 527 illustrates where you choose which of the three MS
integration options you wish to install. You can choose as many as you like. Then
click Next and you are presented with a screen with the size requirements and
the Install button. Click Install and the client will install.
Smart Tags
The MS recognizer technology within Office recognizes various names
depending on the application. In Word, it fires on an English person name.
Sametime is plugged in as a recipient of the name recognition event and uses
the same technology as Quickfind to locate the name and provide the Sametime
options in the right-click drop-down menu.
In Excel, the name recognizer fires on an e-mail address, and if the e-mail
address is in the Outlook Contact address book, then the same recognition event
is fired and Sametime uses this. The also happens in PowerPoint.

Troubleshooting
If you have any problems with the names not being recognized, a quick test is to
try to see whether the name is recognized in the form it is presented in, in
Quickfind within the Sametime client. Sometimes the e-mail address form
displayed in Outlook does not match the directory name/address stored in the
Sametime directory (which is accessed by Quickfind).
6.14.2 Configure MS integration with Sametime

In the four Office products where integration is present, there are a few
configuration options.
MS Outlook
Figure 6-155 is the Outlook client with the toolbar showing presence awareness.
Built in presence awareness
Figure 6-155 Awareness within Outlook

Figure 6-156 shows a list of folders in Outlook after the install has been
completed.
Saved Sametime Transcripts
Figure 6-156 Saved Sametime transcripts
Additionally, note the Sametime transcripts folder that contains the chats that can
be saved to the Outlook folder by a Sametime preferences option (see
Figure 6-157).
Figure 6-157 Chat History

Synchronization of contacts
Figure 6-158 illustrates another option within Outlook, allowing for the
synchronization of contacts between the Outlook and Sametime clients in either
direction.
Figure 6-158 Synchronization of contacts

The following option screen is reached through the Outlook Tools options
drop-down menu option. In the first part, it allows for the synchronization of
Sametime and Outlook contacts, and in the second part it allows for the
Sametime client to be started when Outlook is started. This is a good option, as
the presence awareness with Office only works if the Sametime client is running
at the same time. Figure 6-159 illustrates where you can set these options for the
Sametime client to load automatically.
Figure 6-159 Outlook tools options

Meetings in Outlook
Figure 6-160 illustrates options for creating a new Sametime Meeting. To create
a new meeting, you can use the Actions drop-down menu option when viewing
the calendar in Outlook.
Figure 6-160 Actions

Once this menu item is chosen, this option adds an extra tab (Sametime
OnlineMeeting) to the meeting creation page (Figure 6-161), allowing for an
online meeting (Web conference) to be automatically created on the Sametime
server and linked into this meeting. The meeting text will include a URL link to the
newly created meeting and a note of the meeting password (if created).
Figure 6-161 illustrates the additional tab and the interface for launching an
online meeting.
Figure 6-161 Online meeting scheduling interface

The following option illustrates how you can use the Outlook Tools options
drop-down menu option to enter the meeting creation parameters. If this is not
filled out, then each time an online meeting is created these same parameters
are prompted for at meeting creation (Figure 6-162).
Figure 6-162 Setting default meeting parameters

7
Chapter 7. Deployment phase III -

securing the environment
In the earlier deployment chapters, we have illustrated how to build the
environment. In this chapter we address key security issues, including how to
implement basic Sametime Security, SSL, HTTP Tunnelling, considerations for
dealing with Firewalls, and reverse proxies. Specific topics include:
򐂰 Security
– Basic Sametime Security
– SSL Encryption
• Setting up SSL with a self certificate
• Setting up SSL using Domino as the certificate authority
򐂰 Firewalls
– Ports used by Sametime through firewalls
– Tunneling
򐂰 Sametime and reverse proxies
– Edge reverse proxy - installation and configuration

7.1 Navigating this chapter
This chapter covers the following topics concerning Sametime security, each of
which can be found on the following pages:
򐂰 “Overview of Basic Sametime security” on page 538
򐂰 “SSL encryption” on page 540
– “Install GSKit on Tivoli Directory Server” on page 541
– “Configuring the Domino certificate authority” on page 565
– “Set up SSL on Sametime server with trusted root certificate” on page 584
– “Setting up SSL for Sametime for Web Services” on page 598
– “Setting up SSL to LDAP for QuickPlace” on page 599
򐂰 “Sametime and firewalls” on page 599
򐂰 “HTTP tunneling” on page 609
򐂰 “Protecting Sametime with reverse proxies” on page 618
򐂰 “Caching proxy installation” on page 623
7.2 Security
To secure a Sametime implementation we initially discuss the basic Sametime
security and then SSL. SSL can be is used to encrypt LDAP communications,
Sametime Community Server communications, and Meetings Services.
7.2.1 Overview of Basic Sametime security

This section describes the key security considerations for all of these
components — the server, the Connect client, and the Meeting Room Client.
Securing the Sametime Connect client for desktops

A number of things must be done to properly secure sessions with the Sametime
Connect client. They are discussed in this section.
The client authentication process

The current Sametime 3 Connect client authentication process works as follows:
1. The Sametime client sends a handshake with a public key (a 630-bit key) to
the Sametime server.
2. The server replies with a handshake acknowledgement that contains its
public key (which is recreated every 10 minutes).
3. The client calculates the agreed upon encryption key and sends a login
message to the server with the password, which is encrypted using that key.

4. The server sends the authentication message to the authentication process,
which then tries to authenticate the user.
Saved passwords
The Sametime client password is stored in the connect.ini file if the user chooses
to have the password remembered. Deleting this line in the connect.ini file
prompts the user for his password. The password is encrypted in connect.ini
using the RSA RC2 block cipher, with an encryption key that is 40 bits long. The
encryption process also uses unique information about every machine, thereby
preventing the file from being used on another workstation.
Default security of Sametime communication and saved

information
Sametime chats with Sametime users are automatically secured with encryption
if all participants use Sametime Client 7.5 or later. All chat activity between
Sametime clients and the Sametime 7.5.1 server is always encrypted over the
network using a RSA RC2 block cipher with a 128-bit key, regardless of whether
the Encrypt all meetings setting is selected on the server. However, Sametime
clients from releases prior to 2.5 contain settings that enable users to conduct
unencrypted chats. If a Sametime client from a release prior to 2.5 connects to a
Sametime 7.5.1 server, the chat is either encrypted or unencrypted depending
on the client settings.
File transfers
File transfers are automatically encrypted. This encryption uses the RSA RC2
block cipher with a 128-bit key. This encryption algorithm will not work outside of
the Sametime Connect client.
Instant meetings
For instant meeting security initiated from the client, you need to select the
Secure meeting option to ensure that your meeting is encrypted. Encryption
ensures that no one outside your meeting can read your messages.
Buddy list
The Sametime user’s buddy list is saved in the vpuserinfo (vpuserinfo.nsf)
database. This database is one of the three databases that are created at
installation time and used for deploying Sametime applications. The VPUserInfo
database is responsible for storing a user’s saved buddy list. It also stores the
user-defined settings in the Connect client on information used to restrict who
can see your current status and initiate messaging.
It is important to note that the information in the buddy list is not encrypted when
sent to the server.
Chapter 7. Deployment phase III - securing the environment 539

7.3 SSL encryption
Why is it beneficial to use SSL encryption within your Sametime infrastructure?
Even though Sametime encrypts the information being exchanged between the
server and client it is highly desirable and recommended to set up SSL to the
LDAP server. If SSL is not used, realize that LDAP data is being transmitted in
the clear. Even though your LDAP server is within your intranet, protected from
the outside Internet by firewalls, information could still be intercepted by
someone with your organization. Communicating to an LDAP server by an
unencrypted channel exposes passwords along with other highly confidential
information.
7.3.1 Overview of key steps involved in setting up SSL for Sametime

Two different scenarios are discussed:
򐂰 Setting up SSL using a self-signed certificate
򐂰 Setting up SSL using a certificate from a certificate authority
7.3.2 Setting up SSL using a self-signed certificate

The first scenario describes how to set up SSL between TDS and Sametime
using a self-signed certificate.
The steps for doing this consist of the following:

1. Install GSKit on Tivoli Directory Server.
2. Create the self-signed server certificate.
3. Export the certificate.
4. Configure key file to be used by TDS.
5. Set up SSL on Sametime server with self-signed certificate.

Install GSKit on Tivoli Directory Server
TDS requires IBM Global Security kit 7.0 (GSKit) be installed. Refer to the
following two URLs for detailed information:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.
IBMDS.doc/admin_gd.pdf
1. Insert the Tivoli Directory Server installation CD. From the start menu, click
Run. Navigate to the GSKit subdirectory. Enter the following command:
D:\GSKit\Setup.exe policydirector
2. Click Run (Figure 7-1).
Figure 7-1 Security warning when running GSKit setup.exe

Figure 7-2 GSKit 7 Welcome panel
4. Accept the default installation directory or change. Click Next to continue and
the GSKit software will be installed (Figure 7-3).
Figure 7-3 GSkit 7.0 Installation Directory

5. Click Finish to complete and exit the installation (Figure 7-4).
Figure 7-4 GSKit Installation complete
6. Install IBM JVM Version 1.4.2. See the following URL to download the JVM:
http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=
lenovo&lndocid=MIGR-56888

7. Open the control panel and click the System icon. Click the Advanced tab
and then click environment variables. Click the first New button and enter
the variable JAVA_HOME (Figure 7-5).
Figure 7-5 Setting JAVA_HOME environment variable
8. Delete from C:\Program Files\IBM\Java142\jre\lib\ext\gskikm.jar. Open file

C:\Program Files\IBM\Java142\jre\lib\security and make sure that the
following providers are included (Example 7-1).
Example 7-1 Providers necessary in jave.security file

security.provider.1=sun.security.provider.Sun
security.provider.2=com.ibm.spi.IBMCMSProvider
security.provider.3=com.ibm.crypto.provider.IBMJCE

Create the self-signed server certificate
The simple way to set up SSL for testing purposes is to use a self-signed server
certificate. Later in this chapter we discuss using server certificates from a
certificate authority.
1. From the Start menu chose Run and run the program C:\Program
Files\IBM\gsk7\bin\gsk7ikm.exe (Figure 7-6).
Figure 7-6 IBM Keyman
2. Click Key Database File → New.

3. Enter the name and location of the key file to be created. Then click OK
(Figure 7-7).
Figure 7-7 New key file name and location
4. Enter the stash password and the confirm password and click the check box
to store the stash password in a file (Figure 7-9 on page 547). Then click OK.
Figure 7-8 Stash password

5. Click OK. The key file will be created with a group of common signer
certificates. Pull down the list that contains Signer Certificates and select
Personal Certificates (Figure 7-10 on page 548).
Figure 7-9 Confirmation and location of Stash password

6. Click the New Self Signed button on the right-hand side (Figure 7-11 on
page 549).
Figure 7-10 Personal Certificates

7. Fill in the required information. Make sure that the common name is the fully
qualified DNS name for this host server. Click OK to create the self-signed
certificate (Figure 7-11).
Figure 7-11 Create New Self-Signed Certificate

Figure 7-12 Key File with Self-Signed Certificate
Export the certificate

To do this:
1. You will need to export the certificate that will be used on the Sametime
server. Click Export/Import on the left-hand side.

2. Select key type of PKCS12 and the file name and path and click OK
(Figure 7-13).
Figure 7-13 Export PKSCS12 key
Figure 7-14 Enter password from the exported certificate
3. Exit from the IBM IKeyman utility.

Configure key file to be used by TDS
To do this:
1. Using the TDS Web Administration tool, log into the LDAP server as the
directory administrator. Click the twistie next to Server Administration to
expand the administration options and click Manage Security Properties.
2. Click the SSL option and then click Key Database in the left-hand navigation
pane of the Manage security properties frame (Figure 7-17 on page 555).
Figure 7-15 Manage security properties

3. Click OK and then restart the Tivoli Directory Server (Figure 7-16).
Figure 7-16 Specify key file name and location
Set up SSL on Sametime server with self-signed certificate

In order to set up SSL on the Sametime server you must do the following tasks:
1. Install GSKit on Tivoli Directory Server.
2. Create the CMS key.kdb file.
3. Import the certificate into CMS - key.kdb.
4. Create stkeys.jks file.
5. Import the certificate into JKS - stkeys.jks.
6. Modify sametime.ini.
7. Install the LDAP Internet cross certificate.
8. Enable SSL to LDAP for Community Services.
9. Enable SSL to LDAP for Web Services.

Install GSKit on the Sametime servers
To do this:
1. Locate the GSKit 6.0 on the Sametime Components CD. Open a command
prompt and change the directory to the GSKit directory on the components
CD. Enter the command:
setup.exe GSKit -f1 setup.is.
2. Install the GSKit the same way the GSKit was installed on the Tivoli Directory
Server. Open the control panel and click the systems icon.
3. Click the Advanced tab then click Environment Variables.
4. Click the first new button and enter the variable JAVA_HOME with a value such
as C:\Lotus\Domino\ibm-jre\jre. From the Start menu select Run and run:
C:\Program Files\IBM\gsk6\bin\gsk6ikm.exe

Create the CMS key.kdb file
Create a key file named key.kdb in the Domino Executable directory
(Figure 7-17).
Figure 7-17 Signer certificates for Sametime key.kdb file

Import the certificate into CMS - key.kdb
To do this:
1. Pull down the list containing signer certificates and select Personal
Certificates. Then click Export/Import. Transfer the .p12 file created above
from the TDS. See Figure 7-13 on page 551.
2. Select the action Import, key type PKCS12, and enter the file name and
location of the certificate exported from TDS (Figure 7-18).
Figure 7-18 Import TDS - self-signed certificate into Sametime’s key.kdb
3. Click OK to import the certificate (Figure 7-19).
Figure 7-19 Enter password of the exported certificate JKCS file

Figure 7-20 Key.kdb with the imported certificate
Create stkeys.jks file

Another type of key file will need to be created. This key file is necessary for
business cards and to encrypt Sametime traffic.
1. Click Key Database File → New.

2. Select JKS as the Key Database store. Enter the name and location of the
file. Click OK to create the stkeys.jks file. This file will be created with several
common trusted certificate authorities (Figure 7-21).
Figure 7-21 Create new JKS file
Import the certificate into JKS - stkeys.jks

Pull down the list containing signer certificates and select Personal Certificate.
Repeat the above steps to import the .p12 certificate into this key store.
Modify sametime.ini
Open the sametime.ini file and add the following lines to the [Config] section
(Example 7-2).
Example 7-2 Lines to add to the [Config] section

javax.net.ssl.keyStore=stkeys.jks
javax.net.ssl.keyStorePassword=redb00k
javax.net.ssl.trustStore=stkeys.jks
javax.net.ssl.trustStorePassword=redb00k
Install the LDAP Internet cross certificate

Directory assistance needs to be able to have access to the Internet cross
certificate in order to be able to access the TDS server via SSL:
1. On the Sametime server run c:\lotus\domino\nlnotes.exe. This will run a
Notes client using Sametime’s server ID file.
2. Click File → Security → User Security.

3. Click the plus sign next to Identity of Others (Figure 7-22) and click People,
Services.
Figure 7-22 Notes User Security

4. Click Find more about people.services and click Retrieve Internet Service
Certificate (Figure 7-23).
Figure 7-23 User Security - People, Services
5. Click Connect.
Figure 7-24 Retrieve Internet Service Certificate

6. Click OK (Figure 7-25).
Figure 7-25 Internet cross certificate trust for service
7. Click OK (Figure 7-26). The Internet cross certificate will now have been
added to the primary Domino directory names.nsf.
Figure 7-26 Trust operation succeeded

8. To verify, open the Sametime’s Server primary directory. Click Certificates.
Expand Internet cross certificates, expand the domain ITSO, and then click
the server (Figure 7-27).
Figure 7-27 Internet cross certificate in primary address book
Enable SSL to LDAP for Community Services

To do this:
1. From a browser, access stcenter.nsf on the Sametime server, such as
http://chat1.cam.itso.ibm.com/stcenter.nsf.
2. Click Administer the Server in the left-hand pane, enter the Sametime
administrator’s user name and password, and click OK.
3. Click the plus sign in front of LDAP in the left-hand navigation pane and then
click Connectivity.

4. Click the check box next to “Use SSL to authenticate and encrypt the
connection between the Sametime server and the LDAP server.” Make sure
that the LDAP SSL Port is correct. The default port is 636.
Figure 7-28 LDAP Connectivity
Enable SSL to LDAP for Web Services

To do this:
1. Using the Notes Administrator client, open the Directory Assistant Database
and then edit the LDAP Directory assistant document.
2. Click the LDAP tab and verify that the channel encryption value is set to SSL
and that the port number for SSL is correct.
3. Save the document.

4. Restart the Sametime server.
Figure 7-29 Directory Assistant LDAP settings
7.4 Setting up SSL using certificate from a trusted

authority
Using a self-signed certificate is okay for testing purposes, but we do not
recommend it for production environments. Additionally, some applications do
not work with self-signed certificates. Certificates should be obtained from a
trusted certificate authority such as Verisign. For ease of use, we use a Domino
certificate authority to illustrate the basic steps that need to be performed. We
eliminate the steps to install the GSKit on TDS and Sametime. Refer to the
following sections for further reference on these topics:
򐂰 “Configuring the Domino certificate authority” on page 565
򐂰 “Install GSKit on Tivoli Directory Server” on page 541
򐂰 “Install trusted root certificate into key file” on page 575
򐂰 “Set up SSL on Sametime server with trusted root certificate” on page 584

7.4.1 Configuring the Domino certificate authority
Using a self-signed certificate is okay for testing purposes, but we do not
recommend it for production environments. Additionally, some applications do
not work with self-signed certificates. Certificates should be obtained from a
trusted certificate authority such as Verisign. For ease of use we use a Domino
certificate authority to illustrate the basic steps that need to be performed.
A Domino certificate authority (CA) server hosts the Domino Certificate Authority
application. Most organizations need only a single Domino CA server. We use
our DWA Server dwa.cam.itso.ibm.com to host this application. To set up a
Domino CA server:
1. From the console on the DWA server, check to see whether http is running by
issuing the command show tasks and look for the http task in the list shown in
Figure 7-30.
Figure 7-30 Domino Server tasks

2. If HTTP Server is not listed, load the HTTP task using the load http
command from the Domino server. Create the Domino 5 Certificate Authority
application:
a. Using a Notes client, select File → Database → New. We create a new
database called ITSOca.nsf with the advanced template Domino
Certificate Authority (6) server in our kingston server. Click OK when the
New Database window opens, as shown in Figure 7-31.
Figure 7-31 New Certificate Authority database

b. In the Certificate Authority database, select File → Database → ACL. Edit
the ACL of the Domino 5 Certificate Authority database, as shown in
Figure 7-32:
• Add the names of the administrators who will issue and manage
Internet certificates (Sametime Admin in our example). Assign the
editor with delete access or manager access and the
[CAPrivlegedUser] role to each administrator.
• Set the default access to the author with create documents privilege.
Figure 7-32 Administrator ACL to ITSOca.nsf

c. After making changes to the ACL, close and reopen the database for the
change to take effect. Figure 7-33 shows the initial page for the certificate
authority database.
Figure 7-33 Domino Certificate Authority application
3. Create a CA key ring file and CA certificate.

When you use the Domino administrator to create the CA key ring file, it is
stored by default in the client's data directory. Make sure that you keep the
key ring file in a secure location, especially if you copy it to a shared location.
Only the administrators that you specify should have access to the CA key
ring file and password.
a. Click Create Certificate Authority Key Ring & Certificate.

b. Complete the fields in a similar manner as our example, as shown in
Figure 7-34.
Figure 7-34 Create CA key ring file

c. Click Create Certificate Authority Key Ring. After you review the
information about the key ring file and CA name, click OK.
Figure 7-35 Key ring created confirmation panel
d. Make a backup copy of the certificate authority key ring file, and store it in
a secure location.
4. Configure the CA profile to specify the key ring and mail settings.
The Domino Certificate Authority application profile identifies the CA's key
ring file and specifies the name of the CA server. Domino adds a link to the
CA server when you send a message to clients and server administrators
who request certificates. The clients and server administrators use this
information to determine where to pick up certificates.
a. Click Configure Certificate Authority Profile.
b. If necessary, enter the CA key ring path and file name in the CA Key File
field. By default, Notes looks for the key ring file on the local hard drive.
You can also specify a network drive accessible to other administrators.
c. Enter the TCP/IP DNS name of the server that runs the CA application in
the Certificate Server DNS Name field (kingston.isto.austin.ibm.com in our
example). Domino uses this name to indicate where to pick up signed
certificates in the messages sent to administrators and clients.

d. Configure the remaining fields as you see fit for your environment.
Figure 7-36 shows our example.
Figure 7-36 Certificate Authority profile example
e. Click Save & Close.

5. Set up SSL on the CA server.
Because server administrators and clients use browsers to access the CA
server to request and pick up certificates, use SSL to protect the CA server.
When you set up the CA server for SSL, you create the server key ring file
and request a server certificate. Domino automatically approves the server
certificate and merges the CA certificate as a trusted root.
a. Click Create Server Key Ring & Certificate.

b. Complete the fields in a manner similar to our example, as shown in
Figure 7-37.
Figure 7-37 Create CA server key ring example

c. Click Create Server Key Ring.
d. Enter the CA key ring file password and then click OK. The server SSL
key ring file is created.
e. Copy the server key ring file and put the file in the Domino data directory
on the server. The Domino Certificate Authority application creates the file
locally. However, the server needs the key ring file to use SSL.
f. Close the Domino Certificate Authority application.
Note: If you did not name the key file keyfile.kyr, you can change the name
the Domino server looks for by opening the Server document in the Name
and Address book. Click the Ports → Internet Ports tab and update the
SSL key file name field.
6. Configure the HTTP task for SSL on the Domino CA server:

a. From the Domino Administrator, click Configuration → Servers and open
the Server document for the Domino DWA CA server.
b. Click Ports → Internet Ports → Web.
c. Disable TCP/IP port status and enable SSL port status.
d. Make sure to set the Name & Password field to Yes.
e. Click Save and Close.
f. Restart the Domino server.
Now the Domino Certification Authority server is configured and it will listen for
HTTP requests over port 443 only.
7.4.2 Installing GSKit on Tivoli Director Server

This topic was previously discussed. Refer to 7.4.2, “Installing GSKit on Tivoli
Director Server” on page 574.
The following section discusses using GSKit to create a new CMS key.kdb file on
TDS.

Install trusted root certificate into key file
To do this:
1. Open the browser and access the URL to the Certificate Authority database:
https://dwa.cam.isto.ibm.com/ITSOca.nsf
Figure 7-38 Certificate Authority Web application

2. Click Accept this authority in your server and the Trusted root certificate
will be displayed, as shown in Figure 7-39.
Figure 7-39 Trusted root certificate
3. Highlight the entire certificate and copy it to the clipboard using Crtl+C. Run
Notepad and paste the certificate into the file, as shown in Figure 7-40.
Figure 7-40 Trusted root certificate in Notepad

4. Save the file as .arm file, like c:\temp\itso.arm. Go to the IKeyman application,
Figure 7-41 key.kdb file with signer certificates
5. Click Add on the left-hand side to add a new trusted root authority. Enter the
file name and location of the itso.arm file, as shown in Figure 7-42.
Figure 7-42 Add CA certificate from a file

6. Click OK and then enter the label for this trusted root certificate, as shown
Figure 7-43.
Figure 7-43 Trust Root Certificate Label
7. Click OK and the trusted root will be added to the key.kdb file, as shown in
Figure 7-44.
Figure 7-44 Signer certificates with Domino Certificate Authority

8. Click Create → New Certificate request to create a server certificate
request. Fill in the fields and the location of the certificate request file, as
Figure 7-45 New certificate request

9. Click OK. Open the browser to the Domino Certificate Authority application.
Open the certificate request .arm file created above using Notepad. Copy the
entire certificate request to the clipboard. Then in the Certificate Authority
application fill in the required field and paste the copied certificate into the
certificate request box, as shown in Figure 7-46.
Figure 7-46 Server certificate request
10.Click Submit Certificate Request. The Certificate Authority administrator will

examine the requests and either approve or deny the request. If the request is
approved you will be contacted by e-mail or by phone and given the pickup
ID. Click Pickup Server Certificate in the left-hand navigation pane and
enter the pickup ID, as shown in Figure 7-47.
Figure 7-47 Pick Up Signed Certificate

11.Click Pick Up Signed Certificate.
Figure 7-48 Signed server certificate

12.Highlight the entire certificate including the BEGIN Certificate and End
Certificate line and copy them to the clipboard. Open Notepad and paste the
copied certificate into a text file and save the file as itso.arm. Returning to
Ikeyman on the TDS server, pull down the list that contains personal
certificate requests and select Personal Certificates. See Figure 7-49.
Figure 7-49 Personal certificate requests

13.Click Receive on the right-hand side and enter the file name and location of
the TDS Server certificate, as shown in Figure 7-50.
Figure 7-50 Receive certificate from a file
14.Click OK to add the server certificate to the key.kdb, as shown in Figure 7-51.
Figure 7-51 Key file with server certificate
15.Exit IKeyMan.

16.Using the TDS Web Administration tool, log into the LDAP server as the
directory administrator. Click the twistie next to Server Administration to
expand the administration options and click Manage Security Properties.
Select SSL or SSL only and then click Key database. Enter the key
database path and file name, as shown in Figure 7-52.
Figure 7-52 Enter key file database path and file name
Set up SSL on Sametime server with trusted root certificate

In order to set up SSL on the Sametime server you must do the following tasks:
1. Install GSKit.
2. Create the CMS key.kdb file.
3. Add the trusted root certificate to key.kdb file
4. Add trusted root certificate to stkeys.jks.
5. Modify sametime.ini.
6. Create the Domino key file.
7. Install the certificate authority’s trusted root certificate.
8. Modify server document.
9. Enable SSL to LDAP with trusted root for community services.
10.Enable SSL with trusted root in directory assistance
Install GSKit
Refer to “Install GSKit on the Sametime servers” on page 554.

Create the CMS key.kdb file
Refer to “Create the CMS key.kdb file” on page 555. The key file will be created
with the list of common certificate authorities, as shown in Figure 7-53.
Figure 7-53 Sametime server key.kdb file
Add the trusted root certificate to key.kdb file

To do this:
1. Transfer the trusted root certificate saved in Install trusted root certificate into
key file from the TDS.

2. Click the Add button and fill in the file name and path of the trusted root
certificate, as shown in Figure 7-54, and click OK.
Figure 7-54 Add CA’s trusted root certificate to Sametime’s key.kdb
3. Enter the label for the certificate, as shown in Figure 7-55.
Figure 7-55 Enter label for CA’s trusted root certificate

4. The certificate will be added to key.kdb, as shown in Figure 7-56.
Figure 7-56 key.kdb with CA’s trusted root certificate

Add trusted root certificate to stkeys.jks
To do this:
1. Refer to “Create stkeys.jks file” on page 557. The key file will be created with
the common certificate authorities, as shown in Figure 7-57.
Figure 7-57 Sametime server STKeys.jkx

2. Click the Add button and enter the certificate’s file name and location, as
Figure 7-58 Add CA’s trusted root certificate to Sametime’s stkeys,.kdb
3. Click OK and then enter the certificate’s label, as shown in Figure 7-59.
Figure 7-59 Label for trusted root certificate added to stkeys.kdb

4. Click OK and the trusted root certificate will be added to the stkeys.jks file, as
Figure 7-60 stkey.jks with CA’s trusted root certificate
Modify sametime.ini
Refer to “Modify sametime.ini” on page 558.

Create the Domino key file
Our Sametime servers make use of Domino’s HTTP stack. The Domino HTTP
task will use directory assistance to access the LDAP server. So to set up SSL to
TDS for directory assistance we need to create Domino’s key file and install the
certificate authority’s trusted root certificate.
1. Using the Domino Administrator Client, open server certificate administration
database certsrv.nsf on the Sametime server, as shown in Figure 7-61.
Figure 7-61 Server certificate administration database

2. Click Create Key Ring and fill in the fields, as shown in Figure 7-62.
Figure 7-62 Create key ring

3. Scroll down if necessary and click Create Key Ring. The confirmation dialog
box will be displayed. See Figure 7-63.
Figure 7-63 Key Ring Created

Install the certificate authority’s trusted root certificate
To do this:
1. Click Install Trusted Root Certificate into Key Ring and fill in the fields as
Figure 7-64 Install trusted root
2. Click Merge Trusted Root Certificate into the Key Ring and then enter the
key ring file password, as shown in Figure 7-65.
Figure 7-65 Key ring file password import

3. Click OK and the Merge Certificate Confirmation dialog box will be displayed,
Figure 7-66 Merge Trusted Root Certificate Confirmation
4. Click OK to accept the certificate to be merged, and the dialog box shown in
Figure 7-67 will be displayed.
Figure 7-67 Certificate received into key ring as a trusted root

5. Click OK and then click View and Edit Key Rings in the left-hand navigation
pane and you will see that trusted root has been installed, as shown in
Figure 7-68.
Figure 7-68 View key ring file with trusted root ITSO trusted root authority
Modify server document

To do this:
1. Using the Domino Administrative client click the configuration. Then click the
twistie next to Servers.

2. Click all servers and select the appropriate Sametime server, and then click
Edit. The server document will now be displayed, as shown in Figure 7-69.
Figure 7-69 Server document for Chat1/ITSO

3. Click the Ports tab and then Internet ports, and the SSL setting will be
displayed, as shown in Figure 7-70.
Figure 7-70 SSL setting in server document for chat1/ITSO
4. Make sure that the SSL key file name is correct. You do not need to specify
the path to the key file if that file is in the Domino data directory. If the key file
name is not correct, edit the value and save the document.
Enable SSL to LDAP with trusted root for community services

Refer to “Enable SSL to LDAP for Community Services” on page 562.
Enable SSL with trusted root in directory assistance

Refer to “Enable SSL to LDAP for Web Services” on page 563.
Setting up SSL for Sametime for Web Services

To set up SSL for Web Services, you need to make sure that you created the
keyfile.kyr, as was done in “Create the Domino key file” on page 591. Then
modify the server document as shown in “Modify server document” on page 596,
and also enable SSL for HTTPS.

Setting up SSL to LDAP for QuickPlace
We enabled SSL on our other Sametime servers. To enable SSL on the
QuickPlace server you will need enable SSL using either the self-signed
certificate or the trusted root. Refer to “Install the LDAP Internet Cross
Certificate” on page 485 for self-signed certificates or “Create the Domino
keyfile” on page 513 if using a trusted root certificate. Once the certificate is
imported into the Domino directory or key file, log into QuickPlace as the
QuickPlace administrator. Select server settings and then user directory. Then
click change directory, change the port to SSL port for LDAOP 636, and check
the box next to Check for SSL connection with LDAP User Directory.
At this point, you have now enabled SSL for Sametime.
7.5 Sametime and firewalls

When the words server, extranet, and security are used in the same sentence,
the first thing that comes to mind is a firewall. By definition, a firewall is a security
system consisting of a combination of hardware and software that is used to
prevent unauthorized access to specific network resources.
How can we secure our Sametime server when extending it to the extranet? A
firewall, of course. When placing any server externally (that is, on the Internet),
most if not all enterprises will protect it from hackers by deploying firewalls. The
same requirement goes for Sametime. Due to most common security practices, it
is almost inevitable that a firewall will be placed in front of an external-facing
Sametime server. Therefore, one must make sure that the ports used by
Sametime remain accessible to allow Sametime to continue functioning for
external users as it does for internal users.
7.5.1 Ports used by Sametime through firewalls

The tables in this section list the default ports used by all Sametime services,
including:
򐂰 HTTP Services, Domino Services, LDAP Services, and Sametime intraserver
ports
򐂰 Community Services ports
򐂰 Meeting Services ports
򐂰 Recorded Meeting Broadcast Services ports
򐂰 Audio/Video Services ports

Note: For performance reasons, we recommend that external users should be
allowed to have direct access to the Sametime server and its default ports.
Sametime traffic is encrypted and therefore sniffing/decrypting communication
over these ports should not be a security concern. In addition, Sametime has
built-in logic to detect and prevent denial of service types of attacks for
community connections. Therefore, this should also not raise concern by
leaving Sametime’s default ports open for direct access by external users.
Important: For a summary of the minimum ports recommended to be opened

through a firewall, see the Summary Note boxes at the end of each table.
HTTP Services, Domino Services, LDAP Services, and Sametime

intraserver ports
The following ports are used by the Sametime HTTP Services, Domino
Application Services, and LDAP Services (Table 7-1).
Table 7-1 Ports


Sametime installation, the Community Services multiplexer on the
Sametime server listens for HTTP connections from Web browsers,
Sametime Connect clients, Sametime Meeting Room Clients, and
Sametime Broadcast clients on port 80.

the Sametime installation, the Domino HTTP server listens for HTTP
connections on this port.

Alternate If the administrator allows HTTP tunneling on port 80 during the

HTTP port Sametime installation (or afterward), the Domino HTTP server on
(8088) which Sametime is installed must listen for HTTP connections on a
port other than port 80. The Sametime installation changes the
Domino HTTP port from port 80 to port 8088 if the administrator
allows HTTP tunneling on port 80 during a Sametime server
installation.
Note that if the administrator allows HTTP tunneling on port 80

during the Sametime installation, Web browsers make HTTP
connections to the Community Services multiplexer on port 80, and
the Community Services multiplexer makes an intraserver
connection to the Sametime HTTP server on port 8088 on behalf of
the Web browser.
This configuration enables the Sametime server to support HTTP

tunneling on port 80 by default following the server installation.
Port 389 If you configure the Sametime server to connect to an LDAP server,
the Sametime server connects to the LDAP server on this port.
Port 443 The Domino HTTP server listens for HTTPS connections on this port
by default. This port is used only if you have set up the Domino HTTP
server to use Secure Sockets Layer (SSL) for Web browser
connections.
Port 1352 The Domino server on which Sametime is installed listens for
connections from Notes clients and Domino servers on this port.
Port 9092 The Event Server port on the Sametime server is used for
Port 9094 The Token Server port on the Sametime server is used for
Summary note: For the HTTP Services, Domino Services, LDAP Services,
and Sametime intraserver ports, the following ports should be accessible via
the firewall to allow direct access from an external client to the Sametime
server: 80, 443, and 1352.

Community Services ports
The ports in Table 7-2 are used by the Sametime Community Services. Most of
these ports are configurable.
Table 7-2 Ports used by Sametime Community Services

Port 1516 The Community Services listen for direct TCP/IP connections from
the Community Services of other Sametime servers on this port. If
you have installed multiple Sametime servers, this port must be open
for presence, chat, and other Community Services data to pass
between the servers.
The communications that occur on port 1516 also enable one

Sametime server to start a meeting on another server (or invite the
other server to the meeting).
Port 1533 The Community Services listen for direct TCP/IP connections and
HTTP-tunneled connections from the Community Services clients
(such as Sametime Connect and Sametime Meeting Room Clients)
on this port.
Sametime client uses a unique Sametime protocol over TCP/IP to
establish a connection with the Community Services.
The Community Services also listen for HTTPS connections from the
Community Services clients on this port by default. The Community
Services clients attempt HTTPS connections when accessing the
Sametime server through an HTTPS proxy server. If a Community
Services client connects to the Sametime server using HTTPS, the
data on this connection is not encrypted.

the Sametime installation, the Community Services clients attempt
HTTP-tunneled connections to the Community Services on port 1533
by default.

Sametime installation, the Community Services clients can make
on port 80.
Note that when HTTP tunneling on port 80 is allowed during the

Sametime installation, the Community Services multiplexer listens for
HTTP-tunneled connections on both port 80 and port 1533. The
Community Services multiplexer simultaneously listens for direct
TCP/IP connections on port 1533.

Port 8082 When HTTP tunneling support is enabled, the Community Services
clients can make HTTP-tunneled connections to the Community
Services multiplexer on port 8082 by default. Community Services
clients can make HTTP-tunneled connections on both ports 80 and
8082 by default.
Port 8082 ensures backward compatibility with previous Sametime

releases. In previous releases, Sametime clients made
HTTP-tunneled connections to the Community Services only on port
8082. If a Sametime Connect client from a previous Sametime
release attempts an HTTP-tunneled connection to a Sametime 7.5.1
server, the client might attempt this connection on port 8082.
Summary note: For community services, the following ports should be

accessible via the firewall to allow direct access from an external client to the
Sametime server: 80, 1533, and 8082.

Meeting Services ports
The default ports in Table 7-3 should be open for Sametime Meeting Services.
These ports are configurable.
Table 7-3 Ports

Port 8081 The Meeting Services listen for Sametime protocol over TCP/IP
connections from the Sametime Meeting Room Client on this port.
The screen-sharing, whiteboard, send Web page, and
question-and-answer polling components of the Sametime Meeting
Room Client exchange data with the server over this connection.
For AIX/Solaris, if you are specifying a DNS name for the host name
in “Address for client connections” and in “Address for
HTTP-tunneled client connections,” you must specify a dotted IPv4
address that your fully qualified domain name resolves to.
Steps: Start the Sametime server, log in, and click Administer the
server. Choose Configuration -Connectivity. Enter the dotted IPv4
in the corresponding text fields.
The Meeting Room Client can make the TCP/IP connection directly
to the Meeting Services or through a SOCKS proxy server.
The interactive audio and video components of the Sametime

Meeting Room Client also exchange call control information over a
direct TCP/IP connection on this port.
Sametime client uses a unique Sametime protocol operating over
TCP/IP to establish a connection with the Meeting Services.

the Sametime installation, the Meeting Services clients attempt
HTTP-tunneled connections to the Meeting Services on port 8081 by
default.


Sametime installation, the Meeting Room Client can make
on port 80.
When the Meeting Room Client makes an HTTP-tunneled connection

to the Community Services multiplexer, the Community Services
multiplexer makes an intraserver connection to the Meeting Services
on behalf of the Meeting Room Client. The intraserver connection
occurs on port 8081 by default.
The Meeting Room Client attempts the Sametime protocol over

TCP/IP connection (or direct TCP/IP connection) on port 8081 before
attempting an HTTP-tunneled connection on port 80.
Port 1503 The Meeting Services listen for T.120 connections from the Meeting
Services of other Sametime servers on this port. If you have installed
multiple Sametime servers, this port must be open between the two
servers for the servers to exchange screen-sharing, whiteboard, and
other Meeting Services data.
Port 1516 In a multiple Sametime server environment, a single Sametime

meeting can be simultaneously active on multiple Sametime servers.
This functionality is sometimes called invited servers. Port 1516 must
be open between two Sametime servers to enable one server to
extend a meeting invitation to another server in support of the invited
server’s functionality.
Summary note: For Meeting Services, the following ports should be

Sametime server: 80 and 8081.

Recorded Meeting Broadcast Services ports
The default ports in Table 7-4 are used by the Sametime Recorded Meeting
Broadcast Services. These ports are configurable.
Table 7-4 Ports

Port 554 The Recorded Meeting Broadcast Services listen for Real-Time
Streaming Protocol (RTSP) call control connections over TCP/IP on
this TCP/IP port. (RTSP uses TCP as the transport service.) The
Recorded Meeting client can make the RTSP TCP/IP connection
directly to the Recorded Meeting Broadcast Services or through a
SCOKS proxy server. This port is specific to AIX/Solaris. By default,
a broadcast server will bind only to a single IP address and port. If
multiple IP addresses resolve to the same DNS name, then you will
need to configure a specific IPv4 dotted IP address to use.
Steps: Log in to the Sametime server, click Administer the server,

and choose Configuration-connectivity. In Broadcast Gateway
Address for Client Connections, enter the specific IPv4 Dotted IP
address that you want for the broadcast connection or specify that the
broadcast server should bind to all IP addresses on the server.
(Open meetingserver.ini, and under
[Software\Lotus\Sametime\Broadcast Gateway\DBNL], change the
entry “IPBindAll=0” to IPBindAll=1”.)

the Sametime installation, the Recorded Meeting clients attempt
HTTP-tunneled connections to the Recorded Meeting Broadcast
Services on port 554 by default.

Sametime installation, the Recorded Meeting clients can make
on port 80.
When the Recorded Meeting client makes an HTTP-tunneled

connection to the Community Services multiplexer, the Community
Services multiplexer makes an intraserver connection to the
broadcast gateway on behalf of the recorded meeting client. The
intraserver connection occurs on port 554 by default.
The recorded meeting client attempts the RTSP TCP/IP connection

on port 554 before attempting an HTTP-tunneled connection on port
80.

Dynamic UDP The Recorded Meeting Broadcast Services stream meeting data in
ports RTP format from the server to the client over UDP ports. The specific
UDP ports are chosen randomly by the recorded meeting client and
cannot be controlled by the administrator.
Note that the Recorded Meeting Broadcast Services can also stream
audio and video data to recorded meeting clients. A meeting might
include three separate streams (one each for audio, video, and
screen-sharing/whiteboard data). If the client or server network, or
any network between the Sametime server and the client, does not
allow UDP traffic, the Recorded Meeting Broadcast Services will
tunnel the streamed data over the initial RTSP TCP/IP control
connection that occurs on port 554.
If the call-control connection was established using HTTP-tunneling

on port 80, the client attempts to tunnel the UDP data through the
HTTP-tunneled connection on port 80 or another port specified by the
administrator.
Port 8083 The Recorded Meeting Broadcast Services use this port for internal
control connections between Recorded Meeting Broadcast Services
components. You should change this port only if another application
on the Sametime server is using port 8083.
1–65535 (UDP The Recorded Meeting Broadcast Services can take advantage of
ports for the bandwidth efficiency provided by multicast-enabled networks. If
multicast) your network supports multicast, the Recorded Meeting Broadcast
Services transmit multicast data over UDP ports within the 1 to 65535
range.
Note that multicast uses multicast IP addresses, not the IP address

of the Sametime server.
Summary note: For Recorded Meeting Broadcast Services, the following

ports should be accessible via the firewall to allow direct access from an
external client to the Sametime server: 80, 554, and UDP ports 1–65535.

Audio/Video Services ports
The default ports in Table 7-5 are used by the Audio/Video Services. These ports
are configurable.
Table 7-5 Ports

Port 8081 The Sametime Meeting Room Client establishes a TCP/IP

connection with the Sametime server Meeting Services on this port.
The Audio/Video Services and audio/video components of the
Sametime Meeting Room Client use this connection to the Meeting
Services for call-control functions.
49252–65535 The Sametime Audio/Video Services listen for inbound audio and
(Dynamic UDP video streams from Sametime Meeting Room Clients on a range of
port range) UDP ports specified by the administrator. The UDP ports are selected
by the Sametime Audio/Video Services dynamically from within the
range of ports specified by the administrator.
The administrator can configure the range of available UDP ports

from the MMP UDP port numbers start at/end at settings available
from the Interactive Audio/Video Services networks and ports
settings of the Sametime Administration Tool.
Port 8084 If UDP is unavailable between a Sametime Meeting Room Client and
a Sametime server, Sametime uses this TCP port when attempting
to tunnel the RTP audio and video streams using the TCP transport.
Port 9093 The Interactive Audio/Video Services use this port for internal control
connections between Interactive Audio/Video Services components.
You should change this port only if another application on the
Sametime server is using port 9093.
Summary Note: For Audio/Video Services, the following ports should be

Sametime server: 8081, 8084, and UDP 49252–65535.
For more information about ports used by the Sametime server services, see the
Sametime 7.5.1 Administrators Guide:
http://www-10.lotus.com/ldd/notesua.nsf/find/sametime

7.6 HTTP tunneling
This section describes HTTP tunneling, how it works, how it may affect
performance, and overall best practices for implementing HTTP tunneling.
7.6.1 HTTP tunneling defined

HTTP tunneling is a type of connection that allows all client-to-server traffic to be
transmitted over a single port via the HTTP protocol.
In the world of Sametime, HTTP tunneling allows a Sametime client to

encapsulate all Sametime-related traffic within HTTP headers and transmit it via
the HTTP protocol to the Sametime server over a single port. The server then
strips the HTTP encapsulation headers and redirects the packets to the
appropriate server-side components to process the client requests.
In general, there is only one reason why a Sametime server should enable HTTP
tunneling: to provide restricted clients with the ability to communicate with an
external-facing server. When extending the Sametime infrastructure to the
extranet, there a few security constraints that when enforced may restrict how
clients are able to communicate with the server, such as:
򐂰 End users who are external to the Sametime network may be restricted by
their own internal environments such that they are prohibited from making
any outbound requests on any port other than 80 (for example, proxy servers
may enforce this type of restriction).
򐂰 Corporate security policies may mandate that the Sametime infrastructure is
protected by a reverse proxy server.
򐂰 Corporate security policies may mandate that only a single port be opened on
the firewall to allow for HTTP traffic (default port 80).
With these potential security constraints in mind, one realizes that they do not
have total control over how their environment can be accessed by the outside
world. If you have no control or are not certain what security constraints may be
enforced on external users who may access your Sametime server, then we
recommend that you enable HTTP tunneling.
By enabling HTTP tunneling, you allow your Sametime server to be accessed by

users who may be restricted by security constraints like those described above
(that is, restricted users).

Important: While we recommend that HTTP tunneling be enabled to provide
access to external-facing Sametime servers for those restricted users, we do
not recommend forcing users to use the HTTP tunneling method in order to
communicate with Sametime. By this, we mean that you should not block
access to Sametime’s default ports by using a network device like a firewall.
The direct connection method is the best in terms of performance and should
always be available to those users who can utilize and take advantage of the
direct connection method.
7.6.2 HTTP tunneling at work - Meeting Room Client example

In this section we discuss the Meeting Room Client (MRC) and how it operates
when HTTP tunneling is enabled. By discussing the MRC, we are able to explore
the tunneling process in its entirety.
The following is a high-level overview of the sequence of events that take place
when a user attends a meeting:
1. The MRC applet is downloaded and displayed in an Internet browser on an
end user’s workstation. See Figure 7-71 for an example MRC.
Figure 7-71 Example Meeting Room Client

2. After having downloaded the client, the MRC attempts to connect to the
Sametime server by using one of the available connection methods. To find
the best type of connection to use, the client will iterate, in order, through the
list of connection methods described below:
a. Direct connect
The client attempts to connect and transmit data directly to the server on
the default ports that Sametime is configured to listen on. This is the first
connection method attempted by the MRC and is by far the best method in
terms of performance.
Note: This method is always the first one attempted by the MRC
because it is is the best in terms of performance. Even if HTTP
tunneling is enabled on the server, the client will try the direct connect
method first. If the client is unable to connect directly to Sametime’s
default ports, then it will try the next available connection method.
Sametime’s default ports:

򐂰 Community traffic: directed to ST mux component on port
1533,8082
򐂰 Meeting traffic: directed to T.120 on port 8081
򐂰 Recorded Meeting traffic: directed to Broadcast Gateway on port
554
򐂰 HTTP traffic: directed to HTTP on port 80
b. HTTP tunneling:
This connection method is:
• Only available to clients when the server has enabled it
• The second method used by the MRC to connect to the server if the
direct connect method fails.
If the MRC resorts to this method in order to connect to the server, all of
the Sametime-related traffic (Community, Meeting, and Recorded
Meeting) is encapsulated within HTTP headers and forwarded to the
Sametime server through a single port (80 by default).
In Sametime 7.5.x, the data flow follows the basic HTTP tunneling
connection model as in older Sametime releases. However, the
communication or, more accurately, the dialect between the client and

server has been tweaked for better performance. This style of
communication is called hybrid polling. Hybrid polling, in general, works as
follows:
i. The client connects to the server over a single port to send requests.
ii. Clients holds the connection open waiting for data from the server.
iii. If no data is forthcoming, the connection closes after 30 seconds.
iv. If data is flowing, the connection closes 30 seconds after the last data
is received.
v. Immediately repeat.
Again, this style of communication has been introduced to improve
performance from both a server-side and a client-side perspective.
Tip: Audio/video (A/V) data is treated differently with respects to tunneling.

While A/V data can be tunneled, it cannot be HTTP tunneled. Essentially, this
means that A/V data cannot be encapsulated within HTTP headers and
subsequently transmitted via the HTTP protocol.
Therefore, it is important to note that if A/V is configured to tunnel over port 80

and a firewall is deployed, packet-filtering may prevent A/V from working
properly. If packet-filtering is configured to only allow HTTP-type packets
through the firewall, then A/V traffic will be blocked.
In summary, the HTTP tunneling method is available to all Sametime clients only
when the Sametime server is configured to allow it. When configured, it is the
second method utilized by the client to connect to the server. The HTTP
tunneling method is only provided as a fallback option for when the direct
connect method fails. We highly recommend allowing all clients (internal and
external) to connect directly to the Sametime server for optimal performance
(that is, do not force users to use the HTTP tunneling method by blocking access
to Sametime’s default ports).
7.6.3 HTTP tunneling’s impact on performance

HTTP tunneling has a significant impact on performance due to the way it is
designed to work. HTTP tunneling is designed to allow restricted clients to
communicate with the server over a single port (that is, default port 80).
There are a countless number of variables that affect the performance of a

meeting from an end-user perspective. Some are out of your control, while others
are not, such as network congestion, intermediary network appliances
(forward/reverse proxy servers, firewalls), the number of concurrent meetings on

the server, the number of concurrent users on the server, the tools/activities
being used within a meeting, and, most importantly, the type of connection being
used by the MRC to connect to the server.
Web conferences (Sametime meetings) allow for real-time collaboration amongst

users in a variety of different ways, and its success as a collaborative tool rides
on its ability to provide real-time collaboration. If the performance of a Web
conference is severely compromised, it defeats the objective of real-time
collaboration.
Within a meeting (MRC), there are a variety of tools that users can use to
collaborate with each other. For the most part, these tools rely heavily on the
network and its ability to handle the amount of data being communicated
between the clients and the server. Examples of some tools are:
򐂰 Audio/video
򐂰 Application sharing
򐂰 Screen sharing
򐂰 Slides/whiteboard
򐂰 Group chat/user polling

Because these tools rely so heavily on the network and its bandwidth, any
variables that can negatively affect the network will almost always negatively
affect the performance of Sametime and its meetings. For example, the
overhead introduced by the HTTP tunneling methodology can, in certain
situations, negatively affect the performance of meetings from an end-user
perspective. To understand this further, let us examine Figure 7-72.
Client Request
Server Response
Figure 7-72 HTTP tunneling - hybrid polling
The following sequence describes the flow of information within the tunnelling
process (refer to the sequence numbers in Figure 7-72).
1. After the direct connect method fails, the Meeting Room Client resorts to the
HTTP tunneling method (again, only when tunneling is available).
2. All Sametime-related traffic is encapsulated within HTTP headers and
directed to the Sametime server over the tunneled port (80 is the default port).
3. Sametime’s ST mux server component receives the request and strips the
HTTP encapsulation wrapper.

4. ST mux analyzes the packet and determines which server component to
route the packet to.
5. ST mux receives the response from the server-side components.
6. ST mux encapsulates the response within HTTP headers, and then responds
back to the client.
From the diagram above, you can get an idea as to how much overhead the
HTTP tunneling introduces compared to the direct connection method. If the
situation is just right, this additional overhead can be enough to negatively affect
the end-user experience within meetings.
Note that HTTP tunneling does not affect all environments equally. As stated
before, there are so many different variables that can affect the network, which in
turn can affect the end-user experience. Therefore, if you plan to force the usage
of the HTTP tunneling method for external users (that is, block access to
Sametime’s default ports other than port 80 via a firewall), we recommend that
you fully test the performance of meetings before rolling out to production. With
all the different variables, there are many ways to tweak and optimize the
performance of the HTTP Tunneled connections.
7.6.4 Best practices for HTTP tunneling

HTTP tunneling is a great feature in that it allows restricted clients (those that can
only communicate to the server through a single port due to enforced security
constraints) to connect to your Sametime environment. With that said, however,
HTTP tunneling can come at a cost. Its overhead in combination with other
factors can severely hamper end users’ experiences, which can impede
productivity.
When extending Sametime to the extranet, you typically have no control over
external users’ internal environments and/or security constraints. For example,
one of ITSO Corporations’s business requirements requires the ability for internal
ITSO Corporation employees to collaborate with business partners, contractors,
mobile employees, and other external users. Because ITSO Corporation has no
control over how these users can gain access to the Internet, we must configure
ITSO Corporation’s environment to allow for all types of users (restricted or not)
to gain access to our Sametime infrastructure. To do this we follow these basic
guidelines:
򐂰 Do not force users to use the HTTP tunneling method by blocking direct
access to Sametime’s default ports. From a performance perspective, you
should allow non-restricted clients to connect directly if they can.
򐂰 For external-facing Sametime servers, enable the HTTP tunneling feature to
allow access for restricted users.

򐂰 If you enable HTTP tunneling, you should following the recommendations in
7.6.6, “HTTP tunneling tweaks” on page 617.
Security concerns: Do you or your network administrators have security

concerns about opening more than a single port to allow for direct access to
Sametime? You should not.
Even though the firewall must open additional ports to allow for direct
connections to Sametime, all the Sametime traffic is encrypted by a 128-bit
RC2 encryption algorithm. In addition, 7.5.x Sametime servers include logic to
prevent denial of service-type attacks.
7.6.5 HTTP tunneling and SSL

When discussing security, SSL is a topic that always comes up. Many
administrators need to make sure that traffic between the client and the server is
encrypted, especially for traffic outside the internal networks. Because of the
potential for sensitive data to be exposed, many administrators are required to
set up some type of encryption for external traffic.
Before getting too deep in this section, let us point out one important thing:
Sametime traffic (not including HTTP traffic) cannot be encrypted with SSL.
Sametime traffic is already encrypted with a 128-bit RC2 encryption algorithm,

and therefore there is no need to encrypt Sametime using SSL. Thus, there is no
way to encrypt Sametime traffic with SSL. The only traffic that can be encrypted
with SSL is HTTP-related traffic.
Well then, what about HTTP tunneling? Can I enable HTTP tunneling and
HTTPS at the same time? In short, the answer is yes. However, to get a better
understanding of how that can be done, let us go over the following points:
򐂰 Sametime traffic cannot be encrypted with SSL, and therefore it is not
designed to understand SSL-encrypted traffic.
򐂰 In the most simple of configurations when HTTP tunneling is enabled and
utilized, the ST mux component front ends all traffic including HTTP traffic.
򐂰 To encrypt HTTP traffic with SSL, you must set up SSL on the Domino Web
server on which the Sametime server resides.
򐂰 If HTTPS is enabled and you attempt to tunnel Sametime traffic, the ST mux
component will receive SSL-encrypted HTTP traffic (that is, HTTPS traffic).
Because Sametime is not designed to understand SSL-encrypted traffic, ST
mux will not understand how to handle the traffic and therefore this
configuration will not work.

򐂰 If Sametime traffic cannot be encrypted with SSL, how can you enable SSL
for HTTP traffic (that is, HTTPS) and tunnel at the same time? Essentially,
there are two methods for implementing this:
– Configure Sametime to tunnel over port 80 and at the same time enable
HTTPS over port 443. Do not set the server-side setting to redirect to SSL.
Essentially, you will allow access to both port 80 and 443. By doing this, all
Sametime-related traffic will go over port 80, which is already encrypted,
so there is no need to worry about sensitive data being exposed. HTTP
traffic will be encrypted with SSL. If you enable both 80 and 443, can users
access the Web server over port 80? Yes they can, but at this time, the
only information that you need to encrypt is the login request (user
name/password) since all of the meeting room data is already encrypted.
This can be done with some simple design changes in the online meeting
center.
– Configure at the very least two host names with different IPs on the server.
Reserve one host name for the Domino Web server (IP1) and the second
host name for Sametime (IP2). You can then configure the server such
that all Domino HTTPS traffic is routed to the Domino host name over port
443, and Sametime traffic is routed to the Sametime host name over port
80.
Finally, you could do this another way, but we do not recommend this unless
you are required to do it. You can enable HTTPS and redirect to SSL on the
Domino Web server. But then you have to configure Sametime such that it
can talk to the Domino Web server over SSL. By doing this, you are only
encrypting between the servlets and the Domino Web server (intra-server
communication). This has the ability to affect meeting performance and we do
not recommend it from a performance perspective.
7.6.6 HTTP tunneling tweaks

The following recommendations are also possible to further improve HTTP
Tunnelling performance:
򐂰 Add extra host names and bind Sametime to multiple host names.
򐂰 To improve I/O, offload HTTP requests (typically ST mux has to handle the
HTTP traffic). If you bind to a separate host name, then the ST mux does not
have to handle HTTP traffic, which is a big bonus.
򐂰 Do not enable SSL for Sametime unless you force users to use HTTPS. This
forces the Sametime servlets to communicate with the Sametime server
using SSL, which ultimately affects performance.

7.7 Protecting Sametime with reverse proxies
When configuring Sametime to work behind a reverse proxy you must configure
Sametime to use HTTP tunneling. To configure HTTP tunneling, or for more
details on how HTTP tunneling works, see 7.6, “HTTP tunneling” on page 609.
The following sections explain how to configure Sametime and the Reverse
proxy once tunneling is configured:
򐂰 7.7.1, “Chat and awareness considerations with reverse proxies” on page 618
򐂰 7.8, “Introduction to the IBM Edge Server caching proxy” on page 620
򐂰 7.8.1, “Reverse proxy (IP forwarding)” on page 620
򐂰 7.8.2, “Using multiple caching proxy servers” on page 623
Before we configure the servers, there are some limitations that you need to be
aware of when working with reverse proxies and Sametime.
7.7.1 Chat and awareness considerations with reverse proxies

When a user logs in to a Sametime chat community, either with the Connect
client or an STLinks client (WebSphere Portal, QuickPlace, DWA, and so on), a
persistent connection is opened between the client and the browser. This
connection is what is used by the Sametime server to send status update and
chat messages to users who are signed into Portal. The problem that we run into
with some reverse proxies is that these persistent connections require a thread
from the reverse proxy. Therefore, for example, if you have 50 people signed into
Sametime, 50 threads will be in a busy state holding that thread on the reverse
proxy. If there are only 50 active threads in the reverse proxy, the next person
that attempts to access Sametime, their client will appear to hang, and it will
never reach the server, as the reverse proxy will not have active threads to
process the request. Before deploying a reverse proxy in a Sametime
environment, first ensure that the reverse proxy uses a virtual thread model,
where it will work well with persistent connections, and only use a thread to pass
information back and forth from client to server, and not to simply hold on to a
thread for a persistence connection that is not currently doing work. If your
reverse proxy does not support this type of thread model, ensure that the
maximum number of concurrent users will never go over the number of threads
you can run on your reverse proxy. Remember that the maximum number of
threads allowed on your reverse proxy can vary depending on type, OS, machine
type, processor, memory, and so on. With the number of threads, also remember
the load of other applications (Websphere Portal, QuickPlace, and DWA, for
example), and the expected load that will have on the reverse proxy as well.

A common environment with Sametime working behind the corporate reverse
proxy is shown in Figure 7-73.
WebSphere
Portal
Reverse
Internet QuickPlace
Proxy
Browser
Sametime
Internal Firewall External Firewall
Figure 7-73 Sample reverse proxy configuration
If you only want users to use awareness and chat from their client, a better
environment would be to remove the reverse proxy from protecting Sametime,
and use an STmux in the DMZ to act as the reverse proxy for Sametime. This
can be seen in Figure 7-74.
WebSphere
Portal
Reverse
Proxy
QuickPlace
Internet
Browser
MUX
Sametime
Internal Firewall External Firewall
Figure 7-74 Reverse proxy and mux
If you decide to configure your environment as described in Figure 7-74, the

configuration steps would not change from our test environment shown and
configured in the following chapters:
򐂰 Chapter 5, “Deployment phase I - implementing Meeting Services” on
page 281

򐂰 Chapter 5, “Deployment phase I - implementing Meeting Services” on
page 281
򐂰 Chapter 6, “Deployment phase II - integration with other products” on
page 329
򐂰 Chapter 7, “Deployment phase III - securing the environment” on page 537
To create this configuration, you would simply place the load balancer and mux
server in the DMZ, and the Sametime server in the corporate intranet. If,
however, you decide to protect your Sametime chat and meeting servers with a
reverse proxy (as shown in Figure 7-73 on page 619), the following section
explains how to do this with the WebSphere Edge caching proxy.
7.8 Introduction to the IBM Edge Server caching proxy

The caching proxy component of WebSphere Application Server Edge
Components V6 is both a caching proxy server and a content filter. Within the
context of this book we discuss the functionality of the caching proxy server. It
can be used to provide a robust, efficient proxy server with an optional cache.
The caching proxy server can be configured to operate as:
򐂰 A forward proxy server for clients
򐂰 A transparent proxy server for clients
򐂰 A reverse proxy server for other back-end servers
The caching proxy, when configured as a reverse proxy server, acts on behalf of
one or many back-end servers. A reverse caching proxy intercepts client
requests arriving from the Internet, forwards them to the appropriate back-end
server content hosts, caches the returned data (if requested to), and delivers that
data to clients across the Internet. The cached data can satisfy a request for the
same pages at a later time. In this manner, a reverse proxy can reduce the
amount of traffic and processing that a back-end server must perform to satisfy
duplicate Internet requests for data, while at the same time improving the
response time for those requests
7.8.1 Reverse proxy (IP forwarding)

IP-forwarding topologies use a reverse proxy server, such as the caching proxy,
to receive incoming HTTP requests and forward them to a Web server. The Web
server forwards the requests to the application servers for actual processing. The
reverse proxy returns completed requests to the client, masquerading the
originating Web server.

If a client then requests the same data the next time, it will not be sent to the
back-end server for processing, but instead will be served from the cache. This
prevents unnecessary back-end processing for the same data requests, thus
providing better response times.
There are several reasons for installing reverse proxy servers:

򐂰 Security: The proxy server is an additional layer of defense and therefore
protects the Web servers further up the chain.
򐂰 Encryption/SSL acceleration: When secure Web sites are created, the SSL
encryption is sometimes not done by the Web server itself, but by a reverse
proxy that is equipped with SSL acceleration hardware.
򐂰 Load distribution: The reverse proxy can distribute the load to several
servers, each server serving its own application area. In the case of reverse
proxying in the neighborhood of Web servers, the reverse proxy may have to
rewrite the URLs in each Web page (translation from externally known URLs
to the internal locations).
򐂰 Caching static content: A reverse proxy can offload the Web servers by
caching static content, such as images. Proxy caching of this sort can often
satisfy a considerable amount of Web site requests, greatly reducing the load
on the central Web server.

Client
Internet
80
443
Firewall
Caching Proxy
Reverse Proxy
Firewall
80
Load
Balancer
1533 1533 1533

8082 8082 8082

MUX1 MUX2 MUX3
1516 1516
1352
1516
Server Server
ST
CLUSTER
Figure 7-75 Overview of Sametime Infrastructure through a reverse proxy

7.8.2 Using multiple caching proxy servers
Multiple caching proxy servers can be configured to increase your site
performance, compared with a single caching proxy at peak load times. The load
balancer dispatcher component can be used to distribute the load to the caching
proxy servers
7.9 Caching proxy installation

As with the other Websphere Edge Component products, the caching proxy can
be installed using the wizard provided or by using the operating system tools. We
describe the installation here in a Windows server using the wizard. Prior to
installing on Windows, it is first necessary to ensure that a Java Runtime
Environment 1.4.2 (or later) has been installed.

The WebSphere Edge Components installation media provides a wizard for all
platforms, so the installation is similar for all supported operating systems.
1. Mount the installation media and start LaunchPad by running launchpad.bat
(on Windows servers) or launchpad.sh (on Unix servers). The LaunchPad
window opens, as shown in Figure 7-76.
Figure 7-76 Installation Overview
2. Click Launch the installation wizard for Websphere Application Server -

Edge Components.
3. Client Next on the Welcome Screen and click Yes to accept the product
license.

4. In the Component Selection window select the component you want to install.
Select the Caching Proxy check box and click Change Subcomponents, as
Figure 7-77 Component Selection
5. The Subcomponent Selection window is opened. Select the subcomponents

that you want to install. The caching proxy base server subcomponent is
mandatory. By default, all subcomponents are selected. Click OK to return to
the Component Selection window.
6. The default installation path is C:\Program Files\IBM\edge\cp. If you want to
install to a different path, click Change Folder and enter the path. Click Next
to continue the installation.

7. Make sure that the selected options are correct in the Installation Selection
Summary and click Finish to start the installation (Figure 7-78).
Figure 7-78 Installation Confirmation

8. At the end of the installation you have the option to reboot the server
(Figure 7-79). Make sure that you do so before using the product.
Figure 7-79 Setup Complete
7.10 Configuration of IBM Edge Server caching proxy

The configuration of the IBM Edge Server caching proxy is done through the file
ibmproxy.conf (located in C:\Program Files\ibm\edge\cp\etc\en_US directory).
The settings for the external meeting server (meeting2.cam.itso.ibm.com) in our
test environment are shown in Example 7-3.
Example 7-3 Proxy settings for Edge server with Sametime

Proxy /st03/communityCBR/CC.31*
http://meeting2.cam.itso.ibm.com/communityCBR/CC.31* :80
Proxy /st03/CommunityCBR/CC.35*
http://meeting2.cam.itso.ibm.com/CommunityCBR/CC.35* :80
Proxy /st03/sametime/* http://meeting2.cam.itso.ibm.com/sametime/* :80
Proxy /st03/MeetingCBR* http://meeting2.cam.itso.ibm.com/MeetingCBR*
:80
Proxy /st03/BroadcastCBR*
http://meeting2.cam.itso.ibm.com/BroadcastCBR* :80

Proxy /st03/stcenter.nsf*
http://meeting2.cam.itso.ibm.com/stcenter.nsf* :80
Proxy /st03/names.nsf* http://meeting2.cam.itso.ibm.com/names.nsf* :80
Proxy /st03/* http://meeting2.cam.itso.ibm.com/* :80
Proxy /st03/QuickPlace/*
http://meeting2.cam.itso.ibm.com/QuickPlace/* :80
Redirect /st03/* http://rp.cam.itso.ibm.com/st03/* :80

Redirect /st03
http://rp.cam.itso.ibm.com/st03/stcenter.nsf :80
ReversePass http://meeting2.cam.itso.ibm.com/st03/*
http://rp.cam.itso.ibm.com/st03/*
ReversePass http://meeting2.cam.itso.ibm.com/st03*
http://rp.cam.itso.ibm.com/st03*
ReversePass http://meeting2.cam.itso.ibm.com/*
http://rp.cam.itso.ibm.com/st03*
Add corresponding entries in the Proxy section and restart the caching proxy. If
you want users to access the reverse proxy over SSL, then HTTP to the
Sametime server, use the settings shown in Example 7-4.
Example 7-4 Access the reverse proxy over SSL

Proxy /st03/communityCBR/CC.31*
http://meeting2.cam.itso.ibm.com/communityCBR/CC.31* :443
Proxy /st03/sametime/* http://meeting2.cam.itso.ibm.com/sametime/* :443
Proxy /st03/MeetingCBR* http://meeting2.cam.itso.ibm.com/MeetingCBR*
:443
Proxy /st03/BroadcastCBR*
http://meeting2.cam.itso.ibm.com/BroadcastCBR* :443
Proxy /st03/stcenter.nsf*
http://meeting2.cam.itso.ibm.com/stcenter.nsf* :443
Proxy /st03/names.nsf* http://meeting2.cam.itso.ibm.com/names.nsf* :443
Proxy /st03/* http://meeting2.cam.itso.ibm.com/* :443
Proxy /st03/QuickPlace/*
http://meeting2.cam.itso.ibm.com/QuickPlace/* :443
Redirect /st03/* https://rp.cam.itso.ibm.com/st03/* :443

Redirect /st03
https://rp.cam.itso.ibm.com/st03/stcenter.nsf :443

ReversePass http://meeting2.cam.itso.ibm.com/st03/*
https://rp.cam.itso.ibm.com/st03/*
ReversePass http://meeting2.cam.itso.ibm.com/st03*
https://rp.cam.itso.ibm.com/st03*
ReversePass http://meeting2.cam.itso.ibm.com/*
https://rp.cam.itso.ibm.com/st03*

8
Chapter 8. Sametime Client deployment

considerations
In the previous chapters we demonstrated how to identify your user population;
examine your network topology; and design, install, and configure your
Sametime servers. Now it is time to look at the Sametime Clients that are
available. In this chapter we will provide information about the following
򐂰 Client types - new features and functions
򐂰 Client deployment options

8.1 About Lotus Sametime 7.5.1
Millions of people worldwide use IBM Lotus Sametime 7.5.1 capabilities every
day to gain instant access to people and information, bring together
geographically dispersed teams, and improve individual and team productivity.
Lotus Sametime 7.5.1 provides instant, anytime access to people and
information through three on demand concepts:
򐂰 Presence awareness
򐂰 Business instant messaging
򐂰 Web conferencing
Lotus Sametime now uses audio integration from leading teleconferencing and
telecommunications providers to offer a single interface to both audio and Web
conferencing, as well as click-to-call functionality directly from the Lotus
Additionally, Lotus Sametime 7.5.1:

򐂰 Provides easy-to-use, intuitive technology that provides a rapid way to
resolve problems and settle questions through clear, high-quality
communications
򐂰 Allows quick access to global teams
򐂰 Provides a cost-effective, consistent approach to real-time collaboration
within an encrypted, authenticated, and managed environment
򐂰 Offers integration with Microsoft Outlook and Microsoft Office applications
򐂰 Includes a mobile client that can be deployed on multiple mobile platforms
and devices
8.1.1 New features in Sametime 7.5 and Sametime 7.5.1

Lotus Sametime 7.5 and 7.5.1 includes over 150 new features, including rich
text, chat history, integrated Voice over IP (VoIP), managed interoperability with
public IM networks, and new options for telephony and video integration.
With Lotus Sametime 7.5.1, users get:

򐂰 Improved instant message features, such as spell check, automatic time
stamps, integrated chat histories, built-in Voice over IP (VoIP), and more
򐂰 Streamlined Web conferences that are easier to schedule and join and offer
higher quality, bandwidth efficient presentation sharing and automatic
reconnection

򐂰 Managed interoperability options with public IM networks, such as AOL and
Yahoo
򐂰 Ability to create and embed applications into the real-time environment via
Sametime 7.5.1's Eclipse-based framework
򐂰 Integration with applications such as Microsoft Office and Outlook
򐂰 Ability for mobile clients to run on multiple operating systems and devices
8.1.2 Understanding the distinguishing features within Sametime 7.5

and Sametime 7.5.1
For the writing of this book we used Sametime 7.5.1 as the code base. Most of
the material in this book applies to both Sametime 7.5 and 7.5.1
Sametime 7.5 highlights

Highlights of Sametime 7.5 include:
򐂰 New Sametime Connect client
– Competitive UI and features
– Integrated voice chat
– Eclipse, Expeditor based
– Plug-in model for extensibility
򐂰 Server improvements, which included:
– Policies
– Performance
– Reliability
򐂰 Meeting improvements
– Significant UI update
– Improved welcome page
– Better meeting entry
– Tabbed layout
– Better handling for dropped connections
– New annotation tools
– Audio/video improvements
– Improved uploaded slides handling
Chapter 8. Sametime Client deployment considerations 633

– Written in Java and running in WebSphere system environment
– Provides Federation among external IM systems and your local Lotus
Sametime deployment
Sametime 7.5.1 highlights

Released April 2007, Sametime 7.5.1 builds upon the foundation of Sametime
7.5, but also now includes the following enhancements and functionality:
򐂰 Linux server support
򐂰 Point-to-point video
򐂰 Tabbed chat
򐂰 Mac client for UIM and meetings
򐂰 Calendar auto-status change
򐂰 Windows single sign-on
򐂰 Edge-to-edge view in meetings
򐂰 Office integration
򐂰 Telephony enablement
Figure 8-1 illustrates the new tabbed chat feature provided in Sametime 7.5.1.

tabbed format
Figure 8-1 Illustrating the tabbed chat feature in Sametime 7.5.1

8.2 Sametime 7.5.1 Client options
This section provides an overview of the different Sametime 7.5.1. Client options.
It also highlights many specific new features in the Sametime 7.5.1. Client.
The following Sametime Client options discussed in this chapter are:

򐂰 “Sametime 7.5.1 Connect client” on page 635
򐂰 “Integrated Sametime within the Notes Client” on page 651
– “Notes IM 7.0.2” on page 652
– “Notes 8 instant messaging” on page 658
򐂰 “Sametime Meeting Room Client and Recorded Meeting Client” on page 662
򐂰 Sametime Mobile
8.2.1 Sametime 7.5.1 Connect client

Some of the most fundamental and exciting changes to Lotus Sametime 7.5.1
come in the form of a new chat client that replaces the earlier releases of the
Lotus Sametime Connect client for desktops. The new unified IM client is built on
the Eclipse open source platform. By building Lotus Sametime on top of Eclipse,
it becomes easier for third-party tool providers to build plug-ins, applications, or
extensions that integrate seamlessly into Lotus Sametime. (See 8.2.4, “Plug-in
integration points and extensibility for Sametime 7.5.x Connect client” on
page 649, for more information about extensibility.)
Lotus Sametime 7.5.1 runs on Microsoft Windows 2000, XP, Vista, Linux, and
Apple's Mac OS X Version 10.4, and also serves as the instant messaging client
for a future release of IBM Workplace Collaboration Services. It provides an
extensive list of new out-of-the-box functionality that ultimately leads to a much
richer user experience. Some of these features include:
򐂰 New status settings
򐂰 Click to call
򐂰 Click to dial
򐂰 Location awareness
򐂰 Rich text
򐂰 Ability to send links, graphics, and screen captures to chat partners
򐂰 Time stamps
򐂰 Emoticons
򐂰 Spell check
򐂰 Type-ahead name searching
򐂰 Area for virtual business cards
򐂰 Corporate branding

򐂰 Tools to maintain and view chat history
򐂰 Support for multiple Sametime communities
For more information about the new client features, read Taking a tour of the new
features and technology in IBM Lotus Sametime 7.5 on developerWorks® at:
http://www-128.ibm.com/developerworks/lotus/library/sametime75/
8.2.2 Overview of the features in the Sametime 7.5.1 Connect client

This section highlights many specific new features in the Sametime 7.5.1 Client.
Video and voice enhancements

The Sametime 7.5.1 client now includes point-to-point video capabilities,
allowing you to easily expand an instant message to a voice or video
conversation with another user.
򐂰 Video in chat, as shown in Figure 8-2
Figure 8-2 Video in chat

򐂰 Voice chat, within example shown in Figure 8-3
Figure 8-3 Voice chat functionality

Tabbed chat for multiple Sametime sessions
Sametime 7.5.1 now includes a tabbed chat user interface, allowing you to
simplify your desktop and more easily manage multiple conversations by
consolidating all active IM sessions in a single Lotus Sametime window.
Note: Tabbed chat functionality was introduced with Sametime 7.5.1 and is
not available in Sametime 7.5.
Figure 8-4 illustrates the tabbed chat feature for multiple chat window sessions.
Depending on how you configure your specific user preferences, you may define
the tabs to be either vertical or horizontal. In Figure 8-4, we illustrate the vertical
tab option for multiple chats.

tabbed format
Figure 8-4 Tabbed chat sessions

Further chat window enhancements include the ability for N-way chat with the
chat sessions presented in a tabbed chat format, as shown in Figure 8-5.
Figure 8-5 N-way chat with the chat sessions presented in a tabbed chat format

8.2.3 Enhancements with rich text capabilities
Sametime 7.5.1 allows for the use of rich text, graphics, HTML, and emoticons
included in the chat session.
Figure 8-6 illustrates the use of basic rich text formatting.
Figure 8-6 Rich text formatting
Figure 8-7 illustrates the ability to send links, graphics, and screen captures to
chat partners.
Figure 8-7 Send links, graphics, and screen captures to chat partners

Figure 8-8 illustrates the use of emoticons. Users can manage these from a
default pallet, or can build custom pallet options.
Figure 8-8 Emoticon pallet

Time stamps can be included within the chat dialog and can be configured from
within the preference options (Figure 8-9).
Figure 8-9 Time stamps and other configurable options

Spell checking functionality within the product
Within Sametime 7.5.1 there are multiple options for using the integrated spell
checking capabilities.
Within the Sametime Preferences, set the preference to Always check my

spelling as I type in the message field, while also selecting your preferred
language (Figure 8-10).
Figure 8-10 Spell checking preferences

The user can access the spell checking tool from the Tools menu (Figure 8-11).
Figure 8-11 Spell checking tool
Alternatively, the user can right-click the misspelled word for detailed drop-down
options from the chat menu, as shown in Figure 8-11.
Figure 8-12 Word suggestions from spell checking

Other functional enhancements
Additional functional enhancements within Sametime 7.5.1 include:
򐂰 Type-ahead name searching
Type-ahead name searching is available directly from within the client
interface, making it much quicker to identify the user from within a long
contact list (Figure 8-13). If the user name is not found from within the contact
list, Sametime searches the directory for the name.
Figure 8-13 Type ahead name searching
򐂰 View business card information

From within the listing of names in your contact list, it is very easy to access a
user’s business card information. Simply right-click the name from within the
list, select View Business Card, and the user’s business card is displayed
(Figure 8-14).
Figure 8-14 View business card

򐂰 Mini-apps - primary contacts sample
From within the Sametime Connect client, one of the mini-apps directly
included in the client is the primary contact list. Any of the users in your
contact list can be added by simply right-clicking and selecting Add to
Primary Contacts). This allows you to quickly initiate chats.
Users within
Primary Contacts
Figure 8-15 Primary contact list

򐂰 Tools to maintain and view chat history
Some great improvements have been made to the chat history function. The
Sametime client has a completely new interface for locating and retrieving
saved chats, which can be accessed from a chat history icon right from the
chat window. In this new UI, you can view a list of saved chats by person and
can preview your saved chats. You can also sort the saved chats by person.
By highlighting a person's name in the chat history window, you see a list of
all recent chats that you have had with that person. You can see the date of
the chat along with the start and end times of the chat, as well as who initiated
the chat. As you highlight each of the chats in the list, a preview of the chat is
displayed in that window (Figure 8-16).
List of dates for chat history transcripts
List of contacts for chat history
Figure 8-16 Chat history transcripts

Within the Sametime preferences, you can specify options for saving chat
transcripts (Figure 8-17).
Figure 8-17 Chat history settings

Finally, chat history transcripts also include N-way chats and have search,
e-mail, and cleanup options (Figure 8-18).
Send as email
Delete Search function
Multi-chat
sections
Figure 8-18 Support for n-way chat history
For more information about the new client features, read Taking a tour of the new
features and technology in IBM Lotus Sametime 7.5 on developerWorks at:
http://www.ibm.com/developerworks/lotus/library/sametime75/
8.2.4 Plug-in integration points and extensibility for Sametime 7.5.x

Connect client
With the release of IBM Lotus Sametime Connect 7.5, IBM provides an
application platform upon which enhancements and application plug-ins can be
built to best meet your organization's needs. Sametime Connect 7.5 is the first
release of new instant messaging technology built on the Eclipse-based IBM
WebSphere Everyplace® Deployment platform. This new release leverages the
Eclipse plug-in framework to provide developers with extensibility features that
go far beyond those available in previous releases.
Lotus Sametime Connect 7.5 offers more than simple instant messaging and
presence features. Because it is built on Eclipse, a variety of plug-ins that
expand the functionality of Lotus Sametime Connect are shipped with the
product, and third parties can build additional plug-ins.

Users access plug-in functionality using the same UI features that activate the
standard Lotus Sametime features. These integration points include:
򐂰 Adding an action to the Lotus Sametime Connect system tray icon
򐂰 Adding right-mouse click actions to a selected person or group
򐂰 Adding a toolbar action to the contact list window
򐂰 Adding a toolbar action to the chat window
򐂰 Drop-down menu choices
򐂰 Branding
Figure 8-19 highlights some of the features that can be extended from the Lotus
Figure 8-19 Lotus Sametime Connect client extension points

Figure 8-20 highlights UI features that can be extended in the chat window.
Figure 8-20 Chat window extension points
While Figure 8-19 on page 650 and Figure 8-20 illustrate the extension points
from an user graphical user interface perspective, Extending Sametime 7.5
Building Plug-ins for Sametime, SG24-7346, provides and in-depth look at the
underlying code framework, explaining how and where Sametime can be
extended. This book can be downloaded via:
8.2.5 Integrated Sametime within the Notes Client

Integrated Sametime presence awareness, buddy lists, and other features have
been around, available, and integrated with the Notes Clients for a long time now
(since R5 “Who’s On line”). With each new version of Notes, the parity of
features and functions has been getting closer and closer to that of the
standalone Sametime Connect client. With the upcoming release of Notes 8,
there will no longer be a question about which Sametime client has what features
or functions, since there will finally be a full integration of Connect and Notes.
In the upcoming sections we examine the integrated Notes Instant Messaging

(Notes IM) in both Notes Version 7.0.2 and the upcoming release of Notes 8.
This is the currently shipping version of Notes, as of the writing of this book.

Notes IM 7.0.2
In this section we do not discuss deployment of the Notes client or the
configuration options. If you are looking at Notes Instant Messaging (Notes IM),
then we assume that the Notes Client is already deployed. For information about
how to configure the Notes IM clients to work with Sametime, see 6.4, “Notes
Client integration with Sametime” on page 353, and refer to TN 1139237
“Knowledge Collection: Notes Instant Messaging”:
Figure 8-21 illustrates Notes Integrated Messaging available in Notes 7.0.2.
Figure 8-21 Notes Integrated Messaging available in Notes 7.0.2
With this version you are able to use many of the features and functions that
were available to the pre-7.5 release of Sametime Connect clients.

For example, you can start a chat from the Inbox view (Figure 8-22).
Figure 8-22 Initiating a chat from within the inbox view

As shown in Figure 8-23, you can also Initiate a chat from an open message.
Figure 8-23 Initiate a chat from an open message

As you can see in Figure 8-24, there are meeting options available in this version
of Notes IM as well.
Figure 8-24 Meeting options available in this version of Notes IM

This version also includes and option for chat transcripts and time stamps
(Figure 8-25).
Figure 8-25 Option for chat transcripts and time stamps
Figure 8-26 shows the prompt for the chat transcript.
Time
stamp Option to prompt for
transcript
Figure 8-26 Prompt for transcript

The chat transcripts are saved in the user’s mail file (Figure 8-27).
Figure 8-27 Integrated awareness with Notes Client
There are a lot of good features and functions that can be taken advantage of
with the Notes 7.0.2 version of Notes IM. There are also very important
considerations about server load when using the Notes IM clients. Most of the
load considerations are not relevant against a Sametime 7.5.1 Server back end,
but we do not want to assume what your environment currently looks like, or
what your upgrade strategy looks like, so for more information about this see TN
1222797 “Server load considerations for Notes Instant Messaging”:
Note: The pre-Notes 8 versions are compatible with a Sametime 7.5.1 server,
but most of the new features of the 7.5 Connect client are not available.

Notes 8 instant messaging
Note: Note that all figures and features for this section on Notes 8 refer to the
beta 2 release of Lotus Notes and Domino 8, and may not accurately
represent the features available in the final release.
Features are subject to change, and screen captures are subject to change.
Refer to the Release Notes supplied with the software for the most up-to-date
information.
To access the Lotus Notes and Domino 8 beta software, and for information
about trial versions of available complementary software, see:
http://www.ibm.com/lotus/nd8

With Notes 8, Sametime features, functions, and usage are now be the same for
the users as they exist in the Sametime 7.5.1 Connect client. As you can see in
Figure 8-28, the Sametime component in the Notes IM client comes in on the
component side shelf with Sametime status also showing in the Inbox view,
preview pane.
Figure 8-28 Preview of integrated instant messaging in upcoming Notes 8 client
The Sametime Client that is deployed with the Notes 8 initial release will be the
7.5.1 version of Sametime Connect. Since it is also the same Eclipse-based
program, any of the plug-in or update options that you have set up for your
Sametime 7.5.1 Connect client will work seamlessly.
There are similar functions for Notes IM in Notes 8 as were shown in the Notes
7.0.2 client in the previous section. It has just been improved.

For example, with awareness inside an open message, you have a right-click
menu that gives you options for Sametime functions.
Figure 8-29 Menu options for Sametime functions

Figure 8-30 Sametime integrated functionality directly within the mail message

To show how the integration of the 7.5.1 client fits into Notes 8, notice in
Figure 8-31, that we have selected the tabbed chat option from the Notes 8
preferences for Sametime.
Figure 8-31 Tabbed chat functionality for Sametime from directly within the Notes Client
Now that the Sametime experience is the same, your end users will no longer be
confused about what options they do or do not have. This saves time in training
and in help desk calls. In short, the integration process is finally complete.
Important: Remember that if your users are logging into multiple clients, then
they are being counted for each of those clients in your concurrent user count.
8.2.6 Sametime Meeting Room Client and Recorded Meeting Client

Although Lotus Sametime Web Conferencing has always provided excellent
functionality in terms of application sharing and whiteboard, it needed an
overhaul, most notably in the areas of an outdated UI, poor audio and video
capabilities, and limited administrative control. These weaknesses led to
administrative problems and a poor user experience for end users. With
Sametime 7.5.1, Lotus has made some big improvements, and in the areas that
administrators and users will both appreciate.

In the next few pages we review some of the highlights
Sametime 7.5.1 Web conferencing

Beginning with Sametime 7.5, and subsequently Sametime 7.5.1, Sametime
Web Conferencing functionality has undergone changes and improvements to
the user interface. In particular, you will notice changes to the Sametime Web
Conferencing Welcome page.
Let us start with what the users will see first. Gone is the old yellow page, and
now there is an informative UI (Figure 8-32).
Figure 8-32 New UI for the Sametime Web Conferencing Welcome page
There also is:

򐂰 Streamlined meeting creation
The meeting creation page has been modified to place many of the most
common fields in the first Essentials tab.

Figure 8-33 The meeting creation page has been modified
򐂰 Improved error and information messages when joining a Web meeting

򐂰 Improved connectivity to meeting server and client

A fundamental change to the way the client connects and the information that is
provided during that process has been built into the Sametime 7.5.1. Users
attending Sametime meetings have often had problems with things like pop-up
blockers, lack of JVM, or general browser problems. When these problems
showed up in the past, there was little in the way of useful information that a user
was given to explain the problem. Sametime 7.5.1 provides a page with useful
information about what is happening, so that the user is not just waiting with a
blank yellow screen (Figure 8-34).
Figure 8-34 Sametime 7.5.1 provides a page with useful information about what is happening
As the meeting client is loaded and the user enters the meeting, the status of the
connection is displayed at the bottom of the browser window (Figure 8-35).
Figure 8-35 Status of the connection
Figure 8-36 Confirmation of the connection

Finally, additional improvements for Sametime 7.5.1 Web conferencing include
the following, all illustrated in Figure 8-37:
򐂰 New Meeting Room Client designed for easier navigation and preference
selections
򐂰 Improved UI for easier hand off between moderators
򐂰 Third-party integrated telephony and video solutions
Common actions
on the toolbar Tabs for different
tools
Resizable
Sections
Updated status
bar
Figure 8-37 Enhancements to the meeting room user interface

The Lotus Sametime policy engine allows administrators to regulate specific
functionality that people are allowed to use (Figure 8-38).
Figure 8-38 Configuring Sametime administrative policies
8.2.7 Sametime Mobile

Sametime 7.5CF1 marked the introduction of the feature rich client into the
mobile domain. Users are now able to take many of the new 7.5.x Connect client
features with them when they need to be mobile.
Note: New to Sametime 7.5.1, the mobile client files are installed during the
Sametime 7.5.1 Server installation.
The new features include:

򐂰 Automatic saved chat history and retrieval
򐂰 Alert when user becomes active
򐂰 Sound/vibrate alerts for incoming chats and responses
򐂰 Business card integration/lookup - rich LDAP integration with Sametime client
򐂰 Emoticon support
򐂰 External buddy support for public IM services
Below is a list of the currently supported devices:

򐂰 Nokia ESeries
򐂰 Microsoft Windows Mobile® 5 Pocket PC and Smartphone
򐂰 Microsoft Windows 2003 Second Edition Pocket PC
򐂰 Research in Motion Blackberry 7100/8100/8700/8800
򐂰 Sony Ericsson M600/P990

Important: For the latest information regarding Sametime Mobile, refer to the
IBM Lotus Sametime Mobile Version 7.5.1 information center:
http://www-128.ibm.com/developerworks/lotus/documentation/sametime/
Attention: For detailed information about configuring the Domino Server for
Sametime Mobile Support see:
http://publib.boulder.ibm.com/infocenter/sametime/v7r5m1/index.jsp?
topic=/com.ibm.help.sametime.install.doc/st_inst_cfg_stmobile_on_
dom_t.html
For information about Configuring Sametime Mobile for client downloads, see:
http://publib.boulder.ibm.com/infocenter/sametime/v7r5m1/index.jsp?
topic=/com.ibm.help.sametime.install.doc/st_inst_cfg_stmobile_on_
dom_t.html
8.3 Sametime Client deployment considerations

Sametime is like most other server-client software products. As the Sametime
Administrator, you maintain significant control over the Server environment, but
when it comes to the client side, you may be subject to a whole other set of rules
and demands placed on you by your business unit owners. This section
highlights specific deployment scenarios intended to mimic those typical in most
environments.
8.3.1 Deployment phase 1: planning

Before you begin the deployment phase, you must first look at all the options that
are available — or, more accurately, what are the hurdles going to be for getting
the client deployed and configured? Let us start with a few high-level scenarios.

Note: In most cases, the Sametime Client will need to be pushed out to the
desktops. There are very few large deployment scenarios in which the files
are placed on a central server and the users are simply directed to download
and install the updated client.
Once the client has initially been deployed, it can be further provisioned and
updated via an update site.
The initial challenge, therefore, for many organizations is to determine the

proper tools and approach for initially getting the client installed on the
desktop machines.
Scenario - locked down desktops or limited user rights

If your company is such that you have managed workstations and the users are
not going to have sufficient rights to install software, odds are that your company
also uses a mechanism to do software installs with administrative or power user
rights. This could be a product from CA, SMS, Tivoli, or any number of other
automated deployment options. The point is that in this scenario, you will be
providing the client and directions for getting the client out and configured,
though you may not own the actual deployment process/product.
There is no longer the Sametime Client packager that was provided in some of
the previous versions for Sametime Connect or the Secure Desktop Installer for
Java connect and the other applets. For the Sametime 7.5 Connect client we do
offer a new approach. There is the silent install option or the
plugin_customization.ini that can be pre-configured to set up many of the client
preference values. For 7.5.1 (but not in 7.5) there is also included the
Sametime-connect-win-7.5.1.msi. We explain more about these options later in
the chapter.
Scenario - not locked down, but can they install it

In this scenario, the intent is not to accuse your user community of not being
technically savvy, but it is advantageous to have an administrator perform the
installation. You could probably trust the user community to click a URL and say
OK to an installer, but that is as much as you want for the users to do on their
own. So for these users you may also want to look at the silent install option or
the plugin_customization.ini file.
Scenario - wide open and no restrictions

If your users are in this category, and they are knowledgeable about how to
perform the installation on their desktop machines, then the job of getting the
client deployed will be easier from an administrative perspective. You may still
want to look at the plugin_customization.ini information so that you can help the

user create a common default experience, but otherwise your concerns are going
to be very minimal.
With Sametime 7.5.1 providing the msi file, customers can now use this option to
configure settings.
Scenario - upgrading older client versions

If you currently have Sametime 3.1 or later clients installed, the new 7.5.1 client
installer will detect it. There are two options that you can have the installer
perform:
򐂰 Migrate information from the old client.
򐂰 Remove the older client.
Figure 8-39 Installation dialog
You can select one, both, or none of the options at the install time.
Note: At this time, if you re-run the install to correct any problems, the installer
will automatically perform the options.
The first option is helpful if you do not need any changes and want the new client
to connect to the same server as before. This makes things easier on your users.
The second option to clean up older versions is good for you as an administrator.

Once you roll out the new clients, you do not want end users getting confused
over what client they should be using.
Scenario - using an update site

As the administrator you can determine whether plug-ins are available and
whether you want updates automatically installed. You may also want to think
about setting up two plug-in sites. One of these would be for mandatory updates,
and a second for optional installs.
Note: The DST Plug-in for Sametime 7.5CF1 clients is an example of a

mandatory update that you would want to have automatically deployed.
What would an optional plug in be? The SDK that is provided comes with a few
samples that might help in this area. These might be of interest to some of your
users, but not all. Also, depending on business needs, you may have custom
plug-ins created that only some users would need. Policies will also help you in
controlling the use of plug-ins, but so will the plugin_customization.ini file. For
more information about Sametime Plug-ins, see Extending Sametime 7.5:
Building Plug-ins for Sametime:
8.3.2 Client employment phase II: implementation

Now that you have seen an overview of many of the key new features (8.2.2,
“Overview of the features in the Sametime 7.5.1 Connect client” on page 636)
and completed your planning, it is time to implement your plan.
Option 1 - Sametime 7.5.1 Connect client - server download

option
As discussed in the planning session, the most basic of the strategies is to get
the files onto the Sametime server and allow users to download the files directly
from it. Let us begin by looking at the steps needed to get the files onto the
server.
The Sametime 7.5.1 Connect client is not automatically installed into the client
download directory during the Sametime 7.5.1 server installation. If you want to
make the Sametime 7.5.1 Connect client available for download from the
STcenter.nsf home page you need to copy it over to the proper directory. Below
are the steps to follow.

Copy Sametime Connect clients to server
There are three Sametime 7.5.1 Connect client versions that are listed as
available downloads in the download directory by default.
The links for the clients are already configured by default. You only have to copy
over the client install files to the correct directory and remove the links for any of
the three clients that you do not want your users to access.
Once you have the client files (located on CD4), use the information below to
place the files in the proper location on the server.
Copy sametime-connect-win-7.5.1.exe to the following location on your

Sametime server:
server_data_directory\domino\html\sametime\sametimeclient
Where server_data_directory is the directory specified when you configured the

Domino server.
For example:
c:\lotus\domino\data\domino\html\sametime\sametimeclient
Figure 8-40 Directory location for installation
򐂰 For AIX and Solaris, the default directory is:

/local/notesdata/domino/html/sametime/sametimeclient
򐂰 For i5/OS, there is no default data directory but the name may be similar to
this:
/STserver/domino/html/sametime/sametimeclient
Additional step for i5/OS Sametime servers only: Run the following command
from any i5/OS command line to change the owner of all of the copied objects
to QNOTES:
CHGOWN
OBJ('server_data_directory/domino/html/sametime/sametimeclient/*')
NEWOWN(QNOTES)

The directory should look like Figure 8-41 after all three Sametime 7.5.1 Connect
clients are copied over.
Figure 8-41 Contents of directory
With the files now in place, users can begin to download the clients directly from
the Sametime server (Figure 8-42).
Figure 8-42 Downloading the client from the server

Figure 8-43 Instructions for installing the client
Option 2 - Silent install and assisted install options

In the planning section (8.3.1, “Deployment phase 1: planning” on page 668) we
mentioned options for using the silent install and the plugin_customization.ini file.
Let us look closer at these now and demonstrate what each of these individually
or combined can do for you.
Note: The silent installation still requires that the end user must still copy
and/or run the sametime-connect-win-7.5.1.exe, setup.bat, and silentinstall.ini
files.

Silent install
The Sametime Connect 7.5.1 installer for Windows supports silent operation,
configured and executed via two support files included with the installer. These
included files are:
򐂰 setup.bat - This runs the installer in silent mode.
This batch file contains a command-line that instructs the installer executable
to run in silent mode. It contains several configuration parameters (Table 8-1).
Table 8-1 Configuration parameters

install.log The name of the log file created by the
installer
INSTALLDIR={path} The name of the log file created by the

installer
STSILENTINIFILE={name} Name of the silentinstall.ini file
STSILENTINSTALL=TRUE Must be TRUE for silent execution
򐂰 silentinstall.ini - This provides configuration information for the installer.

This INI file contains configuration parameters for the Sametime client, which
will be used to pre-populate the community-config.xml file with server
connection information and other parameters required by the installer for
silent execution (Table 8-2).
Table 8-2 Configuration parameters
LAPAGREE=YES Must be YES
STSERVERNAME=server.domain.com Host name of Sametime server
STCOMMUNITYNAME=messaging Community name
STSERVERPORT=1533 Sametime server IP Port#
STSENDKEEPALIVE=true Flag for sending keepalive signal
STKEEPALIVETIME=60 Keepalive time
STCONNECTIONTYPE75=direct Connection type
STPROXYHOST= Proxy host name (if used)
STPROXYPORT= Proxy port# (if used)
STRESOLVELOCALY75= Proxy resolves local flag (TRUE/FALSE)
STPROXYUSERNAME= Proxy user name (if used)

STPROXYPASSWORD= Proxy password (if used)
You can edit both of these files to tailor the installer to your specific requirements.
Tip: All of the connection-related settings are used to set values in the
community-config.xml file.
plugin_customization.ini
In cases where you do not have locked-down desktop policies, but you still want
to cover the configuration options for your users, Sametime 7.5.1 includes new
options for this. In order to provide a consistent user experience throughout the
environment, many administrators will want to preset the client-side preferences
per company guidelines. This can be accomplished via the
plugin_customization.ini file.
Why plugin_customization.ini? The Connect client consists of a set of plug-ins

where each plug-in contains its own set of preferences. These preferences are
the client-side preferences that can be customized to alter the behavior of the
client to reflect the business needs of an organization.
At runtime, each plug-in hosted by the Connect client checks the

plugin_customization.ini file to determine whether there are any settings that
need to be updated. If there are any settings that apply, it will set the preferences
accordingly at the time of startup. In this way, you can utilize the
plugin_customization.ini file to preset the majority of the client-side preferences.
Many of the preferences can be pre-configured for the end users by making use
of a file called the ‘plugin_customization.ini’.
By default, when the 7.5.1 client is installed, the file is configured as shown in
Figure 8-44.
Figure 8-44 plugin_customization.ini file configuration

A sample of some values to pre-configure are illustrated in Example 8-1.
Example 8-1 Sample plugin_customization.ini file values

com.ibm.collaboration.realtime.community/DEFAULT_COMMUNITY_HOST=
com.ibm.collaboration.realtime.ui.prefs/external.application.mail=Notes
com.ibm.collaboration.realtime.update/adminUpdatePolicyURL=http://sametimeupdat
e.server.com/sametime75updates/site.xml
org.eclipse.update.core/org.eclipse.update.core.historySize=120
org.eclipse.update.core/org.eclipse.update.core.checkSignature=true
org.eclipse.update.core/org.eclipse.update.core.updateVersions=compatible
org.eclipse.update.core/updatePolicyURL=http://sametimeupdate.server.com/sameti
me75updates/site.xml
#Automatically find updates on
org.eclipse.update.scheduler/enabled=true
#download options automatic
org.eclipse.update.scheduler/download=true
Figure 8-45 illustrates another example of the plugin_customization.ini file and

the values to preconfigure.
Figure 8-45 Sample plugin_customization.ini
Note: This is just a sample of some values used during testing. We

recommend referring to the Sametime Information Center at:
Or contact Lotus Sametime support for additional information about values

that can be set.

Distributing the plugin_customizations.ini file out to users
workstations
Now that we have demonstrated the value and usefulness of this file, we need to
discuss how to get the file down to the user’s workstation. There are several
methods to do this:
򐂰 Push it out with the full client install file set and use a batch file to take care of
a file swap after the client install completes.
򐂰 Set up an update site and push the plugin via your update site.
򐂰 E-mail it. Do not overlook the simple ways that were used in the past. If you
are only looking at a relatively small group that you want to have this, an
e-mail with instructions on manually swapping the file is simple, and the file is
typically going to be only a few kilobytes in size, so it will not be a large
attachment.
򐂰 Help Desk staff. This is a subset of the e-mail it option. Provide a version of
this file to your help desk personnel so that they can provide the file and the
instructions on how to use it. This could be a very good tool for them to help
reset users who have gotten themselves into some trouble with their settings.
Tip: If you have a file this is used to set defaults. When users call your help
desk with problems, this could be used as any easy way to get users back to
the supported or default values. This could aid in resolving end-user problems
faster.
Option 3 - Sametime Java Connect for Browsers

By default, the Sametime 7.5 server no longer ships with a version of the Java
Connect client. If your company is still using the Java Connect client, then you
need to some extra steps. The solution for this is to download and install the
Sametime 7.0 Java Connect client.
Complete the instructions below that are appropriate for your installation and
server platform.
For all Sametime 7.5.1 servers

Downloading the Sametime 7.0 Java Connect for Browsers code:
򐂰 If you do not have access to a Sametime 7.0 Server, you can find the code
posted at:
򐂰 There are two versions of the Sametime 7.0 Java Connect for Browsers
available:
– Sametime 7.0 Java Connect for Browsers: javaconnect.zip

– Sametime 7.0 Java Connect for Browsers (Windows Telephony Toolkit -
enabled version): javaconnect_tel.zip
Download the version that you prefer.
For our example, we use the javaconnect.zip file version.
For all server platforms

Extract the downloaded zip file to the following directory on your Sametime 7.5.1
server (or an equivalent location for your server):
<server_data_directory>\domino\html\sametime
Figure 8-46 Extracting the downloaded zip file to a directory on your server
For AIX and Solaris Sametime servers, run the following command (substitute
the user and group logins for your Domino and Sametime deployment if
different):
chown -R notes:notes
<server_data_directory>/domino/html/sametime/javaconnect
chmod -R 755
<server_data_directory>/domino/html/sametime/javaconnect
For i5/OS Sametime servers, run the following i5/OS commands:

CHGOWN
OBJ('<server_data_directory>/domino/html/sametime/javaconnect')
NEWOWN(QNOTES)
CHGOWN
OBJ('<server_data_directory>/domino/html/sametime/javaconnect/*')
NEWOWN(QNOTES)

Enabling the Connect for Browsers link on the Sametime 7.5.1
server home page
Now that the file is in place, complete the following steps so that the Launch
Connect for Browsers link will appear on the Sametime server home page:
1. Open STConfig.nsf on the Sametime server (Figure 8-47).
Figure 8-47 Open STConfig.nsf on the Sametime server
2. Open the Community Client document (Figure 8-48).
Figure 8-48 Community Client document

3. Set Launch Connect link to true and save the document (Figure 8-49).
Figure 8-49 Selecting keywords
Figure 8-50 Save changes

4. Restart the Sametime server so that the change takes effect (Figure 8-51).
Figure 8-51 Restart the Sametime server

After the changes have been completed and the server has been restarted, you
can now see the Link for the Sametime Java Connect for Browsers link exposed
on the STcenter.nsf home page.
Figure 8-52 Sametime Java Connect for Browsers link exposed
Deploying Sametime 7.0 Connect for Browsers on a Sametime

7.5.1 server managed by EMS
If the Sametime 7.5.1 server is part of a Meeting Services cluster managed by a
Lotus Enterprise Meeting Server, the process for deploying Sametime Connect
for Browsers is the same as described earlier (“Deploying Sametime 7.0 Connect
for Browsers on a Sametime 7.5.1 server managed by EMS” on page 683) with
the following exceptions:
򐂰 If the Sametime server has already been added to the Meeting Services
cluster controlled by EMS, you must remove it before deploying Sametime
Connect for Browsers and re-add it to the cluster afterwards.
򐂰 When you enable the Connect for Browsers link in a later step, it will be
enabled for every server in the Meeting Services cluster. Therefore, you
should deploy Sametime Connect for Browsers on every Sametime server in
the cluster.

Enabling the Connect for Browsers link on Sametime 7.5.1
servers managed by EMS
Complete the following steps so that the Launch Connect for Browsers link will
appear on the server home page of each Sametime server in the Meeting
Services cluster:
1. Start the DB2 command-line processor on the EMS machine.
2. At the db2= > command prompt, type the command required to connect to the
DB2 database used by the EMS.
3. Once connected, type the following command at the db2=> command
prompt:
UPDATE STCONFIG.ORGANIZATION SET CONNECTLINK_EN = '1';
4. Terminate the connection to the DB2 database and close the DB2 command
prompt window.
5. You must restart the STCenter application server in order for the
configuration change to take effect.
8.3.3 Sametime Meeting Room Client, Sametime Recorded Meeting

Client
Sametime Meeting Room Client and Recorded Meeting Client have both been
improved. Another part of that improvement is in how the required applets can
now be downloaded and installed for the users.
Sametime Meeting Room Client (MRC)

The users will install the new 7.5 MRC the first time they attend a meeting on a
7.5 server. Sametime 7.5.1 no longer provides a separate installer for the
applets, as was done in previous versions. This is because it is no longer needed
in order for users to have the applet installed. The user must accept the security
prompts for the applet to install, but does not need administrator rights on the
workstation for it to then load and run properly. Let us go through the steps to
demonstrate this.

When a user attends a Meeting on a Sametime 7.5.1 server for the first time, she
is prompted to install the new applets for the Sametime 7.5.1 Meeting Room
Client.
Figure 8-53 Sametime Meeting Room Client

In Chapter 2, “Planning a Sametime 7.5.1 Deployment” on page 21, we noted
what the software requirements are for the client machines, so that the applet will
be installed and work properly.
Figure 8-54 Applet for the Sametime Meeting Room Client
The installation of the Sametime Meeting Room Client has been redesigned so
that users that do not have administrator rights to the local machine. Figure 8-55
is an example of an account created with only user access rights on the local
machine.
Figure 8-55 Example of an account created with only user access rights on the local machine

Let us take a look at the Java Control panel for our user account (Figure 8-56).
From Java Control panel select Settings

With the Temporary file Settings View applets
See the results of the Applets that are installed
Figure 8-56 Java control panel for our user account

In the Sun Java™ Console we can see the location of the applets to see that this
is still our non-administrator user (Figure 8-57).
Figure 8-57 Cache location
To replay a recorded meeting, the scenario is very much the same as for that of
the Meeting Room Client applet install.
Recorded Meeting Client

To show the full effect to the client, we removed all the Sametime Applets
(Figure 8-58).
Figure 8-58 Showing removed previous applets

First the user goes to the Recorded meetings section and selects a recorded
meeting that she wants to play (Figure 8-59).
Figure 8-59 Selecting a recorded meeting
Click the meeting and then select the option to Replay.
8.4 Conclusion
This chapter provided a comprehensive overview of the latest Sametime 7.5.1
Client features and recommended strategies for planning and executing your
enterprise deployment. In addition to the information contained here, we strongly
recommend that you also refer periodically to the Sametime product page
(http://www-142.ibm.com/software/sw-lotus/sametime), as well as to the
Sametime 7.5.1 Information Center for additional information beyond the scope
of what is covered here:

9
Chapter 9. Systems management and

maintenance
This chapter introduces Sametime Monitoring tools that are available for the
various operating systems that Sametime runs on, as well as tools for the
Domino/Sametime server. We also describe recommended maintenance
activities.

9.1 Monitoring Sametime
Once you have deployed Sametime, you are going to want to ensure that
everything is working as expected. There are several different tools that can be
used to monitor your Sametime environment, some of which you may be familiar
with if you already manage a Domino infrastructure.
9.1.1 Sametime monitoring charts

The IBM Lotus Sametime monitoring charts allow you to monitor Sametime
server statistics by providing up-to-the-second information about Community
Services, Meeting Services, Recorded Meeting Broadcast Services, Audio/Video
Services, Web statistics, and free disk space on the server.
All monitoring charts are available from the Monitoring menu in the Sametime
Administration Tool. The charts that are available from the Miscellaneous link in
the Monitoring menu are part of the Domino Web Administration Tool. These
charts provide information about Web statistics, server memory, and disk space.
Note: To view the status of the Sametime services since the last server
restart, click the Overview link in the Sametime Administration Tool. See the
Server Overview topic for more information. Also note that the time of day that
is listed in the monitoring charts is calculated according to the browser’s time
zone, not the server’s time zone.
Table 9-1 Monitoring charts available for Sametime

Monitoring tool Description
General Server Status Allows you to see the status of the Sametime server at
a glance. Use this chart to keep track of the types of
meetings on the server, the types of connections to the
server, and Community Services activity on the server
at a particular moment.
Logins Displays the number of Community Services logins.

You can view:
򐂰 Total logins, including multiple logins from the
same user
򐂰 Unique logins, where each user is counted only
once
Meetings and Participants Reports the names of all active meetings on the server
and the number of participants in each meeting.

Monitoring tool Description
Tools in Meetings Displays the number of instant and scheduled meetings

that use each tool and the number of people in instant
and scheduled meetings that use each tool.
Miscellaneous Reports current information about HTTP requests,

HTTP commands, and free disk space. This monitor is
part of the Domino Web Administration Tool. You must
have access to the Domino Web Administration Tool
before using the Miscellaneous Monitoring chart.
9.1.2 Sametime logging

The IBM Lotus Sametime server logs information to the Sametime log.
You can determine the format for the Sametime log (a database or a text file) and
the information contained in the log in the log settings, which are available when
you select Logging - Settings in the Sametime Administration Tool. You can also
use the log settings to determine the information that is recorded in the log. How
you view the log depends on the format that you choose to record server
information.
򐂰 Dates and times
Dates and times listed in the log reflect the time zone of the Sametime server
time zone, not the client's time zone.
򐂰 Viewing the log as a text file
If you record information in a text file, open the file in your preferred text editor
to view the log information. You cannot view the text file log from the
Sametime Administration Tool. You can specify a location for the text file in
the database or text file settings.
Note: If you record information in a text file, the text file does not include
information about the Domino log. You must log information to a database
and then choose Logging - Domino Log in the Sametime Administration
Tool to view the Domino log.
򐂰 Viewing the log as a database

If you log Sametime information to the Sametime log database (stlog.nsf),
you can view information in the Sametime log from the Sametime
Administration Tool. To view the Sametime log, open the Sametime
Administration Tool and select Logging, and then select a choice in the
Logging menu.
Chapter 9. Systems management and maintenance 693

Tip: When viewing information in the log, you can click an item to see
additional information about it. For example, click a meeting name in the
Meeting Events section of the log to view details about the meeting, such as
the collaborative activities (tools) used in the meeting.
Table 9-2 lists and describes the available options in the Logging menu of the
Sametime Administration Tool.
Table 9-2 Available options in the logging tool

Menu option Description
Community Login/Logouts Login and logout information for each user

who logs in to Community Services. Also
includes information about failed login
attempts.
Community Statistics The total and peak number of users,

logins, chats, and places accessing the
Community Services. The number of
users differs from the number of logins if
some users are logged in to Community
Services from more than one location or
application.
Community Events Information about the status of

Community Services applications.
Place Login Failures Failed user attempts to:

򐂰 Authenticate with Community
Services when entering an online
place or meeting.
򐂰 Enter a password when accessing a
password-protected place or meeting.
Meeting Login Failures Failures that occur when the Meeting

Room Client cannot authenticate with the
Meeting Services.
Server Connections Connections and disconnections between

Sametime servers.
Meeting Statistics Information about the total and peak

number of meetings, the average meeting
duration, and the average number of
participants in meetings occurring on the
Sametime server.

Menu option Description
Meeting Events Information about the status of Meeting

Services applications in instant and
scheduled meetings.
Capacity Warnings Capacity warnings appear when Meeting

Services usage exceeds parameters
specified by the administrator in the log
settings.
Usage Limits Information about the usage limits that the

administrator defines in the Configuration
- Audio/Video Services settings of the
Sametime Administration Tool. Users are
denied entry to meetings when a usage
limit is reached.
Domino Log Additional information about the

Sametime server, including available disk
space and server memory. The Domino
log is separate from the Sametime log.
The administrator cannot use the
Sametime log settings or the Sametime
Administration Tool to determine what is
recorded in the Domino log.
Settings Options to determine the format and

content of the Sametime log.
For more information about setting up logging, refer to Chapter 15 “Using the
Sametime Logging features” of the Sametime 7.5 Administration guide. This can
be downloaded at:
http://www-128.ibm.com/developerworks/lotus/documentation/sametime/
9.1.3 Domino Administrator

Sametime is a set of services that run on top of a core Domino Server. So if you
are familiar with Domino environments, you should also be familiar with Domino
Administrator. Domino Administrator is the administration client for Notes and
Domino that can be used to perform most administration tasks.
Tip: You can administer the Domino system using the Domino Administrator
client or optionally via the Web interface accessible at:
http://yoursametimeservername.yourdomain.com/webadmin.nsf

For more detailed information about the Domino Administrator, see the
Administrator’s help at:
http://www-12.lotus.com/ldd/doc/domino_notes/7.0/help7_admin.nsf/
Main?OpenFrameSet
Platform statistics
Platform performance statistics can be directly retrieved from the Domino server
console, mailed, or displayed in the Domino Administrator clients. You can also
use Monitoring Configuration and Monitoring Results databases for both
real-time and historical statistics.
Lotus Domino 7 includes platform statistics for the following Sametime platforms:
򐂰 Windows 2000/2003/XP on Intel
򐂰 AIX
򐂰 OS400
򐂰 Solaris
There is a full range of platform statistics that can be monitored, but the most
essential ones to monitor for Sametime are:
򐂰 CPU utilization
򐂰 Memory utilization
򐂰 Disk utilization
򐂰 Network utilization

To display platform statistics using your Domino Administrator client, select the
server that you want to monitor, then go to the Server-Statistic Tab and expand
Platform, as shown in Figure 9-1.
Figure 9-1 Overview of Domino Server stats

Tip: For a quick view of critical health statistics on Sametime, try the
Web-based Administrator tool. It has a platform-specific view in the Status
page that shows a snapshot view of server status.
Go to Server → Status tab and expand Operating System to display

platform statistics, as shown in Figure 9-2.
Figure 9-2 Platform statistics
9.1.4 Clustered environments

In addition to the essential statistics mentioned above, for environments using
Domino/Sametime clustering, you will want to monitor the status of your
replication and cluster replication. A properly clustered environment will rely on
both scheduled and cluster replication to keep a database in sync. The
databases that you would want to monitor include:
򐂰 Names.nsf, Admin4.nsf, cldbdir.nsf (Core Domino databases)
򐂰 vpuserinfo.nsf (buddy list)
򐂰 stpolicy.nsf (Sametime policy)

Specific stats to monitor for cluster replication are shown in Table 9-3 on
page 700. In general, you are checking to see that the cluster replicator is
keeping pace. The seconds on queue should be low numbers. The work queue
depth should not be consistently higher than 0. If it is, then you may want to
consider adding another cluster replicator task to ensure that your databases are
keeping in sync.
Figure 9-3 Stats to monitor for cluster replication
Note: Remember, Sametime is a set of services that run on top of a core

Domino Server, so understanding and achieving successful performance
tuning on your Domino Server lies at the foundation of Sametime
performance.
For more detailed information about Domino statistics, including other platforms,
see Domino Server Performance Troubleshooting Cookbook at:
http://www-1.ibm.com/support/docview.wss?uid=swg21234550
Additionally, we recommend reviewing the following IBM Redbooks and

resources, as these provide helpful information about monitoring and tuning your
(Domino and ultimately Sametime) environment.
򐂰 Domino 7 Performance Tuning Best Practices to Get the Most Out of Your
Domino Infrastructure, REDP-41820:
򐂰 The Domino Performance section of Lotus Developer Domain at:
http://www-128.ibm.com/developerworks/lotus/performance/

9.2 Recommended maintenance activities for Sametime
environments
Maintenance is an important aspect of Sametime administration. Below we listed
the most common best practices in terms of maintaining your Sametime
environment.
Important: Note that since Sametime depends on a Domino server, the

maintenance activities recommended by the Domino product will apply
as well.
Table 9-3 focuses mainly on Sametime-specific maintenance that should be

done.
Table 9-3 Recommended maintenance activities

Maintenance activity Frequency
We recommend backing up your entire The frequency depends on how often

Sametime server installation. This changes are made to this environment.
includes the entire program directory (that
is, \lotus\domino) and the entire data Each time a configuration change is
directory (that is, \lotus\domino\data). This made, a backup should be made.
gives an administrator the opportunity to
restore the server to the last known good With regards to vpuserinfo.nsf, this
state if the need arises. If a full backup is database stores users’ buddy lists and
not possible, then at the very least the changes daily. How often you back it up
following files should be backed up: depends on your environment. If you have
򐂰 notes.ini more than 1,000 employees, it may be
򐂰 sametime.ini beneficial to back up this database on a
򐂰 UserInfoConfig.xml nightly schedule. Again, the frequency at
򐂰 names.nsf which this database is backed up is highly
򐂰 stconf.nsf dependant on your environment, and can
򐂰 stconfig.nsf be altered to match the needs of your
򐂰 stpolicy.nsf environment.
򐂰 stnamechange.nsf
򐂰 vpuserinfo.nsf Note that the same comments above
򐂰 stlinks.js apply to stconf.nsf (online meeting
򐂰 hostinfo.js center).

Set space savers on the databases that We recommend setting the following
will grow large over time like log.nsf and purge interval for:
stlog.nsf. To enable space savers, see the
document titled “Limiting the contents of a 򐂰 log.nsf - 7 days
replica” in the Domino Administrator help 򐂰 stlog.nsf - 30 days
guide. You will need to enable the
“Remove documents not modified in the
last x days” setting on the Space Savers
panel.
Periodically, the sametime.log file should Every 3–4 weeks this file should be
be archived or deleted. deleted unless you are troubleshooting a
specific issue.
Periodically, the contents of the trace The frequency of this is dependant on how
directory (\lotus\domino\trace) should be much space you have available on your
purged. hard drive and how fast the trace files are
growing. If you are not troubleshooting a
specific issue, we recommend purging this
every 3–4 weeks. You may need to
increase the frequency depending on how
much hard disk space you have available
and how much tracing you have enabled.
Create Domino program documents to run The following commands should be run
scheduled database maintenance weekly via a program document while the
(compact and updall) on the following server is up and running:
databases:
򐂰 stconf.nsf updall [database.nsf] -r
򐂰 vpuserinfo.nsf compact [database.nsf] -B
򐂰 stlog.nsf
Note: In order for a copy-style compact to
For an example on how to create a occur on these databases, they must not
program document, see the help be opened by any user. Therefore, we
document titled “Setting a schedule for recommend following these maintenance
Updall in a Program document” in the suggestions with the server shut down as
Domino Administrator help guide. well.

In the cases where the above databases This should be done every two weeks.
cannot be compacted due to open
sessions, shut down the server and run
maintenance on the same databases
above.
1. Open a command prompt.

2. Navigate to the Domino program
directory.
3. Run the following commands:
ncompact [database.nsf] -C
nupdall [database.nsf] -r
On Sametime meeting servers, enable the We recommend setting the purge agent to
purge agent on stconf.nsf. For more purge every 30 days.
details on how to enable the purge agent,
see the help document titled “Maintaining
the Sametime Meeting Center” in the
Sametime Admin help guide.

10
Chapter 10. Enterprise Meeting Server

This chapter discusses the Sametime Enterprise Meeting Server (EMS). The
following topics are discussed:
򐂰 “Introduction to Enterprise Meeting Server (EMS)” on page 704
򐂰 “Differences between Sametime and EMS” on page 704
򐂰 “For which environments is EMS appropriate” on page 705
򐂰 “What is EMS” on page 707
򐂰 “Hardware and software requirements for EMS” on page 712
򐂰 “The applications within EMS” on page 713
򐂰 “EMS deployment - port diagram” on page 715
򐂰 “Installing and configuring EMS” on page 716
򐂰 “Troubleshooting EMS” on page 731

10.1 Introduction to Enterprise Meeting Server (EMS)
Enterprise Meeting Server is an ADA compliant optional front end for managing a
globally distributed online meeting environment. It provides high availability for
Sametime meeting servers and load balancing for meeting attendees. EMS
allows you to create meetings, modify existing meetings, delete and attend
meetings, search, and perform booking services from one centralized location.
EMS manages multiple Sametime meeting servers, referred to as room servers,
and all configuration and meeting services are handled by it. It can also manage
Sametime IM only clusters. In other words, EMS aggregates scalability across
many distributed Sametime meeting servers — the sum of the parts is greater
than the whole. That is a higher level view of what EMS is, but what does an
EMS server actually consist of? What is behind the technology?
EMS is a J2EE™ application running on top of WebSphere Application Server 6

(WAS, rhymes with spaz). It uses Java Server Pages (JSPs), JDBC™ for
database communication, and Java Message Service (JMS) for EMS to Room
Server communication. DB2 is used as a back end to store all configuration data
for all room servers added and all meeting information such as start times,
number of participants, moderators, and so on. Authentication and user name
lookups are handled via an LDAP server, which EMS and all of the room servers
point to as well. The Web-based front end is handled by IBM HTTP Server
referring back to the Web application running on the WAS server. The
requirement of WebSphere MQ (previously known as MQSeries®) has been
removed to allow easier installation and manageability. With this infrastructure,
EMS provides macro-level control and manageability for large-scaled online
meetings.
Key points: Enterprise Meeting Server is a separate product designed

provide high availability and load distribution solutions for meeting services:
򐂰 Allows for a meeting capacity to be defined for a cluster of meeting servers.
򐂰 The meeting manager can distribute the meetings across room servers.
򐂰 Controls scheduling based upon capacity.
10.2 Differences between Sametime and EMS

Even though EMS runs on WebSphere as a J2EE application, the look and feel
is almost identical to a Sametime server running on Domino. On the Meeting
Center page, EMS presents a calendar picker. With this you can easily find or
schedule meetings based on specific dates or time ranges. Another difference is
that with EMS you must enter the expected number of participants for a meeting.
This number will be used for load balancing purposes (described later in this

chapter), but do not think too hard. EMS does not reject participants if more
people join a meeting than it expects, but in order for EMS to do its job it is
important to estimate as closely as possible to avoid overloaded servers.
One other important difference is the home URL. A typical Sametime server
looks like:
http://servername.domain.com/stcenter.nsf
However, the EMS home page is:

http://servername.domain.com/iwc/center
See how they look very similar? The idea is for the users to not worry about the
back end. If they are trained with Sametime then they will see little difference
when they use EMS. Fundamentally, there is no difference between Sametime
and EMS other than that the EMS server is handling all of the meeting booking,
and under the covers it determines which Sametime Room Servers meetings go
on.
10.3 For which environments is EMS appropriate

This section addresses two important questions:
򐂰 When is it appropriate to deploy EMS for your environment?
򐂰 In specific cases, when might it not be appropriate to deploy EMS, and
instead, seek alternate solutions?
10.3.1 When should you deploy EMS

Let us pretend that we have a company, ITSOCorp1, and the employees at
ITSOCorp1 love Sametime meetings. So much that they schedule hundreds of
meetings a day. Sometimes these meetings have up to a hundred people in
them. Currently, ITSOCorp1 has a few Sametime servers in a Sametime
community, but they have no standard operating procedure for scheduling
meetings. ITSOCorp1 employees have gotten upset because it is confusing as to
which servers they can have their meetings on, and also ITSOCorp1 Sametime
administrators are upset because some of their Sametime servers are
overloaded, while others are almost untouched. Also, administrators find it
difficult to manage all of the Sametime servers. What should they do? EMS
solves ITSOCorp1's problems. First of all, EMS solves the problem of the
ITSOCorp1 employee populous having problems determining which server to
schedule meetings on. All ITSOCorp1 employees go to the central EMS server to
do their booking, and EMS ultimately determines which Sametime room server
the meeting will appear on. Even the URL that is given to you after scheduling a
Chapter 10. Enterprise Meeting Server 705

meeting points to EMS, which redirects to the appropriate meeting server.
ITSOCorp1 Sametime administrators do not have to worry about Sametime
servers being overloaded or under utilized. When ITSOCorp1 users book
meetings, they specify approximate attendance, and the EMS server can look at
all of its room servers and distribute meetings based on number of participants
and times accordingly, thereby sharing the server farm workload.
EMS has solved two problems for ITSOCorp1:

򐂰 Provided a centralized area for scheduling and attending of meetings and a
place for administration of all Sametime Room Servers
򐂰 Provided load balancing of multiple meetings with large and small numbers of
participants
Now let us look at another scenario.
10.3.2 When you should not deploy EMS

Now let us look at another company, ITSOCorp2. While ITSOCorp2 users do not
schedule that many meetings, when they do they want 500 or more users per
meeting. ITSOCorp2 also wants to have the capability of 100,000 concurrent
Sametime IM users.
EMS is designed for high availability and load balancing, meaning that Sametime
room servers are almost always available for meeting use, and they are
scheduled across available boxes. This does not mean that EMS can handle
high concurrency in a meeting beyond what a single Sametime server can do. So
EMS is not the ideal solution for high concurrent meeting use (enabling multicast
and using record and playback might be a better route). EMS can handle the
configuration and administrative management of room servers assigned to do
meetings only, and Sametime servers in a cluster assigned to do IM only.
However, EMS is not necessary to handle large amounts of concurrent IM users.
Putting up to six Sametime servers in a Domino cluster, or putting a bunch of

Sametime multiplexers (muxes) in front of a Sametime Community (with an Edge
Server or a DNS Round Robin device in front of the muxes), will do the job nicely
without EMS. So this is another instance of when EMS is not right for the job of
handling high numbers of concurrent users.
Now you should have a good idea of when to deploy EMS and when not to.

10.4 What is EMS
So far we provided a high-level description of EMS. Now let us discuss what it
does from a more technical perspective.
First of all, let us define a room server. A room server is simply a managed
Sametime server. A managed server simply means that there is centralized
configuration and centralized logging and monitoring. The room server provides
both Sametime Meeting and Community Services, and only uses the Domino
HTTP service in a very limited fashion for servlets that report health, create
meetings, and so on. All HTML and Web interfaces are handled by the IBM
HTTP Server (IHS) talking to the EMS application.
Figure 10-1 illustrates EMS graphically. As you can see, the Enterprise Meeting
Server is the center of attention, with your multiple room servers using 2-way
communication reporting health and stats, and starting and ending meetings.
You can also have as many room servers as you need to accommodate your
company’s meeting habits. If you see an increase in meeting server usage, it is
easy to add additional room servers that will inherit your configuration and can all
be administered in one centralized location.
What is EMS graphically?
Enterprise Meeting
Server
Room Room Room

Server Server
* * Server
1 2 * N
Figure 10-1 Overview of EMS

Figure 10-2 illustrates how EMS manages room servers for meetings, but also
provides the context of how EMS fits within an architecture of chat servers as
well. (In 10.4.3, “EMS and clustering” on page 711, we discuss how EMS can
also be used as a centralized location to manage a community, also known as
IM-only cluster.)
Chat
Server
WebSphere IBM
DB2 Application HTTP
Server Server
Chat
Sametime EMS
Server
Room Room Room

Server Server Server
Figure 10-2 EMS within the context of Meeting Room Servers and an IM Cluster

Finally, Figure 10-3 illustrates a more realistic architectural overview of how EMS
would be implemented within the overall Sametime infrastructure. Note the
following key points pertaining to this architecture:
򐂰 The EMS application can manage both meeting and IM servers.
򐂰 Meetings can be restricted on IM systems.
򐂰 A common LDAP Directory is required.
򐂰 All ST configuration is stored in the DB2 database.
򐂰 Can move the Sametime static HTML content to the IHS HTTP Server.
򐂰 Separate mux servers are shown for scaling.
Meeting Server
HTTP Server WAS Server LDAP
Meeting Server
Meeting Cluster
DB
MUX IM Server
IP Sprayer
MUX IM Server
IM Cluster
Figure 10-3 Architectural example

Key points to note: A room server is a managed Sametime server. It can
manage Sametime Meeting and Community Services. Domino HTTP is used
in a limited fashion.
Managed means:
򐂰 Centralized configuration
򐂰 Centralized logging/monitoring
At the core of EMS are two general rules for achieving high availability:
򐂰 It is designed such that there are no single points of failure.
򐂰 There is minimized end-user perceived down time.
10.4.1 Understanding different models and scale factors between

Community and Meeting Services
There are different models between Community and Meeting services, as there
are different scale factors between them, and different usage models between
chat and schedule meetings. Unlike IM-only servers, you cannot just cluster or
turn on replication with multiple Sametime servers, because each meeting is a
unique instance based off of a unique document ID. Replicating that document
would still cause a different meeting to be created based on a different Sametime
community place. You also cannot have a bunch of Sametime servers in an
invited scenario, because if the top tier server ever went down, the meeting
would disappear on the children servers as well.
How EMS addresses these issues

Because of these implementation issues, EMS was developed and obtains high
availability by creating meetings on specific managed Sametime servers. If one
of those room servers goes down, the meeting is placed on another room server.
Key points
򐂰 Different model between Community and Meeting Services:
– Different scale factors
– Different usage model between chat and scheduled meetings
򐂰 Allow for different management strategies for the two service offerings.
10.4.2 How EMS handles failover

Because EMS is simply a WebSphere application, it can be horizontally cloned,
providing redundancy for the main EMS interface. The back-end database, Web,

and Directory Servers (DB2, IHS, LDAP) can also be made redundant,
eliminating those single points of failure as well. But how does EMS handle
failure of a room server?
Room servers report usage and resources to EMS via the Java Message
Service. Health messages, which are simply JMS messages sent back and forth
between the EMS and room servers, verify things like the number of meetings
and users are on a server, and make sure that the server and all services are up
and running. EMS performs the load balancing of scheduled meetings based on
stats it receives from all of its room servers.
Failover is automatic — if users are in a meeting and that particular room server
goes down, the meeting and all data saved up to that point will automatically be
transferred to another room server, and all users browsers will auto-refresh to the
new server. This is possible because the URL to join a meeting does not point to
a specific room server. It points to the EMS server, which then redirects to the
appropriate server.
Users do not need to know or care exactly what room server their meeting will
appear on, eliminating confusion. Should the need arise where there is more
meeting activity than server capacity, additional room servers can be added
quickly and easily, and will inherit the configuration from the other added room
servers.
Key points
򐂰 EMS may be horizontally cloned in a WebSphere environment.
򐂰 Room servers report usage and resources to EMS.
򐂰 EMS performs load balancing of scheduled meetings.
򐂰 Automatic failover.
򐂰 Users never need to know which server.
򐂰 Add room servers as needed.
10.4.3 EMS and clustering

While the primary purpose of EMS is to handle meetings, it can also be used as
a centralized location to manage a community, also known as IM-only cluster.
When adding room servers (or clusters) to be used as IM only, you can
designate that no meetings may be placed on that server. If one of these
community clustered IM-only servers goes down, the user may see a slight
service interruption in their client, but that is about it.
It is important to note that EMS cannot manage a Sametime multiplexor (mux),

only actual Sametime servers.

10.4.4 EMS Meeting Services
Scheduled meetings require resource booking, so administrators need to plan
the capacity of each room server. You can limit the number of meetings and
participants on a room server, and each managed machine can be configured
differently. With this type of capability, you can have smaller boxes handle small
meeting usage and very powerful boxes handle more traffic.
As meetings go active, the least loaded server gets the meeting. Least loaded is
dependent on current and future numbers of participants and meetings. Keep in
mind that limits are not strictly enforced for active meetings, so users will never
be denied entry into a meeting. When any capacity is exceeded, an alert is
logged and booking will be routed to a different server. Also, meetings are not
booked on one server until its capacity is filled and then switched to another.
EMS is smart enough to spread meetings across all servers efficiently. A failed
server results in the meeting getting immediately placed on a different server.
EMS and instant meetings

Instant meetings, like chat, cannot be predicted, so EMS allows you to manage
the number of concurrent instant meetings on a room server. A managed server
can support zero instant meetings, thus creating a chat or scheduled meeting
only server.
You can set a specific number of instant meetings, and if that number is
exceeded, a managed server will direct the activity to another server. Lastly, you
can have an unlimited number of instant meetings. Even though there is no hard
limit imposed, instant meetings are still load balanced among all servers
supporting them. Of course, the EMS administrator can decide how they want to
align machines to services.
10.5 Hardware and software requirements for EMS

EMS hardware requirements are significant. In a test or preproduction/pilot
environment, you can easily run DB2, WAS, and IHS on one box. Obviously if
this box ever goes down, your whole meeting environment goes down, but EMS
services are quite stable. With that in mind we highly recommend in a production
environment having all of these pieces on separate servers.

For the EMS box itself, the requirements are as follows for a Windows 2000/2003
server:
򐂰 2 Gigs or more of RAM (4 Gigs is better, and strongly recommended)
򐂰 Free hard disk space - At least a 2.0 GHz processor, but a dual or quad 3.0
GHz+ is always better.
10.5.1 Software components

EMS requires a specific J2EE infrastructure, including:
򐂰 WAS 6.0.2.11
򐂰 DB2 8.2.5 Enterprise Server
򐂰 Supported LDAP Directory (a Version 3 compliant LDAP server such as IBM
Tivoli Directory Server)
򐂰 A Web server such as IBM HTTP Server that has single sign-on enabled
between the WAS server and the room servers
Note: Enterprise Meeting Server 7.5 no longer requires MQ components

(WebSphere MQ 5.3) to be installed on the server.
10.6 The applications within EMS

EMS consists of three main WebSphere Enterprise Applications that handle all of
the services required. These applications are:
򐂰 STServer
򐂰 STAdmin
򐂰 STCenter
Note: This is the recommended order in which these servers should be

started, but they are not dependent on each other.
STServer
The STServer server handles meeting creation, scheduling, updating status,
load balancing, statistics, and all important meeting server tasks. Each room
server has servlets running that provide services, and this service is what talks to
a number of these servlets. For example, STServer creates meetings on the
room servers by talking to the MMAPI servlet that schedules meetings on a
Sametime server.

STAdmin
The STAdmin server handles all configuration changes, whether they be
managed server, directory, or general settings. It also handles all updates to
DB2, room server additions and subtractions, and other configuration stuff.
Anything that you see at the administration URL is also generated courtesy of
this server:
http://servername.domain.com/iwc-admin
STCenter
The STCenter server is responsible for the Sametime 7.5.1 look and feel. It
provides the easy-to-use GUI and runs the interface with advanced HTML
techniques and Java Server Pages (JSPs).
10.6.1 Why these need to exist as separate applications

In the unlikely event that a particular service fails, splitting up the services and
applications allows individual pieces to be restarted without shutting down the
entire EMS server. For example, if meetings are not being scheduled, the
administrator can try restarting the STServer server since it is responsible for
putting meetings on room servers. Another example is if the Web pages look
corrupt or are not appearing at all, the administrator can try restarting the
STCenter server since it is responsible for providing the Web interface.

10.7 EMS deployment - port diagram
Figure 10-4 illustrates the ports used by EMS. This section provides extensive
details on port usage.
EMS Deployment – Port Diagram
EMS Applications -
port 9060/9043 handed DB2 traffic - port 50000
to port 80 via IHS
EMS DB2
Servlet traffic - port 80 LDAP
RS RS RS LDAP traffic - port

Can be encrypted via 389/636
SSL (port 443)
Servlet traffic is 2-way for status, scheduling,

configuration info between EMS and RS’s
Figure 10-4 Port diagram for EMS deployment
The steps are:

1. First, we have the applications themselves running on ports 9060 and 9043
on the WebSphere server. EMS is not designed to be run directly via the
applications, so you need to use a Web server like IBM HTTP Server. But, it is
helpful to know what ports these processes are running on to verify they are
available with a tool such as TCPView or netstat -a.
2. Next we see servlet traffic between the EMS server and the room servers on
port 80. This servlet traffic includes things like the health of a room server
(whether it is running), number of meetings on a room server, and so on. Also,
servlet traffic is what is used when EMS decides to schedule a meeting on a
room server based on the health and status of the room server already
communicated. This traffic is two-way, so you will see room servers initiating
connections to EMS for health updates, for example, and EMS telling the
room server things like Go schedule this meeting. Do It Now! This
connection can also be encrypted via SSL (port 443) since they are basic
SOAP/HTTP transactions. (Refer to Chapter 7, “Deployment phase III -
securing the environment” on page 537, for instructions on implementing
SSL.)
3. Off to the side, we see our EMS connection to DB2 via the typical port of
50000. Any configuration changes, meeting information, status, and logging

entries are stored in the Sametime database in a table. DB2 acts as a
centralized repository for all things EMS, including configuration pieces such
as security, LDAP, and Sametime configuration options such as HTTP
tunneling and applet details.
Note: In a pilot deployment you can run HTTP and DB2 all on the same
box, but if you separate out each of those servers you will have higher
redundancy if a box goes down. Also keep in mind that EMS can point to a
cluster of DB2 servers or be horizontally cloned itself since it is a WAS
application.
4. On the other side we see connections to the LDAP server via port 389, or 636
if you are using the secure encrypted port. The EMS sever and all room
servers connect to the LDAP server, and use its directory for authentication
and user name lookups. Because of this, it is important for both the EMS
server and each room server to have the same LDAP configuration so that
authentication and user lookups will be consistent between all servers. If the
base DN (or base objects in the Sametime LDAP configuration document),
search filters, and binding names (optional unless using Active Directory) do
not match, the resulting entries returned may not be consistent, causing (to
be as technical as possible) things to break. Also, EMS and all of the room
servers use SSO, so you are not prompted to reauthenticate between looking
at the meeting page and attending a meeting. If you are logging in with one ID
on EMS but the room server expects a differently formed ID based on its
LDAP configuration, or it cannot find your ID at all, then SSO breaks and you
will not be able to attend a meeting. The key here is consistency.
10.8 Installing and configuring EMS
Important: The following installation was based, for the purposes of this book,
on a Single Server Setup using WAS 6.0.2.9.
Before deploying EMS, the J2EE environment must be installed and configured.
Once this environment is ready, installing the EMS application is straightforward.
For this workspace, the administrator name is db2admin. We configure
WebSphere to point to DB2 to use as its datastore, and then we must enable
security by pointing to our appropriate LDAP server. Finally, we create the
application servers for EMS to use and then begin the EMS installation.
For each room server, we must install Domino 7.0.2. Once installed, we
configure single sign-on for the WebSphere, IBM HTTP, and Domino servers.

We can then proceed with the Sametime installation and finally add Sametime to
EMS, converting it to a room server.
10.8.1 Prerequisites
You are required to:
1. Install LDAP. This can be any Version 3 compliant LDAP server, but we
recommend IBM Tivoli Directory Server 5.3.
2. Install DB2. 8.2.x should be fine.
3. Install WebSphere 6.0.0.1, making sure that you use an administrator
account with the correct permissions. Update to WAS V6.0 Refresh Pack 2
and then to WAS V6.0.2 Cumulative Fix 9. When you install the base
WebSphere 6, make sure to select the following components:
– IBM HTTP Server 6.0
– Web server plug-ins for WebSphere Application Server
Prerequisite - define WebSphere variables

You are required to:
1. Start server1. You can do this by either starting the Windows Service called
IBM WebSphere Application Server, clicking Start /Program Files/IBM
WebSphere/Application Server/Profiles/AppSrv01/Start the server, or
opening a command prompt, changing into the /WebSphere/AppServer/bin
directory, and typing startServer server1 (case sensitive).
2. Go to the WebSphere Administrator Console by selecting Start →
Programs → IBM WebSphere → Application Server v6 → profiles →
default → Administrative console. If security is not enabled you can type
any name to log in.
3. Navigate to Environment → WebSphere Variables.
4. Edit DB2UNIVERSAL_JDBC_DRIVER_PATH and enter the appropriate
location (for example, C:\IBM\SQLLIB\java).
5. Edit the DB2 JDBC Driver Path and enter the appropriate location (for
example, C:\IBM\SQLLIB\java).
6. Click OK.
7. Save.

Prerequisite - define JAAS alias
To do this:
1. Navigate to Security → Global security → Authentication → JAAS
Configuration → J2C Authentication Data.
2. Click New and enter the following information:
– Alias = db2admin
– User ID = db2admin
– Password = password
3. Click OK.
4. Save.
Prerequisite - set up resources and create data source

To do this:
1. Navigate to Resources → JDBC Providers.
2. Click New.
3. From the drop-down menu choose DB2.
4. From the drop-down menu choose DB2 Universal JDBC Driver Provider.
5. From the drop-down menu choose Connection pool data source.
6. Click Next.
7. Click Apply.
8. Under the Additional Properties section (right side of the screen) select Data
Sources.
9. Click New and enter the following information:
– Name: SametimeDataSource
– JNDI name: jdbc/SametimeDataSource
– In the Component-Managed Authorization Alias drop-down select
Node01/b2admin.
10.n the Container-Managed Authorization Alias drop-down select the
Node01/b2admin.
11.Under the DB2 Universal data source properties section (bottom of the
screen) select Custom Properties and enter the following information:
– databasename: Sametime
– Servername: full qualified server name (for example,
servername.domain.com)
12.Click OK.

13.Under the Additional Properties section (right side of the screen) select
Connection Pool and change Max Connections to 100.
14.Click OK.
15.Save.
16.There is no need to perform this step now, but once the Sametime database
has been created you can test the connection by navigating back to
Resources → JDBC Providers → DB2 Universal JDBC Driver
Provider → Data Sources and check SametimeDataSource. Use the Test
Connection button at the top of the window.
Prerequisite - enabling LDAP Directory Access and

WebSphere security
To do this:
1. Navigate to Security -> Global Security and enter the following information:
– Check the Enabled box.
– Uncheck the Enforce Java 2 Security box.
– Active Authentication Mechanism = LTPA.
– Active User Registry = LDAP.
2. Click OK.
3. Enter the following information:
– Server User ID = WAS/EMS admin user name (for example, wpsadmin)
– Server User Password = WAS/EMS admin password (for example,
password)
– Type = eDirectory (or what pertains to your LDAP setup) (for example,
IBM_Directory_Server)
– Host= fully qualified name of the LDAP server (for example,
directory.domain.com)
– Port = 389
– Base DN = o=ibm, c=us (or what pertains to your LDAP setup)
– Ignore Case = Check this box.
4. Click the Advanced LDAP Settings section (right side of the screen) and
modify the following fields:
a. User Filter:
(&(|(uid=%v)(cn=%v)(mail=%v))(objectclass=inetOrgPerson))
b. Group Filter:
(&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNa
mes)(objectclass=groupOfURLs)))

c. User ID Map: *:cn
d. Click OK.
e. Save.
5. Navigate to Security → Global Security → Authentication Mechanisms →
LTPA and enter the following information:
a. Password = <any password> (for example, password)
b. Confirm Password = same as above (for example, password)
c. Timeout = 120
6. Click Apply.
7. Under the Additional Properties section (right of the screen) select Single
Signon (SSO).
8. Check the Enabled box and enter a domain name (for example,
domain.com).
9. Click OK.
10.On the following screen click OK.
11.Before saving, recheck all the security settings. Click Save.
12.Log out of WebSphere Administrator Console and restart server1 so that the
security changes will take effect.
13.Open a command prompt and type:
Cd \IBM\WebSphere\AppServer\bin
Stopserver server1 (or stopserver server1 -username wpsadmin

-password password ) and startserver server1
14.Go to the WebSphere Administrator Console by selecting Start →
Programs → IBM WebSphere → Application Server v6 → profiles →
default → Administrative console.
Note: You will be redirected to https and will now need to log in using the
WAS/EMS admin user name and password you entered in the previous
steps.
15.Navigate back to Security → Global Security → Authentication

Mechanisms (right of the screen) → LTPA and enter the following
information: Key File Name= <any name> (for example, servername.key).
16.Click Export Keys.
17.Click Save.

Note that the file will be saved to
C:\IBM\WebSphere\AppServer\profiles\default unless you specified
something different above, like C:\servername.key.
18.Modify the soap.client.props file in:
C:\IBM\WebSphere\AppServer\profiles\default\properties below the comment
of:
# JMX SOAP connector identity
com.ibm.SOAP.loginUserid=wpsdmin
com.ibm.SOAP.loginPassword=password
Prerequisite - create the application servers

To do this:
1. Start the wsadmin tool. Go to
C:\IBM\WebSphere\AppServer\profiles\default\bin, run wsadmin.bat.
2. Create the STAdmin server:
$AdminTask createApplicationServer Node01 {-name STAdmin
-templateName default}
3. Create the STServer server:
$AdminTask createApplicationServer Node01 {-name STServer
4. Create the STCenter server:
$AdminTask createApplicationServer Node01 {-name STCenter
5. Save the configuration changes:
$AdminConfig save
6. Restart server1.
Prerequisite - enable UTF-8 support

To do this:
1. Navigate to Servers → Application Servers and click STAdmin.
2. On the settings page for the selected application server, click Java and
Process Management and click Process Definition.
3. On the Process Definition page, click Java Virtual Machine.
4. On the Java Virtual Machine page, enter the following in Generic JVM
Arguments:
-Dclient.encoding.override=UTF-8

5. Click OK.
6. Return to Servers → Application Servers and repeat the previous steps for
STServer and STCenter.
7. Click Save on the console taskbar.
Note: All application servers must be restarted for the change to take affect.
We are done with the WAS/EMS server for now. Next we install the Domino
infrastructure on a separate box that will eventually become our Sametime room
server.
Prerequisite - install Domino on the first room server

To do this:
1. For type of installation, select Domino Enterprise Server.
2. After files have been copied, navigate to Start → Programs → Lotus
Applications → Lotus Domino Server. This will launch the configuration
part of the Domino install.
3. On the On First or Additional Server step, select First or Stand-alone.
Click Next.
4. On the next four screens enter the following information:
– Server name: Enter <servername>.
– Organization name: Enter <servername>.
– Certifier password: Enter a password.
– Domain name: Enter <servername>.
– Administrator's name - Domino Admin.
– Administrator's Password - password.
– For the type of services to provide, check Web Browsers (HTTP
services) and uncheck Directory Services (LDAP services). Click Next.
– Under Network Settings select Customize and ensure that the TCPIP
server name has a fully qualified name listed. Uncheck NetBIOS and click
OK.
5. Click Next and accept the defaults on the Next page and click Setup to
complete installation.
6. Start Domino once to make sure that it has installed correctly by
double-clicking the icon on the desktop. Choose to run it as a service (never
choose it to run as an application), and while you do not necessarily need it to
start every time Windows starts, making the icon always start Domino as a

Windows service is a general best practice. Assuming that Domino seems to
start successfully, shut it down by typing quit or q at the console window.
7. Go to C:\Lotus\Domino and run nlnotes.exe.
8. Open the names.nsf database (File → Open → Database), navigate to
Configuration → Web → Web Configuration and delete the existing SSO
document from the * - All Server - header, if present.
9. Locate the WebSphere SSO key that was generated previously and copy it to
the room server.
10.Navigate to Servers → All Server Documents, click the Web icon, and
select Create Web SSO Configuration. Click Import Keys and in the dialog
box type in the path to the SSO key.
Note: The file was saved in C:\IBM\WebSphere\AppServer\profiles\default.
11.In the newly created document, enter the following fields. Note that all fields
must be identical to the information in WebSphere.
– DNS Domain: domain.com
– Expiration: 120
– Domain Servers: Use the directory to select all servers that will be listed in
the community.
Note: Make sure that there is a backslash before the :389 (for example,
\:389).

13.Open the server document, navigate to the tab of Internet Protocols →
Domino Web Engine, and select from the drop-down list for the following
fields:
– Session authentication: Multiple Servers (SSO)
– Web SSO Configuration: LtpaToken
14.Save and close the document.
15.When finished start Domino to confirm the install.
We are finished with installing the environment. Now let us begin the actual
installation of EMS and Sametime.

10.8.2 Sametime EMS installation
Now that the prerequisites are complete, we are ready to proceed with the
installation of EMS.
1. On the WAS/EMS server, install the new Sametime EMS build by running
demo32.exe from the EMS folder on CD3.
2. On the Choose Setup Language screen, click OK.
3. On the Welcome screen, click Next.
4. On the Accept Software License Agreement screen, click Accept.
5. On the Information screen, click Next.
6. On the Verify Location to Install Files screen, click Next (that is,
C:\WebSphere\WebConferencing).
7. On the Enter Location of IBM WebSphere Application Server screen, click
Next (that is, C:\WebSphere\Appserver).
8. On the Summary Information screen, click Install.
9. On the Setup Complete screen, click Finish.
Create a database for Sametime EMS on DB2

To do this:
1. Open the command prompt on the server.
2. In the Command Prompt window, change to the directory
<root>:\WebSphere\WebConferencing.
3. From the command prompt, run the following command:
createstdb db2admin
4. When prompted, enter the password for the DB2 server administrator. Press
Enter. After a brief delay, a succession of SQL command completed
successfully/The SQL DISCONNECT command completed successfully
messages appears on the screen.
Catalog the Sametime DB2 database
Attention: This step is only needed when using remote DB2 database.
To do this:
1. Open the DB2 Client Configuration Assistant (Start → > Programs → IBM
DB2 → Client Configuration Assistant).
2. Select Add.

3. Select Manually configure a connection to a database and click Next.
4. Under Protocol select TCP/IP and click Next.
5. On the next page, enter the following information:
– Host Name: fully qualified server name of the DB2 server
– Port Number: 50000
– Leave Service Name blank and click Next.
6. On the next page, enter the following information:
– Database Name: Sametime
– Database Alias: Sametime
– Leave Comment blank and click Next.
7. On the next page uncheck Register This Database for ODBC, then click
Finish.
8. Test the connection by entering the DB2 admin login information.
9. Close the DB2 Client Configuration Assistant window.
Deploy the StAdmin, STServer, and STCenter (.ear) files

Note: The following steps will be used to deploy all three of the
above-mentioned .ear files.
To do this:
1. Open a command prompt on the EMS/WAS server and stop the STCenter,
STServer, and STAdmin application servers (or verify that they are stopped).
Only server1 should be running. You can issue the command 'serverStatus
-all' to determine the server status of all.
2. Go to the WebSphere Administrator Console by opening a Web browser and
entering the https://localhost:9043/ibm/console/logon.jsp and log in.
3. Navigate to Applications → Install New Applications.
4. Select Local Path and click Browse (if you are running the browser from the
WAS/EMS server). Or select Server Path and enter the server path (if you
are not working local).
5. In the C:\WebSphere\AppServer\installableApps folder, select the .ear file
STAdmin, STServer or STCenter.ear from the list and click Open.
6. Click Next.
7. Check the box labeled Generate Default Bindings.
8. Select Override Existing Bindings.
9. Check the radio button Use default virtual host name for Web modules.

10.Click Next.
11.At the Application Security Warnings page click Continue.
12.Click Next.
13.At Step 2: Map modules to servers: From the list, select the server name (.ear
file being installed) and webserver1 and check the boxes for STAdmin
EJB™ and STAdmin WAR. Click Apply when done.
14.Click Next.
15.Click Next.
16.Click Next.
17.Click Next.
18.At Step 6: Map resource references to resources, select
jdbc/SametimeDataSource.
19.Select Node01/db2admin for the Use default method field.
20.Check the boxes STServer EJB and STServer War.
21.Click Next.
22.Click Next.
23.At step 8: Map security roles to users/groups, check the boxes for the
following:
– stadmin
– stmanager
– stservices
24.Click Lookup Users.
25.n the Search String field, enter the WAS/EMS Admin user name and click
Search.
26.Select the appropriate user and click >> to move the user to the Selected
column.
27.Click OK.
28.Check the Everyone? box for (varies for different .ear files)
– steditor
– stcreate
– stattend
– stlist
– stbrowse
– stuser
– Everybody

29.Check the All Authenticated box for (only for STCenter):
– stauthenticateduser
– stonlinemeeting
30.Click Next.
31.Click Next.
32.Click Finish.
33.When the installation completes a message appears indicating that the
installation completed successfully.
34.Click Save to Master Configuration.
35.Confirm by clicking Save. Note: This will take some time.
36.Remember to do this for all three EARs, making sure to get the roles correct.
Generate and propagate the Web server plug-in
Note: This step updates the Web server to know where to find pages on the
EMS server. This step assumes that IBM HTTP Server is running on the same
machine as EMS in a pilot environment.
To do this:
1. In the WAS Admin console go to Servers/Web servers.
2. Check the box next to webserver1 and click the Generate Plug-in button.
3. Check the box again and click the Propagate Plug-in button. The Web
plug-in will be pushed to your HTTP server directory correctly.
Room server setup

These instructions apply to restart (stop and start) of room servers (Domino
servers at this point).
1. Locate the Domino Console window (which contains the orange icon on the
tool bar) and type quit in the window. It will take a few minutes to shut down
and the Domino console will go away.
2. To restart, go to Start → Programs → Lotus Applications and select Lotus
Domino Server.

Note: Once added, room server status can be monitored via the EMS Admin.
Open a browser and enter the URL:
http://<fully qualified server name>/iwc-admin/client
Log in using the WAS/EMS Admin user name and password.
Install Sametime room server

To do this:
1. Make sure that the Domino Console is not running.
2. Run STServer_win32.exe from the Sametime Room Server install.
3. On the Choose Setup Language screen, click OK for English.
4. On the Software License Agreement screen, click Accept.
5. On the Select the Directory Type screen set it to LDAP Directory and set the
following fields to:
– LDAP Server Name: Set it to the same LDAP server set on the WAS/EMS
server.
– Port number: Set it to the same LDAP server port number set on the
WAS/EMS server (typically 389).
– BaseDN: for example, o=ibm,c=us
6. Click Next.
7. On the Summary Information screen, click Install.
8. On the Setup Finished screen, click OK and click Finished.
Add Sametime room server to EMS

To do this:
1. Go to Start → Run and type C:\lotus\domino\nlnotes.exe.
a. In Notes open the da.nsf database (File → Database → Open) and type
da.nsf in the bottom field.
b. Navigate to the LDAP tab and locate the Base DN field. Verify (or type in)
the same base DN used for the WebSphere EMS server. Press the Esc
key to save and exit the document.
2. Open the stconfig.nsf database (File → Open → Database) and navigate
and open the LDAPServer document. Double-click to put the document into
edit mode. Locate the Search Base and Scope heading and enter the base
DN used for the WebSphere EMS server in the two Base Object fields below
the header. Press the Esc key to save and exit the document.

3. Open the MeetingServices document. Under the Remote Services Access
section (found at the bottom), enter the user name and password of the
WAS/EMS Admin (wpsadmin) in all five sections. Press the Esc key to save
and exit out of the document.
4. At this point you should test Sametime by starting Domino and waiting for all
of the Sametime services, including the Windows Services, to start. Log in as
a user in the LDAP and join the test meeting. If this is successful, shut down
Sametime and proceed.
5. Add a network share for record and playback:
a. Choose a host system for the network share.
b. On that system, create or chose a directory for the share. Create the share
with everyone having full control. It should only be necessary to add the
users from step (g.) below.
c. In this location, create a directory for each room server that will be
managed by the EMS.
d. Choose a drive letter that is available on all room servers and the EMS.
e. Map the share on each of these systems as this same drive letter.
f. In the stconfig.nsf database go to the Meeting Services document. Set the
Record Meeting Settings → Directory Path setting to the directory for this
room server within the share (for example,
T:\RecordedMeetings\servername\). The trailing backslash is crucial. Do
not leave it out.
g. Open the Services panel on the room server. Navigate to and right-click
the Sametime Meeting Server service. Select properties, and on the Log
On tab, change the service to log on as a user account rather than the
local system account. Any user account that has access to the network
share should work. Enter the appropriate password for the user.
Note: If the room server has already been added, you can change the
record path in DB2. It is stored in stconfig.serverapplication. The field
name is "MTGCNTRRECORDMEETINGSPATH".
6. With the stconfig.nsf database still open, navigate to File → Database →

Access Control. Click Add. In the Add User dialog, manually add the
WAS/EMS admin name in the following form (for example,
wpsadmin/Lexington/ibm/us). Also add the short form (for example,
wpsadmin).
7. Give the user manager access and check Delete documents,
DatabaseAdmin, SametimeAdmin, and SametimeMonitor.

8. Start the room servers. Go to Start → Programs → Lotus Applications and
select Lotus Domino Server. Note that STAdmin must be running on the
WAS/EMS server before adding the room servers.
This is done by opening a DOS prompt (or one may be currently open).
Navigate to C:/IBM/WebSphere/Appserver/bin and type startserver STAdmin
(this is case sensitive).
9. Open a Web browser and navigate to http:\\<HTTP Server>\iwc-admin\client.
Log in using the WAS/EMS admin user name and password.
10.On the Configuration - Meeting Cluster screen, enter the following:
– Host name of EMS cluster: fully qualified name of the HTTP server
– Name: WebSphere/EMS admin user name (that is, wpsadmin)
– Password: WebSphere/EMS admin password
Click Add.
11.Stop and start STAdmin on the WAS/EMS server.
12.Again open a Web browser and navigate to http:\\<HTTP
Server>\iwc-admin\client. Log in using the WAS/EMS Admin user name and
password.
13.Navigate to Configuration → Configuration → Meeting Cluster → Add a
Meeting Server tab and enter the following:
– "Host name, IP address, or full URL of the additional server": room
server's fully qualified host name
– Name: WebSphere Admin user name
Note: Depending on the environment you may need to use the

Sametime/Domino Admin user name and password instead
– Password: WebSphere Admin password (See note above.)

14.Click Add and after receiving a successfully added message.
15.Shut down the room servers and STAdmin.
16.On the room server (1or 2) navigate to C:\Lotus\domino\ and open
sametime.ini in Notepad. At the end of the [Config] section of the document,
add the following lines (this is case sensitive):
SametimeAdminUsername= enter the WAS/EMS Admin username (for
example, wpsadmin)
SametimeAdminPassword= enter the WAS/EMS Admin password (for

example, password)
17.Start STAdmin, STServer, STCenter, and room server.

18.Go to the URL http://<EMS server name>/iwc/center and enjoy your meeting
server deployment by creating and joining a meeting.
At this point, you have successfully deployed an Enterprise Meeting Server

environment.
10.9 Troubleshooting EMS

In order to be truly effective at solving problems, you need to have a firm
understanding of not only how things work, but how they all work together. That
way if one specific piece of functionality is not working, you can go backwards
and find the cause.
򐂰 It is a very good idea to check out log files on the room server such as the
sametime.log located in the Domino program directory, and the files in the
trace directory.
򐂰 On the EMS/WAS side, check out the three servers’ various start, stop, and
error logs for plenty of information. Both WAS/EMS and Domino/Sametime
have the ability to look at logs via their Web-based administration tools.
Issue - you cannot log into the EMS server

Let us first explain the process of what goes on when you click the Login button
on the main meeting page. First of all, IHS (talking to the WebSphere application)
is handing Web traffic from your browser to the server. When you enter your
credentials and click the Login button, a multitude of steps occur under the
covers. Your authentication session is handed to WebSphere, which then hands
off to its security model. Remember the security page in the WebSphere
administrator? Those values define exactly how EMS is going to talk to your
LDAP server. Remember, an LDAP server is like a tree structure full of names,
and we have to know where to start to find those names and what to search for.
Tools such as the Softerra LDAP Browser are invaluable in troubleshooting
authentication and LDAP issues in general. If you can get an LDAP browser to
work with your LDAP server, then EMS and Sametime should work properly as
well.
So from the top, WAS looks at the LDAP host name and port specified so that it
knows where to find this directory, and whether it is using a secure connection.
Obviously there is more to securing an LDAP connection than just changing the
port, but you get the idea — we need the correct port the LDAP service is
listening on.
Second, we may have to bind as a user to the LDAP server to be able to do

lookups properly. Some LDAP servers such as Active Directory usually require

binding as a user in order to browse all of the users on it. Keep in mind that this
user is generally of the long, fully qualified format such as:
'uid=rfox,cn=users,dc=lexington,o=ibm,c=us'.
For WebSphere, if the search filter is set up properly you can just use the short
name 'rfox' or however you've defined the filter (which we will get into soon).
Obviously, if the password or user is incorrect, you will not be able to bind to the
LDAP server and do look ups. WebSphere generally does not allow you to
continue with incorrect login information, but if those credentials change you
know now where to look. Again, most LDAP servers do not require a bind
account, as they have anonymous binding enabled, but do not be alarmed if the
directory at a secure customer site needs it. The next field in question is the
base DN. This is where in the tree to start looking for users. Obviously, if the
person you are trying to authenticate as is not in the same scope as your base
DN, you are not going to be located and thus not be able to log in. Softerra again
is a great tool for figuring out where a user actually is in the directory.
Note that Sametime has two places it refers to as base objects. This is the same
as the base DN.
Lastly, we look at the search filter. Whatever you typed in at the login prompt is
going to be included in the search of various attribute values. If they match, then
the user is authenticated. If you click a specific user while the Softerra LDAP
Browser is connected to an LDAP server you will see a large number of attributes
such as cn, uid, mail, and so on, with values specific to the user. Also, you will
see a few attributes called objectclass that have values such as person,
inetOrgPerson, group, groupOfUniqueName, and so on. Let us look at this
sample filter:
(&(objectclass=inetOrgPerson)(|(cn=%v)(uid=%v)(mail=%v)))
Notice the & and | symbols? They refer to AND and OR, respectively. Logically
you can look at those symbols and figure out what it is trying to do. Basically, this
filter says “Look for any entry in this directory were the objectclass is equal to
inetOrgPerson (meaning that the entry refers to a person) AND either their
unique ID (uid), OR full conotical name ('cn') OR email address ('mail') is equal to
whatever the user typed in". We can put all of this information in our LDAP
browser and replace the variables with what we typed in and make sure a user is
returned. The Softerra LDAP Browser has a directory search option, so you can
put in your base DN and put in a search filter with the variables replaced and see
if what you expect is returned, like this:
(&(objectclass=inetOrgPerson)(|(cn=Rob Fox)(uid=Rob Fox)(mail=Rob
Fox)))

Now if we look at this more closely, we see that while we do not find a person
entry where the e-mail address or unique ID is exactly Rob Fox, but we can find a
full name entry of Rob Fox, and thus my name should be logged in. There are
other things to remember such as verifying that your user ID map is correct (it is
often *:cn, which means whatever is returned to refer to their cn attribute), but for
the most part we have gone through the entire authentication process. Do not
forget, there are WAS trace files that you can dig through to get further hints on
why you can or cannot log into the WAS/EMS server.
Issue - you can log into EMS, but you cannot join a meeting
This can be a multitude of problems as well, so let us start at the top.
Once all of the above has occurred, WebSphere generates an LTPA token,
which is based on when you logged in, your name, the name of the server, and a
few other things. This token can be passed by the browser to other servers in the
same domain, and if they have all been configured properly the user is not
prompted for authentication. You can test SSO easily by logging into the WAS
server and then immediately typing the URL of a Sametime server in the same
SSO DNS domain. If SSO is configured correctly, you will be logged into the
other server without being prompted or typing anything in. This is not strictly a
WAS-to-Sametime server thing. If you have SSO set up between different
Domino servers like QuickPlace/Quickr or different WAS servers like Portal you
can do the same type test. If you would like to see your LTPA token, simply log in
to the main EMS page and then put this exact text in the URL (this can be done
on any Web page that generates a cookie):
javascript:alert(document.cookie)
You will see a pop up with some information in it, including the LTPA token,
which is just a lengthy string of characters. Now, when you click the Join
Meeting button from EMS, your Web browser is being redirected to an actual
room server. Since you are going to another server, you need to be
authenticated again. If SSO was set up properly, then the generated SSO token
will match what would be generated on the Sametime server, and you will be
allowed in. The token is based on a few things: a unique string generated by
WebSphere, the domain.com piece of the DNS entries of all servers involved
(this is why you cannot log into an EMS or Sametime server with just the IP or
just the short host name — they all need the fully qualified DNS names or
FQDN), the time (the clocks on all servers should be in sync and the SSO
timeouts should be the same), and the LDAP server and port used. After verifying
that these items are consistent between the WAS server and each Sametime
server, make sure that WAS generated the key file correct, and the key file was

imported into Domino correctly. Remember, when entering the LDAP server
name (realm) in Domino make certain that you place a black slash before the
:389, so it looks a little something like this:
ldapserver.domain.com\:389
Now that is just getting access to the Web pages themselves. What if the applet
downloads properly but the Meeting Room Client itself throws a login error?
Everything we talked about thus far only refers to the Web portion of Sametime.
We should now look at the back end piece to see how authentication is handled
there. Core Sametime LDAP configuration is not set up on the WAS security
page or the Domino da.nsf (directory assistance) database. Those are only for
Web-based authentication. Community services (and as such the MRC) are
configured for LDAP via the Sametime Web admin in the LDAP section or directly
in the LDAP document in the stconfig.nsf database. Remember, when you join a
meeting you also join a community place. This is why you cannot just cluster
meeting servers and why we need community to be configured close to WAS.
Very similar to the above, it is important for the base DN (base objects), search
filters, and LDAP servers to match. Also note that Sametime uses %s* and %s in
its filters. Use those variables instead of %v like you did for WebSphere. You can
test to see if the community is configured for LDAP by logging into the Connect
client. If that works then you are good to go. The important thing to take away
here is if you are having problems authenticating through the Web, look at
WebSphere's security page and Domino's directory assistance database. If you
are having problem entering a meeting or logging in with the Connect client, look
at the Sametime Web admin LDAP configuration (or directly at the LDAP
document in stconfig.nsf). Different pages handle the different required
authentication mechanisms, so do not go looking in da.nsf if you cannot log in
with the Connect client.
Issue 3 - you cannot add a room server

When you try to add a room server, a log file is created detailing any successes
and failures. When you add a room server to EMS it verifies that the LDAP
configuration is the same, reads in applet version files, reads in Sametime
deployment information such as if HTTP tunneling, is enabled, and changes
where Sametime gets its configuration information from. Especially with the first
server (any additional room servers added will use this as its base configuration),
as long as you have your Sametime server configured how you want, the
administrator user name and password in the Meeting Services document in the
stconfig.nsf database filled out properly, and your LDAP configuration correct,
adding a room server is a snap. If you ever need to change a configuration
aspect of Sametime such as enabling tunneling, changing the applet version, or
anything else that is not readily available through the Sametime Web Admin, it is
probably easiest to remove the room server, make the changes and read it.

Issue 4 - your room servers do not change status from server
down/unavailable to running
This could be a myriad of things. First we describe how a room server starts up,
and then how EMS looks for it. Once we have all of those steps down, you
should be able to easily determine any problems.
To start a room server, start the Lotus Domino Server service (do not run it as an
application, run it as a service). Domino will go through its usual start up process.
We care most about two Domino tasks — the HTTP process and the STAdmin
process. These can be found in the notes.ini under the tasks line. Remember
those servlets we talked about a while back? In order for those to start, the
Domino Servlet engine needs to be enabled in the server document for the
Sametime server. If the servlet engine is running, it then looks at the
servlet.properties files in the Domino data directory to determine which servlets
to run. There are several Sametime servlets that need to run, so if you watch the
Domino console you will see these Sametime servlets starting up and
successfully initiating.
Keep in mind that if HTTP tunneling is enabled the server document should
reflect the Domino HTTP task running on a different port like 8088, and in
sametime.ini the Sametime mux will be on port 80. Also remember if this
configuration is in place, port 80 traffic will not work until the ST mux service has
started.
The next Domino task we want to start is STAddin. This Domino task starts the
Sametime Meeting Server service (which you can see if you enabled Interact
with Desktop at the Log on tab in Windows Services), which starts a few services
before it starts the critical service, the Configuration Bridge. Now this is where the
main difference between a Sametime server and a room server becomes
obvious. In the sametime.ini you will see an entry for ConfigurationHost. For a
Sametime server that entry is usually the FQDN and port 80 or 443. The
Sametime server then proceeds to connect to the a configuration URL based on
this entry. Locally this is the scs servlet that contains all configuration for the
Sametime server. Once the Configuration Bridge reads in all of this information,
the rest of the Sametime Meeting services will kick off quickly, such as the
gateway, broadcast service, and so on. You can see what the Sametime
configuration URL looks like by typing this in your browser:
http://sametimeserver.domain.com/servlet/auth/scs?xpath=
Now, if a Sametime server has been converted to a room server, the

ConfigurationHost entry in the sametime.ini of the room server is not going to
point to itself, but rather to the EMS server. The URL of configuration information
that EMS uses is:
http://emserver.domain.com/sametime/auth/scs?xpath=

Now to finish, after the configuration data has been read and all of the meeting
services have started successfully, STAddin starts the ST Community Launch
service, which eventually starts the other 11 community services. Remember that
Meeting Services are all the whiteboard and application-sharing services running
on ports 1503/1516 (server/server) and 8081 (server/client), and Community
Services are all of the green light instant messaging services running on port
1516 (server/server) and 1533 (server/client). Once all of this stuff is started up,
then the room server is ready to be used by EMS. Concurrently while all of that
was starting up, on the EMS server the STServer server is constantly polling its
room servers to see whether they are running all of their services correctly. You
can make sure that this server (and others) are running by issuing this command
at the WAS command prompt:
serverStatus -all -usersname wpsadmin -password password
If you are on *nix do not forget the ./ (dot slash) in front of the command. Make
sure that the three EMS servers are running, remembering that STServer does
most of the dirty work, STAdmin does all of the writing to DB2, and STCenter
makes the Web UI available. If one of these servers is not running or appears to
be acting strangely you can run these commands to start and stop them as
necessary:
startServer STWhatever
or
stopServer STWhatever -username wpsadmin -password password
Do not forget that all of these commands are case sensitive and you need proper
credentials to stop servers in WebSphere. Once STServer determines that a
room server is running everything correctly, it will change that server status to
running and then deploy meetings on it.
Issue 5 - meetings will not go active

The STServer creates the meeting by accessing a servlet called the MMAPI on
the room server. You can test to make sure that this servlet is working properly
by going to this URL on the Sametime server:
http://roomserver.domain.com/servlet/mmapi
You will be prompted for credentials. Remember when you entered a user name
and password in the Meeting Services document for five different entries? Those
credentials are what we are looking for here. If you enter them correctly you get a
red and blue five-line piece of XML that looks like an error but it is not. When fed
the proper data, that servlet is what actively creates the meeting on a room
server, so make sure that all of the steps have been followed correctly. It is also

possible that something may have happened to STServer, so restarting it could
fix the problem as well.

11
Chapter 11. Sametime Gateway

This chapter is an overview of the Sametime Gateway and describes the
underlying architecture of the Sametime Gateway. It also highlights specific
recommended topologies.
Important: For actual details on how to install and configure the Sametime
Gateway, refer to the Sametime Gateway Information Center, available at:

11.1 Overview of the Sametime Gateway
Lotus Sametime Gateway is a platform for presence and real-time collaboration
with other instant messaging communities. Sametime Gateway enables real-time
collaboration between communities such as Sametime and public instant
messaging services such as AOL and Google Talk. Sametime Gateway replaces
and enhances the Sametime SIP Gateway.
Sametime Gateway receives messages from one or more communities, checks

their legitimacy, translates their protocol as necessary, and forwards them to
their destination. Sametime Gateway is delivered with out-of-the-box
functionality, such as presence and instant messaging, filtering of blacklisted
domains, user access control, and event logging of user content, presence, and
instant messaging events. All interactions with external domains are logged. A
plug-in technology allows IBM and third-party developers to enrich and
customize message handlers for spam control and virus checking,
Sametime Gateway can enable, for example, a scenario where Alice works at
IBM and wants to talk to John, an IBM business partner who works at company
XYZ. Company XYZ has its own Sametime server. Although this server uses the
same protocol as the IBM server in Anne's unit, it can only work in the XYZ
environment because each company has its own defined users and their own
specifically defined community.
To bridge the communities, Sametime Gateway serves as an intermediary or

conduit between the two communities. Once a company's instant messaging
community is added to Sametime Gateway's list of communities, Sametime
Gateway checks each message to see if it has a route to the desired destination
and checks if there is permission to interact with the other system by means of
an Access Control List (ACL). If necessary, Sametime Gateway translates the
message into a protocol that either the local or external community can
understand and then sends it on its way. In a similar manner, Sametime
Gateway can be used to connect to a SIP community such as AOL Instant
Messaging or Yahoo! Messenger, or a community that uses the XMPP
translation protocol such as Google Talk.
You can install one Sametime Gateway server or cluster of Sametime Gateway
servers for a local Sametime community. A local community can be made up of
one Sametime server, or a cluster of Sametime servers connected by a common
directory. Sametime Gateway does not support more than one local Sametime
community.

Sametime Gateway can connect to external communities that use any of the
following gateways or communities:
򐂰 Sametime SIP Gateway (available in Sametime 6.5.1 and 7.0 versions)
򐂰 AOL Instant Messenger
򐂰 Google Talk
򐂰 Yahoo Messenger
Figure 11-1 illustrates the underlying business architecture, while 11.2,

“Overview of Sametime Gateway architecture” on page 742, discusses the
technical architecture in detail.
2 Submit provisioning
info to public IM
operator
Sametime 7.5
Provisioning AOL / Yahoo!
Application
4 Notify when
provisioning
complete
1 Request access 3 Enable
to AOL and/or customer
Yahoo! on network
5 Send email with
final instructions
Sametime Customer Public IM Networks

(Sametime Gateway Administrator)
Figure 11-1 Business architecture diagram
Chapter 11. Sametime Gateway 741

11.1.1 The business value
The Sametime 7.5.1. Gateway provides the following business value to your
organization:
򐂰 Employees need to do business communication over third-party networks.
The Sametime 7.5.1 Gateway makes this possible.
򐂰 The gateway enables personal communication with these other networks, too.
򐂰 The Gateway allows access to these services through a single client, with
access control and monitoring of activity.
11.2 Overview of Sametime Gateway architecture

The Sametime Gateway is built upon DB2, WebSphere Application Server, and
Sametime.
WebSphere Application Server and DB2

IBM Lotus Sametime Gateway runs on WebSphere Application Server.
WebSphere Application Server provides the following capabilities:
򐂰 Clustering support, robust failover capability using the High Availability
Manager
򐂰 Session Initiation Protocol (SIP) infrastructure, including stateless SIP Proxy
and SIP IP sprayer provided by the platform
򐂰 Open, extensible platform support. Additional plug-in services can be
configured in a flexible manner
򐂰 A central place to administer system configuration, monitoring, and security
policies through the Integrated Solutions Console and wsadmin script
commands.

DB2 is the storage for the Lotus Sametime Gateway policies and logging. DB2
can be clustered for failover and load-balancing purposes. DB2 is part of the
Lotus common storage strategy. Lotus Domino 7 can use DB2 as an alternative
repository, and Lotus Sametime Enterprise Meeting Server also uses DB2 for
storing and sharing configuration data across servers.
Admin UI/Script
Gateway
Sametime
Server VP Management
Connector Bean User Locator
plugin
External SIP
Sametime Connectors
SIP Connectors
Server SIP Connectors Core Plugin
ST SIP Manager ACL plugin
Gateway XMPP Core
Connector
Configuration Logger
GoogleTalk plugin
Figure 11-2 Overview of Sametime Gateway architecture
The Sametime Gateway Core is the central Gateway component that

coordinates the operation of the different supporting modules. The Core is
realized as both a J2EE enterprise application, as well as Java class libraries
running as WebSphere extensions.
򐂰 The Sametime Gateway Core:
– Starts and manages the different connectors.
– Routes the gateway messages.
– Manages the communities.
– Communicates with the plug-ins.
򐂰 The plug-in manager is responsible for:
– Establishing connections to each plug-in application

– Delivering messages in the correct order to the plug-ins
– Informing the Gateway Core of message status
򐂰 On startup, the plug-in manager:
– Takes from the configuration manager a list of all the plug-ins.
– Verifies that all the plug-ins are installed and started successfully
– Lists what messages each plug-in is interested in and invokes plug-ins in
the specified order
򐂰 There are three message plug-ins out of the box:
– UDL - to look up community information associated with the users in the
request
– ACL Manager - checks authorization to grant or deny the request
– Logger - generates activity logging

11.2.1 How it works
Figure 11-3 shows a local IBM Sametime community communicating together
with users from other companies and other instant messaging communities. The
local Sametime community relies on Lotus Sametime Gateway to connect to
instant messaging communities by means of translation protocols such as SIP
and Extensible Messaging and Presence Protocol (XMPP). You can use Lotus
Sametime Gateway to connect to Google Talk users, Yahoo! Messenger users,
AOL Instant Messenger communities, and other Sametime communities who
have Lotus Sametime Gateway or the Sametime SIP Gateway.
Lotus Sametime Gateway
SIP
SUBSCRIBE
VP Connector
mary@aol.com
Core
SUBSCRIBE
XMPP
joe@abc.com
Plugin
Plugin
Plugin
Lotus
Sametime Sametime
Community
Server Enterprises &
LDAP Public IM
Server Providers
External
users?
Figure 11-3 How it works
11.2.2 Recommended installation configurations

This section provides an overview of IBM Lotus Sametime Gateway components
and possible deployment configurations. IBM recommends that you install Lotus
Sametime Gateway on its own machine in the network DMZ.

Topologies
The Lotus Sametime Gateway can be used in three different topologies:
򐂰 Connecting to the AOL, Yahoo! Messenger, and Google Talk user
communities
򐂰 Connecting directly to other Lotus Sametime companies
򐂰 Connecting to other Lotus Sametime companies using the AOL
clearinghouse
You can set up any or all configurations as needed. Lotus Sametime Gateway
allows selected individuals in your company to send instant messages to users
on one or more public networks, giving your users immediate access to millions
of users worldwide.
Note: When you set up a connection with AOL, you have the option of
connecting with AOL users only, or connecting with the AOL clearinghouse
community that includes AOL, ICQ, iChat, and other users from AOL
Enterprise Federation Partner communities, including external Sametime
communities. IBM recommends that you do not configure both communities,
as users served by the AOL clearinghouse are a superset of users served by
the AOL community. If you set up AOL only, and later decide to connect with
the AOL clearinghouse community, delete the AOL community first before
adding the AOL clearinghouse community to Lotus Sametime Gateway.

Connect to the AOL, Yahoo! Messenger, and Google Talk
user communities
Figure 11-4 illustrates a topology for connecting to the AOL, Yahoo! Messenger,
and Google Talk user communities.
AIM
User
AOL
DMZ
Internet
Yahoo!
Sametime Sametime Firewall Sametime Firewall
Users Community Gateway
Server Yahoo!
Messenger
User
Google
LDAP DB
Server Server Google Talk
User
Figure 11-4 Topology recommended for connecting to AOL, Yahoo! Messenger, and Google Talk user
communities

Connect to other Lotus Sametime companies
When you connect to other Lotus Sametime companies, you can connect
business users of different companies (Figure 11-5). This deployment is very
useful in case of acquisitions when IT infrastructure is still separate, when you
want to interconnect vendors over the Internet. Connections are made secure by
using an SSL certificate exchange.
Company A Company B
Sametime Sametime Sametime Firewall Firewall Sametime Sametime Sametime

Users Community Gateway Gateway Community Users
Server Server
LDAP DB DB LDAP
Figure 11-5 Connect to other Lotus Sametime companies
11.2.3 Recommended deployment

IBM recommends that you install Lotus Sametime Gateway on its own machine
in the network DMZ. Firewall restrictions make it impossible for users from the
Internet to directly access a Sametime server on your corporate intranet, but
Internet users can access Lotus Sametime Gateway in the network DMZ. While
installing components such as a Sametime Community server and LDAP on the
same machine is possible, these components perform best when installed on
their own machines and are most secure when behind the internal firewall.
However, if you need to allow users on your corporate intranet and users from
the Internet to attend the same Sametime meetings, you can install a Sametime
Community server in the network DMZ and another Sametime Community server
behind the internal firewall.

Note: DMZ is a networking term that comes from the military term
demilitarized zone. DMZ refers to an area of a network, usually between two
firewalls, where users from the Internet are permitted limited access over a
defined set of network ports and to predefined servers or hosts. A DMZ is
used as a boundary between the Internet and a company's internal network.
The network DMZ is the only place on a corporate network where Internet
users and internal users are allowed at the same time.
Network Address Translation (NAT) is supported between local Lotus Sametime

community servers and Lotus Sametime Gateway 7.5.1, but NAT is not
supported between Lotus Sametime Gateway and the Internet, because of a
limitation in the SIP protocol. A NAT-enabled firewall does not work with some
Internet protocols, including the SIP protocol, which Sametime Gateway uses to
exchange messages with AOL Instant Messenger, Yahoo! Messenger, and other
Sametime communities. However, NAT has no effect on the XMPP protocol, so
exchanges using Google Talk over XMPP would be permitted to pass through a
NAT-enabled firewall that is between Sametime Gateway and the Internet.
DB2 can be located either on the same machine as Lotus Sametime Gateway in
the network DMZ or on a separate machine behind the firewall. Best practices
recommend running DB2 on its own machine, but if it is installed on the same
machine as Lotus Sametime Gateway, DB2 does not significantly impact
performance.
For small test configurations only, you can install Lotus Sametime Gateway on
the same machine as the Sametime server, DB2, or other applications. For a
production environment, your Sametime Community server should be installed
on a separate machine from your Lotus Sametime Gateway.
11.3 Overview of the steps involved for installation

The following high-level steps are involved in the installation of the Sametime
Gateway:
1. Installing DB2 and creating the databases
2. Installing Sametime Gateway
You can install a Lotus Sametime Gateway server or upgrade an existing
Lotus Sametime Gateway server. The infocenter discusses procedures for:
– Installing a single server
– A cluster of servers
– Upgrading a single server or cluster of servers

When installing a cluster, you install a primary server, a Deployment Manager
server, and at least one additional server on its own machine. You can install
the primary server and Deployment Manager on the same machine, or each
on its own machine.
3. Starting the server and starting the Integrated Solutions Console
4. Configuring the Sametime Gateway, including security and LDAP
5. Connecting servers to the Sametime Gateway, including:
– Opening the ports in the firewall
– Connecting instant message communities
– Connecting to external Sametime communities
6. Administering and tuning the Sametime 7.5.1 Gateway
Important: Each of the detailed steps for installation and configuration are
discussed in the Sametime 7.5.1 Information Center, available at:
11.4 Referring to the Sametime Information Center for

installation and configuration
The Sametime 7.5.1 Information Center has the most recent information system
requirements and installation steps for Sametime Gateway that uses DB2 as its
database, and IBM WebSphere Application to create a cluster for horizontal and
vertical scaling.
The information center contains steps for setting up a cluster, security, including
SSL, LDAP, and instructions on connecting to LDAP, a local Sametime server,
and external servers including other Sametime servers, AOL Instant Messenger,
Yahoo! Messenger, and Google Talk servers. It contains complete instructions
for setting up event logging, writing scripts to add users and new communities,
and administering Sametime Gateway on a daily basis.
Important: Each of the detailed steps for installation and configuration are
discussed in the Sametime 7.5.1 Information Center, available at:

A
Appendix A. Directory considerations for

Active Directory
This appendix discusses how to install and configure Active Directory 2003 for
use with Sametime 7.5.1.
Specifically, it covers the following topics:

򐂰 “Installing Active Directory on Windows 2003” on page 752
򐂰 “Populating the Directory Server using an LDIF file” on page 763
򐂰 “Configuring Microsoft Active Directory for SSL access” on page 764
򐂰 “Extending the schema” on page 789

Installing Active Directory on Windows 2003
Active Directory must be installed on a domain controller.
1. On the Windows 2003 server select Run and enter DCPromo, as shown in
Figure A-1.
Figure A-1 Run dcpromo to promote server to a domain controller
2. Click OK. Select Domain Controller for a new domain or Additional

domain controller for an existing domain. We selected to create a domain
controller, as shown in Figure A-2.
Figure A-2 Select Domain controller for a new domain

3. Click Next. Select which type of domain controller you want to create. You
have three options:
– Domain in a new forest
– Child domain in an existing domain tree
– Domain tree in an existing forest
We selected Domain in a new forest, as shown in Figure A-3.
Figure A-3 Domain in a new forest
Appendix A. Directory considerations for Active Directory 753

4. Click Next. We installed Active Directory on our QuickPlace server
qp.cam.itso.ibm.com. Enter the fully qualified DNS name for the domain
controller, as shown in Figure A-4.
Figure A-4 DNS name of domain controller
5. Click Next. The installation generates the NetBIOS name for the new domain
controller. You may see the dialog shown in Figure A-5.
Figure A-5 Default NetBIOS name

6. Click OK. You can now change the NetBIOS name. We accepted the default,
as shown in Figure A-6.
Figure A-6 Enter NetBIOS name

7. Click Next. You can then select the location and name of the database and
log folders. We accepted the defaults, as shown in Figure A-7.
Figure A-7 Database and log folders

8. Click Next. Then specify the folder to contain the shares’ system volume. We
accepted the defaults, as shown in Figure A-8.
Figure A-8 Folder to shared system volume

9. Click Next. The installation runs the DNS diagnostic and displays the results,
Figure A-9 DNS Registration Diagnostic results

10.If no errors appear click Next. Specify the permissions desired. We accepted
the default to set permissions compatible with only Windows 2000 and 2003
servers, as shown in Figure A-10.
Figure A-10 Set permissions

11.Click Next. Enter the Restore Mode Administrator password, as shown in
Figure A-11.
Figure A-11 Restore Mode Administrator Password

12.Click Next. The Summary dialog box will be displayed, as shown in
Figure A-12.
Figure A-12 Active Directory install summary

13.Click Next. The Active Directory installation wizard starts installing. This can
take awhile depending on the options selected. The Completing Active
Directory Installation Wizard dialog appears, as shown in Figure A-13.
Figure A-13 Completing the Active Directory Installation Wizard
14.Click Finish. You will be instructed to restart the server.

Populating the Directory Server using an LDIF file
Directory objects such as users can be added to the Directory Server using the
LDAP Import File (LDIF). The following is a excerpt of the LDIF file we used to
populate our Active Directory using the command:
ldifde -i -f usersl.ldif -s qp.cam.itso.ibm.com
Example: A-1 Excerpt of LDIF file

dn: cn=George Lambie,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=com
changetype: Add
objectclass: user
objectclass: top
givenname: George
sn: Lambie
cn: George Lambie
samAccountName: glambie
userpassword: password
jpegPhoto:< file:c:\photos\glambie.jpg
userPrincipalName: glambie@qp.cam.itso.ibm.com
dn: cn=Jennifer Wales,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=com

changetype: Add
objectclass: user
objectclass: top
givenname: Jennifer
sn: Wales
cn: Jennifer Wales
sAMAccountName: jwales
jpegPhoto:< file:c:\photos\jwales.jpg
userPrincipalName: jwales@qp.cam.itso.ibm.com
dn: cn=Andy Higgins,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=com

changetype: Add
objectclass: user
objectclass: top
givenname: Andy
sn: Higgins
cn: Andy Higgins
sAMAccountName: ahiggins
jpegPhoto:< file:c:\photos\ahiggins.jpg
userPrincipalName: ahiggins@qp.cam.itso.ibm.com
dn: cn=John Bergland,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=com

changetype: Add
objectclass: user
objectclass: top
givenname: John
sn: Bergland
cn: John Bergland
sAMAccountName: jbergland
jpegPhoto:< file:c:\photos\jbergland.jpg
userPrincipalName: jbergland@qp.cam.itso.ibm.com
dn: cn=Charles Price,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=com

changetype: Add

objectclass: user
objectclass: top
givenname: Charles
sn: Price
cn: Charles Price
sAMAccountName: cprice
jpegPhoto:< file:c:\photos\cprice.jpg
userPrincipalName: cprice@qp.cam.itso.ibm.com
dn: cn=Jim Puckett,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=com

changetype: Add
objectclass: user
objectclass: top
givenname: Jim
sn: Puckett
cn: Jim Puckett
sAMAccountName: jpuckett
jpegPhoto:< file:c:\photos\jpuckett.jpg
userPrincipalName: jpuckett@qp.cam.itso.ibm.com
dn: cn=Vineet Rohatgi,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=com

changetype: Add
objectclass: user
objectclass: top
givenname: Vineet
sn: Rohatgi
cn: Vineet Rohatgi
sAMAccountName: vrohatgi
jpegPhoto:< file:c:\photos\vrohatgi.jpg
userPrincipalName: vrohatgi@qp.cam.itso.ibm.com
dn: cn=Stephen Shepherd,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=com

changetype: Add
objectclass: user
objectclass: top
givenname: Stephen
sn: shepherd
cn: Stephen Shepherd
sAMAccountName: sshepherd
jpegPhoto:< file:c:\photos\sshepherd.jpg
userPrincipalName: sshepherd@qp.cam.itso.ibm.com
Configuring Microsoft Active Directory for SSL access

Once Active Directory is installed you need to install the Certificate Services.
Refer to:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=
/com.ibm.itame.doc/am60_install166.html
To add the certificate services, follow these steps:

1. Click Start → Control Panel → Add or Remove Programs.

2. Click Add/Remove Windows Components and select Certificate Services.
3. Select the CA type. Well selected Enterprise root CA, as shown in
Figure A-14.
Figure A-14 Select CA type

4. Click Next. Enter the common name, as shown in Figure A-15.
Figure A-15 Enter common name for certificate

5. Click Next. Change or accept the Certificate Database Settings, as shown in
Figure A-16.
Figure A-16 Certificate Database Settings
6. Click Next. You maybe prompted to insert the Windows 2003 Components
CD.

Adding certificate authority to Microsoft Management Console
As an administrator click Start → Run, enter mmc, and click OK. The
management console will display, as shown in Figure A-17.
Figure A-17 Microsoft Management Console

Click File → Add/Remove Snap-in. The Add/Remove Snap-in dialog box will
appear, as shown in Figure A-18.
Figure A-18 Add/Remove Snap-in

Click Add and the Add Stand-alone Snap-in will be displayed, as shown in
Figure A-19.
Figure A-19 Add Standalone Snap-in

Scroll and select Certificate Authority and click Add. The Certificate Authority
Dialog box will be displayed, as shown in Figure A-20.
Figure A-20 Certificate Authority

Select the local computer if you are running MMC or select another computer
and specify the computer DNS name. Click Finish. You are the returned to the
Add Standalone Snap-in dialog box, as shown in Figure A-19 on page 770. Click
Close and the Add/Remove Snap-in dialog box will show the Certificate Authority
added, as shown in Figure A-21.
Figure A-21 Add/Remove Snap-in with Certificate Authority

Click OK and the Certificate Authority snap-in will have been added to MMC, as
shown in Figure A-22.
Figure A-22 MMC with Certificate Authority
Click File → Save. We saved this MMC as Active Directory Certificate

Authority.msc.
Install trusted root from Domino Certificate Authority

Using the browser, access the Certificate Authority Database, as in our example:
http://dwa.cam.itso,ibm.com/itsoca.nsf.

Click Accept this authority in your server and highlight the entire certificate, as
Figure A-23 Domino Certificate Web Application

Copy the certificate to the clipboard using Ctrl+C. Using Notepad paste the
certificate and name the file ITSO.cer. Using the Active Directory Certificate
Authority MMC expand Certificates and highlight Trust Root Certificate
Authorities, as shown in Figure A-24.
Figure A-24 Managing trusted root certitude authorities

Right-click All Tasks → Import. The Certificate Import Wizard will appear, as
Figure A-25 Certificate Import Wizard

Click Next. The File to Import Selection dialog appears, as shown in Figure A-26.
Figure A-26 Certitude Wizard File to Import

Enter or Browse to itso.cer file, as shown in Figure A-27.
Figure A-27 Enter file to import

Click Next and the Select Certificate Store dialog appears, as shown in
Figure A-28.
Figure A-28 Certificate store selection

Accept to place the certificate in the trusted root authorities store. Click Next and
the Completing the Certificate Import Wizard Dialog will appear, as shown in
Figure A-29.
Figure A-29 Completing the Certificate Import Wizard
Click Finish. The Import Certificate Import successfully message box appears,
Figure A-30 Import certificate was successful message box

Click OK. You then click Certificate and then scroll to the trusted root certificate
for our ITSO organization. The certificate would have been issued to
dwa.cam.itso.ibm.com by dwa.itso.cam.ibm.com, as shown in Figure A-31.
Figure A-31 Certificate for our trusted root authority
Requesting server certificate from a third-party certificate authority

Refer to the following Microsoft knowledge base article:
http://support.microsoft.com/kb/321051/en-us
Create the .inf file. Example A-2 is a sample .inf file that can be used to create
the certificate request.
Example: A-2 Sample .inf file

1. Create the .inf file. Following is an example .inf file that can be
used to create the certificate request.
;----------------- request.inf -----------------

[Version]
Signature="$Windows NT$
[NewRequest]
Subject = "CN=<DC fqdn>" ; replace with the FQDN of the DC

KeySpec = 1
KeyLength = 1024
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication
;-----------------------------------------------

Note: Some third-party certification authorities may require additional
information in the subject parameter. Such information includes an e-mail
address (E), organizational unit (OU), organization (O), locality or city (L),
state or province (S), and country or region (C). You can append this
information to the subject name (CN) in the Request.inf file. For example:
Subject="E=admin@contoso.com, CN=<DC fqdn>, OU=Servers, O=Contoso,
L=Redmond, S=Washington, C=US."
In our example the request.inf file looks like that shown in Example A-3 on
page 783.
Example: A-3 Sample request.inf file

;----------------- request.inf -----------------
[Version]
Signature="$Windows NT$
[NewRequest]
Subject = "CN=qp.cam.itso.ibm.com, O=ITSO, L=Cambridge, S=Massachusetts, C=US."

KeySpec = 1
KeyLength = 1024
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication
;-----------------------------------------------
Create the request file. To do this, type the following command at the command
prompt and then press Enter:
certreq -new request.inf request.req

Open the request.reg file. Select the entire certificate and copy it to the clipboard.
Using the Certificate Authority Web Application, click Request a Server
Certificate. Fill in the fields and paste the certificate request into the box
provided, as shown in Figure A-32.
Figure A-32 Request server certificate for Active Directory Server

Click Submit Certificate Request. Once the certificate is approved by the
Certificate Authority administrator, the pickup ID will be sent to you by e-mail or
by phone. Click Pickup ID, as shown in Figure A-33.
Figure A-33 Pick up server certificate

Click Pickup Signed Certificate and the certificate will be displayed, as shown
in Figure A-34.
Figure A-34 Pick up of signed server certificate
Highlight the entire certificate including the begin and end certificates line, and
copy the certificate to the clipboard using Ctrl+C. Run Notepad and paste the
certificate into the Notepad area. Save the file as certnew.cer.
Open a command prompt window and enter the change directory (CD) command
to change to the directory where you saved the certnew.cer file.
Accept the issued certificate. To do this, type the following command at the
command prompt, and then press Enter:
certreq -accept certnew.cer

To verify that the certificate was installed open the Active Directory Certificate
Authority.msc. Expand Certificate (Local Computer) → Personal →
Certificate. You should see a certificate like that shown in Figure A-35.
Figure A-35 Personal certificate for Active Directory Server
Verifying that SSL is enabled on Active Directory Server

To verify that SSL has been enabled on the Active Directory Server:
1. Ensure that Windows Support Tools is installed on the Active Directory
machine. The suptools.msi setup program is located in the \Support\Tools
directory on your Windows installation CD.
2. Select Start → All Programs → Windows Support Tools → Command
Prompt. Start the ldp tool by typing ldp at the command prompt.

3. From the ldp window, select Connection → Connect and supply the host
name and port number (636). Also select the SSL check box, as shown in
Figure A-36.
Figure A-36 LDP Connection to AD Server via SSL
Note: Ensure that you type the Active Directory domain server name correctly.

If successful, a window is displayed listing information related to the Active
Directory SSL connection, as shown in Figure A-37. If the connection is
unsuccessful, restart your system and repeat this procedure.
Figure A-37 Results of SSL connection to Active Directory
Extending the schema

The following information can be found in help for the Microsoft Management
Console section “Extending the schema.” You can modify the schema through
graphical user interface (GUI) tools, command-line tools, and scripting. The
easiest way to modify the schema is by using the Active Directory Schema
snap-in in Microsoft Management Console (MMC), which is a GUI tool for
schema management.

Install the Active Directory schema snap-in
To do this:
1. Open the command prompt.
2. Type regsvr32 schmmgmt.dll. This command registers schmmgmt.dll on your
computer.
3. Click Start, click Run, type mmc /a, and then click OK.
4. On the File menu, click Add/Remove Snap-in, and then click Add.
5. Under Snap-in, double-click Active Directory Schema, click Close, and then
click OK.
6. To save this console, on the File menu, click Save.
7. In the Save in field, point to the systemroot\system32 directory.
8. In the File name field, type schmmgmt.msc, and then click Save.
9. To create a shortcut on your Start menu, right-click Start, click Open all
Users, double-click the Programs folder, and then double-click the
Administrative Tools folder.
10.On the File menu, point to New, and then click Shortcut.
11.In the Create Shortcut Wizard, in Type the location of the item, type
schmmgmt.msc, and then click Next.
12.On the Select a Title for the Program page, in the Type a name for this
shortcut field, type Active Directory Schema Management and then click
Finish.
Caution: Modifying the schema is an advanced operation best performed by

experienced programmers and system administrators. For detailed information
about modifying the schema, see the Active Directory Programmer's Guide at the
Microsoft Web site:
http://msdn.microsoft.com/
Note: To perform this procedure on a domain controller, you must be a member

of the Domain Admins group or the Enterprise Admins group in Active Directory,
or you must have been delegated the appropriate authority. As a security best
practice, consider using Run as to perform this procedure.
To open the Active Directory Schema snap-in, click Start, click Control Panel,
double-click Administrative Tools, and then double-click Active Directory
Schema.

You can also run the Active Directory schema snap-in from a computer running
Windows XP Professional. Simply install the Windows Server® 2003
Administration Tools Pack on the computer, and then complete step 9 above
The Windows Server 2003 Administration Tools Pack cannot be installed on

computers running Windows 2000 Professional or Windows 2000 Server.

Extending the schema to add attributes
Open the Active Directory Schema Management. Expand Active Directory
Schema and expand Attributes, as shown in Figure A-38.
Figure A-38 Active Directory Schema Management - attributes

Highlight Attributes and then right-click New → Attribute. You will receive a
schema object creation modification warning, as shown in Figure A-39.
Figure A-39 Scheme object creation modification warning
Click Continue and fill in the fields in the Create New Attribute form as shown in
Figure A-40.
Figure A-40 Create New Attribute
The Unique x500 Object ID needs to be numeric such as 1.1.1.1.2. It must be

unique. Click OK. Repeat, extending the schema to add the other attributes
(notescon, notesDN, mailfile, mailserver).

Then expand the object Classes and highlight the organizationalPerson
objectclass, as shown in Figure A-41.
Figure A-41 Active Directory Schema Management

Right-click Properties → Properties. The inetOrgPerson Properties dialog box
is displayed, as shown in Figure A-42.
Figure A-42 organizationalPerson Properties

Click Attributes and the list of attributes is displayed, as shown in Figure A-43.
Figure A-43 List of attributes for organizationalPerson

Click Add. The list of attributes to select appears, as shown in Figure A-44.
Figure A-44 List of attributes to select
Select Sametime Server and then click OK. Return to the list of attributes for the
inetOrgPerson object class (Figure A-43 on page 796). Repeat the process for
the notesDN, notesCon, mailfile, and mailserver attributes. When the last
attribute has been selected, click OK at the list of attributes, as shown in
Figure A-43 on page 796.

Adding attribute values
Values for the newly added attributes can be added via an LDIF file or via an
LDAP Administrative client such as LDP. Example A-4 is the LDIF file we used to
added attribute values for notesCon, notesDN, mailfile, mailservern, and
SametimeServer.
Example: A-4 LDIF file

dn: cn=Stephen Shepherd,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=com
changetype: Modify
add: notescon
notescon: CN=Stephen Shepherd/O=ITSO
-
add: notesdn
notesdn: CN=Stephen Shepherd,O=ITSO
-
add: mailfile
mailfile: mail\SShepher.nsf
-
add: mailserver
mailserver: dwa.cam.itso.ibm.com
-
add: SametimeServer
SametimeServer:
stchatcluster
To make the modification, open a command prompt window and enter the
command:
ldifde -i -f user.ldif -s qp.cam.itso.ibm.com

B
Appendix B. Directory considerations for

Domino LDAP
In this appendix we discuss directory issues involving Domino. The following
type of issues are discussed:
򐂰 Native Domino
򐂰 Domino LDAP
򐂰 Dual Directories using:
– Native Domino
– Domino LDAP

Native Domino
Sametime uses Domino Directories for authentication, authorization, community
services, and Meeting Services. Utilizing Domino Directories always involves
using Domino’s primary Directorynames.nsf. Directory assistance can be used to
include secondary Domino Directories or additional LDAP servers. However,
access utilizes Domino name and group lookups, and unique names formats
would be, for example:
CN=Stephen Shepherd/O=ITSO or Stephen Shepherd/ITSO
As opposed to:
CN=Stephen Shepherd,CN=users,DC=ITSO,dc=com
If Sametime is using native Domino Directories, then QuickPlace must also use
Native Domino Directories. If WebSphere Portal is deployed using a non-Domino
LDAP, you will see that Sametime and QuickPlace can still use the native
Domino directory.
SSL issues with Native Domino

Domino name and group looks do not utilize SSL. If directory assistance is being
used to access a third-party LDAP server, SSL should be set up for LDAP
channel encryption. This has already been covered in previous chapters,
specifically, see 7.3, “SSL encryption” on page 540.

When using Native Domino, this is not necessary.
Domino LDAP
Sametime can use a Domino LDAP server for authentication,
authorization,,community services, and Meeting Services. A separate Domino
Server is required. Do not use the Sametime server as the LDAP server even
though the LDAP server tasks can be run on the Sametime server.
If Sametime is using a Domino LDAP server than QuickPlace must use the same
Domino LDAP server. If WebSphere Portal is deployed using a non-Domino
LDAP you will see that Sametime and QuickPlace can still use a Domino LDAP
server.

Installing Domino LDAP
To install a Domino LDAP server all you need to do is install a Domino Server.
The LDAP server components get installed with the Domino Server. During the
setup you can chose LDAP as a component. If you do not chose LDAP during the
setup do not worry. It can easily be enabled. On any existing Domino Server the
LDAP task can be started and can be added to the servertasks line in the
notes.ini file as follows:
,LDAP
Appendix B. Directory considerations for Domino LDAP 801

Setting up SSL for Domino LDAP
On the LDAP server open the Admin Certificate Database certsrv.nsf shown in
Figure B-1.
Figure B-1 Server Certificate Admin Database

Click Create Key Ring and fill in the form fields, as shown in Figure B-2.
Figure B-2 Create Key Ring

Scroll down and click Create Key Ring. The Create Key Ring Confirmation
dialog is displayed, as shown in Figure B-3.
Figure B-3 Key Ring Created
Refer to “Create the Domino key file” on page 591 to install the trusted root
certificate from the certificate authority. In addition, using the Server Certificate
Admin database, you need to request a server certificate, submit the server
certificate request to the certificate authority, pick up the approved server
certificate, and install the server certificate into the key ring file. Also, make sure
that the server document is updated with the correct key file name. Refer to
“Modify server document” on page 596.

This is not necessary.
Dual directories
Customers have deployed Sametime and QuickPlace using Native Domino
directory or Domino LDAP. Then they want to integrate WebSphere Portal server
that is authenticating with a non-Domino LDAP server. The easiest
implementation has always been when all components authenticate against a

single Directory source. However, these customers already have deployed
Sametime and QuickPlace and invested, and converting to a new Directory
Source is not a simple process. So Sametime provides a mechanism to allow the
integration of these two components. We refer to this dual directories.
Dual directories with Native Domino directory

To configure the Domino directory on the Sametime server, Sync the user names
and passwords in the Domino directory with the names Portal uses to
authenticate a user. For example, if WebSphere Portal's user directory is Tivoli
Directory Server (TDS), and a user's distinguished name (DN) from IDS is
uid=sshepherd,user,cn=users,dc=ITSO,dc=com, then you will need to add the
uid=sshepherd/user/cn=users/dc=ITSO/dc=com to the User Name or Short
Name field of the person document for Stephen Shepherd, as shown in
Figure B-4.
Figure B-4 Domino Person Document for Stephen Shepherd
This entry should be added below the Domino canonical name, which should be
the top line of the User Name field, and common name (CN), which should be
the second line.

To configure the Sametime server to remap users' DNs when passed with an
LTPA token, set the following in the notes.ini file:
ST_UID_PREFIX=*
ST_UID_POSTFIX=*
Then add the following to the sametime.ini file under the [Config] section:
ST_DOMINO_DUAL=1
If you also want awareness capabilities in WebSphere Portal, make the following
configuration changes to CSEnvironment.properties. You should have already
enabled Sametime in WebSphere Portal, as documented in the WebSphere
Portal Information Center.
CSEnvironment.properties:
CS_SERVER_SAMETIME_1.nameFormatForResolve=dn
CS_SERVER_SAMETIME_1.dnNameSeparator=/
Dual directories with Domino LDAP

Sync the user names and passwords in the Domino directory on the LDAP server
with the names Portal uses to authenticate a user. For example, if WebSphere
Portal's user directory is Tivoli Directory Server (TDS) and a user's distinguished
name (DN) from IDS is uid=sshepherd,user,cn=users,dc=ITSO,dc=com, then
you need to add the uid=sshepherd/user/cn=users/dc=ITSO/dc=com to the User
Name or Short Name field of the person document for Stephen Shepherd, as
shown in Figure B-4 on page 805.
To configure the Sametime server to remap users' DNs when passed with an
LTPA token, set the following in the notes.ini file:
ST_UID_PREFIX=*
ST_UID_POSTFIX=*
Add the following sametime.ini settings under the [Directory] section:

ST_DB_LDAP_DEREF=3
Open stconfig.nsf on the Sametime server.

Open the LDAP document and ensure that the following fields are empty:
򐂰 Search Base and Scope
򐂰 Base Objects
򐂰 Base object when searching for person entries
򐂰 Base object when searching for group entries
If you want awareness capabilities in WebSphere Portal, make the following

configuration changes to CSEnvironment.properties. You should have already
enabled Lotus Sametime (also known as instant messaging and Web
conferencing) in WebSphere Portal, as documented in the WebSphere Portal
Information Center.
CSEnvironment.properties:
CS_SERVER_SAMETIME_1.nameFormatForResolve=dn

Adding photos for use with business cards
The design of the Domino directory needs to be modified to allow for the
inclusion of jpeg photos. The design of the directory already includes a
jpegPhoto attribute. However, it is a hidden field. If the photo is added to this field
in a person document the field will be removed if the person document is edited
and saved. You will need to make this modification using the Domino Designer
Client on the Domino directory template pubnames.ntf on the Domino LDAP
server. Once you have opened the directory in the designer, navigate to the
SubForm view, as shown in Figure B-5. To open the Subform view, select the
$PersonInheritableSubform and open the subform.
Figure B-5 Select $PersonInheritableSchema Subform

Find the field jpegPhoto and press Delete and then OK to confirm the deletion,
as shown in Figure B-6.
Figure B-6 Delete field jpegPhoto from $PersonInheritableSchema
Save the subform. Open the subform $PersonExtendableSchema and add a rich
text field named jpegPhoto, as shown in Figure B-7.
Figure B-7 $PersonExtendableSchema subform with jpegPhoto field

Save the subform. Open the Domino directory on the Domino LDAP server and
select File → Database → Replace Design. Select the Domino LDAP server
and then select the Domino directory template pubnames.nsf, as shown in
Figure B-8.
Figure B-8 Select Domino directory Template pubnames.ntf
Click Replace.
The jpeg photo can be added by many different LDAP utilities and management
programs. We used LDAP Modify, which comes with the Tivoli Directory Server.
You need to create an LDIF file similar to Example B-1.
Example: B-1 LDIF file to add jpegPhoto

dn: CN=Stephen Shepherd,o=itso
changetype: modify
add: jpegPhoto
jpegPhoto:< file:///c:\photos\sshepherd.jpg
Then use the following command:

ldapmodify -h dwa.cam.itso.ibm.com -D "cn=Sametime Admin,o=itso" -w
password -i shepherd.ldif

C
Appendix C. Project management guide

for an Enterprise Sametime
deployment
This appendix provides a high-level overview of the subject areas that should be
considered when approaching an enterprise deployment of IBM Lotus
Sametime. This material may be used as a guideline for identifying, scoping, and
implementing the key tasks involved with a rollout of Sametime 7.5.1 in the
enterprise.
Important: The project plan and tasks identified here apply to a generic
Sametime 7.5.x Deployment. This plan must be customized and made more
specific to your organization’s rollout.
The primary objective is to help you identify the key tasks that need to be
accomplished, understand the necessary dependencies between these tasks,
and gain a sense of relative duration and level of effort. The required duration
to accomplish these tasks depends upon your organization’s specific needs,
available resources to dedicate to the project, and finally, the level of skill
within your organization.

We begin with the topic of developing a business case that will drive the
Sametime deployment project. A business case is a description of the reasons
and the justification for undertaking the project. The reasons and justifications for
undertaking a project are based on the estimated costs, risks, and expected
business benefits. For many organizations the business case is considered
absolutely critical, and without it a project cannot be justified.
It is important that the scope of the project is fully understood and defined to
allow the plans to be created. The costs will be derived from the plans and
should be recorded in the business case. The other key area of the business
case is the benefits. These should be quantified and not left as intangible. Failure
to do this makes the project vulnerable to being closed down whenever the
organization experiences financial pressures.
Business case for Sametime deployment

The business case should include the following:
򐂰 Reasons
Why are we undertaking this endeavour? For example, in the situation of a
proposed Lotus Sametime deployment the reasons might include:
– To reduce e-mail and phone mail by 10% across the company
– To reduce the travel costs resulting from meetings conducted with
business partners in other geographies by $1M over the next 12 months
by introducing Web conferencing and online meetings
– To deliver an improved standard of customer service and achieve a
customer satisfaction rating of 95%
– To improve the productivity of the company's customer service help desk
by 20% over two years by providing quick communications on outages
and other situations affecting customers
򐂰 Options
List all the options that were considered. Give reasons for selecting the final
option and why the others were rejected. If this section is covered
comprehensively there will be fewer questions asked about the foundation of
the project since it will be clear that a number of options were considered.
Always include do nothing as an option. This can often help in the area of
benefits. In many companies if the option of doing nothing is examined, it
could show that failure to take action and run the project could contribute to
the company loosing business because of failure to reduce rising costs.

򐂰 Requirements
The high-level requirements of the project need to be defined at this stage
and included in the business case. The first step is to identify all the problems
that the project has been proposed to resolve. One approach is to run
workshops with the users to establish their current problems.
Example questions for organizations proposing to implement IBM Lotus
Sametime are:
– How many people in your organization will use Sametime?
– From how many different physical locations (for example, major corporate
population centers, data centers, satellite data centers, regional hubs)?
– What are the available network bandwidth capacities that exist between
the major data centers?
– How many people do you expect will be using Sametime concurrently?
– What types of Sametime services will they be using? Instant messaging?
Instant meetings and scheduled meetings?
– Is there a requirement to provide instant messaging connectivity with
external contacts (for example, customers or business partners who also
use IBM Lotus Sametime)?
– Is there a requirement to provide an external meeting service to allow
online meetings between both internal and external participants?
– Are there specific corporate security policies that must be adhered to?
– Will encryption of instant messages be required?
– Will location awareness be required?
– How many peak concurrent users for meetings?
– How many meetings are forecast per day?
– What is the forecast number of people per meeting?
– What is the average forecast meeting duration (how many hours)?
– What online meeting features and functions will be required (application
sharing, presentation mode, audio/visual)?
– Is there any specific Sametime customization to be provided?
– Will the deployment utilize any server-based plug-ins?
– Will IM awareness be used in applications (for example, Domino mail,
other applications)?
Appendix C. Project management guide for an Enterprise Sametime deployment 813

Project approach
IBM recommends that the Sametime Enterprise deployment project is
subdivided down into a number of stages (value frames), with each stage being
completed and approved before deciding to continue to the next stage. Each
value frame should be tied to a specific customer project goal and should deliver
defined value to the customer that can be measured through value frame exit
criteria.
For each value frame, a stage plan should be established and updated on a
weekly basis and fed into the overall Sametime Enterprise deployment project.
Milestones should be established to signify delivery completion and reporting
back to the project manager. Once the milestones are defined, the project plan
will be baselined and sent to the customer project manager for inclusion into
project reports.
The Sametime 7.5.1 project plan

The Sametime 7.5.1 upgrade project plan template is a reusable, best-practices
based template for Sametime 7.5.1 upgrade projects. The plan addresses
Sametime 7.5.1 upgrade efforts, and is applicable to both simple software
upgrade efforts as well as software extension development efforts. The template
provides a starting point for planning software deployment efforts.
The benefits of the IBM Sametime 7.5.1 upgrade project plan template are:
򐂰 Leverage best practices from a project management perspective.
򐂰 Leverage best practices and corporate knowledge for an IBM Software
Services-led effort.
򐂰 Reduce the amount of effort required to perform initiation and planning
activities.

The template is a preliminary plan for a full life cycle project associated with a
Sametime 7.5.1 deployment. Not all activities/tasks identified in the template will
be applicable to all project efforts. Additional activities/tasks will need to be
added depending upon the project.
Table C-1 Project initiation activities

Project initiation
򐂰 Define project charter.

򐂰 Identify project stakeholders.
򐂰 Define project scope.
򐂰 Finalize/approve statement of work.
򐂰 Identify/secure project resources.
򐂰 Conduct project kick-off session with client.
򐂰 Formalize project communication plan.
Table C-2 Project planning activities

Project planning
򐂰 Define/validate project assumptions/constraints.

򐂰 Review Sametime 7.5.1 features/functions (validate existing requirements).
򐂰 Identify release requirements/constraints.
򐂰 Identify administration, help desk, and end-user documentation needs.
򐂰 Identify administration, help desk, and end-user training/knowledge transfer.
򐂰 Define software upgrade effort.
򐂰 Define software upgrade effort approach.
򐂰 Define software upgrade effort tasks/activities.
򐂰 Define software extension effort.
򐂰 Define software extension effort tasks/activities.
򐂰 Determine project methodology approach/work products.
򐂰 Define project plan.
򐂰 Prepare software deployment plan.
򐂰 Prepare risk management plan.
򐂰 Prepare issues management plan.
򐂰 Prepare change management plan.
򐂰 Identify any project dependencies.
Table C-3 Design/development

Design/development (associated with software extension effort)
򐂰 Perform design effort.

򐂰 Perform development effort.
򐂰 Perform test effort.

Table C-4 Execution
Execution
򐂰 Deliver training/knowledge transfer.

򐂰 Update administration, help desk, and end-user documentation.
򐂰 Execute software upgrade.
򐂰 Integrate software extensions.
򐂰 Execute software deployment plan.
򐂰 Perform project management activities.
Table C-5 Closing

Closing
򐂰 Perform project closure effort.

򐂰 Document project lessons learned.
򐂰 Release project resources.
򐂰 Formally acknowledge project end.

Sample Sametime deployment project plan
The sample project plan and tasks identified here must apply to a generic
Sametime 7.5.1 deployment. This plan must be customized and made more
specific to your organization’s rollout. The primary objective is to help you identify
the key tasks that need to be accomplished, understand the necessary
dependencies between these tasks, and gain a sense of relative duration and
level of effort. The required duration to accomplish these tasks depends upon
your organization’s specific needs, available resources to dedicate to the project,
and finally, the level of skill within your organization.

Figure C-1 Sample Sametime enterprise deployment plan

D
Appendix D. Introduction to load

balancing - WebSphere
Edge components
In this appendix we describe functions and possibilities offered by load balancers
when working with your Sametime infrastructure. Specifically, we describe the
functions and possibilities offered by the IBM WebSphere Edge Components that
are part of IBM WebSphere Application Server Network Deployment V6.1.
Attention: In addition to the information in this appendix, refer to WebSphere

Application Server V6 Scalability and Performance Handbook, SG24-6392:
Important: Details on how to configure WebSphere Edge load balancer

components are covered in 5.5, “Install and Configure IBM Edge Load
Balancer Components” on page 220.

Introduction to load balancing - WebSphere Edge
Components
In the following sections we describe functions and possibilities offered by load
balancers when working with your Sametime infrastructure. Specifically, we
describe the functions and possibilities offered by the IBM WebSphere Edge
Components that are part of IBM WebSphere Application Server Network
Deployment V6.1. Edge Components provide the following functions:
򐂰 Load balancer
򐂰 Caching proxy
In the following sections we introduce the Load Balancing functions. The basic
concepts described here are used by most Load Balancing software and
hardware.
In our environment we used WebSphere Edge Components. However, many

customers decide to use the F5 Networks Big-IP system. For more information
about the BIG-IP system, visit:
http://www.f5.com/products/bigip/index.html
Another option is setting up a round-robin DNS.
Important: Details on how to configure WebSphere Edge load balancer

components are covered in 5.5, “Install and Configure IBM Edge Load
Balancer Components” on page 220.
For detail on how to configure BIG-IP load balancing for Sametime, visit:
http://www.f5.com/solutions/deployment/sametime_bigip45_dg.html
Scalability
Often Sametime need to scale for increasing numbers of simultaneous users on
a wide range of access devices.
By adding one or more community or mux servers to the existing environment,

you can prevent a single Web server from becoming overloaded. The incoming
requests are then dispatched to a group of servers, called a cluster. A cluster is a
group of independent nodes interconnected and working together as a single
system.
Load balancer software is used to dispatch the load to the servers in the cluster.
It uses a load balancing mechanism usually known as IP spraying, which

intercepts the incoming requests and redirects them to the appropriate machine
in the cluster, providing scalability, load balancing, and failover.
Availability
Users must be able to reach the application regardless of failed servers. In a
clustered Sametime server environment, the load balancer monitors the
availability of the Sametime servers. If a server has failed, no more requests are
sent to it. Instead, all requests are routed to the remaining active servers. We
also recommend that you ensure high availability of the load balancer system
itself to eliminate it as a single point of failure (SPOF).
Performance
Quick response times can be provided by routing requests based on the
geographic location, user identity, or content requested and by caching the
retrieved data.
Load Balancer overview

Load Balancer consists of the following five components that can be used
separately or together:
򐂰 Dispatcher (See “Dispatcher” on page 822.)
򐂰 Content Based Routing (CBR) Component for HTTP and HTTPS (See
“Content Based Routing (CBR) Component” on page 830.)
򐂰 Site Selector (See “Site Selector” on page 831.)
򐂰 Cisco CSS Controller (See “Cisco CSS Controller and Nortel Alteon
Controller” on page 831.)
򐂰 Nortel Alteon Controller (See “Cisco CSS Controller and Nortel Alteon
Controller” on page 831.)
We cover these components in more detail in the following sections. However, in

our test environment we used the Dispatcher component.
Session affinity is an option that applies to all of these components. See “Server
affinity in Load Balancer” on page 831, for details.
Appendix D. Introduction to load balancing - WebSphere Edge components 821

Dispatcher
The Dispatcher component distributes the load it receives to servers contained in
a cluster (a set of servers that run the same application and can provide the
same contents to its clients). This mechanism is also known as IP spraying.
Note: Load balancing can handle any TCP/IP-compliant protocol, including

the Sametime proprietary protocols. For example, Dispatcher can provide load
balancing for protocols such as HTTP, HTTPS, FTP, NNTP, IMAP, POP3,
SMTP, Telnet, and so on.
Dispatcher decides which server will handle a certain TCP/IP connection based
on the weight of each server in the cluster. The weight is the value that
determines the number of connections that each server receives. The weight can
be fixed in the configuration or it can be dynamically calculated by Dispatcher.
If you choose to configure the weight of the servers and set it as a fixed value, it
will not change no matter the conditions of the balanced servers, for example, if
you configure a cluster containing two servers, and you set the weight of the first
server to 1 and the weight of the second server to 2, meaning that the second
server will always receive twice the load as the first server. The only exception to
this is when an Advisor detects a failed server.
If you choose to work with dynamic weights (which is the default option, and what
we did in our test environment), Dispatcher will calculate the load of each
balanced server dynamically. In our previous example, if the response time of the
second server was slower than the response time of the first server, it would now
be possible to detect this and generate the correct weight value according to the
real conditions of each server.
For actual implementation information, refer to 4.5, “Install and configure IBM
Edge Load Balancer components” on page 224. (Specifically, see “Configure the
Manager component” on page 272.)
Dispatcher’s internal components

Dispatcher has internal components that are responsible for the tasks mentioned
earlier, like distributing TCP/IP packets and calculating the weight of the
balanced servers. These components are:
򐂰 Executor
򐂰 Manager
򐂰 Advisors
򐂰 Metric server

Executor
Executor is the core component of Dispatcher, and it is responsible for the load
distribution. It receives the packet, identifies whether this packet is destined to
the operating system or if it is destined to a cluster. If the packet is destined to a
cluster, it then determines whether this packet is a follow up to an existing
connection, or if it is a request for a new connection. Executor keeps a
connection table in memory to keep track of all active connections. After that, it
chooses the back-end server to which this packet will be sent.
In order to be able to identify the packets meant for the operating system, the
administrator needs to associate an IP address to the variable NFA
(non-forwarding address). This variable contains the IP address that is used for
all connections that should not be load balanced by Dispatcher, like telneting into
the machine, connecting to the Dispatcher’s administration service, and so on. In
other words, NFA determines the IP address that the Executor will ignore as far
as load balancing is concerned.
Manager
Manager is the component responsible for providing weight values of each
balanced server to Executor, so it can make its load balancing decision. Running
this component is optional, but it is necessary for dynamic weighting of the
servers and also for identifying failed servers.
Manager uses metric values for calculating the weight value of each server:
򐂰 The number of active connections being handled by that server
򐂰 The number of new connections that were forwarded to that server since the
last check (The default is two seconds.)
򐂰 The input from two components that gather load information about the
balanced servers:
– The Advisors
– The Metric Server
For additional information refer to “Configure the Manager component” on

page 272.
Advisors
The Advisors are lightweight clients that run on the Dispatcher server, and they
are aware of the protocol used by the back-end servers. Load Balancer provides
advisors for HTTP, HTTPS, FTP, and LDAP, among others.
Each advisor connects to a certain service running on each server of the cluster,
and submits a request that validates the health of that service. This means that
the advisor actually tests the service, not only the connectivity to the server (a

system can be reachable by ping, but if the server is not running, it cannot be
used in load balancing). The advisor then returns a value to the manager, which
represents how long it took for each server to respond. If it does not receive a
response from a server, it provides a value of -1 for this server, which is
interpreted by the manager as a server being down. Refer to “Advisors” on
page 828 for more information about the Advisors and to “Configure the Manager
component” on page 272 for information about implementing this feature.
Metric server
Note: We did not configure the metric server in our test environment.
If you need to collect more information from the back-end server for load
balancing, you can also use the metric server, which is a component that is
installed and runs in each back-end server. The metric server can additionally
provide values for the server where it is running. For example, the metric server
can monitor memory and CPU usage. This information is also sent to the
manager and is used to calculate the final weight value for each server.
The interaction of Executor, manager, and other Load Balancer components is

shown in Figure D-1.
Dispatcher HTTP Server 1

Metric Server
dscontrol lbadmin
Web dsserver HTTP Server 2

Client advisors
Manager advisors
Advisors Metric Server
HTTP Server 3
Executor
Metric Server
Figure D-1 Dispatcher components interaction

Forwarding methods
There are three methods used by Executor to forward packets to the balanced
servers:
򐂰 MAC forwarding
Note: This is the method used in our test environment.
򐂰 Network Address Translation (NAT)/ Network Address Port Translation

(NAPT)
򐂰 Content Based Routing (CBR), also referred to as Kernel CBR (KCBR) in
previous versions
MAC forwarding
This is the default forwarding method. When Dispatcher receives a packet and
chooses which server to send it to, it only changes the source and destination
MAC address of the packet. The IP addresses remain the same. This means that
the source IP address remains the IP address of the client machine, and the
destination IP address remains the cluster IP address.
When the balanced server receives the packet, it responds directly to the client
(because the source IP address in the packet belongs to the client).

MAC forwarding is the fastest forwarding method because Dispatcher receives
only the incoming traffic. All outbound traffic is sent directly from the balanced
server to the client. This requires that all balanced servers be connected to the
same subnet as Dispatcher. See Figure D-2.
MAC Forwarding
Client
Incoming traffic
Outgoing
traffic
Load Balancer
Incoming traffic
Backend server
Figure D-2 MAC forwarding - network flow
This method also requires that the services running on the balanced servers be
able to accept the packets containing the cluster IP address as the destination IP
address. The easier solution is to add an IP alias to the loopback interface (so it
is not advertised in the network).
Refer to 4.5, “Install and configure IBM Edge Load Balancer components” on
page 224, or Load Balancer Administration Guide Version 6.0, GC31-6858
(http://www-1.ibm.com/support/docview.wss?uid=pub1gc31685801), for
instructions on how to add an IP alias in various operating systems.
Network Address Translation (NAT)/ Network Address Port

Translation (NAPT)
This forwarding method allows Dispatcher to provide load balancing for remote
servers, which is not available in the MAC forwarding method.

Dispatcher receives the TCP/IP packet and chooses which server to send it to,
rewrites the IP header and changes the source IP address (which is originally the
IP address of the client machine), puts the return address instead (this is an IP
address configured by the Dispatcher administrator), changes the destination IP
address (which is originally the IP address of the cluster), and puts the balanced
server IP address instead. Now this packet can be routed to the balanced server
even if it is on a remote network. But because Dispatcher changes the packet, it
needs to receive the response so it can also change the IP header before
sending it to the client.
NAT Forwarding
Client
Outgoing
traffic Incoming traffic
Load Balancer
Outgoing
Incoming traffic
traffic
Backend server
Figure D-3 NAT forwarding - network flow
This method also allows port redirection (NAPT). This means that the port that
you configure on the cluster configuration does not need to be the same port that
the service is listening on in the balanced server. In this case, Dispatcher
changes the port information in the TCP header the same way it does with the IP
addresses in the IP header of the TCP/IP packet.
This method implies that Dispatcher needs to handle all traffic, both inbound and
outbound. It also needs one extra IP address to implement the configuration,
which is the return address.

Content Based Routing (CBR)
The CBR forwarding method does not require the caching proxy, as does the
CBR component. It allows content-based load balancing for HTTP and HTTPS
protocols.
For the HTTP protocol, the connection distribution is based on the contents of
the URL or the HTTP header. For the HTTPS protocol, the distribution is based
on the SSL session ID field of the client request.
CBR also allows load distribution to servers connected to remote networks. It

also requires one IP address for the return address.
Note: By default, the only available forwarding method is MAC forwarding. In

order to enable NAT/NAPT and CBR, you need to configure the client gateway
property of Executor and set it to the IP address of the router of the network.
Refer to Chapter 5 in the IBM Redbooks publication WebSphere Application

Server V6 Scalability and Performance Handbook, SG24-6392
(http://www.redbooks.ibm.com/abstracts/sg246392.html?Open), specifically
the NAT Scenario, for more details on how to enable all available forwarding
methods.
For more details, advantages, and disadvantages of each forwarding method,

refer to the Load Balancer Administration Guide Version 6.0, GC31-6858:
Advisors
Advisors are lightweight clients that run on the Dispatcher machine, providing
information about the load of a given server. The product provides
protocol-specific advisors for several protocols and products, such as HTTP,
HTTPS, FTP, Telnet, DB2, DNS, LDAP, SMTP, and others.
Standard advisors send transactions periodically to determine the status of the

servers (for example, for HTTP an HTTP HEAD request is sent, and for FTP a
SYST command is sent). If the transaction succeeds, the server is considered
up.
Load Balancer also provides a generic advisor, called Connect, that can be used
in case you need to load balance a service or protocol for which there is no
dedicated advisor available. Connect opens a connection to the server using the
server port informed in the advisor configuration and closes the connection after
the TCP/IP handshake is done. As there is not an out-of-the-box advisor for
Sametime. We used the Connect advisor in our test environment.

In order to calculate a load value, the advisor:
1. Opens a connection with each server.
2. Sends a protocol-specific request message.
3. Listens for a response from the server.
4. Calculates the load value.
After getting the response, the advisor makes an assessment of the server.
To calculate this load value, most advisors measure the time for the server to
respond, and then use this value (in milliseconds) as the load.
You may also set the connecttimeout and receivetimeout parameters for each
advisor. connecttimeout is the amount of time the advisor will wait before
aborting the connection and receivetimeout is the amount of time the advisor
will wait before giving up on the data over the socket.
5. Reports the load value to manager.
If the server does not respond, the advisor returns a negative value (-1) for the
load. A downed server is given a weight of zero by the Executor, and packets will
not be forwarded to it until the server responds to the advisor again.
Manager obtains the load value reported by the advisor, which is available in the
Port column of the Manager report. The manager obtains these values from all of
its sources and sets proportional weight values for Executor.
Custom advisors
You can also write your own advisors for specific applications like Sametime.
These are called custom advisors, and you can write your own advisor based on
sample Java code provided with the product. The sample code is available in the
install_path/servers/samples/CustomAdvisors directory, where install_path is the
load balancer installation path (such as /opt/ibm/edge/lb on AIX, or C:\Program
Files\IBM\edge\lb on Windows).
Custom advisors run on the Dispatcher node, and must be written using Java
language and compiled with a Java compiler for the Dispatcher machine.
Important: For the Edge Components that are part of IBM WebSphere
Application Server Network Deployment V6, you need Java compiler Version
1.4.2.
Class file names must follow the form ADV_name.class, where name is the
name you choose for the advisor.

Using the Java SDK, the compile command is:
javac -classpath <install_path>/servers/lib/ibmlb.jar ADV_<name>.java
Note: The load balancer base classes, found in ibmlb.jar, must be referenced
in the classpath during compilation.
The advisor code must then be copied to the

install_path/servers/lib/CustomAdvisors directory, and it can be started using the
command-line interface or the graphical interface.
Make sure that manager is running before you try to start any advisor.
More detailed information about custom advisors, describing how they work and
how to write, compile, and test them, including examples, development
techniques, and interface methods, can be found in the Load Balancer
Administration Guide Version 6.0, GC31-6858:
More detailed information about custom advisors specifically for Sametime can
be found in the developerWorks article “Sametime Chat Network Dispatcher
Advisor”:
http://www-128.ibm.com/developerworks/lotus/library/ls-STChat_advisor/
Which includes a link to their code for the Sametime Chat Advisor from the Lotus
Developer Domain sandbox:
http://www-10.lotus.com/ldd/sandbox.nsf/cde4d8ccbe98e4868525676e0079ad3
4/670748e0f41ae33485256d18005c9205?OpenDocument
Content Based Routing (CBR) Component

The CBR component load balances based on the content of the request. Load
Balancer supports content-based routing in two ways: the CBR component and
the Dispatcher CBR forwarding method (discussed in “Dispatcher” on page 822).
In conjunction with the caching proxy, the CBR component has the ability to
proxy HTTP and HTTPS (SSL) requests to specific servers based on the content
requested. The Dispatcher component also provides content-based routing, but
it does not require the caching proxy to be installed. Because the Dispatcher
component’s content-based routing is performed in the kernel as packets are
received, it can provide faster content-based routing than the CBR component.

When do you use which CBR method
For fully secure SSL traffic (client through server):
򐂰 The CBR component (in conjunction with the caching proxy) can process SSL
encryption/decryption in order to perform content-based routing.
򐂰 The Dispatcher CBR forwarding method can only be configured with SSL ID
affinity because it cannot process the encryption/decryption to perform true
content-based routing on the requested URL.
For HTTP traffic the Dispatcher CBR forwarding method provides a faster
response to client requests than the CBR component. Also, the Dispatcher CBR
forwarding method does not require the installation and use of a caching proxy.
Site Selector
This component performs load balancing using a DNS round-robin approach or a
more advanced user-specified approach. Site Selector works in conjunction with
a name server to map DNS names to IP addresses. System Metrics (provided by
the metric server) should be used in addition to advisor weights to achieve a
well-balanced and accurate weighting of servers.
Cisco CSS Controller and Nortel Alteon Controller

These controllers can be used to generate server weighting metrics that are then
sent to the Cisco and Alteon Switch, respectively, for optimal server selection,
load optimization, and fault tolerance.
Server affinity in Load Balancer

Server affinity is a technique that enables the load balancer to remember which
balanced server was chosen for a certain client at its initial request. Subsequent
requests are then directed to the same server again.
If the affinity feature is disabled when a new TCP/IP connection is received from
a client, load balancer chooses the correct server at that moment and forwards
the packet to it. If a subsequent connection comes in from the same client, load
balancer treats it as an unrelated connection, and again chooses the most
appropriate server at that moment.
Server affinity allows load balancing for those applications that need to preserve
state across distinct connections from a client. Maintaining state is a requirement
of many applications encountered on the Internet today, including shopping
carts, home banking, and so on.

Important: Maintaining state is a requirement for Sametime servers. When
you initially get logged into Sametime, the community server you reach is the
server that manages your community session. If the load balancer is not
configured for server affinity, then subsequent request may get directed to the
wrong server, causing many problems in Sametime, including the community
Sametime server logging you out from Sametime.
Some options available to maintain application state based on server affinity are,
specifically the first two (Stickyness to source IP address, Cross port affinity):
򐂰 Stickyness to source IP address
򐂰 Cross port affinity
򐂰 Passive cookie affinity
򐂰 Active cookie affinity
򐂰 URI affinity
򐂰 SSL session ID
The passive cookie, active cookie, and URI affinity options are rules-based. They
depend on the content of the client requests.
Stickyness to source IP address

This affinity feature is enabled by configuring the clustered port to be sticky.
Configuring a cluster port to be sticky allows subsequent client requests to be
directed to the same server. This is done by setting the sticky time to a positive
number. The feature can be disabled by setting the sticky time to zero.
The sticky time value represents the time out of the affinity counter. The affinity
counter is reset every time load balancer receives a client request. If this counter
exceeds sticky time, new connections from this client may be forwarded to a
different back-end server.
In Dispatcher and CBR components, you can set the sticky time in three
elements of the load balancer configuration:
򐂰 Executor: Setting the sticky time for the Executor makes this value valid for all
clusters and ports in the configuration.
򐂰 Cluster: You can set a specific sticky time value for each cluster.
򐂰 Port: You can set a specific sticky time value for each port.

Important: Setting affinity at the different levels means that any
subsequent lower level objects inherit this setting by default (when they are
added). In fact, the only true value that is used for sticky time is what is set
at the port level. So if you set the sticky time for the Executor to 60, then
add a cluster and port, these also have a sticky time of 60.
However, if you set a different sticky time for the cluster or the port (for
example, you set it to 30), then this value overrides the Executor sticky
time.
In Site Selector, you set the sticky time on the sitename.
This feature applies to the Dispatcher (all forwarding methods), the CBR, and the
Site Selector components of load balancer.
Note: This affinity strategy has some drawbacks: some ISPs use proxies that
collapse many client connections into a small number of source IP addresses.
A large number of users who are not part of the session will be connected to
the same server. Other proxies use a pool of user IP addresses chosen at
random, even for connections from the same user, invalidating the affinity.
For implementation details, refer to “Configure the sticky bits” on page 276.
Cross port affinity

Cross port affinity is the sticky feature that has been expanded to cover multiple
ports. For example, if a client request is first received on one port and the next
request is received on another port, cross port affinity allows Dispatcher to send
the client requests to the same server.
One example of this feature is a shopping cart application. The user browses the
products and adds them to his shopping cart using port 80 (HTTP). When he is
ready to place the order, he is redirected to a HTTPS (port 443) site, which
encrypts all communication between the browser and the server. Cross port
affinity enables Dispatcher to forward this user’s requests for both ports 80 and
443 to the same server.
In order to use this feature, the ports must:

򐂰 Share the same cluster address.
򐂰 Share the same servers.
򐂰 Have the same sticky time value (not zero).
򐂰 Have the same sticky mask value.

More than one port can link to the same cross port. When subsequent
connections come in from the same client on the same port or a shared port, the
same server will be accessed.
Important: This is another important piece with Sametime servers. If

tunneling is not enabled, Connect client and STLinks connections to the
Sametime server occur over different ports (1533 and 8082, respectively, by
default). If a user is using both to access Sametime from his machine, it is
important that they remain on the same Sametime Community server
throughout their session.
Cross port affinity applies to the MAC and NAT/NAPT forwarding methods of the
Dispatcher component.
For details on implementing this feature, refer to “Configure the sticky bits” on
page 276.
Passive cookie affinity

Passive cookie affinity is based on the content of cookies (name/value)
generated by the HTTP server or by the application server. You must specify a
cookie name to be monitored by Load Balancer in order to distinguish which
server the request is to be sent to.
If the cookie value in the client request is not found or does not match any of the
cookie values of the servers, the most appropriate server at that moment will be
chosen by Load Balancer.
This feature applies to both the CBR component and to the Dispatcher’s CBR
forwarding method.
Active cookie affinity

Active cookie affinity enables load balancing Web traffic with affinity to the same
server based on cookies generated by the Load Balancer. This function is
enabled by setting the sticky time of a rule to a positive number, and setting the
affinity to cookie. The generated cookie contains:
򐂰 The cluster, port, and rule
򐂰 The server that was load balanced to
򐂰 A time-out time stamp for when the affinity is no longer valid
Active cookie affinity formats the cluster/port/server/time information into a key

value in the format of IBMCBR##### so the IP and configuration information is
not visible to the client browser.

The active cookie affinity feature applies only to the CBR component.
URI affinity
URI affinity allows you to load balance Web traffic to caching proxy servers,
which allow unique content to be cached on each individual server. As a result,
you will effectively increase the capacity of your site’s cache by eliminating
redundant caching of content on multiple machines. You can configure URI
affinity at the rule level, and once it is enabled and the servers are running, then
the load balancer will forward new incoming requests with the same URI to the
same server.
URI affinity applies to the CBR component and to Dispatcher’s CBR forwarding
method.
SSL session ID
During establishment of an SSL encrypted session, a handshake protocol is
used to negotiate a session ID. This handshaking phase consumes a good deal
of CPU power, so directing subsequent HTTPS requests to the same server,
using the already established SSL session, saves processing time and increases
the overall performance of the HTTP server.
Load Balancer watches the packets during the handshake phase and holds
information about the session ID if SSL session negotiation is detected.
The forwarding method used to configure SSL session ID affinity is the

Dispatcher’s CBR forwarding method.

Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this book.
IBM Redbooks
For information about ordering these publications, see “How to get IBM
Redbooks” on page 837. Note that some of the documents referenced here may
be available in softcopy only.
򐂰 Extending Sametime 7.5 Building Plug-ins for Sametime, SG24-7346
򐂰 Lotus Instant Messaging/Web Conferencing (Sametime): Building Sametime
Enabled Applications, SG24-7037
򐂰 Lotus Sametime 2.0 Deployment Guide, SG24-6206
Online resources
These Web sites are also relevant as further information sources:
򐂰 Sametime 7.5.1 Information Center
򐂰 Sametime Product Page
http://www-142.ibm.com/software/sw-lotus/sametime
How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips,
draft publications and Additional materials, as well as order hardcopy Redbooks
or CD-ROMs, at this Web site:
ibm.com/redbooks

Help from IBM
IBM Support and downloads
ibm.com/support
IBM Global Services

ibm.com/services

Index
Adding redundancy through 2 chat servers 44
A Adding redundancy to your Sametime infrastructure
A case where users are concentrated in three re-
42
gional locations 37
Adding Sametime Room Server to EMS 728
About Lotus Sametime 7.5.1 3, 632
Adding Server to Web Administration tool 103
access control list 62, 87, 740
Adding Suffixes 109
Access Control List to
Adding the first balanced server 270
ITSO’s Directory 163, 206, 319
Adding values to mailfile and mailserver attributes
Sametime Configuration 165, 208, 321
127
ACL 62, 87, 740
Administering and configuring the Directory Server
Active cookie affinity 834
99
Active Directory 79, 84, 87, 716, 731, 751–752
Administrator ACL to ca.nsf 567
Enterprise Admins group 790
Advanced Network Settings 146, 188, 301
Add a Domino Canonical Name to LDAP Directory
Advanced Settings 235
355
Advanced TCP/IP Settings 248, 250
Add a new hardware device 229
Advisor
Add CA Certificate from a file 577
Connect 1533 274
Add CA’s Trusted root certificate to Sametime’s
Advisors 823, 828
key.kdb 586
all advisors started 276
Add CA’s Trusted root certificate to Sametime’s
All Server Documents View 404, 454
stkeys,.kdb 589
All server documents view 394
Add directory assistance db to server doc 393
America’s Chat Cluster scenario 259
Add Directory Assistance Document 389
Another way to utilize the SA Mux 40
Add Domino DN to Tivoli Directory Server 386
AOL Instant Messenger
Add LDAP DN to Domino person document 397
community 745
Add LDAP DN to LTPA user name field 400
Applet for the Sametime Meeting Room client 686
Add LDAP DN to user name field 397
Application Server v6 717, 720
add LDAP DN to username field 399
Architectural example 709
Add LDAP’s Domino Canonical Name field to re-
Asia Pacific (AP) 17, 23–24
solve filter 356
attribute ibm-allmembers 113
Add New Hardware 228
Attributes to be added to an LDAP Directory 116
Add the trusted root certificate to key.kdb file. 585
Audio Visual Capabilities 13
Add to Domino cluster 216
Audio/Video Services ports 77, 608
Add trusted root certificate to stkeys.jks 588
Authentication 60, 85
Added Console Server 105
Authentication Mechanisms -- LTPA 491
Adding a cluster 265
Authorization 60, 85
Adding a port 268
auto-mail detection 116
Adding a server 270
Availability 821
Adding a suffix 107
Available options in the logging tool 694
Adding Attribute SametimeServer 119
awareness in DWA 412
Adding attribute values for NotesCon and NotesDN
awareness in Inbox. 365
126
awareness in People Finder 506
Adding Attribute values via LDAPModify 128
awareness in QuickPlace 464
Adding attributes to inetOrgPerson 121
Awareness within Outlook 529

B 595
B2B Instant Messaging - Connecting directly to the Certifier Password 173, 286, 368, 423
other company's Lotus Sametime Gateway 47 Certifier Recovery Information Warning 174, 287,
balanced server 822–823 369, 424
load information 823 Change how names are passed to Sametime for
weight values 823 awareness status. 413
balanced servers added to each port in cluster 271 Changing the QuickPlace administration place 442
base DN 716, 719 Chat and awareness considerations with Reverse
Best Practices for setting up the business card fea- Proxies 618
ture 340 chat cluster 43–44, 116
Best Practices on HTTP Tunneling 615 Chat history settings 648
bin directory 100, 111 Chat history transcripts 647
Buddy List 539 chat window 650
Business Architecture Diagram 741 Chat window extension points 651
Business Card & Storage Configurations 337 Checkpoint - Verify photo is available via
Business Card data retrieval test - UserInfo servlet LdapSearch 350
353 Choose a Certifier 173, 286, 368, 423
Business Card integration in Connect client 334 Choose your organization name 142
Business Card Request/Response Flow Diagram Choosing the Data directory for Lotus Domino 136,
336 180, 293, 373, 428
Business Cards 340 Choosing the Program directory for Lotus Domino
business partner 1, 3, 46, 49, 812–813 135, 179, 292, 372, 427
Choosing which type of Directory to use 84
Choosing which type of Directory to use. 59
C Cisco CSS Controller 821, 831
CA 565
Cisco CSS Controller and Nortel Alteon Controller
Cache location 688
831
Caching Proxy Installation 623
Classifications of users - types and population within
Capacity 30
ITSO Corp. 24
capacity planning 28, 39
client connection 32
Capacity Planning within a community services clus-
Broadcast Gateway Address 76
ter 44
Client Considerations 27
Case Fixes 331
Client Deployment phase II
Catalog the Sametime DB2 database
Implementation 671
724
Client Extensibility 13
CBR component 828, 830, 832
Client PC 28
CBR method 831
Client Requirements 67
CBR See Content Based Routing
Client requirements 67
Certificate Authority 537, 540, 545, 564, 768,
Client Software Requirements for Meetings 68
771–772, 804
Cluster added 267
Click OK 752, 755
Cluster Information 219
Database 773
Cluster Name 216
Dialog box 771
Clustered Environments 698
snap-in 773
Common Name (CN) 62, 83, 766, 800, 805
Web Application Click Request 784
Community Client document 680
certificate authority 565
Community Service
Certificate Authority Profile example 571
Capacity Planning 44
Certificate Authority Web Application 575
deployment options 46
Certificate received into Key Ring as a Trusted Root
direct TCP/IP connections 72

up-to-the-second information 692 patcher Component 225
community service 2, 4, 7, 15, 29, 35, 43, 46, 692, Configure NIC on load balancer to accept traffic for
694, 707, 710, 734, 800 imcluster 242
different Sametime server 16 Configure NIC on mux servers to accept traffic for
Server-to-server connections 8 imcluster 226
Community Services 7 Configure Notes Client to pass full canonical name
community services cluster 43–44 format 358
maximum size 43 Configure QuickPlace for awareness and chat 460
Community Services multiplexer 15, 38, 44 Configure QuickPlace for awareness, chat and
Community Services Multiplexer Requirements 68, meetings 447
70 Configure QuickPlace for online meetings 464
Community Services Ports 72, 602 Configure QuickPlace Security 440
Community Trusted IPS 508 Configure Sametime 155, 198, 311
CommunityConnectivity 219 Configure Sametime to trust Portal for the Sametime
Completing the Add Hardware Wizard 234 Contact List Portlet 506
Component Selection window 256 Configure SSO between DWA and Sametime 401
Conceptual example - Same as having 4 functional Configure SSO between Portal and Sametime 489
servers 35 Configure SSO between QuickPlace and Sametime
Conclusion 689 451
concurrent connection 3 Configure Stand-Alone MUX server 223
concurrent meeting Configure the Manager component 272
use 706 Configure the sticky bits 276
user 33 Configure the Web Conferencing Portlet 512
Configuration Document Configure WebSphere Portal for awareness, chat
Domino Web Access tab 409 and meetings 485
Configuration of the IBM Edge Server Caching Configuring invitation process 36
Proxy 627 Configuring Sametime Administrative policies 667
Configuration Settings Configuring the Domino certificate authority 565
basics tab 407 Configuring the interface 266
Configurations view 406 Confirmation and location of Stash password. 547
Configure Business Card to Display Information Confirmation of the connection 665
351 Connect to Host... 262
Configure Directory Assistance on DWA server(s) Connect to other Lotus Sametime companies 748
387 Connect to the AOL®, Yahoo! Messenger™ and
Configure Domino 139, 183, 296, 376, 431 Google Talk™user communities 747
Configure Domino Cluster 215 contact list 650
Configure DWA for awareness and chat 383 Content Based Routing 830
Configure DWA server document for awareness and Content Based Routing (CBR) 828
chat 406 Content Based Routing (CBR) Component 830
Configure Edge Network Dispatcher 259 content-based routing 830–831
Configure iNotes_WA_SametimeNameFormat 416 Contents of directory 673
Configure key file to be used by TDS 552 continuous access 16, 43
Configure LDAP for notes formats 415 Copying Java files required for chat and online
Configure Loopback Adapter 236 awareness 460
Configure loopback adapter for cluster ipaddress Copying Sametime Connect clients to server 672
234 Copying the Java files required for online meetings
Configure Lotus Web Conferencing portlet 515 464
Configure MS integration with Sametime 529 Create a Domino cluster 215
Configure network to work with Edge Network Dis- Create a Sametime cluster 218
Index 841
Create CA key ring file 569 SA Mux in Remote Locations 40
Create CA Server key ring example 573 Separated Community Multiplexing 38
Create Directory Server instance 95 deployment option 22, 25, 28, 30, 38, 43, 64
Create Directory server instance task completion high level overview 46
98 Deployment Option - Dedicated Sametime Servers
Create Key Ring 592 33
Create New Database 387 Deployment Option - Multiple Sametime Servers 33
Create new JKS file 558 Deployment Option - Sametime in the Extranet 46
create new meeting 468 Deployment Option - Single Sametime Server 29
Create New Self Signed Certificate 549 Deployment Options 28
Create stkeys.jks file 557 Deployment Options for High Availability 40
Create the CMS key.kdb file 555, 585 Deployment Phase 1 - Implementing Community
Create the Domino keyfile 591 Services 129
Create the Sametime cluster 218 Deployment Phase I - Implementing Meeting Servic-
Create the WebSphere LTPA key 489 es 281
Creating a database for Sametime EMS on DB2 Deployment Phase II -Integration with other Prod-
724 ucts 329
Creating Domino SSO key 161, 204, 317 Deployment Phase III - Securing the environment
Creating Domino Web Server Configuration data- 537
base 456 Deployment Phase1
Creating new Domino web SSO keys. 203, 316 Planning 668
Creating the qpconfig.xml file 444 Determining different classes of users 23
Creating the self-signed Server Certificate 545 Differences Between Sametime and EMS 704
Cross port affinity 833 direct TCP/IP connection 8, 12, 72
CSEnvironment.prop erties 806–807 call control information 74
Custom advisors 829 Directory Assistance - LDAP 165, 209, 322
Directory Assistance Basic tab 390
Directory Assistance LDAP tab 393
D Directory Assistance Naming Contexts (Rules) tab
Database location and Character set option, 97
391
DB2 Administrator 92, 97
Directory Assistant LDAP Settings 564
DB2 Administrator’s username and password 97
Directory Components 61, 83
DB2® Administrator and password 92
Directory Concepts 81
Default Domino homepage 148, 191, 304, 381, 437
Directory Consideration 59, 83
default port 70–72, 74
Directory Considerations 59
Default Security of Sametime communication and
Directory Considerations specific to Sametime 7.5
saved information
83
539
Directory Information Tree 61, 83, 106
Delete field jpegPhoto from $PersonInheritable-
Directory Information Tree (DIT) 106, 123
Schema 809
Directory location for installation 672
Deploy Clustered Chat Servers 133
Directory Management -> Manage entries 343
Deploy ITSO’s Meeting infrastructure 284
Directory Name 221
Deploy stand-alone MUX servers 220
Directory Server 79, 711, 763, 784
Deploying Sametime 7.0 Connect for Browsers on a
Directory Server Administration Tool 101
Sametime7.5.1 server managed by EMS 683
Directory Server instance - Results 99
Deploying the StAdmin, STServer, and STCenter
-Directory Server successfully added to Web Admin-
(.ear) files
istration tool 104
725
Directory Server Web Administration Tool 100, 118
Deployment Option
Directory Type used by Sametime options 417

Dispatcher 822 dscontrol 260
Advisors 823, 828 dsserver
Connect 828 Start Dispatcher 260
connecttimeout 829 DWA Preferences 411
Custom 829 DWA user person document 385
Downed server 829 DWA user settings to enable awareness and chat
receivetimeout 829 409
Executor 823 DWA Welcome page 410
Connection table 823
Forwarding methods 825
CBR 828
E
e.g. password 730
MAC forwarding 825
Edge Components 819–820
NAT/NAPT 826
Edit attributes 346
Return address 827
Edit attributes for an inetOrgPerson Object 124
Manager 823
Edit objectclass
Metric Server 824
InetOrgPerson 121
Server weights 822
Edit Office Location Document 361
Dynamic 822
E-mail Address 82, 783
Fixed 822
Emoticon pallet 641
Dispatcher components interaction 824
EMS and clustering 711
Dispatcher’s internal components 822
EMS and Instant Meetings 712
distinguished name 61, 83
EMS application 707, 709
Distinguished Name (DN) 83, 96, 805–806
EMS Deployment 715
Distributing the plugin_customizations.ini file out to
EMS Deployment - Port Diagram 715
users’workstations 678
EMS Meeting Services 712
DMZ 48–49, 745, 748
EMS within the context of Meeting Room servers
DNS config for Chat Cluster address 226
and an IM Cluster 708
DNS name 74, 76, 116, 831
en0 266
Domain Controller 752, 754
en1 266
fully qualified DNS name 754
Enable Awareness and Chat in WebSphere Portal
Netbios name 754
499
Domino Administrator 695
Enable awareness in Notes Client. 360
client 695, 697
Enable MSSSO in server document 405, 455
help guide 701
Enable Security with Realm Support 478
Domino Certificate Authority application 568
Enabling SSL to LDAP for Community Services
Domino Directory
562
template pubnames.nsf 810
Enabling SSL to LDAP for Web Services 563
template pubnames.ntf 810
Enabling SSL to LDAP with trusted root for commu-
Domino LDAP 60–61, 79, 84, 799–800
nity services 598
Domino Organization setup 141
Enabling SSL with trusted root in Directory Assis-
Domino Server Setup 134
tance. 598
Domino Server Tasks 565
Enabling the Connect for Browsers link on Same-
Domino server type
time 7.5.1servers managed by EMS 684
Enterprise Server 137, 181, 294, 374, 429
Enabling the Connect for Browsers link on the
Domino Setup 172, 284
Sametime 7.5.1server home page 680
Domino Web Access (DWA) 19, 27, 125
end user 28–29, 53–54, 86
Domino Web Access Integration with Sametime
Canonical name 61
365
collaborative activities 29
Downloading the client from the server 673
Index 843
Enhancements to the Meeting room user interface instant messaging 48
666 instant messaging connectivity 813
Enhancements with Rich text capabilities 640 on-line meeting 51, 54
Enter Import File Name 495 external directory 48, 50
Enter key file database path and file name 584 entirely separate user record 48
Enter label for CA’s Trusted Root Certificate 586 Extracting the downloaded zip file to a directory on
Enter password from the exported certificate 551 your server 679
Enter password of the exported certificate JKCS file
556
Enter your instant messaging user name and pass-
F
Failover in Community Services clusters 43
word 364
fictitious company
Entering the SametimeServer attribute value. 125
ITSO Corp 22
Enterprise Meeting Server 703
ITSO Corporation 23
Enterprise Meeting Server (EMS) 2, 16, 32,
Field - $PersonExtendableSchema subform with
703–704
jpegPhoto field. 809
enterprise-scale deployment 1
File Transfers 539
practice framework 1
Filling in the information to add a cluster 265
Example - deploying a full Sametime Server in AP
first server 734, 822
34
response time 822
Example - servers to be dedicated to chat or meet-
For All Sametime 7.5.1 Servers
ing servers 33
678
Example Business Card 334
For all server platforms 679
Example Meeting Room Client (MRC) 610
For which environments is EMS appropriate 705
Example of a highly redundant architecture 45
Forwarding method 825–826, 828, 833
Example of an account created with only user ac-
Forwarding methods 825
cess rights on the local machine 686
Fully qualified hostname for Sametime server 222
Example of Smart tag integration based on name
"Miles Montgomery" in a word document 523
Example of the Sametime toolbar in Outlook 2003 G
521 GB minimum 65–66, 69–70
Executor 823 Generate and propogate the webserver plugin
Executor started 264 727
Expand containers 344–345 Global Architecture 56–57
Expanding a Community Services Cluster with the Google Talk 740–741
SA Mux 44 user 745
Export PKSCS12 key 551 graphical user interface (GUI) 789
Exporting the certificate 550 Group considerations 62, 86
Extend TDS Schema 386 GSKit 7 Welcome Screen 542
Extendable Applications Platform 12 GSkit 7.0 Installation Directory 542
Extending the LDAP Schema 115 GSKit Installation complete 543
Extending the Schema to add MailFile and
MailServer attributes 126
H
Extending the schema to add NotesDN and Hardware and Software Requirements for EMS
NotesCon. 125 712
Extending the schema to add SametimeServer at- Hardware Server specifications to support Chat or
tribute 116 Meeting services 64
Extension Point 650–651 High Availability Deployment Option - Community
external community 50–51, 53–54, 741 Services Clustering 43
external contact 46–47, 813

Home Server Assignment 61, 86 Application Server 717
home URL 705 IBM Workplace
How awareness works in DWA 396, 401 Collaboration Service 635
How does it work. 400 illustrates a more (IM) 704, 706
How does Sametime use the Directory? 60, 85 Illustrating the tabbed chat feature in Sametime
How does the Business Card feature work? 335 7.5.1 6, 634
How EMS addresses these issues 710 Immediate or Via Administration Process 217
How EMS handles failover 710 Import binary data - Browse 348
How instant messaging works in DWA 383 Import binary data - File uploaded 349
How instant messaging works in QuickPlace 448 Import binary data - Submit file 349
How instant messaging works in WebSphere Portal Import TDS - Self-signed certificate into Sametime’s
486 key.kdb. 556
How instant messaging works using a Notes Client. Import the certificate into CMS - key.kdb 556
353 Import the certificate into JKS - stkeys.jks 558
How is works 745 Import the key into Domino 493
How it Works 745 Import user photo into the TDS LDAP directory. 342
How online meetings work in QuickPlace 450 Import WebSphere LTPA Keys 494
How online meetings work in WebSphere Portal Inbox with awareness 413
488 inetOrgPerson 110, 120, 331, 445, 719, 732,
How this works. 396 763–764
HTTP connection 71 inetOrgPerson object 122
HTTP Services, Domino Services, LDAP Services, inetOrgPerson objectclass 127, 763–764
and Sametimeintraserver ports 71, 600 inf file 781, 783
HTTP Tunneling 609 Initiate a chat from an open message 654
HTTP tunneling 71–72, 716, 734 Initiating a chat from within the InBox view 653
HTTP Tunneling - Hybrid Polling 614 iNotes_WA_SametimeNameFormat defaults 417
HTTP Tunneling & SSL 616 Install and Configure IBM Edge Load Balancer
HTTP Tunneling at Work - Meeting Room Client ex- Components 224
ample 610 Install Destination Location 438
HTTP Tunneling Tweaks 617 Install Domino 134, 178, 291, 366, 371, 426
HTTPS connection 71–72 Install Domino and register the DWA users 366
HTTP-tunneled connection 72, 74 Install Domino for QuickPlace 421
UDP data 77 Install Edge Network Dispatcher 253
Install Location
475
I Install Loopback Adapter 227, 233
IBM HTTP
Install MS integration with Sametime 523
Server 704, 707
Install process 524
IBM HTTP Server 6.0 717
Install QuickPlace 438
IBM Keyman 545
Install QuickPlace and configure Security 421
IBM Lotus Sametime 632, 636, 649
Install Sametime 150, 193, 306
7.5 3
Install Stand-Alone MUX server 221
Gateway 742
Install Summary 223
server 693
Install the Certificate Authority’s Trusted root certifi-
IBM Redbook 1
cate 594
IBM Tivoli Directory Server
Install the hardware that I manually select from a list
instance task 100
230
Web Administration 118
Install the LDAP Internet Cross Certificate 558
IBM WebSphere
Install Trusted root 594
Index 845
Install trusted root certificate into key file 575 Isolated External Sametime Meeting Environment
Install WebSphere Portal and configure Security and using Reverse Proxy Access 53
474 Issue - I can log into EMS, but I can't join a meeting
Install WebSphere Portal v6 474 733
Install/Configure the first chat server 133 Issue - I can't log into the EMS server 731
Install/Configure the second chat server 172 Issue 3 - I can't add a Room Server. 734
Installation Complete 139, 183, 296, 376, 431 Issue 4 - My Room Servers won't change status
Installation confirmation window 258 from "ServerDown/Unavailable" to "Running". 735
Installation dialog 670 Issue 5 - Meetings won't go active 736
Installation was successful. 478 ITSO Corporation 16–17, 21, 56–57
Installing and configuring EMS 716 architectural overview diagram 56
Installing GSKit 584 fictitious scenario 21
Installing GSKit on the Sametime Servers 554 ITSO Corporation Geographic Regions 17
Installing GSKit on Tivoli Director Server 574 ITSO’s Sametime Community Infrastructure 130,
Installing GSKit on Tivoli Directory Server 541 283
Installing Sametime Room Server
728
Instant Meeting 29, 39, 712, 813
J
Java Control panel for our User Account 687
specific number 712
Java Message Service (JMS) 704, 711
unlimited number 712
Java Virtual Machine
Instant Meetings 539
page 721
Instant Message (IM) 3, 26, 746, 813
Java Virtual Machine (JVM) 721
Instant Messaging (B2C) – Individual External Con-
jpegPhoto - Binary data 347
tacts. AOL Instant Messenger, Yahoo!, or Google-
jpegPhoto field - Binary data 350
Talk 47
Instructions for installing the client 674
Integrated awareness with Notes Client 657 K
Integrated Sametime within the Notes Client 651 Key Concepts
Internal and External Meeting Servers using Invited Scalability, Performance and High Availability.
Meeting Server Model and Separate Directories 52 14
internal user 48, 749 Key File with Self Signed Certificate. 550
Internet Cross Certificate in Primary Address Book Key file with Server Certificate 583
562 Key Ring Created 593
Internet Cross Certificate Trust for Service 561 Key ring created confirmation Screen 570
Internet Protocal (TCP/IP) Properties 239 Key Ring File password import 594
Internet Protocol (TCP/IP) Properties 245, 247, 251 key.kdb file with signer certificates 577
intraserver connection 71, 75 key.kdb with CA’s Trusted Root Certificate 587
Introduction to Enterprise Meeting Server (EMS) Key.kdb with the imported certificate 557
704
Introduction to the Enterprise Deployment Scenario
L
16 Label for Trusted Root Certificate added to
Introduction to the IBM Edge Server Caching Proxy stkeys.kdb 589
620 Launch - Administration 513
IP address 76, 730, 823, 825 Launch - Domino Integration 510
IP spraying 16, 820, 822 LaunchPad window 254
ipconfig 242 LB Network Configuration 226
ipconfig /all 238 lbadmin 260
Isolated External Sametime Meeting Environment LDAP browser 731–732
50

LDAP Connectivity 563 Manager
LDAP Directory - Authentication 169, 212, 325 Log 272
LDAP Directory - Basics 168, 211, 324 Start 272
LDAP Directory - Connectivity settings 167, 210, Nortel Alteon Controller 831
323 Protocols 822
LDAP Directory - Group Contents 169, 213, 325 Server affinity 831
LDAP Directory - Searching 169, 212, 325 Active cookie affinity 834
LDAP Directory settings 150, 193, 307 Cross port affinity 833
LDAP document 734, 807 Passive cookie affinity 834
LDAP host SSL session ID 835
name 731 Stickyness to source IP address 832
LDAP Import File (LDIF) 110, 763, 810 URI affinity 835
LDAP Realm - corrected to WMMRealm 497 Site Selector 831
LDAP Realm set to null 496 Site Selector components 833
LDAP server 59, 71, 84, 114, 704, 713, 716, 800 Load Balancer overview 821
LDAP Server Document in STConfig.nsf 117 Load Balancer Window 261
LDAP User Directory - foundation for Sametime 79 load balancing 2, 15, 41, 43, 704, 706, 819–820
ldapsearch test 351 back-end server 824
LDIF file 110–111, 763, 798, 810 Load balancing in Community Services clusters 43
Load Balancer 19–20, 43, 819–820 Load Balancing, Server Clustering and Failover 15
Advisors 273 Local Area Connection - Properties 246
Connect 273 Local Area Connection Properties 243, 246, 252
HTTP 273 local area network (LAN) 81
base class 830 LocalDomainAdmins ACL access to names.nsf
CBR component 830 162, 205, 318
Cisco CSS Controller 831 LocalDomainAdmins ACL access to stconfig.nsf
Command line interface 164, 208, 320
dscontrol 260 Location Document - Instant Messaging tab 363
component 824 Location document - Server tab 362
Configuration Log in user from client 354
Add cluster 264 Log On To Instant Messaging 364
Add Web servers 270 Log user into Sametime from DWA client 383
Basic scenario 260 Log user into Sametime from QuickPlace client 448
Executor 263 Log user into Sametime from WebSphere Portal
Port 268 486
configuration 832 Loopback Adapter properties 237
Content Based Routing 830 Lotus QuickPlace 59–60, 84
Custom advisors 829 Lotus Sametime 1–2, 46, 48, 649, 807
Dispatcher 822 7.5 3–4
CBR forwarding method 830 7.5.1 13, 16
Start 260 company 746, 748
Executor Enterprise Meeting Server 743
Start 263 Gateway 47, 740, 742
Graphical user interface Gateway 7.5.1 749
lbadmin 260 Gateway policy 743
Installation 254 Gateway server 749
installation path 829 own internal deployment 3
Installation wizard 254 Service 14
LaunchPad 254 software 3
Index 847
Lotus Sametime 7.5 and Microsoft Office integration MS Outlook 529
521 multiple Sametime server 12, 16, 33, 48, 710
Lotus Sametime 7.5.1 in the Enterprise 1 multiple server 8, 15, 33, 723
Lotus Sametime Connect client extension points user load 15
650 My Team page 518
Lotus Sametime Services 6
Lotus Sametime software
History and Market Leadership 3
N
names sent to STLinks for awareness 413
LTPA 719–720, 806
NAT forwarding - Network flow 827
LTPA Configuration page 492
Native Domino 48, 60, 85, 799–800
LTPA User name field 400
native Domino
LDAP Directory Server 60
M Navigating this chapter 331, 538
MAC forwarding 825 nested group 86, 112
MAC forwarding - Network flow 826 Sample LDIF 112
Mac OS X Nested groups in a schema 112
version 10.4 635 Network Adapters 231
Manage binary data 350 Network Address
Manage binary data - Import 348 Port Translation 826
Manage Console Servers 102 Translation 749, 826
Manage Object classes 120 Network Address Translation (NAT)/ Network Ad-
Manage security properties 552 dress Port Translation (NAPT) 826
Manage Server Properties 108 Network Connections 243
Manage user entries 123 network design 33, 67
Manager 823 network DMZ 745, 748
Manager options 272 Lotus Sametime Gateway 748–749
MB minimum 66, 70 Network interface 266
Meeting Created in Calendar 472 Network topology 26
Meeting Detail 473 Network Topology considerations 25
Meeting Details 520 New Certificate Authority database 566
Meeting options available in this version of Notes IM New Certificate Request 579
655 New Cluster Name 217
Meeting Room Client (MRC) 26, 28, 694, 734 New Directory Assistance database 388
meeting Service 2, 4, 29, 46, 85, 692, 694, 704, New Directory Server instance 94
735, 800 New features in Sametime 7.5 and Sametime 7.5.1
meeting service 632
load distribution solutions 704 New key file name and location 546
Meeting Services 9 New Meeting page details 470
Meeting Services Ports 74, 604 New UI for the Sametime Web Conferencing Wel-
Meetings in Outlook 533 come page 663
Members view with awareness 449 NFA 823
Menu options for Sametime functions 660 Non-forwarding address 823
Merge Trusted Root Certificate Confirmation 595 non-forwarding address (NFA) 823
Metric Server 823–824 Nortel Alteon Controller 821, 831
Modify Sametime.ini 558, 590 Notes 8 Instant Messaging 658
Modify Server Document 596 Notes Client - User Preferences... 359
Monitoring Charts available for Sametime 692 Notes Client Integration with Sametime 353
Monitoring Sametime 692 Notes IM 7.0.2 652

Notes Integrated Messaging available in Notes 7.0.2 Option 6
652 Separate External Sametime Meeting Server us-
Notes User Security 559 ing InvitedMeeting Server Model with Separate
N-way chat with the chat sessions presented in a Directories and using Reverse Proxy Access 55
tabbed chat format 639 Option for chat transcripts and time stamps 656
Optional attributes 347
organizational unit (OU) 61, 83, 783
O organizationalPerson 110, 168–169, 324–325,
Object Class 83, 112–113, 794
331, 357, 763–764
OK to complete the import process. 350
organizationalPerson objectclass 763–764
Online Meeting 469
Other functional enhancements 645
on-line meeting 2, 24, 48, 812–813
other Lotus Sametime companies 746, 748
average daily number 3
Outlook tools options 532
Online meeting details in Portal 488
Overall Corporate Sametime Global Architecture for
Online meeting details in QuickPlace 450
ITSO Corporation 132
Online meeting scheduling interface 534
Overview of Basic Sametime Security. 538
On-line Meetings and Instant Messaging – Same-
Overview of Domino Server Stats 697
time Server(s) in the DMZ 49
Overview of EMS 707
Open Sametime Configuration Database 164, 207,
Overview of Global Architecture proposed for ITSO
320
Corporation 57
Open STConfig.nsf on the Sametime server 680
Overview of Sametime Gateway Architecture
Open the Domino Directory 156, 199, 312
742–743
operating system
Overview of Sametime Infrastructure through a Re-
IP alias 826
verse Proxy 622
operating system (OS) 59, 64, 69, 691, 823
Overview of the approach for deployment 18
Option 1
Overview of the deployment approach taken
Isolated External Sametime Meeting Environ-
throughout this Redbook 18
ment 50
Overview of the features in the Sametime 7.5.1 Con-
Option 1 - Sametime 7.5.1 Connect Client -Server
nect Client 636
download option 671
Overview of the Global Architecture proposed for
Option 2
ITSO Corporation 56
Separate External Sametime Meeting Environ-
Overview of the key steps involved in setting up SSL
ment in theDMZ with Selective Directory Repli-
for Sametime 540
cation 51
Overview of the Sametime Gateway 740
Option 2 - Silent Install and Assisted Install options
Overview of the Steps involved for Installation 749
674
Overview of the steps within the basic load balanc-
Option 3
ing scenario 225
Internal and External Meeting Servers using In-
vitedMeeting Server Model and Separate Direc-
tories 52 P
Option 3 - Sametime Java Connect for Browsers Passive cookie affinity 834
678 password 60, 85, 92, 141–142, 285, 288, 331, 351,
Option 4 538, 546, 676, 694, 718–719, 760, 810
Isolated External Sametime Meeting Environ- password jpegPhoto 763–764
ment andusing Reverse Proxy Access 53 People Palette 504
Option 5 Performance 821
Separate External Sametime Meeting Server Person View 398
withSelective Directory Replication and using Personal Certificate Requests 582
Reverse Proxy Access 54 Personal Certificates. 548
Index 849
Perspective - how this component fits into the overall ing Notes 8 client 659
enterprise Infrastructure 132 Primary Clients for Sametime 7.5.1 27
Pick Up Signed Certificates 580 Primary contact list 646
Planning a Sametime 7.5.1 Deployment 21 Process of building the community infrastructure.
Platform Statistics 696, 698 131
Plug-in integration points 649 Prompt for transcript 656
Plug-in integration points and extensibility for the Protecting Sametime with Reverse Proxies 618
Sametime 7.5.x Connect Client 649 Provide a server name and title 141
plugin_customization.ini 676 Provide Sametime server hostname 361
plugin_customization.ini file configuration 676 Providing the Domino server name & description
Plug-ins 10 140
Populating the Directory Server using an LDIF file.
110
Population Topology 22
Q
QuickPlace administration
Port Diagram for EMS Deployment 715
Other options 467
Port information 268
QuickPlace administration - Edit options 463
Portal is ready to install 477
QuickPlace administration - Other Options 462
Portlet Management - Portlets 514
QuickPlace administration - Server Settings 461
Ports 1533 and 8082 added 269
QuickPlace administration place 442
Ports used by Sametime through Firewalls 599
QuickPlace Integration with Sametime 421
Ports used by the Sametime Server 70
QuickPlace Server Configuration 439
Possible configuration names to pass 355,
QuickPlace SSO login screen 458
414–415
Post Domino Installation / Configuration Steps 146,
189, 302, 379, 435 R
Pre-Domino Install Checklist 134, 177, 290, 370, real-time collaboration 1, 4, 740
425 Real-Time Collaboration (RTC) 632
Prerequisite - Define JAAS Alias real-time communication 1, 7, 46
718 Real-Time Streaming Protocol (RTSP) 76–77
Prerequisite - Define WebSphere Variables Receive Certificate from a file 583
717 Recommended deployment 748
Prerequisite - Enabling LDAP Directory Access and- Recommended installation configurations 745
WebSphere Security Recommended maintenance activities 700
719 Recommended Maintenance Activities for Same-
Prerequisite - Enabling UTF-8 support time Environments 700
721 Record and Playback (RAP) 12
Prerequisite - Installing Domino on the first Room Recorded Meeting Broadcast Services ports 76,
Server 606
722 Recorded Meeting Client 688
Prerequisite - Setup Resources and Create Data Redbooks Web site 837
Source Contact us xviii
718 Referring to the Sametime Information Center for In-
Prerequisite- Creating the Application Servers stallation and Configuration 750
721 regedit 241
Prerequisites Register 2nd chat server 172
717 Register a server 422
Pre-Sametime Install Checklist 149, 192, 305 Register Domino server 172, 285, 367, 422
Pre-Sametime Installation Steps 149, 192, 305 Register meeting server 284
Preview of integrated Instant Messaging in upcom- Register New Server(s) - Add to registration queue

176, 289 Upgrade project 814
Register New Server(s) - Register 177, 290 upgrade project plan template 814
Register New Servers 175, 288, 370, 425 user 32
Register Servers 174, 287, 369, 424 Sametime 7.5 highlights 5, 633
Register the server 367 Sametime 7.5.1 ii, 1, 3–4, 27, 742, 750
Register users in Domino 382 Administrators Guide 78
Relative distinguished name 61, 83 Deployment 16
Remote Location 40 full version 27
Request Successful 217 Gateway 742
Resolve user list to show awareness status 354, Information Center 750
383, 449, 487 look 714
Restart the Sametime Server 682 Primary Clients 27
Retrieve Internet Service Certificate 560 server 73
Reverse Proxy subsequent Release 4
Access 53–54 tabbed chat feature 6
Access Description 50–51 testing 59, 84
Reverse proxy (IP forwarding) 620 Sametime 7.5.1 Client options 635
Reverse Proxy Access 53 Sametime 7.5.1 Connect Client 635
Reverse Proxy and Mux 619 Sametime 7.5.1 highlights 5, 634
Rich text formatting 640 Sametime 7.5.1 provides a page with useful infor-
Room Server 704, 711 mation about what is happening 665
administrative management 706 Sametime 7.5.1 Web conferencing 663
concurrent Instant Meetings 712 Sametime Administration Tool 78, 692–693
configuration data 704 Audio/Video Services settings 695
log files 731 Domino Log 693
Services panel 729 Monitoring menu 692
Room Server Setup Overview link 692
727 Sametime log 693
Routing table text file log 693
Windows 227, 240 Sametime and Firewalls 599
Sametime Client Deployment Considerations 631,
668
S Sametime Cluster Information Document, 122
SA Mux 38–40
Sametime Deployment 5, 19, 21–22, 43, 811–812
Community Services Cluster 44
Business Case 812
front-end Sametime 40
project 817
SA mux reduces the overall load on the Sametime
Sametime deployment
server 38
various options 56
same server 831–832
Sametime EMS Installation 724
same time 28, 749
Sametime Gateway 739
Sametime 7.5 ii, 1, 21, 26, 83, 751, 811
Sametime in the Extranet - Community Services 46
Administration guide 695
Sametime in the Extranet - Meeting Services 49
connection 32
Sametime integrated functionality directly within the
deployment 815, 817
mail message 661
distinguishing features 4
Sametime Java Connect for Browsers link exposed
end user 29
683
highlight 5
Sametime Logging 693
Project Plan 814
Sametime Meeting Center - Scheduled Meetings 9
Upgrade effort 814
Sametime Meeting Room 11
Index 851
Sametime Meeting Room client OK with Anonymous access 444
interactive audio/video components 11 Scalability 14, 820
public chat components 8 Scalability with Sametime Multiplexors 15
video components 74, 77 Scenario - Locked Down Desktops or Limited User
video streams 78 Rights 669
Sametime Meeting Room Client (MRC) 684–685 Scenario - Not Locked down, but can they install it ?
Sametime Meeting Room Client, Sametime Record- 669
ed Meeting Client 662, 684 Scenario - Upgrading Older Client Versions 670
Sametime Mobile 667 Scenario - Using an Update Site 671
Sametime Monitoring Charts 692 Scenario - Wide open and No Restrictions 669
Sametime Server 8, 12, 25, 27–28, 33, 38, 70, 78, Schedule a new meeting page 519
86, 116, 691–692, 704, 733, 740, 748, 800, 805, Schema 111
821, 832 Search for Charles 505
Open stconfig.nsf 806 Searching 61, 85
requirement 64 Section Overview 133
Services 29 Secure Sockets Layer (SSL) 71
Sametime server Securing the Sametime Connect client for desktops
Additional information 695 538
anothor important peice 834 Security 62, 86, 538
backward release 13 Security -- Global Security 490
Community Services 38 Security helper file properties 479
Community Services multiplexer 71 security helper file properties 479
Event Server port 71 Security warming when running GSKit setup,exe
individual capacity 39 541
IP address 77 Select $PersonInheritableSchema Subform 808
main difference 735 Select a language 221
Meeting Services 75 Select Domino Directory Template pubnames.ntf
overall load 38 810
required number 49 Select Downloads 67
schedules meetings 713 Select IP address to listen on 95
server document 735 Select Loopback Adapter 232
Token Server port 72 Select the directory to use for collaboration 151,
Sametime server document - Basics 157, 200, 313 194, 307
Sametime Server requirements 64 selected internal user
Sametime Server Setup 149 Directory records 51, 55
Sametime service 4, 6, 22, 35, 84, 692, 729, 813 Selecting a recorded meeting 689
Sametime Setup 191, 305 Selecting keywords 681
Sametime stcenter.nsf 459, 498 Selecting the Load Balancer server 262
Sametime System Requirements - Minimum re- Send links, graphics, and screen captures to chat
quirements and recommendations 63 partners 640
Sametime’s Server key.kdb file. 585 separate directory 48, 51
Sametime’s Server STKeys.jkx 588 Invited Meeting Server Model 55
Sample plugin_customization.ini 677 Separate External Sametime Meeting Environment
Sample Reverse Proxy config 619 in the DMZ with Selective Directory Replication 51
Save changes 681 Separate External Sametime Meeting Server using
Save Meeting to 471 Invited Meeting Server Model with Separate Directo-
Save the configuration 277 ries and using Reverse Proxy Access 55
Saved passwords 539 Separate External Sametime Meeting Server with
Saved user directory Selective Directory Replication and using Reverse

Proxy Access 54 Specify an Administrator name and password
Server affinity in Load Balancer 831 142–143
Server Certificate Administration Database 591 Specify key file name and location 553
Server Certificate Request 580 Specify name and password 440
Server Document for Chat1/ITSO 597 Specifying Sametime Community server in Team
Server document, basic tab 395 Workplace 466
Server Extensibility 13 Specifying the Sametime server in QuickPlace 460
servlet 713, 715, 736 Specifying the Web Conferencing authentication
Session Initiation Protocol (SIP) 742 name 465
Set Load Balancer machine with static IP address Spell checking functionality within the product 643
242 Spell checking preferences 643
Set NIC to listen for imcluster address traffic 242, Spell checking tool 644
246 SSL Encryption 540
Set up an additional server 184, 297, 377, 432 SSL session ID 835
Set up the cluster 260 SSL session Id 828, 835
Set up the first server or a stand-alone server 140 SSL setting in Server Document for chat1/ITSO
Setting default meeting parameters 535 598
Setting JAVA_HOME environment variable. 544 Standalone Mux Hardware Specifications 69
Setting up SSL for Sametime for WEB Services Start Advisor 275
598 Start Domino as a Windows service. 139, 183, 296,
Setting up SSL to LDAP for Quickplace 599 376, 431
Setting up SSL using a self-signed certificate 540 Starting and Stopping Service 100
Setting up SSL using certificate from a Trusted au- Starting embedded WebSphere server 101
thority 564 Starting Executor 263
Setup Business Card Feature for ITSO 341 Starting Manager 272
Setup SSL on Sametime Server with self signed Starting the advisor for port 1533 273
Certificate 553 Starting the advisor for port 8082 275
Setup SSL on Sametime Server with Trusted root Stash Password 546
Certificate 584 Status of the connection 665
Showing removed previous applets 688 stconfig.nsf - Community Connectivity 507
Sign In form mapping 457 stconfig.nsf - LDAP document 356, 419
Signed Server Certificate 581 Stephen Shepherd 110, 116, 764, 798, 800, 805
Signer Certificates for Sametime key.kdb file 555 Steps for installing Tivoli Directory Server 87
Signer Certificates with Domino Certificate Authority Steps to populate using the LDIF File 111
578 Sticky time 832
Silent Install 675 sticky time 832–833
single interface 4 Stickyness 832
single point of failure (SPOF) 821 Stickyness to source IP address 832
Single Sametime Server 29, 31, 706 still active (SA) 38–39
Single Sign On 63, 87 stkey.jks with CA’s Trusted Root Certificate 590
Site Selector 831 Storage Respositories 337
Smart Tags - 528 Subcomponent Selection window 257
Software components 713 subform 808
software extension Successfully saved Web Conferencing parameters
development effort 814 517
effort 815 Suffixes 106
effort tasks/activities 815 Summary of selected installation options. 138, 182,
Software System Requirements 70 295, 375, 430
Specific overview of the Architecture in the US 58 Support for n-way chat history 649
Index 853
Synchronization of contacts 531 tr0 266
Synchronize the directories 384 tr1 266
System Databases for Domino 188, 301, 379, 435 Troubleshooting 529
Systems Management and Maintenance 691 Troubleshooting EMS 731
Trust operation succceded 561
Trust Root Certificate Label 578
T Trusted Root Certificate 576
Tabbed Chat for multiple Sametime sessions 638
Trusted root certificate in notepad 576
Tabbed chat functionality for Sametime from directly
Type ahead name searching 645
within the Notes Client 662
Types of Directories 59, 84
Tabbed chat sessions 638
Typical LDAP DN formats 161, 204, 317
TCP/IP Address 249
TCP/IP connection 34, 72, 822
Sametime protocol 74 U
TCP/IP packet 822 UDP port 77–78
TDS Administrator’ DN and password. 96 multicast data 77
TDS features selection 91 Understanding different models and scale factors
TDS Features to install confirmation screen 93 between Community and Meeting Services 710
TDS IP Ports 96 Understanding the distinguishing features within
TDS Language Selection 87 Sametime 7.5, and Sametime 7.5.1 4, 633
TDS License 89 United State 34, 58
TDS Software installation path 90 update 5, 714–715
TDS Welcome Page 88 Update resolve filter in Sametime. 418
Test Awareness in Portal 503 Update sametime.ini 332
Test Lotus Web Conferencing portlet 517 Update stlinks.js 333
Test SSO between WebSphere Portal and Same- Update the SSO login form for QuickPlace 455
time. 498 updated resolve filter including notescon 357
Test the Sametime Contact List Portlet 509 updated resolve filter including NotesDN 420
Testing online awareness 463 URI affinity 835
Testing Online Meetings 468 URL 101, 705, 711, 828, 831
Testing single sign-on 458 Use Canonical name for instant messaging status
Testing The Business Card Setup 352 lookup 360
Testing the user directory 447 Use Case 1- business card-related information is
The Applications within EMS 713 stored inthe Sametime Directory 338
The Business Value 742 Use Case 2 - Business card-information for a single
The client authentication process 538 userspread across 2 separate and distinct storage
The meeting creation page has been modified 664 repositories 338
The ping test should reply back with the correct IP Use Case 3 - information is spread across two (2)
147, 190, 303 separateyet similar storage types 340
Time stamps and other configurable options 642 user xiii, 1, 7, 21–22, 79, 83, 149, 152, 305, 308,
Tivoli Directory Server Installation 87 331, 335, 539, 558, 631, 635, 692, 694, 710–711,
Tivoli Directory Server Web Administration Tool 740, 746, 763–764, 805–806, 815, 821, 831
342 user directory 19, 59, 61, 79, 83, 805–806
top 12, 32, 106, 110, 235, 331, 438, 635, 695, 699, User directory from QuickPlace administration place
704, 710, 763–764, 805 443
top givenname 763–764 User Filter 719
Topology recommended for connecting to the user objectclass 763–764
AOL®, Yahoo! Messenger™ and Google Talk™ User Security - People, Services 560
user communities 747 Using Multiple Caching Proxy Servers 623

V 828
Verification 216 Prerequisite 718–719
Verification Checkpoint - Domino server setup 147, WebSphere Application Server and DB2 742
190, 303, 380, 436 WebSphere Applicaton Server Edge Components
Verification Checkpoint - Sametime server configu- installation 255
ration 170, 213, 326 WebSphere Everyplace Deployment (WED) 649
Verification Checkpoint - Sametime server installa- WebSphere Portal 27, 59, 84, 800
tion 152, 195, 308 Awareness capabilities 806–807
Verification Checkpoint - Test Domino Cluster 218 Information Center 806–807
Verify New directory server instance 98 server 804
Video and voice enhancements 636 Server mail portlets 116
Video in Chat 636 WebSphere Portal Integration with Sametime 474
View Business Card 645 WebSphere Portal Login Screen 503, 509
View Business Card. 335 Welcome to Domino Integration 511
View Key Ring file with trusted root ITSO Trusted What internet services should this Domino server
Root Authority 596 provide 145, 187, 300, 378, 434
virtual private network (VPN) 49 What is a directory 81
Voice chat functionality 637 What is EMS? 707
What is the Business Card 334
What you will be building in this chapter 130, 282
W When do you use which CBR method? 831
WAS administrator 476
When Should You Deploy EMS 705
WAS/EMS Admin
When Should You NOT Deploy EMS 706
name 729
Where is the ID file for this additional Domino serv-
Password 719, 730
er? 185, 298, 433
Username 719–720
White pages 82
Web browser 10, 71, 101, 722
Why do these need to exist as seperate applica-
HTTP connections 71
tions? 714
Web Conferencing 4, 14, 68, 807, 812
Wide Area Network (WAN) 33, 35
web conferencing 632
Windows Service 717, 729
Web Configurations view 402, 452, 493
word suggestions from spell checking 644
Web server
Working Contact List Portlet 512
Availability 821
Cluster 820, 822
Overloading 820 Y
Performance 821 Yellow pages 82
Scalability 820
Web Site Voice 632
Web SSO Configuration Document 403, 453
Web SSO Configuration for LtpaToken 160, 203,
316
Websphere Administrator 717, 720
security page 731
WebSphere Application
Server 41, 742
Server 6 704
Server Prerequisite 717–718
WebSphere Application Server xvii, 93, 100, 225,
227, 255, 476, 479, 482, 624, 717, 724, 742, 819,
Index 855
Sametime 7.5.1
Best Practices for
Enterprise Scale Deployment
Sametime 7.5.1 - Best Practices
for Enterprise Scale Deployment
Sametime 7.5.1 - Best Practices for Enterprise Scale
Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment
Sametime 7.5.1 - Best
Practices for Enterprise
Scale Deployment
Sametime 7.5.1 - Best
Practices for Enterprise
Scale Deployment
Back cover ®
Sametime 7.5.1
Best Practices for Enterprise
Scale Deployment
Building and This IBM Redbooks publication provides a best practice
deploying an framework for an enterprise-scale deployment of Sametime INTERNATIONAL
Enterprise 7.5. It covers a range of business collaboration requirements TECHNICAL
Architecture that might typically be found within many large enterprises SUPPORT
with geographically dispersed user communities and diverse ORGANIZATION
business requirements for real-time collaboration.
Integration with
Portal and Domino Specifically, we discuss how to plan, install and configure a
extended products Sametime 7.5 infrastructure that will scale to meet the needs BUILDING TECHNICAL
of a large, globally distributed enterprise. We approach the INFORMATION BASED ON
System installation and configuration of Sametime in deployment PRACTICAL EXPERIENCE
phases, beginning with implementing the community
administration and
services (chat functionality) and setting up load balancing.
maintenance IBM Redbooks are developed by
We next implement the online meeting services. Building the IBM International Technical
upon this infrastructure, we then discuss how to integrate Support Organization. Experts
Sametime functionality with other IBM/Lotus products, from IBM, Customers and
including Microsoft Office. Finally, we complete the Partners from around the world
create timely technical
environment by discussing aspects of security, information based on realistic
administration, and recommended maintenance. Other scenarios. Specific
topics covered in the book include a discussion of the recommendations are provided
Enterprise Meeting Server and the Sametime Gateway. to help you implement IT
solutions more effectively in
your environment.
For more information:

ibm.com/redbooks
SG24-7410-00 ISBN 0738486531

Sametime Installation and Integration

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sametime Installation and Integration

Enviado por

Direitos autorais:

Formatos disponíveis

Front cover

Integration with Portal and

Sametime 7.5.1 - Best Practices for Enterprise Scale

First Edition (September 2007)

Chapter 1. Lotus Sametime 7.5.1 in the Enterprise . . . . . . . . . . . . . . . . . . . 1

Chapter 2. Planning a Sametime 7.5.1 Deployment . . . . . . . . . . . . . . . . . . 21

© Copyright IBM Corp. 2007. All rights reserved. iii

Chapter 3. LDAP User Directory - foundation for Sametime . . . . . . . . . . . 79

iv Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

Chapter 4. Deployment phase 1 -

Chapter 5. Deployment phase I -

Chapter 6. Deployment phase II -

vi Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

Chapter 7. Deployment phase III -

Chapter 8. Sametime Client deployment considerations . . . . . . . . . . . . 631

Chapter 9. Systems management and maintenance . . . . . . . . . . . . . . . . 691

Chapter 10. Enterprise Meeting Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 703

Chapter 11. Sametime Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739

viii Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

Appendix A. Directory considerations for Active Directory . . . . . . . . . . 751

Appendix B. Directory considerations for Domino LDAP . . . . . . . . . . . . 799

Appendix C. Project management guide for an Enterprise Sametime

Appendix D. Introduction to load balancing - WebSphere Edge components

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837

x Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

© Copyright IBM Corp. 2007. All rights reserved. xi

Redbooks (logo) ® Everyplace® QuickPlace®

The following terms are trademarks of other companies:

xii Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

Sametime is much more than just chat and Web conferences. It is an

The objective of this IBM Redbooks® publication is to provide a best practice

Specifically, we discuss how to plan, install, and configure a Sametime 7.5.1

The team that wrote this book

© Copyright IBM Corp. 2007. All rights reserved. xiii

Charley Price is a Software Engineer in the IBM Software

Jim Puckett works as a Senior Premium Services Manager in

Vineet Rohatgi is an IBM Certified Software Engineer in the

xiv Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

Jennifer Wales is an IBM Certified Consulting IT Specialist in

Jeff Pinkston is a Senior IT Specialist working in the West

Rob Fox is a Senior IT Specialist for Collaboration Products

John Bergland is a Project Leader at the ITSO, Cambridge

Special acknowledgement to the following team

Jonathan Pepin is a Project Manager with IBM Software

Additional Contributors to this book

Carol Stout - Manager, Interoperability Solutions and Sametime SVT, IBM

xvi Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

Wes Morgan, Consulting - Network Engineer, IBM Software Group, WPLC,

Konrad Lagarde, Software Engineer - Lotus Realtime Collaboration, IBM

Nirmala Venkatraman, Software Engineer - Product Engineering, IBM Software

William Link - Application and Integration Middleware Software, WebSphere

Jennifer Heins - WPLC Technical Content Architect, IBM Software Group,

Jack Downing - Information Architect, Sametime, IBM Software Group, WPLC,

Become a published author

xviii Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

Chapter 1. Lotus Sametime 7.5.1 in the

Sametime is much more than just chat and Web conferences. It is an

The objective of this book is to provide a best practice framework for an

Specifically, we discuss how to plan, install, and configure a Sametime 7.5

© Copyright IBM Corp. 2007. All rights reserved. 1

2 Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

3.1 Sept, 2003

Chapter 1. Lotus Sametime 7.5.1 in the Enterprise 3

Additionally, Lotus Sametime 7.5.1: