Redbooks Wiki: Optimizing Lotus Domino Administration

1

Table of Contents

Part 1. Getting Started ............................................................................................................... 8 1.1. Documentation ............................................................................................................... 8

1.1.1. Content to document ............................................................................................. 8 1.1.2. Server Details ........................................................................................................ 9 1.1.3. Architecture Overview ........................................................................................... 9 1.1.4. Security Standards .............................................................................................. 14 1.1.5. Backup Standards ............................................................................................... 14 1.1.6. Naming Standards............................................................................................... 15 1.1.7. Instructions for End Users ................................................................................... 17 1.1.8. Conclusion........................................................................................................... 18

1.2. Daily, Weekly, and Monthly Checklist .......................................................................... 19 1.2.1. General recommendations .................................................................................. 19 1.2.2. Actions ................................................................................................................. 20 1.2.3. Conclusion........................................................................................................... 23

1.3. Security Checklist......................................................................................................... 24 1.3.1. Additional References ......................................................................................... 25

1.4. Domino Authentication Options.................................................................................... 26 1.4.1. Choosing the Domino Authentication Options..................................................... 26 1.4.2. SmartCards (1) .................................................................................................... 27 1.4.3. Lotus Notes and HTTP Password Synchronization (3)....................................... 27 1.4.4. LDAP (4 and 5).................................................................................................... 28 1.4.5. SPNEGO (6)........................................................................................................ 28 1.4.6. Lotus Notes and Operating System Single-Sign On (7)...................................... 29 1.4.7. Tivoli Directory Integrator (9) ............................................................................... 30 1.4.8. Additional Resources........................................................................................... 30

1.5. Agents and the Domino Administrator ......................................................................... 31 1.5.1. Agent Triggers ..................................................................................................... 31 1.5.2. Determining Which Agents Are Scheduled to Run on the Server....................... 32 1.5.3. Agent Manager Settings That Affect Agent Execution ........................................ 32 1.5.4. Full Text Searches and Agents ........................................................................... 33 1.5.5. Performance Impact of New Agents and Applications ........................................ 34 1.5.6. Troubleshooting Problems with the Agent Manager Task .................................. 34 1.5.7. Writing an Agent .................................................................................................. 34

1.6. Expanding the Domino Domain ................................................................................... 35 1.6.1. Registering and Securing a New Server ............................................................. 35 1.6.2. Replicating Critical Databases............................................................................. 36 1.6.3. Mail Routing......................................................................................................... 39 1.6.4. Monitoring and Managing Multiple Servers ......................................................... 40 1.6.5. Clustering............................................................................................................. 40

1.7. Design, Replication, and Mixed Releases: Avoiding Design Ping-Pong ..................... 41 1.7.1. Description of the Problem .................................................................................. 41 1.7.2. Preventing the Problem....................................................................................... 41 1.7.3. Working with Mixed Clusters ............................................................................... 43

1.8. Routine Maintenance Best Practices ........................................................................... 44 1.8.1. Fixup and Transaction Logging ........................................................................... 44 1.8.2. Regular Maintenance .......................................................................................... 44 1.8.3. Database Corruption ........................................................................................... 45 1.8.4. Hard Disk Fragmentation..................................................................................... 45

1.9. Mobile Access .............................................................................................................. 46 1.9.1. Traveler................................................................................................................ 46 1.9.2. BlackBerry ........................................................................................................... 48 1.9.3. Lotus iNotes Ultra-Lite ......................................................................................... 50 1.9.4. IMAP/POP ........................................................................................................... 52

2

Part 2. Managing Users and Clients ........................................................................................ 54 2.1. Optimizing Lotus Notes Client Administration Tips ...................................................... 54

2.1.1. General Client/User Management Tips ............................................................... 54 2.1.2. Recent Contacts .................................................................................................. 55 2.1.3. Local Replicas ..................................................................................................... 55 2.1.4. Smart Upgrade .................................................................................................... 56

2.2. Managing a User's Inbox.............................................................................................. 57 2.2.1. Using Inbox maintenance to manage mail file size ............................................. 57 2.2.2. Quota Enforcement Options................................................................................ 58 2.2.3. Quotas with DAOS Enabled ................................................................................ 58 2.2.4. Enforcing Quotas on Local Replicas ................................................................... 59

2.3. Policies ......................................................................................................................... 59 2.3.1. Introduction to Policies ........................................................................................ 59 2.3.2. Using Policies to Standardize Secure and Simplify Your Environment .............. 60

Part 3. Effective Server Administration .................................................................................... 65 3.1. Monitoring..................................................................................................................... 65

3.1.1. Monitoring Options .............................................................................................. 65 3.1.2. What should be monitored? ................................................................................ 66 3.1.3. Monitoring Profiles for Domino ............................................................................ 66 3.1.4. Domino Event Monitoring .................................................................................... 75 3.1.5. Further Reading................................................................................................... 79

3.2. Mail Routing ................................................................................................................. 80 3.2.1. Managing Spam .................................................................................................. 80 3.2.2. Mail routing and multiple directories.................................................................... 81 3.2.3. Journaling ............................................................................................................ 82 3.2.4. Out of Office Notification...................................................................................... 85 3.2.5. Mail routing in a clustered environment............................................................... 85

3.3. Mass Mailings............................................................................................................... 87 3.3.1. The Mass Mailing Problem.................................................................................. 87 3.3.2. The Mass Mailing Solution .................................................................................. 88 3.3.3. Conclusion........................................................................................................... 94

3.4. Multiple Directories....................................................................................................... 94 3.4.1. Condensed Directory Catalog, Extended Directory Catalog or Directory Assistance 94 3.4.2. Hints and Tips...................................................................................................... 95

3.5. Server Clustering Options ............................................................................................ 96 3.5.1. Keep It Simple ..................................................................................................... 96 3.5.2. Redundant Domino Parts .................................................................................... 97 3.5.3. Domino Cluster.................................................................................................... 98 3.5.4. OS Cluster ......................................................................................................... 100 3.5.5. Internet Cluster Manager (ICM)......................................................................... 102 3.5.6. iNotes High Availability Configuration ............................................................... 103 3.5.7. IMAP failover (Domino 8.5 new feature) ........................................................... 103 3.5.8. Lotus Traveler Server High Availability ............................................................. 103 3.5.9. Load Balancer ................................................................................................... 104 3.5.10. Software proxy (IBM HTTP, nGinx, etc) ............................................................ 105 3.5.11. Sametime and QuickR High Availability ............................................................ 105 3.5.12. Disaster Recovery Plan ..................................................................................... 106

3.6. Transaction Logging................................................................................................... 106 3.6.1. General Transaction Logging Recommendations for 8.5.x Servers ................. 106 3.6.2. Transaction Logging Tips .................................................................................. 107 3.6.3. NOTES.INI Recommendations for Domino 8.5.x Servers ................................ 107 3.6.4. Domino 8.5.x and ODS 51 Updates .................................................................. 108

3.7. Domino Attachment Object Service (DAOS) ............................................................. 109 3.8. Managing Domino Indexing ....................................................................................... 111

3.8.1. View Indexes ..................................................................................................... 111

3

3.8.2. Full Text Indexes ............................................................................................... 112 3.8.3. Domain Indexes................................................................................................. 116

3.9. Backup a Domino Environment.................................................................................. 116 3.9.1. Backup Basics ................................................................................................... 118 3.9.2. Backup Strategy ................................................................................................ 118 3.9.3. Backup Software ............................................................................................... 122 3.9.4. What to back up................................................................................................. 123 3.9.5. Backup procedures............................................................................................ 124 3.9.6. Backup Scripts................................................................................................... 126 3.9.7. Recommendations............................................................................................. 127 3.9.8. Summary ........................................................................................................... 128 3.9.9. Reference Reading............................................................................................ 128

