Sametime Installation and Integration

ibm.com/redbooks

Sametime 7.5.1Best Practices for Enterprise Scale Deployment

George LambieCharles Price, Jr.

Jim PuckettVineet Rohatgi

Stephen ShepherdJennifer Wales

Jeff PinkstonRob Fox

Building and deploying an Enterprise Architecture

Integration with Portal and Domino extended products

System administration and maintenance

Front cover

http://www.redbooks.ibm.com/


Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

September 2007

International Technical Support Organization

SG24-7410-00

© Copyright International Business Machines Corporation 2007. All rights reserved.Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADPSchedule Contract with IBM Corp.

First Edition (September 2007)

This edition applies to IBM Lotus Sametime 7.5 and subsequently Sametime 7.5.1.

Note: Before using this information and the product it supports, read the information in “Notices” on page xi.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiThe team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiSpecial acknowledgement to the following team members for their contributions

to this project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviAdditional Contributors to this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Chapter 1. Lotus Sametime 7.5.1 in the Enterprise . . . . . . . . . . . . . . . . . . . 11.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.1 Community services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.2 Meeting services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3 Extendable Applications Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.1 Client extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.2 Server extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4 Audio Visual Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.5 Key concepts: scalability, performance, and high availability . . . . . . . . . . 14

1.5.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.5.2 Scalability with Sametime Multiplexors . . . . . . . . . . . . . . . . . . . . . . . 151.5.3 Load balancing, server clustering, and failover . . . . . . . . . . . . . . . . . 15

1.6 Introduction to the Enterprise Deployment Scenario. . . . . . . . . . . . . . . . . 161.7 Overview of the deployment approach taken throughout this book . . . . . 18

Chapter 2. Planning a Sametime 7.5.1 Deployment . . . . . . . . . . . . . . . . . . 212.1 Population topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.1 Determining different classes of users . . . . . . . . . . . . . . . . . . . . . . . 232.2 Network topology considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3 Client considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3.1 Primary clients for Sametime 7.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2 Client PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4 Deployment options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.4.1 Deployment option - single Sametime server . . . . . . . . . . . . . . . . . . 292.4.2 Deployment option - dedicated Sametime servers . . . . . . . . . . . . . . 33

© Copyright IBM Corp. 2007. All rights reserved. iii

2.4.3 Deployment option - multiple Sametime servers. . . . . . . . . . . . . . . . 332.4.4 DeploymeNt Option: Separated Community Multiplexing . . . . . . . . . 382.4.5 Deployment option: SA mux in remote locations . . . . . . . . . . . . . . . 402.4.6 Deployment options for high availability . . . . . . . . . . . . . . . . . . . . . . 40

2.5 High-availability deployment option - Community Services clustering . . . 432.5.1 Deployment option - Sametime in the extranet . . . . . . . . . . . . . . . . . 46

2.6 Overview of the global architecture proposed for ITSO Corporation. . . . . 562.7 Directory considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.7.1 Types of directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592.7.2 Choosing which type of Directory to use. . . . . . . . . . . . . . . . . . . . . . 592.7.3 How Sametime uses the directory . . . . . . . . . . . . . . . . . . . . . . . . . . 602.7.4 Directory components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612.7.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622.7.6 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

2.8 Sametime system requirements - minimum requirements and recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

2.8.1 Sametime server requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642.8.2 Client requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672.8.3 Community Services multiplexer requirements. . . . . . . . . . . . . . . . . 68

2.9 Ports used by the Sametime server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Chapter 3. LDAP User Directory - foundation for Sametime . . . . . . . . . . . 793.1 Directory concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

3.1.1 What is a directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.1.2 Directory components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.2 Directory considerations specific to Sametime 7.5.1. . . . . . . . . . . . . . . . . 833.2.1 Types of directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.2.2 Choosing which type of directory to use . . . . . . . . . . . . . . . . . . . . . . 843.2.3 How Sametime uses the directory . . . . . . . . . . . . . . . . . . . . . . . . . . 853.2.4 Group considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863.2.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863.2.6 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.3 Tivoli Directory Server Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873.3.1 Steps for installing Tivoli Directory Server . . . . . . . . . . . . . . . . . . . . 87

3.4 Administering and configuring the Directory Server . . . . . . . . . . . . . . . . . 993.4.1 Directory Server Web Administration Tool . . . . . . . . . . . . . . . . . . . 100

3.5 Directory information tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063.6 Suffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063.7 Populating the Directory Server using an LDIF file . . . . . . . . . . . . . . . . . 110

3.7.1 Steps to populate using the LDIF file . . . . . . . . . . . . . . . . . . . . . . . 1113.8 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

3.8.1 Nested groups in a schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123.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 . . . . . . . . 1163.9.2 Extending the schema to add NotesDN and NotesCon . . . . . . . . . 1253.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304.2 Perspective - how this fits into the overall enterprise infrastructure . . . . 1324.3 Deploy clustered chat servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

4.3.1 Install/configure the first chat server . . . . . . . . . . . . . . . . . . . . . . . . 1334.3.2 Sametime server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494.3.3 Install/configure the second chat server . . . . . . . . . . . . . . . . . . . . . 1724.3.4 Sametime setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1914.3.5 Create a Domino cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2154.3.6 Create a Sametime cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

4.4 Deploy stand-alone mux servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2204.5 Install and configure IBM Edge Load Balancer components. . . . . . . . . . 224

4.5.1 Overview of the steps within the basic load-balancing scenario . . . 2254.5.2 Configure network to work with the Edge Network Dispatcher

Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2254.5.3 Configure NIC on mux servers to accept traffic for imcluster . . . . . 2264.5.4 Configure NIC on load balancer to accept traffic for imcluster . . . . 2424.5.5 Install Edge Network Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . 2534.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 . . . . . . . . . . . . . . . . . . . . . . . . . 2825.2 Deploy ITSO Corporation’s meeting infrastructure . . . . . . . . . . . . . . . . . 284

5.2.1 Domino setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2845.2.2 Sametime setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Chapter 6. Deployment phase II -integration with other products . . . . . . . . . . . . . . . . . . . . . . . . 329

6.1 Navigating this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3316.2 Case fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3316.3 Business card integration in Connect client . . . . . . . . . . . . . . . . . . . . . . 334

6.3.1 What is the business card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3346.3.2 How the business card feature works . . . . . . . . . . . . . . . . . . . . . . . 3356.3.3 Storage respositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3376.3.4 Business card and storage configurations . . . . . . . . . . . . . . . . . . . 3376.3.5 Best practices for setting up the business card feature . . . . . . . . . 3406.3.6 Set up business card feature for ITSO Corporation . . . . . . . . . . . . 341

Contents v

6.3.7 Testing the business card setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 3526.4 Notes Client integration with Sametime . . . . . . . . . . . . . . . . . . . . . . . . . 353

6.4.1 How instant messaging works using a Notes Client . . . . . . . . . . . . 3536.4.2 Add a Domino canonical name to LDAP Directory . . . . . . . . . . . . . 3556.4.3 Add LDAP’s Domino Canonical Name field to resolve filter . . . . . . 3566.4.4 Configure Notes Client to pass full canonical name format . . . . . . 3586.4.5 Enable awareness in Notes Client . . . . . . . . . . . . . . . . . . . . . . . . . 360

6.5 Domino Web Access integration with Sametime. . . . . . . . . . . . . . . . . . . 3656.6 Install Domino and register the DWA users . . . . . . . . . . . . . . . . . . . . . . 366

6.6.1 Install Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3666.6.2 Register users in Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

6.7 Configure DWA for awareness and chat . . . . . . . . . . . . . . . . . . . . . . . . . 3836.7.1 How instant messaging works in DWA . . . . . . . . . . . . . . . . . . . . . . 3836.7.2 Synchronize the directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3846.7.3 Configure SSO between DWA and Sametime . . . . . . . . . . . . . . . . 4016.7.4 Configure DWA server document for awareness and chat . . . . . . . 4066.7.5 DWA user settings to enable awareness and chat . . . . . . . . . . . . . 4096.7.6 Change how names are passed to Sametime for awareness status413

6.8 QuickPlace integration with Sametime . . . . . . . . . . . . . . . . . . . . . . . . . . 4216.9 Install QuickPlace and configure Security . . . . . . . . . . . . . . . . . . . . . . . . 421

6.9.1 Install Domino for QuickPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4216.9.2 Install QuickPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4386.9.3 Configure QuickPlace Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

6.10 Configure QuickPlace for awareness, chat, and meetings . . . . . . . . . . 4476.10.1 How instant messaging works in QuickPlace . . . . . . . . . . . . . . . . 4486.10.2 How online meetings work in QuickPlace . . . . . . . . . . . . . . . . . . . 4506.10.3 Configure SSO between QuickPlace and Sametime . . . . . . . . . . 4516.10.4 Configure QuickPlace for awareness and chat . . . . . . . . . . . . . . . 4606.10.5 Configure QuickPlace for online meetings . . . . . . . . . . . . . . . . . . 464

6.11 WebSphere Portal Integration with Sametime . . . . . . . . . . . . . . . . . . . 4746.12 Install WebSphere Portal and configure Security . . . . . . . . . . . . . . . . . 474

6.12.1 Install WebSphere Portal v6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4746.12.2 Enable security with realm support . . . . . . . . . . . . . . . . . . . . . . . . 478

6.13 Configure WebSphere Portal for awareness, chat, and meetings . . . . 4856.13.1 How instant messaging works in WebSphere Portal . . . . . . . . . . 4866.13.2 How online meetings work in WebSphere Portal . . . . . . . . . . . . . 4886.13.3 Configure SSO between Portal and Sametime. . . . . . . . . . . . . . . 4896.13.4 Enable awareness and chat in WebSphere Portal . . . . . . . . . . . . 4996.13.5 Configure Sametime to trust Portal for the Sametime Contact List

portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5066.13.6 Configure the Web Conferencing Portlet . . . . . . . . . . . . . . . . . . . 512

6.14 Lotus Sametime 7.5.1 and Microsoft Office integration. . . . . . . . . . . . . 5216.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5387.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538

7.2.1 Overview of Basic Sametime security . . . . . . . . . . . . . . . . . . . . . . . 5387.3 SSL encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

7.3.1 Overview of key steps involved in setting up SSL for Sametime . . 5407.3.2 Setting up SSL using a self-signed certificate. . . . . . . . . . . . . . . . . 540

7.4 Setting up SSL using certificate from a trusted authority . . . . . . . . . . . . 5647.4.1 Configuring the Domino certificate authority . . . . . . . . . . . . . . . . . . 5657.4.2 Installing GSKit on Tivoli Director Server . . . . . . . . . . . . . . . . . . . . 574

7.5 Sametime and firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5997.5.1 Ports used by Sametime through firewalls . . . . . . . . . . . . . . . . . . . 599

7.6 HTTP tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6097.6.1 HTTP tunneling defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6097.6.2 HTTP tunneling at work - Meeting Room Client example . . . . . . . . 6107.6.3 HTTP tunneling’s impact on performance. . . . . . . . . . . . . . . . . . . . 6127.6.4 Best practices for HTTP tunneling . . . . . . . . . . . . . . . . . . . . . . . . . 6157.6.5 HTTP tunneling and SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6167.6.6 HTTP tunneling tweaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617

7.7 Protecting Sametime with reverse proxies . . . . . . . . . . . . . . . . . . . . . . . 6187.7.1 Chat and awareness considerations with reverse proxies . . . . . . . 618

7.8 Introduction to the IBM Edge Server caching proxy . . . . . . . . . . . . . . . . 6207.8.1 Reverse proxy (IP forwarding) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6207.8.2 Using multiple caching proxy servers . . . . . . . . . . . . . . . . . . . . . . . 623

7.9 Caching proxy installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6237.10 Configuration of IBM Edge Server caching proxy . . . . . . . . . . . . . . . . . 627

Chapter 8. Sametime Client deployment considerations . . . . . . . . . . . . 6318.1 About Lotus Sametime 7.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632

8.1.1 New features in Sametime 7.5 and Sametime 7.5.1. . . . . . . . . . . . 6328.1.2 Understanding the distinguishing features within Sametime 7.5 and

Sametime 7.5.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6338.2 Sametime 7.5.1 Client options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635

8.2.1 Sametime 7.5.1 Connect client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6358.2.2 Overview of the features in the Sametime 7.5.1 Connect client . . . 6368.2.3 Enhancements with rich text capabilities . . . . . . . . . . . . . . . . . . . . 6408.2.4 Plug-in integration points and extensibility for Sametime 7.5.x Connect

client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6498.2.5 Integrated Sametime within the Notes Client . . . . . . . . . . . . . . . . . 6518.2.6 Sametime Meeting Room Client and Recorded Meeting Client . . . 662

Contents vii

8.2.7 Sametime Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6678.3 Sametime Client deployment considerations . . . . . . . . . . . . . . . . . . . . . 668

8.3.1 Deployment phase 1: planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6688.3.2 Client employment phase II: implementation . . . . . . . . . . . . . . . . . 6718.3.3 Sametime Meeting Room Client, Sametime Recorded Meeting Client.

6848.4 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689

Chapter 9. Systems management and maintenance . . . . . . . . . . . . . . . . 6919.1 Monitoring Sametime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692

9.1.1 Sametime monitoring charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6929.1.2 Sametime logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6939.1.3 Domino Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6959.1.4 Clustered environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698

9.2 Recommended maintenance activities for Sametime environments. . . . 700

Chapter 10. Enterprise Meeting Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 70310.1 Introduction to Enterprise Meeting Server (EMS) . . . . . . . . . . . . . . . . . 70410.2 Differences between Sametime and EMS. . . . . . . . . . . . . . . . . . . . . . . 70410.3 For which environments is EMS appropriate. . . . . . . . . . . . . . . . . . . . . 705

10.3.1 When should you deploy EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 70510.3.2 When you should not deploy EMS . . . . . . . . . . . . . . . . . . . . . . . . 706

10.4 What is EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70710.4.1 Understanding different models and scale factors between Community

and Meeting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71010.4.2 How EMS handles failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71010.4.3 EMS and clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71110.4.4 EMS Meeting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712

10.5 Hardware and software requirements for EMS . . . . . . . . . . . . . . . . . . . 71210.5.1 Software components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713

10.6 The applications within EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71310.6.1 Why these need to exist as separate applications . . . . . . . . . . . . 714

10.7 EMS deployment - port diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71510.8 Installing and configuring EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716

10.8.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71710.8.2 Sametime EMS installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

10.9 Troubleshooting EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731

Chapter 11. Sametime Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73911.1 Overview of the Sametime Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . 740

11.1.1 The business value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74211.2 Overview of Sametime Gateway architecture . . . . . . . . . . . . . . . . . . . . 742

11.2.1 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74511.2.2 Recommended installation configurations . . . . . . . . . . . . . . . . . . 745

viii Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment

11.2.3 Recommended deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74811.3 Overview of the steps involved for installation . . . . . . . . . . . . . . . . . . . 74911.4 Referring to the Sametime Information Center for installation and

configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750

Appendix A. Directory considerations for Active Directory . . . . . . . . . . 751Installing Active Directory on Windows 2003 . . . . . . . . . . . . . . . . . . . . . . . . . 752Populating the Directory Server using an LDIF file . . . . . . . . . . . . . . . . . . . . 763Configuring Microsoft Active Directory for SSL access . . . . . . . . . . . . . . . . . 764

Adding certificate authority to Microsoft Management Console . . . . . . . . 768Install trusted root from Domino Certificate Authority . . . . . . . . . . . . . . . . 773Requesting server certificate from a third-party certificate authority . . . . . 781Verifying that SSL is enabled on Active Directory Server . . . . . . . . . . . . . 787

Extending the schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789Install the Active Directory schema snap-in . . . . . . . . . . . . . . . . . . . . . . . 790Extending the schema to add attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 792Adding attribute values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798

Appendix B. Directory considerations for Domino LDAP . . . . . . . . . . . . 799Native Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800SSL issues with Native Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800Extending the schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800Domino LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800Installing Domino LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801Setting up SSL for Domino LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802Extending the schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804Dual directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804Dual directories with Native Domino directory . . . . . . . . . . . . . . . . . . . . . . . . 805Dual directories with Domino LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806Adding photos for use with business cards . . . . . . . . . . . . . . . . . . . . . . . . . . 808

Appendix C. Project management guide for an Enterprise Sametime deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811

Business case for Sametime deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . 812Project approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814The Sametime 7.5.1 project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814Sample Sametime deployment project plan. . . . . . . . . . . . . . . . . . . . . . . . . . 817

Appendix D. Introduction to load balancing - WebSphere Edge components819

Introduction to load balancing - WebSphere Edge Components . . . . . . . . . . 820Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821

Contents ix

Load Balancer overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822Content Based Routing (CBR) Component . . . . . . . . . . . . . . . . . . . . . . . 830Site Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831Cisco CSS Controller and Nortel Alteon Controller . . . . . . . . . . . . . . . . . . 831

Server affinity in Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831Stickyness to source IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832Cross port affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833Passive cookie affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834Active cookie affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834URI affinity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835SSL session ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837Help 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

TrademarksThe following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

Redbooks (logo) ®developerWorks®eServer™i5/OS®AIX®Cloudscape™Domino®DB2®

Everyplace®IBM®Lotus Notes®Lotus®MQSeries®Notes®Passport Advantage®PowerPC®

QuickPlace®Redbooks®RDN™Sametime®System i™Tivoli®WebSphere®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 bookThis 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 bookThanks 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 authorJoin 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 welcomeYour comments are important to us!

Preface xvii

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/residencies.html

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:

[email protected]

� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400

xviii Sametime 7.5.1 - Best Practices for Enterprise Scale Deployment



http://www.redbooks.ibm.com/contacts.html

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

1

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

Figure 1-1 Lotus Sametime software: history and market leadership

Lotus Sametime softwareHistory and Market Leadership

1998June, 1998IBM Lotus acquires DataBeam and Ubique

Sept, 2003Lotus IMWC 3.1

1.0

1.5

2.0

2.5

3.0

3.1

Dec, 1998Lotus Sametime 1.0

6.5.1

Sept, 2001Lotus Sametime 2.5

Aug, 2002Lotus Sametime 3.0

1999Lotus Sametime 1.5

Oct, 2000Lotus Sametime 2.0


7.0

7.5

March, 2004Lotus IMWC 6.5.1


Widest and largest enterprise deploymentsHas had almost 16 million corporate IM users

Proven deployments to 25 companies with 100,000-350,000+ user deployments

27 of the Global Fortune 508 out of the top 10 worldwide banks

8 out of the top 10 U.S. pharmaceutical firms

3 of the 4 most profitable companies in the world

7.5.1Apr, 2007Lotus Sametime 7.5.1

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 highlightsHighlights 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 highlightsReleased 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.

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

Multiple chat sessions are presented in a tabbed format


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.

Figure 1-6 Overview of the approach for deployment

Deployment Phase I- Community Services

- SA Muxes- Clustered Chat Servers- Load Balancer

- Meeting Services

1

Overview of Approach for Deployment

User Directory

Deployment Phase II - Integration- Integration with other products

- Domino / DWA- Quickplace- Portal

- RTC Gateway- ST Mobile- ST Links- Bots- MS Office Product Integration

2

Deployment Phase III – Advanced- LDAP Extension to include - Business Cards- Security- Reverse Proxy- Single sign-on (SSO)- Firewalls

3


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.


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


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

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

ITSO Corp North America Europe Asia Pacific

Executives 2000 1000 1000

Sales 9000 4000 2000

Tech Support/Help desk

1000 1000 0

Administrative 7000 2000 1000

Field Personal/outside sales

34000 10000 6000

Staff/Other 22000 12000 5000

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 region

