Deploying QuickPlace - IBM Redbooks · any form without payment to IBM, for the purposes of...

ibm.com/redbooks

DeployingQuickPlace

David MorrisonTommi Tulisalo

Marcelo CamêloEmma Green

Kathleen McGivneyRob Novak

Install, configure, and deploy QuickPlace

Security and availability considerations

Real-world examples of integration with other technologies

Front cover

Deploying QuickPlace

May 2002

International Technical Support Organization

SG24-6535-00

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

First Edition (May 2002)

This edition applies to Lotus QuickPlace 2.0.8 for use with Lotus Domino 5.0.8

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

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixNotice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Chapter 1. Introduction and planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 What is Lotus QuickPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Main features of Lotus QuickPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Terminology used in this book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Planning for a successful QuickPlace deployment . . . . . . . . . . . . . . . . . . . 4

1.3.1 Common reasons for deployment difficulties and failure . . . . . . . . . . 41.3.2 Define standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 2. Installing and configuring QuickPlace . . . . . . . . . . . . . . . . . . . . 72.1 Planning the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 QuickPlace server installation types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Choosing the installation type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Server requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Browser client requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.3 Server operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.4 QuickPlace server version compatibility . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Installing the QuickPlace server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.1 Installing as a stand-alone server . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.2 Installing as an overlay on a Domino server . . . . . . . . . . . . . . . . . . . 172.4.3 Installing in a eServer iSeries server. . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5 E-mail integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6 Running the QuickPlace server as a service. . . . . . . . . . . . . . . . . . . . . . . 232.7 Offline services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.7.1 Creating an offline QuickPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.7.2 Other configuration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.8 The QuickPlace Administration Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.8.1 System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.8.2 Installation and setup overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

© Copyright IBM Corp. 2002 iii

2.8.3 Installing the Admin Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Chapter 3. Directories and authentication . . . . . . . . . . . . . . . . . . . . . . . . . 393.1 The Domino Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2 QuickPlace integration with Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.1 QuickPlace integrated into the Domino domain . . . . . . . . . . . . . . . . 423.2.2 QuickPlace in a separate Domino domain . . . . . . . . . . . . . . . . . . . . 42

3.3 Directories and QuickPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.4 Integrating QuickPlace with other directories . . . . . . . . . . . . . . . . . . . . . . 44

3.4.1 Using Directory Assistance for secondary directories. . . . . . . . . . . . 453.4.2 Directory Assistance, LDAP, and external Domino domain . . . . . . . 503.4.3 QuickPlace, Directory Assistance, and LDAP over SSL . . . . . . . . . . 533.4.4 QuickPlace and Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.5 QuickPlace authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.5.1 Basic authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.5.2 Single server, Single session sign-on (SSO) . . . . . . . . . . . . . . . . . . 573.5.3 Multi-server, Single session sign-on (MSSSO) . . . . . . . . . . . . . . . . . 58

3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Chapter 4. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.1 Overview of Domino security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.1.1 Server access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.1.2 Database access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.2 Overview of Web security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.2 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.2.3 Virtual private networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.3 Securing your QuickPlace environment with SSL . . . . . . . . . . . . . . . . . . . 624.3.1 Enabling SSL on QuickPlace servers . . . . . . . . . . . . . . . . . . . . . . . . 634.3.2 SSL on different levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.3.3 X.509 certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.4 Logging users off QuickPlaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.4.1 Clearing the browser cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.4.2 Logout command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.5 E-mail security with QuickPlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.5.1 Avoiding unwanted e-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.5.2 Antivirus scanning of SMTP mail . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.6 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.6.1 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.6.2 DMZs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.6.3 Using QuickPlace offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.6.4 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

iv Deploying QuickPlace

Chapter 5. Availability with clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.1 What is clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.2 Planning a QuickPlace cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.2.1 Types of clustering solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.2.2 Hardware considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.2.3 Network bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.2.4 Network workload distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.3 Installation and configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.3.1 Preparing QuickPlace servers for a clustered environment . . . . . . . 935.3.2 Configuring the Replica Manager and replication . . . . . . . . . . . . . . . 975.3.3 Configuring WebSphere Edge Server for a QuickPlace cluster . . . . 995.3.4 Configuring the clustered servers . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5.4 Third-party routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.5 Performance and other considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5.5.1 Virtual memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195.5.2 HTTP thread settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Chapter 6. Going live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.1 Pilot to production. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.2 Standalone to overlay and a Domino Directory . . . . . . . . . . . . . . . . . . . . 122

6.2.1 Configuration recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236.2.2 Migrating from standalone to overlay and a Domino Directory . . . . 123

6.3 Standalone to overlay with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.3.1 Member documents for LDAP users . . . . . . . . . . . . . . . . . . . . . . . . 129

6.4 User migration caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306.4.1 Going live: some factors to consider . . . . . . . . . . . . . . . . . . . . . . . . 131

6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Chapter 7. Integrating QuickPlace with other software technologies . . 1337.1 Integration with Lotus Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

7.1.1 Process management and Web collaboration together . . . . . . . . . 1347.2 Integration with Lotus Sametime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

7.2.1 Shared signon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1407.2.2 Silent login using name and password . . . . . . . . . . . . . . . . . . . . . . 1417.2.3 Silent login using name and token . . . . . . . . . . . . . . . . . . . . . . . . . 1427.2.4 Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

7.3 Integration with the WebSphere Portal family . . . . . . . . . . . . . . . . . . . . . 1467.3.1 Installation and configuration of the QuickPlace portlet . . . . . . . . . 147

7.4 Integration with Microsoft Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163IBM Redbooks and RedPapers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Contents v

Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

vi Deploying QuickPlace

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 on 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 illustrates 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. 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 IBM's application programming interfaces.

© Copyright IBM Corp. 2002 vii

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

Redbooks(logo)™AIX™AS/400™AT™CT™Current™IBM ^™IBM™

iSeries™Netfinity™OS/400™PowerPC™pSeries™Redbooks™S/390™SecureWay™

SP™SP2™Tivoli™WebSphere™xSeries™zSeries™400™

The following terms are trademarks of International Business Machines Corporation and Lotus Development Corporation in the United States, other countries, or both:

Lotus®Word Pro®Lotus Notes™Domino™

Lotus QuickPlace ™Lotus Sametime™Notes™QuickPlace™

Sametime™Tivoli™

The following terms are trademarks of other companies:

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC.

Other company, product, and service names may be trademarks or service marks of others.

viii Deploying QuickPlace

Preface

Lotus QuickPlace is the leading self-service Web tool for team collaboration. With QuickPlace, teams can share a virtual workspace to communicate, collaborate, and coordinate. People can create and share documents and knowledge, discuss ideas, coordinate tasks, do project management, just to mention a few of the features that QuickPlace offers.

QuickPlaces are created for a variety of reasons. They can serve as collaborative workspaces for teams, they can be created for projects that live only a limited time, and they can be used to help communicate and work together with people outside the company boundaries.

This IBM Redbook shows you how to install, configure, and deploy QuickPlace in your organization. It gives step-by-step installation instructions for the QuickPlace server, and describes how to configure it to use the directories your organization already has. The book includes tips for planning your QuickPlace environment to be scalable, and describes how to install and configure QuickPlace clusters. Detailed instructions as well as examples are presented.

Since QuickPlaces generally contain sensitive information, we discuss the security aspects of the QuickPlace server in detail and describe how to make a QuickPlace installation secure. And, because the number of users and QuickPlaces in an organization tend to expand quickly, we present techniques to manage this growth and the challenges it presents.

The deployment of a new solution or product such as Lotus QuickPlace often starts with a pilot. We discuss issues you should consider when planning for such a pilot, and provide information on how to migrate a pilot installation into a full production environment. Examples of migration scenarios are also given.

QuickPlace complements many other solutions your organization probably already has in place, and is designed to integrate easily with them. This redbook tells you how to extend QuickPlace by connecting it to other solutions such as Lotus Sametime, Lotus Workflow, and WebSphere Portal Server.

The team that wrote this redbookThis redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Cambridge, Massachusetts, USA.

© Copyright IBM Corp. 2002 ix

David Morrison is an International Technical Support Specialist for Notes and Domino at the International Technical Support Organization Center at Lotus Development, Cambridge, Massachusetts. He manages projects whose objective it is to produce redbooks on all areas of Domino. Before joining the ITSO in 1999, he was a senior Lotus Notes consultant working for IBM e-business services in the United Kingdom.

Tommi Tulisalo is a project leader for the International Technical Support Organization at Cambridge, Massachusetts. He manages projects whose objective is to produce redbooks on all areas of Lotus Software products. Before joining the ITSO in 2001, he was an IT Architect for IBM Global Services in Finland, designing solutions for customers, often based on Lotus software.

Marcelo Camêlo is project manager and IT Specialist for Pre-Sales at IBM Brazil in São Paulo, SP, Brasil. Marcelo specializes in Web-based integrated solutions that require extensive document management and knowledge management skills in different industry areas, such as manufacturing, government, finance, and chemicals. He has more than ten years of experience in the IT industry and is a Certified Document Image Architect and Lotus Professional.

Emma Green is a Certified Lotus Instructor, Quickplace Instructor, and consultant based in London, UK. She is the Director of Education for R5Courseware Ltd, a company that specializes in technical curriculum for Domino R5 and Quickplace. Her areas of expertise include infrastructure and administration. She has extensive teaching experience with organizations world-wide using Lotus and R5Courseware materials, and has written a number of courses. Emma’s e-mail address is: [email protected]

Kathleen McGivney is a Senior Domino Developer at Candle Corporation in Los Angeles. She possesses expertise in Lotus Notes and Domino architecture and development, QuickPlace deployment, and Lotus Domino messaging and database infrastructure, with a strong focus on Domino and QuickPlace clustering. She also has extensive experience with WebSphere Application Server, WebSphere Portal Server, Domino.Doc, LotusScript, HTML and Java. She is a Principal CLP in both System Administration and Application Development. Kathleen also co-authored the IBM Redbook, Domino R5 Clustering with IBM ^ xSeries and Netfinity Servers, which was published in November 2000. Kathleen’s e-mail address is: [email protected]

x Deploying QuickPlace

Rob Novak is president of Strategic Net Applications, Inc. (SNAPPS) in Overland Park, Kansas. SNAPPS is the winner of the 2002 Lotus Beacon Award for Rising Star. Rob and his team focus on customization, global implementation planning and execution, and developing tools for QuickPlace and Domino. An eight-year Notes and Domino veteran, Rob frequently speaks on QuickPlace at conferences and seminars. He is a PCLP, holds two masters degrees, and is a doctoral candidate in business.

A number of people have provided support and guidance.

The authors would like to extend special thanks to Stephen Londergan, Product Manager; Michael Dempsey, Development Manager; and the whole QuickPlace development team, especially Miguel Estrada, Charlie Hill and Joseph Russo.

We would also like to thank the following people:

Vladmir Brandão, Robert Bry, Abe Cohen, Katinka Kantor, Greg Prickril, Luciano Resende, Michael Rousseaux, Paulo Torres, Travis Womack - Lotus Software

Bob Balaban - Looseleaf

George Chiesa - dotNSF, Inc

Jake Ochs - eSolutionNow

Jesse Salmon - SNAPPS

Søren Peter Nielsen, William Tworek - ITSO Cambridge

Margarita Hunt, Alison Chandler - ITSO Poughkeepsie

SNAPPS Development Team

NoticeThis publication is intended to help server administrators deploying Lotus QuickPlace to understand how to best install, deploy and configure Lotus QuickPlace. The information in this publication is not intended as the specification of any programming interfaces that are provided by Lotus QuickPlace. See the PUBLICATIONS section of the IBM Programming Announcement for Lotus QuickPlace for more information about what publications are considered to be product documentation.

Preface xi

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 team with IBM technical professionals, Business Partners and/or customers.

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!

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 Internet note to:

[email protected]

� Mail your comments to:

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

xii Deploying QuickPlace

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

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

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

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


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

Chapter 1. Introduction and planning

This chapter provides some basic information about Lotus QuickPlace. In it, we introduce the core features of QuickPlace, and describe the new terms that are used in this book.

The latter part of the chapter discusses issues related to planning a QuickPlace deployment, and gives you examples of some of the most common reasons for difficulty or failure. We also provide guidelines for implementing a successful pilot in your organization.

1

© Copyright IBM Corp. 2002 1

1.1 What is Lotus QuickPlaceLotus QuickPlace is a self-service tool for creating shared, Web-based collaborative workplaces for teams. In these “virtual” workplaces, teams can create, share, and modify information, and discuss and share ideas. The teams can coordinate the people and the activities related to the subject for which the virtual workplace was created.

In addition, QuickPlace is a development platform with robust capabilities for teams. Web developers and Lotus Domino developers alike will find that QuickPlace offers a unique opportunity to start with a foundation for collaborative applications, and add significant value through advanced development.

The best way to get acquainted with QuickPlace is to try it out. You can create your own test QuickPlace at the following Web address:

http://www.lotus.com/quickplace

1.1.1 Main features of Lotus QuickPlaceSome of the features that Lotus QuickPlace has, right out of the box, include the following:

Instant creation – A secure Web workspace can instantly be created for your team—the startup time is literally 60 seconds.

Shared content – Your team’s discussions and documents are all maintained in a single location. Rich content can be created within or imported from Microsoft Office and other applications. Multiple revisions are easily tracked.

Shared sense of time – Gantt charts and calendars reflecting assigned tasks and meetings are available to help move the team toward its ultimate goals. Newsletters are e-mailed daily, providing an active pulse for the team. Real-time chat facilities are provided for instant contact.

Shared process and identity – As your project develops, the team develops a structure and process to meet its goals. The team’s QuickPlace workspace easily adapts: “inner rooms” are available for sub-team security; browser-designed custom forms with approval cycles can be easily added; and the cosmetics of the QuickPlace can be quickly changed to reflect the team’s emerging identity.

Shared knowledge – When the project or initiative is over, a new one is just around the corner. QuickPlace allows you to capture all the previously applied structure and knowledge gained into a “PlaceType” solution module. PlaceTypes can be used as the basis for the next project/initiative by the same team or by other teams within your organization.

2 Deploying QuickPlace

Deep customization – QuickPlace is designed to be easy to use and productive immediately out of the box, but for the corporate developer, Lotus Business Partner, or Application Service Provider, QuickPlace provides a wealth of customization opportunities, including browser customizations, HTML design, Java agents (PlaceBots), and server extensions. The gradient of customization extends QuickPlace from an “instant collaboration application” to an “instant collaboration platform.”

Directory integration – QuickPlace can use a Domino Directory, LDAP-compliant directory, or Windows NT user directory as a central directory for user information and authentication

Microsoft Office 2000 integration – This feature gives users the ability to author content from any Office application, and let’s them import templates as customized forms.

Task management – Team members can assign action items, track status, and monitor progress.

On-line awareness and chat – This feature facilitates brainstorming new ideas or reviewing content with on-line team members.

1.2 Terminology used in this bookIn this redbook you may encounter several new terms. Refer back to this list during your reading.

QuickPlace server – A Web-based groupware development platform to support team communications, unstructured work practices, content management, process management, and collaboration.

Overlay installation – QuickPlace can be installed as a standalone server or as an overlay installation on a Domino server.

Place – A virtual collaborative space, created on a QuickPlace server, instantiated as a group of Domino databases with “awareness of each other.” Sometimes we also refer to a Place as a QuickPlace, but only where it cannot be confused with the full QuickPlace server.

PlaceType – A design specification that gives an instantiated Place all of its default and configurable properties, including its appearance, structure, business logic, content, and programmatic behaviors. A QuickPlace server can be configured to allow the creation of a PlaceType from every Place, in order to reuse form, content, and processes.

Chapter 1. Introduction and planning 3

PlaceBot – A programmatic enhancement to a QuickPlace form, based on LotusScript or Java, that extends or alters the QuickPlace’s form handling behavior. PlaceBots are in essence similar to Domino agents, with the difference that Domino Designer is required to write an agent, while PlaceBots can be written in a simple text file and uploaded to the QuickPlace server from a Place.

Workflow – Applications or features that coordinate the work of groups, when appropriate, making sure that the decisions of one person are acted upon before being passed on to the next person; often embodying features such as privacy control, sequencing, notification, and routing.

Theme – A collection of elements that use the QuickPlace Layout Architecture to control the look and layout of a QuickPlace, often associated with the identity, purpose, and norms of the group. It is sometimes referred to as Skin.

1.3 Planning for a successful QuickPlace deploymentWhen planning a deployment of QuickPlace, it is important to note that although the product is packaged to be installed quickly, and in fact can be installed in 5 minutes or so, there are numerous considerations around the rest of the infrastructure that must be assessed, even in pilot.

Each deployment is slightly different and is affected by the organization’s infrastructure, technology, culture, and place on the technology adoption curve. For instance, it is quite common that the deployment of Quickplace will start with a test or a pilot environment and then evolve to a production environment. This is no different than any other technology solution—however, the difference is that for QuickPlace, its availability and the content posted on it will give even a pilot the characteristics of a mission-critical system very early on.

The chapters in this book are designed to help technologists manage their way through the decisions required to plan an effective and smooth QuickPlace deployment. For managers, it is important to understand that even with an easy-to-install program like QuickPlace, planning is a critical component of the deployment process and this book, professional assistance, and research are part of the due diligence you should follow before implementing a collaboration system.

1.3.1 Common reasons for deployment difficulties and failureThe experiences gained on numerous QuickPlace deployments reveal that there are a couple of simple reasons for many problems and fails in a deployment, the most common being:


1. User directory choices, the number one reason for difficulty in moving from pilot to production.

2. Imposing a technology solution where a culture for collaboration does not exist.

3. Lack of planning, leading to dissatisfied users and discussions of another technology direction.

While there are many other reasons a deployment might fail, we recommend that you consider these three points with respect to your company’s specific circumstances, to ensure a smooth deployment process in your organization. Pay close attention to the release notes of the version of QuickPlace you are installing. They tell you the hardware and software requirements that your installation has to comply with. By doing that, you will avoid some of the early issues encountered during installation and configuration.

1.3.2 Define standardsTaking the time to properly plan and document a set of standards at the start of a deployment project will ensure that you build a robust and flexible Domino environment. Standards will ensure consistency and integrity of data across the organization and maximize the efficient use of the Domino infrastructure. Standards will help you because they do the following:

� Facilitate the integration of new technologies into existing infrastructures.

� Let you deploy applications that are readily accepted by the user community.

� Assist in establishing an infrastructure that is easily managed, maintained and supported.

� Serve as the basis for the quality of service you deliver.

� Ensure compatibility across support organizations and platforms.

� Save time and productivity during implementation and maintenance and thereby reduce costs.

� Make troubleshooting easier. Without a level starting point, it will be very difficult to determine what your problems are or could be.

� Make it easier for new administration staff to learn the environment.

� Provide a central source of information that all support teams can refer to (and possibly your end users, if appropriate).

It’s important to note that in order to gain maximum advantage from standards, they must be developed and observed across all disciplines of the IT infrastructure and supported throughout all levels of management.

Chapter 1. Introduction and planning 5

Without this, there is a danger of implementing a disjointed and potentially unmanageable environment.

ConsiderationsStart work on a set of standards as early as possible in a deployment.

Waiting until the collaborative infrastructure has already been rolled out and established will be too late. People naturally resist change and will not welcome the introduction of a new way of doing things.

Having said that, it is not impossible to implement standards after deployment, nor should not having them in advance be used as an excuse not to implement them. It will simply make your job a little more challenging.

When thinking about standards, remember that they should:

1. Be flexible enough to allow people to perform their jobs

2. Not completely limit or deny creativity or flexibility

3. Be clearly documented in a central area that is accessible by all relevant parties

4. Be a living document that is updated as new technology emerges and the environment changes

5. Be developed in conjunction with all support teams, with the opportunity for review and feedback throughout the process

6. Be enforced

Having said all this, remember to develop and document a process for requesting, reviewing, and granting exceptions to the documented standards for special cases.

1.4 SummaryIn this chapter we have given a brief overview of Lotus QuickPlace. We have also described the terminology to be used in the book. Finally, we have provided suggestions to help you ensure that your deployment will be successful.


Chapter 2. Installing and configuring QuickPlace

This chapter describes how to install and configure QuickPlace servers.

Different types of QuickPlace server installation methods are discussed, along with stand-alone versus overlay on an existing Domino server. We describe how to plan the installation and define the system requirements, then we give step-by-step procedures for installation and configuration.

We discuss how to integrate QuickPlace with your mail system, and how to implement offline services.

Finally, we describe the features of the QuickPlace Administration utility, and how to install and use it.

2


2.1 Planning the installationFollowing is a high-level overview of the steps to take in planning the installation of QuickPlace server. Details about some of the steps are covered in this chapter, others later in the book. References to the pertinent sections are provided here.

1. Choose the installation type.

The first thing to do when planning for a QuickPlace installation is to decide whether to install it as a stand-alone server or as an overlay install over a Domino server. The details regarding each type of installation are in 2.2, “QuickPlace server installation types” on page 9.

2. Choose the domain.

You have the option of adding your QuickPlace server as an additional server in a existing Domino domain or creating a new domain for your QuickPlace server. To learn more about Domino domains, see the Domino 5 Administration Help database (help5_admin.nsf).

3. Define the level of security.

There are several techniques from which to choose when considering the level of security to implement. See 3.5, “QuickPlace authentication” on page 55 for information about Single Sign-on (SSO); see details in 4.3, “Securing your QuickPlace environment with SSL” on page 62 to learn more about adding security to your environment using Single Sockets Layer; and if you have a firewall to protect your environment, see 4.6, “Firewalls” on page 85.

4. Define the use of directories.

You can use the Domino Directory or another external directory as your user directory. See more in 3.3, “Directories and QuickPlace” on page 43.

5. Define the mail server.

You can use Domino or another SMTP server as you mail server. Learn more about this in 2.5, “E-mail integration” on page 21.

6. Ensure that your environment meets the system requirements.

See details in the release notes of your QuickPlaces server, and see 2.3, “System requirements” on page 10.


2.2 QuickPlace server installation typesThere are two installation types for QuickPlace: as a stand-alone and as an overlay install on a Domino server. Each installation type has its own benefits; choose between them in accordance with your organization’s particular needs.

The installation types have the following characteristics:

� Stand-alone - The QuickPlace server is installed on a server which doesn’t have a Domino server installed. The stand-alone QuickPlace server will still utilize features and services the Domino server provides, such as security and http server. The installation program installs minimal Domino code, which is required for QuickPlace server to use Domino functionality.

� Overlay install - The QuickPlace server is installed on a server which has a Domino server installed. The QuickPlace server runs as a task in the Domino server, and can use all the services provided by the Domino server, such as mail routing, directory services, management tools, and logging.

2.2.1 Choosing the installation typeWhen installing the QuickPlace server, the question arises whether one should install the QuickPlace server in a stand-alone mode or as an overlay install. The simplistic answer is that, if there is an existing Domino environment in the organization, then it is advantageous to install the QuickPlace server as an overlay. Of course, hardware and bandwidth capacity always need due consideration before reaching a conclusion.

In the next release of QuickPlace, the overlay install on Domino server is going to be the only installation type available. As a general rule, we recommend that you use this installation type. You gain a lot of benefits by using the overlay on Domino server install, such as:

� You are able to replicate with other QuickPlace servers.

� You can use your existing Domino skills for administration.

� Domino server provides you with the required security features to let people from outside your company network access your QuickPlace server.

� You can configure your server to use more than one directory with Directory Assistance.

� You are able to cluster QuickPlace servers for high availability.

� You are able to implement Single Sign-On with other servers by using the DSAPI.

Chapter 2. Installing and configuring QuickPlace 9