3.10. Restore .................................................................................................................. 128 3.10.1. Disaster Recovery ............................................................................................. 129 3.10.2. Static File Recovery........................................................................................... 130 3.10.3. Domino Data File Recovery............................................................................... 130

3.11. Procedure to Restore Deleted Documents on IBM i.............................................. 136 3.11.1. Operating Type Save Restore Procedure ......................................................... 137 3.11.2. BRMS Full Save Restore Procedure................................................................. 138 3.11.3. BRMS Incremental Save Restore Procedure.................................................... 140 3.11.4. Additional Resources......................................................................................... 141

3.12. The Domino HTTP Server ..................................................................................... 141 3.12.1. General Server Configuration............................................................................ 141 3.12.2. iNotes................................................................................................................. 141 3.12.3. Troubleshooting and Tuning.............................................................................. 142 3.12.4. Additional References ....................................................................................... 142 3.12.5. Some Tips.......................................................................................................... 142

3.13. Domino HTTP Server Security .............................................................................. 143 3.13.1. Server Access ................................................................................................... 143 3.13.2. User Security and Authentication ...................................................................... 145 3.13.3. Database Security ............................................................................................. 146 3.13.4. File System Security.......................................................................................... 150

3.14. Setting up a Redirection Application for Lotus iNotes users.................................. 151 3.14.1. Create the iNotes Redirect Application ............................................................. 151 3.14.2. Configure the iNotes Redirect Application......................................................... 152 3.14.3. Configuring the iNotes Redirect Application as the Default Home Page .......... 156

3.15. Securing Lotus iNotes............................................................................................ 158 3.15.1. iNotes and the Notes ID files............................................................................. 158 3.15.2. Active X Controls ............................................................................................... 158 3.15.3. Browser Cache Management............................................................................ 159 3.15.4. Encrypting Offline Databases............................................................................ 160 3.15.5. S/MIME.............................................................................................................. 161

Part 4. Tuning the Environment ............................................................................................. 162 4.1. Health Check.............................................................................................................. 162

4.1.1. High Level Checklist for Health Check .............................................................. 162 4.1.2. Performing the Health Check ............................................................................ 163

4.2. Document Configuration Tuner (DCT) ....................................................................... 172 4.3. Establishing a Performance Baseline ........................................................................ 173

4.3.1. Recommended Metrics...................................................................................... 174 4.3.2. Collecting Domino Statistics .............................................................................. 175 4.3.3. Reporting Database........................................................................................... 175

4.4. Domino Tuning Tips (all platforms) ............................................................................ 176 4.4.1. View Index Updates........................................................................................... 176 4.4.2. Disable Transaction Logging For Certain Databases ....................................... 177 4.4.3. Replication......................................................................................................... 177 4.4.4. Internal Caches ................................................................................................. 179

4

4.4.5. Multiple Mail Boxes............................................................................................ 181 4.4.6. Tips for Server Based Mail Rules...................................................................... 181 4.4.7. Tuning User Sessions ....................................................................................... 181 4.4.8. Domino Configuration Tuner (DCT) .................................................................. 182

4.5. Tuning for Virtualized Environments .......................................................................... 182 4.5.1. The Pros and Cons of Virtualization.................................................................. 182 4.5.2. Static Resources ............................................................................................... 183 4.5.3. Best Practices for Guest VM ............................................................................. 183

4.6. Domino on Windows Tips .......................................................................................... 185 4.6.1. System Page Pool ............................................................................................. 185 4.6.2. Other Tuning Tips for Windows Servers ........................................................... 186 4.6.3. Additional references......................................................................................... 186

4.7. Domino on Linux Tips ................................................................................................ 186 4.7.1. Monitoring Server Resources............................................................................ 186 4.7.2. Operating System Limits ................................................................................... 186 4.7.3. Linux Services ................................................................................................... 187 4.7.4. TuneKrnl ............................................................................................................ 187 4.7.5. Troubleshooting and Debug Tips ...................................................................... 187 4.7.6. Disabling concurrent I/O and direct I/O on Domino servers on AIX.................. 188 4.7.7. Tuning Java for Domino on AIX ........................................................................ 188 4.7.8. Perfpmr for AIX.................................................................................................. 188

4.8. Domino on IBM i Tips................................................................................................. 188 4.8.1. Overview............................................................................................................ 188 4.8.2. Performance ...................................................................................................... 189

4.9. Tuning Tips for the Domino HTTP Server.................................................................. 192 4.9.1. HTTP Server Threads ....................................................................................... 192 4.9.2. HTTP Requests ................................................................................................. 193 4.9.3. JVM Heap.......................................................................................................... 193 4.9.4. Database Performance...................................................................................... 194

5

0.1 Preface

Note: This PDF document is the original text from the Optimizing Lotus Domino Administration wiki found in the URL in which this document originated. Always refer to the wiki version for the latest updates.

This IBM Redbooks wiki provides you with information on how to optimize Lotus Domino administration. The focus is to provide Lotus Domino administrators with information on how to get most of their valuable time.

Optimization of a Lotus Domino environment is not only a matter of how to set specific configuration parameters on a server or on a client; it is more a conceptual approach on how to address specific needs of the environment.

In this Redbooks wiki, we share our experiences and industry best practices about how an optimized and smart Lotus Domino environment should look like and the checklists and steps you should perform to ensure a smooth and optimized Domino environment. Ideas and concepts presented here are meant to be an introduction, and are not meant to be a complete list. If there are existing wiki articles, technotes, or whitepapers available that have detailed discussion on the topics being presented we provide the reference links.

Using this wiki

Each article in this Redbooks wiki is intended to be used stand-alone. However, you can navigate back to the TOC and access all of the articles in the series by clicking the "Table of Contents" link at the top of each article.

6

0.2 About the Authors

This book is produced by a team of specialists from around the world.

Paul Band is a certified IT specialist with IBM Software Services for Lotus in the UK. He has been working with Lotus software within IBM for 10 years, having started with Domino Development in R4.6. Paul has worked on countless customer engagements ranging from troubleshooting customer issues to designing global enterprise collaboration environments. In his spare time, Paul tries to improve his golf swing.

Thomas Hampel is an IT Architect at IBM Germany. His key areas of focus are migration projects, performance and delivery service architecture for customers who outsourced to IBM. He is working with Lotus Domino since version 3 and is an IBM Certified Advanced Lotus Developer as well as IBM Certified Advanced Lotus Administrator in various versions up to 8.5. He is also an IBM Certified Advanced Security Professional.

Amy Hoerle is an Advisory Software Engineer in the Lotus Support Center. She has been focusing on Lotus products running on the IBM i Operating system for over 10 years. She is also a frequent presenter at the COMMON, A Users Group, annual meeting. When not working, Amy spends her time caring for her children, volunteering at their school, reading or working in her garden.

Gladstone Lang is a IT Specialist at ITD/SSO, Hortolandia/SP/Brazil. He is one of the account focals for the Email and Collaboration Service Line working with Lotus products. Before joining IBM in 2004, Gladstone used to work at an IBM Client and Training Center.