75,000 30,000 15,000

Projected number of community connections per day

60,000 25,000 10,000

Projected peak concurrency of community connections per day

40,000 18,000 7,500

Projected concurrency of n-way chat sessions

3,000 1,250 500

Projected number of Basic Chat users

Projected number of Power Chat users


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.

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

Projected average for number of scheduled meetings per day

120 80 30

Projected number or peak concurrency of scheduled meetings

60 35 15

Percentage of scheduled meetings expected to involve participants from two or more geographic regions

10% 10% 10%

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.

ITSO Corp Americas Europe Asia Pacific


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

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

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.

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

Combination chat and meeting serverWhen 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.

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.


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.

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.

Client type Per connection point

Basic user (Legacy Client or 7.5.1/Notes 8 Integrated Client with modest buddylist, using core chat functionality)

1

Advanced user (7.5.1 Client/Notes 8 Integrated Instant Messaging Client using advanced features: voice/video chat, file transfer, and inline images)

1.2

Sametime links user (Web browser user browsing Sametime-enabled Web site)

1

Meeting user (no A/V) 30


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.

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

MeetingServer

Chat Server

Sametime Connect

Client

Web BrowserMeeting

Room Client

Server 1 Server 2


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.

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.

Community Services

Meeting Services

MultiplexerCommunity Services

InstantMessaging

Users

North America13,000 Users

Asia Pacific7,000 Users

InstantMessaging

Users

151615031352

Community Services

Meeting Services


Sametime 7.5Server 1



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.

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

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.

Sametime 7.5Server2

Meeting Services

Community ServicesMultiplexer


Web BrowserMeeting

Room Client

Sametime 7.5Server1

Meeting Services

Community Services

SametimeConnect

Client

Meeting Services1503

Community Services1515

Domino1352


Web BrowserMeeting

Room Client

SametimeConnect

Client

Multiplexer


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.

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.

InstantMessaging

Users

Community Services

Meeting Services


InstantMessaging

Users


Sametime 7.5Server1

15161503 1352

Europe10,000 Users


InstantMessaging

Users

Community Services

Meeting Services


Sametime 7.5Server2

Community Services

Meeting Services


Sametime 7.5Server3

15161503 1352

15161503 1352


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.

Figure 2-7 SA mux reduces overall load on Sametime server

Multiplexer

Sametime 7.5 Server

Client PCs Client PCs

SametimeMUX1

SametimeMUX2

1516 1516


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.

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

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.

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.

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.

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

Community Services

Meeting Services


InstantMessaging

Users



InstantMessaging

Users

1516 Community ServicesSametime

MUX


Note: Connecting a SA mux to a Sametime server across an internal firewall requires only port 1516 for Community Services.


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.

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.

Note: Fault-tolerant solutions in Sametime require that servers are dedicated to a particular function, either chat or meetings.

COMMUNITY SERVICES CLUSTER

ChatServer

ChatServer

Chat Infrastructure

EMS

Sametime 7.5RoomServer

Sametime 7.5RoomServer

Meeting Infrastructure

Web BrowserMeeting

Room Client

LoadBalancer

SametimeConnect

Client


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.

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

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

Figure 2-10 Adding redundancy through two chat servers

Expanding a Community Services cluster with the SA muxIf 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.

COMMUNITY SERVICES CLUSTER

Sametime 7.5Server

InstantMessaging

User

Sametime 7.5Server

LoadBalancer


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.

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

COMMUNITY SERVICESCLUSTER

Sametime 7.5Server

Sametime 7.5Server

Instant Messaging

User

Load Balancer

SametimeMUX1

SametimeMUX3

SametimeMUX2


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

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.

Figure 2-13 Instant messaging (B2C) - individual external contacts

Company ASametime

ServerCommunity

Lotus SametimeGateway

RTCCompany A

Company BSametime

ServerCommunity


RTCCompany BInternet

InternalServer

Community


RTCCompany A

Internal Firewall External Firewall

AOL Messenger®User

Yahoo!®User

GoogleTalk®User

Internet


http://www.aol.com/aimpro

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.

Figure 2-14 Online meetings and instant messaging - Sametime servers in the DMZ

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

Sametime 7.5Chat Server

Sametime 7.5Chat Server


SIPConnector

Sametime 7.5Meeting Server

ExternalSametime 7.5Chat Server

ExternalSametime 7.5

Meeting Server

Internal LDAPDirectory

External LDAPDirectory

Internal users conducttheir online meetingswith external contactshere (...using their"External Alias"credentials)

External user recordshere (...and "ExternalAlias" entries forinternal people (i.e., employees, contractors)

Note: For additional security, consider housing the External LDAP directory in the protected zone (Intranet) or optionally including another external firewall.


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

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.

Internal Corporate Network

ST 7.5 MeetingServer

DMZ

Directory

STCLUSTER

LoadBalancer(Primary)

LoadBalancer(Backup)


LDAP Server1

LDAP Server2


Sametime 7.5MeetingServer2


Sametime 7.5

Server

Sametime 7.5

Server

Sametime MUX1

InstantMessaging

User

Sametime MUX3

Sametime MUX3


� 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 theDMZ with selective directory replicationThe description, advantages, and disadvantages are:

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

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.

Internal Corporate Network


DMZ

Selective Replication of Internal User Accounts from Corporate LDAP directory to Replica Copy in the DMZ (i.e. only internal

users who are authorized to participate in on -line meeting with external contacts )

Directory Directory


� 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 invitedmeeting server model and separate directoriesThe description, advantages, and disadvantages are:

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

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.

Internal Corporate Network DMZ

Invited Meeting Server ModelInternal

DirectoryExternalDirectory




Option 4: isolated external Sametime meeting environment andusing reverse proxy accessThe description, advantages, and disadvantages are:

� 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).

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.


External Users Directory

ExternalST

MeetingServer

Internet

ReverseProxy


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 withSelective Directory Replication and using reverse proxy accessThe description, advantages, and disadvantages are:

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

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

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.



ExternalST

MeetingServer

Internet

ReverseProxy

Internal Directory

Selective replicationof internal users

to external directory


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

The reverse proxy is Sametime's worst-performing connectivity method (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 invitedmeeting server model with separate directories and using reverse proxy accessThe description, advantages, and disadvantages are:

� 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.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).

Figure 2-20 Separate external Sametime meeting server using invited meeting server model with separate directories and using reverse proxy access



ExternalST

MeetingServer

Internet

ReverseProxy

Internal Directory

Invited MeetingServer Model

InternalST

MeetingServer


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

The reverse proxy is Sametime's worst-performing connectivity method (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.


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.

United States75,000 Users


EMEA30,000 Users

InstantMessaging

User

STCLUSTER

Sametime 7.5Server

STCLUSTER

Invited Meeting Server Model Invited Meeting Server Model

External Sametime infrastructure shown on separate diagram

Inst

ant M

essa

ging

and

Aw

aren

ess

(Com

mun

ity S

ervi

ces)

Inst

ant M

essa

ging

and

Aw

aren

ess

(Com

mun

ity S

ervi

ces)

Dire

ctor

y

Dire

ctor

y

Mee

ting

Serv

ices

Mee

ting

Serv

ices

InstantMessaging

User



SametimeMUX1

SametimeMUX2

SametimeMUX3

SametimeMUX1

SametimeMUX2

Sametime 7.5Server

Sametime 7.5Server

Sametime 7.5Server





LDAP Server1

LDAP Server2

LDAP Server1

LDAP Server2

LDAP Replication LDAP Replication

LDAP Server1

Sametime 7.5MeetingServer

1


2


3


4

InstantMessaging

User

SametimeMUX1

SametimeMUX2






For the sake of clarity, Figure 2-22 illustrates a more focused view of just the United States portion of the architecture.

Figure 2-22 Specific overview of the architecture in the US

STCLUSTER

Sametime 7.5Server

Sametime 7.5Server

Instant Messaging

User

SametimeMUX1

SametimeMUX3

SametimeMUX2




LDAP Server1

LDAP Server2




Invited Meeting ServerModel


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 V7.0.x - Native� Lotus Domino V6.5.x - LDAP server� Lotus Domino V7.0.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

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

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

SearchingSearching 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 assignmentSametime 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 considerationsSametime, 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.

Table 2-3 Hardware server specifications to support Chat or Meeting Services

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.

Server requirements Minimum Real recommendation

Windows platform

CPU Single Intel® Pentium® III 800 MHz or higher.

Four 2 Ghz or better CPUs (4 cores total.

OS Windows 2003 SP1 or later.

Windows 2003 SP1 or 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 setting must be higher than 256 colors.

Video card installed. The setting must be higher than 256 colors. Recommended video display color setting is 16-bit color.


AIX® platform

CPU Dual 375 MHz PowerPC® processor minimum.

Four 1 GHz or higher, IBM Power4 processor recommended.

OS AIX 5.3 Technical Level 5 (for 7.5.1 release).

AIX 5.3 Technical Level 5.



Swap 1 GB minimum. 5 GB RAM recommended.

Video requirements Video card installed. The setting must be higher than 256 colors.


i5/OS

CPU IBM eServer™ iSeriesTM, IBM eServerTM i5, or IBM System i5TM server models capable of running IBM i5/OS V5R3.

IBM eServer iSeriesTM, IBM eServerTM i5, or IBM System i5TM server models capable of running IBM i5/OS V5R3.

OS i5/OS Version 5 Release 3 and Version 5 Release 4.

i5/OS Version 5 Release 3 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 space, minimum of 4 disk drives (arms).

10 GB recommended free space, as this allows for debugging, logging, etc.

Swap

Video requirements



Solaris™

CPU UltraSPARC III 550 MHz processor minimum.

Four UltraSPARC IV 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 than 256 colors.


Linux x86

CPU Intel Pentium III 800 MHz. Four 2 Ghz or better CPUs (4 cores total).

OS Red Hat Enterprise Linux 4.0 Update 4 SUSE Linux Enterprise Server 10.0.

Red Hat Enterprise Linux 4.0 Update 4 SUSE Linux Enterprise Server 10.0.


Disk free 500 MB minimum. 10 GB recommended free space, as this allows for debugging, logging, etc.

Swap 1 GB minimum. 5 GB recommended.

Video requirements The setting must be higher than 256 colors.




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

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.

Client requirement Minimum Real recommendation

Windows/Linux platforms

CPU Pentium 2 - 266 MHz (or higher)

CPU - Pentium 3 800 MHz (or higher)

RAM 512 MB RAM or higher 1 GB recommended

Macintosh

OS Macintosh OSX 10.4.6 (Tiger) with JVM™ 1.5, including patches for PowerPC and Intel J2SE™ 5.0 Release 4a

a. This is Java 1.5 and may have already been acquired through the MacOS autoupdate. It is also available at:http://developer.apple.com/java/download/SWT Compatibility Libraries for J2SE 5.0 Release 4. These are available throughhttp://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 MacOS X 10.4, Release 5 Developer Preview 2.

Macintosh OSX 10.4.6 (Tiger) with JVM 1.5, including patches for PowerPC and Intel J2SE 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 required by Tiger

Higher than 256 colors required by Tiger


http://developer.apple.com/java/download/SWT

http://developer.apple.com/

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

Table 2-5 Client software requirements for meetings

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.

b. This is Java 1.5 and may have already been acquired through the MacOS autoupdate. 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 selectDownloads → Java from the menu on the right. Java for Mac OS X 10.4, Release5 Developer Preview 2.

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.0Client 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.0Client 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


http://developer.apple.com/java/download/SWT

http://developer.apple.com/

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.

Table 2-6 Standalone mux hardware specifications

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.

Mux requirements Minimum Real recommendation

Windows platform

CPU Single Intel Pentium III 800 MHz or higher

Two 2 Ghz or better CPUs (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 space, as this allows for debugging, logging, etc.

Swap 1 GB minimum 3 GB recommended

AIX Platform

CPU Dual 375 MHz PowerPC processor minimum

Two 1 GHz or higher, IBM Power4 processor recommended

OS AIX 5.3 Technical Level 5 (for 7.5.1 release)

AIX 5.3 Technical Level 5

Memory 1 GB 2 GB recommended


Swap 1 GB Minimum 3 GB RAM recommended

Solaris

CPU UltraSPARC III 550 MHz processor minimum

Two UltraSPARC IV 1 GHz processor or higher 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

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 4.0 Update 4 SUSE Linux Enterprise Server 10.0

Red Hat Enterprise Linux 4.0 Update 4 SUSE Linux Enterprise Server 10.0

Memory 1GB 2 GB recommended

Disk free 500 MB minimum 10 GB recommended free space, as this allows for debugging, logging, etc.

Swap 1GB minimum 3 GB recommended

Mux requirements Minimum Real recommendation


HTTP Services, Domino Services, LDAP Services, and Sametimeintraserver 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 HTTP port (8088)

If the administrator allows HTTP tunneling on port 80 during the Sametime installation (or afterward), the Domino HTTP server on 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.


Community Services portsThe 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 9094 The Token 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 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.

If the administrator does not allow HTTP tunneling on port 80 during the Sametime installation, the Community Services clients attempt HTTP-tunneled connections to the Community Services on port 1533 by default.



Port 80 If the administrator allows HTTP tunneling on port 80 during the 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 portsThe 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.

Note that the term direct TCP/IP connection means that the Sametime client uses a unique Sametime protocol operating over TCP/IP to establish a connection with the Meeting Services.

If the administrator does not allow HTTP tunneling on port 80 during the Sametime installation, the Meeting Services clients attempt HTTP-tunneled connections to the Meeting Services on port 8081 by default.


Port 80 If the administrator allows HTTP tunneling on port 80 during the Sametime installation, the Meeting Room Client can make HTTP-tunneled connections to the Community Services multiplexer 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 portsThe 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”.

If the administrator does not allow HTTP tunneling on port 80 during the Sametime installation, the Recorded Meeting clients attempt HTTP-tunneled connections to the Recorded Meeting Broadcast Services on port 554 by default.

Port 80 If the administrator allows HTTP tunneling on port 80 during the Sametime installation, the Recorded Meeting clients can make HTTP-tunneled connections to the Community Services multiplexer 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.


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

Table 2-11 Audio/Video Services ports

Dynamic UDP Ports

The Recorded Meeting Broadcast Services streams meeting data in 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 ports for multicast)

The Recorded Meeting Broadcast Services can take advantage of the bandwidth efficiency provided by multicast-enabled networks. If 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.


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.



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

49252–65535(dynamic UDP port range)

The Sametime Audio/Video Services listen for inbound audio and video streams from Sametime Meeting Room Clients on a range of 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.




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.

3

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� Lotus Domino V6.5.x - Native� Lotus Domino V7.0.x - Native� Lotus Domino V6.5.x - LDAP server� Lotus Domino V7.0.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.

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

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

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

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


http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?toc=/com.ibm.IBMDS.doc/toc.xm

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?toc=/com.ibm.IBMDS.doc/toc.xm

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.

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,

cn: wpsadminsuniquemember:

uid=wpsadmin,cn=users,dc=itso,dc=comobjectclass: groupOfUniqueNames

Domain Suffix:dc=itso, d=com

objectclass=domain

cn=users

objectClass=container

cn=groups

objectClass=container

uid=sshepherdobjectClass=inetOrgPerson

uid=jberglandobjectClass=inetOrgPerson

uid=jwalesobjectClass=inetOrgPerson

uid=glambieobjectClass=inetOrgPerson

uid=wpsadminobjectClass=inetOrgPerson

cn: Sales and Marketinguniquemember:

uid=eshepherd,cn=users,dc=itso,dc=comibm-memberGroup:

cn=Sales,cn=groups,dc=itso,dc=comibm-memberGroup:

cn=Marketing,cn=groups,dc=itso,dc=comobjectclass: groupOfUniqueNames

objectclass: ibm-NestedGroup

cn: Salesuniquemember:

uid=sshepherd,cn=users,dc=itso,dc=comuniquemember:

uid=cprice,cn=users,dc=itso,dc=comobjectclass: groupOfUniqueNames

cn: Marketinguniquemember:

uid=glambie,cn=users,dc=itso,dc=comuniquemember:

uid=jwales,cn=users,dc=itso,dc=comuniquemember:

uid=ahiggins,cn=users,dc=itso,dc=comobjectclass: groupOfUniqueNames


dc=itso,dc=ibm and ou=Tivoli,o=ibm could be defined. Sametime can only use one directory hierarchy.

Adding a suffixTo 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, as shown in Figure 3-28.

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=comdc: itso, dc=comobjectclass: domainobjectclass: top

dn: cn=users,dc=itso,dc=comcn: usersobjectClass: containerobjectClass: top

dn: cn=groups,dc=itso,dc=comcn: groupsobjectClass: containerobjectClass: top

dn: uid=sshepherd,cn=users,dc=itso,dc=comobjectclass: inetOrgPersonobjectclass: organizationalPersonobjectclass: personobjectclass: topobjectclass: ePersongivenname: Stephensn: shepherdcn: Stephen Shepherduid: sshepherduserPassword: password

dn: uid=wpsadmin,cn=users,dc=itso,dc=comobjectclass: inetOrgPersonobjectclass: organizationalPersonobjectclass: personobjectclass: topobjectclass: ePersongivenname: wps


sn: admincn: wps adminuid: wpsadminuserPassword: password

dn: cn=wpsadmins,cn=groups,dc=itso,dc=comobjectclass: topobjectclass: groupOfUniqueNamesobjectclass: ibm-appuuidauxcn: wpsadminsuniquemember: 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


http://publib.boulder.ibm.com/tividd/td/IBMDS/IDSschema52/en_US/HTML/schema.htm

http://publib.boulder.ibm.com/tividd/td/IBMDS/IDSschema52/en_US/HTML/schema.htm



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=comobjectclass: GroupofUniqueNamesobjectclass: ibm-nestedGroupobjectclass: topcn: Level1description: Group composed of static and nested membersuniquemember: uid=sshepherd,cn=users,dc=itso,dc=comuniquemember: uid=vrohatgi,cn=users,dc=itso,dc=comibm-memberGroup: cn=Level2,cn=groups,dc=itso,dc=com

dn: cn=level3,cn=groups,dc=itso,dc=comobjectclass: GroupofUniqueNamesobjectclass: topcn: Level3uniquemember: uid=jbergland,cn=users,dc=itso,dc=comuniquemember: uid=cprice,cn=users,dc=itso,dc=comuniquemember: uid=jpuckett,cn=users,dc=itso,dc=comuniquemember:

dn: cn=level3,cn=groups,dc=itso,dc=comobjectclass: GroupofUniqueNames




objectclass: topcn: Level3uniquemember: uid=jbergland,cn=users,dc=itso,dc=comuniquemember: uid=cprice,cn=users,dc=itso,dc=comuniquemember: 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=comuniquemember=uid=sshepherd,cn=users,dc=itso,dc=comuniquemember=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

ldapsearch -h tds.cam.itso.ibm.com -D cn=root -w redb00k -s base -b "cn=level1,cn=groups,dc=itso,dc=com" objectclass=* ibm-allmembers

cn=Level1,cn=groups,dc=itso,dc=comibm-allmembers=uid=sshepherd,cn=users,dc=itso,dc=comibm-allmembers=uid=vrohatgi,cn=users,dc=itso,dc=comibm-allmembers=uid=glambie,cn=users,dc=itso,dc=comibm-allmembers=uid=jwales,cn=users,dc=itso,dc=comibm-allmembers=uid=ahiggins,cn=users,dc=itso,dc=comibm-allmembers=uid=jbergland,cn=users,dc=itso,dc=comibm-allmembers=uid=cprice,cn=users,dc=itso,dc=comibm-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.


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=comobjectclass: GroupofUniqueNamesobjectclass: ibm-nestedGroupobjectclass: topcn: Salesuniquemember: uid=sshepherd,cn=users,dc=itso,dc=comuniquemember: uid=cprice,cn=users,dc=itso,dc=com

dn: cn=Marketing,cn=groups,dc=itso,dc=comobjectclass: GroupofUniqueNamesobjectclass: ibm-nestedGroupobjectclass: topcn: Marketinguniquemember: uid=glambie,cn=users,dc=itso,dc=comuniquemember: uid=jwales,cn=users,dc=itso,dc=comuniquemember: uid=ahiggins,cn=users,dc=itso,dc=com

dn: cn=Sales and Marketing,cn=groups,dc=itso,dc=comobjectclass: GroupofUniqueNamesobjectclass: ibm-nestedGroupobjectclass: topcn: Sales and Marketinguniquemember: uid=eshepherd,cn=users,dc=itso,dc=comibm-memberGroup: cn=Sales,cn=groups,dc=itso,dc=comibm-memberGroup: cn=Marketing,cn=groups,dc=itso,dc=com

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.


Using ldapsearch, it produced the results shown in Example 3-6.

Example 3-6 ldapsearch for attribute ibm-allgroups

ldapsearch -h tds.cam.itso.ibm.com -D cn=root -w redb00k -s base -b "uid=sshepherd,cn=users,dc=itso,dc=com" objectclass=* ibm-allgroups

uid=sshepherd,cn=users,dc=itso,dc=comibm-allgroups=cn=Level1,cn=groups,dc=itso,dc=comibm-allgroups=cn=Sales,cn=groups,dc=itso,dc=comibm-allgroups=cn=Sales and Marketing,cn=groups,dc=itso,dc=com

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

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

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.

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.


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.

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.

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.


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=comnotescon: CN=Charles Price/O=ITSOnotesdn: CN=Samuel Palmisano,O=ITSOMailfile: mail\SPalmisano.nsfmailserver: dwa.cam.itso.ibm.comSametimeServer: 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


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


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.

Figure 4-1 ITSO Corporation’s Sametime community infrastructure

ITSO s Sametime Community Infrastructure

STCLUSTER

Sametime 7.5Server

Sametime 7.5Server

Instant Messaging

User

SametimeMUX1

SametimeMUX3

SametimeMUX2

LoadBalancer

LDAP Server1

LDAP Server2

LoadBalancer

15338082

15338082

15338082

13521516

15161516

ITSO'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.

Figure 4-2 Process of building the community infrastructure

Building the Community Infrastructure

DeployStand-Alone MUX servers

2

DeployClustered

Chat servers

1

– Install Domino– Install Sametime– Setup Domino

Cluster– Setup Sametime

cluster– Sanity checks

– Deploy Muxservers

– Sanity checks

– Setup theLoad Balancer

– Sanity checks

DeployWebSphere

EdgeLoad Balancer

3

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.

Figure 4-3 Overall corporate Sametime global architecture for ITSO Corporation

United States75,000 Users


EMEA30,000 Users

InstantMessaging

User

STCLUSTER

Sametime 7.5Server

STCLUSTER

Invited Meeting Server Model Invited Meeting Server Model

External Sametime infrastructure shown on separate diagram

Inst

ant M

essa

ging

and

Aw

aren

ess

(Com

mun

ity S

ervi

ces)

Inst

ant M

essa

ging

and

Aw

aren

ess

(Com

mun

ity S

ervi

ces)

Dire

ctor

y

Dire

ctor

y

Mee

ting

Serv

ices

Mee

ting

Serv

ices

InstantMessaging

User



SametimeMUX1

SametimeMUX2

SametimeMUX3

SametimeMUX1

SametimeMUX2

Sametime 7.5Server

Sametime 7.5Server

Sametime 7.5Server





LDAP Server1

LDAP Server2

LDAP Server1

LDAP Server2

LDAP Replication LDAP Replication

LDAP Server1


1


2


3


4

InstantMessaging

User

SametimeMUX1

SametimeMUX2





Chat cluster within one of the geographies


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

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.

STCLUSTER

Sametime 7.5Server

Sametime 7.5Server


Domino Server setupPre-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 DominoTo 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 DominoTo 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.

Table 4-2 Domino organization setup

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.

Field Value

Organization Name ITSO

Organization Certifier Password

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.

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


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

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.

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

Verification checkpoint - Domino server setupAt 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

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.


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:


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

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

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 know the type of directory (Domino directory or LDAP directory) that you are going to use. We use an LDAP directory for ITSO Corporation.

� Temporarily disable any screen savers and turn off any virus-detection 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 SametimeTo 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




Figure 4-19 Select the directory to use for collaboration

9. Uncheck the Enable HTTP tunneling field and click Next.

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.

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.

Note: For more information about HTTP tunneling see 7.6, “HTTP tunneling” on page 609.


Verification checkpoint - Sametime server installationBefore 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=1VPS_IGNORE_UNKNOWN_CLIENT_IP=1VPMX_CAPACITY=20000SAKeyMapper=ConfigurationKeyMapperStandalone.propertiesRSKeyMapper=ConfigurationKeyMapperRoomserver.propertiesST_JAVA_CLASS_PATH=C:\Lotus\Domino\java;C:\Lotus\Domino\StConfig.jar;C:\Lotus\Domino\StConfigXml.jarST_CONFIG_XML=C:\\Lotus\\Domino\\StCommunityConfig.xmlST_JAVA_BB_CLASS_NAME=com.lotus.sametime.configxml.ConfigXmlManagerVP_SECURITY_LEVEL=25HTMLRootDirectory=C:\Lotus\Domino\data\Domino\htmlEnableStaticInvites=0ClusterGroupAffinity=IsolationVPS_NAME=CN=chat1/O=ITSO[STLinks]STLINKS_MAX_USERS=2500STLINKS_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpauseSTLINKS_MAX_OPEN_CONNECTION_TIME=600000[Policy]POLICY_DB_BB_IMPL=com.ibm.sametime.policy.databasebb.notes.DbNotesBlackBoxPOLICY_ADAPTER_IMPL=com.ibm.sametime.policy.calculateservice.PolicyDefaultAdapterPOLICY_DIRECTORY_BB_IMPL=com.ibm.sametime.policy.directorybb.ldap.DirLdapBlackBoxPOLICY_UNIQUE_TRACE_FILES=1POLICY_MAX_THREADS=5POLICY_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause[Debug]POLICY_DEBUG_LEVEL=1VPDIR_IGNORE_BROWSE=1[STReflector]STREFLECTOR_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause[STCapabilities]STCAPABILITIES_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause


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: 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=ITSOSametimeDirectory=C:\Lotus\Domino\dataConfigurationPort=80ConfigurationHost=chat1.cam.itso.ibm.comSametimeEventServerPort=9092ConfigurationChangeListener.count=1ConfigurationChangeListener.classname.1=com.lotus.sametime.configuration.EventPublisherConfigurationChangeListenerConfigurationChangeNotifier.count=1ConfigurationChangeNotifier.classname.1=com.lotus.sametime.configuration.EventListenerConfigurationChangeNotifierLocale=en

Note: To start the Lotus Domino Server (LotusDominodata) service:


services.msc



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

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 SametimeTo configure Sametime:

1. Launch a Lotus Notes client and log in using the Sametime administrator ID.

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


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)