One benefit of installing the QuickPlace server on top of Domino is that it makes administering the environment easier. You can take advantage of all the existing Domino management tools, along with the administration and support processes; for example, you can continue to do logging and analysis via domlog.nsf. If you have a data backup process in place for your Domino applications, the same process can automatically back up QuickPlaces. Also, in most cases, end-user support can use the same problem management model as with existing applications.

If you have an existing Lotus Domino environment and would like to customize or enhance the QuickPlace capabilities, then it is suggested that you install the QuickPlace server on top of a Domino server.

Disadvantages of running QuickPlace as an overlay include:

� Additional load on the Domino server may impact the response times for existing Domino users.

� Any problem with the Domino server may also impact QuickPlace users.

We recommend that you install the QuickPlace server on a dedicated machine, regardless of your selection of the installation type.

Keep in mind that, regardless of whether QuickPlace is installed in stand-alone mode or as an overlay, if Domino and QuickPlace are installed on the same piece of hardware, then any hardware trouble may impact both environments.

2.3 System requirementsHere are the system requirements for the QuickPlace server version 2.0.8. If you are installing a version other than this, read the system requirements from the release notes of that particular version of QuickPlace.

2.3.1 Server requirementsThis section gives you an overview of the minimum requirements to run the QuickPlace server on different platforms.

� Windows NT Server

– Windows NT 4.0 Service Pack 4 or above.

– 150 MB minimum free disk space, 200 MB recommended.

– 128 MB minimum memory, 256 MB recommended.

– Video Card: 256 colors minimum, True Color recommended.


� eServer iSeries

– An iSeries server based on PowerPCTM technology that is running OS/400R with the latest cumulative PTF package applied. Refer to the release documentation for the required OS/400 version.

– Minimum 500 MB free disk space.

– Minimum 256 MB memory, 512 MB recommended.

� eServer zSeries

– Domino 5.0.8 for S/390

– QuickPlace requires 30 MB in the Notes executable directory and 20 MB in the Notes data directory. Additional space should be allocated in the Notes data directory for creation of new QuickPlaces.

� eServer pSeries

– QuickPlace 2.0.8 works on AIX 4.3.3. Refer to the QuickPlace 2.0.8 product documentation for information about limitations, as well as further requirements.

– Domino 5.0.9x Server

� Solaris

– Minimum 160 MB free disk space (80 MB for program files and 80 MB for data files), 200 MB recommended

– Minimum 128 MB memory, 256 MB recommended

2.3.2 Browser client requirementsOn an IBM-compatible PC, you need to have one of the following:

� Microsoft Internet Explorer 4 with SP2 or above

� Microsoft Internet Explorer 5.x

� Netscape Navigator 4.5x



� Lotus Notes 4.6 and above using integrated Microsoft Internet Explorer 4 and above

On a Macintosh you need to have one of the following:

� Microsoft Internet Explorer 5.x





2.3.3 Server operating system� Windows 95, Windows 98, Windows NT 4.0 Server (with Service Pack 4).

� Windows 2000 as a platform for a QuickPlace server and browser client is supported, but it is not certified.

� System 8.6, System 9.

� iSeries V4R3 or later.

� AIX 4.3.3.

� Solaris 8 (supported in QuickPlace Release 2.0.5).

� IBM S/390 (supported in QuickPlace Release 2.0.7).

2.3.4 QuickPlace server version compatibilityQuickPlace can be installed as a stand-alone server or on top of Lotus Domino, but should you wish to install QuickPlace on top of Domino, you need to make sure that the release version of QuickPlace corresponds with the appropriate release version of Domino. For example, QuickPlace 1.0.3 works as an overlay install on top of Domino 5.0.3; QuickPlace 2.0 works as an overlay install on top of Domino 5.0.4 and QuickPlace 2.0.8 works on top of Domino 5.0.8.

Previous versions of QuickPlace (1.0, 1.0.2, 1.0.3) do not work with Domino 5.0.4. After you upgrade to Domino 5.0.4, you must upgrade to QuickPlace 2.0 to make sure you can continue working with your existing QuickPlaces. You can find information on the QuickPlace 2.0 download at:

http://extranet.lotus.com/qpdevzone


2.4 Installing the QuickPlace serverThis section gives you step-by-step instructions for installing a QuickPlace server on a Windows NT server. First we present the steps for a stand-alone installation, then those for an overlay installation.

2.4.1 Installing as a stand-alone serverThe process to install QuickPlace as a stand-alone server is quick and easy.

In stand-alone mode, the QuickPlace server does not need a pre-installed Domino server. Although it still uses a Domino engine for the services, the installation program installs all the necessary elements to run QuickPlace. The required parts of the Domino server code are installed as part of the stand-alone installation.

1. Run the setup.exe that is part of the QuickPlace installation package.

2. The installation program starts.

3. Select the appropriate drive and directory (the default is c:\lotus\quickplace) where you want to install the software. See Figure 2-1 on page 14 for details.

Attention: Before you begin the installation process, make sure that no Lotus Notes, or Domino, Sametime, or QuickPlace servers are running on the same server.

Note: If your server has an existing Domino environment and you do no want to install QuickPlace over a Domino Server, you must choose a different location than the Domino directory to install your QuickPlace stand-alone server. You might encounter unforeseen problems if you try to run the two servers at the same time on the same machine.


Figure 2-1 Choosing the destination folder for the installation

4. On the screen shown in Figure 2-2 on page 15, type the user name, and type and confirm a password, for the person who is going to be the QuickPlace server administrator. This name is not mapped to any user record in any directory, and the name and the password are recorded into the names.nsf file.


Figure 2-2 Defining the user name and password

That’s all there is to it! The installation process picks up all the network information (like the host name, domain, TCP/IP address, and so forth) from the network configuration of the Windows NT server you are installing from.

Once the installation was successful you see a window containing information on how to access the QuickPlace server you just installed. This is shown in Figure 2-3 on page 16.


Figure 2-3 Installation finished successfully

5. Click the Finish button. The preferred browser automatically launches with the readme.htm file, shown in Figure 2-4 on page 17, that contains a link to your newly installed QuickPlace site. It also provides information on how to start and stop the QuickPlace server via the Services dialog under the Control Panel in Windows NT.


Figure 2-4 Read.me file launched into the browser after installation

6. After the installation, the QuickPlace server is automatically launched.

2.4.2 Installing as an overlay on a Domino server

Installing a QuickPlace server on top of an existing Domino server is quite similar to the installation routine for a stand-alone version. However, there are a few differences. One difference is that the install process requires you to provide the certifier ID file, along with the password, that your existing Domino environment is using. This is shown in Figure 2-5 on page 18.

Attention: Make sure your Domino server is not running when you install the QuickPlace server.


Figure 2-5 Specifying the Certifier ID File during the installation

Follow the simple steps given previously for the stand-alone installation. Once the installation is complete, the readme file is displayed in the browser, as shown in Figure 2-4 on page 17.

As in the stand-alone mode, QuickPlace server is automatically launched. In this case the Domino server is started, and the start of the QuickPlace process is logged in the Domino console.

In the overlay install, the installation process modifies only two Domino files: Notes.ini and Domino Directory (names.nsf). All the other files, which are modified or copied, are QuickPlace server-specific.

Certifier ID considerations and certifier hierarchyDomino is a security-rich environment. It also follows a hierarchical naming convention. As a Domino administrator, you can control which users, group of users, organization units, and organizations can perform certain operations.


The certifier ID file is what forms the base for the hierarchy. Your application designers can then use the appropriate hierarchy certificate (certifier) while building the design elements like forms, agents, etc., so as to avoid any security violations in the QuickPlace server. To learn more about certifiers and certificates, refer to the Domino 5 Administration Help database (help5_admin.nsf).

When using a stand-alone QuickPlace server, you can enter the certifier ID and password in the advanced section. Contact your Domino administrator to obtain the relevant certifier ID file and its password. If you need to customize the QuickPlace environment using the Domino Designer, then be sure to specify the same certifier ID that is used by your development team.

The Domino IDs that the designers use to create agents should have valid execution rights on the Domino server. You can specify this in the server document of the Domino Directory (names.nsf) under the Agents Restrictions section of the Security in the server document. Alternatively, you may sign the database or elements with the Domino server ID (Quickplace server ID in the stand-alone mode). For more details about signing the database, see the document “Signing a template or a database” in the Domino 5 Administration Help database (help5_admin.nsf).

During the QuickPlace server installation, make sure that the certifier file you provide is the one that is the base for the IDs that you or your developers use to sign the design elements.

Groups and securityFor every QuickPlace, h_members is the group (with the proper hierarchy) that is created in the Domino Directory. This is where all the members of a particular Place are listed. The Contacts1.nsf (Member List) of every Place contains person records of all the members.

The group, h_members, is used in the access control list (ACL) of Contacts1.nsf to limit read access to the members only. The ACL of main.nsf controls the access to that Place. The managers for the Place are listed with Manager access in the ACL, and so are the authors and readers with corresponding ACL rights.

Note: The certifier ID file may not contain more than two OUs. QuickPlace uses two additional OUs - one always named QP and another has the same name as that of the QuickPlace. For example, in our case the certifier ID had OU=ITSO/o=IBM as the hierarchy. So, the manager of our newly created QuickPlace had the canonical name.


2.4.3 Installing in a eServer iSeries serverThe process for installing QuickPlace on your AS/400 system uses the Load and Run (LODRUN) command. The installation procedure for AS/400 is described in more detail in Installing and Managing QuickPlace for AS/400. This is found as a PDF file on your AS/400 QuickPlace CD-ROM, and is on the Web at:

http://www-1.ibm.com/servers/eserver/iseries/quickplace/

Briefly, the installation steps are as follows:

1. Sign on to your AS/400 system.

2. End any existing Domino or QuickPlace servers on your AS/400 system.

3. Insert the QuickPlace for AS/400 CD-ROM in the AS/400 CD-ROM drive.

4. On the OS/400 command line, type the OS/400 command LODRUN and press F4.

5. When the Load and Run screen appears, follow these steps:

a. Enter *opt in the Device field.

b. Enter '/os400' in the Directory field. If this step fails with the message “Not able to allocate object OPT01,” use the WRKCFGSTST *DEV command to determine the name of your active optical drive, for example OPT02, and use that value in place of *opt.

6. The QuickPlace option screen appears. Enter 1 in the QuickPlace product option field. Press Enter and the system will load the QuickPlace product into the appropriate AS/400 libraries and /QIBM directories. Status messages will appear as the software is copied to the AS/400 system.

7. When installation is complete, you are ready to configure QuickPlace.

Before configuring QuickPlace on your AS/400 system, we recommend that you read the following RedPaper: REDP0045: Lotus QuickPlace for AS/400 - Setup and Management Considerations / An ITSO RedPaper.


2.5 E-mail integrationYou have the option to determine how your QuickPlace server sends and receives e-mail in a variety of network configurations.

Click the more information link, shown in Figure 2-6, to see useful information for determining the proper e-mail domain and SMTP server settings for your QuickPlace server.

Figure 2-6 The mail settings page in QuickPlace

Click Change Mail Settings on the right side of the screen to access the mail settings page, which is shown in Figure 2-7 on page 22.


Figure 2-7 The mail settings

Receiving mailThe Email Domain setting for your QuickPlace server plays a role in determining whether QuickPlaces that are created on this server can successfully receive e-mail.

Suppose a user creates a QuickPlace, titled CoolProject, on a QuickPlace server, TeamServer.com. In a typical network configuration, people could now send mail to [email protected]. The mail would be delivered to the index of http://Teamserver.com/CoolProject.

Thus, each QuickPlace that is created on your QuickPlace server automatically gets its own e-mail address. The manager of each QuickPlace determines whether folks are able to send mail into the QuickPlace by going to Customize Basics within the QuickPlace.


When the QuickPlace server is installed, by default the Email Domain setting is set to be the same name as the computer on which the QuickPlace server is installed. If QuickPlaces that are created on this server are able to receive mail, don't change QuickPlace's Email Domain setting. You are all set.

If QuickPlaces on this server are not able to receive mail, it is probably because your organization's network requires a different Email Domain setting. Here are some details about QuickPlace's ability to receive mail:

� Each QuickPlace is allocated an e-mail address: QuickPlaceName@domain, where domain is determined by the value of the Email Domain setting.

� Any computer that is trying to send mail to this QuickPlace server must be able to resolve this domain name. In a DNS environment, this is typically handled by looking up the MX record or the IP address of the domain name in the DNS server.

Another popular configuration relies on host files, where the domain name must be contained in the host file of the sending computer.

Sending mailThe SMTP Server setting affects how this QuickPlace sends e-mail notifications to individuals inside and outside your organization.

E-mail notifications are used in QuickPlace to notify new members that they have been invited to a QuickPlace, and to notify members of new pages that have been added to a QuickPlace.

The QuickPlace server includes an SMTP server function which sends and receives SMTP mail. When QuickPlace is installed, by default, there’s no value for QuickPlace's SMTP Server setting. The QuickPlace server will send all outgoing mail from QuickPlaces. If you have a network configuration where you prefer to route all mail through another SMTP server, you need to specify that server's name in the SMTP Server setting.

2.6 Running the QuickPlace server as a serviceIf you have installed Lotus QuickPlace on Windows NT or Windows 2000, your QuickPlace Server is installed as a service that automatically starts when Windows starts up.

You can stop or start the QuickPlace server on Windows NT by doing the follow-ing:

� Choose Settings-> Control Panel from the Windows Start menu on the computer in which your QuickPlace Server is installed.


� Double-click the Services icon. (You will be presented with the NT Services dialog).

� Select “Lotus QuickPlace Server” in the list of Services.

� Click either the Stop or Start button.

� Click Close to dismiss the NT Services dialog.

Manual startupTo configure the QuickPlace server for manual startup on Windows NT, do the following:

� Select “Lotus QuickPlace Server” in the list of Services in the NT Services dialog.

� Click the Startup... button

� Change “Startup type” to Manual.

� Click the OK button

You can stop or start the QuickPlace server on Windows 2000 by doing the following:

� From the Start menu, select Programs -> Administrative Tools -> Services.

� The Services window is opened, as shown in Figure 2-8 on page 25.

� Select “Lotus QuickPlace Server” in the list of services.

� You can start or stop the service by clicking the appropriate buttons on the icon bar.

Note: As an automatic service, the QuickPlace server will start automatically whenever Windows NT starts up. You can opt to have QuickPlace require manual startup by following the next set of steps.


Figure 2-8 Services window in Windows 2000

2.7 Offline servicesWhen you work with your QuickPlace online, you have to be connected to your QuickPlace server. If you need to access the QuickPlace while not connected to the network, you can create an offline QuickPlace. An offline QuickPlace is a copy of the one on the QuickPlace server; it resides on the hard disk of your personal computer. The offline QuickPlace can include the top-level room in the QuickPlace only, or the top-level room plus some or all of the inner rooms, if there are any.

When you make changes in your offline QuickPlace while physically connected to your QuickPlace server—for example, when you add or edit pages in the offline QuickPlace—QuickPlace server automatically updates your online QuickPlace with the changes at regular intervals. Similarly, when you make changes in your online QuickPlace, QuickPlace server updates the offline QuickPlace with the changes. The process of updating the online QuickPlace and the offline QuickPlace is called synchronization.


You can have more than one offline copies of a QuickPlace. For example, if you use one computer to connect to your QuickPlace and a colleague uses another computer to connect to the same QuickPlace, you and your colleague can each create your own offline QuickPlace on your own computer. In addition, if two or more people share the same computer, each person who uses the computer can create his or her own offline QuickPlace on that computer.

2.7.1 Creating an offline QuickPlaceQuickPlace allows you to work with the QuickPlaces on your QuickPlace server or to take a copy of the online QuickPlace (or part of it) and put it on your personal computer. This enables you to work offline and synchronize the offline QuickPlace and online QuickPlace later. The software program that allows you to do this is called QuickPlace-Sync.

During the installation process, QuickPlace copies information from the server where your online QuickPlace resides to your hard drive, and synchronizes your online QuickPlace and offline QuickPlace for the first time. The entire process may take a few minutes or more, depending on the size of the QuickPlace and the type of connection you have.

Installing an offline QuickPlace requires a minimum of 66 Mbytes of disk space. Make sure you have this much space available before you begin installing an offline QuickPlace.

To create an offline copy of a QuickPlace, follow these steps:

1. Go to the top-level room of the QuickPlace.

1. Click the Customize link on the left side of the page (see Figure 2-9 on page 27).

2. Click the Offline link in the middle of the page. A page with offline-related information opens. This is shown in Figure 2-9.

3. Click the Begin Install link in the top right corner of the page.


Figure 2-9 The beginning of the offline QuickPlace installation

4. A new page with instructions opens.

5. Read the instructions and click the INSTALL NOW! link in the bottom right corner of the page.

6. Depending on the security settings for your browser and whether or not you connect to your online QuickPlace through a proxy server, your system may or may not display a Security Warning or Security Information dialog box. Click Yes to start the installation.

7. The installation program displays the QuickPlace-Sync Installer dialog box, which lists the steps the program must perform to finish the installation of your offline QuickPlace, and proceeds with the installation. A checkmark appears next to each step as it is completed. See Figure 2-10 on page 28.

a. Click OK when QuickPlace presents you with a pathname for the folder (directory) into which it will copy the offline QuickPlace files.


b. QuickPlace asks you for this pathname when the progress indicator in the QuickPlace-Sync Installer dialog box reaches “Install QuickPlace-Sync software.”

Figure 2-10 Offline Quickplace installation in progress

8. Click Yes when QuickPlace asks whether you want to create a folder with the name you approved in the previous step. If this is not the first time you have installed an offline QuickPlace, QuickPlace does not ask whether you want to create the folder.

If QuickPlace finds there is not enough disk space on your hard drive for the offline QuickPlace files, it presents you with a warning. You can then do one of the following:

– Choose a new pathname that points to a drive where there is more disk space.


– Use Windows Explorer to delete unnecessary files on your hard disk and then return to the offline QuickPlace installation process.

– Cancel the offline QuickPlace installation process.

9. Enter the password you use to sign in to your online QuickPlace and then click OK. See Figure 2-11 on page 29.

10. This password lets you start both the offline QuickPlace and QuickPlace-Sync, the program that synchronizes your offline QuickPlace with your online QuickPlace. Windows starts QuickPlace-Sync every time you start your offline QuickPlace and prompts you for this password.

If you don’t want to enter a password every time you start your offline QuickPlace and QuickPlace-Sync, click Save Password.

Figure 2-11 Entering the password for QuickPlace synchronization

If you receive an error message after you enter the password, one of two things has happened: You either entered the password incorrectly or QuickPlace-Sync was unable to connect to the QuickPlace server.

11.When checkmarks appear next to all the items in the QuickPlace-Sync Installer dialog box, click Done.

12.Click OK to dismiss the message that tells you to restart your computer.

13.Close all your applications, including your browser, and then shut down and restart your computer. QuickPlace creates an icon labeled “QuickPlace Offline” on your Windows desktop and puts your offline QuickPlace on the Windows Programs menu, giving you two different ways to start your offline QuickPlace from the Windows desktop.

14.Start your offline QuickPlace either by double-clicking the QuickPlace Offline icon on the Windows desktop or by selecting Start -> Programs -> QuickPlace -> QuickPlace Offline.

15.Enter your user name and password to start your offline QuickPlace. You can now either change your offline options or start reading and/or creating pages in your offline QuickPlace.


2.7.2 Other configuration optionsQuickPlace provides server settings regarding the use of ActiveX and Java, QuickPlace chat, QuickPlace Offline, e-mail link format, PlaceBots, and file attachments. Click the Other Options link on the left side of the QuickPlace screen to access the Other Options panel shown in Figure 2-12. Click the Edit Options button to modify these settings.

Figure 2-12 Other options

The option settings have the following functions and meanings.

� Enable/Disable ActiveX and Java - Choose whether to allow the use of ActiveX controls and/or Java Applets. If you choose to disable ActiveX and Java you can avoid potential security holes; but you will also disable, for example, PlaceBots written in Java.

� Enable/Disable PlaceBots - By enabling this option, you allow QuickPlace managers to import and run PlaceBots. With PlaceBots, you can have


programmatic access to data in QuickPlaces; but a badly coded PlaceBot can do damage to your installation, for example, causing your server to fail or slowing the server dramatically. Some administrators might want to choose to disable PlaceBots for added security or performance reasons.

� File Attachment Size Limit - Set the maximum size of files that can be attached to QuickPlace pages.

This is an effective way to control how much information is stored on your QuickPlaces. Since it is very easy to create new documents in QuickPlaces and attach files to them, you might want to pay close attention to the size of the attachments you allow QuickPlace users to add to pages.

� Enable/Disable Chat - Choose whether to allow QuickPlace members to communicate using real-time chat.

This option has no effect, if you don’t have Sametime as a part of your installation.

Choose to disable if you don’t want to allow QuickPlace users to use Chat services.

� Remote Chat Server - Specify a remote QuickPlace server or Sametime multiplexer to provide chat services.

� Offline Passthru Server - Specify a passthru server for use when accessing QuickPlace Offline.

� Alternate Offline Download URL - Specify an alternate URL for downloading the QuickPlace Offline installer. You can direct your users to download the QuickPlace Offline installer from somewhere other than from your QuickPlace server. By doing this you take away the unnecessary workload from your QuickPlace server.

� Email Link Format - Specify an alternative root URL for QuickPlace links displayed in outgoing email messages. By default the URL for the server would be the hostname of the server; you might want a more meaningful name.

For example, for the hostname of itsoQP01, an example of a link to a QuickPlace would be http://itsoQP01.ibm.com/exemplaryQuickPlace; specifying the email link format to be quickplace.itso.ibm.com would result in the same link being http://quickplace.itso.ibm.com/exemplaryQuickPlace.


2.8 The QuickPlace Administration UtilityThe QuickPlace Administration Utility is a tool for helping to administer and maintain the QuickPlace environment in your organization.

The QuickPlace Admin Utility allows system administrators to easily manage QuickPlace servers or individual QuickPlaces. The administrator can view QuickPlaces or server statistics, and take action or enter any QuickPlace.

2.8.1 System requirementsTo install and set up the Admin Utility, you will need the following components:

� QuickPlace Release 2.0.8 installed on Microsoft Windows NT 4.0.

� Microsoft Internet Explorer 4.0 or above. (Netscape Navigator is not supported in Release 2.0.8 of the Admin Utility.)

The Admin Utility can be used on a stand-alone QuickPlace server or on a QuickPlace server installed as an overlay to a Domino Release 5.0.8 server.

You can install the Admin Utility on an IIS server. However, you will need to perform a preliminary installation procedure. Information about this procedure is provided at the end of this section.

The server on which you choose to install Release 2.0.8 of the Admin Utility can be different from the one that was used for the Beta version, or it can be the same server. However, if you use the same server for Release 2.0.8 that you used for the Beta, you must manually uninstall the Beta Admin Utility from that server before installing Release 2.0.8, as upgrading from the Beta version to the 2.0.8 version of the Admin Utility in not supported. Instructions for uninstallation are provided later in this section.

2.8.2 Installation and setup overviewThis section describes what happens during the installation and setup of the Admin Utility.

The setup application of the Admin Utility is responsible for:

� Installing files required by the Admin Utility.

Note: The Admin Utility Release 2.0.8 is compatible only with QuickPlace Release 2.0.8. If you are running a version of QuickPlace that is not Release 2.0.8, you will need to upgrade your QuickPlace server to 2.0.8 before you can install the Admin Utility Release 2.0.8.


� Editing the notes.ini configuration file.

� Modifying the Names.nsf database.

� Editing the system’s PATH environment variable.

The details of the process are as follows:

1. Install files required by the Admin Utility.

The setup application installs the components into the specified directories. See Table 2-1 for a list of sample directory locations and components.

Table 2-1 Installed components

2. Edit the notes.ini configuration file.

The setup application edits your server’s NOTES.INI file and adds the following line:

QuickPlaceModules=nQuickPlaceAdmin.dll

If you already have a “QuickPlaceModules” entry in the NOTES.INI file, setup will add nQuickPlaceAdmin.dll to the end of the list. For example:

QuickPlaceModules=qphook.dll,qpcustominvite.dll,nQuickPlaceAdmin.dll

3. Modify the Names.nsf database.

The following changes are made to NAMES.NSF automatically when the Admin Utility is installed:

– Group “QPAdminUtility”

• Stand-alone server: Group “QPAdminUtility” is created. The QuickPlace Administrator name is added to this group automatically.

• Overlay server: Group “QPAdminUtility” is not created.

– A file protection document and a realm document are created to protect the nQuickPlaceAdmin.exe program from unauthorized access. These documents can be found in the Server, Web Configurations view.

Directory Directory location example Files installed

Data Directory d:\quickplace\data\AdminUtilityord:\lotus\domino\data\AdminUtility

QPAdmin.nsf

Program Directory

d:\quickplaceord:\lotus\domino\data

nQuickPlaceAdmin.dllnQuickPlaceAdminrs.dllnQuickPlaceAdmin.exe

CGI-bin Directory

d:\quickplace\data\domino\cgi-binord:\lotus\domino\data\domino\cgi-bin

nQuickPlaceAdmin.exe


4. Edit the system’s PATH environment variable.

The QuickPlace program directory is added to the system PATH environment variable so that the Admin Utility CGI program can properly locate the QuickPlace DLLs that it needs. This editing is done automatically by the Admin Utility setup program. Because the PATH environment variable is modified, you will be prompted to reboot the machine after setup is complete.

2.8.3 Installing the Admin UtilityPerform the following steps to install the QuickPlace Admin Utility:

1. Shut down the QuickPlace server.

2. Locate the Admin Utility installation directory on the CD and run Setup. The setup application will prompt you for the name of your QuickPlace program directory (for example, d:\quickplace).

3. During setup, if this is a stand-alone installation, the QuickPlace server administrator who installed the QuickPlace server will automatically be added as administrator of the Admin Utility. If this is an overlay installation, the user is prompted for a user name or group name during installation. The username specified here needs to be an existing administrator of the Domino server. An administration group can also be entered, in which case the group name checkbox should be used.

4. Setup will prompt you to reboot your server. After rebooting, restart the Domino Server for an overlay installation. The QuickPlace service is automatically restarted on reboot for a stand-alone installation.

5. If you have installed the Admin Utility successfully, you see a dialog box confirming this and showing the URL for the Admin Utility, as shown in Figure 2-13 on page 35.

Note: Create this group manually if it does not already exist in the Domino server’s Name and Address Book.


Figure 2-13 The Admin Utility has been successfully installed

6. To start using the Admin Utility, type the following URL into a browser:

http://servername/AdminUtility/QPAdmin.nsf.

You will be prompted for a user name and password. For stand-alone servers, use the QuickPlace administrator’s user name and password. For overlay configurations, use the user name (or member of the group) specified during install. You can see the Admin Utility in your browser, as shown in Figure 2-14 on page 36.


Figure 2-14 QuickPlace Admin Utility

Installing the Admin Utility with Microsoft IISIf your QuickPlace server is installed on an IIS server, you will need to do the following before installing the Admin Utility:

1. Stop the IIS service.

2. If you are using QuickPlace for IIS with single sign-on using the NTLM, you need to be sure that all members of the QPAdminUtilityUsers group in the Domino Directory (names.nsf) have usernames that correspond to their NT usernames.

NTLM is one of the authentication mechanisms for Windows NT 4.0 based on a challenge/response mechanism. It might also be in use in Windows 2000 Server or Windows XP installations, for example if such an environment has workstations using NTLM for authentication. NTLM authentication is most useful in an intranet environment, where the client and server machines are in the same, or trusted domains, and therefore it is not so commonly used.

For example, if Joe Smith has a Notes ID in the “CorpSales” domain and an NT user account in the “SALES” NT domain, the Username field in Joe Smith’s Person document needs to contain:


– Joe Smith/CorpSales

– SALES\Jsmith