Vladislav Tatarincev is the Technical Director and co-owner of CYONE. www.cyone.eu. He has a Master of Computer Science from Latvian University. He has been working with Domino from release 4.5, for more than 10 years. He is also an IBM Certified Security Professional. Vladislav is the author of many freeware tools for Domino. His key areas of focus for Lotus Domino are: Performance, Traveler, Security. His hobbies include: diving, shark diving, wreck diving, underwater archeology, and motorbikes.

Wei-Dong Zhu (Jackie) is an Enterprise Content Management Project Leader with International Technical Support Organization. She has more than 10 years of software development experience in accounting, image workflow processing, and digital media distribution using C, C++, Java, and Lotus Notes scripts. Jackie holds a Master of Science degree in Computer Science from the University of the Southern California. She is a Certified Solution Designer for IBM Content Manager and has managed and lead the production of many ECM redbooks and Lotus Domino redbooks wiki projects.

7

Part 1. Getting Started

1.1. Documentation How many times have you come across a project or new client, where you have to migrate hundreds of databases, application, and servers? You assume that everything is documented and has always been well documented. As you begin to work on the project, you realize that the existing documentation does not contain what you needed or expected. This article describes how to properly document your Lotus Domino environment and what kind of documentation you should have based on the size of your corporation. The article serves as a valuable resource as you begin to document your environment or assist you in evaluating your current documentation. Before you start, here are some questions to consider regarding your existing documentation:

Where is the documentation stored in? Is there a defined place for all documentation?

Have you ever inherited an environment from someone else? If so, is the document about this environment up to date as you were told?

Documentation helps the current and the next administrator or technical project manager to quickly understand the environment. Properly and up-to-date documentation helps the continuation and growth of your environment.

Lets look at what documents should be created and what information should be documented.

1.1.1. Content to document

What makes a good documentation? Just listing the number of servers and host names is certainly not enough in all cases. A well documented environment helps to identify problems more efficiently, resolve tickets faster, and helps to find bottlenecks. The following table lists the kind of information that should be part of your documentation and what implementation size benefits most from this type of documentation.

What Content to Document Small Medium Large

Server details + +++ +++

Architectural overview + ++ +++

Naming standards (+) ++ +++

Instructions for end users (+) ++ +++

8

1.1.2. Server Details The very first and basic documentation is to have the server configuration described. Often, the Domino Directory is misunderstood to be online documentation of the server configuration. However, there is much more to be detailed for example, to allow someone who is new to the environment to understand the building blocks.

The server configuration is essential for upgrade projects because it can uncover pitfalls such as incompatibilities before they would cause a problem.

For each logical Lotus Domino server in your environment, the following (but not limited to) configuration elements should be detailed:

Server names and IP addresses Platform details such as hardware, operating system Lotus Domino version with fix packs or hot fixes installed (if any) Additional Lotus products with name, version and patch level 3rd party software installed with information on licensing details, install instructions

and describing how to access the installation package

For this part of the documentation, it is advisable to use the server name as the primary key, e.g. have one document per server where you keep track of the current server configuration details.

The resulting document must be able to be referenced in other parts of the documentation. That's why a Notes application is a good choice for this kind of information. Document links can be used to cross reference information.

1.1.3. Architecture Overview

An architectural overview diagram is a graphical overview of your servers, clusters and their inter-connections. The main focus is set on Lotus Domino servers and how their logical communication paths like mail and replication or SMTP connections.

The main purpose of the architecture overview diagram is to communicate a simple, brief, clear and understandable overview of the environment that the administrators are working with. Most likely, this is a drawing, much larger than one sheet of paper, which is the building of your environment. This diagram should include:

Lotus Domino Servers with their name and primary usage type and cluster membership (if applicable)

Mail routing connections Replication paths

For one way connections like "Pull only", use arrows to point out the direction of the data flow

Inbound and outbound SMTP connections Incoming and outgoing 3rd party connections like ODBC or other type of connections Major non-Domino systems which Domino is communicating with

9

Some recommendations for creating an architectural overview diagram are:

Do no try to put too much information into the same drawing. It is important to get the concept rather than all the tiny little details at this point in time. Focus on the Domino level, ignore details such as hardware and operating system, patch level, etc.

Do not use abbreviations without explaining them in (e.g.) a legend. Make sure when you build this overview, others can understand it easily. Especially for complex environments, it is a key element to a successful documentation because even the person who created this overview might not remember all the details later.

Work with your application development team to get an understanding of the 3rd party connections. There is a high chance that administrators do not know what developers have done in the past. It is essential to get a full understanding of these inter-connections to avoid problems when applying changes to the infrastructure.

Make sure to describe the type of connection, e.g. by using different colors for each connection type. Include a legend within the drawing for more details. An example for this legend is shown below.

Keep this overview up to date by making sure changes in the infrastructure are reflected in the drawing as soon as possible. In best case, the documentation is updated as part of the change implementation.

Tools and Method to Create an Architectural Overview Diagram

To create a drawing, any vector oriented graphic software is acceptable. Even CAD software or simple bitmap oriented graphic software will work. A broad number of software products are available on the market, from commercial software products to freeware applications. The product choice is yours. Just make sure to be familiar with its usage and be comfortable with the licensing details.

Some examples for applications which are free of charge are listed below.

Dia http://projects.gnome.org/dia/

yED http://www.yworks.com/en/products_yed_about.html

After you have selected the software of your choice, create a drawing in the following way:

1. Create an overview of the Lotus Domino Domains and outline how they are connected. For this first step, the Domain can be represented by a cloud icon or similar.

Review the replication topology within the Domain by looking into the Replication Topology of each Domain. This information can be retrieved from the Lotus Domino Administrator client within the Replication \ Replication Topology tab as shown on the picture below.

10

Note: The Domino Administrator client will retrieve this information from the Domino server which runs the maps task. This task is not automatically started on a Domino server. For details on how to enable the maps task, refer to the Lotus Domino Administrator Help http://www.ibm.com/developerworks/lotus/documentation/domino/

Add the administration server of each Domain and walk along the replication path. Ensure that in the end of this process, all servers of a Domain were added.

Example

Here is an example of how a simple architectural overview diagram can look like:

11

Standards

Especially in large organizations, it is important to describe standards that apply to the entire corporation. These standards can apply to every single detail of the environment, sometimes predefined by other people in your company e.g. your operating system standard or similar. Even if there are no regulations, it is advisable to define simple but effective software standards, giving you and your peers the opportunity to work towards a common target.

Hardware Standards Start with documenting the hardware type and size, and used for what purpose.

From the Domino point of view you start by Defining server classes, this is where you defer the server usability according to registered users or user access, location size, server main task, etc.

For example, in Company A, the architect has defined that:

Small Servers should not exceed 150 users or host application for small locations (up to 150 users);

Intermediate Servers can work as administration/application hub and should not exceed 1000 registered users or host application where the concurrent users should not exceed 1000 users;

Large Servers should not exceed 3000 registered users or host application where the concurrent users should not exceed 3000 users. They may also be used for high performance infrastructure servers (e.g. central SMTP gateways).

In a second step, for each of the server classes above, define:

Server Parameters: This is where you define based in the Server Class how your servers configuration are going to be; type and amount of CPUs; how much memory they should have, etc.

Hard Disk Layout: In here, you identify how your servers hard disk is or should be configured, where would the operating system be installed; where the binaries are going to be; and where is your data configured. Also in here, you should determine which type of disk array you are going to be using or used according to each different Server Class.

Be aware that vendors change their server hardware models quite often. New and more powerful servers are being offered while the older ones might not be available anymore. This is why you should consider the hardware standards as a rough guidance for new Domino administrators or people who are not familiar with Domino itself. Keep them updated on a yearly basis and do not hesitate to brainstorm smaller adjustments, e.g. to use a more powerful CPU if it becomes available. Note: Domino is a very I/O intensive application. When you choose a server model, choose the system with best I/O thruput for best performance!