This value should be the host name that your end users use to access the server.

chat1.cam.itso.ibm.com

Load Internet Configurations from Server\Internet Sites documents

Sametime is not designed to retrieve Internet configurations from Internet site documents, and therefore this should be disabled.

disabled

Is this a Sametime server?

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.

Yes

Directory assistance database name

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.

da.nsf

Run This Script After Server Fault/Crash

If a server crashes, it would run this batch file, which collects all the pertinent diagnostics used by IBM Support.

c:\Lotus\Domino\stdiagzip.bat

Directory Type Primary Domino directory


Security

Run unrestricted methods and operations

This field should contain the value on the right for proper operation of the Sametime server.

Sametime Development/Lotus Notes companion products

Administrators

This field should not be empty. It should at the very least contain an administrator’s group.

LocalDomainAdmins

Internet authentication

Provides more security when logging into the Domino Web server.

Fewer name variations with higher security

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

This is populated by the administration process.

TCP

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

TCPIP Network

Net Address

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


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.

Ports/Internet ports

TCP/IP port number

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.

80

TCP/IP port status Enabled

Authentication options

Name and password.

Yes


Anonymous.

Yes

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

Basics

Field Value


11.Fill in the fields as listed in Table 4-6.

Table 4-6 Web SSO configuration for LtpaToken

Figure 4-21 Web SSO configuration for LtpaToken

Field Value

Configuration Name LtpaToken

Organization (Leave blank)

DNS Domain

Note the dot preceding the Internet domain suffix:.domain.com

.cam.itso.ibm.com

Map names in LTPA tokens

Disabled

Domino Server Names

From the address book, select the Sametime server.

chat1/ITSO


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 distinguished name (DN)

What to enter Directory type

1 cn=administrator,cn=users,dc=ibm,dc=com

cn=administrator/cn=users/dc=ibm/dc=com

Active Directory

2 uid=stadmin,cn=users,dc=itso,dc=com

uid=stadmin/cn=users/dc=itso/dc=com

Tivoli Directory Server

3 cn=Sametime Administrator,ou=Austin,O=IBM

Sametime Administrator/Austin/IBM

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

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.

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 ACL with manager access. If not, add the group as needed with 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


16.Click Save & Close.

17.Restart the Domino server.

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 token (map to Notes LTAP_UsrNm)

(Leave blank.)

Naming contexts (rules)

Trusted for CredentialsUse only the first rule.

Yes

LDAP

HostnameProvide the host name of the LDAP server.

tds.cam.itso.ibm.com

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

cn=root

PasswordThe password for the account listed above.

password

Base DN for search dc=itso,dc=com

Channel encryption None

Basics

Field Value


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

e. Click Update if you made any changes.

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.

Field Value

Host name or IP address of the LDAP 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 connection between the Sametime server and the LDAP server

(Leave blank for now)

LDAP SSL Port 636


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

Table 4-12 LDAP Directory - basics

g. Click Update if you made any changes.

Field Value

Where to start searching for people (base object for person entries)

cn=users,dc=itso,dc=com

Scope for searching for a person (the number of levels below the base object, for example, subtree or one level)

recursive

The attribute of the person entry that defines the person’s name (for example, cn or mail)

cn

Attribute used to distinguish between two similar person names

uid

Attribute of a person entry that defines the person’s e-mail address

mail

The object class used to determine if an entry is a person (for example, organizationalPerson)

organizationalPerson

Where to start searching for groups (base object for group entries)

cn=groups,dc=itso,dc=com

Scope for searching for groups (the number of levels below the base object)

recursive

Attribute of the group that defines the group name (for example, cn or mail)

cn

Attribute used to distinguish between two similar group names

The group object class used to determine if an entry is a group (for example, groupOfNames or groupOfUniqueNames)

groupOfUniqueNames


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

Table 4-13 LDAP Directory - authentication

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

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

m. Click Update.

Field Value

Search filter to use when resolving a user name to a distinguished name (Modifying this field affects the name people use to authenticate.)

(&(objectclass=organizationalPerson)(|(cn=%s)(givenname=%s)(sn=%s)(mail=%s)))

Home Sametime server stserver

Field Value

Search filter for resolving person names (&(objectclass=organizationalPerson)(|(cn=%s*)(givenname=%s*)(sn=%s*)(mail=%s*)))

Search filter for resolving group names (&(objectclass=groupOfUniqueNames)(cn=%s*))

Policy search filters

Base Membership

Group Membership ibm-allgroups

Field Value

Attribute in the group object class that has the names of the group members (for example, member or uniqueMember)

ibm-allmembers


19.Shut down the Domino server.

We have completed configuring Sametime. We now need to proceed with validating this configuration.

Verification checkpoint - Sametime server configurationThe 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.

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 notes.ini configuration file.

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


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/

b. Click Administer the server on the left-hand side.

c. Log in with the LDAP account that has manager access to stconfig.nsf.

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.

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.

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.

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.

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 setupIn this section we discuss the Domino setup.

Register second chat serverTo 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

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

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

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.

Uncheck In Domino Directory.Check In file.


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 checklistThe checklist is:









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










4. Choose the program directory in which to copy the Lotus Domino software (that is, C:\Lotus\Domino) (Figure 4-33). Click Next.




5. Choose the data directory in which to copy the Lotus Domino data files (that 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 DominoTo 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.

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.

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.


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


8. Click Customize and uncheck the following Domino server tasks:

– Mail Router– Calendar Connector– Schedule Manager– DOLS Domino Off Line Services– Rooms and Resources Manager

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


� Database Replicator� Agent Manager� Administration Process� HTTP Server


9. Click OK, then Next to continue.

Figure 4-41 What Internet services should this Domino server provide?




b. For the TCP/IP Notes Port Driver, enter in the fully qualified host name for the Domino server in the Host Name (Editable) field.




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

Leave unchecked


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 Domino Server setup process.


Post Domino installation/configuration stepsYou 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 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.)


a. Click Start → Run, and enter the following:

services.msc


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

Use a dialup connection Leave Unchecked

Get system databases from CD or other media

Leave Unchecked

Field Value


Verification checkpoint - Domino server setupAt 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 the local network configuration:


cmd


ping chat2.cam.itso.ibm.com



ipconfig

2. Verify that the Domino HTTP server starts successfully.

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.



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.



4. From a Lotus Notes client, select the following from the menu bar: File → 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 Domino server via a Notes client.


4.3.4 Sametime setup

In this section we discuss Sametime setup.


Pre-Sametime installation stepsThe steps are:





Pre-Sametime install checklistCheck the following:





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






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









� Before running any Sametime setup command, complete any pending reboot actions you may have from installing other applications.









Field Value





7. Click Next to continue.


9. Uncheck the Enable HTTP tunneling field blank and click Next.


11. Once completed, click Finish to exit the installation wizard.

12. Reboot the operating system to complete the installation.

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.

Note: For more information about HTTP tunneling see 7.6, “HTTP tunneling” on page 609



1. Ascertain that all Sametime services were registered successfully:


services.msc

b. In the Windows services panel, verify that all of the following exists:

• 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 and are set accordingly respective to your local environment (Example 4-5).


# Sametime configuration file[Config]VP_PRIV_SYM=1VPS_IGNORE_UNKNOWN_CLIENT_IP=1VPMX_CAPACITY=20000SAKeyMapper=ConfigurationKeyMapperStandalone.propertiesRSKeyMapper=ConfigurationKeyMapperRoomserver.propertiesST_JAVA_CLASS_PATH=C:\Lotus\Domino\java;C:\Lotus\Domino\StConfig.jar;C:\Lotus\Domino\StConfigXml.jarST_CONFIG_XML=C:\\Lotus\\Domino\\StCommunityConfig.xmlST_JAVA_BB_CLASS_NAME=com.lotus.sametime.configxml.ConfigXmlManagerVP_SECURITY_LEVEL=25HTMLRootDirectory=C:\Lotus\Domino\data\Domino\htmlEnableStaticInvites=0ClusterGroupAffinity=IsolationVPS_NAME=CN=chat2/O=ITSO[STLinks]STLINKS_MAX_USERS=2500STLINKS_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpauseSTLINKS_MAX_OPEN_CONNECTION_TIME=600000[Policy]POLICY_DB_BB_IMPL=com.ibm.sametime.policy.databasebb.notes.DbNotesBlackBoxPOLICY_ADAPTER_IMPL=com.ibm.sametime.policy.calculateservice.PolicyDefaultAdapterPOLICY_DIRECTORY_BB_IMPL=com.ibm.sametime.policy.directorybb.ldap.DirLdapBlackBoxPOLICY_UNIQUE_TRACE_FILES=1POLICY_MAX_THREADS=5POLICY_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause[Debug]POLICY_DEBUG_LEVEL=1VPDIR_IGNORE_BROWSE=1[STReflector]STREFLECTOR_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause[STCapabilities]STCAPABILITIES_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause


3. Verify that all of the Sametime servlets initialize successfully.




ServerTasks=Update,Replica,AMgr,AdminP,HTTP

c. Start the Lotus Domino Server (LotusDominodata) service from the Windows services panel, and do the following:

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]SametimeCluster=CN=chat2/O=ITSOSametimeDirectory=C:\Lotus\Domino\dataConfigurationPort=80ConfigurationHost=chat2.cam.itso.ibm.comSametimeEventServerPort=9092ConfigurationChangeListener.count=1ConfigurationChangeListener.classname.1=com.lotus.sametime.configuration.EventPublisherConfigurationChangeListenerConfigurationChangeNotifier.count=1ConfigurationChangeNotifier.classname.1=com.lotus.sametime.configuration.EventListenerConfigurationChangeNotifierLocale=en



services.msc



i. Verify that each of the Sametime servlets initialize successfully. As each servlet initializes, a debug print is written to the Domino server console. See Example 4-7.

Example 4-7 Domino Bootstrap servlet successful initialization example


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 SametimeTo configure Sametime:

1. Launch a Lotus Notes client and log in using the Sametime administrator’s ID.




2. From the menu bar, select File → Database → Open and open the Domino 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






disabled


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.

Yes


When you install Sametime to use an LDAP directory, a directory assistance database is created, and, by default, is named da.nsf. If you have another database that you prefer to use, update this field to point to that one.

da.nsf






Security



Sametime Development/Lotus Notes Companion Products

Administrators


LocalDomainAdmins




Ports/notes network portsOn 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

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

TCPIP Network

Net Address



Enabled Enabled

Basics

Field Value




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

Ports/Internet ports

TCP/IP port number

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.

80



Name and password.

Yes


Anonymous.

Yes

SSL port number 443




Internet Protocols/Domino Web engine





Class path Domino\servlet

Basics

Field Value


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.

14.Confirm administrative access to the Sametime server for the LDAP account that will be used to administer the server.



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 on page 161 for examples on how to enter the DN into the Members field.






Active Directory








d. Click Save & Close.


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


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



Field Value


Access Manager


Roles Check All


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



h. From the menu bar, select File → Database → Open and open the Sametime Configuration database (stconfig.nsf).




j. Verify that the administrative group (LocalDomainAdmins) is listed in the ACL with manager access. If not, add the group as needed with the following settings (see Table 4-9 on page 164).



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

16.Configure directory assistance to allow for LDAP authentication to the Domino Web server.

Field Value


Access Manager


Roles Check All




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


(Leave blank.)

Naming contexts (rules)

Trusted for CredentialsUse only the 1st rule

Yes

LDAP

Hostname

Provide the host name of the LDAP server.


Username

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.

cn=root




19.When the Domino server is back up, we update Sametime’s LDAP settings via the Sametime administration interface.







Password

The password for the account listed above.

password



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

Field Value

Host name or IP address of the LDAP server.


Position of this server in the search order. 1

Port. 389

Administrator distinguished name. cn=root

Basics

Field Value





Administrator password. password

Use SSL to authenticate and encrypt the connection between the Sametime server and the LDAP server.

(Leave blank for now.)

LDAP SSL Port. 636

Field Value




recursive


cn


uid


mail






recursive


cn


Field Value



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

Table 4-26 LDAP Directory - authentication

i. Click Update if you made any changes.

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


k. Click Update.


groupOfUniqueNames

Field Value




Field Value




Base Membership


Field Value


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


m. Click Update.


We have successfully completed configuring Sametime. We now can proceed to validate this configuration.

Verification checkpoint - Sametime server configurationThe steps are:


2. Click Start → Run and enter:

services.msc



Field Value


ibm-allmembers

Tip: This step provides the administrator with the ability to monitor Sametime Meeting server’s startup 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:





This console window appears but remains 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.



6. Add STAddin back to the ServerTasks notes.ini parameter and save the notes.ini configuration file.