This allows Domino to authenticate the NT user SALES\JSmith as the Domino user Joe Smith/CorpSales. Stand-alone QuickPlace users who do not have a Notes client can use the browser to edit names.nsf (http://servername/names.nsf).

For stand-alone QuickPlace/IIS server configurations that are not using single sign-on, you need to do the following in order to access QPAdmin.nsf:

1. In the Microsoft Management Console, right-click Default Web Site and select Properties.

2. Click the Directory Security tab.

3. In the “Anonymous Access,” or first, section, click Edit.

4. Uncheck the item labeled “Windows NT challenge/response (IISv4)” or “Integrated Windows Authentication (IISv5).”

5. Click OK.

6. Restart the Default Web Site.

Uninstalling the Admin UtilityTo uninstall the Admin Utility, either Beta or Release 2.0.8, use the following steps:

1. Set Super User to No Super User.

2. Delete the AdminUtility subdirectory, including the file QPAdmin.nsf.

3. Remove the cgi-bin file: data\domino\cgi-bin\nquickplaceadmin.exe

4. Remove nQuickplaceAdmin from the notes.ini QuickPlaceModules setting. Do not remove the QuickPlaceAdmin= line which defines the server administrator login.

5. In the Domino Directory (names.nsf file), remove the File Protection Document and the Realm Document for the Admin Utility. See Figure 2-15 on page 38 for details. They are located under Server -> Web Configurations. Locate the server under Web Configurations and then delete the documents for that server of type:

a. “Access to <serverpath>\Data\domino\cgi-bin”

b. “Realm for <serverpath>\Data\domino\cgi-bin”


Figure 2-15 Deleting documents related to Admin Utility

6. Remove the QuickPlace program directory from the Windows NT Path.

2.9 SummaryIn this chapter we have discussed briefly how to plan for a QuickPlace installation, what the system requirements are, and what do you need to consider before installation. We have shown you how to install the QuickPlace server, both as a stand-alone installation and as an overlay install over a Domino server.

In this chapter we also have given step-by-step instructions how to take a QuickPlace offline and install necessary components. We have also shown how to install the QuickPlace Admin Utility.

Attention: Do not delete the documents ending in \adm-bin. This is the first document shown in the view in the Figure 2-15.


Chapter 3. Directories and authentication

As organizations evolve, expand, or merge, having one central directory for user management and messaging is unlikely. Large organizations can have many different directory products in place; combining these products can be troublesome and entail hours of time-consuming support. Consolidating several diverse products can cost thousands of dollars in support, training, and down-time.

QuickPlace provides administrators with the ability to use existing directories for user lookups when adding QuickPlace members. If your organization already has a user directory in place, it provides the added benefit of one central location for managing users.

In this chapter we briefly introduce you to the Domino Directory as well as to the overall QuickPlace architecture.

We look at how to configure QuickPlace to use existing directories for user lookup and authentication. We then provide you with a high-level overview of what is involved with QuickPlace authentication and all the steps it takes when users log on.

3


3.1 The Domino DirectoryThe Domino Directory is the central store for directory information (such as information on users, servers, and applications), used by Domino servers and by clients accessing applications and services hosted on those servers within a Domino domain. The Domino Directory is physically a Domino database on the Domino server. The first server in a domain creates the first instance of the Domino Directory as it is initially installed. Each subsequent server in the same domain creates a replica copy of this same directory as part of its installation process. A replica is a fully functional copy of the original database. These copies will be kept synchronized through periodic replication across the domain, providing a robust and distributed directory architecture.

The following roles and functionalities are supported by the Domino Directory services:

� A domain configuration store and centralized point of domain management

All certificates, connections, cross certificates, server configurations and domain documents are maintained in the primary Domino Directory. This enables easy domain administration as the administrators just need to update the details in the Domino Directory in a single Domino Directory in the domain.

� Username lookup and resolution service using the Domino Directory services

Type-ahead functionality and name resolution are provided by any combination of primary and secondary Domino directories, server and user Directory Catalogs, and Directory Assistance.

� User authentication and authorization using the Domino Directory services

Non-Notes users are authenticated using the Domino Directory.

� Domino Directory services as a user information store and central point of information management, for example user phone numbers and address details

� Referral services to other directories from the primary LDAP directory

The Domino Directory is at the core of Domino architecture. This database (names.nsf) is a directory of services that provides a robust capability to act as either the center of an enterprise directory infrastructure or as a peer directory in a multi-directory environment.

QuickPlace is able to fully leverage the Domino Directory as a central location for user authentication and management.


3.2 QuickPlace integration with DominoWhen planning to implement QuickPlace, one of the decisions facing organizations is whether to integrate QuickPlace into the existing Domino Domain, give QuickPlace its own separate domain, or create a new one.

The result will vary from one organization to another since there are a number of factors to consider. There is no definitive solution; it will be a subjective decision that will vary from one organization to another depending on internal policies and procedures.

In mixed Domino release environments, the Domino Directory that QuickPlace is referencing must be using the R5 design template. Although QuickPlace does not affect the design of the Domino Directory, there are a number of views that QuickPlace needs to perform lookups. Specifically, it uses the following views:

� $LDAPCN

This hidden view shows all entries with the first column as the common name component that is exposed via the Domino LDAP implementation. This view only shows one row for each names.nsf entry. This view is used for lookup when adding users to QuickPlace.

� $Users

This view shows many instances of a name. QuickPlace uses this view to retrieve user and group member information and for retrieving information for a particular external user or group.

We recommend that you install QuickPlace into the existing organization, so that the same certifier file is used for both QuickPlace and Domino users. This means administering security is easier since all signatures will be uniform, with no need to cross-certify.

Once implemented, QuickPlace usually becomes very popular, very quickly, so it is important to make the right decisions when planning since QuickPlace is likely to grow exponentially.

Note: QuickPlace needs to have sufficient access in the Domino Directory to create groups: QuickPlace creates an h_Members group for every place on the server. This group contains a list of all the members of the place with their full hierarchical names. These groups are used for lookups and for generating names used when authenticing QuickPlace users. For example, if a QuickPlace called Collaborado is created, there is a a corresponding group created in the Domino Directory called h_members/Collaborado/QP/CMC. For more detailed information about authentication, refer to 3.5, “QuickPlace authentication” on page 55.

Chapter 3. Directories and authentication 41

3.2.1 QuickPlace integrated into the Domino domainThe main benefit of configuring QuickPlace to use the existing Domino domain is having only one central location for managing users and servers. Before you implement this, you need to consider the following:

� Single point of failure

If there is reliance on a single directory by several products, by many users, and by many tasks, you need to consider the impact on the organization should that single directory fail for any reason.

� Security

QuickPlace needs to access a number of views to perform user lookup and authentication. You need to know if there are any policies in your organization that restrict access to the Domino directory because this will hinder integration.

� Groups

QuickPlace creates an h_members group for every place on the server. If the Domino Directory is also used for Notes mail, these groups will appear in address dialogs when users perform name searches. You need to determine whether this is going to cause issues with users at a later date.

3.2.2 QuickPlace in a separate Domino domainThe main reason for implementing a separate Domino domain for use just by the QuickPlace server is to remove some of the potential problems identified previously.

As with the integrated solution, before you implement this you need to consider the following points:

� Administration

Having a separate domain for QuickPlace increases the number of administrative tasks since there are now two directories in the organization to administer. This includes mail, server, and user configurations.

� Users

Users from the primary Domino Directory will need to be recreated in the QuickPlace directory. There are several ways this can be done: manually (copying the person documents), automatically (creating an agent on the primary address book that copies the person documents), or by the users themselves (having the users self-register using a registration program such as the Domino Web Registration database).


3.3 Directories and QuickPlaceOnce you have planned how QuickPlace is going to integrate with the chosen directory, you need to configure Quickplace to use this directory. The directory types available for authentication and lookups are defined within the QuickPlace server main screen. To change the directory type, follow these steps:

1. Go to the QuickPlace server’s main screen (the Welcome screen).

2. Click Sign In and enter the ID and the password of the QuickPlace server administrator.

3. Select Server Settings then click User Directory.

4. Click the Change Directory button at the bottom right.

5. Select the desired directory from the choices available, as shown in Figure 3-1.

6. Provide server names as required.

Figure 3-1 Changing the user directory for the QuickPlace server

The QuickPlace server supports four directory types:

� Microsoft Windows NT

QuickPlace members are added from the NT domain; users are authenticated using their current NT password.


� LDAP Server

One of the benefits of using an LDAP server for QuickPlace is that members can be added and authenticated using any internal or external LDAP-compliant directory, such as the Domino Directory, Netscape’s iPlanet or Microsoft’s Active Directory.

� Domino Server

QuickPlace members can be added from any existing Domino Directory within the current domain or an external Domino Domain. QuickPlace users are authenticated using their current Internet password contained within their person documents. When accessing Domino domains outside of the current organization, ensure that the QuickPlace has a cross-certificate in common.

� (No Directory)

No directory is commonly referred to as “local.” With this option, each QuickPlace member is manually created and added to each individual place. There is no central location for managing these users. This directory type is only recommended for test environments.

3.4 Integrating QuickPlace with other directoriesIn this section we show you how to configure QuickPlace to integrate with other directories for user lookup and authentication. We describe how to configure QuickPlace with:

� An external LDAP-compliant directory, using iPlanet in our scenario

� An LDAP-compliant directory and an additional external Domino organization and domain

� Secure LDAP

� Microsoft’s Active Directory

Note: For clustered QuickPlace servers, you have to apply any directory type changes to each server individually for these changes to take effect. Administration configuration settings for a QuickPlace server are contained within the admin.nsf database in the QuickPlace subdirectory. This database is not a replica copy across clustered QuickPlace servers. More details about implementing a QuickPlace server cluster are in Chapter 5, “Availability with clustering” on page 89.


3.4.1 Using Directory Assistance for secondary directoriesDirectory Assistance is a feature that enables users and servers to locate information in a directory that is not a server's primary Domino Directory. You can set up Directory Assistance for secondary Domino directories and for LDAP directories.

QuickPlace can be configured to use other directories for user lookup and authentication using Directory Assistance. The secondary directory can be an LDAP-compliant directory or a Domino Directory in another domain; you can have one type or several different directories configured for this purpose in Directory Assistance.

In this section we look at what is required to configure an LDAP directory as a secondary directory for authentication. The detailed steps that follow walk you through the procedures. This would be the same if you wanted to do a lookup on another Domino Directory in another domain in addition to your current domain. You may skip the steps your server is already configured with.

Before we describe the details, here is a high-level view of the configuration steps:

1. Create a Directory Assistance database.

2. Create entries in the Directory Assistance database.

3. Create replica copies of the Directory Assistance database on all QuickPlace Servers.

4. Identify the Directory Assistance database in each server document.

5. Set the QuickPlace User Directory type to Domino Server.

Step 1: Create the Directory Assistance databaseThe Directory Assistance database is not created during the Domino installation process—you will need to manually create and configure it. The step-by-step procedures to create the Directory Assistance database are as follows:

1. Select File -> Database -> New.

2. In the New Database dialog box, as shown in Figure 3-2 on page 46, specify the Domino server where QuickPlace is installed.

3. Define a title and filename for the database. In our example we chose Master Directory as the title and da.nsf as the filename.

4. Select the Directory Assistance template (da50.ntf), which is an advanced template on the server. To do this, click the Template Server button, select your Domino server and check Show Advanced templates. See Figure 3-2 for details.


5. Click OK.

Figure 3-2 New Directory Assistance database dialog box

Step 2: Create an entry in the Directory Assistance databaseIn the newly created Directory Assistance database, you need to create a document for each secondary directory used for user lookups and authentication. Follow these step-by-step procedures:

1. Open the Directory Assistance database on the server.

2. To create the new Directory Assistance document, click the Add Directory Assistance action button.

3. Under the Basics tab, set the following parameters (see examples in Figure 3-4 on page 48):

– Domain type: LDAP

– Domain name: Enter the unique LDAP domain name

– Company name: Enter the company name to identify the document

– Search order: A number representing the order in which this directory is searched, relative to other directories in the Directory Assistance database.

– Group expansion: Group expansion can be enabled only for one LDAP directory. Set the Enabled field to Yes.


Figure 3-3 Basics tab of the Directory Assistance document

4. Switch to the Rules tab. This feature allows you to specify one or more naming rules that correspond to the hierarchical names of entries in the directory. Directory assistance uses naming rules to determine the order in which to search directories when users provide hierarchical names and there are multiple directories configured in directory assistance.

5. Consider the case where you set up directory assistance to refer LDAP clients that use the Domino LDAP service to another LDAP directory. When a client provides a search base that is a distinguished name representing the branch of a directory tree to search, if an LDAP Directory Assistance document is configured for referrals and contains a naming rule that matches the specified base, then directory assistance refers the client to that LDAP directory if secondary Domino directories don't satisfy the search. For more information on the configuration rules refer to the “Setting up Directory Assistance” in the Domino Administration Help database (help5_admin.nsf).

6. Switch to the LDAP tab. This tab defines characteristics about the LDAP server. Set the following parameters:

– Hostname: Enter the hostname of the LDAP server.

– Optional Authentication Credentials: If the LDAP server does not allow anonymous access, you will need to provide a username and password to authenticate. Contact the LDAP administrator for any login details.

– Base DN for search: Some LDAP servers require a suffix; use the base DN field to denote that.

– Perform LDAP search for: Select both boxes to allow searching.


– Channel encryption: Specify whether SSL is enabled. Choose SSL to use SSL when the Domino server connects to the LDAP directory server in order to verify the server's identity.

– Define the port and timeout interval for the chosen option; refer to Figure 3-4.

.

Figure 3-4 The LDAP tab of the Directory Assistance document

7. Save and close the document.

Step 3: Create replica copies of the Directory Assistance database

This is necessary because of the way QuickPlace refers to the directories for authentication. When an authentication request is made, the QuickPlace server uses local Domino authentication code. This code will call the Domino server to determine how to perform the authentication. It detects there is Directory Assistance in place and reads the Directory Assistance documents. When the server finds an LDAP document, it will try to make a connection using the local LDAP connection information; if it cannot locate this information, it will fail.

Important: For user authentication with a secondary LDAP directory to be successful, you must create a replica copy of the Directory Assistance database on all QuickPlace servers in the Domain or cluster.


Step 4: Identify the Directory Assistance database in the server document

To set up each QuickPlace server to use directory assistance, you need to define the Directory Assistance database in each server document. You can either manually enter the database name in each server document or get the Administration Process to set the filename on multiple servers.

1. Ensure the Administration Process is set up and configured.

For more information on the Administration Process and how to configure it, refer to the Domino Administration Help database (help5_admin.nsf) in the Help sub-directory on the Domino server. From the Contents view of this database, select Administration Tools -> The Administration Process. There are several documents in this section that will help you define, set up and configure it.

2. Launch the Domino Administrator and select the Domino domain from the lower computer icon on the left toolbar.

3. Switch to the Configuration tab.

4. Select Server -> All server documents.

5. Highlight the server documents and select Actions -> Set Directory Assistance Information.

6. Enter the Directory Assistance filename you created earlier in the dialog box. The database needs to be relative to the Domino\data directory; include any sub-directories as required.

Figure 3-5 Defining the Directory Assistance database in the server document

7. Click OK.

8. Switch to the Administration server console. Enter: Tell Adminp Process All. This console command will process any pending administration request in the Administration Requests database (admin4.nsf).

9. Replicate the Domino Directory with all other servers in the domain.


Step 5: Set the QuickPlace User Directory type to Domino Server

You now have to define the directory type the QuickPlace server will use for authentication and lookups. Follow these steps to change the directory type:


2. Click Sign In and enter the ID and the password of the QuickPlace server administrator.

3. Select Server Settings then click User Directory.

4. Click the Change Directory button on the bottom right.

5. Select the Domino Server.

6. Enter the Domino Server name in the field below.

3.4.2 Directory Assistance, LDAP, and external Domino domainIn this section we look at what is required to configure QuickPlace with an LDAP-compliant directory, and an external Domino organization and domain, as secondary directories for authentication. The procedures for creating and configuring the Directory Assistance database are the same as those covered in the previous section, so the details of these steps are not repeated here. We used the scenario of Cambridge Motor Company wanting to access Cambridge Auto Parts’ Domino Directory so users can be added and autenticated to QuickPlace.

1. Cross-certify both organizations.

2. Create a Directory Assistance database.

3. Create an entry for each directory in the Directory Assistance database.

4. Create replica copies of the Directory Assistance database on all QuickPlace Servers.

5. Identify the Directory Assistance database in each server document.

Tip: There are some useful notes.ini commands to help you when configuring LDAP:

� INET_AUTHENTICATE_WITH_SECONDARY=1

This notes.ini command forces the Domino server to authenticate through Directory Assistance with an LDAP Directory.

� LDAPDEBUG=15

This notes.ini command logs all LDAP connections on the server console.


6. Set the QuickPlace User Directory type to Domino Server.

Step 1: Cross-certify both organizationsWhen Domino servers communicate, the first thing that happens is they try to authenticate. Domino authentication compares certificates to verify whether the servers have a certificate in common each party trusts. If they are not from the same organization, they will need a cross certificate. Cross-certification is the process of exchanging Notes certificates to generate a certificate in common that will allow two organizations to authenticate. You can authenticate at various levels of the organization, you need to determine this with the administrator from the other organization. There are a number of methods available for cross-certifying. For this example, we used the exchange of safe.ids.

For more information on the other ways to cross-certify, refer to the Domino Administration Help database in the Help sub-directory on the Domino server. From within the Contents view of this database select Security -> Domino server and Notes user IDs -> Adding Cross-Certificates to the Domino Directory or Personal Address book.This document lists all the methods available to cross-certify.

1. From the Domino Administrator, select Configuration -> Tools -> Certification -> ID Properties.

2. Locate the QuickPlaceCert.id and click Open.

3. Enter the password for the certifier.

4. In the User ID dialog box, select More Options.

5. Click Create Safe Copy.

6. Give the safe copy ID file a name and click Save.

7. Give this safe copy file to the administrator in the other organization. They will give you the safe.id for the level in their organization.

8. From the Domino Administrator, select Configuration -> Tools -> Certification -> Cross-certify.

9. In the Choose Certifier ID field, select the QuickPlaceCert.id and enter the password.

10. In the Choose ID to be cross-certified field, select the safe ID the administrator in the other organization sent you.

11.In the Issue Cross Certificate dialog, specify your server, not local. Cross-certificates reside in the Domino Directory on the server.

12.Click Cross-certify.


13.Once the administrator in the other organization has completed the same procedures you will be able to authenticate with the other organization and perform lookups and user authentication on that domain.

14.Create a connection document on the source server to define the route and and network information necessary to allow it to connect to the destination server.

Step 2: Create the Directory Assistance databaseRefer to “Step 1: Create the Directory Assistance database” on page 45 for details on how to create the Directory Assistance database.

Step 3: Create entries in the Directory Assistance databaseIn the Directory Assistance database, create a document for the external organization’s Domino Directory. Follow these steps:

1. Open the Directory Assistance database on the server.

2. Click the Add Directory Assistance action button.

3. Under the Basics tab, set the following parameters:

– Domain type: Notes

– Domain name: Enter the Domino domain name

– Company name: Enter the company name to identify the document

– Search order: A number representing the order in which this directory is searched, relative to other directories in the Directory Assistance database.

Figure 3-6 The Directory Assistance document for a Domino Directory


4. Switch to the Rules tab, where you can specify one or more naming rules that correspond to the hierarchical names of entries in the directory. Directory assistance uses naming rules to determine the order in which to search directories when users provide hierarchical names and there are multiple directories configured in directory assistance.

5. Switch to the Replicas tab and specify the location and file name of the Domino directory you will be using. You can have one or several entries for failover purposes. Refer to Figure 3-7.

Figure 3-7 Configuring the Directory Assistance document Replicas tab

Steps 4 through 6 Refer to 3.4.1, “Using Directory Assistance for secondary directories” on page 45 for details on how to create and configure the Directory Assistance database.

3.4.3 QuickPlace, Directory Assistance, and LDAP over SSLFor organizations that want to keep access to data secure, accessing directory members are no exception. To do this the QuickPlace server needs to communicate to the LDAP directory server securely, using SSL.

One of the caveats of doing this is that QuickPlace does not support encrypted communication directly to an LDAP server over SSL, only non-encrypted insecure communication. A secure encrypted connection is only available if you use Directory Assistance. The QuickPlace server and LDAP server are then able to talk to the Directory Assistance database securely using SSL.


For secure LDAP to work successfully, your Domino server that hosts the Directory Assistance database must have an SSL certificate in common with the LDAP server.

Section 3.4.1, “Using Directory Assistance for secondary directories” on page 45 outlines the procedures for configuring your server to use an LDAP-compliant server as a secondary directory. When creating the Directory Assistance document, under the LDAP tab, set Channel encryption to SSL, as shown in Figure 3-8. This will enable SSL communication from Directory Assistance to the LDAP server.

Figure 3-8 Configuring Secure LDAP in the Directory Assistance document

To ensure the connection is encrypted from QuickPlace to the Directory Assistance server, enable SSL by following these configuration steps:


2. Click Sign In and enter the administer ID and password.

3. Select Server Settings -> Security.

4. Check the option: Use SSL at the bottom of the screen, as shown in Figure 3-9 on page 55.


Figure 3-9 Configuring SSL for Quickplace

3.4.4 QuickPlace and Active DirectoryQuickPlace can be configured for user lookup and authentication with Active Directory. Active Directory is an LDAP-compliant directory and you can configure QuickPlace to use Active Directory both on standalone and overlay installations.

With the standalone installation, you can configure QuickPlace to use Active Directory just like any other LDAP Server.

If you have an overlay installation, configure QuickPlace server to use Active Directory with Directory Assistance. The Directory Assistance database needs a secure LDAP entry that does a lookup to the Active Directory server. To create the configuration refer to 3.4.1, “Using Directory Assistance for secondary directories” on page 45

3.5 QuickPlace authenticationIn this section describe how QuickPlace does authentication, the procedures it follows and features it uses to allow users to log in.

There are three authentication models used in QuickPlace:


� Basic authentication

� Single Server, Single Session Sign on (SSO)

� Multi-Server, Single Session Sign on (MSSSO)

3.5.1 Basic authenticationQuickPlace authentication is similar in concept to default Domino Web authentication. Default Domino Web authentication uses a username and password held in the user’s person document in the Domino Directory to verify the user. QuickPlace utilizes a lot of this pre-existing Domino authentication, but it also has it’s own .dll file that manages all QuickPlace requests.

If there is no anonymous access to a place, the user is prompted for their username and password stored in the contacts1.nsf database based on their membership information. QuickPlace uses the DSAPI filter built into the product to validate the user. The Domino Web Server Application Programming Interface (DSAPI) is a C API which lets you write your own extensions to the Domino Web Server. For example, you can customize how users get authenticated.

QuickPlace is effectively a DSAPI application for Domino: all authentication requests are passed through this application.

Basic authentication varies depending on whether you are using a local directory or secondary directory. The following sections discuss these option in detail.

Local directoriesUsers whose QuickPlace is configured for Local directories are authenticated in the following steps:

1. If there is no anonymous access to the place, the user is prompted for their username and QuickPlace password.

2. QuickPlace looks in a cache to see whether the user has been previously authenticated for the current session.

3. If not, it opens the Contacts1.nsf database and looks for the user.

4. It finds the user based on their common name (CN), for example Emma Green.

5. It compares the password the user has entered with the password stored in the contacts database.

6. A distinguished name is generated and added to the names list; this list contains the distinguished name and the groups the user is a member of.

7. This user information is added to the user cache so that it can be used by other places during the current session.


The length of time this information is held in the user cache can be configured from within the server document. From within the server document, select Internet Protocols -> Domino Web Engine. Edit the Garbage Collection interval field at the bottom left of the screen to define how long you want this user cache information retained.

External directoriesQuickPlace can be configured to authenticate users either from an LDAP-compliant secondary directory or simply by accessing the organization’s Domino Directory. In both cases, the authentication process will be done by the following steps:

1. If there is no anonymous access to the place, the user will be prompted for their user name and password.

2. Each member document in the contacts database has an h_alias field that contains the distinguished name of the user as referenced in the secondary directory.

3. QuickPlace takes this alias and presents it to the directory server to verify it.

4. The directory server authenticates the user based on this information. As with local authentication, the name is placed in the server cache so it can be reused and the user does not have to keep entering their details for the current session.

5. QuickPlace searches and checks all group information to try and find the user. Group authentication is based on the user’s common name; all users with the same common name are listed and a match is found for the name and password entered.

6. Once a match has been found the lookup quits. Based on this information a distinguished name is created and stored in the user cache. QuickPlace then builds a list of all the external groups the user is a member of and stores that information in the user cache to be referred to for the current session.

3.5.2 Single server, Single session sign-on (SSO)Single session sign-on is the ability for the user to sign onto one server, once with their browser, and have several applications recognize that one-time login and authentication. This saves the user having to re-enter their details. The Single sign-on functionality is provided by the Domino server.

The procedure for SSO is as follows:

1. SSO is configured on the Domino server. When the user logs in to the application, Domino displays a customized form to the user. This looks the


same as the standard username and password dialog users will be familiar with. The user enters their username and password.

2. Domino looks at this information and creates a “session cookie.” This cookie uses Lightweight Third Party Authentication (LTPA), often referred to as a “token.”

3. As with local user authentication, Domino verifies the information entered based on where the username and password information is stored, for example in an external directory.

4. Domino takes the username, password, date time string, encrypts it and writes it to the user cache. Every time an application that supports SSO requests the information, the browser presents it to the application and it trusts it unconditionally. This cookie is stored in the browser memory and not written to any standard disk cookie cache. To remove the cookie, simply close all browser sessions and restart the browser.

3.5.3 Multi-server, Single session sign-on (MSSSO)In this scenario, there are several servers that all support SSO and the user logs on to one server once. As with SSO, when the user logs on to a server, an LTPA cookie is created in the browser and encrypted. When the user goes to another server the browser presents this cookie and the server just trusts it.

In order for multi-server, single session sign on to be successful, each server must be configured for SSO so that the other servers know that the LTPA cookie can be trusted.

3.6 SummaryIn this chapter we have discussed the basic architecture of QuickPlace. We described how to configure QuickPlace server to use different available directory options, which are no central directory, Domino Directory, external LDAP directory and Microsoft NT user directory. Step-by-step instructions for implementing directory connection were given.

Last, we described how QuickPlace server performs user authentication. Both basic authentication as well as single sign-on scenarios were discussed.

Note: In order for authentication to be successful, your browser must be able to accept cookies. Check your browser privacy settings to see whether Cookies are restricted.


Chapter 4. Security

Security is a top priority for many IBM customers. Implementing a solution that satisfies the end users’ requirements while maintaining a secure application infrastructure can prove to be a very challenging endeavor. Understanding how QuickPlace’s underlying security architecture works and how to configure it to meet your company’s needs is essential to a successful deployment.

This chapter includes information about how QuickPlace security works and discusses important considerations and strategies for implementing a secure QuickPlace environment. We also discuss how to install and configure security options on your QuickPlace servers.

4


4.1 Overview of Domino securitySince the QuickPlace security model is based on the Domino security model, it is beneficial to understand some basic Domino security features. Domino security is hierarchical, so a user must pass through the first level of security to get to the next level. If you want to learn about Domino security in more detail, refer to the redbook Lotus Notes and Domino R5.0 Security Infrastructure Revealed, (SG24-5341).

4.1.1 Server accessServer-level access is the first level of Domino security. Server access is configured in the Security section of the Server document in the Domino Directory. A basic level of security for Web browsers can be achieved by simply turning off Anonymous access to the Domino server, as shown in Figure 4-1, and disallowing Web client access to browse the file system. This forces the user to authenticate with the Domino server when they attempt to access any database on the server.

Figure 4-1 The setting for anonymous access


For Notes clients, there are two server access lists: “Deny Access,” which lists users or groups who will explicitly be denied access to the server, and “Allow Access,” which lists groups and users allowed access. The “Deny Access” list will always supersede the “Allow Access” list. In other words, if a name is in both the “Deny Access” and “Allow Access” lists, the user will be denied access to the server. These lists can be found in the Server Access table of the Server document’s Security tab.

Since Notes clients are rarely used to access QuickPlace databases (except in some cases by administrators or developers), Notes client access levels do not have much bearing on QuickPlace security.

4.1.2 Database accessDatabase-level access is implemented with the use of Access Control Lists (or ACLs) in the individual Domino databases. The ACL contains lists of users, servers, and groups with specific access levels. The access levels from least to most access are: None, Depositor, Reader, Author, Editor, Designer, and Manager. Generally speaking, Web users usually have Reader or Author access. Higher levels of access are usually reserved for users accessing the Domino server using a Notes client.

4.2 Overview of Web securityQuickPlace is a Web-based application. A good understanding of the basic concepts of Web security is essential to understanding the different options for QuickPlace authentication and security configuration.

4.2.1 AuthenticationWhen users access a Domino server with a Notes client, they are using Notes ID files for authentication. Accessing a Domino Web application, with a Web browser, there is no ID file available. Users authenticate against the Domino server with name and password only. The most commonly used authentication option, basic name-and-password authentication, requires a person record in the Domino Directory or secondary directory configured by means of Directory Assistance, containing the user’s name and an Internet password.

Chapter 4. Security 61

4.2.2 SSLSecure Sockets Layer, or SSL, is the standard Internet protocol for secure communications. The SSL protocol is a type of sockets communication and is typically used between server and client to secure the connection. It protects the data link between a Web browser and a server, so that the data cannot be intercepted during transmission.

SSL uses digital certificates to verify the identity of the parties involved in data transmission over the internet. Digital certificates facilitate the public key exchange that is required to establish an SSL connection. In other words, a digital certificate is like an “identification card” that is used by a server to prove that it is who it says it is.

Digital certificates are issued by Certificate Authorities, or CAs. There are certain trusted CAs that most browsers will accept, such as those issued by VeriSign, for example. However, anyone with the proper type of software can be a certificate authority. Since most Web browsers contain a list of trusted certificate authorities, if a Web browser is presented with a digital certificate from a CA that it does not recognize, the browser will ask the user if they want to accept the certificate. Users can also specify other CAs to trust in their browser settings.

4.2.3 Virtual private networksA virtual private network (VPN) allows people to connect to a company’s LAN over a secure, encrypted connection. A VPN is a network that supports private data traveling over public IP network infrastructure such as the internet. VPN communications travel over the internet but are encrypted so that the data cannot be intercepted. The data is essentially encapsulated into a “tunnel,” allowing remote users access to the corporate network.

4.3 Securing your QuickPlace environment with SSLSince QuickPlace is a Web application, it is recommended that you secure your QuickPlaces using SSL. This section discuss how to configure and enable SSL on different types of QuickPlace installations, as well as other security variables such as browser support and third party certificates. In addition, we discuss securing different levels of your QuickPlace servers using SSL.

Note: SSL will increase the amount of network traffic.


4.3.1 Enabling SSL on QuickPlace serversThis section describes how to enable SSL on a QuickPlace server. Both installation options, standalone and Domino overlay, are described.

SSL on a standalone QuickPlace serverWhen you install a QuickPlace server and choose the “Use SSL” option (see Figure 4-2 on page 64), a self-signed server certificate is created for use with SSL. This allows the QuickPlace server to start up after installation ready to use SSL immediately, without any additional configuration. However, the server certificate created is not signed by an external certificate authority such as VeriSign. This means that browsers will display a warning about the server's certificate being invalid. These warnings do not affect the functionality of the QuickPlace application, and each QuickPlace user can avoid the warnings by instructing the browser to trust the QuickPlace server's certificate. This is necessary because a self-signed server certificate is created at the time of installation using the machine's TCPIP host name.

If your QuickPlace server was installed as a standalone server, use the following steps to enable SSL for QuickPlace.

1. Sign in to the QuickPlace as an administrator.

2. Select Server Settings on the sidebar.

3. Select Security on the sidebar.

4. In the section labeled “Do you want to use Secure Sockets Layer (SSL) encryption?” select Use SSL.


Figure 4-2 Enabling SSL for a QuickPlace server

5. Close the browser and restart the QuickPlace server.

SSL on a Domino overlay QuickPlace serverWhen you have an overlay installation of QuickPlace, you will need to configure the Domino server to use SSL in addition to performing the steps detailed in the previous section.

If you have installed your QuickPlace server as a Domino overlay, use the following steps to enable SSL for QuickPlace and Domino.

1. Set up the Server Certificate Admin application (CERTSRV.NSF), which Domino creates automatically during server setup. To do this:

a. In the Notes client on the Domino server, open a local copy of the Server Certificate Admin application (CERTSRV.NSF).

b. Edit the ACL as follows:

i. Add the names of server administrators who will access the Server Certificate Admin application from a Notes client or Domino Administrator client that is not on the local server machine. Assign


Manager access to these users. (You can skip this step if administrators are only going to access the Server Certificate Admin application locally on the server; local access will automatically grant them Manager access.)

ii. Set the Default entry in the ACL to No Access to prevent unauthorized users from accessing the database.

Figure 4-3 Setting the Default ACL entry to No Access

iii. Set the Maximum Internet Name & Password field to No Access to prevent unauthorized Web users from accessing the database. This can be found from the Advanced section of the ACL window.


Figure 4-4 Setting the Maximum Internet name & password to No Access

c. Open the Domino Administrator client. Click the Files tab, and open the Server Certificate Admin application.


Figure 4-5 Creating a key ring file

d. Click Create Key Ring.

e. Complete the fields on the Create Key Ring form shown in Figure 4-6 on page 68. The fields are described in Table 4-1.

Table 4-1 Fields on the Key Ring form

Field Value

Key Ring File Name A file name. The default file name is KEYFILE.KYR, but your key ring file name may be different.

Key Ring Password At least 12 characters. They are case-sensitive and can be alphanumeric.

Key Size The size Domino uses when creating the public and private key pairs. The larger the size, the stronger the encryption.

Common name The fully qualified domain name (FQDN) of the server. Most browsers check for a match between the FQDN and the host name before allowing authentication, so it is important to ensure that they are consistent.

Organization The name of the organization of the certificate owner (usually a company name).

Organizational Unit (Optional) The division or department of the certificate owner.


f. Click Create Key Ring.

Figure 4-6 Create Key Ring form

City or Locality (Optional) The city or town where the certificate owner resides.

State or Province Three or more characters that represent the state or province where the certificate owner resides. For U.S. states, enter the complete state name, not the abbreviation.

Country A two-character representation of the country where the certificate owner resides.

Field Value


g. Click OK when you are presented with the information about the new key ring file. Domino will create the key ring file and stash (.STH) file and place them in the Notes data directory on the machine used to create the key ring.

h. If you have created the key ring on a machine other than the Domino server, copy the key ring file and stash file to the Domino data directory on the server.

2. Request an SSL server certificate. You can request and obtain server certificates from a third-party Certificate Authority (CA), such as VeriSign. The server certificate is a binary file that contains a public key, a name, an expiration date, and a digital signature. It is stored on the server’s hard drive.

To request a server certificate from a third-party Certificate Authority:

a. Make sure that you have mapped a drive to the directory that contains the server key ring file that you created in the previous step.

b. From the Domino Administrator client, click the Files tab and open the Server Certificate Admin application.

Figure 4-7 Creating a certificate request

c. Click Create Certificate Request.

d. Complete the fields described in Table 4-2 on page 70.


Table 4-2 Fields on the Server Certificate form

e. Click Create Certificate Request.

Figure 4-8 Create Server Certificate form

Field Value

Key Ring File Name The name of the server key ring file, including the path to the file (for example, c:\domino\data\keyfile.kyr)

Log Certificate Request

Choose Yes to log information in the Server Certificate Admin application.Choose No if you choose not to maintain a log.

Method Choose Paste into form on CA’s site (recommended) or Send to CA by e-mail.VeriSign only accepts the paste option. If you are using another CA and choose “Send to CA by e-mail”, enter the CA’s e-mail address along with your e-mail address, phone number, and location.


f. Enter the password for the server key ring file.

g. If you selected “Paste into form on CA’s site” in step iv, copy the certificate to the clipboard, including the Begin Certificate and End Certificate lines. Then use a browser to visit the CA’s site and follow their instructions for submitting a request for a new certificate.

3. Merge the CA certificate as a trusted root. The server certificate needs to contain the CA certificate as a trusted root because the trusted root allows servers and clients that have a common CA certificate to communicate. Before you merge a server certificate signed by a CA, merge the CA certificate into your key ring file as a trusted root. To do this, perform the following steps.

Note: Before performing these steps, view the default trusted roots in the key ring file to make sure the third-party Certificate Authority’s certificate is not already included. If it is included, you can skip these steps.

a. Make sure that you have mapped a drive to the directory that contains the key ring file.

b. Go to the CA’s Web site and follow their instructions to obtain the CA’s trusted root certificate.

c. From the Domino Administrator, click the Files tab and open the Server Certificate Admin application.

Figure 4-9 Installing a trusted root certificate into a key ring


d. Select Install Trusted Root Certificate into Key Ring.

e. Enter the name of the key ring file that will store this certificate. This is the name of the key ring file that you specified in the server certificate request.

f. Enter the name that the key ring file will use to identify this certificate. Domino will use the distinguished name of the certificate if this field is left blank.

g. If you copied the contents of the CA’s certificate to the clipboard in step ii, choose Clipboard in the Certificate Source field. Paste the clipboard contents into the next field.

h. If you received a file that contains the CA’s certificates in step ii, detach the file to your hard drive and select File in the Certificate Source field. Enter the file name in the File Name field.

i. Click Merge Trusted Root Certificate into Key Ring.

Figure 4-10 Install Trusted Root Certificate form

j. Enter the password for the key ring file and click OK.

4. Ask the CA to sign the server certificate. This adds the CA’s digital signature to the certificate. Contact the third-party CA to find out their procedures for signing server certificates.


5. Merge the signed server certificate into the key ring file.

a. Make sure that the CA signed the certificate and that you have mapped a drive to the directory that contains the server key ring file.

b. Use the instructions provided by the CA to pick up the certificate. The CA will usually either send the certificate in an e-mail or send a URL for you to visit to obtain the certificate.

c. From the Domino Administrator client, click the Files tab and open the Server Certificate Admin application.

Figure 4-11 Installing a signed certificate into a key ring

d. Click Install Certificate into Key Ring.

e. Enter the file name for the key ring that will store the signed certificate. This is the name of the key ring file that you specified in the server certificate request.

f. If you copied the certificate to the clipboard, choose Clipboard in the Certificate Source field. Paste the clipboard contents into the next field.

g. If you received a file attachment that contains the certificate, detach the file to your hard drive and choose File in the Certificate Source field. Enter the file name in the File name field.

h. Click Merge Certificate into Key Ring.


Figure 4-12 Install Certificate into Key Ring form

i. Enter the password for the server key ring file, and click OK.

6. Configure the SSL port on the Domino server. You should configure the port to use server authentication only. To configure the SSL port, perform the following steps.

a. From the Domino Administrator client, open the Server document by clicking the Configuration tab, then clicking Current Server Document.

b. Click Edit Server. Then click the Ports tab, then the Internet Ports tab.


Figure 4-13 Enabling SSL for the Domino server

c. Complete the fields identified in Table 4-3.

Table 4-3 Fields on the Internet ports tab in the server document

Field Value

SSL key file The file name of the server key ring file. The key ring file must be located in the Domino data directory or in one of its subdirectories. Enter the key ring file name relative to the Domino data directory; for example, if the key ring file is in c:\Domino\Data\CMC\keyfile.kyr, you should enter \CMC\keyfile.kyr.

SSL protocol version Choose one of the options:V2.0 only will allow only SSL V2.0 connections.V3.0 handshake will connect via SSL 2.0 if the attempt to use

SSL 3.0 fails.V3.0 only will allow only SSL V3.0 connections.V3.0 and V2.0 handshake will attempt a V3.0 connection, but

will start with a V2.0 connection. Negotiated will attempt an SSL V3.0 connection first, then will

attempt to use V2.0 if the first attempt fails. This is the default setting.


d. Click the Web tab and complete the fields described in Table 4-4.

Table 4-4 Fields on the Web tab of Internet ports

4.3.2 SSL on different levelsYou can protect your QuickPlace environment with SSL on different levels.

Entire Domino serverYou can configure your entire Domino server to use SSL for all requests. This includes any non-QuickPlace requests that are sent to the server. To do this, follow the instructions in “SSL on a Domino overlay QuickPlace server” on page 64.

All QuickPlacesYou can configure your QuickPlace server to use SSL for all QuickPlace requests. This will not affect any non-QuickPlace related requests (such as Domino requests) if you do not have SSL enabled on a Domino overlay installation. To enable SSL for all QuickPlaces on a server, follow the instructions in “SSL on a standalone QuickPlace server” on page 63.

Accept SSL site certificates

Choose Yes to allow this server to accept the site certificate and use SSL to access an Internet server even if there is no common certificate between this server and the Internet server.Choose No to disallow site certificates.

Accept expired SSL certificates

Choose Yes to allows clients to access the server even if the client certificate is expired.Choose No to disallow clients with expired certificates access to this server.

Field Value

SSL port number Enter the port number on which this server will listen for SSL requests. The default port is 443. It is recommended that you keep the default port in this field.

SSL port status Choose Enabled to allow SSL connections on this port.

Client certificate Choose No to not use client authentication.

Name & password Choose Yes to use name and password authentication.

Anonymous Choose Yes to allow anonymous access.

Field Value


Individual QuickPlacesIf you do not want to configure your entire QuickPlace server to use SSL, you can configure individual QuickPlaces to use SSL.

To enable an individual QuickPlace to use SSL:

1. In the Notes client, open the MAIN.NSF database for the QuickPlace you want to enable for SSL. The MAIN.NSF database will be in a subdirectory of the QuickPlace directory on your server. For example, if you are looking for the MAIN.NSF directory for the Autos QuickPlace, it would be in the \QuickPlace\Autos directory.

2. Open the database properties by clicking File -> Database -> Properties.

3. In the database properties box, check the property “Web Access: Require SSL Connection” on, as shown in Figure 4-14.

Figure 4-14 Enabling SSL for an individual QuickPlace

Note: Enabling SSL on an individual QuickPlace will cause Offline services for that QuickPlace to stop working. This happens because when you set an individual QuickPlace to use SSL, it affects that QuickPlace’s database properties, which then get transferred to the offline version of the database. When the user attempts to access the offline database, they will be denied access because an SSL certificate will not be found on the local machine.


4. Close the Database Properties dialog box.

4.3.3 X.509 certificatesAt the time of this writing, QuickPlace does not support the use of X.509 certificates for client authentication. SSL is used for channel encryption only.

4.4 Logging users off QuickPlacesThe standard themes that are provided with QuickPlace do not include the ability to easily log off users. This is an important step in ensuring the security of your QuickPlaces. Many browsers store both logon credentials and private data in memory, typically up to 30 pages, which are not reliably discarded until the browser is closed. By logging off the QuickPlace and clearing their browser’s caches, each user can ensure that no one can access the QuickPlace with the user’s personal identity. There are a couple of options for logging users off when they have completed their work in their QuickPlaces.

4.4.1 Clearing the browser cacheYou can instruct your QuickPlace users to clear their browser cache when they close the browser window. However, the login credentials will remain cached while the browser session is still open. This leaves the workstation vulnerable if the user steps away before they clear the cache and close the browser window.

Clearing the browser cache manuallyTo manually clear the cache in Microsoft Internet Explorer 4.x and later:

1. On Internet Explorer, select Tools -> Internet Options.


Figure 4-15 Internet Options window

2. Click Delete Files.

Figure 4-16 Delete temporary internet files confirmation window

3. Click OK to confirm the deletion.

To manually clear the cache in Netscape Navigator 4.x and later:

1. Click Edit -> Preferences.

2. Select Advanced -> Cache.

3. Click Clear Memory Cache and Clear Disk Cache buttons to clear all memory and disk cache.

4. Click OK to close the Preferences dialog box.

5. Close the browser window.


Figure 4-17 Deleting cached files in Netscape Navigator

Clearing the browser cache automaticallyThere is an option to configure Internet Explorer to empty temporary internet files automatically. This can be enabled on Internet Explorer by selecting Tools -> Internet Options from the menu bar. Click the Advanced tab, as shown in Figure 4-18 on page 81, and check the option “Empty temporary Internet file folders when browser is closed.”


Figure 4-18 Empty temporary Internet file folders when browser is closed

After this is done, the browser deletes the files automatically every time the browser is closed.

4.4.2 Logout commandYou can use the Domino ?Logout command in your QuickPlace themes to force user logoff. You can do this in one of two ways: add the logout command to your QuickPlace themes, or add the logout command as a link page in an individual QuickPlace.

Logout command as a page in an individual QuickPlaceYou can use the Domino ?Logout command to add a logoff page to an individual QuickPlace. This will only apply to the room in which you create it; inner rooms will not inherit the logout function.

To add a link page with a Domino ?Logout command:

1. Click New to start a new page in your QuickPlace.

Note: In order to use this function, session-based authentication must be enabled for the QuickPlace server.


2. Select Link Page as the type of page to create and click Next.

3. Enter the page title. An intuitive title like “Sign Out” or “Log Off” will be sufficient.

4. In the URL field, type:

/main.nsf?logout

5. Select No in the “Should the page pointed to open in a new window?” field.

6. Click Publish As.

7. In the “Where would you like to put this page?” section, select Sidebar and choose where you would like the logout command to appear in the sidebar. Do not place it at the top of the sidebar.

8. Click Next.

Logoff button in a QuickPlace themeAdding a Logoff button to your QuickPlace themes is an excellent way to implement a logoff action because each QuickPlace created from a theme will inherit the logoff button. It can also be easily copied into all the themes on your QuickPlace servers.

You can use the same ?Logout command in your button that is detailed in the previous section.

To learn more about customizing themes in QuickPlace, see the IBM Redbook Customizing QuickPlace, SG24-6000, or visit the QuickPlace DevZone website at:

http://www.lotus.com/qpdevzone

4.5 E-mail security with QuickPlaceSMTP (Simple Mail Transfer Protocol) is used to route mail to and from your QuickPlace servers. When planning the overall security of your QuickPlace environment, it is important to consider the security of the SMTP routing component.

Note: You can control where the logout command will take you by placing redirection information after the logout command in the URL field. For example, you could add this argument:

/main.nsf?Logout&RedirectTo=/QuickPlace/Auto/Main.nsf

This example URL would redirect you to the main page of the Auto place.



4.5.1 Avoiding unwanted e-mailUnsolicited commercial or bulk e-mail (known as “spam”) is a major concern for any company that routes mail to and from the internet. It is important to configure your QuickPlace servers so that it will be more difficult for people to route unwanted mail through your servers.

Disabling open mail relayIf you have QuickPlace running as an overlay on a Domino server, you can change some settings in the Domino server document so that unwanted mail does not route through your servers. Domino has native SMTP functionality built into the server; if you are using another service to route SMTP mail, you will need to configure that device to disallow routing of unauthorized mail.

To disable open mail relay on your Domino server:

1. From the Domino Administrator client, select the Configuration tab and click Configurations in the left frame.

2. If you have a configuration document for all servers already, select it and click Edit Configuration. If you do not, click New Configuration.

3. On the Basics tab, select Yes in the “Use these settings as the default settings for all servers” field.

4. Select the Router/SMTP tab, then the Basics tab. Select Enabled for the “SMTP used when sending messages outside of the local internet domain” field. Select MIME messages only in the “SMTP allowed within the local internet domain” field.


Figure 4-19 Configuring the Domino server for SMTP mail routing

5. Select the Router/SMTP tab, then Restrictions and Controls -> SMTP Inbound Controls.

6. Place an asterisk (*) in the following fields:

– Deny messages from external internet domains to be sent to the following internet domains.

– Deny messages from the following external internet domains to be sent to the following external internet domains.


Figure 4-20 Disabling open SMTP relay

7. Click Save and Close.

4.5.2 Antivirus scanning of SMTP mailThere are several products on the market that will automatically scan incoming and outgoing SMTP mail for viruses. It is highly recommended that you implement antivirus scanning on the SMTP mail router that you are using to route mail for your QuickPlace servers, especially if users are e-mailing documents directly into your QuickPlaces.

4.6 FirewallsFor added security, most companies place their application servers behind a firewall. They leave certain ports open so that the applications can still be available to people outside the firewall, but the rest of the server is secured. Some customers opt to place their Web application servers on a special network segment called a DMZ, which resides on their extranet. This is done for added security because the servers located on the DMZ are more secure than if they were directly exposed to the internet.


4.6.1 PortsWhen your QuickPlace servers are accessed through a firewall, you must open certain ports on the firewall that QuickPlace uses to communicate. After the ports have been opened on the firewall, you should test the configuration by using Telnet to try to access the QuickPlace server from outside the firewall. If you cannot Telnet to the ports that QuickPlace uses from a machine outside the firewall, QuickPlace will not be able to use them either.

QuickPlace uses the following ports:

� Port 80 for HTTP

� Port 443 for HTTPS

� Port 1352 for offline setup

� Ports 1533 and 8082 for on-line awareness and chat

In addition, the QuickPlace Offline Client uses port 88. For security reasons, the QuickPlace client is configured to refuse all connections to port 88 that did not originate from the same machine. Consequently, you cannot use Telnet to test on port 88.

4.6.2 DMZsDMZ is an acronym that stands for Demilitarized Zone. A DMZ is a network segment that resides between the company network and an external network, like the Internet. This configuration provides added security because a machine that resides on the DMZ has a layer of security between itself and the Internet, and machines that are on the company network have a layer of security between themselves and the machines on the DMZ. The most typical types of servers that would be in the DMZ would be SMTP mail servers and Web servers.

4.6.3 Using QuickPlace offlineIn order to use the QuickPlace Offline Client with SSL enabled, you need to ensure that clients will be able to communicate with the QuickPlace server via port 1352. If you are using a firewall or proxy, it must be configured to allow connections on port 1352; otherwise the communication that is required to install the offline client and synchronize the data with the server will not occur.


4.6.4 SummaryIn this chapter we have discussed the security aspects related to QuickPlace. In order to fully understand QuickPlace security, we first gave an overview of Domino and Web security. Then we discussed how to secure your QuickPlace with SSL. Detailed instruction about how to enable SSL on your QuickPlace server were provided.

This chapter also covered how to enable logout functionality for QuickPlace users. Finally, e-mail security and firewalls with QuickPlace server were discussed.


Chapter 5. Availability with clustering

QuickPlace is a valuable collaboration tool with an intuitive, user-friendly interface. Since it is a Web-based application, even users who are resistant to learning new software products find it easy to learn. For these and many other reasons, it can quickly become a mission-critical application for your company.

Unexpected QuickPlace server downtime can severely impact your users’ productivity. So how can you implement a solution that will provide high availability of your QuickPlace servers?

Implementing clustering for failover and load balancing can help you provide high availability and maximum server uptime for your users. In this chapter, we provide an overview of clustering solutions, discuss options for implementing clustering in your organization, and provide a step-by-step installation and configuration guide for implementing clustering for high availability.

5


5.1 What is clusteringA cluster is a group of servers treated as a single computing resource that provides services to network users. When a server in a cluster fails, its workload is passed to one or more other members of the cluster until corrective action is taken and the failed server can be brought back into operation again. This is known as “failover” and is a common practice with critical operations.

Clustering also provides “load balancing,” or dividing the total computing resource requirements of the system over several servers. QuickPlace clusters are typically made up of two or more servers serving the application and at least one other server or hardware device that manages the traffic to those servers.

QuickPlace 2.08 supports clustering by combining the native clustering capabilities of Domino Enterprise Server with the load balancing and failover capabilities of either IBM WebSphere Edge Server software (using the Network Dispatcher component) or Cisco LocalDirector hardware.

5.2 Planning a QuickPlace clusterTo plan a QuickPlace cluster, you must consider two things: the type of clustering solution you want to implement and the total number of concurrent users the cluster will be supporting. To estimate the number of concurrent users that a given configuration will support, refer to the Performance Paper on the QuickPlace DevZone website at:


5.2.1 Types of clustering solutionsWhen planning to implement a clustered QuickPlace solution, it is important to consider which type of clustering solution will be the best fit for your organization. The type of clustering solution that you choose to implement will determine the number of servers that will be required.

FailoverThe simplest clustering solution involves a primary server and a secondary server. The primary server handles all user requests and the secondary server is kept in tight synchronization with the primary server so that it can be used in case the primary server fails or requires a scheduled outage. When the primary server becomes unavailable, all user requests fail over to the secondary server until the primary server becomes available again. In this scenario, the resources of the



secondary server are not used for user requests unless the primary server is offline. The capacity of the cluster is equal to the capacity of the primary server. If the secondary server is identical to the primary server, the cluster capacity is the same during regular usage as it is in failover situations.

Load balancingIn addition to failover, QuickPlace clusters can support a load balancing solution. With load balancing, all the servers in the cluster share the workload. In a load balancing scenario, the total capacity of the cluster is approximately the sum of the capacities of all the servers in the cluster. For example, a QuickPlace cluster that has three servers that each support 1,000 users has an approximate maximum capacity of 3,000 users. However, if one of the servers in the cluster becomes unavailable, the capacity of the cluster is reduced to the total capacity of the remaining servers. In this example, the capacity of the QuickPlace cluster would be reduced to 2,000 if one of the servers were to fail. Therefore, the average capacity of a load-balanced cluster is less than the maximum possible.

Having more than two servers in a load-balanced cluster allows for greater reliability and better performance because the remaining servers in the cluster can take on the workload of a single server when it becomes unavailable. When planning a cluster that will have more than two servers, it is important to plan the cluster so that the clustered servers will not be at maximum capacity if one server in the cluster fails or needs scheduled downtime.

5.2.2 Hardware considerationsThe hardware requirements for QuickPlace servers in a cluster are very similar to the requirements for a non-clustered Domino overlay QuickPlace server. The performance paper located on the QuickPlace DevZone at http://www.lotus.com/qpdevzone outlines the computations required to decide what your total resource requirements will be. With this information, in combination with your organization’s reasons for clustering, you can determine the appropriate number and size of servers.

If you intend to choose IBM WebSphere Edge Server for your load balancing and failover software solution, the requirements are minimal: the server requires 64 MB of RAM, approximately 50 Mb of disk space, and a JRE 1.3 installation. It can run on several platforms, including Windows NT/2000, AIX, Linux, S/390 and Sun Solaris. For more details on the installation requirements, see 5.3.3, “Configuring WebSphere Edge Server for a QuickPlace cluster” on page 99.

Chapter 5. Availability with clustering 91

5.2.3 Network bandwidthNetwork bandwidth has a direct impact on the performance of your clusters. It is important that you consider all of the factors that will affect your network performance when planning a clustered QuickPlace environment. Several vendors have performed extensive testing on clustered Domino servers. Viewing their test results may assist you in planning your QuickPlace clusters. You can view their results at:

http://www.notesbench.org

It is recommended that you create a private LAN to carry cluster traffic. Doing so makes your cluster more efficient by separating the cluster traffic from the other network traffic on your LAN. This will also help avoid the problem of a busy cluster taking up too much bandwidth on your primary LAN. In addition, a private network for your cluster ensures that cluster replication will continue even if problems occur on the primary LAN.

To create a private LAN for your cluster, you must install an additional network interface card (NIC) on each server in the cluster and connect these secondary NICs through a suitable interconnecting hub or switch. All cluster members must be connected to both the primary LAN for client access and the private LAN for cluster communication.

5.2.4 Network workload distribution There are several options available for distributing workload across a number of servers. QuickPlace requires that the network redirection solution send HTTP requests to one node in the cluster continuously for a predetermined amount of time. This is sometimes referred to as “sticky time.” The Network Dispatcher component of the IBM WebSphere Edge Server is one option that is used for HTTP traffic distribution among cluster nodes.

5.3 Installation and configurationAs of this writing and QuickPlace version 2.0.8, the Network Dispatcher component of the IBM WebSphere Edge Server is the only software solution certified for use with QuickPlace for load balancing and failover. In our lab environment, we set up a simple cluster of two QuickPlace servers and one WebSphere Edge Server to represent a typical scalable solution. A diagram that describes the environment we created is shown in Figure 5-1 on page 93.


http://www.notesbench.org

Figure 5-1 Overview of a clustered QuickPlace environment

To install QuickPlace in a cluster, you must first configure two or more Domino Enterprise Servers with clustering enabled. Our configuration called for two Domino servers. We created a domain “CMC” and two new servers KANSASQPA and KANSASQPB in this domain, then clustered them using the cluster name QPCLUSTER. Information on setting up a cluster using Domino Enterprise Servers is readily available in the Domino Administration Help database (help5_admin.nsf).

After the Domino servers are installed and the cluster is operational, QuickPlace servers must be installed over the Domino servers. Refer to Chapter 2, “Installing and configuring QuickPlace” on page 7 for the installation instructions for QuickPlace. Of interest in the context of a cluster, however, are some of the settings in the administration interface of QuickPlace that pertain to clustering.

5.3.1 Preparing QuickPlace servers for a clustered environmentWhen QuickPlace is installed in a clustered environment, there are a few settings to make in order to support the cluster. All of the settings pertain to QuickPlace features that need to be run from only one of the servers in order to avoid conflict or duplication. These settings are:

QP Server #19.85.35.59

QP Server #29.95.35.56

Network DispatcherNon-Forwarding Address:

9.95.35.65(Not in DNS)

Domino Enterprise Server Cluster withQuickPlace Replica Manager

Cluster Address:9.95.35.68

Configured by IBM ND, not O/SDNS entry: cluster address A and MX records

IBM ND Advisormakes sure servers

are available

2:IBM ND Manager balances

requests to servers based on weights, availability

Workstation

1:Browser client makes request to cluster address:http://cluster.mycompany.com

3:QuickPlace: answer from available server


� Chat: Point the QuickPlace chat service to one server, since multiple QuickPlace servers cannot maintain place awareness.

� Offline: Point the offline download and offline sync services to a single server.

� Host name (e-mail URL prefix): Provide all servers in the cluster with a setting that instructs the QuickPlace server to use a defined host name (that of the cluster) in the URL prefix of notifications, invitations, and newsletters.

� Mail: Remove the duplicate entries that process rejected or bounced mail.

� Newsletters: Use a NOTES.INI setting to allow only one server in the cluster to process the nightly/weekly newsletters.

The first three settings—Chat, Offline and Host name—are made in the QuickPlace administration interface shown in Figure 5-2 on page 95. This screen is accessed by logging in to the QuickPlace server at http://hostname/quickplace and following the menu to Server Settings -> Other Options, then clicking the button to Edit Options.


Figure 5-2 Other Options screen in the QuickPlace Administration interface

Chat settingsIn this screen, the Remote Chat Server is indicated by its hostname. This setting only needs to be made on the servers that are not providing the chat service.

Offline settingsThe Offline Passthru Server is recorded, as well as its hostname. The Offline entry also requires a change to the Domino Directory server record to enable passthru. This setting only needs to be made on the servers not providing offline services.

Also to support Offline service, the choice can be made to direct all of the traffic for downloading the Offline installation files (26 Mb) to another source. Since this is a self-contained file and the download itself does not depend on QuickPlace services, the file “instoqp.exe” can be placed anywhere and made available for


download from the specified URL. This is a valuable setting, since it can reduce the amount of traffic going to your QuickPlace servers immensely—especially during a major rollout. Using an external FTP server may be desirable, as FTP is typically also a faster download. There is no compromise in security by placing the instoqp.exe file on an FTP server because the installation process requires the generation of a user ID, which is not available to the general public. This setting should be made on all servers, including the one being used for the alternate offline download URL, if that server is one of the servers in the QuickPlace cluster.

Host name (URL prefix)The Email URL Prefix field allows you to specify the URL that will show in mail generated by the QuickPlace server: newsletters, notifications, and invitations. It is important to note that this setting will not change hard-coded URLs in placebots (agents) inside the QuickPlaces. They will need to be addressed separately by the developers of those placebots. This setting must be made on all servers in the cluster.

Dead mail settingBy default, a QuickPlace server installation creates a mail-in database record in the Domino Directory for a database to handle bounced, undeliverable, or rejected mail sent out by the server. In a clustered environment, this means more than one of these records will have been created by installations, and there will be conflict in the Directory with duplicate names for this resource. The mail-in database that is created for this purpose is called QuickPlace/QuickPlace/QP/<domain> and points to the database QuickPlace\DeadMailQP.nsf. This database runs a scheduled agent that removes all of its contents. Figure 5-3 on page 97 shows the process for removing the extra mail-in database record once both (or more) QuickPlace servers are installed.


Figure 5-3 Removing the extra mail-in database record for QuickPlace dead mail

Newsletter settingEach night the QuickPlace server runs the server task nQuickPlaceNightly. This program takes care of some housekeeping duties, such as finalizing the removal of deleted QuickPlaces. It also generates the nightly and weekly e-mail newsletters to QuickPlace users, personalized for each user. While the housekeeping tasks are desirable on all servers, the newsletter should only be generated from a single server. An edit to the NOTES.INI file for each server you wish to skip sending the newsletter is required. To make this setting, shut down the Domino server instance or service on each of the machines where you want to turn this off and add the following line to the NOTES.INI file:

QPWhatsNewEmailEnable=0

This setting will allow the nQuickPlaceNightly program to run but avoid duplicating newsletters for QuickPlace users in the cluster.

5.3.2 Configuring the Replica Manager and replicationBeginning with QuickPlace version 2.0.8, a separate Admin Utility is shipped on the CD. Part of the Admin Utility’s function, in addition to the administrative tools it provides, is the Replica Manager, a command-line function that controls the creation and deletion of QuickPlaces and rooms on multiple servers.

The Replica Manager is the first offering from Lotus that fully manages replicas of QuickPlaces on multiple servers. A sample utility, qpreplicate.dll, was distributed in June 2000 at Lotus DevCon, and has been downloaded and used for this


purpose in versions prior to 2.0.8. However, this sample had several limitations and was meant only as a sample of how to write hooks into QuickPlace using the API, not for production. Lotus recommends and supports only the Replica Manager for a clustered environment or multi-server environment.

The syntax for the Replica Manager is very straightforward. It is called from the Domino console using the syntax:

replicaManager -r <target server>

where <target server> is the name of another server in the cluster.

Replica Manager should be run on one server in a two-server environment, and on multiple servers in a larger cluster. Since it is bidirectional in function (that is, it creates new replicas on either server when it runs), it can be run in a hub-spoke fashion similar to a replication schedule.

Replica Manager should be run often in a cluster to reflect the addition of new rooms and QuickPlaces very quickly. We suggest an interval of 10 minutes or less. This recommendation lends itself to using a program document in the Domino Directory to schedule the task. Figure 5-4 shows a configured program document for Replica Manager. As a result, the Domino console displays the command and its results every 10 minutes; this is illustrated in Figure 5-5 on page 99.

Figure 5-4 Program document for the QuickPlace Replica Manager


Figure 5-5 Domino Console with the Replica Manager Log Entries

Scheduled replicationIn addition, a frequent scheduled replication is recommended to “catch” anything that the cluster may have missed for various reasons—a short downtime, a very busy server, network issues, and so forth. In a connection document, we scheduled replication between the two clustered servers for every 20 minutes.

5.3.3 Configuring WebSphere Edge Server for a QuickPlace clusterThere is a document available from Lotus on the QuickPlace DevZone called QuickPlace 2.0 Administration Practices, which describes the process for implementing QuickPlace in a clustered environment. We suggest using this document in conjunction with the instructions in this section to complete your installation and configuration.

The instructions from Lotus on this part of the configuration are not very detailed (approximately 1/2 page of the total document), while the documentation on WebSphere Edge Server from IBM is very detailed—over 400 pages—but does not address some of the intricacies presented by Domino and QuickPlace. For


this reason, we decided to give detailed and heavily illustrated instructions on making these products work together. In addition, we describe some undocumented settings and tricks that can be used to ease implementation and improve performance.

Preparing for the WebSphere Edge ServerWebSphere Edge Server requires a minimally configured server: only 64 MB of RAM, 50 Mb or so of disk space, and a JRE 1.3 installation. It can run on several platforms, including Windows NT/2000, AIX, Linux, S/390, and Sun Solaris.

Although it is not documented as a requirement, we suggest for ease of use and support that users install the version of JRE 1.3 that ships on the CD with WebSphere Edge Server, and to make this version the system JRE. The simple installation of this JRE is located on the CD in the JRE13 folder.

Once the JRE is installed, you are ready to install WebSphere Edge Server.

After the JRE is installed, there is a network requirement to attend to. WebSphere Edge Server actually uses two IP addresses - one for the NIC card’s normal network operations and another for the IP address associated with the cluster in the system’s DNS tables. It is important to note that this second IP address is not configured on the NIC card, but that it is configured dynamically by the software.

Note: Wherever the term IBM Network Dispatcher is used in the formal documentation, it refers to a component of that name that is a part of the product called WebSphere Edge Server. Network Dispatcher used to be sold as a single product, but in early 2001 it was rolled into the WebSphere Edge Server along with some other performance tools. We have decided to use the WebSphere name in this book to reflect the product’s new packaging. Where you see “Dispatcher” in this chapter, we are referring to that component.

Important: JRE 1.3, preferably the one that ships on the CD, must be installed before installing WebSphere Edge Server!


Figure 5-6 Installation panels for Network Dispatcher component of WebSphere Edge Server

Installing WebSphere Edge ServerOur environment included several IBM eServer xSeries (Netfinity) machines with Windows 2000 Professional and Server installed. Since WebSphere Edge Server is cross-platform, we chose one of the Windows 2000 Professional machines for the installation. In the root directory of the installation is a setup.exe file, which we ran. After choosing Network Dispatcher as the only product we wished to install, we began to make more refined choices for the installation.

As shown in Figure 5-6, we chose a selective installation of components by choosing “Your choice of components,” then unselecting “Metric Server.” The Metric Server is a component designed for the servers being clustered, not for the dispatcher machine itself.

This should allow the installation to complete. After installation completes, reboot the dispatcher machine. You will notice—if you are using Windows NT or 2000— that nine new services have been added to the machine. You can see these by opening the services in the machine’s administrative tools (Windows 2000) or settings (Windows NT). Figure 5-7 on page 102 indicates that by default, the only


service that starts automatically is the IBM Dispatcher service. This is correct; we do not need any of the other services running to accomplish load balancing and failover for a QuickPlace cluster. For more information on these services, see the WebSphere Edge Server documentation.

Figure 5-7 IBM Dispatcher starts automatically as a Windows NT/2000 service

Creating IBM Dispatcher keysThe first step to configuring the Dispatcher is creating a set of keys it uses to keep track of sessions. This is a one-time process and is easily accomplished. With the IBM Dispatcher service running, open a command prompt and type ndkeys create, as illustrated in Figure 5-8 on page 103. If the JRE 1.3 is installed correctly and the IBM Dispatcher is running, and this process has not been done before, you should receive the response Key files have been created successfully.


Figure 5-8 Using the ndkeys create Java command

If you receive an error message, the machine is probably not configured with the new JRE as the system JRE. You can check this by typing “java -version” at a command prompt. If your IBM JRE does not report as the system JRE, you may need to reinstall it or modify the computer’s environment variables to accommodate this requirement.

Configuring IBM DispatcherAssuming a successful installation and creation of keys, configuration of the Dispatcher is the next step. In this section we refer to several figures that were taken during configuration of our own lab environment.

The configuration instructions contained in this section refer to use of the user interface (UI) version of Dispatcher on a Windows machine. It is possible to configure Dispatcher using the command line and calls to the Dispatcher’s main program “ndcontrol.” However, with the visual setup it is much easier to follow what is actually happening. For configuration instructions for other platforms, see the WebSphere Edge Server documentation that ships with the product.

The UI version of Dispatcher is buried quite deeply in the Program menu. Access it with the following selections: Start -> Programs -> IBM WebSphere -> Edge Server -> IBM Network Dispatcher -> Network Dispatcher. We opened this shortcut and were presented with a quick status bar, followed by a two-panel configuration screen.


Connecting to the host serverThe first step, illustrated in Figure 5-9, is to connect to the Edge Server, known as the “host.” We right-clicked the Network Dispatcher entry in the left pane and chose “Connect to Host”. There should only be one choice, as shown in Figure 5-10.

Figure 5-9 Network Dispatcher initial screen: Connecting to host

Figure 5-10 Choosing the host


Adding a clusterAs soon as the host was chosen, a new set of expanded branches appeared under “Dispatcher.” These are the tools we configured to provide load balancing and failover for QuickPlace. The first step was to add a new cluster, which was done by right-clicking the Executor entry and choosing Add Cluster, then providing the IP address we wished the cluster to have. This is the IP address associated in DNS with the host name we are assigning to the cluster. Remember that this IP address is not set up on the NIC card at the operating system level; Dispatcher is going to configure and bind it for you.

Adding portsOnce the cluster address was set up (in our case 9.95.35.68), we began to add ports as shown in Figure 5-11. Ports refer to the TCP/IP ports that we care about for the QuickPlace server’s use on the Web:

� Port 80 - for normal HTTP traffic

� Port 25 - for normal SMTP traffic

� Port 1533 - for QuickPlace chat traffic

Figure 5-11 Adding Ports to a Cluster


Figure 5-11 on page 105 indicates that we have already set up ports 80 and 1533. So, we have port 25 to complete. By selecting “Add Port” we were presented with a dialog box to indicate the port number. This is shown in Figure 5-12.

Figure 5-12 Adding the SMTP port 25 to the cluster

Changing the sticky time for port 80“Sticky time” is a term that refers to the amount of time that, by default, Dispatcher will balance your session to one server in the cluster and leave it there before re-evaluating the load. By default, this is set to 0 for all ports when they are configured. Because we want users to stay on the same server even if that server is receiving a majority of the load at a given time, this number should be increased to 300 (5 minutes). This translates to: “If I log in to the cluster, Dispatcher will leave my session alone—all requests from me will go to the same server—for at least 5 minutes.” Due to the nature of QuickPlace publishing and the large number of requests in a given page, it is important to set this value to a high number. Changing the sticky time is simple: we clicked the port assignment for port 80, chose the Configuration Settings tab, and modified the field as shown in Figure 5-13 on page 107. We then clicked the Update Configuration button to save the change.


Figure 5-13 Changing “Sticky time” for HTTP port 80

Adding servers to portsEach port assignment will be servicing one or more clustered servers. In our lab, with two QuickPlace servers, we were supporting both servers on ports 25 and 80, and only one on port 1533. This is because the QuickPlace chat feature is directed only to a single server.


Figure 5-14 Adding servers to each port being managed in the cluster

To add a server to each port as in Figure 5-14, we right-clicked on the port assignment and chose Add Server. At this point we were presented with the dialog box shown in Figure 5-15 requesting the server name and address. The first entry for server is simply the name you wish to see displayed; we chose the IP address. The server address entry is the IP or host name of the clustered server. We repeated this process for each server in the cluster for ports 25 and 80, and for just one server for port 1533.

Figure 5-15 Dialog box to add servers to a port


Adding AdvisorsThe Cluster, Port and Server configuration described tells the Dispatcher how to behave when it receives requests for resources (incoming packets) for the cluster servers. Dispatcher also has a feature called Advisors, which monitor the cluster servers for both their load and availability. An Advisor sends a port-specific request at specified intervals, returning availability information to the Dispatcher’s engine for interpretation and use in determining where to send the new and existing sessions.

Figure 5-16 Adding an Advisor to monitor the clustered servers

To add Advisors for SMTP and HTTP traffic, we right-clicked the Manager branch under host, and chose Start Advisor as displayed in Figure 5-16. Figure 5-17 on page 110 shows the resulting dialog box, which provided us with a choice of standard ports to monitor. We chose SMTP for one Advisor and HTTP for the other, leaving all of the configuration settings at default.


Figure 5-17 Dialog box when adding an Advisor

Configuring the SMTP AdvisorOnce the Advisors were set, we chose to modify a setting in the SMTP Advisor as shown in Figure 5-18. The setting is called “Update interval (seconds)”. By default, Dispatcher sets this field to 7 seconds. For SMTP traffic, we felt that this is too short an interval, one that would result in unnecessary network traffic every 7 seconds, so we changed it to 300 (5 minutes). It is also quite simple to modify DNS to add lower priority routing to cover if a server goes down. Using these together provides a complete solution for high availability of SMTP services in your cluster.


Figure 5-18 Modifying the SMTP Advisor update interval

When a setting in Dispatcher is changed, it is important to click the Update Configuration button at the bottom of the right panel, as in Figure 5-19 on page 112. It is good practice to make this a habit after each field change.


Figure 5-19 Updating the configuration after each configuration change

Saving the configuration changesWhen all of the configuration changes have been completed to accommodate your QuickPlace cluster environment, the configuration must be saved while exiting the UI program. Figure 5-20 on page 113 illustrate the steps required to save the configuration as the default configuration.


Figure 5-20 Series of dialog boxes received on exiting the Dispatcher configuration

5.3.4 Configuring the clustered serversIn order for the clustered servers to respond to client requests “as if they were at the cluster address,” there are two actions to take on the clustered servers at the network level. The first is setting up a loopback address, and the second is deleting an extra network route that this first action creates. The instructions for completing these actions for other platforms are also located in the documentation for WebSphere Edge Server; we will discuss the implementation on Windows 2000 in our lab.

Alias the loopback deviceFor Windows 2000, implementing a loopback address to the cluster address is required, and is a fairly simple process. Following are the steps as described in the WebSphere Edge Server documentation:

1. Click Start -> Settings -> Control Panel.

2. If you have not done so already, add the MS Loopback Adapter Driver.

a. Double-click Add/Remove Hardware. This launches the Add/Remove Hardware Wizard.

b. Click Next, select Add/Troubleshoot a Device, then click Next.

c. The screen blinks off/on, then presents the Choose a Hardware Device panel.

d. If the MS Loopback Adapter is in the list, it is already installed. Click Cancel to exit.


e. If the MS Loopback Adapter is not in the list, select Add a New Device and click Next.

f. To select the hardware from a list, for the Find New Hardware panel, click No and then click Next.

g. Select Network Adapters and click Next.

h. On the Select Network Adapter panel, select Microsoft in the Manufacturers list, then select Microsoft Loopback Adapter.

i. Click Next, then click Next again to install the default settings (or select Have Disk, then insert the CD and install from there).

j. Click Finish to complete installation.

3. From the Control Panel, double-click Network and Dial-up Connections.

4. Select the connection with Device Name “Microsoft Loopback Adapter” and right-click it.

5. Select Properties from the dropdown.

6. Select Internet Protocol (TCP/IP), then click Properties.

7. Click Use the following IP address. Fill in the IP address field with the cluster address, and subnet mask with the default subnet mask (255.0.0.0). This may need to be modified to match your default subnet mask.

Remove the extra routeConfiguring the loopback device as described will cause your Windows 2000 machine (and other platforms) to have an extra, unnecessary route in its routing tables. The effect of this is a failure of the machine to communicate properly at the network level, as it “thinks” that it should be responding to the cluster address. The extra route is easy to identify by using the command route print from a command prompt. This produces a table similar to this:

Active Routes:Network Address Netmask Gateway Address Interface Metric0.0.0.0 0.0.0.0 9.95.35.1 9.95.35.56 19.0.0.0 255.0.0.0 9.95.35.56 9.95.35.56 19.95.35.0 255.255.248.0 9.95.35.68 9.95.35.68 19.95.35.56 255.255.255.255 127.0.0.1 127.0.0.1 19.95.35.56 255.255.255.255 127.0.0.1 127.0.0.1 19.255.255.255 255.255.255.255 9.95.35.68 9.95.35.68 1127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1224.0.0.0 224.0.0.0 9.95.35.56 9.95.35.56 1224.0.0.0 224.0.0.0 9.95.35.68 9.95.35.68 1

Note: Don’t enter a router address. Use the localhost as the default DNS server.


255.255.255.255 255.255.255.255 9.95.35.68 9.95.35.68 1

In this example, we are interested in the two lines:

9.95.35.0 255.255.248.0 9.95.35.68 9.95.35.68 19.255.255.255 255.255.255.255 9.95.35.68 9.95.35.68 1

The reason for this is that the first line is actually an extra route: it causes the server to fail to respond to any other type of network call other than the cluster requests. For instance, if this extra route remains, the clustered servers will not be able to reach each other via TCP/IP, hence they will not be able to replicate. The command to remove an extra route is very simple:

route delete <network address> <gateway address>

In our case:

route delete 9.95.35.0 9.95.35.68

With Windows NT and 2000, this command must be run every time the server is rebooted. This presents a problem for Domino servers, which typically start as services before a human being is aware the server is up and running. The IBM documentation recommends the use of a batch file that executes at startup of the server. However, this solution is incomplete in that it requires a physical login to the machine. Typically, a machine may restart and Domino will start without logging in. This presents us with the challenge of deleting the route, automatically, before logging in.

There are two solutions to this problem. First, you could create a Windows service that handles the route deletion using the Windows Resource Kit. If you are comfortable with writing Windows services, this may be the route for you. However, there is an easier way afforded by the fact that we are using Domino: a program document that runs on startup only. Figure 5-21 on page 116 shows how a program document can be constructed very easily to handle the route deletion, run only on startup, and run automatically when the Domino service starts, without logging in.


Figure 5-21 Program document to remove the extra network route

If the Domino server is being restarted without an operating system restart, the route will already be removed. Running the “route delete” program document will have no effect, and will simply report that the specified route does not exist. We have tested this method and found it to be by far the easiest way to manage the requirement to delete the extra route.

5.4 Third-party routingQuickPlace 2.0.8 and later has features that enable third-party routing services to help manage QuickPlace network traffic. Third-party routing has been thoroughly tested and is supported for Tivoli Policy Director (which we will refer to as Policy Director throughout this section) and iPlanet Portal server (which we will refer to as iPlanet).

Third-party routing will work with QuickPlace overlay installations on Windows NT or Solaris. Clustered QuickPlace servers are also supported with third-party routing services.


QuickPlace 2.0.8 is currently not supported with third-party routing in the following configurations:

� QuickPlace with IIS.

� QuickPlace with SSL.

� QuickPlace on the iSeries platform.

� A QuickPlace standalone server.

� QuickPlace with a Macintosh client.

� Upgrading from any 2.0.8 beta builds to 2.0.8 Gold. If you want to use third-party routing, a clean install of 2.0.8 or an upgrade from an earlier release is required.

In addition, the following features in QuickPlace 2.0.8 are not supported with third-party routing:

� QuickPlace Chat

� QuickPlace Admin Utility

The administrator must access the Admin Utility directly for the server they wish to administer. The third-party routing product should not be referenced in the URL when accessing the 2.0.8 Admin Utility. To learn more about the Admin Utility see 2.8, “The QuickPlace Administration Utility” on page 32.

Setting up third-party routingIn addition to installing QuickPlace, some additional steps are required to support QuickPlace when you are using a third-party routing service. You must:

� Install a Domino Passthru server, which is required for the Offline service to work correctly with Policy Director or iPlanet.

� Set New Server Options in QuickPlace 2.0.8.

� Edit the NOTES.INI file on the QuickPlace server.

Setting up the QuickPlace server to use third-party routingIn order for the QuickPlace Offline feature to work properly with third-party routing services, a Domino passthru server must be installed and configured. Following is an overview of how to install and set up a Domino passthru server and how to configure your QuickPlace servers prior to using the third-party routing service. For more detailed information on Domino server setup and Domino passthru servers, refer to the Lotus Domino documentation available at

http://www.notes.net

1. Install a Domino server with the same type of network connectivity as the iPlanet or Policy Director servers. Set up the Domino server as a passthru server, ensuring that the proper updates to the server document and


http://www.notes.net

connection documents are created in the Domino Directory and replicated to all servers in the Domino domain. For information on setting up a passthru server, see the Domino Administration Help topic, “Setting up a passthru server.”

2. On a separate machine, install Domino 5.0.8 and QuickPlace 2.0.8 server. Make sure the Domino server is set up using the same certifier ID that was used to set up the passthru server. For information on how to install Domino and QuickPlace, see 2.4, “Installing the QuickPlace server” on page 13.

3. After you have finished installing the QuickPlace server, edit the Access server field in the QuickPlace server’s document in the Domino Directory so that it reflects the certifier you are using for the Domino servers. In other words, if the certifier you are using is /CMC, you should enter */CMC in the Access server field. To do this:

a. Using the Domino Administrator client, select the Configuration tab, then select All Server Documents.

b. Locate the server document for your QuickPlace server and click Edit Server.

c. Select the Security tab and update the information in the Access server field.

d. Click Save and Close to save your changes.

4. Sign in to your QuickPlace server as the Administrator and go to the Server Settings screen.

a. Click Other Options, then Edit Other Options.

b. Select Disable in the Enable/Disable Chat field.

c. Specify the server’s canonical name (i.e., MyServer/MyCertifier) and the server’s hostname (i.e., myserver.mydomain.com) in the Offline Passthru Server fields.

d. Enter the URL of the QuickPlace server that users will access to download the Offline client software in the Alternative Offline Download URL field. Note: This field is mandatory if you are using third-party routing services and your users will be using the Offline feature.

e. Enter the appropriate e-mail URL prefix in the E-Mail URL Prefix field. Note: This field is mandatory if you are using third-party routing services and your users will be using e-mail features such as What’s New e-mails on your QuickPlace servers.

f. Click Next to save your changes.

5. Shut down the QuickPlace server.

6. Add the following line to the NOTES.INI file:


NoWebFileSystemACLs=1

This NOTES.INI setting will cause the server to ignore any authentication information sent with HTTP requests to files in the HTML directory.

7. Restart the QuickPlace server.

5.5 Performance and other considerationsOnce you have set up and configured your QuickPlace clusters, you may want to monitor your cluster’s performance and make adjustments to the server configuration based on the results. In addition, there are several native functions in QuickPlace that are affected when clustering is implemented.

5.5.1 Virtual memoryFor Windows NT and Windows 2000, adjusting the virtual memory setting on your QuickPlace servers can result in better performance. Your virtual memory settings should be at least double the physical memory on your QuickPlace server. For example, if your server has 256 MB of RAM, you should set the virtual memory to at least 512 MB.

5.5.2 HTTP thread settingsHTTP threads are execution threads for handling incoming HTTP requests. To improve performance, you can reduce the number of HTTP threads that the server is running concurrently. To do this, perform the following steps:

1. From the Domino Administrator client, select the Configuration tab.

2. Select Server -> All Servers from the left pane.

3. Select your QuickPlace server from the list and click Edit Server.

4. Select the Internet Protocols tab, then the HTTP tab.

5. Change the value in the Number active threads field.

6. Click Save and Close to save your changes.


5.6 SummaryIn this chapter we have described how to make your QuickPlace server reliable and highly available. We discussed different clustering options and how to implement them. We also provided a step-by-step guide for installing and configuring the IBM WebSphere Edge Server for a QuickPlace server cluster.


Chapter 6. Going live

Organizations like to run pilots with new products to evaluate them and see whether they’re going to be suitable to roll-out to other parts of the organization.

One of the main appeals of QuickPlace is that it is very easy to install, so getting a pilot up and running can take a matter of minutes.

However, what is often the case is that QuickPlace becomes very popular, very quickly. Within weeks QuickPlace becomes a mission-critical application to all levels of users, when really it’s still at the pilot stage! This can raise a number of issues.

Chapter 1, “Introduction and planning” on page 1 discusses the best approach for implementing a pilot.

In this chapter we provide advice and recommendations you need to consider if you already have a pilot up and running and need to take it to the next step, with the minimum amount of downtime and distruption. This should help you avoid some of the pitfalls when the pilot moves into production.

6


6.1 Pilot to productionIn this section we look at how best to migrate an existing pilot to a more scalable production environment.

Throughout this section we look at the scenario of Cambridge Auto Parts (CAP), an organization that has been running a pilot on a standalone installation of QuickPlace that has grown so rapidly it is now becoming unmanageable.

To better manage the product, CAP needs to migrate their places onto a Domino overlay installation and have the ability to look up and authenticate users in a centralized secondary directory.

We first look at how to migrate a standalone QuickPlace server installation to an overlay install with the pre-existing local users authenticated with a Domino Directory. Then we focus on the more complex migration, migrating to an overlay installation with the pre-existing local users authenticated with a third-party compliant LDAP directory.

The aim of the migration is zero downtime!

6.2 Standalone to overlay and a Domino DirectoryMigrating QuickPlace from a standalone installation to overlay includes a lot of initial manual work, including configuring servers and installing software.

Ensuring users are still able to log into their places, with the same access and with the minimum disruption, is a critical part of the project.

Migrating users from a local directory on a standalone installation to a Domino overlay and Domino Directory is made easier thanks to the QuickPlace Move utility, QPMove.

This utility lets you move or copy a QuickPlace on a QuickPlace or Domino server to the same server or to another QuickPlace or Domino server. You can also use QPMove to rename a QuickPlace.

You will need the QPMove version that corresponds to the server version that contains the QuickPlace you are moving or renaming. Also, the server version you are moving from must match the server version you are moving to. QPMove for QuickPlace 2.08 is included as part of the Global English server installation; prior to this release you had to download it separately. We recommend that you upgrade your QuickPlace to 2.08 if you are using previous versions.


6.2.1 Configuration recommendationsPrior to performing the migration, we suggest the following configuration considerations:

1. Separate server

We recommend you have a dedicated machine for the Domino server and QuickPlace overlay, separate from any current pre-installed Domino server infrastructure. You will find QuickPlace is more efficient if the underlying Domino server is not performing routine Domino server tasks.

2. Same Domino organization

We recommend that you install QuickPlace into the existing Domino organization, so that the same certifier file is used for both QuickPlace and Domino users. This means administering security is easier since all signatures will be uniform, with no need to cross-certify.

3. Integrate into the current Domino domain or separate domain

There are advantages and disadvantages to either integrating QuickPlace into the current domain or creating a separate dedicated domain. There are a number of factors to consider. Refer to 2.1, “Planning the installation” on page 8 to help you determine which option best suits to your needs.

6.2.2 Migrating from standalone to overlay and a Domino DirectoryThe detailed steps below walk you through the migration procedures. You may skip the steps your server is already configured with.

1. Notify users.

2. Install Domino with the QuickPlace overlay.

3. Ensure all users are listed in the Domino Directory.

4. Copy QuickPlaces to the new Domino/QuickPlace server.

5. Run QPMove.

6. Edit fields in the contacts1.nsf database.

Step 1: Notify usersThe main benefit of migrating from a local QuickPlace directory to a Domino Directory is having one central location for managing users. Once users are migrated, all login and password authentication is referenced in their person document in the Domino Directory.

Chapter 6. Going live 123

Users may have different passwords in different QuickPlaces, so they need to be informed that once the migration is complete they will just have one login. To make the process easier, it is beneficial if users are able to define their Internet passwords in their person document themselves to help alleviate the workload on the administrators.

By default the Domino Directory ACL is set to allow users to change their Internet passwords. Some organizations have strict policies on user access to Domino Directory documents; in these cases, the administrators will need a workaround.

In summary, you will need to notify users of the planned timetable of this migration and what affect it will have on them. Also, inform them whether they need to edit their own Internet passwords or give them a password and any changes to any bookmarked URLs.

Step 2: Install Domino with QuickPlace overlayPrepare the destination server that will be used for the migration. Refer to Chapter 2, “Installing and configuring QuickPlace” on page 7 for installation of Domino and QuickPlace overlay.

Step 3: Ensure users are registered in the Domino DirectoryIf your organization does not have a pre-existing Domino Directory, you will need to register users so they each have a person document with an Internet password. This can be done using the Domino Administrator. For more help on registering users, see the topic Registering users in the Domino Administration Help database (help5_admin.nsf).

If you are not integrating QuickPlace into pre-existing Domino Directories, but providing QuickPlace with it’s own domain, users from the primary Domino Directory will need to be recreated in the QuickPlace directory.

This can either be done by manually copying the person documents, creating an agent on the primary address book that copies the person documents across to automate this task, or having the users self-register using a registration program such as the Domino Web Registration database.

Step 4: Copy QuickPlaces to the new Domino/QuickPlace serverQPMove is the utility that re-signs QuickPlaces once they have been moved. It does not physically move the places for you: you must manually copy the QuickPlaces to their new location. In this example, we demonstrate moving the Hubcaps QuickPlace onto the new QuickPlace server.

Follow these procedures to move the places:

1. For each QuickPlace you are moving, create a directory on the destination server off the QuickPlace sub-directory. This new directory needs to have the


same name as the source QuickPlace, for example \Lotus\Domino\Data\QuickPlace\Hubcaps.

2. Within each QuickPlace directory, copy all databases from the source directory to the destination directory, except Search.ft. This full text index is rebuilt when the place is loaded. The databases you copy include:

– Main.nsfThe main room that contains the data and structure of the place

– Contacts1.nsfContains all the membership and user information to that place

– Search.nsfContains search information

– PageLibraryxxx.nsfAny inner rooms contained within the place

3. Repeat steps 1 and 2 for each individual QuickPlace you want to move.

Step 5: Run QPMoveOnce you have copied the QuickPlaces to the destination server, run the QPMove utility. This utility does the following:

� Signs the place with the certifier of the new QuickPlace, therefore retaining all links and logins.

� Renames all existing users in the QuickPlaces databases to incorporate the new distinguished names of destination servers, for example: Terry Medhurst is a user on the pilot system and his name appears in the ACLs, Authors, and Readers fields as Terry Medhurst/Hubcaps/QP/Pilot. Once the QuickPlace has been moved and QPMove has run, his name will be updated with the new certifier, and he will automatically be renamed as Terry Medhurst/Hubcaps/QP/CAP, thereby retaining the logins and ensuring he can authenticate with the new system.

� QPMove creates an h_members group for each QuickPlace in the Domino Directory of the new location.

Note: Once QPMove has run on the QuickPlaces, all existing names in the ACLs, Readers, and Authors fields will change to the new distinguished name. If you are considering having the pilot and production servers co-exist for a short testing period, you will not be able to successfully replicate between the two systems due to these name and ACL changes without first changing the ACL and making post-replication field-level edits to reflect new and old names.


To run QPMove, follow these steps:

1. Shut down the Domino QuickPlace server—otherwise you could corrupt your QuickPlaces.

2. Launch a command window and change to the Domino root directory, for example with the command cd\Lotus\Domino.

3. At the prompt, type:

QPMove -q QuickPlace name

where QuickPlace name is the name of the QuickPlace you are signing, for example: QPMove -q HubCaps

Once you have run the utility you will see QPMove signing all the databases. Figure 6-1 shows you this procedure.

Figure 6-1 QPMove command

4. Repeat step 3 for all moved QuickPlaces.


Step 6: Edit fields in the contacts1.nsf databaseThe contacts1.nsf database contains member information for each user of a particular QuickPlace. Once QPMove has run, all instances of the user’s name are changed to the new distinguished name, allowing that user to continue using the QuickPlace and retain their level of access.

However, before you go live, in order for the user to be authenticated against a secondary directory instead of a local one, you will need to manually edit their member document in each contacts1.nsf database to point to this directory.

Figure 6-2 A Members document configured for local authentication

The fields that are important to change in the member document are:

� h_password

If the user is being authenticated locally, this field contains the encrypted hashed password. If the user is being authenticated in a secondary directory, this field needs to be blank. This is only valid if the h_type field contains the value h_member; it is not relevant for groups.

� h_FromWhere

This field tells QuickPlace which directory users need to be authenticated with. If this field is blank, it means the user is being authenticated locally. For authentication with secondary directories, the format of the string is:

h_Value : h_Type : h_Name

Table 6-1 on page 128 defines each component in the string.


Table 6-1 Reference guide to h_FromWhere parameters

For example, users migrated from the pilot CAP server to the production Domino QuickPlace server will have their h_FromWhere field set to:

dir:h_UserTypeNAB:CN=CAPMAil01/O=CAP

Figure 6-3 shows the edited member document now configured for Domino Directory authentication.

Figure 6-3 The member document configured for Domino Directory authentication

Step 7 Switch to the production serverOnce the QPMove has run and member documents have been edited, launch the Domino server.

The QuickPlace server is now ready to go live. Users can switch to using the new production server and continue working on a more scalable, manageable server.

Component name Parameters Notes

h_Value Contains the domain name.

h_Type h_UserTypeLocalh_UserTypeNTh_UserTypeNABh_UserType

Specifies the directory type. This will be local, NT, Domino Director, or LDAP.

h_Name This component is always set to dir.


6.3 Standalone to overlay with LDAPWhen migrating a standalone installation to Domino overlay with LDAP authentication and name lookup, the process is very similar to that covered in the previous section. As with that migration, you will need to notify users, install and configure a Domino server with QuickPlace overlay, move the QuickPlaces and run QPMove.The majority of the difference relates to the member documents in Contacts1.nsf.

6.3.1 Member documents for LDAP usersOnce QPMove has run, you will also need to edit each member document in the Contacts1.nsf for every QuickPlace in order for the user to be authenticated against a secondary LDAP directory instead of a local one.

The fields that are important to change are:

� h_password

This field must be blank.

� h_FromWhere

This field tells QuickPlace which directory users need to be authenticated with. It must contain the LDAP directory name and h_UserTypeLDAP in the string. Refer to “Step 6: Edit fields in the contacts1.nsf database” on page 127 for detailed definitions of the h_Password and h_FromWhere fields.

� h_FirstName and h_LastName

These fields must contain the user’s first and lastname as stored in the LDAP directory.

� h_Alias

This field must contain the fully distinguished LDAP user name as it appears in the LDAP directory.

Note: When LDAP users are authenticated with their LDAP server, the users’ names need to be in the format the LDAP server understands. This username is stored in the h_Alias field. Be sure to verify the LDAP schema for your LDAP server. In our example we referred users to an iPlanet directory server, where the format of the LDAP name is:

uid=EGreen/ou=people/dc=lotus/dc=com

For more information on LDAP Authentication, refer to “External directories” on page 57.


Figure 6-4 shows an example of an LDAP member document with all completed fields.

Figure 6-4 An LDAP Member document

6.4 User migration caveatsMigrating users from local lookup and authentication to a secondary directory is painless if each username is unique. One of the most common problems occurs if there are variations of the users’ names, with many QuickPlaces and many different managers. In such cases, when a local user is added to the place, the user can be known by several different names. For example, the user Rob Novak has an entry in the LDAP server. However, he has been added to a number of QuickPlaces as Robbie Novak, Bob Novak, Robert Novak, and Roberto Novak.

QuickPlace uses Authors and Readers fields throughout to determine access rights to a particular element such as a room, page, or folder. A user’s distinguished name needs to be uniform and be updated in every ACL, Authors and Readers field, throughout the whole of QuickPlace during the migration. This updated name change ensures that the user is successfully authenticated with the Domino/LDAP server and that once signed in, the user is able to retain the same access level to the place and all it’s elements.


If the name is not consistent and uniform, the user could encounter problems such as not seeing a room they once had access to or not being able to edit a document they were the author of.

The challenging part of the process is ensuring there are no variations of the same user name, so that only one name corresponds with their directory entry. If not, you will need to standardize the name across Quickplace. For example, Rob’s name will have to be standardized to ensure successful authentication with the LDAP directory.

The field names that contain this information are standardized across the product. These fields are:

� h_Authors

� h_Readers

� h_Originator

Updating all of these fields manually in all places for each user would be a very time-consuming process. We recommend you talk to your developers and ask them to create a series of agents to help you automate this task.

6.4.1 Going live: some factors to considerThe high-level migration procedures we have outlined assume a very generic configuration. Since no QuickPlace migration will be the same, however, there are some factors that you need to consider when developing your migration plan.

� Total zero downtime

It will be very difficult for you to achieve zero downtime when performing a migration. The main reason is that the destination server will need to be shut down to perform QPMove. You will need to consider performing this migration over a non-working day to cause minimum distruption to users.

� Time zone issues

There may be a situation where your organization has piloted QuickPlace in local offices and you are trying to migrate these pilots to one central production server. If your organization is widely dispersed, spanning several time zones, you need to be aware of the time zone when coordinating the migration.

� Retaining bookmarked URLs


Migrating from a pilot to production server means users will need to refer to a new URL for their bookmarked places. It will be very difficult to map any existing bookmarked URLs seamlessly to the new production server. Notify the users that they will need to update their bookmarks prior to the move. During the intermediate period, it’s a good idea to provide them with a page that informs them of the new URL along with the link whenever they try to log on to the old URL.

� Local directory migration

If you are moving thousands of users from local directory authentication to a secondary directory (LDAP/Domino), you may want to consider a co-existence period. This means that local user authentication will still work as you migrate users gradually over to the secondary directory only authentication, allowing you to edit the contacts1.nsf databases in stages.

Inform all QuickPlace managers that once the servers are migrated, all new members added to a Place should be looked up from the defined directory. This policy will help you during the co-existence period.

Once all users are migrated and are able to sign in with their user name and password from the secondary directory, you can edit the QuickPlace administration settings to now disallow local users.

6.5 SummaryIn this chapter we provided guidelines for situations where you need to migrate your QuickPlace installation. You might see this situation when you need to proceed from the pilot to production, or if you have had a standalone installation and you need to move to a overlay installation. We also described what you need to do if you move to an overlay installation with an external directory.

In this chapter we also provided details about how to use the QPMove utility.


Chapter 7. Integrating QuickPlace with other software technologies

Generally it is the case that, when you are planning for a production deployment of QuickPlace, the needs of your organization require integrating the existing solutions your organization has with the QuickPlace you are about to deploy.

In this chapter we describe the key points to extending and connecting your QuickPlace with the most prevalent products in use in the marketplace.

Integration with the following products is described: Lotus Workflow, Lotus Sametime, and Microsoft Office. We also give you detailed guidelines for how to integrate QuickPlace with IBM WebSphere Portal Server.

7


7.1 Integration with Lotus WorkflowThe integration between QuickPlace and Lotus Workflow gives users the ability to efficiently develop a collaborative business environment in an organization.

In this section we describe a business case developed by the Lotus Workflow Product Management Team to illustrate how to do this.

7.1.1 Process management and Web collaboration togetherLotus QuickPlace is an easy-to-use Web collaboration tool that gives distributed teams the ability to instantly create places to share documents, collaborate, and manage projects over the Internet.

QuickPlace also offers a user-configurable workflow capability to route documents. This native workflow facility is appropriate for simple processes, such as managing document reviews.

However, when an organization needs to manage document content in a larger business context, or manage complex business processes, Lotus Workflow is the preferred tool. When Lotus Workflow is combined with QuickPlace the user can create collaborative workspaces with enterprise process management.

Using the Workflow graphical tools to design and track workflow jobs, organizations can automate their critical business processes by leveraging Domino's secure messaging and collaboration services. In this section, we explore how Lotus Workflow can be used to provide process management to QuickPlace applications. We begin by describing a business scenario and then discuss the high-level integration steps.

Business scenarioLet's imagine a scenario where a organization will be launching a new product at an industry trade show in another city. In preparation for the launch at the show, the event staff needs to orchestrate the activities of the product development team, a public relations firm, some independent contract writers and the event's organizers.

Beyond the simple need to share information and track the status of tasks, the event staff will need to consolidate information from all of these sources for publication on their Web site during the show.


The Web publishing requirement presents the following challenges:

1. Some members do not have access to systems and data that reside behind the firewall because they are not employees; however, they are part of the extended event team.

2. Independent contract writers, who will write articles concerning activities at the show, may have to submit their stories via a Web browser.

Of particular concern is an organization policy which dictates that all Web-bound content must pass through an established Web publishing system that ensures that both text and images are reviewed and approved by members of the legal department and the website development team.

Solution proposalCombining QuickPlace with a Web content management system developed using Lotus Workflow allows developers to quickly architect a solution with the following characteristics:

� A Lotus QuickPlace will be created to give secure access to a centralized repository to users outside the corporate firewall. A custom form will be created in the QuickPlace that journalist will use to submit their stories to the existing Web content management solution.

� When a page created with the custom form is published, a Lotus Workflow job will be initiated.

� For the duration of the workflow, users accessing the page via QuickPlace will be automatically navigated to the workflow application.

Integration pointsAs products that were designed to be easily extended, both Lotus Workflow and QuickPlace offer fairly straightforward interfaces for the type of integration required in this business scenario. We first discuss the mechanism by which a workflow job can be initiated remotely, and then take a look at how QuickPlace can leverage it.

Table 7-1 Workflow initiation methods

Initiation method Description

Manually A user creates a job via the Workflow application's interface. This is the most common method of job initiation.

Mail-based initiation A message is routed to the Workflow database (which has been configured as a mail-in database in Domino). The routing process, called the “Backgrounder,” initiates from the message based on settings in the application setup document.

Chapter 7. Integrating QuickPlace with other software technologies 135

To support the sample application, the user could initiate a job in our scenario using either mail-based or form-based initiation. Form-based initiation offers more flexibility, so this is the approach we will use. Since both the QuickPlace and Lotus Workflow applications run on Domino servers, we can route a document with the reserved fields from the QuickPlace to the Lotus Workflow database.

Form-based initiation Table 7-2 describes the fields required for form-based initiation. When a document with these fields is created in a Lotus Workflow application, the routing process, or “backgrounder,” will initiate a job based on the values of these reserved items.

Table 7-2 Required fields for form-based initiation

Form-based initiation A document is created with items with reserved names. The backgrounder initiates a job based on the values contained in these items.

Field name Purpose

NewProcessNameOS Determines which process should be started by the form.

NewJobNameOS Determines the name of the job started by the form.

NewJobPriorityOS Determines the job priority.

MailStatusOS A button in the form displays a keyword list.

If the field is empty ("") or contains "2," the document becomes the main document in the binder. If the field contains "3," the document will be deleted. If the field has any other content, the document becomes a binder document.

InitiateOS If the field is empty, or contains "No," the document won't be used to start a job. If the field contains "Yes," the document will start a job based on the other fields in this table.

ExternalInitiatorOS This field can optionally be used to specify the name of the person responsible for initiating this new job. The value of this field is transferred to the cover document during initiation. Within the process design, this field can be referred to using the Job Property "External Initiator." We recommend using a canonicalized user name.

Initiation method Description


Now that we've identified our approach for initiating the workflow job, we have to determine how the QuickPlace can route the document to the Workflow application database. Luckily for us, QuickPlace offers a fairly simple mechanism to accomplish this task: PlaceBots.

Creating PlaceBotsPlaceBot is the QuickPlace name for the LotusScript or Java agents most Domino developers are familiar with. In the customizing facility available to QuickPlace administers, it is possible to upload ScriptCode or Java agent source code and specify a trigger. PlaceBots can be scheduled or executed when a particular type of document is published. Since time is of the essence in our scenario, we'll want to create an agent that sends a document with the form-based initiation fields as soon as a story is published.

Development stepsNow that we've identified the basic mechanism we plan to use to initiate a workflow job (a PlaceBot mailing a document that contains special values to the workflow application), let's take a look at the high-level steps required to deliver the solution. They are:

1. Identify or create the Lotus Workflow application. Be sure to enable Advanced Initiation.

In our business scenario, this step is already completed. The important point here is that Workflow does not require any special effort when designing the process or developing the application to take advantage of form-based initiation. The only requirement is verifying that advanced initiation is enabled by following the next two steps.

2. Identify or create the QuickPlace.

Creating a QuickPlace is as easy as accessing the QuickPlace server and submitting a form containing a few fields. Our integration scenario does not require any special steps when creating a QuickPlace.

3. Create a custom form for a news item (the default QuickPlace page could also be used but we want to add some special fields that are specific to our application).

QuickPlace offers a customizing facility, which allows developers to easily create custom forms.

4. Create a PlaceBot that will send mail to the Workflow application when a page is created with our custom form.

To support our integration scenario, we create a LotusScript agent that does the following:

a. Accesses the page being published via the NotesSession's DocumentContext property


b. Creates a new document containing the pertinent information from the published QuickPlace page, as well as the fields required for form-based initiation

c. Mails the new document to the Lotus Workflow application

d. Updates the published page so that users are redirected to the Workflow application when they open the page in the QuickPlace (activate the pages link)

5. Ensure that advanced initiation is enabled in our Workflow application so that the routing process (the backgrounder) knows to look for documents containing the form-based initiation fields. Follow these steps to verify that advanced initiation has been enabled in the application database:

a. Open the Administration Setup document in the application database.

b. Select the Enable Advanced Initiation option on the Initiation Settings tab.

Before we review the PlaceBot LotusScript code (Example 7-1), let's take a moment to understand in detail how to redirect users when they open a page in a QuickPlace.

Redirection in QuickPlaceQuickPlace offers a fairly simple mechanism for directing the user to a specified URL when a page is opened. To redirect a Web user to a URL different than the QuickPlace page they are opening, follow these steps:

� Set the value of the page's h_Form field to the reserved redirect document ID 256C05A2026AE284052568B0005C0B6D. You may want to retain the previous value of this field so you can restore it after the workflow job is complete.

� Set the h_URLPointer field to the URL to which the user is to be redirected.

� Set the h_URLNewWindow item to “Yes” or “No,” depending on whether or not a new browser window opens when the user is redirected.

Example 7-1 PlaceBot example for integration to Lotus Workflow

Sub Initialize Const QP_LINKFORM_UNID = "256C05A2026AE284052568B0005C0B6D" '--- reserved unid for QuickPlace link form Dim ns As New NotesSession Dim dcQP As NotesDocument Dim dcLWF As NotesDocument Dim stJobName As String Dim stKey As String Dim var var = Evaluate( "@Unique" )


stKey = var( Lbound( var ) ) Set dcQP = ns.DocumentContext '--- get reference to note associated with QuickPlace page '--- create document that will be mailed to the LWF database Set dcLWF = dcQP.ParentDatabase.CreateDocument() '--- create the document to be mailed Call dcQP.CopyAllItems( dcLWF ) '--- capture all page information. You could alternatively copy only the relevant items '--- store info about QuickPlace page so we can update it later dcLWF.h_FormOld = dcQP.h_Form '--- preserve h_Form value so we can restore it when workflow is completed dcLWF.QP_UnId = dcQP.UniversalID '--- set form-based initiation items dcLWF.NewProcessNameOS = "News Content Management" stJobName = "News Item " & ns.UserName & " " & Now() dcLWF.NewJobNameOS = stJobName dcLWF.NewJobPriorityOS = "High" dcLWF.MailStatusOS = "2" '--- will become main document dcLWF.InitiateOS = "Yes" dcLWF.ExternalInitiatorOS = dcQP.Author dcLWF.DocKey = stKey dcLWF.Form = "News" Call dcLWF.Send( False, "LWF Response@Dharma" ) '--- mail to LWF database (configured as a main-in database) '---- prepare QuickPlace page for redirect dcQP.h_Form = QP_LINKFORM_UNID dcQP.h_URLNewWindow = "Yes" '--- open workflow doc in its own window dcQP.h_URLpointer = "http://workflowserver/lwf/tradeshow/app.nsf/vwNewsByKey/" & stKey '--- url to which we'll redirect Call dcQP.Save( True, True )

End Sub

To create the PlaceBot, follow these steps:

1. Save the preceding LotusScript code in a text file with an LSS extension (for example, placebot.lss).

2. From the QuickPlace customization facility (choose Customize from the Go sidebar), choose the PlaceBots link in the Advanced Customization Features section.

3. Choose the New Placebot link at the top of the page.

4. Provide values for the required fields and attach the LSS file containing the LotusScript code. Be sure to select our custom QuickPlace form in the “When should this PlaceBot run?” section. Selecting the custom form will cause our PlaceBot to be executed when a user publishes a page created with it. The


published document is exposed to the LotusScript agent via the Document Context property of the NotesSession class.

7.2 Integration with Lotus SametimeIt is difficult to get through a conversation about QuickPlace without hearing Lotus Sametime mentioned. QuickPlace and Sametime are marketed together, sold in a bundle together, and demonstrated together at conferences. And, in fact, a small piece of Sametime is incorporated into QuickPlace: the “Chat” link on a standard QuickPlace invokes Sametime 1.5 services that install and run silently on a standard QuickPlace server.

It is natural for the products to be marketed, sold, and demonstrated together since they are part of the collaborative framework for so many companies. QuickPlace provides the asynchronous, Web-based experience while Sametime provides the ubiquitous real-time experience. They are truly a powerful combination.

Despite all this togetherness, the QuickPlace and Sametime server products spent almost three years with separate technical implementations, not able to be installed together or easily used in the same application. Now, however, we are beginning to see innovations and progress with the release of tools and capabilities that make the products more of a technical fit with each other. Furthermore, Sametime and QuickPlace can be installed together beginning with QuickPlace 2.08.

Let’s look at some of the approaches to QuickPlace - Sametime integration.

7.2.1 Shared signonThe simplest approach to integration has little to do with the products talking to each other and more to do with the underlying Domino server. A user can sign on to QuickPlace and Sametime without having to re-authenticate if any of these conditions is true:

1. Sametime and QuickPlace are installed on two servers in the same domain, both as Domino overlay installations, with multi-server SSO turned on, and users log into either Sametime first or into a Domino database on the QuickPlace server first.

2. Sametime and QuickPlace are installed together (available beginning with QuickPlace 2.08) and users log into a Domino database first.


Both of these options can be accomplished with some configuration; however, the authentication across the two is not without its problems. QuickPlace uses a DSAPI filter for authentication, making trips back from QuickPlaces to Sametime resources unpredictable in terms of whether authentication will be re-requested. For more information on QuickPlace authentication, see 3.5, “QuickPlace authentication” on page 55.

7.2.2 Silent login using name and passwordIt is possible, using Java, for a user to log into Sametime silently. By passing a user name and password as parameters in a Java applet, a user in QuickPlace, Domino, or another Web page can authenticate with Sametime and use Sametime services.

Sample code pulled from an HTML page, which can be imported into QuickPlace, is shown in Example 7-2.

Example 7-2

<SCRIPT> document.writeln("<div class='apt' align='center'>"); document.writeln("<applet align='center' code=MeetingRoom.STSampleMeetingApplet name=MeetingRoomSample codebase='http://sametime.xyz.com/sametime/toolkits/java25/bin/' width=600 height=400 id=Applet1 MAYSCRIPT>"); document.writeln("<param name='cabinets'value='http://sametime.xyz.com/sametime/toolkits/java25/code/MeetingRoomSample.cab, http://sametime.xyz.com/sametime/toolkits/java25/bin/MeetRes25.cab, http://sametime.xyz.com/sametime/toolkits/java25/bin/CommRes25.cab, http://sametime.xyz.com/sametime/toolkits/java25/bin/STMeeting25.cab'>"); document.writeln("<param name='loginName'value='Rob Novak'>"); document.writeln("<param name='password'value='remyxo'>"); document.writeln("<PARAM NAME='MeetingID'value='My Meeting'>"); document.writeln("<PARAM NAME='MeetingName'value='My Meeting'>"); document.writeln("<PARAM NAME='ActivityCount'VALUE='5'>"); document.writeln("<PARAM NAME='ActivityClass1'VALUE='MeetingRoom.whiteboard.STSampleWhiteboardActivity'>"); document.writeln("<PARAM NAME='ActivityClass2'VALUE='MeetingRoom.appshare.STSampleAppShareActivity'>"); document.writeln("<PARAM NAME='ActivityClass3'VALUE='MeetingRoom.chat.STSampleChatActivity'>"); document.writeln("<PARAM NAME='ActivityClass4'VALUE='MeetingRoom.audio.STSampleAudioActivity'>"); document.writeln("<PARAM NAME='ActivityClass5'VALUE='MeetingRoom.video.STSampleVideoActivity'>"); document.writeln("</applet></div>");</SCRIPT>


Security considerations for this method are obvious. The username and the password are stored on the page as plain text. The only ways to capture the user’s password for transmission are to store it in a secured document, or to capture it in a cookie during login, which also requires session authentication. By passing even computed text across the network with a user’s password, you may be violating security policies. However, if this is not a great concern for your implementation of Sametime, this may be the simplest method for your organization to integrate Sametime and QuickPlace.

7.2.3 Silent login using name and tokenSametime presents the concept of tokens for silent login. Basically, a token is a computed value that, when passed to the Sametime server, allows a user to log in without their password. It is assumed to be more secure than a direct login, since the token is “generated” for the unique user, and requires that the user be authenticated to begin with.

There are two ways to generate a token for a user. One of these is based upon Domino agents, which are available in the STAUTHS.NSF database located on the Sametime server. Once a token is generated, it can be passed to the server in lieu of a password, and still allow the user to authenticate with the Sametime server.

An example of this follows in Example 7-3.

Example 7-3

<Script>document.writeln('<APPLET CODEBASE="http://sametime.xyz.com/sametimeapplets/" CODE="com.lotus.sametime.placechat.PlaceChatApplet" WIDTH="100%" HEIGHT="100%">');document.writeln('<PARAM NAME="archive" VALUE="VpApi.jar,PlaceChat.jar">');document.writeln('<PARAM NAME="nickname" VALUE="CN=Rob Novak/O=SNADEV">');document.writeln('<PARAM NAME="token" VALUE="(F7730696625DC5CB4C20492CF70FB58B)">');document.writeln('<PARAM NAME="placeids" VALUE="85256B030074E841">');document.writeln('<PARAM NAME="placenames" VALUE="TeamRM">');document.writeln('<PARAM NAME="bgcolor" VALUE="0xc0c0c0">');document.writeln('<PARAM NAME="send_button_label" VALUE=" Send ">');document.writeln('<PARAM NAME="conf_invitation" VALUE="Please, join my chat now!">');document.writeln('<PARAM NAME="conf_name" VALUE="My cool conference.">');document.writeln('<PARAM NAME="chat_menu_label" VALUE="Message...">');document.writeln('<PARAM NAME="sametimeserver" VALUE="', scodebase, '">');document.writeln('<PARAM NAME="statuslabel" VALUE=" ">');document.writeln('<PARAM NAME="namelabel" VALUE="Name">');document.writeln('<PARAM NAME="descriptionlabel" VALUE="Description">');document.writeln('<PARAM NAME="show_status_icon" VALUE="true">');


document.writeln('<PARAM NAME="default_status_active" VALUE="I Am Active">');document.writeln('<PARAM NAME="default_status_not_using" VALUE="Not using computer">');document.writeln('<PARAM NAME="default_status_away" VALUE="I Am Away">');document.writeln('<PARAM NAME="default_status_dnd" VALUE="Do Not Disturb Me">');document.writeln('<PARAM NAME="default_status_unresolved" VALUE="Unresolved">');document.writeln('<PARAM NAME="default_status_offline" VALUE="Offline">');document.writeln('<PARAM NAME="show_placename_tabs" VALUE="true">');document.writeln('<PARAM NAME="show_peoplelist_table_header" VALUE="true">');document.writeln('<PARAM NAME="show_user_status" VALUE="true">');document.writeln('<PARAM NAME="use_default_status_description" VALUE="false">');document.writeln('<PARAM NAME="show_multiple_logins" VALUE="false">');document.writeln('<PARAM NAME="user_regexp" VALUE="false">');document.writeln('<PARAM NAME="user_replacement_rule" VALUE="false">');document.writeln('</APPLET>');</Script>

The most difficult piece of this puzzle is generation of the token. Since agents cannot easily be set up to load when a page loads in QuickPlace (it is not impossible but requires deep customization), that method is of little use to the developer. The second method of generating a token is using the token generation function in the Sametime 2.5 Server Toolkit. This Toolkit was in alpha at the time of this writing; however, the token generation function did work. Generation of tokens using the server toolkit will open up a significant number of opportunities for integration between QuickPlace and Sametime.

An IBM Redbook is being prepared that describes how to use the Sametime 2.5 Server Toolkit. Check the Redbooks website for availability.

7.2.4 ApplicationsUsing the methods described previously, we were able to achieve integration of a Sametime applet into a QuickPlace page. We used a simple group chat applet, in order to see the people online and test the bidirectional chat feature. This particular example used the token method described. Figure 7-1 on page 144 shows the chat applet loaded inside a QuickPlace.


Figure 7-1 Chat applet from external Sametime server embedded in QuickPlace

As proof (both to ourselves and to our readers) that the applet was live, using the Sametime server, and real-time, we loaded a Sametime Connect client for users Rob and Viktor, who were connected to the Sametime server.

Figure 7-2 on page 145 shows that while using the chat applet established in the QuickPlace, Drew and Jesse indeed were authenticated (silently) with the Sametime server, while Viktor and Rob were using the Sametime Connect client. To our delight, we were even able to instantiate a private chat across the clients. As well, Jesse and Drew could enter into a private chat (outside the group chat) by double-clicking on each other’s name, and that private chat was secure.


Figure 7-2 Drew and Jesse appear in the Sametime Connect client while using the QuickPlace example

Once Drew and Jesse unloaded the QuickPlace page, they immediately disappeared from the Sametime Connect client, as indicated in Figure 7-3 on page 146. Since the applet was coded to a single page in QuickPlace and not to the theme, this is the expected behavior.

We anticipate that developers using the Sametime 2.5 Server Toolkit, tokens, and Java will develop some very interesting combined applications in the near future. This simple example is just the tip of the iceberg for integration between the two products.


Figure 7-3 After unloading the QuickPlace page, Drew and Jesse disappeared from the Sametime Connect client for other users

7.3 Integration with the WebSphere Portal familyThe IBM WebSphere Portal family provides a portal software infrastructure that allows you to bring together the software components you need to help you deliver tailored content to users. It provides a single point of interaction while allowing users the flexibility of content personalization.

The WebSphere Portal family Extend offering currently ships with a QuickPlace portlet ready to deploy in your organization. The QuickPlace portlet is also available for download from the IBM Portlet Catalog website. For this section, we assume that you have installed and configured your WebSphere Portal infrastructure and are ready to deploy the QuickPlace portlet. For more information on the WebSphere Portal family, visit the IBM WebSphere website at:

http://www.ibm.com/websphere/

The QuickPlace portlet displays a dialog that allows the user to launch Lotus QuickPlace. The portlet maintains a list of up to 6 favorite QuickPlaces. When the user selects a QuickPlace from the list of favorites, the QuickPlace is launched in a new browser window.


http://www.ibm.com/websphere/

7.3.1 Installation and configuration of the QuickPlace portletPlease note that this section assumes that you are running WebSphere Portal Server version 1.2, which is the current version at the time of this writing. All of the installation instructions and screen captures in this section refer to WebSphere Portal Server version 1.2. If you are installing the QuickPlace portlet on WebSphere Portal Server version 2.1, there will be slight differences in the installation procedure. For more information on configuration of the WebSphere Portal Server, see the appropriate product documentation.

Install the QuickPlace portlet1. Move the QuickPlace portlet .par file to the \app\DeployablePortlets directory

under the root WebSphere Portal Server directory on your server.

2. Log in to your Portal Server as the administrator.

3. Click the Administration tab.

4. Click Install. See Figure 7-4.

Figure 7-4 Installing a new portlet

5. On the installation page, click Browse and navigate to the DeployablePortlets directory where you copied the portlet file on your server.


6. Select the appropriate portlet (IBM_QuickPlace.par) and click Open. This is shown in Figure 7-5.

Figure 7-5 Select the appropriate portlet for installation

7. Click Import.

8. Verify that all the portlet information is correct and click Continue. (See Figure 7-6 on page 149.)


Figure 7-6 Verify that portlet information is correct

9. Verify that the installation completed successfully and click Finish. (See Figure 7-7 on page 150.)


Figure 7-7 Installation was successful

10.The portlet should appear in the list of portlets with a status of “Inactive.”

Activate the QuickPlace portlet1. On the Administration tab of your portal, select the QuickPlace portlet from

the list of installed portlets and click Activate. See Figure 7-8 on page 151 for details.


Figure 7-8 Activate the new portlet

2. Verify that the portlet information is correct and click Continue. (See Figure 7-9 on page 152.)


Figure 7-9 Portlet activation screen

3. Verify that the activation was successful and click Finish.

4. The portlet should appear in the list of portlets with a status of “Active.”

Set portlet access control1. On the Administration tab of your portal, scroll down to the Access Control

Administration section.

2. Select the user or group that you want to grant access to, the access level that you would like to grant, and the QuickPlace portlet; click Add. (See Figure 7-10 on page 153.)

In our example, we gave editing rights to our portlet to the group all-users.


Figure 7-10 Granting access to the portlet

3. Scroll down to the section containing the existing access rules and verify that the rule was added successfully. (See Figure 7-11 on page 154.)


Figure 7-11 Verify new access rule

Add the QuickPlace portlet to a portal page1. Click the Customize button on the upper right portion of the portal page.

2. Select the page where you would like the QuickPlace portlet to appear.

3. Select the QuickPlace portlet from the list of available portlets on the left side of the window and click the add button, which appears as a right arrow between Available portlets and Column1 lists, as shown in Figure 7-12 on page 155.


Figure 7-12 Add the QuickPlace portlet to a portal page

4. Move the QuickPlace portlet to the desired location using the arrows located below the Column1 and Column2 lists.

5. Click Save when finished, then click Close.

6. The QuickPlace portlet should appear on the designated portal page.

Edit the QuickPlace portlet1. Click the Customize button on the upper right portion of the portal page.

2. Select the page on which you placed your QuickPlace portlet.

3. Select the QuickPlace portlet and click the edit portlet button, shown in Figure 7-13 on page 156.


Figure 7-13 Edit the QuickPlace portlet

4. You can add up to six QuickPlaces that will appear in the drop-down list in the portlet. Be sure to add the full URI of each QuickPlace and a nickname for each one. See Figure 7-14 on page 157 for details and examples.


Figure 7-14 Add QuickPlaces to the portlet drop-down list

5. Click Save when finished.

6. Click Save again when you return to the layout customizer page.

7. The portlet should appear on the designated portal page with a drop-down list containing all of the QuickPlaces that you added.

Using the portlet1. Select the QuickPlace you would like to launch from the drop-down list of

QuickPlaces in the portlet.

2. Click Go. The portlet will launch the QuickPlace that you selected in a new window.


Figure 7-15 QuickPlace portlet in action

Figure 7-16 on page 159 is an example of how the portlet will appear when it is installed on WebSphere Portal Server version 2.1.

Note: You can also edit the QuickPlace portlet directly from the portal page if you have editor or higher access. A pencil icon will appear at the upper right corner of the portlet if you have editor access. To edit the portlet, click the pencil icon (see Figure 7-13 on page 156) and follow the instructions in the section “Edit the QuickPlace portlet” on page 155.


Figure 7-16 QuickPlace portlet installed on WebSphere Portal Server 2.1

7.4 Integration with Microsoft Office QuickPlace integrates tightly with Microsoft products for enhanced ease of use in several key ways:

� QuickPlace enables users to author content using any Microsoft Office 2000 application, and publish it automatically and seamless on the Web in HTML. Content created in Office, such as Excel spreadsheets and Word documents, is maintained in QuickPlace in its native format for easy updating, yet is instantly accessible to browsers. Team members can read Office-based content whether they have Office on their desktop or not, and regardless of what version of Office they are using.

� Office documents can be used as custom QuickPlace forms. In this way, new content created in QuickPlaces can have a standardized “look and feel,” and benefit from the formatting and data entry capabilities of the Office tools.


Directory integration with Windows NT and Microsoft Exchange makes it possible to register users in a QuickPlace directly from an Exchange directory, the NT domain directory, or any other LDAP-enabled directory (including the Domino Directory). QuickPlace can also seamlessly utilize existing LDAP directories for user authentication.

QuickPlace users can drag-and-drop Office documents and other content directly from their desktop into a QuickPlace.

Creating a QuickPlace page using Microsoft OfficeIf you are using Internet Explorer and Microsoft Word, Microsoft PowerPoint, and/or Microsoft Excel are installed on your computer, you can work with these programs within QuickPlace to create a QuickPlace page. You must use Office 97 or Office 2000 versions of these applications only; you cannot create QuickPlace pages using earlier versions of Word, PowerPoint, or Microsoft Excel.

When you begin creating a page using Word, PowerPoint, or Microsoft Excel, QuickPlace creates a temporary file for the page in the Temp subdirectory of your Windows directory. The temporary file has the file name QuickPlace Page x (where x is a number) and the file extension .DOC (for a Word file), .PPT (for a PowerPoint file), or .XLS (for an Excel file).

When you finish creating a page using one of these programs, QuickPlace copies the temporary file and converts it to HTML format, the format QuickPlace uses for displaying pages in your QuickPlace.

Use the following detailed steps to create a QuickPlace page using Microsoft Office products.

1. Enter the room in which you want to create the page. If you want to create the page in a folder, click the title of the folder in the sidebar.

2. Click New. If the New option does not currently appear on the screen, click a page or folder title in the sidebar.

3. Select Microsoft Word Page, Microsoft PowerPoint Page, or Microsoft Excel Page, and then click Next. If the program you want to use is not installed on your computer, the corresponding option does not appear in the list of options. For example, if Word is not installed on your computer, the option “Microsoft Word Page” does not appear.

4. Enter a title for the page in the box under “What is the title of this page?” Depending on the location you choose for the page, the title appears in the list

Note: You cannot attach files to a page you create using Word, PowerPoint, or Microsoft Excel.


of pages in the Index or sidebar or in a folder when you finish creating the page, allowing QuickPlace members to locate the page in the QuickPlace.

5. (Optional) To display the page title, your name, and the date you created the page at the top of the finished page, check the box next to “Show the title, author and date on page?”

6. Double-click the Word, PowerPoint, or Microsoft Excel file icon to start Word, PowerPoint, or Microsoft Excel.

7. In the Word, PowerPoint, or Microsoft Excel window, enter the contents of the page.

8. In the Word, PowerPoint, or Microsoft Excel window, select one of the following commands. Each of these commands saves your information in the file used to store the contents of the QuickPlace page.

– File Exit

– File Close

– File Save AsIf you select File Save As, specify the file to which you want to save the changes.

After you choose one of these commands, QuickPlace displays a message indicating it is converting the temporary Microsoft file into an HTML file.

9. Click one of the following options:

– SaveSaves the page in draft mode and leaves the page on the screen so you can continue working on it in the current editing session. When you are ready to end the current editing session, click Publish or Publish As.

– PublishIf you are creating a page for the sidebar, this option lets you select a location for the finished page and then publishes the page in that location, without requiring you to choose any special publication options. (Note that you must have manager privileges in the current room to create a page for the sidebar.) If you are creating a page in a folder, this option publishes the page in the folder; you can then skip the remaining steps in this procedure. If you are creating a page for the sidebar and you click Publish, continue on to the next step.

– CancelClick Cancel to abandon your work and return to the previous screen without creating a new page. If you click Cancel, you can skip the remaining steps in this procedure.


10.Under “Where would you like to put this Page?” choose one of the following locations:

– A folder title, for example, LibraryIf you don’t have author access to any folders in the current room, no folder titles appear. If you do have access to one or more folders and you choose a folder name, the page title appears in the list of pages in that folder and in the Index, which is a listing of all the pages in the current room.

– The sidebarThis choice is available only if you are a manager of the current room. If you choose Sidebar, the page title appears in the list of pages, folders, and rooms in the sidebar and in the Index. You can also indicate where in the sidebar you want the page title to appear by clicking the down arrow next to the text box and then clicking the name of the title above which the page should go.

– The IndexThe page title appears in the Index only.

11.Click Next.

7.5 SummaryIn this chapter we have described how to connect and integrate QuickPlace into the other application your organization might be using. Step-by-step instructions described how to connect QuickPlace into products such as Lotus Workflow, Domino.Doc, Lotus Sametime, and Microsoft Office.

Note: The Publish As option lets you select a location for the finished page and select one or more publication options. You can choose to notify a select set of QuickPlace members via e-mail that you created the page; limit the readership of the page; grant editing rights to the page to certain members; and/or add the page to the calendar in the current room. You can also use Publish As to save the page in draft form, so you can finish editing the page later in a future editing session. When you save a page in draft form, only you can access the edited page. For more information on these options, see the other sections in this chapter.


Related publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.

IBM Redbooks and RedPapersFor information on ordering these publications, see “How to get IBM Redbooks” on page 164.

� Customizing QuickPlace, SG24-6000

� Lotus Notes and Domino R5.0 Security Infrastructure Revealed, SG24-5341

� Lotus Sametime 2.0 Deployment Guide. SG24-6206

� Using Domino Workflow, SG24-5963

� Creating Customized Solutions with Domino.Doc, SG24-5658

� Domino and WebSphere Together Second Edition, SG24-5955

� Using LDAP for Directory Integration: A Look at IBM SecureWay Directory, Active Directory, and Domino. SG24-6163

� Getting the Most From Your Domino Directory, SG24-5986

� Working with the Sametime Client Toolkits, SG24-6666

� Working with the Sametime Community Server Toolkit, SG24-6667

� Lotus QuickPlace for AS/400 - Setup and Management Considerations, ITSO Redpaper, REDP0045

Referenced Web sitesThese Web sites are also relevant as further information sources:

� Lotus QuickPlace product web site

http://www.lotus.com/quickplace

� QuickPlace DevZone - technical resources

http://extranet.lotus.com/qpdevzone

� QuickPlace discussion forum

http://www.notes.net/quickplace.nsf


How to get IBM RedbooksYou can order hardcopy Redbooks, as well as view, download, or search for Redbooks at the following Web site:

ibm.com/redbooks

You can also download additional materials (code samples or diskette/CD-ROM images) from that site.

IBM Redbooks collectionsRedbooks are also available on CD-ROMs. Click the CD-ROMs button on the Redbooks Web site for information about all the CD-ROMs offered, as well as updates and formats.

164 Deploying QuickPlace164 Deploying QuickPlace

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



Index

Symbols?Logout command 81

AAccess control 61Access control list 19, 61ACL 19, 61, 65Active Directory 44, 55ActiveX 30Admin Utility 32Administering QuickPlaces 32, 42Administrator 14Agents 19Authentication 39, 55–56, 61, 141Authorization 40Availability 89Avoiding unwanted email 83

BBasic authentication 56Bowser cache 78Browser 11, 78

CCertificate Authority 69Certified ID 17Certifier hierarchy 18Chat 31, 140Client requirements 11Clustering 89

chat 93, 95configuring 113distributing the workload 92failover 90–91hardware 91HTTP thread settings 119IBM Webshere Edge Server 92IBM WebSphere Edge Server 91, 99–100installing 92network bandwidth 92number of users 91offline 93, 95

© Copyright IBM Corp. 2002

performance 119planning 90preparing QuickPlace servers 93replica manager 97settings 93third-party routing 116virtual memory 119what is? 90

Compatibility 12Configuring 7Contacts1.nsf 127Contatcs1.nsf 19Controlling access 19, 61Creating forms with Microsoft Office 159Creating pages with Microsft office 160Creating standards 5Customization 19, 134

DDefining standards 5Deployment considerations 6Directories 39Directory 42–43, 122, 129

Active Directory 44changing 43, 50clustering 44directory assistance 45Domino Server 44, 50integrating 44iPlanet 44LDAP 43, 57Microsoft Windows NT Server 43no directory 44secure LDAP 44selecting 43Windows NT Server 43

Directory assistance 45Active Directory 55clustered solution 48configuring 45creating an entry in the database 46creating the database 45document 46

165

group expansion 46indentifying 49LDAP 45, 50, 55LDAP over SSL 53replicas 48rules 46secure communication with LDAP 54setting up 45setting up channel encryption 54

Domino Directory 18, 33, 40–41, 122Domino security 60Domino Server 13, 17, 44, 57, 93

clustering 93on a iSeries 20running QuickPlace on top of 10

DSAPI 141

EEmail Domain 22Email integration 21Email notifications 23Email security 82Encrypting data 53, 62Extending 133

FFile attachment size limit 31Firewalls 85

GGroups 19, 42

Hh_members 19, 41Hardware requirements 10High availaility 89

IIBM WebSphere Edge Server 91, 99–100

configuring IBM Dispatcher 103IBM Dispatcher 102installation 101JRE 100preparing 100system requirements 100

IBM Websphere Edge Server 92IBM WebSphere Portal Server 147

Installation 7Admin Utility 32client requirements 11clustered solution 92compatibility 12creating a offline QuickPlace 25files 18network information 15offline services 25on a iSeries 20other options 30overlay install on Domino 9, 17planning 4, 8portlet 147QuickPlace servers in a cluster 92Sametime and QuickPlace together 140selecting a domain 41server requirements 10server settings 43standalone 9, 13starting the QuickPlace server 23stopping the QuickPlace server 23system requirements 10types 8–9user directory 43

Installation steps 8Installation types 8–9Installing the Admin Utility 34Integrating 133iPlanet 44iSeries 11, 20

JJava 30

LLDAP 40, 55, 57, 129Lightweight Third Party Authentication 58Logging users off 78Logout command 81Lotus Sametime 13, 95, 140Lotus Workflow 134LTPA 58

MMacintosh 11Mail Settings 21


Maintaining QuickPlaces 32Member list 19Microsoft 43Microsoft Internet Explorer 11, 78Microsoft Office 159Microsoft Windows NT Server 43Migrating 122, 129–130Migrating pilot to production 122Modifications 18

NNames.nsf 33, 40Netscape Navigator 11, 79nQuickPlaceAdmin.dll 33nQuickPlaceAdmin.exe 33

OOffline passthru server 31Offline services 25, 86Organisational unit 19Overlay installation 3

PPiloting 121PlaceBots 4, 19, 30, 137

creating 137developing 137example 138redirection 138

PlaceType 3Planning for a pilot 121Planning the deployment 4Portlet 147pSeries 11

QQPMove 122, 124–125, 129QuickPlace architecture 41QuickPlace portlet 147QuickPlace security 60QuickPlace server 2–3, 34

clustering 44, 90configuring 7connecting 133directory 39, 43Email Domain setting 22from standalone to overlay w/ Domino Directory

122from standalone to overlay with LDAP 129in a separate Domino Domain 42installation types 8installing 7integrating with Sametime 140offline services 25overlay install on Domino 9overlay installation 3receiving email 22running as a service 23security 59sending mail 23SMTP Server settings 21SSL 76standalone 9starting the server 16stopping the server 16user directory 39, 43version compatibility 12

QuickPlace-Sync 25

RReceiving mail 22Redbooks Web site 164

Contact us xiiRedirection 138Reliability 89

SSametime 13, 95, 140

applications 143chat 140silent login 141–142

Scalability 89Secure communication with LDAP 54Secure LDAP 44Secure Sockets Layer

See SSLSecurity 39–40, 42, 53, 59

access control 61access levels 61anonymous access 60authentication 39, 55certifier hiearchy 18certifier ID 18clearing the browser cache 78database access 61

Index 167

DMZ 86email 82enabling SSL on a server 76encrypting 62firewalls 85logging users off 78offline QuickPlace 86scanning for viruses 83, 85server access 60server ID 19Single Sign-On 55, 57–58SSL 53, 62SSO 55, 57–58username and password 56using offline 86virtual private networks 62X.509 certificates 78

Selecting a Domain 41Sending Mail 23Server requirements 10Setting up Single Sign-On 57Signing 18Single Sign-On 55, 58, 141SMTP Server settings 21Software requirements 10Solaris 11SSL 62

Certificate Authority 69creating a key ring file 65enabling on a server 75encrypting data 62key ring file 67offline services 77on a Domino overlay QuickPlace server 62on a Domino Server 76on a QuickPlace 77on a standalone server 62on all QuickPlaces 76securing the QuickPlace environment 62server certificate 69Server Certificate Admin application 64using offline 86

SSO 55, 57–58, 141Standards 5Starting the QuickPlace server 16Stopping the QuickPlace server 16System requirements 10, 32

TTesting 121Theme 4

UUser directory 43, 50

changing 42Using QuickPlaces offline 25

VViews 41Virtual private networks 62Viruses 85

WWeb authentication 56, 61Web security 61Windows 2000 12Windows NT Server 10, 43Workflow 4, 134Working offline 25

XX.509 certificates 78

ZzSeries 11


(0.2”spine)0.17”<->0.473”

90<->249 pages

Deploying QuickPlace

®

SG24-6535-00 ISBN 0738424420

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

DeployingQuickPlaceInstall, configure, and deploy QuickPlace

Security and availability considerations

Real-world examples of integration with other technologies

Lotus QuickPlace is the leading self-service Web tool for team collaboration. With QuickPlace, teams can share a virtual workspace to communicate, collaborate, and coordinate. People can create and share documents and knowledge, discuss ideas, coordinate tasks, do project management, just to mention a few of the features that QuickPlace offers.QuickPlaces are created for a variety of reasons. They can serve as collaborative workspaces for teams, they can be created for projects that live only a limited time, and they can be used to help communicate and work together with people outside the company boundaries.This IBM Redbook shows you how to install, configure, and deploy QuickPlace in your organization. It gives step-by-step installation instructions for the QuickPlace server, and describes how to configure it to use the directories your organization already has. The book includes tips for planning your QuickPlace environment to be scalable, and describes how to install and configure QuickPlace clusters. Detailed instructions as well as examples are presented.Since QuickPlaces generally contain sensitive information, we discuss the security aspects of the QuickPlace server in detail and describe how to make a QuickPlace installation secure. And, because the number of users and QuickPlaces in an organization tend to expand quickly, we present techniques to manage this growth and the challenges it presents.The deployment of a new solution or product such as Lotus QuickPlace often starts with a pilot. We discuss issues you should consider when planning for such a pilot, and provide information on how to migrate a pilot installation into a full production environment. Examples of migration scenarios are also given.QuickPlace complements many other solutions your organization probably already has in place, and is designed to integrate easily with them. This redbook tells you how to extend QuickPlace by connecting it to other solutions such as Lotus Sametime, Lotus Workflow, and WebSphere Portal Server.

Back cover

Deploying QuickPlace - IBM Redbooks · any form without payment to IBM, for the purposes of...

Documents

Transcript of Deploying QuickPlace - IBM Redbooks · any form without payment to IBM, for the purposes of...