12

Software Standards An important part of the environment documentation is the software standard. You determine what will be the server operating system according to each Server Class. Again, we can see that when you determine the Server Class correctly, it facilitates everything that comes after.

Below is the suggested software standards that help you in your documentation:

Operating System (OS): You determine what should be the OS version and which service pack needs to be installed according to the products requirements. Depending in your Server Class, you can determine a specific OS.

Anti-virus Software: For anti-virus software, you have to differentiate between anti-virus software for the OS and anti-virus software for Lotus Domino:

Anti-virus software at the OS level: You document the software version, patch level applied, how the virus pattern files are being updated (how often they should be updated), and also the files to be ignored by the OS anti-virus.

Anti-virus software at the Lotus Domino level: You document the software version, patch level applied, and how the virus pattern files are being updated (how often they should be updated).

Lotus Domino server: Document what is the Lotus Domino Server version and Fix Packs applied according to each sub-software requirements. We all know that for every product, there is a recommended Lotus Domino Server version with a specified Fix Pack, which is very important to follow. Also, you document what should be the folder naming convention for your Lotus Domino Server binary folder and data folder

Backup software: This is a tricky area. In many circumstances in a large company, the Domino administrators do not work with the backup administrators. It is very critical for every environment to have a good backup standard and policies very well defined:

Domino server backup tool and policies: Document what are covered and how your Domino server backups occur (daily, weekly, monthly) and what type (Incremental, Full, the use or not of Transaction Logging Archiving).

OS backup tool and policies: Document what are covered and how your OS backup occur (daily, weekly, monthly and what type for each Incremental and/or Full).

Special backups: If your company follows some sort of rule that request a longer retention period or any special tasks that need to be done with the Lotus Domino Server backup, this is the place where you should document it.

Environment monitoring: You document how your environment is being monitored (which tool, and what if being monitored at the OS level and at the Lotus Domino Server level).

Server reporting: You have to differentiate between reporting of operating system specific data and reporting of Domino specific data. This document only covers the Domino related reporting;

OS settings: Document the mandatory OS settings for all Domino servers. These mandatory settings are necessary to support a stable and secure environment and to minimize the support efforts.

Document what and how your OS should be set (e.g. drive letter, volume name, if Windows update should be automatic or not, network card naming convention, registry keys for OS tuning, etc):

Drive Indexing: If option is turned off as per Lotus recommendation (for each drive) or if the service is turned off in the control panel (which covers all disk drive).

13

System Page file: Document how your systems page file is set. Time settings: To assure a smooth mail routing and replication between all Domino

servers, it is important that the servers have been set to the correct time. Time zone: The operating systems time zone has to be set to the correct value

according to the physical location of the server. In addition, the setting "Automatically adjust clock to daylight saving changes" should be enabled and Domino servers should be set to "use OS time zone settings".

Regional settings: Document how your servers Regional Settings are set, when working on Windows OS environment;

Not all of the information must be described for a small environment. In large and growing environments with multiple administrators and teams working in different time zones, it is clearly a benefit to have common settings lay out.

1.1.4. Security Standards

One of the key components in a documentation is a description of the security standards in your environment. This information is not only essential in case of a disaster, its also supposed to clearly describe whats allowed and whats not.

Describe the different roles and the limitations for each role. E.g. User Administrator, Database Administratror, Application developer

Defined server access level, e.g. how the server security tab is supposed to be set up. Part of this is already described in the naming standards, so the focus should be on the concept rather than the naming as such.

Limitations and permissions within the environment defined in form of a corporate policy Think about who is allowed to run agents, who is allowed to sign applications, script libraries, etc. Have you got a specific role defined who will perform this work?

Handling of user id's and passwords, where are they stored, who (which role) Handling of access deny groups Where backup copies of key system (cert.id, server.id's, administrator id's.) files are

located and who got access to them in case of an emergency

Please note that the list above wont be a full list of items to be considered - additoinal elements may apply to your environment, so please ensure to update this chapter of your documentation on a regular basis.

1.1.5. Backup Standards Documentation should also include a description of your environment is backed up and what users can expect from a restore. This should include:

Backup policy, descrbing your corporate rules for how long a backup is retained "What" explaining what kind of information is backed up how often. Here the focus

should be on Domino data and not so much on other elements such as the operating system

"When", backup jobs are starting and when your backup window ends. "Where", describing which servers do perform which role within your backup concept,

e.g. if one server is backing up data for all servers, etc.

14

"How", describing what backup software is used, where its installed Details about the restore process and an estimate of how long it will take to have the

restore available

For more details about backup concepts for Domino please refer to the chapter "Backup a Lotus Domino Environment".

1.1.6. Naming Standards Naming standards allow people who are new to the environment to understand how to maintain consistency while extending or changing elements within. The following list represents configuration details of a Lotus Domino environment where naming standards could be applied:

Server names e.g. Define when to use what kind of server name. As the previous example, Company B uses CCNNNNXXX where CC stands for ISO country code, NNNN server Type (MAIL, HUB, APPL, etc), and XXX stands for the server sequential number according to its Type.

Domain names. Cluster names. Domino named Networks. Access control lists. Directory names.

e.g. Describe the directory structure of a Domino server and where to put which type of applications. Note: You should document your company standards for servers directories (folders) names for system databases, users Mail database, mail-in databases, and application databases.

File names. e.g. Define how to get a unique file naming in place. Document the naming convention used by your company for file naming convention at the Domino side. You can cover the naming convention for: users mail database, mail-in database, common Domino application database, Domino application based in the default templates; etc.

Group names. Document the naming convention used by your company for groups used in the Domino environment. Make sure to define groups following Domino standards: multi-purpose, access control list only, mail only, server only, and deny list only. Also, clearly define which characters are allowed and which are not.

Rooms and resources. For information, see http://www.ibm.com/support/docview.wss?rs=899&uid=swg21251010

User names. Describe the naming convention used by your company for users names naming convention. Cover all the details that are in use in your environment, such as: First Name, Last Name, Full Name, Short name, Internet Address and any other important field related to user that is in-place at your company. e.g. Which characters are allowed or how and when to use middle initials.

Email addresses. e.g. How an email address is computed if users can choose any address of their choice or if there are restrictions within your organization.

15

Agent signer names If you use specific ID files to sign or run your agents, then describe what syntax to be used for them.

Note: There are limitations defined by IBM Lotus for each of the elements listed. For more detail, refer to IBM Technote 1091216.

Access Control List

In this section of the documentation, include information on the database access control lists (ACLs). They provide a flexible mechanism for the database owner to determine the rights that individuals and groups have with respect to a Notes database. The ACLs for a database are server specific, in that each server enforces the ACL as specified in its version (replica) of the database. For ACL documentation, include how your companys default template ACLs are set and how the ACL of the system databases are set. With this kind of information, you can improve your level of standardization and fine tune your monitored environment. To document ACL settings, we provide the following suggestions as how this can be done:

Define basic ACL rules, e.g. Define ACL entries which must be present in all applications or must be present in all mail files. This can be all the groups and default IDs that should be in all databases ACL. Normally, these are groups that are related to IT Administrator and Administrative Server groups such as Domino Administration Process server, Server Backup, and so on.

Databases that are under investigation. In most companies, the legal department can request access to any database that may be part of some sort of litigation process. Create and document the standards for this scenario.