ServerTasks=Update,Replica,AMgr,AdminP,HTTP,STAddin


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. Click Start → Run, and enter the following:

services.msc



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.




d. On the Server-Overview page, you will see a complete list of all the Sametime services and their respective status. Verify that all of the Sametime services are running.

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

Notes: The Telephony Services (sttelephonyservice.exe) are not running by default. This is okay and should not be a point of concern.



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

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

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.

Field Value

Cluster Name

This value is used as the users’ Home Sametime server. It is specified in an attribute in the LDAP directory.

stchatcluster

DNS Name

Specify the DNS host name of the load balancer that will be placed in front of the stand-alone mux servers.

lb.cam.itso.ibm.com

List of servers in the cluster. cn=chat1/o=itso; cn=chat2/o=itso

Field Value

Community Trusted IPs

Specify the IPs of both mux servers.

9.33.85.66; 9.33.85.67

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


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.

Figure 4-59 Deploy stand-alone mux servers

Building the Community Infrastructure

DeployStand-Alone MUX servers

2

DeployClustered

Chat servers

1

– Install Domino– Install Sametime– Setup Domino

Cluster– Setup Sametime

cluster– Sanity checks

– Deploy Muxservers

– Sanity checks

– Setup theLoad Balancer

– Sanity checks

DeployWebSphere

EdgeLoad Balancer

3


Install stand-alone mux serverTo 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 serverAfter 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.

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

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






Table 4-31 LB network configuration

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

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.

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

Machine functionality Machine name IP address

Chat cluster address imcluster.cam.itso.ibm.com 9.33.85.78


Install loopback adapterIf 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 List0x1 ........................... MS TCP Loopback interface0x1000003 ...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 1Default Gateway: 10.20.10.1===========================================================================Persistent Routes: None


http://www.redbooks.ibm.com/abstracts/SG246392.html

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 addressTo 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 List0x1 ........................... MS TCP Loopback interface0x1000003 ...00 02 55 91 4b 4c ...... AMD PCNET Family Ethernet Adapter0x3000004 ...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 1Default 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 offroute delete 10.20.10.0 10.20.10.100exit

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 (9.33.85.78 in our environment).

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 addressTo 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 (255.255.255.128 in our environment).

– Default gateway: This should be the default gateway for your environment (9.33.85.1 in our 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 trafficTo 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 (255.255.255.128 in our 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.

1. Start LaunchPad by running launchpad.bat.

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

Figure 4-89 LaunchPad window

Important: Before starting with the installation, you should have Java Runtime (V1.4.2 or later) installed on your system.


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.

Figure 4-94 America’s chat cluster scenario

STCLUSTER

Sametime 7.5Server

Sametime 7.5Server

Instant Messaging

User

SametimeMUX1

SametimeMUX3

SametimeMUX2

LoadBalancer

LDAP Server1

LDAP Server2

LoadBalancer

15338082

15338082

15338082

13521516

15161516

Configuring thisload balancerand ports


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 clusterThe 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 shown in Figure 4-97.

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

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

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.


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 shown in Figure 4-106.

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 componentTo 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 bitsFirst 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.


2. Next run the same command for port 8082:

dscontrol port set imcluster.cam.itso.ibm.com:8082 stickytime 600

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 configurationWe 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).

Note: The stickytime is the number of seconds.


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 1dscontrol executor start

dscontrol cluster add imcluster.cam.itso.ibm.com address 9.33.85.78 primaryhost 9.33.85.68dscontrol cluster set imcluster.cam.itso.ibm.com proportions 49 50 1 0dscontrol executor configure 9.33.85.78 en0 255.255.255.128

dscontrol port add imcluster.cam.itso.ibm.com:8082 reset nodscontrol port set imcluster.cam.itso.ibm.com:8082 stickytime 600

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


dscontrol port add imcluster.cam.itso.ibm.com:1533 reset nodscontrol port set imcluster.cam.itso.ibm.com:1533 stickytime 600




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.



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


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.

Figure 5-1 ITSO Corporation’s Sametime community infrastructure

STCLUSTER

Sametime 7.5Server

Sametime 7.5Server

Instant Messaging

User

SametimeMUX1

SametimeMUX3

SametimeMUX2




LDAP Server1

LDAP Server2




Invited Meeting ServerModel

ITSO's Sametime Meeting Services 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 serverTo do this:


2. From the menu bar, select File → Open Server and enter in the host name of 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).



9. You may be prompted with a Certifier Recovery Information Warning dialog window (Figure 5-5). Click OK to continue.


10.On the Register Servers dialog window, confirm that the registration server (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.


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

Field Value

Server name meeting1

Server title (optional) meeting server





Uncheck In Domino directory.Check In file.


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


14.Highlight the new server and click the Register button to complete the server 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 checklistCheck the following:


























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 DominoTo do this:






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



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 (Figure 5-16).


6. On the Provide the registered name of this additional Domino server screen, click Next.

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.




8. Click Customize and uncheck the following Domino server tasks: DOLS Domino Off Line ServicesRooms and Resources Manager.

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.


� Database Replicator� Mail Router� Agent Manager� Administration Process� 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?




b. For the TCP/IP Notes Port Driver, enter in the fully qualified host name for the Domino server in the Host Name (Editable) field.




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


Field Value




Leave Unchecked



14.On the Secure your Domino Server screen, uncheck “Prohibit Anonymous access to all databases and templates” and then 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 Domino Server setup process.


Post Domino installation/configuration stepsYou 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 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.)



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.

Use a dialup connection Leave Unchecked


Leave Unchecked

Field Value


Verification Checkpoint - Domino server setupAt 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


ping meeting1.cam.itso.ibm.com



ipconfig

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:


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.




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, as in Figure 5-20.



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, 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 Domino server via a Notes client.



5.2.2 Sametime setup

In this section we discuss Sametime setup.

Pre-Sametime installation stepsDo the following:





Pre-Sametime install checklistCheck the following:





� 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, meeting1.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:



� 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 Corp.









� Before running any Sametime setup command, complete any pending reboot actions that you may have from installing other applications.













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.

Field Value



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


11.Reboot the operating system to complete the installation.


1. Ascertain that all Sametime services were registered successfully.


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 and are set accordingly respective to your local environment (Example 5-1 on page 309).



# Sametime configuration file[Config]VP_PRIV_SYM=1VPS_IGNORE_UNKNOWN_CLIENT_IP=1VPMX_CAPACITY=20000SAKeyMapper=ConfigurationKeyMapperStandalone.propertiesRSKeyMapper=ConfigurationKeyMapperRoomserver.propertiesST_JAVA_CLASS_PATH=C:\Lotus\Domino\java;C:\Lotus\Domino\StConfig.jar;C:\Lotus\Domino\StConfigXml.jarST_CONFIG_XML=C:\\Lotus\\Domino\\StCommunityConfig.xmlST_JAVA_BB_CLASS_NAME=com.lotus.sametime.configxml.ConfigXmlManagerVP_SECURITY_LEVEL=25HTMLRootDirectory=C:\Lotus\Domino\data\Domino\htmlEnableStaticInvites=0ClusterGroupAffinity=IsolationVPS_NAME=CN=meeting1/O=ITSO[STLinks]STLINKS_MAX_USERS=2500STLINKS_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpauseSTLINKS_MAX_OPEN_CONNECTION_TIME=600000[Policy]POLICY_DB_BB_IMPL=com.ibm.sametime.policy.databasebb.notes.DbNotesBlackBoxPOLICY_ADAPTER_IMPL=com.ibm.sametime.policy.calculateservice.PolicyDefaultAdapterPOLICY_DIRECTORY_BB_IMPL=com.ibm.sametime.policy.directorybb.ldap.DirLdapBlackBoxPOLICY_UNIQUE_TRACE_FILES=1POLICY_MAX_THREADS=5POLICY_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause[Debug]POLICY_DEBUG_LEVEL=1VPDIR_IGNORE_BROWSE=1[STReflector]STREFLECTOR_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause[STCapabilities]STCAPABILITIES_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause


3. Verify that all of the Sametime servlets initialize successfully.




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

c. Start the Lotus Domino Server (LotusDominodata) service from the Windows services panel, and do the following:

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=ITSOSametimeDirectory=C:\Lotus\Domino\dataConfigurationPort=80ConfigurationHost=meeting1.cam.itso.ibm.comSametimeEventServerPort=9092ConfigurationChangeListener.count=1ConfigurationChangeListener.classname.1=com.lotus.sametime.configuration.EventPublisherConfigurationChangeListenerConfigurationChangeNotifier.count=1ConfigurationChangeNotifier.classname.1=com.lotus.sametime.configuration.EventListenerConfigurationChangeNotifierLocale=en



services.msc



i. Verify that each one of the Sametime servlets initialize successfully. As each servlet initializes, a debug print is written to the Domino server console. See Example 5-3.

Example 5-3 Domino bootstrap servlet successful initialization example


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 SametimeTo do this:

1. Launch a Lotus Notes client and log in using the Sametime administrator’s ID.




2. From the menu bar, select File → Database → Open and open the Domino 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



meeting1.cam.itso.ibm.com



disabled


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.

Yes


When you install Sametime to use an LDAP directory, a directory assistance database is created, and, by default, is named da.nsf. If you have another database that you prefer to use, update this field to point to that one.

da.nsf






Security



Sametime Development/Lotus Notes Companion Products

Administrators


LocalDomainAdmins




Ports/Notes Network PortsOn 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

Notes Network

This is an arbitrary value, but it is used for Domino messaging. We recommend that this value matches all Sametime servers in the same community.

TCPIP Network

Net Address


meeting1.cam.itso.ibm.com

Enabled Enabled

Basics

Field Value




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

Ports/Internet Ports

TCP/IP port number

By default the Domino HTTP Web server listens on all IPs for this port. Make sure that there are no other products that will interfere with this port.

80



Name and password.

Yes


Anonymous.

Yes

SSL port number 443




Internet Protocols/Domino Web Engine





Class path domino\servlet

Basics

Field Value


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.

14.Confirm administrative access to the Sametime server for the LDAP account that will be used to administer the server:



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 5-5 for examples of how to enter the DN into the Members field.






Active Directory








d. Click Save & Close.


f. Verify that the administrative group (LocalDomainAdmins) is listed in the ACL with manager access. If not, add the group as needed with the following settings (Table 5-6).


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



Field Value


Access Manager


Roles Check All


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



h. From the menu bar, select File → Database → Open and open the Sametime Configuration database (stconfig.nsf) (Figure 5-27).



j. Verify that the administrative group (LocalDomainAdmins) is listed in the ACL with manager access. If not, add the group as needed with the following settings (see Table 5-7).


Field Value


Access Manager


Roles Check All



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

16.Configure directory assistance to allow for LDAP authentication to the Domino 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


(leave blank)

Naming Contexts (Rules)

Trusted for Credentials

Use only the first rule.

Yes

LDAP

Hostname

Provide the host name of the LDAP server.


Username

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.

cn=root

Password

The password for the account listed above.

password





19.When the Domino server is back up, update Sametime’s LDAP settings via the Sametime administration interface:








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 backup. This can cause many problems that we would like to avoid. In order to restart the Sametime server, we recommend splitting out the process: 1) quit the server first, and then 2) start it back up.

Field Value

Host name or IP address of the LDAP 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 connection between the Sametime server and the LDAP server

(Leave blank for now.)

Basics

Field Value






LDAP SSL Port 636

Field Value




recursive


cn


uid


mail






recursive


cn



groupOfUniqueNames

Field Value


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

Table 5-11 LDAP Directory - Authentication

i. Click Update if you made any changes.

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


k. Click Update.

l. Expand LDAP Directory → Group Contents and fill in the fields shown in Table 5-13.


m. Click Update.

Field Value




Field Value




Base Membership


Field Value


ibm-allmembers



We have successfully completed configuring Sametime. We now can proceed to validate this configuration.

Verification Checkpoint - Sametime server configurationTo configure:


2. Click Start → Run, and enter:

services.msc




6. Add STAddin back to the ServerTasks notes.ini parameter and save the notes.ini configuration file (Example 5-4).


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

Tip: This step provides the administrator with the ability to monitor Sametime Meeting server’s startup 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:





This console window appears but remains 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.



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:





d. On the Server-Overview page, you will see a complete list of all the Sametime services and their respective status. Verify that all of the Sametime services are indeed running.



services.msc



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.

Notes: The Telephony Services (sttelephonyservice.exe) will not be running by default. This is okay and should not be a point of concern.






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

6


� 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

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=comobjectclass=inetOrgPersonobjectclass=organizationalPersonobjectclass=personobjectclass=topobjectclass=ePersonobjectclass=ibm-appuuidauxgivenname=Charlessn=Pricecn=Charles Priceuid=cpriceuserpassword=passwordstserver=stchatclustermail=Charles.Price@itso.com

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.

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.iniTo 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:

STLINKS_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause -DAWARENESS_CASE_SENSITIVE=0

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=1VPS_IGNORE_UNKNOWN_CLIENT_IP=1VPMX_CAPACITY=20000SAKeyMapper=ConfigurationKeyMapperStandalone.propertiesRSKeyMapper=ConfigurationKeyMapperRoomserver.propertiesST_JAVA_CLASS_PATH=C:\Lotus\Domino\java;C:\Lotus\Domino\StConfig.jar;C:\Lotus\Domino\StConfigXml.jarST_CONFIG_XML=C:\\Lotus\\Domino\\StCommunityConfig.xml

Note: This should appear on one line in your sametime.ini.


ST_JAVA_BB_CLASS_NAME=com.lotus.sametime.configxml.ConfigXmlManagerVP_SECURITY_LEVEL=25HTMLRootDirectory=C:\Lotus\Domino\data\Domino\htmlEnableStaticInvites=0ClusterGroupAffinity=IsolationVPS_NAME=CN=chat1/O=ITSOSametimeCluster=CN=chat1/O=ITSOSametimeDirectory=C:\Lotus\Domino\dataConfigurationPort=80ConfigurationHost=chat1.cam.itso.ibm.comSametimeEventServerPort=9092ConfigurationChangeListener.count=1ConfigurationChangeListener.classname.1=com.lotus.sametime.configuration.EventPublisherConfigurationChangeListenerConfigurationChangeNotifier.count=1ConfigurationChangeNotifier.classname.1=com.lotus.sametime.configuration.EventListenerConfigurationChangeNotifierLocale=enAWARENESS_CASE_SENSITIVE=0

[STLinks]STLINKS_MAX_USERS=2500STLINKS_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause -DAWARENESS_CASE_SENSITIVE=0STLINKS_MAX_OPEN_CONNECTION_TIME=600000[Policy]POLICY_DB_BB_IMPL=com.ibm.sametime.policy.databasebb.notes.DbNotesBlackBoxPOLICY_ADAPTER_IMPL=com.ibm.sametime.policy.calculateservice.PolicyDefaultAdapterPOLICY_DIRECTORY_BB_IMPL=com.ibm.sametime.policy.directorybb.ldap.DirLdapBlackBoxPOLICY_UNIQUE_TRACE_FILES=1POLICY_MAX_THREADS=5POLICY_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause

Update stlinks.jsTo 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

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.

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.


Use case 1- business card-related information is stored inthe Sametime directoryThe 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

User information stored in the Primary Storage:Name, Address, Email, Phone number, & User’s Photo

Use case 2 - business card information for a single userspread across two separate and distinct storage repositoriesBusiness 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 directorySecondary Storage type: Custom Notes Database

User information stored in the Primary Storage: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 directorySecondary Storage type: Custom Notes Database



Example 6-8 Data spread across two storage repositories (Domino/LDAP)

Primary Storage (Sametime directory) type: Domino directorySecondary Storage type: LDAP directory



Example 6-9 Data spread across two storage repositories (LDAP/Domino)

Primary Storage (Sametime directory) type: LDAP directorySecondary 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 separateyet similar storage typesThe 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)

Primary Storage (Sametime directory) type: Domino directorySecondary Storage type: Domino directory



Example 6-11 Data spread across two storage repositories (LDAP/LDAP)

Primary Storage (Sametime directory) type: LDAP directorySecondary 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.


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

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.


Import user photo into the TDS LDAP directoryTo 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


http://tds.cam.itso.ibm.com:12100/IDSWebApp/IDSjsp/Login.jsp

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

Figure 6-18 ldapsearch test

Configure business card to display informationTo 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: 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.


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

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&userId=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 clientThrough 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 Sametime Connect client.

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.

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 statusOnce 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/ITSOFull 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

Note: This option only works when Sametime authenticates against Native Domino or Domino LDAP.


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

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.

Type Name passed

Abbreviated canonical John Bergland/ITSO

Full canonical CN=John Bergland/O=ITSO


6.4.3 Add LDAP’s Domino Canonical Name field to resolve filter

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

Note: This section should only need to be completed if Sametime authenticates against a Non-Domino LDAP directory.


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 nameTo 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 seen in Figure 6-25.

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



http://www-128.ibm.com/developerworks/lotus/documentation/domino/

Register the serverTo 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, 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).


10.On the Register Servers dialog window, confirm that the registration server (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).


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 checklistCheck the following:





Field Value

Server name dwa

Server title (optional) Domino Web Access server 2














Install DominoTo install Lotus Domino on a Windows platform:












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.











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



6. On the Provide the registered name of this additional Domino server, click Next.

Note: In previous steps we stored the DWA’s server ID on chat1’s local file system and not in the Domino directory. For this step within the setup 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.


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:


b. For the TCP/IP Notes Port Driver, enter in the fully qualified host name for the Domino server in the Host Name (Editable) field (dwa.cam.itso.ibm.com in our test environment).

c. In the text field on the bottom of the screen, enter in the same fully 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.




14.On the Please review and confirm your chosen server setup options screen, confirm the options that you have selected, and then click Setup to initiate the Domino Server setup process.


Do the post Domino installation/configuration stepsYou 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 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. (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.)

Field Value




Leave unchecked.

Use a dialup connection Leave unchecked.


Leave unchecked.




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.

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 Domino server setup:



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

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:





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



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

Resolve user list to show awareness statusOnce 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 complete the following sections to configure instant messaging in DWA:




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 complete the following sections to configure instant messaging in DWA:

� 6.7.2, “Synchronize the directories” on page 384




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

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

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

DWA distinguished name Sametime distinguished name

CN=Charlie Price/O=IBM uid=cprice,cn=users,dc=ibm,dc=com

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.


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 serversTo 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 seen in Figure 6-47.

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 docTo 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 worksOnce 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.

Figure 6-53 How awareness works in DWA

DWA Mail Server

Cprice.nsf ACLCharlie Price/ITSO

TDS LDAP Server

uid=cprice,cn=users,dc=itso,dc=comcn: Charlie Priceuid: cpricemail: [email protected]: CN=Charlie Price,O=itso

Sametime Server

Filter: notesDN=

CN=Charlie Price,O=ITSO

4

32

1

Return: uid=cprice,cn=users,

dc=itso,dc=com

Writestlinksapplet(uid=cprice,cn=users, dc=itso,dc=com;

<LTPAToken>);


Add LDAP DN to Domino person document

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


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.

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

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.

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


Add LDAP DN to LTPA user name fieldTo 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 worksOnce 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.

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:


DWA Mail Server

cprice.nsf ACLCharlie Price/ITSO

Domino Directory

UserName:Charlie Price/ITSOCharlie Priceuid=cprice/cn=users/dc=itso/dc=com

LTPA UsrNm:uid=cprice/cn=users/dc=itso/dc=com

Sametime ServerCharlie Price/ITSO

4

32

1

Return: uid=cprice,cn=users,

dc=itso,dc=com

Writestlinksapplet(uid=cprice,cn=users,

dc=itso,dc=com;<LTPAToken>);


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.

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

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.


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.

Figure 6-65 DWA Welcome page

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.


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


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.


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=comcn: John Berglandcn: John A. Berglanduid: jberglandnotesdn: John Bergland/Marketing/ITSO....

2nd John Bergland user:uid=jbergland2,cn=users,dc=itso,dc=com

Jennifer Wales Jennifer Wales/ITSO@ITSO

Andy Higgins Andy Higgins/ITSO@ITSO

Type Name passed

Abbreviated Canonical John Bergland/ITSO


Full LDAP canonical CN=John Bergland,O=ITSO

Common Name John Bergland

Who From field


cn: John Berglandcn: John B. Berglanduid: jbergland2notesdn: 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 formatsDecide 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.


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.

Type Name passed

Abbreviated canonical John Bergland/ITSO


Full LDAP canonical CN=John Bergland,O=ITSO

Common name John Bergland


Configure iNotes_WA_SametimeNameFormatTo 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=1011where 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 [email protected]) should be sent to Sametime:0 = No, do not send1 = 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

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.

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


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:

iNotes_WA_SametimeNameFormat=214

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

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.

Note: This should only need to be completed if Sametime authenticates against a non-Domino LDAP directory.


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=1ST_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.


http://www-10.lotus.com/ldd/notesua.nsf/find/quickplace

4. Configure Domino.5. Post Domino installation/configuration steps.6. Verification checkpoint - Domino server setup.

Register a serverTo 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.






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.



9. You may be prompted with a Certifier Recovery Information Warning dialog 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

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.

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 for the QuickPlace machine.

Pre-Domino Install ChecklistCheck the following:





Field Value

Server name qp

Server title (optional) QuickPlace server 2













� This server should have a static IP and host name that are resolvable via DNS.

Install DominoTo install Lotus Domino on a Windows platform:






4. Choose the program directory in which to copy the Lotus Domino software (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.











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





6. On the Provide the registered name of this additional Domino server screen, click Next.



Note: In previous steps, we stored the qp’s server ID on chat1’s local file system and not in the Domino directory. For this step within the setup 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.


8. Then, click Customize, and uncheck the following Domino server tasks:

– Calendar Connector– Schedule Manager

9. Click OK, then Next to continue (Figure 6-85).




b. For the TCP/IP Notes Port Driver, enter in the fully qualified host name for the Domino server in the Host Name (Editable) field (qp.cam.itso.ibm.com in our test environment).

c. In the text field on the bottom of the screen, enter in the same fully 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.




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 Domino Server setup process.


Post Domino installation/configuration stepsYou 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 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. (Ten minutes is generally longer than actually needed, but to be on the safe side, we recommended that the Domino server run for a full 10 minutes during this step.)

Field Value




Leave unchecked.

Use a dialup connection Leave unchecked.


Leave unchecked.




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.

Verification checkpoint - Domino server setupAt 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

b. In the command prompt window that appears, enter the following command (substitute qp.cam.itso.ibm.com for your fully qualified host name):

ping qp.cam.itso.ibm.com


ipconfig

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:


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.




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



4. From a Lotus Notes client, select the following from the menu bar: File → 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 seen in Figure 6-88.

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


http://www.lotus.com/ldd/notesua.nsf/find/quickplace

Changing the QuickPlace administration placeTo 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.


http://qp.cam.itso.ibm.com/quickplace

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

Figure 6-92 Saved user directory: OK with Anonymous access

6. Close the browser window.

Creating the qpconfig.xml fileYou 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.

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.


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.

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

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.


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

Testing the user directoryTo 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.

6.10.1 How instant messaging works in QuickPlace


1. Log user into Sametime from QuickPlace client2. Resolve user list to show awareness status

Log user into Sametime from QuickPlace clientThrough 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.

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.


Resolve user list to show awareness statusOnce 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, as shown in Figure 6-93.

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 QuickPlaceTo 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-onPerform 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).

Figure 6-101 QuickPlace SSO login page

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.


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 awarenessTo 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 QuickPlaceTo 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).


http://www.lotus.com/ldd/down.nsf

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 shown in Figure 6-105.

Figure 6-105 QuickPlace administration - Edit options

7. Click Next and then sign out of QuickPlace.

Testing online awarenessTo 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.

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.


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 meetingsTo 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,QPJC4QPJC1=C:\LOTUS\DOMINO\quickplace.jarQPJC2=C:\LOTUS\DOMINO\log4j-118compat.jarQPJC3=C:\LOTUS\DOMINO\STCore.jarQPJC4=C:\LOTUS\DOMINO\STMtgManagement.jar

Specify the Web Conferencing authentication nameTo 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>


4. Click Save and Close to save the XML file.

Specify Sametime Community server in Team WorkplaceTo 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.

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.



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



http://www-128.ibm.com/developerworks/websphere/zones/portal/proddoc.html#1

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

– Host name: wps.cam.itso.ibm.com in our test environment

Note: The cell and node name should be four characters or less.


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.


http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wpf/intr_ldap.html

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 recommended for most environments. 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 recommended for most environments. 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 onlyDefault value: falseExample: trueNote: 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



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=trueWPSconfig -DparentProperties="C:\ibm\WebSphere\PortalServer\config\helpers\sec

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.Example: cn=wpsadmins,cn=groups,dc=itso,dc=com

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.Example: cn=wpsadmins,cn=groups,dc=itso,dc=com

WcmAdminGroupIdShort The Web Content Management Administrators group ID.Example = wpsadmins



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

Resolve user list to show awareness statusOnce 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 keyTo 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

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

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


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 shown in Figure 6-120.

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.

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.

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.


You can now stop server1 with the following command:

C:\IBM\WebSphere\AppServer\bin\stopserver server1 -user wasadmin - password password

Import the key into DominoTo 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

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.

Important: The realm setting is case sensitive, so you must have WMMRealm. (wmmrealm will not work.)


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 SametimePerform 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 in our test environment).

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=trueCS_SERVER_SAMETIME_1.hostname=imcluster.cam.itso.ibm.comCS_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=httpCS_SERVER_SAMETIME_1.port=8082

## Optional advanced settings#


http://www-1.ibm.com/support/docview.wss?uid=21158269

# 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.AwarenessInitLwp

# 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

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

Note: This is the port used by Portal to connect to the Sametime server to get a user’s buddy list.


# 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


3. Restart WebSphere Portal for the changes to take effect.

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.


Test awareness in PortalAfter 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 shown in Figure 6-130.

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 portletEnsure 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 shown in Figure 6-137.

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 in our test environment).


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 shown in Figure 6-140.

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


– SametimePassword1: password of user set in SametimeUserName1 above.

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:


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.



7. Click OK to save the portlet settings. You should see a message indicating Successfully saved changes to portlet Lotus Web Conferencing, as shown in Figure 6-141.

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

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

Built in presence awareness


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 OFFREM *** Use this batch file to execute the Sametime Connect 7.5.1REM *** 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 processIn 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 TagsThe 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.


TroubleshootingIf 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 OutlookFigure 6-155 is the Outlook client with the toolbar showing presence awareness.

Figure 6-155 Awareness within Outlook

Built in presence awareness


Figure 6-156 shows a list of folders in Outlook after the install has been completed.

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

Saved Sametime Transcripts


Synchronization of contactsFigure 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 OutlookFigure 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



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


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 desktopsA number of things must be done to properly secure sessions with the Sametime Connect client. They are discussed in this section.

The client authentication processThe 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 passwordsThe 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 informationSametime 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 transfersFile 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 meetingsFor 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 listThe 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 ServerTDS 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



http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.IBMDS.doc/admin_gd.pdf


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.Sunsecurity.provider.2=com.ibm.spi.IBMCMSProvider security.provider.3=com.ibm.crypto.provider.IBMJCE


Create the self-signed server certificateThe 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 certificateTo 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 TDSTo 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 certificateIn 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 serversTo 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 fileCreate 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.kdbTo 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.jksPull 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.iniOpen 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.jksjavax.net.ssl.keyStorePassword=redb00kjavax.net.ssl.trustStore=stkeys.jksjavax.net.ssl.trustStorePassword=redb00k

Install the LDAP Internet cross certificateDirectory 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 ServicesTo 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 ServicesTo 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.

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.

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.


Install trusted root certificate into key fileTo 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, as shown in Figure 7-41.

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 shown in Figure 7-45.

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 certificateIn 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 file4. 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 GSKitRefer to “Install GSKit on the Sametime servers” on page 554.


Create the CMS key.kdb fileRefer 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 fileTo 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.jksTo 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 shown in Figure 7-58.

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 shown in Figure 7-60.

Figure 7-60 stkey.jks with CA’s trusted root certificate

Modify sametime.iniRefer 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 certificateTo do this:

1. Click Install Trusted Root Certificate into Key Ring and fill in the fields as shown in Figure 7-64.

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, as shown in Figure 7-66.

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 documentTo 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 servicesRefer to “Enable SSL to LDAP for Community Services” on page 562.

Enable SSL with trusted root in directory assistanceRefer to “Enable SSL to LDAP for Web Services” on page 563.

Setting up SSL for Sametime for Web ServicesTo 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 QuickPlaceWe 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


HTTP Services, Domino Services, LDAP Services, and Sametimeintraserver ports The following ports are used by the Sametime HTTP Services, Domino Application Services, and LDAP Services (Table 7-1).

Table 7-1 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.


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 HTTP port (8088)

If the administrator allows HTTP tunneling on port 80 during the Sametime installation (or afterward), the Domino HTTP server on 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 intraserver connections between Sametime components. This port cannot be used by other applications on the server.

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

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.

If the administrator does not allow HTTP tunneling on port 80 during the Sametime installation, the Community Services clients attempt HTTP-tunneled connections to the Community Services on port 1533 by default.

Port 80 If the administrator allows HTTP tunneling on port 80 during the 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.

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

Note that the term direct TCP/IP connection means that the Sametime client uses a unique Sametime protocol operating over TCP/IP to establish a connection with the Meeting Services.

If the administrator does not allow HTTP tunneling on port 80 during the Sametime installation, the Meeting Services clients attempt HTTP-tunneled connections to the Meeting Services on port 8081 by default.


Port 80 If the administrator allows HTTP tunneling on port 80 during the Sametime installation, the Meeting Room Client can make HTTP-tunneled connections to the Community Services multiplexer 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 accessible via the firewall to allow direct access from an external client to the Sametime server: 80 and 8081.



Recorded Meeting Broadcast Services portsThe 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”.)

If the administrator does not allow HTTP tunneling on port 80 during the Sametime installation, the Recorded Meeting clients attempt HTTP-tunneled connections to the Recorded Meeting Broadcast Services on port 554 by default.

Port 80 If the administrator allows HTTP tunneling on port 80 during the Sametime installation, the Recorded Meeting clients can make HTTP-tunneled connections to the Community Services multiplexer 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 ports

The Recorded Meeting Broadcast Services stream meeting data in 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 ports for multicast)

The Recorded Meeting Broadcast Services can take advantage of the bandwidth efficiency provided by multicast-enabled networks. If 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 portsThe default ports in Table 7-5 are used by the Audio/Video Services. These ports are configurable.

Table 7-5 Ports

For more information about ports used by the Sametime server services, see the Sametime 7.5.1 Administrators Guide:



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(Dynamic UDP port range)

The Sametime Audio/Video Services listen for inbound audio and video streams from Sametime Meeting Room Clients on a range of 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 accessible via the firewall to allow direct access from an external client to the Sametime server: 8081, 8084, and UDP 49252–65535.



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


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

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.


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.

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

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


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.

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

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.


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.

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.

Server ResponseClient Request


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.

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.

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.


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

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.

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

ReverseProxy


Internet

Browser

QuickPlace

Sametime

WebSpherePortal


Browser

QuickPlace

Sametime

WebSpherePortal

ReverseProxy

MUX

Internet


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


Figure 7-75 Overview of Sametime Infrastructure through a reverse proxy

Internet

STCLUSTER

Sametime 7.5Server

Sametime 7.5Server

Client

SametimeMUX1

SametimeMUX3

SametimeMUX2

LoadBalancer

15338082

15338082

15338082

13521516

15161516

Caching ProxyReverse Proxy

80

Firewall

Firewall

80443


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 shown in Figure 7-77.

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* :80Proxy /st03/CommunityCBR/CC.35* http://meeting2.cam.itso.ibm.com/CommunityCBR/CC.35* :80Proxy /st03/CommunityCBR/CC.39* http://meeting2.cam.itso.ibm.com/CommunityCBR/CC.39* :80Proxy /st03/sametime/* http://meeting2.cam.itso.ibm.com/sametime/* :80Proxy /st03/MeetingCBR* http://meeting2.cam.itso.ibm.com/MeetingCBR* :80Proxy /st03/BroadcastCBR* http://meeting2.cam.itso.ibm.com/BroadcastCBR* :80


Proxy /st03/stcenter.nsf* http://meeting2.cam.itso.ibm.com/stcenter.nsf* :80Proxy /st03/names.nsf* http://meeting2.cam.itso.ibm.com/names.nsf* :80Proxy /st03/* http://meeting2.cam.itso.ibm.com/* :80Proxy /st03/QuickPlace/* http://meeting2.cam.itso.ibm.com/QuickPlace/* :80