Define how the ACL for Domino System databases should look like in your environment. Include every ACL entry with its access rights and roles from the following system databases: names.nsf, admin4.nsf, catalog.nsf, log.nsf, certlog.nsf, events4.nsf, ddm.nsf, domlog.nsf, domcfg.nsf, busytime.nsf / clubusy.nsf, report.nsf, statrep.nsf, mail.box / mailX.box (where X stands for the number from 1 to n depending on the amount of mail.box set in the configuration document), statmail.nsf, mtstore.nsf, and da-CC.nsf (where CC stands for the naming convention used for your companys Country code or Site code).

Format to be used to document naming standards

It does not matter what format you use to document naming standards; however, it is important that this part of the documentation is available to everyone. It must be simple and easy to access and should be versioned.

There are multiple options to achieve this. Some examples are:

Stored in a Notes application, e.g. A discussion database where all users have READER access.

Create a file based document (e.g. PDF) and store it in (e.g.) Lotus QuickR or any other existing document management system.

16

An internal web page, where users can access the information by using their web browser.

There are other methods. Use your favorite ones. Again, make sure the result is accessible for all your users who need the documentation.

The following recommendations should be kept in mind when detailing naming standards:

In small implementations of Domino, naming standards most likely do not need to be defined because the number of servers and domains are relatively consistent. Nevertheless, it might be useful to define some naming standard to set the scene for future growth.

Within larger Domino environments, corporate naming standards are defined or need to be defined to define precise rules and limits for a team of administrators. This is why it should include all the elements we mentioned in their naming standards.

Especially in large environments, allow users and IT people to improve these naming standards by offering a discussion forum where people can ask why a certain standard is defined in this way. Keep answers accessible for others and be open-minded for changes suggested by your users.

1.1.7. Instructions for End Users

To reduce the number of help desk tickets and service requests, end users need to be provided with a completely different kind of documentation. Most likely, end users do not want to know about the detailed server configuration or their replication paths. Instead, they look for guidance on how to manage standard requests in an efficient way. Descriptions of common processes such as How to reset request new User ID or how to reset a password is what end users are usually looking for.

The list of processes can be endless. Always aim to reduce the time support staff needed to spend for answering the same question over and over again.

Consider this part of the documentation to be one of the first places for people who are new to your organization. Its purpose is to be used for self assistance platform or a form of guidance for your end users:

Process descriptions What-if scenarios Background information and cross reference (e.g. to naming standards) Help desk phone number(s)

Additionally, keep the following recommendations in mind:

Include information for 1st level help desk, e.g. where to route tickets or how to reach self service portals.

Do not mix end user instructions with training material. If people are new to Lotus Notes, there are better existing resources to refer them to. You do not have to create your own training material. For more information please take a look into:

http://www-01.ibm.com/software/lotus/training/ http://www-01.ibm.com/software/lotus/training/multimedialibrary.html

17

Define the language which is to be used. Depending on your corporation and regional distribution, not all users might understand English. The language is defined by what users understand best, not by what administrators would like to use.

Extend this part of the documentation as needed. Whenever you experience a growing amount of questions or requests in a certain area, add one more instruction and cross reference them where needed.

Do not send mass mails to your users communicating how a new process looks like. Instead, put the process description into this part of your documentation and refer users to it by sending a link to the respective entry.

Format to be used for documenting end user instructions

Although there are many different ways to provide information, not all method provide the required functionality:

Simple to access, e.g. via web browser or Lotus Notes client

Distributable to a broader population Accessible even when having a problem

e.g. Stored locally on the users desktop

One advisable method is to set up a new Lotus Domino application based on the Help template. IBM Technote 1164526 describe how to do this.

Keep in mind that process descriptions are likely to change. Especially in larger organizations, they are not easy to categorize because the processes differ e.g. between countries, regions, business units or even between departments.

1.1.8. Conclusion With a well documented environment, any infrastructure changes and any emergency situation can be faced with more efficiency and more professionalism. It is important to understand that documentation is not a static document. It is a living document with your environment and needs to be updated on a regular basis to keep its value.

18

1.2. Daily, Weekly, and Monthly Checklist Lotus products typically run smoothly. To ensure that they continue to run smoothly, administrators should be equipped with the right set of tools for analyzing problems when they occur. This article provides considerations and recommendations on what administrators can do to improve efficiency or optimizing their system.

1.2.1. General recommendations As a general recommendation, administrators should always be equipped with the latest knowledge in the Domino area, understand how to analyze system performance, and be able to troubleshoot server crashes.

Knowledge One of the very basic elements is to know about capabilities of an environment, know about bugs or problems, and practical methods to improve system functionality. Optimizing an environment requires continuous improvement and fresh ideas. However, fresh ideas are not always written down in a book yet. So you should always keep track of the up-to-date information. We recommend few hints to help you or an administrator to do this:

Sign up for My Notifications within the IBM Support portal. With My Notifications you can receive daily or weekly announcements through e-mail, custom Web pages and RSS feeds. These customizable communications can contain important news, new or updated support content, such as publications, hints and tips, technical notes, product flashes (alerts) and downloads and drivers. The tool allows you to customize and categorize the products you want to monitor and any of the available delivery methods to suit your support needs. http://www-01.ibm.com/software/support/einfo.html

Since the early beginning Lotus Domino administrators have been collaborating with each other to exchange information, best practices, hints, etc. One of the key elements is to share knowledge with the community. This is why the biggest source of information is the community itself. Make use of this valuable information by:

Signing up for the IBM Developerworks Lotus Community to read about Lotus software products and strategy from those who develop it. The Lotus Blogs are brought to you from IBMers who focus on Lotus software. http://www.ibm.com/developerworks/lotus/community/

Actively participate in the product discussion forums. Do not hesitate to ask your questions and feel free to answer questions from other people. ttp://www.ibm.com/developerworks/lotus/community/

Reading the blog posts of the Domino community. This following site provides a good start because it consolidates Blog posts from

19

various Lotus community blogs. You may want to use the RSS Feed Reader embedded in your Lotus Notes client in order to stay up to date. www.planetlotus.org

Getting in touch with other Domino Administrators in your region by attending community meetings or round tables.

Setting up your own Blog and post about your experience with Lotus products.Encourage the community to provide feedback by registering your Blog at: www.planetlotus.org

Performance Troubleshooting performance related issues is not a simple task. Usually, these kind of problems do not show up over night. Most likely, it is a phenomenon which develops over time and this is also the reason why a performance analysis must take into account that the root cause may be located outside of the Lotus Domino ecosystem. Different tools and techniques apply to different platforms or areas that you want to focus. IBM already provided a detailed article about performance best practices. To get an idea of which tools you need for your platform, take a look at

IBM Technote #7008849 - Notes Domino Best Practice: Performance http://www-01.ibm.com/support/docview.wss?uid=swg27008849

Server Crash Analysis For troubleshooting server crashes, the following tools are valuable to have. Be familiar with their capabilities, functionality and usage.

Analyzing server and client problems sometimes requires taking a closer look into NSD files created by Lotus while a crash occurred. By default, these files are stored within the Data directory of the client or server. Administrators can set up an Automatic Diagnostics database to collect these NSD files in a central database which will help to quickly get access to these files. For more information, see:

IBM Technote 1085850 describes how to set up this Automatic Diagnostic Database http://www-01.ibm.com/support/docview.wss?uid=swg21085850

IBM Technote 1272213 provides the latest version of the utility. http://www-01.ibm.com/support/docview.wss?uid=swg21272213

IBM Support Assistant is a desktop software which helps to find answers or solve problems for various different IBM software products. It supports multiple IBM products, not just Domino alone. http://www-01.ibm.com/software/support/isa/

Lotus Notes Diagnostic is a Lotus Notes application which can analyze NSD files, search for known problems and collect suggestions for a possible resolution of the problem. http://www-01.ibm.com/support/docview.wss?uid=swg24019151

1.2.2. Actions

To help administrators in maintaining smooth Domino operations, optimizing server stability, performance, and security, we provide recommendations for daily/weekly/monthly tasks that are to be carried out. Actions outlined in the sections below represent general best practice, but do not include maintenance activities such as compact or fixup tasks which typically run scheduled. Focus is set on what administrators are required to do to keep the Domino environment healthy.

20

This is not an all-in-one perfect list as individual actions vary based on your environment. If any of the described actions is performed, but does not result as expected, administrators need to investigate further as there may be undiscovered problems. On the other hand, not every action needs escalations or emergency actions. So even if you are not investigating further, it is highly recommended to at least document an abnormality with date and time of when the event occurred followed by comments or clarifications. Actions can be automated or may even be part of an existing monitoring solution. In this case, the task shall be understood as task to verification of functionality. To get an understanding of efficiency, where valuable time is spent, we recommend documenting how much time administrators spend for which reoccurring action and activity. After a certain period of time, the reported hours should be reviewed to identify where (e.g.) small tasks take up a lot of the administrators time. In return, a conclusion would be to evaluate if such a task or action can be automated in some way to optimize your environment.

Daily Actions The following list represents the daily actions an administrator should carry out for optimizing server runtime, performance and security:

Check and resolve problems reported in Domino Domain Monitoring database (DDM). The type and number of issues shown are depending on your DDM configuration.

Check if there were any servers crashing. If there is a problem, find the root cause by analyzing NSD files using tools referenced in the general recommendations section earlier.

Check available free disk space. This daily check can be automated by creating an event in a properly configured Domino Domain Monitoring database (DDM).

Verify daily backup jobs ran successfully. How to do this depends on the backup software used in the environment. All backup software vendors provide log files which administrators can check. Some can report success and failures through mail or other notification methods.

Check if anti-virus software is running properly and patterns are up to date. Keep in mind to include the operating system anti-virus software in this check because it is as important as the anti-virus software on Domino servers.

Check for replication problems by reviewing the replication log of your server(s). The amount of time spent for this action can be minimized by setting up DDM replication monitors which only reports failures to DDM.

Monitor mail routing by checking mail routing queues. Check key statistic values on your servers and compare them with values from past

days. For the number of peak transactions per minute, a fixed limit can not be provided because the capabilities depend on the underlying hardware. Over time, you will get an idea of when workloads become an issue and you will get to know how to balance workload.

For the daily check, focus on these statistics:

Server.trans.PerMinute.peak Replica.cluster.WorkQueueDepth.avg Replica.cluster.WorkQueueDepth.Max

21

Note: This list does not claim to be complete. Depending on your environment, additional or fewer actions may apply e.g. caused by third party tools which either requires administrators to manage them separately or which help them to perform some of the tasks mentioned above automatically.

Weekly Actions In addition to the daily actions, administrators should perform the following actions on a weekly basis, preferable in the beginning of a week to review the previous weekend:

Monitor Administration Requests database (Admin4.nsf), Check the views Errors by Date and Individual approval required and take appropriate action.

Review Domino server statistics and statistic trends. Especially search for workload peaks and document them. Take actions if you can see an unexplainable peak by reviewing log files further and explore options to balance workload within your environment. For more details, refer to Notes/Domino Best Practice Statistic and Events http://www-01.ibm.com/support/docview.wss?uid=swg27009310

Clean up your server and remove restored NSF files which are no longer required on your server. Typically, a restore is only required to be kept for a certain period of time, e.g. 7 days after this time, the restored file can be removed from disk.

Once again, additional actions may apply to your environment.

Monthly Actions In addition to the weekly actions, administrators should perform the following actions on a monthly basis:

Monitor Domino server memory consumption and take actions to provide sufficient memory for the Domino server to avoid performance problems. The total amount of memory required depends on more than just the Domino server alone. Third party tools on the operating system level that consume additional memory must also be taken into account.

Check for new releases or patches affecting your environment. Sign up to mailing lists as described in General Recommendations above.

If any changes are applied to the infrastructure, update the documentation to reflect the current environment.

Run Lotus Domino Configuration tuner against all servers in the environment and review recommendations made by DCT. http://www-10.lotus.com/ldd/dominowiki.nsf/dx/domino-configuration-tuner

Check Certlog.nsf for expiring certificates and ID files, If required initiate the recertification process as described here http://www-01.ibm.com/support/docview.wss?uid=swg21326765

Check server disk fragmentation, because fragmented disks may result in slow server performance. Note: You can run defragmentation tools on a server, but Lotus Domino must be down to avoid damage to your data! For more details, see IBM Technote #1229817 http://www-01.ibm.com/support/docview.wss?uid=swg21229817

22

Review problems (if any) that have been reported in the previous month. Dig into problems and try to find and fix the root cause.

For Domino Web servers, monitor web server requests. The following IBM technotes can be helpful when working with Domino HTTP logs:

#1382231 - How can I gather and sort data from HTTP access? http://www-01.ibm.com/support/docview.wss?uid=swg21382231

1161104 How to reduce the size of Domino Web Server Log (domlog.nsf) http://www-01.ibm.com/support/docview.wss?uid=swg21161104

As mentioned previously, this list does not claim to be complete. Depending on your infrastructure, the focus may vary and additional actions may apply.

Yearly Actions In addition to the monthly actions, administrators should perform the following actions on quarterly or yearly basis:

Perform tape backup restoration tests to ensure valid recovery data. Just checking backup logs and reacting on errors alone is not everything. There is nothing worse than a restore which cannot be done because (e.g.) backup media is broken or it is empty for whatever reason. Once in a while, such as on a quarterly or yearly basis, backups should be verified by restoring to a full server. The restore can be done on an isolated server to avoid effect on your production environment.

Update your documentation. We recommend updating documentation whenever a change is applied to the infrastructure or at least with only a small delay. A quarterly or yearly update is recommended to verify essential parts are correct. The larger an environment is, the more frequent administrators should schedule this task.

Perform a server health check of your environment. For more information on this topic, refer to the IBM OpenMic Call Health Check for Lotus Domino servers in IBM Technote #1432995 http://www-01.ibm.com/support/docview.wss?uid=swg21432995

1.2.3. Conclusion

In this article, we recommended a set of actions you should perform on daily, weekly, monthly, quarterly, and yearly basis. These are not complete lists of actions. Depending on your specific environment, come up with your own lists to perform on regularly basis, to ensure smooth Domino operation and optimized system performance.

23

1.3. Security Checklist According to some estimates, 80-90% of threats come from current or ex-employees. This article describes activities which administrators should perform on a regular basis to keep their environments secure. Server security consists of different areas, such as server physical security (server room), operating system (OS) access by OS administrators, and services that run on this machine. The security level of a server is defined by the weakest node in the chain. The following checklist guides you on what needs to be checked regularly to keep your servers in good shape from a security perspective:

Check for unneeded account by enabling the License Tracking in Configuration document. For small and medium environments, check every six months. For large environments, check quarterly. According to statistics, about 10% of the accounts in large environments are not used or not closed properly. For more information, see License Tracking