Redirect /st03/* http://rp.cam.itso.ibm.com/st03/* :80Redirect /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* :443Proxy /st03/CommunityCBR/CC.35* http://meeting2.cam.itso.ibm.com/CommunityCBR/CC.35* :443Proxy /st03/CommunityCBR/CC.39* http://meeting2.cam.itso.ibm.com/CommunityCBR/CC.39* :443Proxy /st03/sametime/* http://meeting2.cam.itso.ibm.com/sametime/* :443Proxy /st03/MeetingCBR* http://meeting2.cam.itso.ibm.com/MeetingCBR* :443Proxy /st03/BroadcastCBR* http://meeting2.cam.itso.ibm.com/BroadcastCBR* :443Proxy /st03/stcenter.nsf* http://meeting2.cam.itso.ibm.com/stcenter.nsf* :443Proxy /st03/names.nsf* http://meeting2.cam.itso.ibm.com/names.nsf* :443Proxy /st03/* http://meeting2.cam.itso.ibm.com/* :443Proxy /st03/QuickPlace/* http://meeting2.cam.itso.ibm.com/QuickPlace/* :443

Redirect /st03/* https://rp.cam.itso.ibm.com/st03/* :443Redirect /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*



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


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

� Sametime Gateway

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

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 enhancementsThe 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 sessionsSametime 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.

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.

Figure 8-4 Tabbed chat sessions

Note: Tabbed chat functionality was introduced with Sametime 7.5.1 and is not available in Sametime 7.5.



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 productWithin 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 enhancementsAdditional 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.

Figure 8-15 Primary contact list

Users within Primary Contacts


� 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).

Figure 8-16 Chat history transcripts

List of contacts for chat history

List of dates for 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).

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.

Multi-chatsections

Delete

Send as email

Search function



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 Sametime Connect client.

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.2In 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.

Figure 8-26 Prompt for transcript

Timestamp Option to 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


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.

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.

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.


In the next few pages we review some of the highlights

Sametime 7.5.1 Web conferencingBeginning 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

Figure 8-37 Enhancements to the meeting room user interface

Resizable Sections

Common actions on the toolbar Tabs for different

tools

Updated status bar


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.

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

Note: New to Sametime 7.5.1, the mobile client files are installed during the Sametime 7.5.1 Server installation.


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.

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:






Scenario - locked down desktops or limited user rightsIf 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 restrictionsIf 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

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.


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

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.

Note: At this time, if you re-run the install to correct any problems, the installer will automatically perform the options.


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

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

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.



Copy Sametime Connect clients to serverThere 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 optionsIn 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

� 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

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

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)


You can edit both of these files to tailor the installer to your specific requirements.

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

STPROXYPASSWORD= Proxy password (if used)

Tip: All of the connection-related settings are used to set values in the community-config.xml file.


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=Notescom.ibm.collaboration.realtime.update/adminUpdatePolicyURL=http://sametimeupdate.server.com/sametime75updates/site.xmlorg.eclipse.update.core/org.eclipse.update.core.historySize=120org.eclipse.update.core/org.eclipse.update.core.checkSignature=trueorg.eclipse.update.core/org.eclipse.update.core.updateVersions=compatibleorg.eclipse.update.core/updatePolicyURL=http://sametimeupdate.server.com/sametime75updates/site.xml#Automatically find updates onorg.eclipse.update.scheduler/enabled=true#download options automaticorg.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 usersworkstationsNow 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.

Option 3 - Sametime Java Connect for BrowsersBy 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 serversDownloading 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

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.



– 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 platformsExtract 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/javaconnectchmod -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.1server home pageNow 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 Sametime7.5.1 server managed by EMSIf 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.1servers managed by EMSComplete 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).

Figure 8-56 Java control panel for our user account

From Java Control panel select Settings

With the Temporary file Settings View applets

See the results of the Applets that are installed


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




http://www-142.ibm.com/software/sw-lotus/sametime


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


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.

Table 9-1 Monitoring charts available for Sametime

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.

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.


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.

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

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.

Monitoring tool Description

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.

Chapter 9. Systems management and maintenance 693

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

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.

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.


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:


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.

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.

Menu option Description

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


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


http://www-12.lotus.com/ldd/doc/domino_notes/7.0/help7_admin.nsf/Main?OpenFrameSet

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


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)

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.


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

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/

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.



http://www-1.ibm.com/support/docview.wss?uid=swg21234550

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.

Table 9-3 focuses mainly on Sametime-specific maintenance that should be done.

Table 9-3 Recommended maintenance activities

Important: Note that since Sametime depends on a Domino server, the maintenance activities recommended by the Domino product will apply as well.

Maintenance activity Frequency

We recommend backing up your entire Sametime server installation. This includes the entire program directory (that is, \lotus\domino) and the entire data directory (that is, \lotus\domino\data). This gives an administrator the opportunity to restore the server to the last known good state if the need arises. If a full backup is not possible, then at the very least the following files should be backed up:� notes.ini� sametime.ini� UserInfoConfig.xml� names.nsf� stconf.nsf� stconfig.nsf� stpolicy.nsf� stnamechange.nsf� vpuserinfo.nsf� stlinks.js� hostinfo.js

The frequency depends on how often changes are made to this environment.

Each time a configuration change is made, a backup should be made.

With regards to vpuserinfo.nsf, this database stores users’ buddy lists and changes daily. How often you back it up depends on your environment. If you have more than 1,000 employees, it may be beneficial to back up this database on a nightly schedule. Again, the frequency at which this database is backed up is highly dependant on your environment, and can be altered to match the needs of your environment.

Note that the same comments above apply to stconf.nsf (online meeting center).


Set space savers on the databases that will grow large over time like log.nsf and stlog.nsf. To enable space savers, see the document titled “Limiting the contents of a replica” in the Domino Administrator help guide. You will need to enable the “Remove documents not modified in the last x days” setting on the Space Savers panel.

We recommend setting the following purge interval for:

� log.nsf - 7 days� stlog.nsf - 30 days

Periodically, the sametime.log file should be archived or deleted.

Every 3–4 weeks this file should be deleted unless you are troubleshooting a specific issue.

Periodically, the contents of the trace directory (\lotus\domino\trace) should be purged.

The frequency of this is dependant on how much space you have available on your 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 scheduled database maintenance (compact and updall) on the following databases:� stconf.nsf� vpuserinfo.nsf� stlog.nsf

For an example on how to create a program document, see the help document titled “Setting a schedule for Updall in a Program document” in the Domino Administrator help guide.

The following commands should be run weekly via a program document while the server is up and running:

updall [database.nsf] -rcompact [database.nsf] -B

Note: In order for a copy-style compact to occur on these databases, they must not be opened by any user. Therefore, we recommend following these maintenance suggestions with the server shut down as well.



In the cases where the above databases 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] -Cnupdall [database.nsf] -r

This should be done every two weeks.

On Sametime meeting servers, enable the purge agent on stconf.nsf. For more details on how to enable the purge agent, see the help document titled “Maintaining the Sametime Meeting Center” in the Sametime Admin help guide.

We recommend setting the purge agent to purge every 30 days.



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


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.

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

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.


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.

Figure 10-1 Overview of EMS

What is EMS graphically?

Enterprise Meeting

Server

* **

Room

Server

1

Room

Server

2

Room

Server

N


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

Figure 10-2 EMS within the context of Meeting Room Servers and an IM Cluster

WebSphereApplication

ServerDB2

IBMHTTPServer

Sametime EMS

RoomServer

RoomServer

RoomServer

ChatServer

ChatServer


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.

Figure 10-3 Architectural example

Meeting Cluster

IM Cluster

LDAP

MUX

IP Sprayer

MUX

WAS ServerHTTP Server

Meeting Server

Meeting Server

IM Server

IM Server

DB


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

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,

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

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.


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.

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.

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

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

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

Note: Enterprise Meeting Server 7.5 no longer requires MQ components (WebSphere MQ 5.3) to be installed on the server.

Note: This is the recommended order in which these servers should be started, but they are not dependent on each other.


STAdminThe 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

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

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

EMS Deployment – Port Diagram

EMS

RS RS RS

DB2

LDAP

Servlet traffic is 2-way for status, scheduling, configuration info between EMS and RS’s

EMS Applications -port 9060/9043 handed to port 80 via IHS

DB2 traffic - port 50000

Can be encrypted via SSL (port 443)

LDAP traffic - port 389/636

Servlet traffic - port 80


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.

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

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.

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.

Important: The following installation was based, for the purposes of this book, on a Single Server Setup using WAS 6.0.2.9.


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 variablesYou 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 aliasTo 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 sourceTo 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 andWebSphere securityTo 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=groupOfUniqueNames)(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.

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


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 identitycom.ibm.SOAP.loginUserid=wpsdmincom.ibm.SOAP.loginPassword=password

Prerequisite - create the application serversTo 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 -templateName default}

4. Create the STCenter server:

$AdminTask createApplicationServer Node01 {-name STCenter -templateName default}

5. Save the configuration changes:

$AdminConfig save

6. Restart server1.

Prerequisite - enable UTF-8 supportTo 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.

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

Note: All application servers must be restarted for the change to take affect.


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.

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.


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.

Note: The file was saved in C:\IBM\WebSphere\AppServer\profiles\default.

Note: Make sure that there is a backslash before the :389 (for example, \:389).


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

To do this:

1. Open the DB2 Client Configuration Assistant (Start → > Programs → IBM DB2 → Client Configuration Assistant).

2. Select Add.

Attention: This step is only needed when using remote DB2 database.


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

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.

Note: The following steps will be used to deploy all three of the above-mentioned .ear files.


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

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 setupThese 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: 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.


Install Sametime room serverTo 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 EMSTo 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.

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.


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.

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.

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


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

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

Note: Depending on the environment you may need to use the Sametime/Domino Admin user name and password instead


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 serverLet 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 serverWhen 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 serverdown/unavailable to runningThis 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 activeThe 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.



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.

11

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 Gateway � 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.

Figure 11-1 Business architecture diagram

Sametime 7.5 Provisioning Application

AOL / Yahoo!

Request accessto AOL and/or Yahoo!

1

Sametime Customer(Sametime Gateway Administrator)

2 Submit provisioninginfo to public IM operator

3 Enablecustomer on network

4 Notify whenprovisioningcomplete

5 Send email withfinal instructions

Public IM Networks

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

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

SametimeServer

ST SIP Gateway

GoogleTalk

Gateway

User Locator plugin

ACL pluginPlugin

Manager

Core

Logger plugin

ManagementBean

External Sametime

Server

Admin UI/Script

Core

Configuration

VP Connector

SIP Connectors

XMPP Connector

SIP Connectors

SIP Connectors


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

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.

[email protected]

[email protected]

LotusSametimeCommunity

Server

Externalusers?

Lotus Sametime Gateway

VP

Connector

Core

Plugin

Plugin

Plugin

SIPXM

PP

LDAPServer

Enterprises & Public IM Providers

Sametime


TopologiesThe 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 Talkuser communitiesFigure 11-4 illustrates a topology for connecting to the AOL, Yahoo! Messenger, and Google Talk user communities.

Figure 11-4 Topology recommended for connecting to AOL, Yahoo! Messenger, and Google Talk user communities

DMZ

DBServer

LDAPServer

SametimeUsers

Internet

AIMUser

AOL

Yahoo!

Yahoo!Messenger

User

Google

Google TalkUser

SametimeCommunity

Server

Firewall FirewallSametimeGateway


Connect to other Lotus Sametime companiesWhen 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.

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.

DBServer

LDAPServer

SametimeUsers

SametimeCommunity

Server

FirewallSametimeGateway

DBServer

LDAPServer

SametimeUsers

SametimeCommunity

Server

SametimeGateway

Firewall

Company A Company B


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

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.


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

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:


Important: Each of the detailed steps for installation and configuration are discussed in the Sametime 7.5.1 Information Center, available at:





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

A


Installing Active Directory on Windows 2003Active 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, as shown in Figure A-9.

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 fileDirectory 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=comchangetype: Addobjectclass: inetOrgPersonobjectclass: userobjectclass: organizationalPersonobjectclass: topgivenname: Georgesn: Lambiecn: George LambiesamAccountName: glambieuserpassword: passwordjpegPhoto:< file:c:\photos\glambie.jpguserPrincipalName: [email protected]

dn: cn=Jennifer Wales,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=comchangetype: Addobjectclass: inetOrgPersonobjectclass: userobjectclass: organizationalPersonobjectclass: topgivenname: Jennifersn: Walescn: Jennifer WalessAMAccountName: jwalesuserpassword: passwordjpegPhoto:< file:c:\photos\jwales.jpguserPrincipalName: [email protected]

dn: cn=Andy Higgins,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=comchangetype: Addobjectclass: inetOrgPersonobjectclass: userobjectclass: organizationalPersonobjectclass: topgivenname: Andysn: Higginscn: Andy HigginssAMAccountName: ahigginsuserpassword: passwordjpegPhoto:< file:c:\photos\ahiggins.jpguserPrincipalName: [email protected]

dn: cn=John Bergland,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=comchangetype: Addobjectclass: inetOrgPersonobjectclass: userobjectclass: organizationalPersonobjectclass: topgivenname: Johnsn: Berglandcn: John BerglandsAMAccountName: jberglanduserpassword: passwordjpegPhoto:< file:c:\photos\jbergland.jpguserPrincipalName: [email protected]

dn: cn=Charles Price,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=comchangetype: Add


objectclass: inetOrgPersonobjectclass: userobjectclass: organizationalPersonobjectclass: topgivenname: Charlessn: Pricecn: Charles PricesAMAccountName: cpriceuserpassword: passwordjpegPhoto:< file:c:\photos\cprice.jpguserPrincipalName: [email protected]

dn: cn=Jim Puckett,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=comchangetype: Addobjectclass: inetOrgPersonobjectclass: userobjectclass: organizationalPersonobjectclass: topgivenname: Jimsn: Puckettcn: Jim PuckettsAMAccountName: jpuckettuserpassword: passwordjpegPhoto:< file:c:\photos\jpuckett.jpguserPrincipalName: [email protected]

dn: cn=Vineet Rohatgi,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=comchangetype: Addobjectclass: inetOrgPersonobjectclass: userobjectclass: organizationalPersonobjectclass: topgivenname: Vineetsn: Rohatgicn: Vineet RohatgisAMAccountName: vrohatgiuserpassword: passwordjpegPhoto:< file:c:\photos\vrohatgi.jpguserPrincipalName: [email protected]

dn: cn=Stephen Shepherd,CN=Users,DC=qp,DC=cam,DC=itso,DC=ibm,DC=comchangetype: Addobjectclass: inetOrgPersonobjectclass: userobjectclass: organizationalPersonobjectclass: topgivenname: Stephensn: shepherdcn: Stephen ShepherdsAMAccountName: sshepherduserpassword: passwordjpegPhoto:< file:c:\photos\sshepherd.jpguserPrincipalName: [email protected]

Configuring Microsoft Active Directory for SSL accessOnce 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.


http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.itame.doc/am60_install166.html

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 ConsoleAs 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 AuthorityUsing 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 shown in Figure A-23.

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 shown in Figure A-25.

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, as shown in Figure A-30.

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


http://support.microsoft.com/kb/321051/en-us

[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 = 12RequestType = PKCS10 KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication

;-----------------------------------------------


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 = 12RequestType = 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

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="[email protected], 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.


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 ServerTo 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 schemaThe 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-inTo 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.


http://msdn.microsoft.com/

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 attributesOpen 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 valuesValues 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=comchangetype: Modifyadd: notesconnotescon: CN=Stephen Shepherd/O=ITSO-add: notesdnnotesdn: CN=Stephen Shepherd,O=ITSO-add: mailfilemailfile: mail\SShepher.nsf-add: mailservermailserver: dwa.cam.itso.ibm.com-add: SametimeServerSametimeServer: 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


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

B


Native DominoSametime 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 DominoDomino 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.

Extending the schemaWhen using Native Domino, this is not necessary.

Domino LDAPSametime 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 LDAPTo 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:

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

Appendix B. Directory considerations for Domino LDAP 801

Setting up SSL for Domino LDAPOn 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.

Extending the schemaThis is not necessary.

Dual directoriesCustomers 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 directoryTo 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.useLTPAToken=trueCS_SERVER_SAMETIME_1.nameFormatForResolve=dnCS_SERVER_SAMETIME_1.dnNameSeparator=/

Dual directories with Domino LDAPSync 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.useLTPAToken=trueCS_SERVER_SAMETIME_1.nameFormatForResolve=dn


Adding photos for use with business cardsThe 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=itsochangetype: modifyadd: jpegPhotojpegPhoto:< 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


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.

C

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 deploymentThe 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 approachIBM 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 planThe 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

Table C-2 Project planning activities

Table C-3 Design/development

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.

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.

Design/development (associated with software extension effort)

� Perform design effort.� Perform development effort.� Perform test effort.


Table C-4 Execution

Table C-5 Closing

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.

Closing

� Perform project closure effort.� Document project lessons learned.� Release project resources.� Formally acknowledge project end.


Sample Sametime deployment project planThe 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


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.

D

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.

For detail on how to configure BIG-IP load balancing for Sametime, visit:

http://www.f5.com/solutions/deployment/sametime_bigip45_dg.html

ScalabilityOften 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

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.


http://www.f5.com/products/bigip/index.html

http://www.f5.com/solutions/deployment/sametime_bigip45_dg.html

intercepts the incoming requests and redirects them to the appropriate machine in the cluster, providing scalability, load balancing, and failover.

AvailabilityUsers 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).

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

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

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

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.


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

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

AdvisorsThe 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

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.

Figure D-1 Dispatcher components interaction

Note: We did not configure the metric server in our test environment.

HTTP Server 3

HTTP Server 1

WebClient

HTTP Server 2

dscontrol

Executor

lbadmin

Manager

Dispatcher

dsserveradvisorsadvisorsAdvisors

Metric ServerMetric ServerMetric Server

Metric Server

Metric Server


Forwarding methodsThere are three methods used by Executor to forward packets to the balanced servers:

� MAC forwarding

� Network Address Translation (NAT)/ Network Address Port Translation (NAPT)

� Content Based Routing (CBR), also referred to as Kernel CBR (KCBR) in previous versions

MAC forwardingThis 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).

Note: This is the method used in our test environment.


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.

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.

MAC Forwarding

Client

Load Balancer

Backend server

Incoming traffic

Incoming traffic

Outgoingtraffic




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.

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.

NAT Forwarding

Client

Load Balancer

Backend server

Incoming traffic

Incoming trafficOutgoingtraffic

Outgoingtraffic


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.

For more details, advantages, and disadvantages of each forwarding method, refer to the Load Balancer Administration Guide Version 6.0, GC31-6858:


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

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.




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

Class file names must follow the form ADV_name.class, where name is the name you choose for the advisor.

Important: For the Edge Components that are part of IBM WebSphere Application Server Network Deployment V6, you need Java compiler Version 1.4.2.


Using the Java SDK, the compile command is:

javac -classpath <install_path>/servers/lib/ibmlb.jar ADV_<name>.java

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/cde4d8ccbe98e4868525676e0079ad34/670748e0f41ae33485256d18005c9205?OpenDocument

Content Based Routing (CBR) ComponentThe 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.

Note: The load balancer base classes, found in ibmlb.jar, must be referenced in the classpath during compilation.



http://www-128.ibm.com/developerworks/lotus/library/ls-STChat_advisor/



When do you use which CBR methodFor 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 BalancerServer 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.


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 addressThis 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: 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.


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.

For implementation details, refer to “Configure the sticky bits” on page 276.

Cross port affinityCross 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.

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.

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.


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.

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 affinityPassive 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 affinityActive 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.

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.


The active cookie affinity feature applies only to the CBR component.

URI affinityURI 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 IDDuring 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 RedbooksFor 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 resourcesThese Web sites are also relevant as further information sources:

� Sametime 7.5.1 Information Center


� Sametime Product Page


How to get IBM RedbooksYou 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 IBMIBM Support and downloads

ibm.com/support

IBM Global Services

ibm.com/services


http://www.ibm.com/support/

http://www.ibm.com/support/

http://www.ibm.com/services/

http://www.ibm.com/services/

Index

AA case where users are concentrated in three re-gional locations 37About Lotus Sametime 7.5.1 3, 632access control list 62, 87, 740Access Control List to

ITSO’s Directory 163, 206, 319Sametime Configuration 165, 208, 321

ACL 62, 87, 740Active cookie affinity 834Active Directory 79, 84, 87, 716, 731, 751–752

Enterprise Admins group 790Add a Domino Canonical Name to LDAP Directory 355Add a new hardware device 229Add CA Certificate from a file 577Add CA’s Trusted root certificate to Sametime’s key.kdb 586Add CA’s Trusted root certificate to Sametime’s stkeys,.kdb 589Add directory assistance db to server doc 393Add Directory Assistance Document 389Add Domino DN to Tivoli Directory Server 386Add LDAP DN to Domino person document 397Add LDAP DN to LTPA user name field 400Add LDAP DN to user name field 397add LDAP DN to username field 399Add LDAP’s Domino Canonical Name field to re-solve filter 356Add New Hardware 228Add the trusted root certificate to key.kdb file. 585Add to Domino cluster 216Add trusted root certificate to stkeys.jks 588Added Console Server 105Adding a cluster 265Adding a port 268Adding a server 270Adding a suffix 107Adding Attribute SametimeServer 119Adding attribute values for NotesCon and NotesDN 126Adding Attribute values via LDAPModify 128Adding attributes to inetOrgPerson 121

© Copyright IBM Corp. 2007. All rights reserved.

Adding redundancy through 2 chat servers 44Adding redundancy to your Sametime infrastructure 42Adding Sametime Room Server to EMS 728Adding Server to Web Administration tool 103Adding Suffixes 109Adding the first balanced server 270Adding values to mailfile and mailserver attributes 127Administering and configuring the Directory Server 99Administrator ACL to ca.nsf 567Advanced Network Settings 146, 188, 301Advanced Settings 235Advanced TCP/IP Settings 248, 250Advisor

Connect 1533 274Advisors 823, 828all advisors started 276All Server Documents View 404, 454All server documents view 394America’s Chat Cluster scenario 259Another way to utilize the SA Mux 40AOL Instant Messenger

community 745Applet for the Sametime Meeting Room client 686Application Server v6 717, 720Architectural example 709Asia Pacific (AP) 17, 23–24attribute ibm-allmembers 113Attributes to be added to an LDAP Directory 116Audio Visual Capabilities 13Audio/Video Services ports 77, 608Authentication 60, 85Authentication Mechanisms -- LTPA 491Authorization 60, 85auto-mail detection 116Availability 821Available options in the logging tool 694awareness in DWA 412awareness in Inbox. 365awareness in People Finder 506awareness in QuickPlace 464Awareness within Outlook 529

839

BB2B Instant Messaging - Connecting directly to the other company's Lotus Sametime Gateway 47balanced server 822–823

load information 823weight values 823

balanced servers added to each port in cluster 271base DN 716, 719Best Practices for setting up the business card fea-ture 340Best Practices on HTTP Tunneling 615bin directory 100, 111Buddy List 539Business Architecture Diagram 741Business Card & Storage Configurations 337Business Card data retrieval test - UserInfo servlet 353Business Card integration in Connect client 334Business Card Request/Response Flow Diagram 336Business Cards 340business partner 1, 3, 46, 49, 812–813

CCA 565Cache location 688Caching Proxy Installation 623Capacity 30capacity planning 28, 39Capacity Planning within a community services clus-ter 44Case Fixes 331Catalog the Sametime DB2 database

724CBR component 828, 830, 832CBR method 831CBR See Content Based RoutingCertificate Authority 537, 540, 545, 564, 768, 771–772, 804

Click OK 752, 755Database 773Dialog box 771snap-in 773Web Application Click Request 784

certificate authority 565Certificate Authority Profile example 571Certificate Authority Web Application 575Certificate received into Key Ring as a Trusted Root

595Certifier Password 173, 286, 368, 423Certifier Recovery Information Warning 174, 287, 369, 424Change how names are passed to Sametime for awareness status. 413Changing the QuickPlace administration place 442Chat and awareness considerations with Reverse Proxies 618chat cluster 43–44, 116Chat history settings 648Chat history transcripts 647chat window 650Chat window extension points 651Checkpoint - Verify photo is available via LdapSearch 350Choose a Certifier 173, 286, 368, 423Choose your organization name 142Choosing the Data directory for Lotus Domino 136, 180, 293, 373, 428Choosing the Program directory for Lotus Domino 135, 179, 292, 372, 427Choosing which type of Directory to use 84Choosing which type of Directory to use. 59Cisco CSS Controller 821, 831Cisco CSS Controller and Nortel Alteon Controller 831Classifications of users - types and population within ITSO Corp. 24client connection 32

Broadcast Gateway Address 76Client Considerations 27Client Deployment phase II

Implementation 671Client Extensibility 13Client PC 28Client Requirements 67Client requirements 67Client Software Requirements for Meetings 68Cluster added 267Cluster Information 219Cluster Name 216Clustered Environments 698Common Name (CN) 62, 83, 766, 800, 805Community Client document 680Community Service

Capacity Planning 44deployment options 46direct TCP/IP connections 72


up-to-the-second information 692community service 2, 4, 7, 15, 29, 35, 43, 46, 692, 694, 707, 710, 734, 800

different Sametime server 16Server-to-server connections 8

Community Services 7community services cluster 43–44

maximum size 43Community Services multiplexer 15, 38, 44Community Services Multiplexer Requirements 68, 70Community Services Ports 72, 602Community Trusted IPS 508CommunityConnectivity 219Completing the Add Hardware Wizard 234Component Selection window 256Conceptual example - Same as having 4 functional servers 35Conclusion 689concurrent connection 3concurrent meeting

use 706user 33

Configuration DocumentDomino Web Access tab 409

Configuration of the IBM Edge Server Caching Proxy 627Configuration Settings

basics tab 407Configurations view 406Configure Business Card to Display Information 351Configure Directory Assistance on DWA server(s) 387Configure Domino 139, 183, 296, 376, 431Configure Domino Cluster 215Configure DWA for awareness and chat 383Configure DWA server document for awareness and chat 406Configure Edge Network Dispatcher 259Configure iNotes_WA_SametimeNameFormat 416Configure key file to be used by TDS 552Configure LDAP for notes formats 415Configure Loopback Adapter 236Configure loopback adapter for cluster ipaddress 234Configure Lotus Web Conferencing portlet 515Configure MS integration with Sametime 529Configure network to work with Edge Network Dis-

patcher Component 225Configure NIC on load balancer to accept traffic for imcluster 242Configure NIC on mux servers to accept traffic for imcluster 226Configure Notes Client to pass full canonical name format 358Configure QuickPlace for awareness and chat 460Configure QuickPlace for awareness, chat and meetings 447Configure QuickPlace for online meetings 464Configure QuickPlace Security 440Configure Sametime 155, 198, 311Configure Sametime to trust Portal for the Sametime Contact List Portlet 506Configure SSO between DWA and Sametime 401Configure SSO between Portal and Sametime 489Configure SSO between QuickPlace and Sametime 451Configure Stand-Alone MUX server 223Configure the Manager component 272Configure the sticky bits 276Configure the Web Conferencing Portlet 512Configure WebSphere Portal for awareness, chat and meetings 485Configuring invitation process 36Configuring Sametime Administrative policies 667Configuring the Domino certificate authority 565Configuring the interface 266Confirmation and location of Stash password. 547Confirmation of the connection 665Connect to Host... 262Connect to other Lotus Sametime companies 748Connect to the AOL®, Yahoo! Messenger™ and Google Talk™user communities 747contact list 650Content Based Routing 830Content Based Routing (CBR) 828Content Based Routing (CBR) Component 830content-based routing 830–831Contents of directory 673continuous access 16, 43Copying Java files required for chat and online awareness 460Copying Sametime Connect clients to server 672Copying the Java files required for online meetings 464Create a Domino cluster 215Create a Sametime cluster 218

Index 841

Create CA key ring file 569Create CA Server key ring example 573Create Directory Server instance 95Create Directory server instance task completion 98Create Key Ring 592Create New Database 387Create new JKS file 558create new meeting 468Create New Self Signed Certificate 549Create stkeys.jks file 557Create the CMS key.kdb file 555, 585Create the Domino keyfile 591Create the Sametime cluster 218Create the WebSphere LTPA key 489Creating a database for Sametime EMS on DB2

724Creating Domino SSO key 161, 204, 317Creating Domino Web Server Configuration data-base 456Creating new Domino web SSO keys. 203, 316Creating the qpconfig.xml file 444Creating the self-signed Server Certificate 545Cross port affinity 833CSEnvironment.prop erties 806–807Custom advisors 829

DDatabase location and Character set option, 97DB2 Administrator 92, 97DB2 Administrator’s username and password 97DB2® Administrator and password 92Default Domino homepage 148, 191, 304, 381, 437default port 70–72, 74Default Security of Sametime communication and saved information

539Delete field jpegPhoto from $PersonInheritable-Schema 809Deploy Clustered Chat Servers 133Deploy ITSO’s Meeting infrastructure 284Deploy stand-alone MUX servers 220Deploying Sametime 7.0 Connect for Browsers on a Sametime7.5.1 server managed by EMS 683Deploying the StAdmin, STServer, and STCenter (.ear) files

725Deployment Option

SA Mux in Remote Locations 40Separated Community Multiplexing 38

deployment option 22, 25, 28, 30, 38, 43, 64high level overview 46

Deployment Option - Dedicated Sametime Servers 33Deployment Option - Multiple Sametime Servers 33Deployment Option - Sametime in the Extranet 46Deployment Option - Single Sametime Server 29Deployment Options 28Deployment Options for High Availability 40Deployment Phase 1 - Implementing Community Services 129Deployment Phase I - Implementing Meeting Servic-es 281Deployment Phase II -Integration with other Prod-ucts 329Deployment Phase III - Securing the environment 537Deployment Phase1

Planning 668Determining different classes of users 23Differences Between Sametime and EMS 704direct TCP/IP connection 8, 12, 72

call control information 74Directory Assistance - LDAP 165, 209, 322Directory Assistance Basic tab 390Directory Assistance LDAP tab 393Directory Assistance Naming Contexts (Rules) tab 391Directory Assistant LDAP Settings 564Directory Components 61, 83Directory Concepts 81Directory Consideration 59, 83Directory Considerations 59Directory Considerations specific to Sametime 7.5 83Directory Information Tree 61, 83, 106Directory Information Tree (DIT) 106, 123Directory location for installation 672Directory Management -> Manage entries 343Directory Name 221Directory Server 79, 711, 763, 784Directory Server Administration Tool 101Directory Server instance - Results 99-Directory Server successfully added to Web Admin-istration tool 104Directory Server Web Administration Tool 100, 118Directory Type used by Sametime options 417


Dispatcher 822Advisors 823, 828

Connect 828connecttimeout 829Custom 829Downed server 829receivetimeout 829

Executor 823Connection table 823Forwarding methods 825

CBR 828MAC forwarding 825NAT/NAPT 826

Return address 827Manager 823Metric Server 824Server weights 822

Dynamic 822Fixed 822

Dispatcher components interaction 824Dispatcher’s internal components 822distinguished name 61, 83Distinguished Name (DN) 83, 96, 805–806Distributing the plugin_customizations.ini file out to users’workstations 678DMZ 48–49, 745, 748DNS config for Chat Cluster address 226DNS name 74, 76, 116, 831Domain Controller 752, 754

fully qualified DNS name 754Netbios name 754

Domino Administrator 695client 695, 697help guide 701

Domino Certificate Authority application 568Domino Directory

template pubnames.nsf 810template pubnames.ntf 810

Domino LDAP 60–61, 79, 84, 799–800Domino Organization setup 141Domino Server Setup 134Domino Server Tasks 565Domino server type

Enterprise Server 137, 181, 294, 374, 429Domino Setup 172, 284Domino Web Access (DWA) 19, 27, 125Domino Web Access Integration with Sametime 365Downloading the client from the server 673

dscontrol 260dsserver

Start Dispatcher 260DWA Preferences 411DWA user person document 385DWA user settings to enable awareness and chat 409DWA Welcome page 410

Ee.g. password 730Edge Components 819–820Edit attributes 346Edit attributes for an inetOrgPerson Object 124Edit objectclass

InetOrgPerson 121Edit Office Location Document 361E-mail Address 82, 783Emoticon pallet 641EMS and clustering 711EMS and Instant Meetings 712EMS application 707, 709EMS Deployment 715EMS Deployment - Port Diagram 715EMS Meeting Services 712EMS within the context of Meeting Room servers and an IM Cluster 708en0 266en1 266Enable Awareness and Chat in WebSphere Portal 499Enable awareness in Notes Client. 360Enable MSSSO in server document 405, 455Enable Security with Realm Support 478Enabling SSL to LDAP for Community Services 562Enabling SSL to LDAP for Web Services 563Enabling SSL to LDAP with trusted root for commu-nity services 598Enabling SSL with trusted root in Directory Assis-tance. 598Enabling the Connect for Browsers link on Same-time 7.5.1servers managed by EMS 684Enabling the Connect for Browsers link on the Sametime 7.5.1server home page 680end user 28–29, 53–54, 86

Canonical name 61collaborative activities 29

Index 843

Enhancements to the Meeting room user interface 666Enhancements with Rich text capabilities 640Enter Import File Name 495Enter key file database path and file name 584Enter label for CA’s Trusted Root Certificate 586Enter password from the exported certificate 551Enter password of the exported certificate JKCS file 556Enter your instant messaging user name and pass-word 364Entering the SametimeServer attribute value. 125Enterprise Meeting Server 703Enterprise Meeting Server (EMS) 2, 16, 32, 703–704enterprise-scale deployment 1

practice framework 1Example - deploying a full Sametime Server in AP 34Example - servers to be dedicated to chat or meet-ing servers 33Example Business Card 334Example Meeting Room Client (MRC) 610Example of a highly redundant architecture 45Example of an account created with only user ac-cess rights on the local machine 686Example of Smart tag integration based on name "Miles Montgomery" in a word document 523Example of the Sametime toolbar in Outlook 2003 521Executor 823Executor started 264Expand containers 344–345Expanding a Community Services Cluster with the SA Mux 44Export PKSCS12 key 551Exporting the certificate 550Extend TDS Schema 386Extendable Applications Platform 12Extending the LDAP Schema 115Extending the Schema to add MailFile and MailServer attributes 126Extending the schema to add NotesDN and NotesCon. 125Extending the schema to add SametimeServer at-tribute 116Extension Point 650–651external community 50–51, 53–54, 741external contact 46–47, 813

instant messaging 48instant messaging connectivity 813on-line meeting 51, 54

external directory 48, 50entirely separate user record 48

Extracting the downloaded zip file to a directory on your server 679

FFailover in Community Services clusters 43fictitious company

ITSO Corp 22ITSO Corporation 23

Field - $PersonExtendableSchema subform with jpegPhoto field. 809File Transfers 539Filling in the information to add a cluster 265first server 734, 822

response time 822For All Sametime 7.5.1 Servers

678For all server platforms 679For which environments is EMS appropriate 705Forwarding method 825–826, 828, 833Forwarding methods 825Fully qualified hostname for Sametime server 222

GGB minimum 65–66, 69–70Generate and propogate the webserver plugin

727Global Architecture 56–57Google Talk 740–741

user 745graphical user interface (GUI) 789Group considerations 62, 86GSKit 7 Welcome Screen 542GSkit 7.0 Installation Directory 542GSKit Installation complete 543

HHardware and Software Requirements for EMS 712Hardware Server specifications to support Chat or Meeting services 64High Availability Deployment Option - Community Services Clustering 43


Home Server Assignment 61, 86home URL 705How awareness works in DWA 396, 401How does it work. 400How does Sametime use the Directory? 60, 85How does the Business Card feature work? 335How EMS addresses these issues 710How EMS handles failover 710How instant messaging works in DWA 383How instant messaging works in QuickPlace 448How instant messaging works in WebSphere Portal 486How instant messaging works using a Notes Client. 353How is works 745How it Works 745How online meetings work in QuickPlace 450How online meetings work in WebSphere Portal 488How this works. 396HTTP connection 71HTTP Services, Domino Services, LDAP Services, and Sametimeintraserver ports 71, 600HTTP Tunneling 609HTTP tunneling 71–72, 716, 734HTTP Tunneling - Hybrid Polling 614HTTP Tunneling & SSL 616HTTP Tunneling at Work - Meeting Room Client ex-ample 610HTTP Tunneling Tweaks 617HTTPS connection 71–72HTTP-tunneled connection 72, 74

UDP data 77

IIBM HTTP

Server 704, 707IBM HTTP Server 6.0 717IBM Keyman 545IBM Lotus Sametime 632, 636, 649

7.5 3Gateway 742server 693

IBM Redbook 1IBM Tivoli Directory Server

instance task 100Web Administration 118

IBM WebSphere

Application Server 717IBM Workplace

Collaboration Service 635illustrates a more (IM) 704, 706Illustrating the tabbed chat feature in Sametime 7.5.1 6, 634Immediate or Via Administration Process 217Import binary data - Browse 348Import binary data - File uploaded 349Import binary data - Submit file 349Import TDS - Self-signed certificate into Sametime’s key.kdb. 556Import the certificate into CMS - key.kdb 556Import the certificate into JKS - stkeys.jks 558Import the key into Domino 493Import user photo into the TDS LDAP directory. 342Import WebSphere LTPA Keys 494Inbox with awareness 413inetOrgPerson 110, 120, 331, 445, 719, 732, 763–764inetOrgPerson object 122inetOrgPerson objectclass 127, 763–764inf file 781, 783Initiate a chat from an open message 654Initiating a chat from within the InBox view 653iNotes_WA_SametimeNameFormat defaults 417Install and Configure IBM Edge Load Balancer Components 224Install Destination Location 438Install Domino 134, 178, 291, 366, 371, 426Install Domino and register the DWA users 366Install Domino for QuickPlace 421Install Edge Network Dispatcher 253Install Location

475Install Loopback Adapter 227, 233Install MS integration with Sametime 523Install process 524Install QuickPlace 438Install QuickPlace and configure Security 421Install Sametime 150, 193, 306Install Stand-Alone MUX server 221Install Summary 223Install the Certificate Authority’s Trusted root certifi-cate 594Install the hardware that I manually select from a list 230Install the LDAP Internet Cross Certificate 558Install Trusted root 594

Index 845

Install trusted root certificate into key file 575Install WebSphere Portal and configure Security 474Install WebSphere Portal v6 474Install/Configure the first chat server 133Install/Configure the second chat server 172Installation Complete 139, 183, 296, 376, 431Installation confirmation window 258Installation dialog 670Installation was successful. 478Installing and configuring EMS 716Installing GSKit 584Installing GSKit on the Sametime Servers 554Installing GSKit on Tivoli Director Server 574Installing GSKit on Tivoli Directory Server 541Installing Sametime Room Server

728Instant Meeting 29, 39, 712, 813

specific number 712unlimited number 712

Instant Meetings 539Instant Message (IM) 3, 26, 746, 813Instant Messaging (B2C) – Individual External Con-tacts. AOL Instant Messenger, Yahoo!, or Google-Talk 47Instructions for installing the client 674Integrated awareness with Notes Client 657Integrated Sametime within the Notes Client 651Internal and External Meeting Servers using Invited Meeting Server Model and Separate Directories 52internal user 48, 749Internet Cross Certificate in Primary Address Book 562Internet Cross Certificate Trust for Service 561Internet Protocal (TCP/IP) Properties 239Internet Protocol (TCP/IP) Properties 245, 247, 251intraserver connection 71, 75Introduction to Enterprise Meeting Server (EMS) 704Introduction to the Enterprise Deployment Scenario 16Introduction to the IBM Edge Server Caching Proxy 620IP address 76, 730, 823, 825IP spraying 16, 820, 822ipconfig 242ipconfig /all 238Isolated External Sametime Meeting Environment 50

Isolated External Sametime Meeting Environment and using Reverse Proxy Access 53Issue - I can log into EMS, but I can't join a meeting 733Issue - I can't log into the EMS server 731Issue 3 - I can't add a Room Server. 734Issue 4 - My Room Servers won't change status from "ServerDown/Unavailable" to "Running". 735Issue 5 - Meetings won't go active 736ITSO Corporation 16–17, 21, 56–57

architectural overview diagram 56fictitious scenario 21

ITSO Corporation Geographic Regions 17ITSO’s Sametime Community Infrastructure 130, 283

JJava Control panel for our User Account 687Java Message Service (JMS) 704, 711Java Virtual Machine

page 721Java Virtual Machine (JVM) 721jpegPhoto - Binary data 347jpegPhoto field - Binary data 350

KKey Concepts

Scalability, Performance and High Availability. 14

Key File with Self Signed Certificate. 550Key file with Server Certificate 583Key Ring Created 593Key ring created confirmation Screen 570Key Ring File password import 594key.kdb file with signer certificates 577key.kdb with CA’s Trusted Root Certificate 587Key.kdb with the imported certificate 557

LLabel for Trusted Root Certificate added to stkeys.kdb 589Launch - Administration 513Launch - Domino Integration 510LaunchPad window 254LB Network Configuration 226lbadmin 260LDAP browser 731–732


LDAP Connectivity 563LDAP Directory - Authentication 169, 212, 325LDAP Directory - Basics 168, 211, 324LDAP Directory - Connectivity settings 167, 210, 323LDAP Directory - Group Contents 169, 213, 325LDAP Directory - Searching 169, 212, 325LDAP Directory settings 150, 193, 307LDAP document 734, 807LDAP host

name 731LDAP Import File (LDIF) 110, 763, 810LDAP Realm - corrected to WMMRealm 497LDAP Realm set to null 496LDAP server 59, 71, 84, 114, 704, 713, 716, 800LDAP Server Document in STConfig.nsf 117LDAP User Directory - foundation for Sametime 79ldapsearch test 351LDIF file 110–111, 763, 798, 810Load Balancer 19–20, 43, 819–820

Advisors 273Connect 273HTTP 273

base class 830CBR component 830Cisco CSS Controller 831Command line interface

dscontrol 260component 824Configuration

Add cluster 264Add Web servers 270Basic scenario 260Executor 263Port 268

configuration 832Content Based Routing 830Custom advisors 829Dispatcher 822

CBR forwarding method 830Start 260

ExecutorStart 263

Graphical user interfacelbadmin 260

Installation 254installation path 829Installation wizard 254LaunchPad 254

ManagerLog 272Start 272

Nortel Alteon Controller 831Protocols 822Server affinity 831

Active cookie affinity 834Cross port affinity 833Passive cookie affinity 834SSL session ID 835Stickyness to source IP address 832URI affinity 835

Site Selector 831Site Selector components 833

Load Balancer overview 821Load Balancer Window 261load balancing 2, 15, 41, 43, 704, 706, 819–820

back-end server 824Load balancing in Community Services clusters 43Load Balancing, Server Clustering and Failover 15Local Area Connection - Properties 246Local Area Connection Properties 243, 246, 252local area network (LAN) 81LocalDomainAdmins ACL access to names.nsf 162, 205, 318LocalDomainAdmins ACL access to stconfig.nsf 164, 208, 320Location Document - Instant Messaging tab 363Location document - Server tab 362Log in user from client 354Log On To Instant Messaging 364Log user into Sametime from DWA client 383Log user into Sametime from QuickPlace client 448Log user into Sametime from WebSphere Portal 486Loopback Adapter properties 237Lotus QuickPlace 59–60, 84Lotus Sametime 1–2, 46, 48, 649, 807

7.5 3–47.5.1 13, 16company 746, 748Enterprise Meeting Server 743Gateway 47, 740, 742Gateway 7.5.1 749Gateway policy 743Gateway server 749own internal deployment 3Service 14software 3

Index 847

Lotus Sametime 7.5 and Microsoft Office integration 521Lotus Sametime 7.5.1 in the Enterprise 1Lotus Sametime Connect client extension points 650Lotus Sametime Services 6Lotus Sametime software

History and Market Leadership 3LTPA 719–720, 806LTPA Configuration page 492LTPA User name field 400

MMAC forwarding 825MAC forwarding - Network flow 826Mac OS X

version 10.4 635Manage binary data 350Manage binary data - Import 348Manage Console Servers 102Manage Object classes 120Manage security properties 552Manage Server Properties 108Manage user entries 123Manager 823Manager options 272MB minimum 66, 70Meeting Created in Calendar 472Meeting Detail 473Meeting Details 520Meeting options available in this version of Notes IM 655Meeting Room Client (MRC) 26, 28, 694, 734meeting Service 2, 4, 29, 46, 85, 692, 694, 704, 735, 800meeting service

load distribution solutions 704Meeting Services 9Meeting Services Ports 74, 604Meetings in Outlook 533Members view with awareness 449Menu options for Sametime functions 660Merge Trusted Root Certificate Confirmation 595Metric Server 823–824Modify Sametime.ini 558, 590Modify Server Document 596Monitoring Charts available for Sametime 692Monitoring Sametime 692

MS Outlook 529multiple Sametime server 12, 16, 33, 48, 710multiple server 8, 15, 33, 723

user load 15My Team page 518

Nnames sent to STLinks for awareness 413NAT forwarding - Network flow 827Native Domino 48, 60, 85, 799–800native Domino

LDAP Directory Server 60Navigating this chapter 331, 538nested group 86, 112

Sample LDIF 112Nested groups in a schema 112Network Adapters 231Network Address

Port Translation 826Translation 749, 826

Network Address Translation (NAT)/ Network Ad-dress Port Translation (NAPT) 826Network Connections 243network design 33, 67network DMZ 745, 748

Lotus Sametime Gateway 748–749Network interface 266Network topology 26Network Topology considerations 25New Certificate Authority database 566New Certificate Request 579New Cluster Name 217New Directory Assistance database 388New Directory Server instance 94New features in Sametime 7.5 and Sametime 7.5.1 632New key file name and location 546New Meeting page details 470New UI for the Sametime Web Conferencing Wel-come page 663NFA 823Non-forwarding address 823non-forwarding address (NFA) 823Nortel Alteon Controller 821, 831Notes 8 Instant Messaging 658Notes Client - User Preferences... 359Notes Client Integration with Sametime 353Notes IM 7.0.2 652


Notes Integrated Messaging available in Notes 7.0.2 652Notes User Security 559N-way chat with the chat sessions presented in a tabbed chat format 639

OObject Class 83, 112–113, 794OK to complete the import process. 350Online Meeting 469on-line meeting 2, 24, 48, 812–813

average daily number 3Online meeting details in Portal 488Online meeting details in QuickPlace 450Online meeting scheduling interface 534On-line Meetings and Instant Messaging – Same-time Server(s) in the DMZ 49Open Sametime Configuration Database 164, 207, 320Open STConfig.nsf on the Sametime server 680Open the Domino Directory 156, 199, 312operating system

IP alias 826operating system (OS) 59, 64, 69, 691, 823Option 1

Isolated External Sametime Meeting Environ-ment 50

Option 1 - Sametime 7.5.1 Connect Client -Server download option 671Option 2

Separate External Sametime Meeting Environ-ment in theDMZ with Selective Directory Repli-cation 51

Option 2 - Silent Install and Assisted Install options 674Option 3

Internal and External Meeting Servers using In-vitedMeeting Server Model and Separate Direc-tories 52

Option 3 - Sametime Java Connect for Browsers 678Option 4

Isolated External Sametime Meeting Environ-ment andusing Reverse Proxy Access 53

Option 5Separate External Sametime Meeting Server withSelective Directory Replication and using Reverse Proxy Access 54

Option 6Separate External Sametime Meeting Server us-ing InvitedMeeting Server Model with Separate Directories and using Reverse Proxy Access 55

Option for chat transcripts and time stamps 656Optional attributes 347organizational unit (OU) 61, 83, 783organizationalPerson 110, 168–169, 324–325, 331, 357, 763–764organizationalPerson objectclass 763–764Other functional enhancements 645other Lotus Sametime companies 746, 748Outlook tools options 532Overall Corporate Sametime Global Architecture for ITSO Corporation 132Overview of Basic Sametime Security. 538Overview of Domino Server Stats 697Overview of EMS 707Overview of Global Architecture proposed for ITSO Corporation 57Overview of Sametime Gateway Architecture 742–743Overview of Sametime Infrastructure through a Re-verse Proxy 622Overview of the approach for deployment 18Overview of the deployment approach taken throughout this Redbook 18Overview of the features in the Sametime 7.5.1 Con-nect Client 636Overview of the Global Architecture proposed for ITSO Corporation 56Overview of the key steps involved in setting up SSL for Sametime 540Overview of the Sametime Gateway 740Overview of the Steps involved for Installation 749Overview of the steps within the basic load balanc-ing scenario 225

PPassive cookie affinity 834password 60, 85, 92, 141–142, 285, 288, 331, 351, 538, 546, 676, 694, 718–719, 760, 810password jpegPhoto 763–764People Palette 504Performance 821Person View 398Personal Certificate Requests 582Personal Certificates. 548

Index 849

Perspective - how this component fits into the overall enterprise Infrastructure 132Pick Up Signed Certificates 580Planning a Sametime 7.5.1 Deployment 21Platform Statistics 696, 698Plug-in integration points 649Plug-in integration points and extensibility for the Sametime 7.5.x Connect Client 649plugin_customization.ini 676plugin_customization.ini file configuration 676Plug-ins 10Populating the Directory Server using an LDIF file. 110Population Topology 22Port Diagram for EMS Deployment 715Port information 268Portal is ready to install 477Portlet Management - Portlets 514Ports 1533 and 8082 added 269Ports used by Sametime through Firewalls 599Ports used by the Sametime Server 70Possible configuration names to pass 355, 414–415Post Domino Installation / Configuration Steps 146, 189, 302, 379, 435Pre-Domino Install Checklist 134, 177, 290, 370, 425Prerequisite - Define JAAS Alias

718Prerequisite - Define WebSphere Variables

717Prerequisite - Enabling LDAP Directory Access and-WebSphere Security

719Prerequisite - Enabling UTF-8 support

721Prerequisite - Installing Domino on the first Room Server

722Prerequisite - Setup Resources and Create Data Source

718Prerequisite- Creating the Application Servers

721Prerequisites

717Pre-Sametime Install Checklist 149, 192, 305Pre-Sametime Installation Steps 149, 192, 305Preview of integrated Instant Messaging in upcom-

ing Notes 8 client 659Primary Clients for Sametime 7.5.1 27Primary contact list 646Process of building the community infrastructure. 131Prompt for transcript 656Protecting Sametime with Reverse Proxies 618Provide a server name and title 141Provide Sametime server hostname 361Providing the Domino server name & description 140

QQuickPlace administration

Other options 467QuickPlace administration - Edit options 463QuickPlace administration - Other Options 462QuickPlace administration - Server Settings 461QuickPlace administration place 442QuickPlace Integration with Sametime 421QuickPlace Server Configuration 439QuickPlace SSO login screen 458

Rreal-time collaboration 1, 4, 740Real-Time Collaboration (RTC) 632real-time communication 1, 7, 46Real-Time Streaming Protocol (RTSP) 76–77Receive Certificate from a file 583Recommended deployment 748Recommended installation configurations 745Recommended maintenance activities 700Recommended Maintenance Activities for Same-time Environments 700Record and Playback (RAP) 12Recorded Meeting Broadcast Services ports 76, 606Recorded Meeting Client 688Redbooks Web site 837

Contact us xviiiReferring to the Sametime Information Center for In-stallation and Configuration 750regedit 241Register 2nd chat server 172Register a server 422Register Domino server 172, 285, 367, 422Register meeting server 284Register New Server(s) - Add to registration queue


176, 289Register New Server(s) - Register 177, 290Register New Servers 175, 288, 370, 425Register Servers 174, 287, 369, 424Register the server 367Register users in Domino 382Relative distinguished name 61, 83Remote Location 40Request Successful 217Resolve user list to show awareness status 354, 383, 449, 487Restart the Sametime Server 682Retrieve Internet Service Certificate 560Reverse Proxy

Access 53–54Access Description 50–51

Reverse proxy (IP forwarding) 620Reverse Proxy Access 53Reverse Proxy and Mux 619Rich text formatting 640Room Server 704, 711

administrative management 706concurrent Instant Meetings 712configuration data 704log files 731Services panel 729

Room Server Setup 727

Routing tableWindows 227, 240

SSA Mux 38–40

Community Services Cluster 44front-end Sametime 40

SA mux reduces the overall load on the Sametime server 38same server 831–832same time 28, 749Sametime 7.5 ii, 1, 21, 26, 83, 751, 811

Administration guide 695connection 32deployment 815, 817distinguishing features 4end user 29highlight 5Project Plan 814Upgrade effort 814

Upgrade project 814upgrade project plan template 814user 32

Sametime 7.5 highlights 5, 633Sametime 7.5.1 ii, 1, 3–4, 27, 742, 750

Administrators Guide 78Deployment 16full version 27Gateway 742Information Center 750look 714Primary Clients 27server 73subsequent Release 4tabbed chat feature 6testing 59, 84

Sametime 7.5.1 Client options 635Sametime 7.5.1 Connect Client 635Sametime 7.5.1 highlights 5, 634Sametime 7.5.1 provides a page with useful infor-mation about what is happening 665Sametime 7.5.1 Web conferencing 663Sametime Administration Tool 78, 692–693

Audio/Video Services settings 695Domino Log 693Monitoring menu 692Overview link 692Sametime log 693text file log 693

Sametime and Firewalls 599Sametime Client Deployment Considerations 631, 668Sametime Cluster Information Document, 122Sametime Deployment 5, 19, 21–22, 43, 811–812

Business Case 812project 817

Sametime deploymentvarious options 56

Sametime EMS Installation 724Sametime Gateway 739Sametime in the Extranet - Community Services 46Sametime in the Extranet - Meeting Services 49Sametime integrated functionality directly within the mail message 661Sametime Java Connect for Browsers link exposed 683Sametime Logging 693Sametime Meeting Center - Scheduled Meetings 9Sametime Meeting Room 11

Index 851

Sametime Meeting Room clientinteractive audio/video components 11public chat components 8video components 74, 77video streams 78

Sametime Meeting Room Client (MRC) 684–685Sametime Meeting Room Client, Sametime Record-ed Meeting Client 662, 684Sametime Mobile 667Sametime Monitoring Charts 692Sametime Server 8, 12, 25, 27–28, 33, 38, 70, 78, 86, 116, 691–692, 704, 733, 740, 748, 800, 805, 821, 832

Open stconfig.nsf 806requirement 64Services 29

Sametime serverAdditional information 695anothor important peice 834backward release 13Community Services 38Community Services multiplexer 71Event Server port 71individual capacity 39IP address 77main difference 735Meeting Services 75overall load 38required number 49schedules meetings 713server document 735Token Server port 72

Sametime server document - Basics 157, 200, 313Sametime Server requirements 64Sametime Server Setup 149Sametime service 4, 6, 22, 35, 84, 692, 729, 813Sametime Setup 191, 305Sametime stcenter.nsf 459, 498Sametime System Requirements - Minimum re-quirements and recommendations 63Sametime’s Server key.kdb file. 585Sametime’s Server STKeys.jkx 588Sample plugin_customization.ini 677Sample Reverse Proxy config 619Save changes 681Save Meeting to 471Save the configuration 277Saved passwords 539Saved user directory

OK with Anonymous access 444Scalability 14, 820Scalability with Sametime Multiplexors 15Scenario - Locked Down Desktops or Limited User Rights 669Scenario - Not Locked down, but can they install it ? 669Scenario - Upgrading Older Client Versions 670Scenario - Using an Update Site 671Scenario - Wide open and No Restrictions 669Schedule a new meeting page 519Schema 111Search for Charles 505Searching 61, 85Section Overview 133Secure Sockets Layer (SSL) 71Securing the Sametime Connect client for desktops 538Security 62, 86, 538Security -- Global Security 490Security helper file properties 479security helper file properties 479Security warming when running GSKit setup,exe 541Select $PersonInheritableSchema Subform 808Select a language 221Select Domino Directory Template pubnames.ntf 810Select Downloads 67Select IP address to listen on 95Select Loopback Adapter 232Select the directory to use for collaboration 151, 194, 307selected internal user

Directory records 51, 55Selecting a recorded meeting 689Selecting keywords 681Selecting the Load Balancer server 262Send links, graphics, and screen captures to chat partners 640separate directory 48, 51

Invited Meeting Server Model 55Separate External Sametime Meeting Environment in the DMZ with Selective Directory Replication 51Separate External Sametime Meeting Server using Invited Meeting Server Model with Separate Directo-ries and using Reverse Proxy Access 55Separate External Sametime Meeting Server with Selective Directory Replication and using Reverse


Proxy Access 54Server affinity in Load Balancer 831Server Certificate Administration Database 591Server Certificate Request 580Server Document for Chat1/ITSO 597Server document, basic tab 395Server Extensibility 13servlet 713, 715, 736Session Initiation Protocol (SIP) 742Set Load Balancer machine with static IP address 242Set NIC to listen for imcluster address traffic 242, 246Set up an additional server 184, 297, 377, 432Set up the cluster 260Set up the first server or a stand-alone server 140Setting default meeting parameters 535Setting JAVA_HOME environment variable. 544Setting up SSL for Sametime for WEB Services 598Setting up SSL to LDAP for Quickplace 599Setting up SSL using a self-signed certificate 540Setting up SSL using certificate from a Trusted au-thority 564Setup Business Card Feature for ITSO 341Setup SSL on Sametime Server with self signed Certificate 553Setup SSL on Sametime Server with Trusted root Certificate 584Showing removed previous applets 688Sign In form mapping 457Signed Server Certificate 581Signer Certificates for Sametime key.kdb file 555Signer Certificates with Domino Certificate Authority 578Silent Install 675single interface 4single point of failure (SPOF) 821Single Sametime Server 29, 31, 706Single Sign On 63, 87Site Selector 831Smart Tags - 528Software components 713software extension

development effort 814effort 815effort tasks/activities 815

Software System Requirements 70Specific overview of the Architecture in the US 58

Specify an Administrator name and password 142–143Specify key file name and location 553Specify name and password 440Specifying Sametime Community server in Team Workplace 466Specifying the Sametime server in QuickPlace 460Specifying the Web Conferencing authentication name 465Spell checking functionality within the product 643Spell checking preferences 643Spell checking tool 644SSL Encryption 540SSL session ID 835SSL session Id 828, 835SSL setting in Server Document for chat1/ITSO 598Standalone Mux Hardware Specifications 69Start Advisor 275Start Domino as a Windows service. 139, 183, 296, 376, 431Starting and Stopping Service 100Starting embedded WebSphere server 101Starting Executor 263Starting Manager 272Starting the advisor for port 1533 273Starting the advisor for port 8082 275Stash Password 546Status of the connection 665stconfig.nsf - Community Connectivity 507stconfig.nsf - LDAP document 356, 419Stephen Shepherd 110, 116, 764, 798, 800, 805Steps for installing Tivoli Directory Server 87Steps to populate using the LDIF File 111Sticky time 832sticky time 832–833Stickyness 832Stickyness to source IP address 832still active (SA) 38–39stkey.jks with CA’s Trusted Root Certificate 590Storage Respositories 337Subcomponent Selection window 257subform 808Successfully saved Web Conferencing parameters 517Suffixes 106Summary of selected installation options. 138, 182, 295, 375, 430Support for n-way chat history 649

Index 853

Synchronization of contacts 531Synchronize the directories 384System Databases for Domino 188, 301, 379, 435Systems Management and Maintenance 691

TTabbed Chat for multiple Sametime sessions 638Tabbed chat functionality for Sametime from directly within the Notes Client 662Tabbed chat sessions 638TCP/IP Address 249TCP/IP connection 34, 72, 822

Sametime protocol 74TCP/IP packet 822TDS Administrator’ DN and password. 96TDS features selection 91TDS Features to install confirmation screen 93TDS IP Ports 96TDS Language Selection 87TDS License 89TDS Software installation path 90TDS Welcome Page 88Test Awareness in Portal 503Test Lotus Web Conferencing portlet 517Test SSO between WebSphere Portal and Same-time. 498Test the Sametime Contact List Portlet 509Testing online awareness 463Testing Online Meetings 468Testing single sign-on 458Testing The Business Card Setup 352Testing the user directory 447The Applications within EMS 713The Business Value 742The client authentication process 538The meeting creation page has been modified 664The ping test should reply back with the correct IP 147, 190, 303Time stamps and other configurable options 642Tivoli Directory Server Installation 87Tivoli Directory Server Web Administration Tool 342top 12, 32, 106, 110, 235, 331, 438, 635, 695, 699, 704, 710, 763–764, 805top givenname 763–764Topology recommended for connecting to the AOL®, Yahoo! Messenger™ and Google Talk™ user communities 747

tr0 266tr1 266Troubleshooting 529Troubleshooting EMS 731Trust operation succceded 561Trust Root Certificate Label 578Trusted Root Certificate 576Trusted root certificate in notepad 576Type ahead name searching 645Types of Directories 59, 84Typical LDAP DN formats 161, 204, 317

UUDP port 77–78

multicast data 77Understanding different models and scale factors between Community and Meeting Services 710Understanding the distinguishing features within Sametime 7.5, and Sametime 7.5.1 4, 633United State 34, 58update 5, 714–715Update resolve filter in Sametime. 418Update sametime.ini 332Update stlinks.js 333Update the SSO login form for QuickPlace 455updated resolve filter including notescon 357updated resolve filter including NotesDN 420URI affinity 835URL 101, 705, 711, 828, 831Use Canonical name for instant messaging status lookup 360Use Case 1- business card-related information is stored inthe Sametime Directory 338Use Case 2 - Business card-information for a single userspread across 2 separate and distinct storage repositories 338Use Case 3 - information is spread across two (2) separateyet similar storage types 340user xiii, 1, 7, 21–22, 79, 83, 149, 152, 305, 308, 331, 335, 539, 558, 631, 635, 692, 694, 710–711, 740, 746, 763–764, 805–806, 815, 821, 831user directory 19, 59, 61, 79, 83, 805–806User directory from QuickPlace administration place 443User Filter 719user objectclass 763–764User Security - People, Services 560Using Multiple Caching Proxy Servers 623


VVerification 216Verification Checkpoint - Domino server setup 147, 190, 303, 380, 436Verification Checkpoint - Sametime server configu-ration 170, 213, 326Verification Checkpoint - Sametime server installa-tion 152, 195, 308Verification Checkpoint - Test Domino Cluster 218Verify New directory server instance 98Video and voice enhancements 636Video in Chat 636View Business Card 645View Business Card. 335View Key Ring file with trusted root ITSO Trusted Root Authority 596virtual private network (VPN) 49Voice chat functionality 637

WWAS administrator 476WAS/EMS Admin

name 729Password 719, 730Username 719–720

Web browser 10, 71, 101, 722HTTP connections 71

Web Conferencing 4, 14, 68, 807, 812web conferencing 632Web Configurations view 402, 452, 493Web server

Availability 821Cluster 820, 822Overloading 820Performance 821Scalability 820

Web Site Voice 632Web SSO Configuration Document 403, 453Web SSO Configuration for LtpaToken 160, 203, 316Websphere Administrator 717, 720

security page 731WebSphere Application

Server 41, 742Server 6 704Server Prerequisite 717–718

WebSphere Application Server xvii, 93, 100, 225, 227, 255, 476, 479, 482, 624, 717, 724, 742, 819,

828Prerequisite 718–719

WebSphere Application Server and DB2 742WebSphere Applicaton Server Edge Components installation 255WebSphere Everyplace Deployment (WED) 649WebSphere Portal 27, 59, 84, 800

Awareness capabilities 806–807Information Center 806–807server 804Server mail portlets 116

WebSphere Portal Integration with Sametime 474WebSphere Portal Login Screen 503, 509Welcome to Domino Integration 511What internet services should this Domino server provide 145, 187, 300, 378, 434What is a directory 81What is EMS? 707What is the Business Card 334What you will be building in this chapter 130, 282When do you use which CBR method? 831When Should You Deploy EMS 705When Should You NOT Deploy EMS 706Where is the ID file for this additional Domino serv-er? 185, 298, 433White pages 82Why do these need to exist as seperate applica-tions? 714Wide Area Network (WAN) 33, 35Windows Service 717, 729word suggestions from spell checking 644Working Contact List Portlet 512

YYellow pages 82

Index 855


Sametim

e 7.5.1 - Best Practices for Enterprise Scale

Sametim

e 7.5.1 - Best Practices for Enterprise Scale Deploym

ent

Sametim

e 7.5.1 Best Practices for Enterprise Scale Deploym

ent

Sametim

e 7.5.1 - Best Practices for Enterprise Scale Deployment

Sametim


ent

Sametim


ent

®

SG24-7410-00 ISBN 0738486531

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICALINFORMATION BASED ONPRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.

For more information:ibm.com/redbooks

Sametime 7.5.1Best Practices for Enterprise Scale Deployment

Building and deploying an Enterprise Architecture

Integration with Portal and Domino extended products

System administration and maintenance

This IBM Redbooks publication provides 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 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 the book include a discussion of the Enterprise Meeting Server and the Sametime Gateway.

Back cover

Date post:	22-Nov-2014
Category:	Documents
Upload:	gouravshnu
View:	695 times
Download:	7 times