Run ACL analysis on all databases. Check to make sure that there is no high Default access, such as Default=Manager or Designer. Also, if your server is accessible from the Internet make sure that all databases have an Anonymous entry. Note: Catalog.nsf may not have all databases. It lists existing entries. It does not show that Anonymous entry is missing. You can write a simple LotusScript agent to check the ACL or use the Domino Administrator client to perform a mass ACL update.

Consider enabling LOG_USERSESSION=2 server notes.ini parameter as this will log the IP address of the PC from which the user accesses the Domino server.

Ensure that the Domino web server is logging requests. You may filter some resources from being logged. For more information, see License Tracking

Check that the Domino web server logs for attacks and scan your web site for brute force password attempts.

If you have HTTP access to your server, consider deploying SSL for authorization so that passwords are not transmitted in plain text over the network.

Check DDM database daily for new tickets. Consider enabling Security Probes in Lotus Domain Monitoring. For more information, see Security Probe

Make sure that no person records have attached USER.ID files. You can run a scheduled script to check this. In the case that the attached USER.ID is found, the script should notify the administrator. Many organizations have default start password. If password checking is not enabled, old copies of USER.ID may be used for the wrong purposes.

Check if deny access group is updated and is populated in server documents. Check for unneeded tasks running on server. For example LDAP running on public

server with Anonymous access allowed. Check that only needed ports are open. Ask firewall administrators which ports are

allowed from outside (Internet). Make sure only needed ports are open. If a port is no longer needed, close it on Domino and at the firewall level. Every opened port is a potential way to get inside your system.

If you plan to do vulnerability scanning with third-party software, do this outside of working hours. Notify administrators who are responsible for this system when you plan to perform the test.

24

Check against information theft. There are third-party solutions that allow you to check if anyone is accessing unauthorized data. There are Data Leakage Prevention systems that can protect you against information theft.

Ensure that the Domino server has Internet password locking feature enabled. If somebody does a brute force attack on a server, you can see this in the internet lockout database. For more information, see Securing an IBM Lotus Domino Web server: Using the new Internet lockout feature

Consider implementing stronger and more complex passwords. Do this step by step. If a users password does not comply with policy, the user will be asked to change the password. If the user cancels the password change procedure, Lotus Notes will notify the user that the current password is not complying with policy and the client will close.

Review the Security tab of your servers. Check who can enable Full Access Administration mode, who can sign scripts that has server operating system access, etc. Enable notification for enabling Full Access Administration to others, or a special mailbox. For more information, see Technote # 1197579

Keep in mind, security can impact system performance and user experience. The more secure the environment, the harder for users to access data to perform their work. You should find a balance between the needed security level required by the business holders and user comfort.

1.3.1. Additional References

For additional references and reading, see:

Lotus Security Handbook http://www.redbooks.ibm.com/abstracts/sg247017.html

Security Considerations in Notes and Domino 7: Making Great Security Easier to Implement http://www.redbooks.ibm.com/abstracts/sg247256.html

25

1.4. Domino Authentication Options This article describes the Domino authentication options to help you determine which option best suits your environment.

1.4.1. Choosing the Domino Authentication Options Traditionally, Lotus Notes use USER.ID file for authentication. Release 8.5.x added some new options for authenticating as well as a great feature that significantly reduces time for ID management ID VAULT. Authentication using SmartCards is another option. The following flowchart helps you understand which Domino authentication option is best suited for your environment.

Each authentication option listed and numbered in the flowchart is described in the following sections.

26

1.4.2. SmartCards (1) SmartCards provide high security for Lotus Notes access. Regular Lotus Notes USER.ID files can be stored on SmartCards and be protected with a PIN number. Every time you log into Lotus Notes, you need to enter the PIN number, so the SmartCards can unlock the protected USER.ID. You can also protect SERVER.ID files with SmartCards as well. In that case, every time a server is started you need to enter the PIN number to unlock the SERVER.ID.

If you decide to use SmartCards with Lotus Notes ID, you need to know how to configure Lotus Notes/Domino for SmartCards usage. Keep in mind that SmartCards users may require a separate policy. This is because periodic password changes and some other options are not applicable for SmartCards protected USER.ID files.

For more information, see the following articles:

http://www-10.lotus.com/ldd/dominowiki.nsf/dx/enabling-smartcards-for-notes-login/ http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/com.ibm.notes85.help.

doc/sec_smartcard_t.html

==Single-Sign On (2)== If you have many Domino Web servers, then Single-Sign-On (SSO) based on LTPAToken can be used. When a user connects and authenticates to the first server, the browser receives a secret ticket (token) that is stored in the browser. If you need to authenticate to a new server, the browser will pass this ticket to the server (limited to servers inside your Domain) and you will be authenticated without an additional password prompt. For example, you have 5 servers (3 mail servers in a cluster, and two applications servers, one of which is an internal application server and the other one is an external application server). In this case, if you do not use (SSO), you have to enter your password several times on each server. If SSO using a LTPAToken is used, you log in only once. Be cautious when you configure your server. If you use Internet Sites, then you use one LTPAToken definition. If do not use Internet Sites, then you may use another LTPAToken definition, which is stored in another document. It is recommended that you check the ($WebSSOConfigs) view for duplicated documents and that on all servers you use or not use Internet Sites documents. This may save you time while deploying SSO. You may also later use LTPA SSO during deployment of an Instant Messaging (Sametime Entry) or Sametime Meeting Server. For example, you can configure the Lotus Notes embedded Sametime client to log into Sametime using the SSO token. Thus, you can eliminate the need for Lotus Notes users to enter an HTTP password to log into Lotus Sametime.

For more information, see the following articles:

Can Sametime work with Internet Sites enabled? http://www-01.ibm.com/support/docview.wss?uid=swg21157740

Configuring Single Sign-On between Lotus Quickr and Lotus Sametime http://www-10.lotus.com/ldd/lqwiki.nsf/dx/configuring-single-sign-on-between-lotus-quickr-and-lotus-sametime

1.4.3. Lotus Notes and HTTP Password Synchronization (3)

27

Lotus Notes provides an option for users to set the HTTP password same as the Lotus Notes password. The advantage of setting the same password is that the user has one less password to remember. If the user uses the same password for both systems (Lotus Notes and HTTP access), there is no need to spend time to set the HTTP password. It happens automatically if it is set in Security Settings and added to Domino policy. When needed, user can submit request to change the user's HTTP password. Lotus Notes and HTTP password synchronization can be the first step to make authentication easier for the users. This also helps reduce the number of help desk calls. Lotus Notes and HTTP synchronization is available in Release 6.x, 6.5, 7.x, 8.x, 8.5.

For more information, refer to Security Setting help for enabling Lotus Notes and HTTP password sync

Note, password synchronization does not work with Shared Login.

1.4.4. LDAP (4 and 5) Lotus Domino users are registered in NAMES.NSF - the Domino directory. If you deploy one more system, you may need to maintain multiple user accounts for single user in your environment. User and password management can be a costly task in each system. You can use Lotus Domino server for authenticating other users with the help of LDAP protocol. Other systems may use Domino users for authentication with LDAP. The benefit of this approach is if something is changed, e.g. password is changed or a new user is added, all systems that use Domino for authentication automatically reflect the changes and and see changes. You do not need to register or remove the user from different systems.

For more information, see IBM Infocenter, Planning LDAP Features

1.4.5. SPNEGO (6) Lotus Domino 8.5.1 introduced a new way for user authentication: Users can authenticate in Domino web server with their Windows credentials. The benefit of the SPNEGO authentication is that users are not asked to enter passwords. According to research, password management in systems is rather expensive. Reducing the number of passwords users need to have helps decrease the number of help desk calls. If you currently use pre 8.5.x Release of Lotus Notes and plan to upgrade, consider migrating from Single-Sign-On service to 8.5 so you can use Shared Login because this solution does not synchronize password, thus it is easier to administer.

SPNEGO means Simple and Protected GSSAPI Negotiation Mechanism. The clients browser and server can negotiate and the server can get information from Windows Active Directory regarding which user is trying to access the system. In this way the server will map the Windows user to the Domino users. If you consider adding SPNEGO authentication to products such as Microsoft Quickr, Sametime, consult IBM Consultants. Check requirements for Windows Active Directory and the Domino version before you decide to deploy this.

28

For more information, see:

Deploying Windows single sign-on for Web clients (SPNEGO) in an existing Domino environment http://www-10.lotus.com/ldd/dominowiki.nsf/dx/Deploying_SPNEGO

Who supports SPNEGO authentication in a Lotus Quickr Domino 8.1 or 8.2 environment? http://www-01.ibm.com/support/docview.wss?uid=swg21422957

1.4.6. Lotus Notes and Operating System Single-Sign On (7) Lotus Notes prior to 8.5.x offered an option that enabled users to not enter their Lotus Notes password. Lotus Notes Single-Sign-On service was synchronizing the password between Lotus Notes and the Windows operating system. If you currently use pre 8.5.x Release of Lotus Notes and plan to upgrade, consider migrating from Single-Sign-On service to Shared Login because this solution does not synchronize password, thus it is easier to administer.

For more information, see Does Notes support Single Logon with Novell?

==Shared Login (8)== Notes Shared Login (NSL) is a feature introduced in Release 8.5. It allows you to unlock your Lotus Notes ID with your Windows credentials. If the person is logged into the Windows operating system, a special Windows service is responsible for unlocking Lotus Notes USER.ID and the user can log into Lotus Notes without a password prompt. If the user forgot his/her password, you need to reset his/her Windows Domain password. Lotus Notes policy security settings in Release 8.5 has options on how to notify and enable Shared Login for users. If you have enabled Lotus Notes and HTTP password synchronization and you later enable Shared Login, users will now have to manage their HTTP password separately. If needed, for some users, you can enable Shared Login in the security preferences of the Lotus Notes client (grayed out by default).

29

Tips: Do not mix Shared Login with Single-Sign-On from Release 6.x-7.x. Single Sign-On from old versions of Lotus Notes was synchronizing the Lotus Notes and Windows passwords, Shared Login in 8.5 does not have to synchronize the passwords. A special Windows Service UNLOCKs the USER.ID of the user. If you are upgrading from an environment which used operating system Single-Sign-On, it is recommended to move to the Shared Login feature. Operating system Single-Sign-On is maintained for backward compatibility.

For more information, see Using Notes shared log in to eliminate Notes password prompts http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/com.ibm.notes85.help.doc/sec_nsl_desc_t.html

1.4.7. Tivoli Directory Integrator (9) Users who have purchased Lotus Domino 8.5.x are entitled to use Tivoli Directory Integrator to synchronize data with Domino. For more information, see TDI Entitlement

If Tivoli Directory Integrator (TDI) is used to synchronize data with Domino, you do not need to buy additional licenses. If TDI is used to synchronize non-Domino data, you need to buy additional licenses.

TDI allows integration of different systems and synchronization of data. For example, it enables you to integrate Lotus Domino directory and Windows Active directory as well as export or import users to and from textfiles or CSV files. TDI is a very powerful tool. You will need to take some time to learn its architecture before getting started with it.

1.4.8. Additional Resources

For more information, see:

Robust Data Synchronization with IBM Tivoli Directory Integrator Home page of TDI Users community You can find here online education and tutorial

materials.

Lotus Domino integration page Tivoli Directory Integrator - integration with Lotus Domino

30

1.5. Agents and the Domino Administrator As a Domino Administrator, you may consider agents are for developers to write and handle. However; there are a number of things every Domino Administrator should know relating to agents. This article provides the list of these agent-related topics including how can an agent trigger, how to determine which agnets are schedule to run on the server, full text searches and agents, performance impact on agents, and how to write an agent.

1.5.1. Agent Triggers Agents can be triggered in a number of ways and can also run under a number of server tasks including agent manager, server and http. When an agent is created, the developer can choose how that agent can run. An agent can be triggered on an event such as being called from a menu, a mail message being delivered or a document being created. It is important to understand which task an agent will be running under in order to be able to recognize the impact of an agent. If you see a sudden increase in CPU usage on your server, you may want to be able to easily identify or eliminate an agent as the potential cause. The list of triggers is as follows:

On Schedule: This type of agent will run on the server and on schedule that was defined by the developer. The agent may run multiple times per day, weekly or monthly.

Action menu selection: For this type of agent to run, a user must selects the agent from the Actions menu in the Lotus Notes client. When an agent runs in this manner, the code will run either on the client or in the server task depending on how the agent was coded. Domino administrator does not get a log or see a list of agents triggered in this way.

Agent list selection: This type of agent trigger is reserved for agents that will be called by another agent or only ran from the designer client. These agents will run in the designer client or within the server task that called the agent.

Before new mail arrives: This type of agent is triggered by the router task immediately prior to the message being written to the Inbox of a mail or application database. This type of agent will run under the router task.

After new mail has arrived: This type of agent is triggered by a new mail message being written to the Inbox of a mail or application database. Once the message is delivered, the agent is scheduled to run in 2 minutes. This type of agent is controlled by the agent manager task; this ensures that if multiple mail messages are written into the database within a short period of time, the server will be able to process those new mail messages during one execution rather than running multiple times within seconds.

After documents are created or modified: When a new document is created or a document is updated, this type of agent will run. The agent will be set to run as a scheduled agent under the agent manager task once a document has been created or modified, but not more than every 30 minutes.

31

1.5.2. Determining Which Agents Are Scheduled to Run on the Server

The Domino Administrator client provides an easy way to determine which agents are scheduled to run on the server. In figure 1 you can see that there are 5 agents scheduled to run. For illustration purposes, the agents are named with their trigger type. As you can see, only the agents that will be run by the agent manager task are listed. The next scheduled run time can be easily seen under the Next column. If you place your cursor over the schedule, the server will then display information on the schedule for that agent. "A Scheduled Agent on a Server" is set to run every 60 minutes. If you were to hover over "An After documents are created" or "An After New Mail Arrives" agent, you will see a listing of "Agent will not run" to indicate to you that the agent will be scheduled based on another trigger.

1.5.3. Agent Manager Settings That Affect Agent Execution There are several settings that determine how many agents can run on your server at any time and how long they may run. You find these settings in the server document, Server Tasks... Agent Manager tab as shown below in figure 2. For example, by default, only 1 agent may run at a time during the day and 2 agents may run concurrently during the night. Depending on the number of agents that need to be processed in you environment, you can raise this number.

Why would you need to increase the number of agents to run concurrently? In the section above, you saw how to determine which agents are scheduled to run. If you saw many of those agents scheduled to run in the past, and they are not agents triggered by a document update or mail message, then the agent manager task is not keeping up and you may want to consider increasing the Max concurrent agents parameter for daytime, nighttime or both. Another parameter to consider is the Max LotusScript/Java execution time. If you have agents that take over 10 minutes to process, you must change this parameter or the agent will be stopped by the agent manager task before it is finished. This setting is a safety precaution against infinite loops and to ensure one agent does not prevent all other agents from running.

32

1.5.4. Full Text Searches and Agen