Novell GROUPWISE 7 Interoperability Guide

Interoperability Guide
Novell®
novdocx (en) 11 July 2008
AUTHORIZED DOCUMENTATION
GroupWise
7
®
www.novell.com

GroupWise 7 Interoperability Guide

Legal Notices
Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes.
Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export, or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the Novell International Trade Services Web page (http://www.novell.com/info/exports/) for more information on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export approvals.
novdocx (en) 11 July 2008
Copyright © 2003-2008 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher.
Novell, Inc. has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed on the Novell Legal Patents Web page (http://www.novell.com/company/legal/patents/) and one or more additional patents or pending patent applications in the U.S. and in other countries.
Novell, Inc. 404 Wyman Street, Suite 500 Waltham, MA 02451 U.S.A. www.novell.com
Online Documentation: To access the online documentation for this and other Novell products, and to get
updates, see the Novell Documentation Web site (http://www.novell.com/documentation).
Novell Trademarks
For Novell trademarks, see the Novell Trademark and Service Mark list (http://www.novell.com/company/legal/
trademarks/tmlist.html).
Third-Party Materials
All third-party trademarks are the property of their respective owners.
novdocx (en) 11 July 2008
novdocx (en) 11 July 2008
Contents
About This Guide 17
Part I Novell Cluster Services on NetWare 19
1 Introduction to GroupWise 7 and Novell Cluster Services on NetWare 21
2 Planning GroupWise in a NetWare Cluster 23
2.1 Meeting Software Version Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Installing Novell Cluster Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Planning a New Clustered Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Planning a New Clustered Post Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Planning a New Library for a Clustered Post Office. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6 Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise . . . . . . . . . . . 27
2.7 Ensuring Successful Name Resolution for GroupWise Volumes . . . . . . . . . . . . . . . . . . . . . . . 29
2.8 Deciding How to Install and Configure the Agents in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8.1 Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the
Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8.2 Determining Appropriate Failover Paths for the Agents . . . . . . . . . . . . . . . . . . . . . . 33
2.8.3 Deciding Where to Install the Agent Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.8.4 Deciding Whether to Run the Agents in Protected Memory . . . . . . . . . . . . . . . . . . . 36
2.8.5 Planning the NetWare Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.9 GroupWise Clustering Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.9.1 System Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.9.2 IP Address Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.9.3 Agent Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
novdocx (en) 11 July 2008
3 Setting Up a Domain and Post Office in a NetWare Cluster 43
3.1 Preparing the Cluster for GroupWise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.1 Ensuring Required Software Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.2 Cluster-Enabling Shared Volumes for Use with GroupWise . . . . . . . . . . . . . . . . . . . 43
3.1.3 Configuring Short Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Setting Up a New GroupWise System in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3 Creating a New Secondary Domain in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 Creating a New Post Office in a Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5 Installing and Configuring the MTA and the POA in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5.1 Installing the Agent Software in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5.2 Editing Clustered Agent Startup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5.3 Configuring the GroupWise Volume Resource to Load and Unload the Agents . . . . 53
3.5.4 Setting Up New Instances of the Agents without Installing the Agent Software . . . . 57
3.6 Testing Your Clustered GroupWise System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.7 Managing Your Clustered GroupWise System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.7.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . . 60
3.7.2 Using Novell Remote Manager on NetWare 6.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.7.3 Knowing What to Expect in MTA and POA Failover Situations . . . . . . . . . . . . . . . . . 64
3.8 What’s Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.9 Clustering Quick Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.9.1 GroupWise System Quick Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Contents 5
3.9.2 Domain Quick Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.9.3 Post Office Quick Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4 Implementing the Internet Agent in a NetWare Cluster 69
4.1 Planning the Internet Agent in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1.1 Planning a Domain for the Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.1.2 Deciding Whether to Cluster-Enable the Internet Agent Volume. . . . . . . . . . . . . . . . 70
4.1.3 Determining an Appropriate Failover Path for the Internet Agent Volume. . . . . . . . . 70
4.1.4 Planning a Secondary IP Address and Cluster-Unique Port Numbers for the Internet
Agent and Its MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.1.5 Preparing Your Firewall for the Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.1.6 Deciding Where to Install the Internet Agent and Its MTA. . . . . . . . . . . . . . . . . . . . . 72
4.1.7 Deciding Whether to Run the Internet Agent and Its MTA in Protected Memory. . . . 72
4.1.8 Planning the MTA Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.1.9 Planning the Internet Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2 Setting Up the Internet Agent in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2.1 Cluster-Enabling a Shared Volume for Use with the Internet Agent . . . . . . . . . . . . . 73
4.2.2 Creating a Domain for the Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.3 Installing the MTA for the Internet Agent Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.4 Installing and Configuring the Internet Agent in a Cluster . . . . . . . . . . . . . . . . . . . . . 74
4.2.5 Testing the Clustered Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3 Managing the Internet Agent in a Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.3.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . . 83
4.3.2 Knowing What to Expect in an Internet Agent Failover Situation . . . . . . . . . . . . . . . 84
4.4 Internet Agent Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.5 Internet Agent Quick Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
novdocx (en) 11 July 2008
5 Implementing WebAccess in a NetWare Cluster 89
5.1 Understanding the WebAccess Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2 Planning WebAccess in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.1 Planning a New Domain for the WebAccess Agent. . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2.2 Deciding Whether to Cluster-Enable the WebAccess Agent Volume . . . . . . . . . . . . 90
5.2.3 Determining an Appropriate Failover Path for the WebAccess Agent Volume . . . . . 91
5.2.4 Planning a Secondary IP Address and Cluster-Unique Port Numbers for the
WebAccess Agent and Its MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.2.5 Deciding Where to Install the WebAccess Agent and Its MTA . . . . . . . . . . . . . . . . . 91
5.2.6 Deciding Whether to Run the WebAccess Agent and Its MTA in Protected Memory 92
5.2.7 Planning the MTA Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2.8 Planning the WebAccess Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3 Setting Up WebAccess in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3.1 Cluster-Enabling a Shared Volume for Use with the WebAccess Agent . . . . . . . . . . 93
5.3.2 Creating a Domain for the WebAccess Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.3.3 Installing the MTA for the WebAccess Agent Domain . . . . . . . . . . . . . . . . . . . . . . . . 94
5.3.4 Installing and Configuring the WebAccess Agent in a Cluster. . . . . . . . . . . . . . . . . . 94
5.3.5 Testing Your Clustered WebAccess Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4 Managing WebAccess in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.4.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . 101
5.4.2 Knowing What to Expect in WebAccess Failover Situations . . . . . . . . . . . . . . . . . . 102
5.4.3 Updating the WebAccess Agent Configuration File (commgr.cfg). . . . . . . . . . . . . . 102
5.5 WebAccess Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.6 WebAccess Quick Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6 GroupWise 7 Interoperability Guide
6 Implementing GroupWise Gateways in a Novell Cluster 107
7 Monitoring a GroupWise System in a NetWare Cluster 109
8 Backing Up a GroupWise System in a NetWare Cluster 111
8.1 Using GWTSA in a NetWare 5.1 Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.2 Using TSAFSGW in a NetWare 6.x Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
9 Updating a GroupWise System in a NetWare Cluster 115
10 Moving an Existing GroupWise 7 System into a NetWare Cluster 117
11 Implementing Messenger in a NetWare Cluster 119
11.1 Planning Your Messenger System in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.1.1 Understanding Your Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.1.2 Planning Messenger Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.1.3 Deciding Where to Install the Messenger Agent Software . . . . . . . . . . . . . . . . . . . 120
11.1.4 Planning the Messenger Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
11.2 Setting Up Your Messenger System in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
11.2.1 Installing to Each Node in the Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.2.2 Installing to a Messenger Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.3 Messenger Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
novdocx (en) 11 July 2008
Part II Novell Cluster Services on Linux 129
12 Introduction to GroupWise 7 and Novell Cluster Services on Linux 131
13 Planning GroupWise in a Linux Cluster 133
13.1 Installing Novell Cluster Services on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
13.2 Planning a Clustered Software Distribution Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13.3 Planning a New Clustered Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
13.4 Planning a New Clustered Post Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.5 Planning a New Library for a Clustered Post Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.6 Deciding How to Install and Configure the Linux Agents in a Cluster . . . . . . . . . . . . . . . . . . 138
13.6.1 Recording Secondary IP Addresses for the Agents . . . . . . . . . . . . . . . . . . . . . . . . 138
13.6.2 Determining Appropriate Failover Lists for the Agents . . . . . . . . . . . . . . . . . . . . . . 138
13.6.3 Determining Cluster Resource Information for the Linux Agents. . . . . . . . . . . . . . . 139
13.6.4 Planning the Linux Agent Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
13.7 GroupWise Clustering Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
13.7.1 System Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
13.7.2 Agent Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
14 Setting Up a Domain and a Post Office in a Linux Cluster 143
14.1 Setting Up a New GroupWise System in a Linux Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
14.2 Creating a New Secondary Domain in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
14.3 Creating a New Post Office in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
14.4 Installing and Configuring the MTA and the POA in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . 146
14.4.1 Installing and Setting Up the Agents in Your Cluster . . . . . . . . . . . . . . . . . . . . . . . . 146
Contents 7
14.4.2 Changing Agent Paths to Locations on GroupWise Partitions . . . . . . . . . . . . . . . . 150
14.4.3 Configuring GroupWise Cluster Resources to Load and Unload the Agents . . . . . 152
14.4.4 Setting Up New Instances of the Agents without Installing the Agent Software . . . 158
14.5 Testing Your Clustered GroupWise System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
14.6 Managing Your Clustered GroupWise System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
14.6.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . 161
14.6.2 Knowing What to Expect in MTA and POA Failover Situations . . . . . . . . . . . . . . . . 163
14.7 What’s Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
14.8 Clustering Quick Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
14.8.1 GroupWise System Quick Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
14.8.2 Domain Quick Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
14.8.3 Post Office Quick Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
15 Implementing the Internet Agent in a Linux Cluster 167
15.1 Planning the Internet Agent in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
15.1.1 Planning a Domain for the Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
15.1.2 Selecting the Internet Agent Partition and Secondary IP Address . . . . . . . . . . . . . 168
15.1.3 Determining an Appropriate Failover List for the Internet Agent . . . . . . . . . . . . . . . 169
15.1.4 Determining Cluster Resource Information for the Internet Agent . . . . . . . . . . . . . . 169
15.1.5 Preparing DNS for the Clustered Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
15.1.6 Preparing Your Firewall for the Clustered Internet Agent . . . . . . . . . . . . . . . . . . . . 169
15.1.7 Planning the MTA Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
15.1.8 Planning the Internet Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
15.2 Setting Up the Internet Agent in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
15.2.1 Creating a Domain for the Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
15.2.2 Installing the MTA for the Internet Agent Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 171
15.2.3 Installing and Configuring the Internet Agent in a Cluster . . . . . . . . . . . . . . . . . . . . 171
15.3 Testing the Internet Agent in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
15.4 Managing the Internet Agent in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
15.4.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . 183
15.4.2 Knowing What to Expect in an Internet Agent Failover Situation . . . . . . . . . . . . . . 184
15.5 Internet Agent Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
15.6 Internet Agent Quick Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
novdocx (en) 11 July 2008
16 Implementing WebAccess in a Linux Cluster 187
16.1 Understanding the WebAccess Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
16.2 Planning the WebAccess Agent in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
16.2.1 Planning a Domain for the WebAccess Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
16.2.2 Selecting the WebAccess Agent Partition and Secondary IP Address . . . . . . . . . . 189
16.2.3 Determining an Appropriate Failover List for the WebAccess Agent . . . . . . . . . . . . 189
16.2.4 Determining Cluster Resource Information for the WebAccess Agent . . . . . . . . . . 189
16.2.5 Planning the MTA Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
16.2.6 Planning the WebAccess Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
16.2.7 Planning the WebAccess Application Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 190
16.3 Setting Up the WebAccess Agent in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
16.3.1 Creating a Domain for the WebAccess Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
16.3.2 Installing the MTA for the WebAccess Agent Domain . . . . . . . . . . . . . . . . . . . . . . . 191
16.3.3 Installing and Configuring the WebAccess Agent in a Cluster. . . . . . . . . . . . . . . . . 191
16.3.4 Installing and Configuring the WebAccess Application in a Cluster . . . . . . . . . . . . 201
16.4 Testing the WebAccess Agent in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
16.5 Managing the WebAccess Agent in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
16.5.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . 203
16.5.2 Knowing What to Expect in a WebAccess Agent Failover Situation . . . . . . . . . . . . 204
16.6 WebAccess Agent Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
8 GroupWise 7 Interoperability Guide
16.7 WebAccess Agent Quick Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
17 Implementing GroupWise Monitor in a Linux Cluster 207
17.1 Understanding the Monitor Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
17.2 Planning GroupWise Monitor in a Linux Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
17.2.1 Selecting a Domain for Access during Monitor Agent Installation . . . . . . . . . . . . . . 208
17.2.2 Selecting an MTA for the Monitor Agent to Access after Installation. . . . . . . . . . . . 208
17.2.3 Selecting the Monitor Agent Partition and Secondary IP Address. . . . . . . . . . . . . . 209
17.2.4 Determining an Appropriate Failover List for the Monitor Agent . . . . . . . . . . . . . . . 209
17.2.5 Determining Cluster Resource Information for the Monitor Agent . . . . . . . . . . . . . . 209
17.2.6 Planning the Monitor Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
17.3 Setting Up GroupWise Monitor in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
17.3.1 Installing and Configuring the Monitor Agent on Each Node in Your Cluster . . . . . 210
17.3.2 Configuring the Monitor Agent Cluster Resource to Load and Unload the Monitor
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
17.4 Testing the Monitor Agent in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
17.5 Managing the Monitor Agent in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
17.6 Monitor Agent Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
17.7 Monitor Agent Quick Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
novdocx (en) 11 July 2008
18 Backing Up a GroupWise System in a Linux Cluster 221
19 Updating a GroupWise System in a Linux Cluster 223
20 Moving an Existing Linux GroupWise 7 System into a Linux Cluster 225
21 Moving a Clustered GroupWise 7 System from NetWare to Linux 227
22 Implementing Messenger in a Linux Cluster 229
22.1 Planning Your Messenger System in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
22.1.1 Understanding Your Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
22.1.2 Selecting the Messenger Partition and Secondary IP Address . . . . . . . . . . . . . . . . 230
22.1.3 Determining an Appropriate Failover List for the Messenger Agents . . . . . . . . . . . 230
22.1.4 Determining Cluster Resource Information for the Messenger Agents . . . . . . . . . . 230
22.1.5 Planning the Messenger Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
22.2 Setting Up Your Messenger System in a Linux Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
22.2.1 Creating Your Messenger System and Installing the Messenger Agents . . . . . . . . 231
22.2.2 Changing Messenger Paths to Locations on the Messenger Partition . . . . . . . . . . 233
22.2.3 Configuring the Messenger Cluster Resource to Load and Unload the Messenger
Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
22.3 Testing Your Clustered Messenger System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
22.4 Managing Your Clustered Messenger System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
22.5 Messenger Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
22.6 Messenger Clustering Quick Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Part III Novell Teaming and Conferencing 243
23 Using GroupWise with Novell Teaming 245
23.1 Understanding How Novell Teaming Interacts with eDirectory and GroupWise . . . . . . . . . . 245
Contents 9
23.2 Meeting Novell Teaming System Requirements on OES 2 or SLES 10 SP1 Servers. . . . . . 245
23.2.1 Linux Open File Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
23.2.2 Java Development Kit Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
23.2.3 MySQL Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
23.2.4 Potential Web Server Port Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
23.3 Installing Novell Teaming with GroupWise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
23.3.1 Preparing for the Novell Teaming Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
23.3.2 Performing the Novell Teaming Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
23.4 Configuring LDAP Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
23.5 Configuring GroupWise to Support Your Teaming Installation. . . . . . . . . . . . . . . . . . . . . . . . 249
23.5.1 Configuring Outgoing E-Mail from Teaming to GroupWise . . . . . . . . . . . . . . . . . . . 249
23.5.2 Configuring Incoming E-Mail from GroupWise Users to the Novell Teaming Site . . 251
23.5.3 Testing GroupWise Integration with Novell Teaming. . . . . . . . . . . . . . . . . . . . . . . . 257
23.6 Receiving Notification of Teaming Site Activity in Your GroupWise Client. . . . . . . . . . . . . . . 259
23.7 Receiving Calendar Postings from the Teaming Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
23.8 Adding Portlets to Novell Teaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
23.8.1 Adding Liferay Portlets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
23.8.2 Adding GroupWise Portlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
24 Using GroupWise with Conferencing 263
novdocx (en) 11 July 2008
24.1 Configuring GroupWise as the Conferencing E-Mail System. . . . . . . . . . . . . . . . . . . . . . . . . 263
24.1.1 Preparing for GroupWise Integration with Conferencing . . . . . . . . . . . . . . . . . . . . . 263
24.1.2 Integrating GroupWise with Novell Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . . 263
24.1.3 Testing GroupWise as the Novell Conferencing E-Mail System . . . . . . . . . . . . . . . 264
25 Streamlining Authentication to Teaming or Conferencing 265
25.1 Using iChain for Authenticating to Teaming or Conferencing . . . . . . . . . . . . . . . . . . . . . . . . 265
25.1.1 Meeting iChain Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
25.1.2 Setting Up an iChain Web Server Accelerator for Teaming or Conferencing . . . . . 265
25.1.3 Adding the New Web Server Accelerator to the iChain Server Object in
ConsoleOne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
25.1.4 Using iChain for Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
25.2 Using Novell Access Manager for Authenticating to Teaming or Conferencing. . . . . . . . . . . 267
Part IV Other Novell Products 269
26 GroupWise DirXML Driver for Novell Identity Manager 271
26.1 Identity Manager Warnings in ConsoleOne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
26.1.1 Recovering a Deleted GroupWise Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
26.1.2 Grafting Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
26.1.3 Converting an External Entity to a User. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
26.1.4 Converting a User to an External Entity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
26.1.5 Associating a GroupWise Object with an eDirectory Object . . . . . . . . . . . . . . . . . . 272
26.1.6 Disassociating a GroupWise Object’s Attributes from an eDirectory Object . . . . . . 272
26.1.7 Resolving an Invalid Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
26.1.8 Disabling the DirXML Warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
26.1.9 Enabling the DirXML Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
10 GroupWise 7 Interoperability Guide
27 GroupWise Customization Tools 275
28 Novell exteNd 277
Part V Heartbeat on Linux 279
29 Introduction to GroupWise 7 and Heartbeat on Linux 281
29.1 Understanding Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
29.2 Meeting System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
29.3 Installing Heartbeat Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
29.4 Configuring Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
29.5 Starting Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
29.6 Managing Heartbeat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
29.7 Setting Up Shared Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
29.8 Setting Up Node Fencing or Resource Fencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
29.9 What’s Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
novdocx (en) 11 July 2008
30 Planning GroupWise in a Heartbeat Cluster 285
30.1 Planning Your Heartbeat Cluster for GroupWise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
30.1.1 Recording Heartbeat Cluster Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
30.1.2 Planning GroupWise Cluster Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
30.1.3 Planning Cluster Resources and Resource Groups . . . . . . . . . . . . . . . . . . . . . . . . 287
30.1.4 Planning Secondary IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
30.2 Planning a Software Distribution Directory for a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
30.3 Planning a New Clustered Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
30.4 Planning a New Clustered Post Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
30.5 Planning a New Library for a Clustered Post Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
30.6 Considering How to Install and Configure the Linux Agents in a Cluster . . . . . . . . . . . . . . . . 290
30.6.1 Recording Secondary IP Addresses for the Agents . . . . . . . . . . . . . . . . . . . . . . . . 290
30.6.2 Determining Appropriate Heartbeat Constraints for GroupWise Cluster Resource
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
30.6.3 Planning the Linux Agent Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
30.7 GroupWise Clustering Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
30.7.1 Heartbeat Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
30.7.2 GroupWise Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
31 Setting Up a Heartbeat Cluster 297
31.1 Starting the HA Management Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
31.2 Creating a Cluster Resource Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
31.3 Creating Native Heartbeat Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
31.3.1 EVMS Container Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
31.3.2 File System Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
31.3.3 IP Address Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
31.4 Creating Heartbeat Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
31.4.1 Place Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
31.4.2 Order Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
31.4.3 Colocation Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
31.5 Starting the Native Heartbeat Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Contents 11
32 Setting Up a Domain and a Post Office in a Heartbeat Cluster 307
32.1 Setting Up a New GroupWise System in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . 307
32.2 Creating a New Secondary Domain in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 308
32.3 Creating a New Post Office in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
32.4 Installing and Configuring the MTA and the POA in a Heartbeat Cluster. . . . . . . . . . . . . . . . 310
32.4.1 Running the GroupWise Installation Program on the Initial Node . . . . . . . . . . . . . . 311
32.4.2 Running the GroupWise Installation Program on Subsequent Nodes . . . . . . . . . . . 313
32.4.3 Creating and Configuring GroupWise Cluster Resources . . . . . . . . . . . . . . . . . . . . 315
32.4.4 Testing Your Agent Installation on Each Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
32.4.5 Changing Agent Paths to Locations on the Shared Storage Partition . . . . . . . . . . . 318
32.4.6 Setting Up New Instances of the Agents without Installing the Agent Software . . . 319
32.5 Testing Your Clustered GroupWise System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
32.6 Managing Your Clustered GroupWise System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
32.6.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . 321
32.6.2 Knowing What to Expect in MTA and POA Failover Situations . . . . . . . . . . . . . . . . 322
32.7 What’s Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
33 Implementing the Internet Agent in a Heartbeat Cluster 325
33.1 Planning the Internet Agent in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
33.1.1 Planning a Cluster Resource Group for the Internet Agent . . . . . . . . . . . . . . . . . . . 326
33.1.2 Planning a Domain for the Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
33.1.3 Recording the Internet Agent Secondary IP Address . . . . . . . . . . . . . . . . . . . . . . . 327
33.1.4 Determining Appropriate Heartbeat Constraints for the Internet Agent . . . . . . . . . . 327
33.1.5 Preparing DNS for the Clustered Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
33.1.6 Preparing Your Firewall for the Clustered Internet Agent . . . . . . . . . . . . . . . . . . . . 327
33.1.7 Planning the MTA Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
33.1.8 Planning the Internet Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
33.2 Setting Up the Internet Agent in a Heartbeat Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
33.2.1 Setting Up Native Heartbeat Cluster Resources for the Internet Agent. . . . . . . . . . 329
33.2.2 Creating a Domain for the Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
33.2.3 Installing the MTA for the Internet Agent Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 330
33.2.4 Installing and Configuring the Internet Agent in a Cluster . . . . . . . . . . . . . . . . . . . . 330
33.3 Testing the Internet Agent in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
33.4 Managing the Internet Agent in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
33.4.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . 339
33.4.2 Knowing What to Expect in an Internet Agent Failover Situation . . . . . . . . . . . . . . 340
33.5 Internet Agent Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
novdocx (en) 11 July 2008
34 Implementing WebAccess in a Heartbeat Cluster 343
34.1 Understanding the WebAccess Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
34.2 Planning the WebAccess Agent in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
34.2.1 Planning a Cluster Resource Group for the WebAccess Agent . . . . . . . . . . . . . . . 344
34.2.2 Planning a Domain for the WebAccess Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
34.2.3 Recording the WebAccess Secondary IP Address . . . . . . . . . . . . . . . . . . . . . . . . . 345
34.2.4 Determining Appropriate Heartbeat Constraints for the WebAccess Agent . . . . . . 345
34.2.5 Planning the MTA Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
34.2.6 Planning the WebAccess Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
34.2.7 Planning the WebAccess Application Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 346
34.3 Setting Up the WebAccess Agent in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
34.3.1 Setting Up Native Heartbeat Resources for the WebAccess Agent . . . . . . . . . . . . 347
34.3.2 Creating a Domain for the WebAccess Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
34.3.3 Installing the MTA for the WebAccess Agent Domain . . . . . . . . . . . . . . . . . . . . . . . 347
34.3.4 Installing and Configuring the WebAccess Agent in a Heartbeat Cluster . . . . . . . . 348
12 GroupWise 7 Interoperability Guide
34.3.5 Installing and Configuring the WebAccess Application on Your Web Server . . . . . 355
34.4 Testing the WebAccess Agent in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
34.5 Managing the WebAccess Agent in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
34.5.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . 357
34.5.2 Knowing What to Expect in a WebAccess Agent Failover Situation . . . . . . . . . . . . 357
34.6 WebAccess Agent Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
35 Implementing GroupWise Monitor in a Heartbeat Cluster 361
36 Backing Up a GroupWise System in a Heartbeat Cluster 363
37 Updating a GroupWise System in a Heartbeat Cluster 365
38 Moving an Existing Linux GroupWise 7 System into a Heartbeat Cluster 367
39 Implementing Messenger in a Heartbeat Cluster 369
39.1 Planning Your Messenger System in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
39.1.1 Planning a Cluster Resource Group for the Messenger Agents . . . . . . . . . . . . . . . 369
39.1.2 Recording the Messenger Agents’ Secondary IP Address . . . . . . . . . . . . . . . . . . . 370
39.1.3 Determining Appropriate Constraints for the Messenger Agents . . . . . . . . . . . . . . 370
39.1.4 Planning the Messenger Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
39.2 Setting Up Your Messenger System in a Heartbeat Cluster . . . . . . . . . . . . . . . . . . . . . . . . . 371
39.2.1 Setting Up Native Heartbeat Resources for the Messenger Agents . . . . . . . . . . . . 371
39.2.2 Creating Your Messenger System and Installing the Messenger Agents . . . . . . . . 372
39.2.3 Changing Messenger Paths to Locations on the Messenger Partition . . . . . . . . . . 376
39.3 Testing Your Clustered Messenger System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
39.4 Managing Your Clustered Messenger System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
39.5 Messenger Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
novdocx (en) 11 July 2008
Part VI Microsoft Clustering Services on Windows 381
40 Introduction to GroupWise 7 and Microsoft Clusters 383
41 Planning GroupWise in a Microsoft Cluster 385
41.1 Setting Up Your Microsoft Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
41.2 Planning a New Clustered Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
41.3 Planning a New Clustered Post Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
41.4 Planning a New Library for a Clustered Post Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
41.5 Planning GroupWise Resource Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
41.6 Planning Shared Administrative Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
41.7 Ensuring Successful Name Resolution for GroupWise Resource Groups. . . . . . . . . . . . . . . 389
41.8 Deciding How to Install and Configure the Agents in a Cluster . . . . . . . . . . . . . . . . . . . . . . . 391
41.8.1 Planning Cluster-Unique Port Numbers for Agents in the Cluster . . . . . . . . . . . . . . 391
41.8.2 Deciding Where to Install the Agent Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
41.8.3 Planning the Agent Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
41.8.4 Planning the Windows Agent Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
41.9 GroupWise Clustering Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
41.9.1 System Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
41.9.2 Network Address Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
41.9.3 Agent Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Contents 13
42 Setting Up a Domain and Post Office in a Microsoft Cluster 401
42.1 Preparing the Cluster for GroupWise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
42.1.1 Creating GroupWise Resource Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
42.1.2 Creating Agent Service Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
42.1.3 Configuring Short Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
42.2 Setting Up a New GroupWise System in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
42.3 Creating a New Secondary Domain in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
42.4 Creating a New Post Office in a Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
42.5 Installing and Configuring the MTA and the POA in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . 406
42.5.1 Installing the Agent Software in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
42.5.2 Editing Clustered Agent Startup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
42.5.3 Setting Up New Instances of the Agents without Installing the Agent Software . . . 408
42.6 Testing Your Clustered GroupWise System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
42.7 Managing Your Clustered GroupWise System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
42.7.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . 409
42.7.2 Knowing What to Expect in MTA and POA Failover Situations . . . . . . . . . . . . . . . . 410
42.8 What’s Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
43 Implementing the Internet Agent in a Microsoft Cluster 413
novdocx (en) 11 July 2008
43.1 Planning the Internet Agent in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
43.1.1 Planning a Domain for the Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
43.1.2 Planning the Internet Agent Resource Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
43.1.3 Planning Cluster-Unique Port Numbers for the Internet Agent and Its MTA . . . . . . 414
43.1.4 Preparing Your Firewall for the Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
43.1.5 Deciding Where to Install the Internet Agent and Its MTA . . . . . . . . . . . . . . . . . . . . 415
43.1.6 Planning the MTA Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
43.1.7 Planning the Internet Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
43.2 Setting Up the Internet Agent in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
43.2.1 Setting Up the Internet Agent Resource Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
43.2.2 Creating a Domain for the Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
43.2.3 Installing the MTA for the Internet Agent Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 417
43.2.4 Installing and Configuring the Internet Agent in a Cluster . . . . . . . . . . . . . . . . . . . . 417
43.2.5 Testing the Clustered Internet Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
43.3 Managing the Internet Agent in a Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
43.3.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . 420
43.3.2 Knowing What to Expect in an Internet Agent Failover Situation . . . . . . . . . . . . . . 421
43.4 Internet Agent Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
44 Implementing WebAccess in a Microsoft Cluster 423
44.1 Understanding the WebAccess Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
44.2 Planning WebAccess in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
44.2.1 Setting Up Your Web Server in the Microsoft Cluster . . . . . . . . . . . . . . . . . . . . . . . 424
44.2.2 Planning a New Domain for the WebAccess Agent. . . . . . . . . . . . . . . . . . . . . . . . . 424
44.2.3 Planning the WebAccess Resource Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
44.2.4 Planning Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA. . . 425
44.2.5 Deciding Where to Install the WebAccess Agent and Its MTA . . . . . . . . . . . . . . . . 426
44.2.6 Planning the MTA Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
44.2.7 Planning the WebAccess Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
44.3 Setting Up WebAccess in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
44.3.1 Setting Up the WebAccess Resource Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
44.3.2 Creating a Domain for the WebAccess Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
44.3.3 Installing the MTA for the WebAccess Agent Domain . . . . . . . . . . . . . . . . . . . . . . . 428
44.3.4 Installing the WebAccess Agent in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
14 GroupWise 7 Interoperability Guide
44.3.5 Installing and Configuring the WebAccess Application in a Cluster . . . . . . . . . . . . 429
44.3.6 Testing Your Clustered WebAccess Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
44.4 Managing WebAccess in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
44.4.1 Updating GroupWise Objects with Cluster-Specific Descriptions . . . . . . . . . . . . . . 431
44.4.2 Knowing What to Expect in WebAccess Failover Situations . . . . . . . . . . . . . . . . . . 432
44.4.3 Updating the WebAccess Agent Configuration File (commgr.cfg). . . . . . . . . . . . . . 432
44.5 WebAccess Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
45 Implementing GroupWise Gateways in a Microsoft Cluster 435
46 Monitoring a GroupWise System in a Microsoft Cluster 437
47 Backing Up a GroupWise System in a Microsoft Cluster 439
48 Moving an Existing GroupWise 7 System into a Microsoft Cluster 441
49 Implementing Messenger in a Microsoft Cluster 443
49.1 Planning Your Messenger System in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
49.1.1 Understanding Your Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
49.1.2 Planning Messenger Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
49.1.3 Deciding Where to Install the Messenger Agent Software . . . . . . . . . . . . . . . . . . . 444
49.1.4 Planning the Messenger Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
49.2 Setting Up Your Messenger System in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
49.2.1 Installing the Messenger Agents to Each Node in the Cluster. . . . . . . . . . . . . . . . . 446
49.2.2 Installing the Messenger Agents to a Shared Disk . . . . . . . . . . . . . . . . . . . . . . . . . 446
49.3 Messenger Clustering Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
novdocx (en) 11 July 2008
Part VII Non-GroupWise Clients 449
50 Outlook Express 451
51 Microsoft Outlook 453
52 Evolution 455
52.1 GroupWise Features Available in Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
52.2 Configuring Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Part VIII Mobile Devices 459
53 GroupWise Mobile Server, Powered by Intellisync 461
54 BlackBerry Enterprise Server 463
55 GroupWise PDA Connect 465
55.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
55.2 Downloading the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
55.3 Third-Party Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Contents 15
Part IX Documentation Updates 467
A June 25, 2008 469
B March 14, 2008 (GroupWise 7 SP3) 471
C October 24, 2007 473
D April 16, 2007 (GroupWise 7 SP 2) 475
E September 29, 2006 477
F August 2, 2006 479
G June 15, 2006 (GroupWise 7 SP1) 481
novdocx (en) 11 July 2008
H November 30, 2005 485
16 GroupWise 7 Interoperability Guide

About This Guide

This Novell® GroupWise® 7 Interoperability Guide helps you use GroupWise in the context of other software products. The guide provides assistance with Novell products and third-party products:
Novell Products Part I, “Novell Cluster Services on NetWare,” on page 19
Part II, “Novell Cluster Services on Linux,” on page 129
Part III, “Novell Teaming and Conferencing,” on page 243
Part IV, “Other Novell Products,” on page 269
novdocx (en) 11 July 2008
Third-Party Products
For information about additional GroupWise-related software from GroupWise partners, see the
Novell Partner Product Guide (http://www.novell.com/partnerguide).
Audience
This guide is intended for network administrators who install and administer GroupWise.
Feedback
We want to hear your comments and suggestions about this manual and the other documentation included with this product. Please use the User Comment feature at the bottom of each page of the online documentation, or go to www.novell.com/documentation/feedback.html and enter your comments there.
Documentation Updates
For the most recent version of the GroupWise 7 Interoperability Guide, visit the Novell GroupWise
7 documentation Web site (http://www.novell.com/documentation/gw7).
Part V, “Heartbeat on Linux,” on page 279
Part VI, “Microsoft Clustering Services on Windows,” on page 381
Part VII, “Non-GroupWise Clients,” on page 449
Additional Documentation
For additional GroupWise documentation, see the following guides at the Novell GroupWise 7
documentation Web site (http://www.novell.com/documentation/gw7):
Installation Guide
Administration Guide
Multi-System Administration Guide
Troubleshooting Guides
GroupWise Client User Guides
GroupWise Client Frequently Asked Questions (FAQ)
About This Guide 17
Documentation Conventions
In Novell documentation, a greater-than symbol (>) is used to separate actions within a step and items within a cross-reference path.
TM
A trademark symbol (
, ®, etc.) denotes a Novell trademark. An asterisk denotes a third-party
trademark.
When a single pathname can be written with a backslash for some platforms or a forward slash for other platforms, the pathname is presented with a backslash. Users of platforms that require a forward slash, such as Linux*, should use forward slashes as required by your software.
When a startup switch can be written with a forward slash for some platforms or a double hyphen for other platforms, the startup switch is presented with a forward slash. Users of platforms that require a double hyphen, such as Linux, should use double hyphens as required by your software.
novdocx (en) 11 July 2008
18 GroupWise 7 Interoperability Guide
I
Novell Cluster Services on NetWare
Chapter 1, “Introduction to GroupWise 7 and Novell Cluster Services on NetWare,” on page 21
Chapter 2, “Planning GroupWise in a NetWare Cluster,” on page 23
Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,” on page 43
Chapter 4, “Implementing the Internet Agent in a NetWare Cluster,” on page 69
Chapter 5, “Implementing WebAccess in a NetWare Cluster,” on page 89
Chapter 6, “Implementing GroupWise Gateways in a Novell Cluster,” on page 107
Chapter 7, “Monitoring a GroupWise System in a NetWare Cluster,” on page 109
Chapter 8, “Backing Up a GroupWise System in a NetWare Cluster,” on page 111
Chapter 9, “Updating a GroupWise System in a NetWare Cluster,” on page 115
Chapter 10, “Moving an Existing GroupWise 7 System into a NetWare Cluster,” on page 117
novdocx (en) 11 July 2008
Chapter 11, “Implementing Messenger in a NetWare Cluster,” on page 119
Novell Cluster Services on NetWareI19
novdocx (en) 11 July 2008
20 GroupWise 7 Interoperability Guide
1
Introduction to GroupWise 7 and
novdocx (en) 11 July 2008
Novell Cluster Services on NetWare
Before implementing GroupWise® 7 with Novell® Cluster ServicesTM, make sure you have a solid understanding of Novell Cluster Services by reviewing the following information resources:
AppNote: An Introduction to Novell Cluster Services (http://developer.novell.com/research/
appnotes/1999/may/01/a990501_.pdf)
Novell Open Enterprise Server (OES) Product Documentation: OES Novell Cluster
Services 1.8 Administration Guide for NetWare (http://www.novell.com/documentation/oes/ cluster_admin/data/h4hgu4hs.html#bktitle)
NetWare 6.5 Product Documentation: Novell Cluster Services (http://www.novell.com/
documentation/ncs65)
NetWare 6 Product Documentation: Novell Cluster Services (http://www.novell.com/
documentation/ncs6p)
NetWare 5.1 Product Documentation: Novell Cluster Services (http://www.novell.com/
documentation/ncs)
When you review the information resources recommended above, you discover that clustering employs very specialized terminology. The following brief glossary provides basic definitions of clustering terms and relates them to your GroupWise system:
®
cluster: A grouping of from 2 to 32 NetWare that data storage locations and applications can transfer from one server to another without interrupting their availability to users.
servers configured using Novell Cluster Services so
1
node: A clustered server; in other words, a single NetWare server that is part of a cluster.
resource: An IP address, volume, application, service, and so on, that can function successfully
anywhere in the cluster. The volumes where domains and post offices reside are a specific type of cluster resources termed “volume resources.” In this section, the terms “cluster resource” and “volume resource” are used instead of “resource” to avoid confusion with GroupWise resources (such as conference rooms and projectors).
failover: The process of moving cluster resources from a failed node to a functional node so that availability to users is uninterrupted. For example, if the node where the POA is running goes down, the POA and its post office fail over to a secondary node so that users can continue to use GroupWise. When setting up cluster resources, you need to consider what components need to fail over together in order to continue functioning.
fan-out-failover: The configuration where cluster resources from a failed node fail over to different nodes in order to distribute the load from the failed node across multiple nodes. For example, if a node runs a cluster resource consisting of a domain and its MTA, another cluster resource consisting of a post office and its POA, and a third cluster resource for WebAccess, each cluster resource can be configured to fail over separately to different secondary nodes.

Introduction to GroupWise 7 and Novell Cluster Services on NetWare

21
failback: The process of returning cluster resources to their preferred node after the situation causing the failover has been resolved. For example, if a POA and its post office fail over to a secondary node, that cluster resource can be configured to fail back to its preferred node when the problem is resolved.
migration: The process of manually moving a cluster resource from its preferred node to a secondary node for the purpose of performing maintenance on the preferred node, temporarily lightening the load on the preferred node, and so on.
shared disk system: The hardware housing the physical disk volumes that are shared among the cluster nodes.
shared volume: A volume in a shared disk system that can be accessed from any cluster node that needs the data stored on it.
novdocx (en) 11 July 2008
cluster-enabled shared volume: A shared volume for which a Volume Resource object has been
TM
created in Novell eDirectory
. The properties of the Volume Resource object provide load and unload scripts for programs installed on the volume, failover/failback/migration policies for the volume, and the failover path for the volume. Cluster-enabling is highly recommended for GroupWise.
GroupWise volume: As used in this section, a cluster-enabled shared volume that is used for GroupWise, such as for storing a domain, post office, software distribution directory, and so on. This section also uses the terms Internet Agent volume, WebAccess Agent volume, Messenger volume, and gateway volume in a similar manner.
storage area network (SAN): The cluster nodes together with their shared disk system and shared volumes.
virtual server: A logical server, rather than a physical server, to which cluster-enabled shared volumes are tied.
active/active mode: The configuration of a clustered application where the application runs simultaneously on multiple nodes in the cluster. Active/active mode is recommended when the GroupWise MTA, POA, Internet Agent, and WebAccess Agent run in protected memory because protected memory isolates them from each other, even if they are running on the same node.
active/passive mode: The configuration of a clustered application where the application runs on only one node at a time in the cluster. The GroupWise MTA, POA, Internet Agent, and WebAccess Agent must run in active/passive mode if they are not running in protected memory because only one instance of each agent/database combination can be running at the same time in the cluster.
22 GroupWise 7 Interoperability Guide
2
Planning GroupWise in a NetWare
novdocx (en) 11 July 2008
Cluster
The majority of this part of the GroupWise 7 Interoperability Guide (Chapter 2, “Planning
GroupWise in a NetWare Cluster,” on page 23 through Chapter 8, “Backing Up a GroupWise System in a NetWare Cluster,” on page 111) is designed for those who are creating a new
GroupWise Services a newly installed cluster, see Chapter 10, “Moving an Existing GroupWise 7 System into a NetWare
Cluster,” on page 117.
When you implement a new GroupWise system or a new domain or post office in a clustering environment, overall GroupWise system design does not need to change substantially. For a review, see “Installing a Basic GroupWise System” in the GroupWise 7 Installation Guide. However, the configuration of individual components of your GroupWise system will be significantly different. This section helps you plan the following GroupWise components in a cluster:
A new GroupWise system consisting of the primary domain and the initial post office
A new secondary domain
A new post office
The GroupWise agents (MTA and POA)
®
system, or at least new domains and post offices, in the context of Novell® Cluster
TM
. If you already have an existing GroupWise 7 system and need to configure it to work in
2
During the planning process, component configuration alternatives are explained. For example, you might want the domain and post office together on the same shared volume or on different shared volumes. You might want to install the agents to standard sys:\system directories or to manually created vol:\system directories on shared volumes where domains and post offices reside. You might or might not need to run the agents in protected memory.
The “System Clustering Worksheet” on page 37 lists all the information you need as you set up GroupWise in a clustering environment. You should print the worksheet and fill it out as you complete the tasks listed below:
Section 2.1, “Meeting Software Version Requirements,” on page 24
Section 2.2, “Installing Novell Cluster Services,” on page 24
Section 2.3, “Planning a New Clustered Domain,” on page 25
Section 2.4, “Planning a New Clustered Post Office,” on page 26
Section 2.5, “Planning a New Library for a Clustered Post Office,” on page 27
Section 2.6, “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise,”
on page 27
Section 2.7, “Ensuring Successful Name Resolution for GroupWise Volumes,” on page 29
Section 2.8, “Deciding How to Install and Configure the Agents in a Cluster,” on page 31
Section 2.9, “GroupWise Clustering Worksheets,” on page 37
After you have completed the tasks and filled out “System Clustering Worksheet” on page 37, you are ready to continue with Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,”
on page 43.

Planning GroupWise in a NetWare Cluster

23

2.1 Meeting Software Version Requirements

GroupWise 7 can be clustered on a system that meets the following requirements:
GroupWise 7
A supported version of NetWare
OES NetWare
NetWare 6.5
NetWare 6
NetWare 5.1
IMPORTANT: Novell Cluster Services does not support mixed NetWare versions within a cluster.
SYSTEM CLUSTERING WORKSHEET
Under Item 1: Software Version Updates for Cluster, mark any updates required for nodes in the cluster to ensure that all nodes in the cluster are running the same version of NetWare.
®
with the latest Support Pack
novdocx (en) 11 July 2008

2.2 Installing Novell Cluster Services

Install Novell Cluster Services by following the instructions provided in the documentation for your version of NetWare, as listed in Chapter 1, “Introduction to GroupWise 7 and Novell Cluster
Services on NetWare,” on page 21.
The installation process includes:
Meeting hardware and software requirements
Setting up a shared disk system
Creating a new NetWare Cluster object to represent the cluster in Novell eDirectory
Adding nodes to the cluster
Installing the Novell Cluster Services software on all nodes in the cluster
Mounting the shared volumes where you will set up GroupWise domains and post offices and
install the GroupWise agents
As you install Novell Cluster Services, record key information about the cluster on the System Clustering Worksheet:
SYSTEM CLUSTERING WORKSHEET
Under Item 2: eDirectory Tree for Cluster, record the name of the eDirectory tree where the new NetWare Cluster object has been created.
TM
Under Item 3: Cluster Name, record the name of the NetWare Cluster object that you created for your GroupWise system.
Under Item 4: Cluster Context, record the full context of the NetWare Cluster object.
Under Item 5: Nodes in Cluster, list the nodes that you have added to the cluster.
24 GroupWise 7 Interoperability Guide
The number of nodes and shared volumes that are available in the cluster strongly influences where you place GroupWise domains and post offices. You have several alternatives:
Your whole GroupWise system can run in a single cluster.
Parts of your GroupWise system can run in one cluster while other parts of it run in one or more
other clusters.
Parts of your GroupWise system can run in a cluster while other parts run outside of the cluster,
on non-clustered servers.
If you do not have the system resources to run all of your GroupWise system in a clustering environment, you must decide which parts have the most urgent need for the high availability provided by clustering. Here are some suggestions:
Post offices and their POAs must be available in order for users to access their GroupWise
mailboxes. Therefore, post offices and their POAs are excellent candidates for the high availability provided by clustering.
In a like manner, WebAccess provides user access to GroupWise mailboxes across the Internet
through users’ Web browsers. It is another good candidate for clustering.
Domains and their MTAs are less noticeable to users when they are unavailable (unless users in
different post offices happen to be actively engaged in an e-mail discussion when the MTA goes down). On the other hand, domains and their MTAs are critical to GroupWise administrators, although administrators might be more tolerant of a down server than end users are. Critical domains in your system would be the primary domain and, if you have one, a hub or routing domain. These domains should be in the cluster, even if other domains are not.
novdocx (en) 11 July 2008
The Internet Agent might or might not require high availability in your GroupWise system,
depending on the importance of immediate messaging across the Internet and the use of POP3 or IMAP4 clients by GroupWise users.
There is no right or wrong way to implement GroupWise in a clustering environment. It all depends on the specific needs of your particular GroupWise system and its users.

2.3 Planning a New Clustered Domain

The considerations involved in planning a new domain in a clustering environment are essentially the same as for any other environment.
Primary Domain: If you are setting up a new GroupWise system in a clustering environment,
you will be creating the primary domain as you complete the tasks in this section. In preparation, review “Planning Your Basic GroupWise System”, then print and fill out the Basic GroupWise System Worksheet” in “Installing a Basic GroupWise System” in the
GroupWise 7 Installation Guide. This covers planning the primary domain and an initial post
office in the primary domain.
Secondary Domain: If your GroupWise system already exists, you will be creating a new
secondary domain. In preparation, review “Planning a New Domain”, then print and fill out the “Domain Worksheet” in “Domains” in the GroupWise 7 Administration Guide.
Planning GroupWise in a NetWare Cluster 25
Regardless of the type of domain you are creating, keep in mind the following cluster-specific details as you fill out the worksheet you need:
When you specify the location for the domain directory (and for a new GroupWise system, the
post office directory) on the worksheet, include the shared volume where you want the directory to reside.
Do not concern yourself with the GroupWise agent information on the worksheet. You will
plan the agent installation later. If you are filling out the Basic GroupWise System Worksheet, stop with item 17. If you are filling out the Domain Worksheet, stop with item 10.
When you have completed the worksheet, transfer the key information from the Basic GroupWise System Worksheet or the Domain Worksheet to the System Clustering Worksheet.
SYSTEM CLUSTERING WORKSHEET
Under Item 10: Domain Name, transfer the domain name and database directory to the System Clustering Worksheet.
Under Item 7: Shared Volume for Domain, transfer the domain location to the System Clustering Worksheet. You will fill out the rest of the information under item 7 later.
novdocx (en) 11 July 2008
IMPORTANT: Do not create the new domain until you are instructed to do so in Chapter 3,
“Setting Up a Domain and Post Office in a NetWare Cluster,” on page 43.

2.4 Planning a New Clustered Post Office

The considerations involved in planning a new post office in a clustering environment are essentially the same as for any other environment. The initial post office in a new GroupWise system is planned on the Basic GroupWise System Worksheet. To plan additional new post offices, review “Planning a New Post Office ”, then print and fill out the “Post Office Worksheet” in “Post
Offices” in the GroupWise 7 Administration Guide. When you specify the locations for the post
office directories, include the shared volumes where you want the post office directories to reside.
When you have completed the worksheet, transfer key information from the Basic GroupWise System Worksheet or the Post Office Worksheet to the System Clustering Worksheet.
SYSTEM CLUSTERING WORKSHEET
Under Item 11: Post Office Name, transfer the post office name and database location to the System Clustering Worksheet.
If you will create the post office on a different shared volume from where the domain is located, under
Item 8: Shared Volume for Post Office, transfer the post office location to the System Clustering
Worksheet. You will fill out the rest of the information under item 8 later.
IMPORTANT: Do not create the new post office until you are instructed to do so in Chapter 3,
“Setting Up a Domain and Post Office in a NetWare Cluster,” on page 43.
26 GroupWise 7 Interoperability Guide

2.5 Planning a New Library for a Clustered Post Office

The considerations involved in planning a new library in a clustering environment are essentially the same as for any other environment. You can plan a library for a clustered post office by following the standard instructions provided in “Creating and Managing Libraries” in the GroupWise 7
Administration Guide and filling out the “Basic Library Worksheet” or the “Full-Service Library
Worksh ee t”. Then provide the library information on the System Clustering Worksheet.
SYSTEM CLUSTERING WORKSHEET
Under Item 14: Library Location, mark where you want to create the library’s document storage area.
If the document storage area will be located outside the post office directory structure, specify a user name and password that the POA can use to access the volume where the document storage area will reside.
IMPORTANT: Do not create the new library until you are instructed to do so in Chapter 3, “Setting
Up a Domain and Post Office in a NetWare Cluster,” on page 43.
novdocx (en) 11 July 2008

2.6 Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise

Cluster-enabling the shared volumes where domains and post offices reside greatly simplifies GroupWise administration. If you are creating a new GroupWise system, you might also want to cluster-enable shared volumes for the GroupWise administration snap-ins to ConsoleOne the GroupWise software distribution directory so that these locations are always available within the cluster. To review the concept of cluster-enabled shared volumes, see the applicable section of clustering documentation for your version of NetWare, as listed in Chapter 1, “Introduction to
GroupWise 7 and Novell Cluster Services on NetWare,” on page 21.
The advantages of cluster-enabling GroupWise volumes include:
Drive mappings always occur through the virtual server associated with the cluster-enabled
volume, rather than through a physical server. This guarantees that you can always map a drive to the domain or post office database no matter which node it is currently located on.
The GroupWise snap-ins to ConsoleOne always work no matter which node is running
ConsoleOne.
Cluster-enabling the domain volume and installing the GroupWise agents to this volume
guarantees that the GroupWise snap-ins to ConsoleOne can always find the configuration files that they need to access.
When you rebuild a domain database or a post office database, you do not need to determine
which node the database is currently located on.
Help desk personnel do not need to be trained to determine where GroupWise is running before
they connect to a domain to create a new GroupWise user.
®
and for
When you cluster-enable a volume, additional eDirectory objects are created:
Planning GroupWise in a NetWare Cluster 27
Table 2-1 eDirectory Objects Used in a Cluster
novdocx (en) 11 July 2008
eDirectory Object
Object Name and Description
clustername_volumename (default object name) A new Volume object represents the cluster-enabled volume. It is created by renaming the original Volume object that was tied to a physical server and associating it with a virtual server instead.
For example, if your cluster name is GWCLUSTER and your original volume name is gwvol1, the new Volume object representing the cluster-enabled volume is named gwcluster_gwvol1.
clustername_volumename_SERVER (default object name) A new Server object represents the virtual server to which the new cluster-enabled volume is tied.
Continuing with the above example, the new Server object representing the virtual server is named GWCLUSTER_GWVOL1_SERVER.
volumename_SERVER.clustername (default object name) A new Volume Resource object stores property information for the cluster-enabled volume, such as start, failover, and failback mode information and load/unload scripts. These modes and scripts enable the cluster-enabled volume to function much like an independent server; hence, the SERVER portion of its name. The Volume Resource object is created in the Cluster container object.
Continuing with the above example, the new Volume Resource object is named GWVOL1_SERVER.GWCLUSTER.
IMPORTANT: Notice that the default object names include the underscore (_) character. Some DNS name servers cannot resolve object names that include underscore characters. If you have met the system requirements described in Section 2.1, “Meeting Software Version Requirements,” on
page 24, you can rename these objects as needed when you cluster enable the volume.
Cluster-enabling the shared volumes used by GroupWise is highly recommended. Throughout the rest of this document, the term “GroupWise volume” means “a cluster-enabled shared volume used by GroupWise.”
SYSTEM CLUSTERING WORKSHEET
Under Item 6: Shared Volumes for GroupWise Administration, list any shared volumes you want to use for GroupWise administration purposes. For example, you might have a shared pub: volume with a public directory where you install the GroupWise snap-ins to ConsoleOne instead of installing them on multiple administrator workstations. You might have a shared apps: volume where you create the GroupWise software distribution directory. Mark whether or not you want to cluster-enable the GroupWise administration volumes.
Under Item 7: Shared Volume for Domain, specify the name of the shared volume where you will create the domain. Mark whether or not you want to cluster-enable the domain volume. Also mark whether you will place the post office on the same volume with the domain.
If you want the post office on a different volume from where the domain is located, under Item 8:
Shared Volume for Post Office, specify the name of the shared volume where you will create the post
office. Mark whether or not you want to cluster-enable the post office volume.
28 GroupWise 7 Interoperability Guide
IMPORTANT: Because cluster-enabling the volumes where domains and post offices reside is so strongly recommended, this documentation does not include the steps for setting up domains and post offices on non-cluster-enabled volumes. If you decide not to cluster-enable GroupWise volumes, you should adjust the steps presented in this documentation for your system’s specialized needs. Novell Cluster Services does provide a GroupWise Mail Server template for use when creating GroupWise Cluster Resource objects instead of cluster-enabled Volume Resource objects.

2.7 Ensuring Successful Name Resolution for GroupWise Volumes

Because you are using cluster-enabled volumes for GroupWise domains and post offices, you must ensure that short name resolution is always successful. For example, in ConsoleOne, if you right­click a Domain object in the GroupWise View and then click Connect, ConsoleOne must be able to resolve the domain database location, as provided in the UNC Path field, to the network address of the current, physical location of that domain within your cluster. It is through short name resolution that all GroupWise cluster resources (such as domain and post office volumes) are accessed and managed in ConsoleOne.
novdocx (en) 11 July 2008
A client program (such as ConsoleOne) that runs on a Windows* workstation, can be configured to use several different short name resolution methods. To see which methods are in use at a particular workstation, view the protocol preferences for the Novell Client workstation:
Figure 2-1 Novell Client Preferences Property Page
TM
that is installed on the Windows
Short name resolution methods that pertain to clustering your GroupWise system are discussed below:
Planning GroupWise in a NetWare Cluster 29
Table 2-2 Short Name Resolution Methods
Short Name Resolution Method Description
eDirectory You can use eDirectory to resolve short names into specific network addresses. However,
when using eDirectory for short name resolution, you must remember to consider current context in the name resolution process. eDirectory short name resolution works only if your current context is the same as the context of the eDirectory object you need to access.
novdocx (en) 11 July 2008
Hosts File
Windows uses the following files when performing short name resolution at the workstation:
Windows 2000/XP/2003:
\winnt\system32\drivers\etc\hosts
Using these files at the Windows workstation is not a preferred method for TCP/IP name resolution (except perhaps for the administrator’s workstation).
However, whenever you cluster-enable a volume, you should add its virtual server to the sys:\etc\hosts file of all nodes in the cluster.
DNS Perhaps the most common short name resolution option is Domain Name Service (DNS).
As with the hosts file, it is good practice to place all of your virtual servers into DNS.
For short name resolution to work using DNS, the client workstation must either belong to the same DNS zone (such as provo.novell.com) as the cluster resource, or the cluster resource zone must be configured in the client’s DNS suffix search path under TCP/IP settings for the workstation.
The underscore (_) character is part of default cluster-related object names. Because it is not supported by the DNS RFC, some DNS name servers cannot resolve default cluster­related object names. If you are using such a DNS name server on NetWare 5.1, make sure you have installed the latest Novell Cluster Services snap-in to ConsoleOne, so that you can change cluster-related object names as needed to remove the underscore characters.
SLP NetWare 6.x and NetWare 5.1 both use Service Location Protocol (SLP) to advertise
service information across TCP/IP-based networks, which provides short name resolution of TCP/IP-based cluster resources within the network. On NetWare 6.x, Novell Cluster Services propagates virtual server information into SLP by default.
On NetWare 5.1, Novell Cluster Services does not propagate virtual server information into SLP by default. If you want to propagate virtual server information to SLP on NetWare 5.1, you can run the (unsupported) CVSBIND utility, which gives you reliable short name resolution within your cluster regardless of shortcomings you might encounter with other name resolution methods.
Specific setup instructions for each of these short name resolution methods will be provided in
Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,” on page 43.
30 GroupWise 7 Interoperability Guide

2.8 Deciding How to Install and Configure the Agents in a Cluster

There are several cluster-specific issues to consider as you plan to install the NetWare MTA and POA in your clustered GroupWise system:
Section 2.8.1, “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents
in the Cluster,” on page 31
Section 2.8.2, “Determining Appropriate Failover Paths for the Agents,” on page 33
Section 2.8.3, “Deciding Where to Install the Agent Software,” on page 34
Section 2.8.4, “Deciding Whether to Run the Agents in Protected Memory,” on page 36
Section 2.8.5, “Planning the NetWare Agent Installation,” on page 37
2.8.1 Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster
The GroupWise agents listen on all IP addresses, both primary and secondary, that are bound to the server on their specified port numbers. This means that any time there is a possibility of two of the same type of agent loading on the same node, it is important that each agent use a cluster-unique port number, even though each agent is using a unique secondary IP address. The best way for you to avoid port conflicts is to plan your cluster so that each agent in the cluster runs on a cluster-unique port. Print out a copy of the “IP Address Worksheet” on page 40 to help you plan secondary IP addresses and cluster-unique port numbers for all GroupWise agents.
novdocx (en) 11 July 2008
The following filled-out version of the IP Address Worksheet illustrates one way this can be done:
Domain Information
Domain
Provo1 172.16.5.81 7100 7180
MTA IP Address
MTA MTP Port
MTA HTTP Port
Post Office Information
Post Office
Development (same as MTA) 1677 7101 7181
Manufacturing 172.16.5.82 1678 7102 7182
POA IP Address
POA C/S Port
POA MTP Port
POA HTTP Port
Planning GroupWise in a NetWare Cluster 31
Internet Agent Information
novdocx (en) 11 July 2008
Internet Agent
GWIA Domain MTA
Internet Agent (GWIA)
GWIA IP Address
172.16.5.83 7110 7677 7183 N/A
(same as MTA) N/A N/A N/A 9850
MTA MTP Port
MTA Live Remote Port
MTA HTTP Port
GWIA HTTP Port
WebAccess Information
WebAccess Agent
WebAccess Domain MTA
WebAccess Agent (GWINTER)
WebAccess IP Address
172.16.5.84 7120 7184 N/A N/A
(same as MTA) N/A N/A 7205 7205
MTA MTP Port
MTA HTTP Port
WebAccess Agent Port
WebAccess HTTP Port
(same as agent)
This example places the Development post office on the same node and on the same GroupWise volume with the Provo1 domain; therefore, the Provo1 MTA and the Development POA can use the same secondary IP address. The Manufacturing post office is placed on a different node on a different GroupWise volume, so that the Manufacturing post office has a different secondary IP address.
The example also illustrates that the MTA, the POA, and the Internet Agent use different port numbers for agent ports and HTTP ports. In contrast, the WebAccess Agent uses the same port number for the agent port and the HTTP port.
The example uses default port numbers where possible. For example, the default MTA message transfer port is 7100 and the default POA client/server port is 1677. Incrementing port numbers are used in the example when multiple components have the same type of ports. For example, port numbers 1677 and 1678 are both POA client/server ports and port numbers 7180 through 7184 are all HTTP ports. Incrementing from the default port numbers generates unique, though related, port numbers.
If you are going to set up a GroupWise name server to help GroupWise clients locate their post offices, make sure that the default POA port number of 1677 is used somewhere in the cluster. For more information, see “Simplifying Client/Server Access with a GroupWise Name Server” in “Post
Office Agent” in the GroupWise 7 Administration Guide.
IP ADDRESS WORKSHEET
Fill out the “IP Address Worksheet” on page 40 to help you plan secondary IP addresses and cluster- unique port numbers for all GroupWise agents in the cluster. (MTA, POA, Internet Agent, WebAccess Agent).
32 GroupWise 7 Interoperability Guide
After you have filled out the IP Address Worksheet, transfer the secondary IP addresses and cluster­unique port numbers from the IP Address Worksheet to the System Clustering Worksheet and the Agent Clustering Worksheet so that they are available in the sequence in which you will need them as you set up GroupWise in a cluster.
SYSTEM CLUSTERING WORKSHEET
If you are setting up a new GroupWise system, under Item 6: Shared Volumes for GroupWise
Administration, specify secondary IP addresses for your GroupWise administration volumes.
Under Item 7: Shared Volume for Domain, use the domain MTA secondary IP address from the IP Address Worksheet as the domain volume IP address.
If you are planning the post office on a different volume from the domain, under Item 8: Shared
Volume for Post Office, use the post office POA secondary IP address from the IP Address
Worksheet as the post office volume IP address.
AGENT CLUSTERING WORKSHEET
novdocx (en) 11 July 2008
Under Item 4: MTA Network Information, transfer the secondary IP address and cluster-unique port numbers for the MTA from the IP Address Worksheet to the Agent Clustering Worksheet.
Under Item 7: POA Network Information, transfer the secondary IP address and cluster-unique port numbers for the POA from the IP Address Worksheet to the Agent Clustering Worksheet.
2.8.2 Determining Appropriate Failover Paths for the Agents
By default, a GroupWise volume is configured to have all nodes in the cluster in its failover path, organized in ascending alphanumeric order. Only one node at a time can have a particular GroupWise volume mounted and active. If a GroupWise volume’s preferred node fails, the volume fails over to the next node in the failover path. You will want to customize the failover path for each GroupWise volume based on the fan-out-failover principle.
When a node fails, its volumes should not all fail over together to the same secondary node. Instead, the volumes should be distributed across multiple nodes in the cluster. This prevents any one node from shouldering the entire processing load typically carried by another node. In addition, some volumes should never have the potential of being mounted on the same node during a failover situation. For example, a post office and POA that service a large number of very active GroupWise client users should never fail over to a node where another very large post office and heavily loaded POA reside. If they did, users on both post offices would notice a decrease in responsiveness of the GroupWise client.
AGENT CLUSTERING WORKSHEET
Under Item 3: Domain Failover Path, list the nodes that you want to have in the domain volume failover path. The MTA might need to run on any node that the domain volume fails over to.
If you are planning the post office on a different GroupWise volume from where the domain is located, under Item 6: Post Office Failover Path, list the nodes that you want to have in the post office volume failover path. The POA might need to run on any node that the post office volume fails over to.
Planning GroupWise in a NetWare Cluster 33
2.8.3 Deciding Where to Install the Agent Software
When you install the NetWare MTA and POA in a clustering environment, you can choose between two different installation locations:
Table 2-3 Agent Software Installation Locations
Location Description
novdocx (en) 11 July 2008
sys:\system on each node in the cluster
This is the default location provided by the Agent Installation program. Because the agents must be installed on each node where they might need to run during a failover situation, you need to do one of the following if you select this alternative:
Run the Agent Installation program multiple times in order to install the
agent software and to create the agent startup files on each node that is on a GroupWise volume failover path.
Run the Agent Installation program, then copy the agent software and
startup files to each node that is on a GroupWise volume failover path.
system directory on each GroupWise volume
If you create a vol:\system directory on a GroupWise volume, the agent software and startup files fail over and back with the domains and post offices that the agents service.
Unless you have a very small GroupWise system with all domains and post offices on a single GroupWise volume, you still need to install the agent software multiple times, once to each GroupWise volume.
A simple way to look at the agent location alternatives would be that if you have fewer nodes on failover paths than you have GroupWise volumes for domains and post offices, then it would be most efficient to install the agent software to the nodes. Conversely, if you have fewer GroupWise volumes than you have nodes on failover paths, then it would be most efficient to install the agent software to the GroupWise volumes. However, there are issues to consider that extend beyond efficiency during installation.
The following sections can help you choose which installation location would be best for your clustered GroupWise system:
“Advantages of a vol:\system Directory on Each GroupWise Volume” on page 34
“Disadvantages of a vol:\system Directory on Each GroupWise Volume” on page 35
“Recommendation” on page 35
Advantages of a vol:\system Directory on Each GroupWise Volume
Using a vol:\system directory on each GroupWise volume has several advantages:
If you change information in the agent startup files, you only need to change it in one place, not
on every node on any GroupWise volume failover path.
Having the agent startup files on the same GroupWise volume as the domain or post office
makes them easy to find.
34 GroupWise 7 Interoperability Guide
When you update the agent software, you only need to update it in one place for a particular
domain or post office, not on every node on a GroupWise volume failover path. This prevents the potential problem of having a domain or post office fail over to a location where a different version of the agent software is installed.
If you ever need to add or replace a physical server in the cluster, you only need to install
NetWare and Novell Cluster Services to the new server, then add that node to the appropriate failover paths. No extra GroupWise configuration is necessary because there are no sys:\system dependencies for the GroupWise agents.
If you want to back up the GroupWise software, you do not have to include the
sys:\system directory in the backup.
Disadvantages of a vol:\system Directory on Each GroupWise Volume
Installing the agents on a GroupWise volume does have some disadvantages:
GroupWise administrators who are used to the GroupWise agents being installed in
sys:\system might be confused by not finding them there in the clustered GroupWise system.
You must remember where you installed the GroupWise agents when you update the agent
software. Accidently installing a GroupWise Support Pack to the default location of sys:\system would not have the desired results if the original agent software was installed to the vol:\system directory on a GroupWise volume.
novdocx (en) 11 July 2008
Recommendation
Whichever method you choose, be consistent throughout the entire cluster. Either put all the GroupWise agents on the GroupWise volumes with the domains and post offices they service, or put them all in sys:\system directories. If you put them on GroupWise volumes, make sure there are no agent files in sys:\system directories to confuse the issue at a later time.
Even if you choose to install the agents to multiple sys:\system directories, you can still store the agent startup files on the GroupWise volumes. The significant advantage of this approach is that you only have one startup file to modify per agent.
AGENT CLUSTERING WORKSHEET
Under Item 1: Agent Installation Location, mark whether you will install the agent software to a vol:\system directory on a GroupWise volume or to sys:\system on each node in the cluster. If necessary, specify where the agent startup files will be stored.
Under Item 2: Domain Name, transfer the domain name and location from the System Clustering Worksheet to the Agent Clustering Worksheet.
Under Item 5: Post Office Name, transfer the post office name and location from the System Clustering Worksheet to the Agent Clustering Worksheet.
Planning GroupWise in a NetWare Cluster 35
2.8.4 Deciding Whether to Run the Agents in Protected Memory
On a NetWare server, using protected memory allows you to create isolated memory spaces where
TM
NLM contributes to the high availability of the cluster. Using protected memory has the following advantages:
If you have any possibility of the same type of GroupWise agent loading multiple times on any node in the cluster, you must use protected memory so that you can unload agents individually. Check your failover paths (Agent Clustering Worksheet items 3 and 6) for failover combinations where multiple instances of the same type of agent might need to run on the same node.
programs can run without affecting other NLM programs running on the same node. This
When using protected memory, the node can restart a specific memory space if any NLM
program within that memory space abends. This allows for recovery without failing the entire node, which enhances both up time and database integrity.
Using protected memory gives you the ability to unload a single instance of an agent, rather
than all instances.
If you use protected memory, you can run the agents in active/active mode, rather than active/
passive mode.
novdocx (en) 11 July 2008
Protected memory does result in higher memory utilization (about 5% to 10%) and a slight performance penalty. Make sure your nodes have sufficient memory to handle the number of memory spaces that might reside on them. Keep in mind that if you load the MTA and the POA in different memory spaces, the agent engine (gwenn5.nlm) will load twice on the node. Remember to provide memory for any GroupWise volumes that could fail over to a node, in addition to that node’s regular processing load.
IMPORTANT: For optimum stability, we strongly recommend that you run the agents in protected memory, with one agent per memory space.
AGENT CLUSTERING WORKSHEET
Under Item 8: Load Agents in Protected Memory?, mark whether or not you need to run the GroupWise agents in protected memory.
If you will use protected memory, provide one or two unique protected memory space names. If you will create the domain and post office on the same GroupWise volume, the MTA and POA can use the same memory space, although this is not recommended. If you will create the domain and post office on different GroupWise volumes, the MTA and POA must use different memory spaces.
If you will use protected memory, a user name and password for the POA to use to access its post office volume might be required, depending on the version of NetWare you are using.
Provide a user name and password if you are using the following versions of NetWare:
NetWare 5.1 Support Pack 2 or earlier
Initial release of NetWare 6
A user name and password are no longer needed on the following later versions of NetWare.
NetWare 5.1 Support Pack 3 or later
NetWare 6 Support Pack 1 or later
36 GroupWise 7 Interoperability Guide
2.8.5 Planning the NetWare Agent Installation
Aside from the cluster-specific issues discussed in the preceding sections, the considerations involved in planning to install the GroupWise NetWare agents are the same in a clustering environment as for any other environment. Review “Planning the GroupWise Agents”, then print and fill out the “GroupWise Agent Installation Worksheet” in “Installing GroupWise Agents” in the
GroupWise 7 Installation Guide for each location where you will install the NetWare MTA and/or
POA.
Fill out the NetWare Agent Worksheet, taking into account the following cluster-specific issues:
GROUPWISE AGENT INSTALLATION WORKSHEET
Under Item 2: Agents and Locations, mark POA Local to Post Office and MTA Local to Domain. In a clustering environment, a domain or post office and its agent must reside on the same GroupWise volume in order to fail over together.
Under Item 3: Installation Path, take into account your decision based on “Deciding Where to Install
the Agent Software” on page 34.
Under Item 4: Configure GroupWise Agents for Clustering, mark Yes. This will cause the Agent Installation program to customize the agent startup files for clustering.
novdocx (en) 11 July 2008
Under Item 6: Domains and Item 7: Post Offices, refer to the Domain and Post Office Worksheets you filled out in Section 2.3, “Planning a New Clustered Domain,” on page 25 and Section 2.4, “Planning a
New Clustered Post Office,” on page 26, and to the IP Address Worksheet you completed during “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 31.
Under Item 10: Launch GroupWise Agents Now, mark No. You will configure the agents to run in protected mode later.
IMPORTANT: Do not install the NetWare agent software until you are instructed to do so in
Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,” on page 43.
Skip to Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,” on page 43.

2.9 GroupWise Clustering Worksheets

Section 2.9.1, “System Clustering Worksheet,” on page 37
Section 2.9.2, “IP Address Worksheet,” on page 40
Section 2.9.3, “Agent Clustering Worksheet,” on page 41
2.9.1 System Clustering Worksheet
Item Explanation
1) Software Version Updates for Cluster:
List any servers that need to be updated so that all nodes in the cluster are running the same version of NetWare.
For more information, see Section 2.1, “Meeting Software
Version Requirements,” on page 24.
Planning GroupWise in a NetWare Cluster 37
Item Explanation
2) eDirectory Tree for Cluster: Record the eDirectory tree where you created the new Novell
Cluster object when you installed Novell Cluster Services.
For more information, see Section 2.2, “Installing Novell
Cluster Services,” on page 24
novdocx (en) 11 July 2008
3) Cluster Name:
Cluster IP Address:
4) Cluster Context: Record the full context where you created the new NetWare
5) Nodes in Cluster List the nodes that are part of the cluster that you set up for
6) Shared Volumes for GroupWise Administration:
Cluster Enabled?
Yes (highly recommended)
Cluster volume IP addresses
No
GroupWise Administration Snap-ins to ConsoleOne
Record the name of the new NetWare Cluster object that you created for your GroupWise system. Also record the virtual IP address of the cluster that will remain constant regardless of which node is currently active.
For more information, see Section 2.2, “Installing Novell
Cluster Services,” on page 24.
Cluster object.
For more information, see Section 2.2, “Installing Novell
Cluster Services,” on page 24.
your GroupWise system.
For more information, see Section 2.2, “Installing Novell
Cluster Services,” on page 24.
Specify the names (cluster_volume) of the shared volumes where the GroupWise administration snap-ins to ConsoleOne and the GroupWise software distribution directory will reside.
For cluster-enabling, specify the IP addresses of the virtual servers (volume_SERVER.cluster) to which the cluster­enabled volumes are tied.
For more information, see Section 2.6, “Deciding Whether to
Cluster-Enable the Shared Volumes Used by GroupWise,” on page 27.
public directory
Other
GroupWise Software Distribution Directory
\grpwise\software directory
Other
38 GroupWise 7 Interoperability Guide
Item Explanation
novdocx (en) 11 July 2008
7) Shared Volume for Domain:
Cluster Enabled?
Yes (highly recommended)
Cluster volume IP address
No
Post Office on Same Volume as Domain?
Yes
No
8) Shared Volume for Post Office:
Cluster Enabled?
Yes (highly recommended)
Cluster volume IP address
No
9) IP Address Resolution Methods:
eDirectory
hosts file
DNS
SLP (highly recommended)
Specify the name (cluster_volume) of the shared volume where the GroupWise domain will reside.
For cluster-enabling, specify the IP address of the virtual server (volume_SERVER.cluster) to which the cluster-enabled volume is tied.
For more information, see Section 2.4, “Planning a New
Clustered Post Office,” on page 26 and Section 2.6, “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise,” on page 27.
Specify the name (cluster_volume) of the shared volume where the GroupWise post office will reside.
For cluster-enabling, specify the IP address of the virtual server (volume_SERVER.cluster) to which the cluster-enabled volume is tied.
For more information, see Section 2.4, “Planning a New
Clustered Post Office,” on page 26 and Section 2.6, “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise,” on page 27.
Mark the short name address resolution methods you want to implement to ensure that the UNC paths stored in ConsoleOne can be successfully resolved into physical network addresses.
For more information, see Section 2.7, “Ensuring Successful
Name Resolution for GroupWise Volumes,” on page 29
10) Domain Name:
Domain Database Location:
11) Post Office Name:
Post Office Database Location:
Specify a unique name for the domain. Specify the directory on the GroupWise volume where you want to create the new domain.
For more information, see Section 2.3, “Planning a New
Clustered Domain,” on page 25.
Specify a unique name for the post office. Specify the directory on the GroupWise volume where you want to create the post office.
For more information, see Section 2.4, “Planning a New
Clustered Post Office,” on page 26.
Planning GroupWise in a NetWare Cluster 39
Item Explanation
novdocx (en) 11 July 2008
12) Document Storage Area Location:
If you need a library for a clustered post office, mark where you want to create its document storage area and provide a
At the post office
Outside the post office
Separate post office
directory if necessary.
For more information, see Section 2.5, “Planning a New
Library for a Clustered Post Office,” on page 27.
Document Storage Area Access
POA /user startup switch setting
POA /password startup switch
setting
2.9.2 IP Address Worksheet
“Domain Information” on page 40
“Post Office Information” on page 40
“Internet Agent Information” on page 40
“WebAccess Information” on page 41
Domain Information
Domain
MTA IP Address
MTA MTP Port
MTA HTTP Port
Post Office Information
Post Office
POA IP Address
Internet Agent Information
Internet Agent
GWIA Domain MTA
Internet Agent (GWIA)
GWIA IP Address
(same) N/A N/A N/A
POA C/S Port
MTA MTP Port
POA MTP Port
MTA Live Remote Port
POA HTTP Port
MTA HTTP Port
GWIA HTTP Port
N/A
40 GroupWise 7 Interoperability Guide
WebAccess Information
novdocx (en) 11 July 2008
WebAccess Agent
WebAccess IP Address
MTA MTP Port
MTA HTTP Port
WebAccess Domain MTA
WebAccess
(same) N/A N/A Agent (GWINTER)
2.9.3 Agent Clustering Worksheet
Item Explanation
1) agent installation location:
vol:\system on the GroupWise
volume
sys:\system on each node
Consolidate multiple startup files on GroupWise volume?
2) Domain Name:
Domain Location:
Mark the location where you will install the agent software.
If necessary, specify the location where you will consolidate multiple agent startup files on a GroupWise volume.
For more information, see “Deciding Where to Install the
Agent Software” on page 34.
Transfer this information from the System Clustering Worksheet (item 10).
WebAccess Agent Port
WebAccess HTTP Port
N/A N/A
3) Domain Failover Path: List other nodes in the cluster where the GroupWise
domain and its MTA could fail over.
For more information, see “Determining Appropriate
Failover Paths for the Agents” on page 33.
4) MTA Network Information:
Gather the MTA network address information from the
“IP Address Worksheet” on page 40.
MTA IP address
MTA message transfer port
MTA HTTP port
5) Post Office Name:
Post Office Location:
6) Post Office Failover Path: List other nodes in the cluster where the GroupWise post
For more information, see “Planning Secondary IP
Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 31.
Transfer this information from the System Clustering Worksheet (item 11).
office and its POA could fail over.
For more information, see “Determining Appropriate
Failover Paths for the Agents” on page 33.
Planning GroupWise in a NetWare Cluster 41
Item Explanation
novdocx (en) 11 July 2008
7) POA Network Information:
POA IP address
POA client/server port
POA message transfer port
POA HTTP port
8) Load Agents in Protected Memory?
No
Yes
MTA protected address space POA protected address space POA /user startup switch setting POA /password startup switch setting
Gather the POA network address information from the
“IP Address Worksheet” on page 40.
For more information, see “Planning Secondary IP
Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 31.
Mark whether you need to run the agents in protected memory. If so, specify a unique address space for each agent. For the POA, specify a user name and password if required by your version of NetWare.
For more information, see “Deciding Whether to Run the
Agents in Protected Memory” on page 36.
42 GroupWise 7 Interoperability Guide
3
Setting Up a Domain and Post
novdocx (en) 11 July 2008
Office in a NetWare Cluster
You should have already reviewed “Planning GroupWise in a NetWare Cluster” on page 23 and filled out the “System Clustering Worksheet” on page 37, the “IP Address Worksheet” on page 40, and the “Agent Clustering Worksheet” on page 41. You are now ready to complete the following tasks to set up GroupWise
Section 3.1, “Preparing the Cluster for GroupWise,” on page 43
Section 3.2, “Setting Up a New GroupWise System in a Cluster,” on page 46
Section 3.3, “Creating a New Secondary Domain in a Cluster,” on page 48
Section 3.4, “Creating a New Post Office in a Cluster,” on page 49
Section 3.5, “Installing and Configuring the MTA and the POA in a Cluster,” on page 50
Section 3.6, “Testing Your Clustered GroupWise System,” on page 59
Section 3.7, “Managing Your Clustered GroupWise System,” on page 60
Section 3.8, “What’s Next,” on page 64
Section 3.9, “Clustering Quick Checklists,” on page 65

3.1 Preparing the Cluster for GroupWise

®
in a clustering environment:
3
After you have installed Novell® Cluster ServicesTM, as described in Novell Cluster Services Overview and Installation, complete the following tasks to prepare the cluster for your GroupWise
system:
Section 3.1.1, “Ensuring Required Software Versions,” on page 43
Section 3.1.2, “Cluster-Enabling Shared Volumes for Use with GroupWise,” on page 43
Section 3.1.3, “Configuring Short Name Resolution,” on page 44
3.1.1 Ensuring Required Software Versions
Double-check each node in the cluster to make sure it meets the requirements described in
Section 2.1, “Meeting Software Version Requirements,” on page 24.
3.1.2 Cluster-Enabling Shared Volumes for Use with GroupWise
To cluster-enable a shared volume for use with GroupWise:
1 Select a System Clustering Worksheet item (6, 7, or 8) where you marked Yes under Cluster
Enabled?.
2 Complete the steps in the cluster-enabling section of the cluster documentation for your version
of NetWare
on NetWare,” on page 21.
®
, as listed in Chapter 1, “Introduction to GroupWise 7 and Novell Cluster Services

Setting Up a Domain and Post Office in a NetWare Cluster

43
The System Clustering Worksheet provides the volume to cluster-enable for use the GroupWise, the cluster-enabled volume IP address, and the failover path for the GroupWise volume.
For a review of the new Novell eDirectoryTM objects that are created when you cluster-enable a shared volume, see Section 2.6, “Deciding Whether to Cluster-Enable the Shared Volumes
Used by GroupWise,” on page 27.
®
If you have installed the latest version of ConsoleOne
and the Novell Cluster Services snap­in, you can rename the cluster-related objects in case your DNS name server cannot resolve object names that include the underscore (_) character.
3 Repeat Step 1 and Step 2 above for the other shared volumes on your System Clustering
Worksheet that need to be cluster-enabled.
4 Continue with Configuring Short Name Resolution.
3.1.3 Configuring Short Name Resolution
To ensure that GroupWise volumes are always locatable, configure the short name resolution methods that you want to rely on for GroupWise (System Clustering Worksheet item 9):
novdocx (en) 11 July 2008
“eDirectory” on page 44
“Hosts Files” on page 45
“DNS” on page 45
“SLP” on page 46
After configuring your selected short name resolution methods, continue with the task you need to perform:
“eDirectory” on page 44
“Hosts Files” on page 45
“DNS” on page 45
“SLP” on page 46
eDirectory
Most commonly, you will use eDirectory to resolve the UNC path of a volume into its network address. For example, on the workstation where you run ConsoleOne, you need to map a drive to the location of a domain directory so that ConsoleOne can access the domain database. You could use a map command as shown in the example below:
Syntax:
map drive: = .cluster_volume.context
Example:
map m: = .GWCLUSTER_GWVOL1.GWServers
When specifying the map commands, use System Clustering Worksheet item 3 for cluster. Use
System Clustering Worksheet item 7 or 8 for each volume where a domain or post office resides. Use System Clustering Worksheet item 4 for context.
44 GroupWise 7 Interoperability Guide
Hosts Files
Because each GroupWise volume where you plan to create a domain or post office has been associated with a virtual server, you should add lines for the new virtual servers to one or more of the following files as needed:
NetWare:
sys:\etc\hosts
(on all nodes in the cluster; recommended)
Windows 2000/2003:
\winnt\system32\drivers\etc\hosts
(on the administrator’s workstation only; optional)
The lines you add to a hosts file could look similar to the following example:
Syntax:
IP_address cluster_volume_SERVER.context cluster_volume_SERVER
Remember that cluster_volume_SERVER represents the name of the virtual server created when you cluster-enabled the volume.
novdocx (en) 11 July 2008
Example:
172.16.5.81 gwcluster_gwvol1_SERVER.gwcluster.com gwcluster_gwvol1_SERVER
When specifying the lines in the hosts files, use System Clustering Worksheet item 7 or 8 for each IP_address and volume where a domain or post office resides. Use System Clustering Worksheet
item 3 for cluster. Use System Clustering Worksheet item 4 for context.
DNS
Because each GroupWise volume where you plan to create a domain or post office has been associated with a virtual server, you should add all your new virtual servers to DNS. Then you could use a map command as shown in the example below (all on one line, of course):
Syntax:
map drive: = \\volume_SERVER.cluster.com\volume
Remember that volume_SERVER represents the name of the Volume Resource object created when you cluster-enabled the volume. A cluster-enabled volume can function like a server, as these commands illustrate.
Example:
map m: = \\gwvol1_SERVER.gwcluster.com\gwvol1
Or, if the ConsoleOne workstation is in the same DNS domain as the GroupWise volume:
Syntax:
map drive: = \\volume_SERVER\volume
Setting Up a Domain and Post Office in a NetWare Cluster 45
Example
map m: = \\gwvol1_SERVER\gwvol1
When specifying the map commands you will need, use System Clustering Worksheet item 7 or 8 for each volume where a domain or post office resides. Use System Clustering Worksheet item 3 for cluster.
SLP
On NetWare 6.x, Novell Cluster Services automatically propagates virtual server information into SLP and provides the most reliable name resolution.
On NetWare 5.1, Novell Cluster Services does not propagate virtual server information into SLP by default. If you want to use SLP for name resolution on NetWare 5.1, you must download the (unsupported) CVSBIND utility from the Technical Information Document NWCS Bindery Tool
(http://www.novell.com/support/ search.do?cmd=displayKC&docType=kc&externalId=10062624&sliceId=&dialogID=9016836&st ateId). Install CVSBIND according to the instructions included with the download, then determine
the server-specific commands you will need to use with CVSBIND.
novdocx (en) 11 July 2008
Syntax:
cvsbind add cluster_volume_SERVER ip_address cvsbind del cluster_volume_SERVER ip_address
Remember that cluster_volume_SERVER represents the name of the virtual server created when you cluster-enabled the volume.
Example:
cvsbind add gwcluster_gwvol1_SERVER 172.16.5.81 cvsbind del gwcluster_gwvol1_SERVER 172.16.5.81
Later, in “Modifying the Volume Resource Load Script for the Agents” on page 53 and “Modifying
the Volume Resource Unload Script for the Agents” on page 54, you need to add the cvsbind
commands to the load and unload scripts for GroupWise volume resources.

3.2 Setting Up a New GroupWise System in a Cluster

The GroupWise Installation Advisor walks you through setting up the primary domain and an initial post office in the primary domain. You might be creating your primary domain and initial post office on the same GroupWise volume or on two different volumes. After you have created the primary domain and initial post office and installed the GroupWise agents, you can create additional secondary domains and post offices as needed.
To set up the primary domain and initial post office for a new GroupWise system in a clustering environment:
1 If necessary, map a drive to each GroupWise administration volume (System Clustering
Worksh e e t item 6).
46 GroupWise 7 Interoperability Guide
2 Map a drive to the GroupWise volume for the domain (System Clustering Worksheet item 7)
and, if needed, to the GroupWise volume for the post office (System Clustering Worksheet item
8), where the primary domain and the initial post office for your new GroupWise system will
be created.
The GroupWise volume name will be cluster_volume. For assistance with mapping a drive to a cluster-enabled volume, see “Configuring Short Name Resolution” on page 44.
3 Manually create the domain directory (System Clustering Worksheet item 10) and the post
office directory (System Clustering Worksheet item 12).
This step is not required, but in a clustered environment, the following step is easier if the domain directory already exists.
4 Run the GroupWise Installation Advisor to set up your initial GroupWise system, following the
steps provided in “NetWare and Windows: Setting Up a Basic GroupWise System” in Installing a Basic GroupWise System” in the GroupWise 7 Installation Guide. Keep in mind the following cluster-specific details:
When you specify the ConsoleOne directory and the software distribution directory, be
sure to browse to each location through the GroupWise volume accessed in Step 1 above.
When you specify the domain directory and post office directory, be sure to browse
through the GroupWise volume accessed in Step 2 to select the directory created in Step 3 above.
For the post office link type, select TCP/IP Link.
When providing the MTA and POA network address information, use the Agent
Clustering Worksheet that you filled out in Section 2.8, “Deciding How to Install and
Configure the Agents in a Cluster,” on page 31. The information you provide is used to
configure the MTA and POA objects in the domain and post office even though you have not yet installed the agent software.
Do not create users in the post office at this time.
In the Summary dialog box, the domain directory and post office directory that you
browsed to should display as UNC paths using the virtual server name with the GroupWise volume.
novdocx (en) 11 July 2008
5 When you have finished creating the primary domain and the initial post office, continue with
installing the GroupWise Agents, starting with Step 4 on page 51 in Section 3.5, “Installing and
Configuring the MTA and the POA in a Cluster,” on page 50.
Setting Up a Domain and Post Office in a NetWare Cluster 47

3.3 Creating a New Secondary Domain in a Cluster

After you have set up the primary domain and initial post office, as described in Section 3.2,
“Setting Up a New GroupWise System in a Cluster,” on page 46, you can create additional
secondary domains as needed.
To create a new secondary domain in a clustering environment:
1 Map a drive to the GroupWise volume for the domain (System Clustering Worksheet item 7)
where the new secondary domain will be created.
The GroupWise volume name will be cluster_volume. For assistance with mapping a drive to a cluster-enabled volume, see “Configuring Short Name Resolution” on page 44.
2 Manually create the domain directory (System Clustering Worksheet item 10).
This step is not required, but in a clustered environment, Step 5 is easier if the domain directory already exists.
3 If you selected vol:\system on GroupWise volume as the agent installation location (under
Agent Clustering Worksheet item 1), create the vol:\system directory on the GroupWise
volume accessed in Step 1.
novdocx (en) 11 July 2008
or
If you selected sys:\system on each node, decide which node you will install the agents to first.
4 In ConsoleOne, connect to the primary domain in your GroupWise system, as described in
Connecting to a Domain” in “Domains” in the GroupWise 7 Administration Guide.
5 Create the new domain, following the steps provided in “Creating the New Domain” in
Domains” in the GroupWise 7 Administration Guide. Keep in mind the following cluster- specific details:
Use the Domain Worksheet you filled out in Section 2.3, “Planning a New Clustered
Domain,” on page 25 to fill in the fields in the Create GroupWise Domain dialog box.
In the Domain Database Location field, be sure to browse through the drive you mapped
in Step 1 to the domain directory you created in Step 2 above.
In the Link to Domain field, link the new domain to the primary domain of your
GroupWise system.
The Configure Link option is selected by default. Select TCP/IP Link to the Other
Domain. Refer to the Agent Clustering Worksheet that you filled out in “Planning
Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 31 for the secondary IP address and cluster-unique port numbers that you need to
specify in order to configure the link.
6 Use the Link Configuration tool to change the links from the new domain to all other domains
in the cluster to direct TCP/IP links, following the steps provided in “Changing the Link
Protocol between Domains to TCP/IP” in “Message Transfer Agent” in the GroupWise 7
Administration Guide.
Although a complete mesh link configuration is the most efficient, it might not be feasible in all situations. Set up as many direct TCP/IP links as possible for best MTA performance in the cluster.
7 Make sure you are still connected to the primary domain.
48 GroupWise 7 Interoperability Guide
8 Rebuild the domain database for the new domain, following the steps provided in “Rebuilding
Domain or Post Office Databases” in “Databases” in the GroupWise 7 Administration Guide.
Be sure to browse to the database location (under System Clustering Worksheet item 10) through the virtual server that was created when you cluster-enabled the GroupWise volume.
The database rebuild is necessary in order to transfer the MTA configuration information and the domain link information into the secondary domain database, because the MTA for the new domain is not yet running.
9 Continue with Creating a New Post Office in a Cluster.

3.4 Creating a New Post Office in a Cluster

You can create a new post office on the same GroupWise volume where its domain resides or on a separate GroupWise volume. If the post office and its domain are on the same GroupWise volume, they fail over together. If they are on separate GroupWise volumes, they fail over separately.
To create a new post office in a clustering environment:
1 If you marked Yes for Post Office on Same Volume as Domain? (under System Clustering
Worksh e e t item 7), map a drive to the GroupWise volume for the domain (System Clustering Worksh e e t item 7).
novdocx (en) 11 July 2008
or
Map a drive to the GroupWise volume for the post office (System Clustering Worksheet item
8).
The GroupWise volume name will be cluster_volume. For assistance with mapping a drive to a cluster-enabled volume, see “Configuring Short Name Resolution” on page 44.
2 Manually create the post office directory (System Clustering Worksheet item 12).
This step is not required, but in a clustered environment, Step 4 is easier if the post office directory already exists.
3 In ConsoleOne, connect to the GroupWise domain where you want to create the new post
office, as described in “Connecting to a Domain” in “Domains” in the GroupWise 7
Administration Guide.
4 Create the new post office, following the steps provided in “Creating the New Post Office” in
Post Offices” in the GroupWise 7 Administration Guide. Keep in mind the following cluster- specific details:
Use the Post Office Worksheet you filled out in Section 2.4, “Planning a New Clustered
Post Office,” on page 26 to fill in the fields in the Create GroupWise Post Office dialog
box.
In the Post Office Database Location field, be sure to browse through the drive you
mapped in Step 1 to the post office directory you created in Step 2 above.
If you want to create a library at the post office (System Clustering Worksheet item 14),
select Create Library.
Setting Up a Domain and Post Office in a NetWare Cluster 49
This option creates the document storage area for the library under the post office directory and is not recommended for large libraries.
The Configure Link option is selected by default. Select TCP/IP Link from Domain to New
Post Office. Refer to the Agent Clustering Worksheet that you filled in during “Planning
Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 31 for the secondary IP address and cluster-unique port numbers that you need to
specify in order to configure the link.
5 Right-click the new Post Office object, then click Properties.
6 Click GroupWise > Post Office Settings; in the Access Mode field, select Client/Server Only.
7 Right-click the new POA object, then click Properties.
On the POA Agent Settings and Scheduled Events pages, you might want to specify unique times for the following POA activities to prevent multiple POAs from performing the same activities on the same node at the same time during a failover situation:
Start User Upkeep
Generate Address Book for Remote
Enable QuickFinder Indexing
Mailbox/Library Maintenance Event
For more information about these repetitive POA activities, see “Performing Nightly User
Upkeep”, “Regulating Indexing”, and “Scheduling Database Maintenance” in “Post Office Agent” in the GroupWise 7 Administration Guide.
8 Make sure you are still connected to the domain that owns the new post office.
novdocx (en) 11 July 2008
9 Rebuild the post office database for the new post office, following the steps provided in
Rebuilding Domain or Post Office Databases” in “Databases” in the GroupWise 7
Administration Guide. Be sure to browse to the database location (under System Clustering
Worksh e e t item 11 ) through the virtual server that was created when you cluster-enabled the
GroupWise volume.
The database rebuild is necessary in order to transfer the POA configuration information and the post office link information into the post office database, because the POA for the new post office is not yet running.
10 If you want to create a library with its document storage area outside the post office directory,
(System Clustering Worksheet item 14), follow the steps in “Setting Up a Basic Library” or Setting Up a Full-Service Library” in “Libraries and Documents” in the GroupWise 7
Administration Guide, after you have completely finished setting up the clustered post office.
11 Continue with Installing and Configuring the MTA and the POA in a Cluster.

3.5 Installing and Configuring the MTA and the POA in a Cluster

After you have created a new domain and/or post office, you are ready to install and configure the GroupWise agents. Complete all the tasks below if you are setting up a new GroupWise system or if you have created a new GroupWise volume where you want to install the agent software:
Section 3.5.1, “Installing the Agent Software in a Cluster,” on page 51
Section 3.5.2, “Editing Clustered Agent Startup Files,” on page 52
50 GroupWise 7 Interoperability Guide
Section 3.5.3, “Configuring the GroupWise Volume Resource to Load and Unload the Agents,”
on page 53
Section 3.5.4, “Setting Up New Instances of the Agents without Installing the Agent Software,”
on page 57
Under some circumstances, the agent software has already been installed and you simply need to create a new startup file specific to the new domain or post office. For example:
You have created a new domain and/or post office on a GroupWise volume where the agent
software is already installed in the vol:\system directory of the GroupWise volume.
In your GroupWise system, the agent software is already installed to multiple sys:\system
directories.
In these circumstances, follow the instructions in “Setting Up New Instances of the Agents without
Installing the Agent Software” on page 57 instead of completing the tasks above.
3.5.1 Installing the Agent Software in a Cluster
To install the MTA and the POA:
novdocx (en) 11 July 2008
1 Map a drive to the GroupWise volume for the domain (Agent Clustering Worksheet item 2) or
the post office (Agent Clustering Worksheet item 5).
The GroupWise volume name will be cluster_volume. For assistance with mapping a drive to a cluster-enabled volume, see “Configuring Short Name Resolution” on page 44.
2 If you selected vol:\system on GroupWise volume as the agent installation location (under
Agent Clustering Worksheet item 1), create the vol:\system directory on the GroupWise
volume accessed in Step 1.
or
If you selected sys:\system on each node, decide which node you will install the agents to first.
3 Start the Agent Installation program, following the steps provided in “Installing the NetWare
Agent Software” in “Installing GroupWise Agents” in the GroupWise 7 Installation Guide.
4 Install the NetWare agents, keeping in mind the following cluster-specific details:
Use the NetWare Agent Clustering Worksheet that you filled out in “Planning the
NetWare Agent Installation” on page 37 to fill in the fields during the agent installation
process.
In the Installation Path dialog box, be sure to browse through the drive you mapped in
Step 1 to the location you chose in Step 2 above. Also select Configure GroupWise Agents
for Clustering.
In the Domains / Post Offices dialog box, click Add for each domain and post office that
the agents will service. In the Path to Database field, be sure to browse through the drive you mapped in Step 1 above to the domain directory or the post office directory. In the HTTP Port field, specify the cluster-unique HTTP port planned for each agent (under
Agent Clustering Worksheet items 4 and 7).
In the Installation Complete dialog box, do not select Launch GroupWise Agents Now.
You will configure the agents to launch in protected mode later.
Setting Up a Domain and Post Office in a NetWare Cluster 51
5 If you need to install the agents to sys:\system on multiple nodes in the cluster:
5a Repeat Step 4, mapping new drives as needed.
5b If you marked Yes for Consolidate Multiple Startup Files on GroupWise Volume? (under
Agent Clustering Worksheet item 1), copy one complete set of agent startup files and the
grpwise.ncf file to the planned location, then delete all agent startup files, as well as the grpwise.ncf file, from the sys:\system directories to avoid future confusion.
The grpwise.ncf file includes a load command for each instance of each agent. You will use this information later when you create the load and unload scripts for the volume resources.
6 Continue with Editing Clustered Agent Startup Files.
3.5.2 Editing Clustered Agent Startup Files
By default, the Agent Installation program creates agent startup files in the agent installation directory. Each MTA startup file is named after the domain it services, with a .mta extension. Each POA startup file is named after the post office it services, with a .poa extension.
Because you selected Configure GroupWise Agents for Clustering during installation, the Agent Installation program set the MTA /home startup switch and the POA /home startup switch using the format:
novdocx (en) 11 July 2008
volume:\directory
so that the startup files are valid no matter which node the agents are currently running on.
The Agent Installation program also adds a /cluster startup switch to POA startup files to ensure that GroupWise clients detect the clustering environment and try more persistently to reconnect in a failover, failback, or migration situation.
One additional manual modification of POA startup files is required for robust functionality in a clustering environment. Uncomment the /ip startup switch and provide the secondary IP address of the GroupWise volume where the post office is located (Agent Clustering Worksheet item 7). This information is available to the POA in its eDirectory object properties. However, in some failover situations, reconnection to the MTA is improved when the information is immediately available to the POA in its startup file.
If you are running the POA in protected memory and your version of NetWare requires it, add the /
user and /password startup switches (under Agent Clustering Worksheet item 8) in order to provide a
user name and password that the POA can use to access its post office volume.
If the POA needs to access a remote document storage area, add the /user and /password startup switches (under System Clustering Worksheet item 12) in order to provide a user name and password that the POA can use to access the volume where the document storage area resides. As an alternative to startup switches, you can assign the POA object all rights except Supervisor and Access control, as long as the remote document storage area is located in the same tree with the post office.
If you have connection problems between the MTA and the POA, you can use the /user and /
password startup switches in the MTA startup file as well.
52 GroupWise 7 Interoperability Guide
3.5.3 Configuring the GroupWise Volume Resource to Load and Unload the Agents
novdocx (en) 11 July 2008
The properties of the Volume Resource object define how the GroupWise volume functions within
TM
the cluster, how NLM
programs are loaded and unloaded, and how failover and failback situations are handled. At this point, you might have one volume resource with a domain and post office on it, or you might have two volume resources, one for the domain and one for the post office. Complete the following tasks for each volume resource:
“Modifying the Volume Resource Load Script for the Agents” on page 53
“Modifying the Volume Resource Unload Script for the Agents” on page 54
“Setting the Failover Path and Policies for the Agents” on page 56
Modifying the Volume Resource Load Script for the Agents
The volume resource load script executes whenever the GroupWise volume comes online.
To set up the load script:
1 In ConsoleOne, browse to and select the Cluster object.
If necessary, click View > Conso le View to display its contents.
2 Right-click the Volume Resource object (volume_SERVER), then click Properties > Load to
display the default volume resource load script for the GroupWise volume.
3 Make the following changes to the default load script:
Remove the trustmig command. It is not necessary to migrate trustees for a GroupWise
volume. Removing this line helps the load script to execute faster.
On NetWare 5.1, if you selected SLP as a short name resolution method, add the
cvsbind add command for the GroupWise volume to the load script.
cvsbind add cluster_volume_SERVER IP_address
If you selected vol:\system on GroupWise volume as the agent installation location
(Agent Clustering Worksheet item 1), add a search add command to add the new vol:\system directory to the server search path.
search add volume:\system
If you selected sys:\system on each node as the installation location (Agent
Clustering Worksheet item 1) but you are storing the agent startup files on the GroupWise
volume, add that location to the server search path.
If you marked No under Load Agents in Protected Memory? (Agent Clustering Worksheet
item 8), add the following abend recovery options:
set auto restart after abend = 2 set auto restart after abend delay time = 0 set auto restart down timeout = 60 set developer option = off
These settings provide the best possible handling of GroupWise databases in the event that an abend should occur within the cluster when the agents are not running in protected memory.
Setting Up a Domain and Post Office in a NetWare Cluster 53
Transfer the agent load commands from the grpwise.ncf file into the load script.
Use Ctrl+C to copy and Ctrl+V to paste text into the load script page. Then delete or rename the grpwise.ncf file to avoid future confusion.
load volume:\system\agent.nlm @startup_file
If you marked Yes under Load Agents in Protected Memory? (Agent Clustering
Worksheet item 8), add the address space parameter to the agent load commands to
specify the protected address space for each agent. Add a protection restart command for each address space name.
load address space=addr_space_name
volume:\system\agent.nlm @startup_file
protection restart name
The result would look similar to the following example:
novdocx (en) 11 July 2008
NOTE: The set commands are needed in the load script only when the agents are not running in protected memory. The address space parameters are needed in the load commands only when the agents are running in protected memory.
4 Click Apply to save the load script.
5 If necessary, click OK to confirm that you must offline and then online the volume resource in
order for the changes to take effect.
6 Continue with Modifying the Volume Resource Unload Script for the Agents.
Modifying the Volume Resource Unload Script for the Agents
The volume resource unload script executes whenever the GroupWise volume goes offline. Programs should be unloaded in the reverse order of how they were loaded. This ensures that supporting programs are not unloaded before programs that rely on them in order to function properly.
54 GroupWise 7 Interoperability Guide
To set up the unload script:
1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER),
click Unload to display the default volume resource unload script.
2 Make the following changes to the default unload script:
If you marked Yes under Load Agents in Protected Memory? (Agent Clustering
Worksheet item 8), add an unload address space command for each address
space. Add an unload kill address space command to ensure that the address space is completely cleaned up.
unload address space=addr_space_name unload kill address space=addr_space_name
If your system seems to be trying to kill the address space before the GroupWise agents have been completely unloaded, resulting in the agents hanging in the unloading state, load the delay.nlm program and set a delay of several seconds before issuing the unload kill address space command to allow the GroupWise agents adequate time to unload completely. The length of the delay varies from system to system; ten seconds is a good starting place.
novdocx (en) 11 July 2008
unload address space=addr_space_name load delay.nlm delay 10 unload kill address space=addr_space_name
If you marked No under Load Agents in Protected Memory? (Agent Clustering Worksheet
item 8), create an unload command parallel to each load command that you placed in
the load script.
unload agent.nlm
On NetWare 5.1, if you selected SLP as a short name resolution method, add the
cvsbind del command for the GroupWise volume to the unload script.
cvsbind del cluster_volume_SERVER IP_address
Remove the trustmig command just like you did in the load script.
The result would look similar to the following example:
Setting Up a Domain and Post Office in a NetWare Cluster 55
3 Click Apply to save the unload script.
4 If necessary, click OK to confirm that you must offline and then online the volume resource in
order for the changes to take effect.
5 Continue with Setting the Failover Path and Policies for the Agents.
Setting the Failover Path and Policies for the Agents
To modify the failover path and policies for a GroupWise volume resource:
1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER),
click Nodes to display the default failover path for the GroupWise volume resource.
novdocx (en) 11 July 2008
2 Arrange the nodes in the cluster into the desired failover path for the domain or post office
volume (under Agent Clustering Worksheet items 3 or 6).
3 Click Apply to save the failover path.
4 Click Policies to display the default start, failover, and failback policies.
The default policy settings are often appropriate. By default, a volume resource:
Fails over automatically if the node it is running on fails
Starts automatically on the next node in its failover path
Continues running at its failover location, even after its most preferred node is again
available
56 GroupWise 7 Interoperability Guide
If you are considering changing these defaults, see the section about failover and failback modes in the cluster documentation for your version of NetWare, as listed in Chapter 1,
“Introduction to GroupWise 7 and Novell Cluster Services on NetWare,” on page 21.
5 Click OK when you are finished editing the GroupWise volume resource properties.
6 Skip to Section 3.6, “Testing Your Clustered GroupWise System,” on page 59.
3.5.4 Setting Up New Instances of the Agents without Installing the Agent Software
There are two steps to setting up new instances of the agents without installing the agent software:
“Creating New Startup Files” on page 57
“Modifying Existing Load and Unload Scripts” on page 57
Creating New Startup Files
Each MTA startup file is named after the domain it services, with a .mta extension. Each POA startup file is named after the post office it services, with a .poa extension. If the existing agent software is located in the vol:\system directory of a GroupWise volume, the startup files are there as well. If the existing agent software is located in multiple sys:\system directories, the startup files might be located there as well, or they might be in a directory on a GroupWise volume.
novdocx (en) 11 July 2008
To create a new startup file without installing the agent software:
1 Make a copy of an existing startup file and name it after the domain or post office that will be
serviced by the agent.
2 Edit the setting of the /home startup switch to point to the location of the new domain directory
or post office directory. Be careful to maintain the syntax of the original line.
3 Scroll down through the startup file looking for other active (not commented out) startup
switches, then modify them as needed for the new agent.
For example, you might find that the /httpport switch is active and needs to be changed to a cluster-unique port number for the new agent.
4 Save the new startup file.
5 Continue with Modifying Existing Load and Unload Scripts.
Modifying Existing Load and Unload Scripts
The agent startup file names are part of the load commands found in GroupWise volume resource load scrips.
If you created the new domain and/or post office on a new GroupWise volume, skip back to
“Configuring the GroupWise Volume Resource to Load and Unload the Agents” on page 53 for
instructions to create new load and unload scripts.
If you created the new domain and/or post office on an existing GroupWise volume, most of the configuration of the volume resource has already been done. You just need to add new load and unload commands to the existing scripts. Continue with the steps below:
To modify existing load and unload scripts:
1 In ConsoleOne, browse to and select the Cluster object.
Setting Up a Domain and Post Office in a NetWare Cluster 57
If necessary, click View > Conso le View to display its contents.
2 Right-click the Volume Resource object (volume_SERVER), then click Properties > Load to
display the volume resource load script for the GroupWise volume.
3 Following the pattern of the existing load commands, add load commands for the new
instances of the agents you are setting up. Use Ctrl+C to copy and Ctrl+V to paste lines in the load script page.
The results would be similar to the following example:
novdocx (en) 11 July 2008
4 Click Apply to save the modified load script.
5 Click Unload
6 Add corresponding unload commands for the new instances of the agents.
7 Click Apply to save the modified unload script.
58 GroupWise 7 Interoperability Guide
You might want to review other properties of the Volume Resource object, such as the failover path on the Nodes page and the failover/failback/migration procedures on the Policies page, in light of the fact that an additional domain and/or post office now resides on the GroupWise volume.
8 Change other Volu m e Re s o urce properties as needed.
9 Click OK to save the modified properties.
10 In the Cluster State View, take the GroupWise volume offline and then bring it online again to
test the new startup files and the modified load and unload scripts. If you need assistance with these tasks, see Section 3.6, “Testing Your Clustered GroupWise System,” on page 59.

3.6 Testing Your Clustered GroupWise System

After you have configured the GroupWise volume resources, you can test the load and unload scripts by bringing the GroupWise volume online and taking it offline again.
1 In ConsoleOne, select the Cluster object, then click View > Cluster State.
novdocx (en) 11 July 2008
The new GroupWise volume resource shows Offline in the State column.
2 Click the new GroupWise volume resource, then click Online.
The State column for the volume resource now displays Running.
3 Observe the server console where the MTA and/or POA are loading to see that they start and
run correctly.
If you are using protected memory, you can use the protection command at the server console prompt to list all the address spaces on the node and what NLM programs are running in each one.
Setting Up a Domain and Post Office in a NetWare Cluster 59
4 Click the new GroupWise volume resource, then click Offline.
The State column for the volume resource returns to Offline.
5 Observe the server console where the MTA and/or POA are unloading to see that they shut
down correctly.
If you are using protected memory, you can use the protection command again to make sure that the address spaces used by the GroupWise agents are no longer present.
6 Repeat Step 2 whenever you are ready to bring the new GroupWise volume resource online
permanently.
On NetWare 6.x, these actions can also be performed from your Web browser. See “Using
Novell Remote Manager on NetWare 6.x” on page 61.
7 Continue with Managing Your Clustered GroupWise System.

3.7 Managing Your Clustered GroupWise System

After you have set up a basic clustered GroupWise system, you should consider some long-term management issues.
novdocx (en) 11 July 2008
Section 3.7.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 60
Section 3.7.2, “Using Novell Remote Manager on NetWare 6.x,” on page 61
Section 3.7.3, “Knowing What to Expect in MTA and POA Failover Situations,” on page 64
3.7.1 Updating GroupWise Objects with Cluster-Specific Descriptions
After setting up your clustered GroupWise system, while the cluster-specific information is fresh in your mind, you should record that cluster-specific information as part of the GroupWise objects in ConsoleOne so that you can easily refer to it later. Be sure to keep the information recorded in the GroupWise objects up to date if the configuration of your system changes.
“Recording Cluster-Specific Information for a Domain and Its MTA” on page 60
“Recording Cluster-Specific Information for a Post Office and Its POA” on page 61
“Recording Cluster-Specific Information for a Software Distribution Directory” on page 61
Recording Cluster-Specific Information for a Domain and Its MTA
To permanently record important cluster-specific information for the domain:
1 In ConsoleOne, browse to and right-click the Domain object, then click Properties.
2 In the Description field of the domain Identification page, provide a cluster-specific description
of the domain, including the secondary IP address of its cluster-enabled volume and the cluster­unique port numbers used by its MTA.
3 Click OK to save the domain description.
4 Select the Domain object to display its contents.
5 Right-click the MTA object, then click Properties.
6 In the Description field of the MTA Identification page, record the secondary IP address of the
cluster-enabled domain volume and the cluster-unique port numbers used by the MTA.
60 GroupWise 7 Interoperability Guide
This information appears on the MTA console, no matter which node in the cluster it is currently running on.
7 Click OK to save the MTA description.
8 Continue with Recording Cluster-Specific Information for a Post Office and Its POA.
Recording Cluster-Specific Information for a Post Office and Its POA
To permanently record important cluster-specific information for a post office:
1 In ConsoleOne, browse to and right-click the Post Office object, then click Properties.
2 In the Description field of the post office Identification page, provide a cluster-specific
description of the post office, including the secondary IP address of its cluster-enabled volume and the cluster-unique port numbers used by its POA.
3 Click OK to save the post office description.
4 Select the Post Office object to display its contents.
5 Right-click the POA object, then click Properties.
6 In the Description field of the POA Identification page, record the secondary IP address of the
cluster-enabled post office volume and the cluster-unique port numbers used by the POA.
novdocx (en) 11 July 2008
This information appears on the POA console, no matter which node in the cluster it is currently running on.
7 Click OK to save the POA description.
8 If necessary, continue with “Recording Cluster-Specific Information for a Software
Distribution Directory” on page 61.
or
Skip to “Knowing What to Expect in MTA and POA Failover Situations” on page 64.
Recording Cluster-Specific Information for a Software Distribution Directory
To permanently record important cluster-specific information about a software distribution directory located on a cluster-enabled volume:
1 In ConsoleOne, click Tools > System Operations > Software Directory Management.
2 Select the software distribution directory, then click Edit.
3 In the description field, record the secondary IP address of the cluster-enabled volume where
the software distribution directory resides.
4 Click OK, then click Close to save the software distribution directory description.
5 Skip to “Knowing What to Expect in MTA and POA Failover Situations” on page 64.
3.7.2 Using Novell Remote Manager on NetWare 6.x
On NetWare 6.x, you can use Novell Remote Manager to manage many aspects of your GroupWise cluster from your Web browser. For instructions on setting up and accessing this useful network administration utility, see the NetWare 6.x Novell Remote Manager Administration Guide at the
Novell Documentation Web site (http://www.novell.com/documentation). Cluster management
features are automatically added to Novell Remote Manager when you install Novell Cluster Services.
Setting Up a Domain and Post Office in a NetWare Cluster 61
After you have accessed Novell Remote Manager, you might find that many GroupWise cluster management tasks are easier to perform with Novell Remote Manager than with ConsoleOne. The following sections help you configure and manage the cluster using Novell Remote Manager:
“Configuring Your GroupWise Cluster” on page 62
“Managing Your GroupWise Cluster” on page 63
Configuring Your GroupWise Cluster
On the main Novell Remote Manager page:
1 In the left frame, scroll down to the Clustering section, then click Cluster Config.
novdocx (en) 11 July 2008
The Cluster Configuration page displays the cluster name, the nodes in the cluster, and the resources in the cluster. It also enables you to create new GroupWise Volume Resource objects (termed Cluster Volumes in the Novell Remote Manager interface).
2 Click the cluster name to display the Cluster object properties:
Click a linked item to edit the Cluster object properties. Click your browser’s Back button to return to the Cluster Configuration page.
62 GroupWise 7 Interoperability Guide
3 On the Cluster Configuration page, click a server to display the Server object properties:
Click a linked item to edit the Server object properties. Click Back or Delete to perform the specified action.
4 On the Cluster Configuration page, click a GroupWise volume to display the Volume Resource
object properties:
novdocx (en) 11 July 2008
Click a linked item to edit Volume Resource object properties. Click Back or Delete to perform the specified action.
5 On the Cluster Configuration page, click New Cluster Volume to create a new GroupWise
Volume Resource object, then follow the instructions to provide the information needed to create the new Cluster Volume object.
Managing Your GroupWise Cluster
On the main Novell Remote Manager page:
1 In the left frame, scroll down to the Clustering section, then click Cluster Management.
The Cluster Status page displays the nodes and volume resources in the cluster. The master node in the cluster is marked with a yellow ball. Status information is listed for each volume resource. You can set the refresh rate for the status information at the top of the Cluster Status page.
Setting Up a Domain and Post Office in a NetWare Cluster 63
2 Select a page refresh rate, then click Begin Refresh so that the page automatically refreshes at
the selected rate.
3 Click a cluster resource to bring it online, take it offline, or migrate it to another node.
To take the currently running volume resource offline, click Offline. To migrate the volume resource, select a node from the drop-down list, then click Migrate.
4 On the Cluster Resource page, click Event Log to view a list of cluster events.
The event log can help you resolve problems with cluster functioning.
3.7.3 Knowing What to Expect in MTA and POA Failover Situations
novdocx (en) 11 July 2008
In a failover situation, the agents might need to perform some database repair as they start on the new node. The time required depends on the size of the databases involved.
Typically, the POA returns to full functionality faster than the MTA. This benefits GroupWise client users, who can reconnect to their mailboxes very quickly and probably do not notice if messages to users in other post offices are not delivered immediately. The only time a user would need to restart the GroupWise client would be if he or she was actually in the process of sending a message when the POA went down. Notify can continue running even if the connection to the POA becomes unavailable and then it reconnects automatically when the POA is again available.
The MTA typically takes some time reestablishing the links to its post offices, other domains, and gateways, but this situation usually resolves itself in a few minutes without administrator intervention. If it does not, you can manually restart the MTA to speed up the process.
In comparison to failover, migration typically takes longer because the agents methodically terminate their threads and close their databases as part of their normal shutdown procedure. However, as a result, no database repair is required when the agents start up again in their new location.
Continue with What’s Next.

3.8 What’s Next

Now that you have at least one GroupWise domain and post office up and running in a clustering environment, you are ready to proceed with the rest of your GroupWise system setup by:
Adding users to post offices. See “Users” in the GroupWise 7 Administration Guide.
Setting up the GroupWise client software and helping users to get started using it. See “Client
in the GroupWise 7 Administration Guide. Also see the GroupWise 7 Windows Client User
Guide.
Connecting your clustered GroupWise system to the Internet. See Chapter 4, “Implementing
the Internet Agent in a NetWare Cluster,” on page 69.
64 GroupWise 7 Interoperability Guide
Providing access to users’ GroupWise mailboxes from their Web browsers. See Chapter 5,
“Implementing WebAccess in a NetWare Cluster,” on page 89.
Connecting your clustered GroupWise system to other e-mail systems through GroupWise
gateways. See Chapter 6, “Implementing GroupWise Gateways in a Novell Cluster,” on
page 107.
Monitoring the status of your clustered GroupWise system from your Web browser. See
Chapter 7, “Monitoring a GroupWise System in a NetWare Cluster,” on page 109.
Backing up your clustered GroupWise system. See Chapter 8, “Backing Up a GroupWise
System in a NetWare Cluster,” on page 111.

3.9 Clustering Quick Checklists

Section 3.9.1, “GroupWise System Quick Checklist,” on page 65
Section 3.9.2, “Domain Quick Checklist,” on page 66
Section 3.9.3, “Post Office Quick Checklist,” on page 67
3.9.1 GroupWise System Quick Checklist
novdocx (en) 11 July 2008
Plan your new clustered GroupWise system.
See Chapter 2, “Planning GroupWise in a NetWare Cluster,” on page 23.
Cluster-enable the volumes where GroupWise domains and post offices will reside.
See Section 3.1.2, “Cluster-Enabling Shared Volumes for Use with GroupWise,” on page 43.
Make sure that short name resolution works throughout your network.
See Section 3.1.3, “Configuring Short Name Resolution,” on page 44.
Create the primary domain and initial post office in your new clustered GroupWise system.
See Section 3.2, “Setting Up a New GroupWise System in a Cluster,” on page 46.
Set up the agents for the primary domain and the initial post office.
See Section 3.5, “Installing and Configuring the MTA and the POA in a Cluster,” on page 50.
Modify the volume resource load script(s):
Remove the trustmig command
Add the cvsbind add command (NetWare 5.1 only; optional)
Add the search add command (optional)
If you will not run the agents in protected memory, add the set auto restart
commands and the set developer option = off command
Add the agent load command(s)
If you will run the agents in protected memory, add the address space parameter to
the load command(s) and add a corresponding protection restart command for each address space
See “Modifying the Volume Resource Load Script for the Agents” on page 53.
Modify the volume resource unload script(s):
Add the agent or address space unload command(s)
Setting Up a Domain and Post Office in a NetWare Cluster 65
Add the cvsbind del command if you used the cvsbind add command in the load
script (NetWare 5.1 only; optional)
Remove the trustmig command
See “Modifying the Volume Resource Unload Script for the Agents” on page 54.
Set up the volume failover path(s) and policies.
See “Setting the Failover Path and Policies for the Agents” on page 56.
Test your new clustered GroupWise system.
See Section 3.6, “Testing Your Clustered GroupWise System,” on page 59.
Record cluster-specific information in the properties pages of the GroupWise objects that the
information pertains to.
See Section 3.7, “Managing Your Clustered GroupWise System,” on page 60.
3.9.2 Domain Quick Checklist
Plan your new clustered domain.
novdocx (en) 11 July 2008
See Section 2.3, “Planning a New Clustered Domain,” on page 25.
Cluster-enable the volume where the domain will reside.
See Section 3.1.2, “Cluster-Enabling Shared Volumes for Use with GroupWise,” on page 43.
Make sure that short name resolution for the new domain volume works throughout your
network.
See Section 3.1.3, “Configuring Short Name Resolution,” on page 44.
Create the new domain.
See Section 3.3, “Creating a New Secondary Domain in a Cluster,” on page 48.
Set up the MTA for the new domain.
See Section 3.5, “Installing and Configuring the MTA and the POA in a Cluster,” on page 50.
Modify the domain volume resource load script:
Remove the trustmig command
Add the cvsbind add command (NetWare 5.1 only; optional)
Add the search add command (optional)
If you will not run the MTA in protected memory, add the set auto restart
commands and the set developer option = off command
Add the MTA load command
If you will run the MTA in protected memory, add the address space parameter to
the MTA load command and add a corresponding protection restart command for the address space
See “Modifying the Volume Resource Load Script for the Agents” on page 53.
Modify the domain volume resource unload script:
Add the MTA or address space unload command
66 GroupWise 7 Interoperability Guide
Add the cvsbind del command if you used the cvsbind add command in the load
script (NetWare 5.1 only; optional)
Remove the trustmig command
See “Modifying the Volume Resource Unload Script for the Agents” on page 54.
Set up the domain volume failover path and policies.
See “Setting the Failover Path and Policies for the Agents” on page 56.
Test your new clustered domain.
See Section 3.6, “Testing Your Clustered GroupWise System,” on page 59.
Record cluster-specific information in the properties pages of the GroupWise objects that the
information pertains to.
See Section 3.7, “Managing Your Clustered GroupWise System,” on page 60.
3.9.3 Post Office Quick Checklist
Plan your new clustered post office.
novdocx (en) 11 July 2008
See Section 2.4, “Planning a New Clustered Post Office,” on page 26.
Cluster-enable the volume where the post office will reside.
See Section 3.1.2, “Cluster-Enabling Shared Volumes for Use with GroupWise,” on page 43.
Make sure that short name resolution for the new post office volume works throughout your
network.
See Section 3.1.3, “Configuring Short Name Resolution,” on page 44.
Create the new post office.
See Section 3.4, “Creating a New Post Office in a Cluster,” on page 49.
Set up the POA for the new post office.
See Section 3.5, “Installing and Configuring the MTA and the POA in a Cluster,” on page 50.
Add the /ip startup switch to the POA startup file in order to provide the secondary IP address
of the post office volume. If you are running the POA in protected memory, add the /user and /
password startup switches so the POA can access the volume.
See “Editing Clustered Agent Startup Files” on page 52.
Modify the post office volume resource load script:
Remove the trustmig command
Add the cvsbind add command (NetWare 5.1 only; optional)
Add the search add command (optional)
If you will not run the POA in protected memory, add the set auto restart
commands and the set developer option = off command
Add the POA load command
If you will run the POA in protected memory, add the address space parameter to the
POA load command and add a corresponding protection restart command for the address space
See “Modifying the Volume Resource Load Script for the Agents” on page 53.
Setting Up a Domain and Post Office in a NetWare Cluster 67
Modify the post office volume resource unload script:
Add the POA or address space unload command
Add the cvsbind del command if you used the cvsbind add command in the load
script (NetWare 5.1 only; optional)
Remove the trustmig command
See “Modifying the Volume Resource Unload Script for the Agents” on page 54.
Set up the post office volume failover path and policies.
See “Setting the Failover Path and Policies for the Agents” on page 56.
Test your new clustered post office.
See Section 3.6, “Testing Your Clustered GroupWise System,” on page 59.
Record cluster-specific information in the properties pages of the GroupWise objects that the
information pertains to.
See Section 3.7, “Managing Your Clustered GroupWise System,” on page 60.
novdocx (en) 11 July 2008
68 GroupWise 7 Interoperability Guide
4
Implementing the Internet Agent in
novdocx (en) 11 July 2008
a NetWare Cluster
You should already have set up at least a basic GroupWise® system, as described in Chapter 2,
“Planning GroupWise in a NetWare Cluster,” on page 23 and Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,” on page 43. As part of this process, the “System Clustering Worksheet” on page 37 and the “IP Address Worksheet” on page 40 were filled out. If you do not
have access to the filled-out worksheets, print the worksheets now and fill in the clustering and network address information as it currently exists on your system. You need this information as you implement the Internet Agent in a cluster.
Section 4.1, “Planning the Internet Agent in a Cluster,” on page 69
Section 4.2, “Setting Up the Internet Agent in a Cluster,” on page 73
Section 4.3, “Managing the Internet Agent in a Cluster,” on page 83
Section 4.4, “Internet Agent Clustering Worksheet,” on page 84
Section 4.5, “Internet Agent Quick Checklist,” on page 86

4.1 Planning the Internet Agent in a Cluster

A main system configuration difference between a GroupWise system in a clustering environment and a GroupWise system in a regular environment is that you need to create a separate domain to house each GroupWise gateway, including the Internet Agent.
4
The Section 4.4, “Internet Agent Clustering Worksheet,” on page 84 lists all the information you need as you set up the Internet Agent in a clustering environment. You should print the worksheet and fill it out as you complete the tasks listed below:
Section 4.1.1, “Planning a Domain for the Internet Agent,” on page 70
Section 4.1.2, “Deciding Whether to Cluster-Enable the Internet Agent Volume,” on page 70
Section 4.1.3, “Determining an Appropriate Failover Path for the Internet Agent Volume,” on
page 70
Section 4.1.4, “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the
Internet Agent and Its MTA,” on page 71
Section 4.1.5, “Preparing Your Firewall for the Internet Agent,” on page 71
Section 4.1.6, “Deciding Where to Install the Internet Agent and Its MTA,” on page 72
Section 4.1.7, “Deciding Whether to Run the Internet Agent and Its MTA in Protected
Memory,” on page 72
Section 4.1.8, “Planning the MTA Installation,” on page 73
Section 4.1.9, “Planning the Internet Agent Installation,” on page 73

Implementing the Internet Agent in a NetWare Cluster

69
4.1.1 Planning a Domain for the Internet Agent
The considerations involved in planning a domain for the Internet Agent are much the same as planning any other domain. In preparation, review “Planning a New Domain”, then print and fill out the “Domain Worksheet” in “Domains” in the GroupWise 7 Administration Guide.
Keep in mind the following cluster-specific details:
When you specify the location for the domain directory on the Domain Worksheet, include the
shared volume where you want the domain directory to reside.
Do not concern yourself with the GroupWise agent information on the Domain Worksheet. You
can stop with item 10. You will plan the MTA installation later.
When you have completed the Domain Worksheet, transfer the key information from the Domain Worksheet to the Internet Agent Clustering Worksheet.
INTERNET AGENT CLUSTERING WORKSHEET
Under Item 1: Shared Volume for Internet Agent, transfer the domain location to the Internet Agent Clustering Worksheet.
novdocx (en) 11 July 2008
Under Item 2: Internet Agent Domain Name, transfer the domain name and database directory to the Internet Agent Clustering Worksheet.
4.1.2 Deciding Whether to Cluster-Enable the Internet Agent Volume
You should plan to cluster-enable the shared volume where the Internet Agent domain will reside. For a review of the benefits of cluster-enabling volumes, see Section 2.6, “Deciding Whether to
Cluster-Enable the Shared Volumes Used by GroupWise,” on page 27, which describes the issues in
the context of planning MTA and POA installations.
INTERNET AGENT CLUSTERING WORKSHEET
Under Item 1: Shared Volume for Internet Agent, mark Yes under Cluster Enabled?.
Cluster-enabling relies on successful short name resolution throughout your system. Review
Section 2.7, “Ensuring Successful Name Resolution for GroupWise Volumes,” on page 29, which
describes the issues in the context of planning MTA and POA installations.
4.1.3 Determining an Appropriate Failover Path for the Internet Agent Volume
As with the MTA and the POA, you need to decide which nodes in the cluster would be appropriate locations for the Internet Agent volume to fail over to. For a review of failover paths, see
“Determining Appropriate Failover Paths for the Agents” on page 33, which describes the issues in
the context of planning MTA and POA installations.
70 GroupWise 7 Interoperability Guide
INTERNET AGENT CLUSTERING WORKSHEET
Under Item 3: Internet Agent Failover Path, list the nodes that you want to have in the Internet Agent volume failover path.
4.1.4 Planning a Secondary IP Address and Cluster-Unique Port Numbers for the Internet Agent and Its MTA
As with the MTA and the POA, the Internet Agent needs a secondary IP address and cluster-unique port numbers. As part of planning to install the MTA and POA, you should already have determined the secondary IP address and cluster-unique port numbers for the Internet Agent and its MTA as you filled out the “IP Address Worksheet” on page 40. If you do not have a filled-out copy of this worksheet for your system, print it now and fill in current system information.
INTERNET AGENT CLUSTERING WORKSHEET
Under Item 5: MTA Network Information, transfer the MTA secondary IP address and cluster-unique port numbers from the Internet Agent section of the IP Address Worksheet to the Internet Agent Clustering Worksheet.
novdocx (en) 11 July 2008
Under Item 1: Shared Volume for Internet Agent, copy the MTA secondary IP address under Cluster Volume IP Address as well, because they are the same.
Under Item 7: Internet Agent Network Information, transfer the Internet Agent secondary IP address (the same as for its MTA) and the cluster-unique Internet Agent port number from the Internet Agent section of the IP Address Worksheet to the Internet Agent Clustering Worksheet.
4.1.5 Preparing Your Firewall for the Internet Agent
The Internet Agent receives incoming messages on the secondary IP address of the Internet Agent domain volume. Your firewall configuration must be modified to allow inbound TCP/IP traffic from the Internet to the Internet Agent secondary IP address on the following standard ports:
Table 4-1 Standard Ports
Protocol Standard Port
IMAP4 143
LDAP 389
POP3 110
SMTP 25
By default, the Internet Agent sends outgoing messages on the primary IP address of the server where it is running. If you decide to use this default configuration, your firewall must be configured
to allow outbound TCP/IP traffic from all nodes in the Internet Agent volume failover path.
Implementing the Internet Agent in a NetWare Cluster 71
If the Internet Agent has a large number of nodes on its failover path, you could configure the Internet Agent to send outgoing messages to a relay host, which would then send them out through the firewall using its own IP address rather than the address of the particular node where the Internet Agent was running. This reduces the amount of modification to your firewall required to set up the Internet Agent. However, if the relay host goes down, outgoing messages are delayed.
As another alternative, you can configure the Internet Agent to use its secondary IP address for sending as well as receiving messages. Setup instructions for this configuration are provided in
“Forcing Use of the Internet Agent Secondary IP Address” on page 81, which you can complete
after installing the Internet Agent.
In preparation for installing the Internet Agent, configure your firewall as needed to handle the Internet Agent’s use of primary and secondary IP addresses when sending and receiving messages.
4.1.6 Deciding Where to Install the Internet Agent and Its MTA
As with the MTA and the POA, you can choose to install the Internet Agent and its MTA to the sys:\system directory of each node or to a vol:\system directory on the Internet Agent volume. For a discussion of these alternatives, see “Deciding Where to Install the Agent Software”
on page 34, which describes the issues in the context of planning MTA and POA installations. If you
only have one Internet Agent for your GroupWise system with several servers in its failover path, it is an easy choice: Install it once to a vol:\system directory on the Internet Agent volume.
novdocx (en) 11 July 2008
INTERNET AGENT CLUSTERING WORKSHEET
Under Item 4: MTA Installation Location and Item 6: Internet Agent Installation Location, mark whether you will install the Internet Agent and its MTA to a vol:\system directory on the Internet Agent volume or to sys:\system on each node in the cluster. If necessary, specify where the MTA startup file and the Internet Agent configuration file will be stored.
4.1.7 Deciding Whether to Run the Internet Agent and Its MTA in Protected Memory
As with the MTA and the POA, you can choose whether to run the Internet Agent in protected memory. For a review of the benefits of protected memory, see “Deciding Whether to Run the
Agents in Protected Memory” on page 36, which describes the issues in the context of planning
MTA and POA installations.
You might think that protected memory is not necessary if you have only one Internet Agent for your GroupWise system because it could never fail over to a node where another Internet Agent was running. However, because the Internet Agent in a cluster is installed into its own domain with its own MTA, this MTA could fail over to a node where another MTA was already running. Therefore, it is safest to load the MTA into protected memory. Loading the Internet Agent into protected memory is also recommended. Load each agent into its own memory space and mark each memory space as restartable.
INTERNET AGENT CLUSTERING WORKSHEET
Under Item 8: Load Internet Agent and Its MTA in Protected Memory?, mark whether you need to run the Internet Agent and its MTA in protected memory. If you do, provide a protected memory address space name for each agent.
72 GroupWise 7 Interoperability Guide
4.1.8 Planning the MTA Installation
Follow the instructions in “Planning the NetWare Agent Installation” on page 37, then return to this point. After you follow the instructions, you have a filled-out NetWare Agent Worksheet to use when you install the MTA.
IMPORTANT: Do not install the NetWare MTA until you are instructed to do so in Section 4.2,
“Setting Up the Internet Agent in a Cluster,” on page 73.
4.1.9 Planning the Internet Agent Installation
Aside from the cluster-specific issues discussed in the preceding sections, the considerations involved in planning to install the Internet Agent are the same in a clustering environment as for any other environment. Review the installation instructions in “NetWare and Windows: Installing the
Internet Agent Software” in “Installing the GroupWise Internet Agent” in the GroupWise 7
Installation Guide. You might want to print this section and write down the types of planning
information you have provided on worksheets in other sections. You will need this information as you install the Internet Agent in your cluster.
novdocx (en) 11 July 2008
IMPORTANT: Do not install the Internet Agent software until you are instructed to do so in
Section 4.2, “Setting Up the Internet Agent in a Cluster,” on page 73.

4.2 Setting Up the Internet Agent in a Cluster

You should already have reviewed Section 4.1, “Planning the Internet Agent in a Cluster,” on
page 69 and filled out the Section 4.4, “Internet Agent Clustering Worksheet,” on page 84. You are
now ready to complete the following tasks to set up the Internet Agent in a clustering environment:
Section 4.2.1, “Cluster-Enabling a Shared Volume for Use with the Internet Agent,” on page 73
Section 4.2.2, “Creating a Domain for the Internet Agent,” on page 74
Section 4.2.3, “Installing the MTA for the Internet Agent Domain,” on page 74
Section 4.2.4, “Installing and Configuring the Internet Agent in a Cluster,” on page 74
Section 4.2.5, “Testing the Clustered Internet Agent,” on page 82
4.2.1 Cluster-Enabling a Shared Volume for Use with the Internet Agent
To cluster-enable the Internet Agent shared volume:
1 Complete the cluster-enabling steps in the applicable section of the cluster documentation for
your version of NetWare, as listed in Chapter 1, “Introduction to GroupWise 7 and Novell
Cluster Services on NetWare,” on page 21.
The Internet Agent Clustering Worksheet provides the volume to cluster-enable, the cluster­enabled volume IP address, and the failover path for the Internet Agent volume.
®
For a review of the new Novell a shared volume, see Section 2.6, “Deciding Whether to Cluster-Enable the Shared Volumes
Used by GroupWise,” on page 27.
eDirectoryTM objects that are created when you cluster-enable
Implementing the Internet Agent in a NetWare Cluster 73
If you have installed the latest version of ConsoleOne® and the Novell Cluster Services snap­in, you can rename the cluster-related objects in case your DNS name server cannot resolve object names that include the underscore (_) character.
2 To ensure successful short name resolution, add entries for the Internet Agent virtual server to
support your preferred methods of short name resolution, as described in “Configuring Short
Name Resolution” on page 44.
3 To ensure that the Internet Agent has incoming and outgoing access to the Internet, make sure
your firewall is properly configured, as described in “Preparing Your Firewall for the Internet
Agent” on page 71.
4 Continue with Creating a Domain for the Internet Agent.
4.2.2 Creating a Domain for the Internet Agent
The Internet Agent domain will be a secondary domain. To create it, follow the instructions in
Section 3.3, “Creating a New Secondary Domain in a Cluster,” on page 48, taking your information
from the Internet Agent Clustering Worksheet, rather than the System Clustering Worksheet, then return to this point.
novdocx (en) 11 July 2008
Do not create any post offices in the Internet Agent domain.
Continue with Installing the MTA for the Internet Agent Domain.
4.2.3 Installing the MTA for the Internet Agent Domain
The MTA for the Internet Agent domain can be installed just like any other MTA in your clustered GroupWise system. Follow the instructions in “Installing the Agent Software in a Cluster” on
page 51, then return to this point.
You do not need to edit the MTA startup file. You do not need to modify the Volume Resource properties until after you have installed the Internet Agent.
Continue with Installing and Configuring the Internet Agent in a Cluster.
4.2.4 Installing and Configuring the Internet Agent in a Cluster
After you have created a domain for the Internet Agent and installed the MTA for that domain, you are ready to install and configure the Internet Agent.
“Installing the Internet Agent Software in a Cluster” on page 74
“Configuring the Internet Agent Volume Resource to Load and Unload the Internet Agent and
Its MTA” on page 75
“Enabling Internet Addressing for Your Clustered GroupWise System” on page 80
“Verifying Internet Agent Object Properties” on page 80
Installing the Internet Agent Software in a Cluster
1 Map a drive to the Internet Agent volume (Internet Agent Clustering Worksheet item 1).
The Internet Agent volume name will be cluster_volume. For assistance with mapping a drive to a cluster-enabled volume, see “Configuring Short Name Resolution” on page 44.
74 GroupWise 7 Interoperability Guide
2 If you selected vol:\system on Internet Agent Volume as the Internet Agent installation
location (Internet Agent Clustering Worksheet item 6), create the vol:\system directory on the Internet Agent volume accessed in Step 1.
or
If you selected sys:\system on Each Node, decide which node you will install the Internet Agent to first, then map a drive to sys:\system on that node.
®
3 Start the Internet Agent Installation program and install the NetWare
Internet Agent, following the steps provided in “NetWare and Windows: Installing the Internet Agent
Software” in “Installing the GroupWise Internet Agent” in the GroupWise 7 Installation Guide.
Keep in mind the following cluster-specific details:
Use the notes you made during “Planning the Internet Agent Installation” on page 73 to
fill in the fields during the Internet Agent installation process.
In the Installation Path dialog box, be sure to browse through the drive you mapped to the
location you chose in Step 2 above. Deselect Update AUTOEXEC File and select Configure GroupWise Agents for Clustering.
In the GroupWise Domain dialog box, be sure to browse through the drive you mapped in
Step 1 to the domain directory (Internet Agent Clustering Worksheet item 2).
The Internet Agent Installation program creates the gwia.ncf file, which includes the
load command for the Internet Agent. You need this information later when you create
the load script for the Volume Resource object.
4 If you need to install the Internet Agent to sys:\system to each node in the cluster:
novdocx (en) 11 July 2008
4a Repeat Step 3, mapping new drives as needed.
4b If you marked Yes for Consolidate Multiple Configuration Files on Internet Agent
Volume? (under Internet Agent Clustering Worksheet item 6), copy the gwia.cfg file to the planned location, then delete it from the sys:\system directories to avoid future confusion.
5 Make sure you have completed all the tasks described in “Installing the GroupWise Internet
Agent” in the GroupWise 7 Installation Guide.
The Internet Agent starts automatically immediately after Installation.
6 Stop each Internet Agent you have installed before configuring it for clustering.
7 Continue with Configuring the Internet Agent Volume Resource to Load and Unload the
Internet Agent and Its MTA.
Configuring the Internet Agent Volume Resource to Load and Unload the Internet Agent and Its MTA
The properties of the Volume Resource object define how the Internet Agent volume functions
TM
within the cluster, how NLM
programs are loaded and unloaded, and how failover and failback
situations are handled. Complete the following tasks for the Internet Agent volume:
“Modifying the Volume Resource Load Script for the Internet Agent” on page 75
“Modifying the Volume Resource Unload Script for the Internet Agent” on page 77
“Setting the Failover Path and Policies for the Internet Agent” on page 79
Modifying the Volume Resource Load Script for the Internet Agent
The volume resource load script executes whenever the Internet Agent volume comes online.
Implementing the Internet Agent in a NetWare Cluster 75
To set up the load script:
1 In ConsoleOne, browse to and select the Cluster object.
If necessary, click View > Conso le View to display its contents.
2 Right-click the Volume Resource object (volume_SERVER), then click Properties > Load to
display the default volume resource load script for the Internet Agent volume.
The next step assumes that this is the first time you have edited this load script. If other GroupWise agents are already running from this volume, some of the modifications have already been made.
3 Make the following changes to the default load script:
Remove the trustmig command. It is not necessary to migrate trustees for the Internet
Agent volume. Removing this line helps the load script to execute faster.
On NetWare 5.1, if you are using SLP as a short name resolution method, as described in
“Configuring Short Name Resolution” on page 44, add the cvsbind add command for
the Internet Agent volume to the load script.
cvsbind add cluster_volume_SERVER IP_address
If you selected vol:\system on Internet Agent volume as the installation location
(Internet Agent Clustering Worksheet items 4 and 6), add a search add command to add the new vol:\system directory to the server search path.
novdocx (en) 11 July 2008
search add volume:\system
If you selected sys:\system on each node as the installation location (Internet Agent
Clustering Worksheet items 4 and 6) but you are storing the MTA startup file and the
Internet Agent configuration file on the Internet Agent volume, add that location to the server search path.
If you marked No under Load Internet Agent and Its MTA in Protected Memory? (Internet
Agent Clustering Worksheet item 8), add the following abend recovery options:
set auto restart after abend = 2 set auto restart after abend delay time = 0 set auto restart down timeout = 60 set developer option = off
These settings provide the best possible handling of GroupWise databases in the event that an abend should occur within the cluster.
Transfer the MTA load command from the grpwise.ncf file located in the
vol:\system directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text into the load script page. Then delete or rename the grpwise.ncf file to avoid future confusion.
load volume:\system\gwmta.nlm @domain.mta
Add a delay so that the MTA is fully loaded before the Internet Agent starts to load:
load delay.nlm delay 10
The length of the delay varies from system to system; ten seconds is a good starting place.
76 GroupWise 7 Interoperability Guide
Transfer the Internet Agent load command from the gwia.ncf file located in the
vol:\system directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text into the load script page. Then delete or rename the gwia.ncf file to avoid future confusion.
load volume:\system\gwia.nlm @gwia.cfg
If you marked Yes under Load Internet Agent and Its MTA in Protected Memory?
(Internet Agent Clustering Worksheet item 8), add the address space parameter to the load commands to specify the protected address space where the Internet Agent and its MTA will run. Add a protection restart command for the address space name.
load address space=addr_space_name
volume:\system\gwmta.nlm @domain.mta
load address space=addr_space_name
volume:\system\gwia.nlm @gwia.cfg
protection restart addr_space_name
The result would look similar to the following example:
novdocx (en) 11 July 2008
NOTE: The set commands are needed in the load script only when the MTA and the Internet Agent are not running in protected memory. The address space parameters are needed in the load commands only when the MTA and the Internet Agent are running in protected memory.
4 Click Apply to save the load script.
5 If necessary, click OK to confirm that you must offline and then online the volume resource in
order for the changes to take effect.
6 Continue with Modifying the Volume Resource Unload Script for the Internet Agent.
Modifying the Volume Resource Unload Script for the Internet Agent
The volume resource unload script executes whenever the Internet Agent volume goes offline. Programs should be unloaded in the reverse order of how they were loaded. This ensures that supporting programs are not unloaded before programs that rely on them in order to function properly.
Implementing the Internet Agent in a NetWare Cluster 77
To set up the unload script:
1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER),
click Unload to display the default volume resource unload script.
The next step assumes that this is the first time you have edited this unload script. If other GroupWise agents are already running from this volume, some of the modifications have already been made.
2 Make the following changes to the default unload script:
If you marked Yes under Load Internet Agent and Its MTA in Protected Memory?
(Internet Agent Clustering Worksheet item 8), add an unload address space command and an unload kill address space command to ensure that the address space is completely cleaned up.
unload address space=addr_space_name unload kill address space=addr_space_name
If your system seems to be trying to kill the address space before the Internet Agent and its MTA have been completely unloaded, resulting in the agents hanging in the unloading state, set a delay of several seconds before issuing the unload kill address space command to allow the Internet Agent and its MTA adequate time to unload completely. The length of the delay varies from system to system; ten seconds is a good starting place.
novdocx (en) 11 July 2008
unload address space=addr_space_name delay 10 unload kill address space=addr_space_name
If you marked No under Load Internet Agent and Its MTA in Protected Memory? (Internet
Agent Clustering Worksheet items 8), create an unload command parallel to each load
command that you placed in the load script.
unload gwia.nlm unload gwmta.nlm
On NetWare 5.1, if you are using SLP as a short name resolution method, add the
cvsbind del command for the Internet Agent volume to the unload script.
cvsbind del cluster_volume_SERVER IP_address
Remove the trustmig command just like you did in the load script.
The result would look similar to the following example:
78 GroupWise 7 Interoperability Guide
3 Click Apply to save the unload script.
4 If necessary, click OK to confirm that you must offline and then online the volume resource in
order for the changes to take effect.
novdocx (en) 11 July 2008
5 Continue with Setting the Failover Path and Policies for the Internet Agent.
Setting the Failover Path and Policies for the Internet Agent
To modify the failover path and policies for the Internet Agent volume resource:
1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER),
click Nodes to display the default failover path for the Internet Agent volume resource.
2 Arrange the nodes in the cluster into the desired failover path for the Internet Agent volume
(Internet Agent Clustering Worksheet item 3).
3 Click Apply to save the failover path.
4 Click Policies to display the default start, failover, and failback policies.
Implementing the Internet Agent in a NetWare Cluster 79
The default policy settings are often appropriate. By default, a volume resource:
Fails over automatically if the node it is running on fails
Starts automatically on the next node in its failover path
Continues running at its failover location, even after its most preferred node is again
available
If you are considering changing these defaults, see the applicable section about failover and failback modes in the cluster documentation for your version of NetWare, as listed in
Chapter 1, “Introduction to GroupWise 7 and Novell Cluster Services on NetWare,” on page 21.
5 Click OK when you are finished editing the Internet Agent volume resource properties.
novdocx (en) 11 July 2008
6 Continue with Enabling Internet Addressing for Your Clustered GroupWise System.
Enabling Internet Addressing for Your Clustered GroupWise System
Setting up Internet addressing for a clustered Internet Agent is no different from setting it up for an Internet Agent in a any other environment. Follow the instructions in “Enabling Internet
Addressing” in “System” in the GroupWise 7 Administration Guide, then return to this point.
Verifying Internet Agent Object Properties
During installation of the Internet Agent, the Internet Agent object should have been configured correctly. However, it can be helpful to verify certain cluster-specific information in order to familiarize yourself with the configuration of a clustered Internet Agent.
“Accessing Internet Agent Object Properties” on page 80
“Verifying the Reference to the Volume Resource” on page 81
“Verifying the Reference to the Virtual Server” on page 81
“Verifying Post Office Links” on page 81
“Forcing Use of the Internet Agent Secondary IP Address” on page 81
Accessing Internet Agent Object Properties
1 In ConsoleOne, browse to and select the Internet Agent domain in order to display its contents.
80 GroupWise 7 Interoperability Guide
2 Right-click the Internet Agent object, then click Properties.
3 Continue with Verifying the Reference to the Volume Resource.
Verifying the Reference to the Volume Resource
In the Internet Agent object properties pages:
1 Click SMTP/MIME > Settings.
2 Verify the contents of the Hostname/DNS "A Record" Name field.
It displays the hostname as currently configured in DNS. It should match the Volume Resource object name (volume_SERVER) of the Internet Agent volume, not the name of a physical server in the cluster.
3 Make changes if necessary.
4 Continue with Verifying the Reference to the Virtual Server.
Verifying the Reference to the Virtual Server
In the Internet Agent object properties pages:
novdocx (en) 11 July 2008
1 Click Server Directories.
2 Verify that the displayed directories match the virtual server name (cluster_volume_SERVER)
associated with the Volume Resource object, not the name of a physical server in the cluster.
3 Make changes if necessary.
4 Continue with Verifying Post Office Links.
Verifying Post Office Links
In the Internet Agent object properties pages:
1 Click Post Office Links.
2 Verify that the Access Mode column displays C/S (for client/server mode) for all post offices
serviced by the Internet Agent.
3 Verify that the Links column displays the secondary IP addresses of the GroupWise volumes
where post offices reside, not the IP addresses of any physical servers in the cluster.
4 Make changes if necessary.
5 Continue with Forcing Use of the Internet Agent Secondary IP Address.
Forcing Use of the Internet Agent Secondary IP Address
If you want the Internet Agent to send outgoing messages on its secondary IP address, rather than using the default of its primary IP address:
1 Click GroupWise > Network Address.
2 In the TCP/IP Address field, provide the secondary IP address (under Internet Agent Clustering
Worksh e e t item 1) for the Internet Agent to use for sending outgoing messages.
3 Click SMTP/MIME, then click Settings.
4 Select Bind to TCP/IP Address at Connection Time.
Implementing the Internet Agent in a NetWare Cluster 81
5 Click OK.
6 Continue with Testing the Clustered Internet Agent.
4.2.5 Testing the Clustered Internet Agent
After you have configured the Internet Agent volume resource, you can test the load and unload scripts by bringing the Internet Agent volume online and taking it offline again.
1 In ConsoleOne, select the Cluster object, then click View > Cluster State.
novdocx (en) 11 July 2008
The new Internet Agent volume resource shows Offline in the State column.
2 Click the new Internet Agent volume resource, then click Online.
The State column for the volume resource now displays Running.
3 Observe the server console where the Internet Agent and its MTA are loading to see that they
start and run correctly.
If you are using protected memory, you can use the protection command at the server console prompt to list all the address spaces on the node and what NLM programs are running in each one.
4 Click the new Internet Agent volume resource, then click Offline.
The State column for the volume resource returns to Offline.
5 Observe the server console where the Internet Agent and its MTA are unloading to see that they
shut down correctly.
If you are using protected memory, you can use the protection command again to make sure that the address space used by the Internet Agent and its MTA is no longer present.
82 GroupWise 7 Interoperability Guide
6 Repeat Step 2 whenever you are ready to bring the new Internet Agent volume resource online
permanently.
On NetWare 6.x, these actions can also be performed from your Web browser. See “Using
Novell Remote Manager on NetWare 6.x” on page 61.
7 Continue with Managing the Internet Agent in a Cluster.

4.3 Managing the Internet Agent in a Cluster

After you have installed the Internet Agent in a cluster, you should consider some long-term management issues.
Section 4.3.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 83
Section 4.3.2, “Knowing What to Expect in an Internet Agent Failover Situation,” on page 84
4.3.1 Updating GroupWise Objects with Cluster-Specific Descriptions
novdocx (en) 11 July 2008
After installing the Internet Agent in your clustered GroupWise system, while the cluster-specific information is fresh in your mind, you should record that cluster-specific information as part of the GroupWise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the information recorded in the GroupWise objects if the configuration of your system changes.
“Recording Cluster-Specific Information about the Internet Agent Domain and Its MTA” on
page 83
“Recording Cluster-Specific Information about the Internet Agent” on page 84
Recording Cluster-Specific Information about the Internet Agent Domain and Its MTA
To permanently record important cluster-specific information for the Internet Agent domain:
1 In ConsoleOne, browse to and right-click the Domain object, then click Properties.
2 In the Description field of the Internet Agent domain Identification page, provide a cluster-
specific description of the Internet Agent domain, including the secondary IP address of its cluster-enabled volume and the cluster-unique port numbers used by its MTA.
3 Click OK to save the Internet Agent domain description.
4 Select the Internet Agent Domain object to display its contents.
5 Right-click the MTA object, then click Properties.
6 In the Description field of the MTA Identification page, record the secondary IP address of the
cluster-enabled Internet Agent domain volume and the cluster-unique port numbers used by the MTA.
This information appears on the MTA console, no matter which node in the cluster it is currently running on.
7 Click OK to save the MTA description.
8 Continue with Recording Cluster-Specific Information about the Internet Agent.
Implementing the Internet Agent in a NetWare Cluster 83
Recording Cluster-Specific Information about the Internet Agent
With the contents of the Internet Agent domain still displayed:
1 Right-click the Internet Agent object, then click Properties.
2 Click GroupWise, then click Identification.
3 In the Description field, record the secondary IP address of the cluster-enabled Internet Agent
domain volume and the cluster-unique port numbers used by the Internet Agent.
This information appears on the Internet Agent console, no matter which node in the cluster it is currently running on.
4 Click OK to save the Internet Agent information.
5 Continue with Knowing What to Expect in an Internet Agent Failover Situation.
4.3.2 Knowing What to Expect in an Internet Agent Failover Situation
The failover behavior of the MTA for the Internet Agent domain is the same as for an MTA in a regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” on page 64.
novdocx (en) 11 July 2008
Failover of the Internet Agent itself is more complex. The various clients (POP3, IMAP4, and LDAP) receive an error message that the node is not available. Most of the clients do not attempt to reconnect automatically, so the user must exit the client and restart it to reestablish the connection after the failover process is complete. Fortunately, the Internet Agent restarts quickly in its failover location so users can reconnect quickly.
As with the MTA and the POA, migration of the Internet Agent takes longer than failover. In fact, the Internet Agent can seem especially slow to shut down properly as it finishes its normal processing and stops its threads. For a busy Internet Agent, you might need to wait several minutes for it to shut down properly.

4.4 Internet Agent Clustering Worksheet

Item Explanation
1) Shared Volume for Internet Agent:
Cluster Enabled?
Yes (highly recommended)
Cluster volume IP address
No
Specify the name (cluster_volume) of the shared volume where the Internet Agent domain will be created.
For cluster-enabling, specify the IP addresses of the virtual server (volume_SERVER.cluster) to which the cluster-enabled volume is tied.
For more information, see “Deciding Whether to Cluster-Enable the
Internet Agent Volume” on page 70.
2) Internet Agent Domain Name:
Domain Database Location:
84 GroupWise 7 Interoperability Guide
Specify a unique name for the Internet Agent domain. Specify the directory on the Internet Agent volume where you want to create the new domain.
For more information, see “Planning a Domain for the Internet Agent”
on page 70.
Item Explanation
novdocx (en) 11 July 2008
3) Internet Agent Failover Path:
4) MTA Installation Location:
vol:\system on Internet
Agent volume
sys:\system on each
node
Consolidate multiple MTA startup files on Internet Agent volume?
5) MTA Network Information:
MTA IP address
MTA message transfer port
MTA live remote port
MTA HTTP port
6) Internet Agent Installation Location:
vol:\system on the
Internet Agent volume
sys:\system on each
node
Consolidate multiple Internet Agent configuration files on Internet Agent volume?
List other nodes in the cluster where the Internet Agent and its MTA could fail over.
For more information, see “Determining an Appropriate Failover Path
for the Internet Agent Volume” on page 70.
Mark the location where you will install the MTA software. If necessary, specify the location where you will consolidate multiple MTA startup files on an Internet Agent volume.
For more information, see “Deciding Where to Install the Internet
Agent and Its MTA” on page 72.
Gather the MTA network address information from the Internet Agent section of the “IP Address Worksheet” on page 40.
For more information, see “Planning a Secondary IP Address and
Cluster-Unique Port Numbers for the Internet Agent and Its MTA” on page 71.
Mark the location where you will install the Internet Agent software.
If necessary, specify the location where you will consolidate multiple Internet Agent configuration files (gwia.cfg) on an Internet Agent volume.
For more information, see “Deciding Where to Install the Internet
Agent and Its MTA” on page 72.
7) Internet Agent Network Information:
Internet Agent IP address
Internet Agent HTTP port
8) Load Internet Agent and Its MTA in Protected Memory?
No
Yes
Protected address space names:
MTA:
Internet Agent:
Gather the Internet Agent network address information from the Internet Agent section of the “IP Address Worksheet” on page 40.
For more information, see “Planning a Secondary IP Address and
Cluster-Unique Port Numbers for the Internet Agent and Its MTA” on page 71.
Mark whether you need to run the Internet Agent and its MTA in protected memory. If so, specify a unique address space for each agent.
For more information, see “Deciding Whether to Run the Internet
Agent and Its MTA in Protected Memory” on page 72.
Implementing the Internet Agent in a NetWare Cluster 85

4.5 Internet Agent Quick Checklist

Plan the new clustered Internet Agent, including the new domain required to house the Internet
Agent in a clustering environment.
See Section 4.1, “Planning the Internet Agent in a Cluster,” on page 69.
Make sure your firewall is configured to accommodate the Internet Agent.
See Section 4.1.5, “Preparing Your Firewall for the Internet Agent,” on page 71.
Cluster-enable the volume where the Internet Agent domain will reside.
See Section 5.3.1, “Cluster-Enabling a Shared Volume for Use with the WebAccess Agent,” on
page 93.
Create the new Internet Agent domain.
See Section 4.2.2, “Creating a Domain for the Internet Agent,” on page 74.
Set up the MTA for the new Internet Agent domain.
See Section 4.2.3, “Installing the MTA for the Internet Agent Domain,” on page 74.
Install the Internet Agent.
novdocx (en) 11 July 2008
See “Installing the Internet Agent Software in a Cluster” on page 74.
Modify the Internet Agent volume resource load script:
Remove the trustmig command
Add the cvsbind add command (NetWare 5.1 only; optional)
Add the search add command (optional)
If you will not run the MTA and the Internet Agent in protected memory, add the set
auto restart commands and the set developer option = off command
Add the load commands for the MTA and the Internet Agent, separating them with a
delay command
If you will run the MTA and the Internet Agent in protected memory, add the address
space parameter to the load commands and add a protection restart command for the address space
See “Modifying the Volume Resource Load Script for the Internet Agent” on page 75.
Modify the Internet Agent volume resource unload script:
Add the MTA and Internet Agent or address space unload command(s)
Add the cvsbind del command if you used the cvsbind add command in the load
script (NetWare 5.1 only; optional)
Remove the trustmig command
See “Modifying the Volume Resource Unload Script for the Internet Agent” on page 77.
Set up the Internet Agent volume failover path and policies.
See “Setting the Failover Path and Policies for the Internet Agent” on page 79.
Enable Internet Addressing for the clustered Internet Agent.
See “Enabling Internet Addressing for Your Clustered GroupWise System” on page 80.
Double-check the cluster-specific Internet Agent object properties.
See “Verifying Internet Agent Object Properties” on page 80.
86 GroupWise 7 Interoperability Guide
Test the clustered Internet Agent.
See Section 4.2.5, “Testing the Clustered Internet Agent,” on page 82.
Record cluster-specific information in the properties pages of the GroupWise objects
associated with the Internet Agent.
See Section 4.3.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on
page 83.
novdocx (en) 11 July 2008
Implementing the Internet Agent in a NetWare Cluster 87
novdocx (en) 11 July 2008
88 GroupWise 7 Interoperability Guide
5
Implementing WebAccess in a
novdocx (en) 11 July 2008
NetWare Cluster
You should already have set up at least a basic GroupWise® system, as described in Chapter 2,
“Planning GroupWise in a NetWare Cluster,” on page 23 and Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,” on page 43. As part of this process, the “System Clustering Worksheet” on page 37 and the “IP Address Worksheet” on page 40 were filled out. If you do not
have access to the filled-out worksheets, print the worksheets now and fill in the clustering and network address information as it currently exists on your system. You need this information as you implement WebAccess in a cluster.
Section 5.1, “Understanding the WebAccess Components,” on page 89
Section 5.2, “Planning WebAccess in a Cluster,” on page 89
Section 5.3, “Setting Up WebAccess in a Cluster,” on page 93
Section 5.4, “Managing WebAccess in a Cluster,” on page 101
Section 5.5, “WebAccess Clustering Worksheet,” on page 103
Section 5.6, “WebAccess Quick Checklist,” on page 104

5.1 Understanding the WebAccess Components

If you are not familiar with GroupWise WebAccess, review “GroupWise WebAccess Overview” in Installing GroupWise WebAccess” in the GroupWise 7 Installation Guide.
5
As you plan WebAccess in a clustering environment, you must keep in mind that WebAccess consists of two components:
WebAccess Agent (gwinter.nlm) that will be associated with a GroupWise WebAccess
domain in the cluster
WebAccess Application (a Java* servlet) that will be added to your Web server. You can install
the WebAccess Application on a clustered Web server or a non-clustered Web server. How to set up and manage a clustered Web server is beyond the scope of the GroupWise documentation. If you have not clustered your Web server, you can install the WebAccess Application on a server that is outside of the cluster where the WebAccess Agent is installed.

5.2 Planning WebAccess in a Cluster

A main system configuration difference between a GroupWise system in a clustering environment and a GroupWise system in a regular environment is that you need to create a separate domain to house each GroupWise gateway, including the WebAccess Agent.
Section 5.5, “WebAccess Clustering Worksheet,” on page 103 lists all the information you need as
you set up the WebAccess Agent in a clustering environment. You should print the worksheet and fill it out as you complete the tasks listed below:
Section 5.2.1, “Planning a New Domain for the WebAccess Agent,” on page 90

Implementing WebAccess in a NetWare Cluster

89
Section 5.2.2, “Deciding Whether to Cluster-Enable the WebAccess Agent Volume,” on
page 90
Section 5.2.3, “Determining an Appropriate Failover Path for the WebAccess Agent Volume,”
on page 91
Section 5.2.4, “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the
WebAccess Agent and Its MTA,” on page 91
Section 5.2.5, “Deciding Where to Install the WebAccess Agent and Its MTA,” on page 91
Section 5.2.6, “Deciding Whether to Run the WebAccess Agent and Its MTA in Protected
Memory,” on page 92
Section 5.2.7, “Planning the MTA Installation,” on page 92
Section 5.2.8, “Planning the WebAccess Installation,” on page 92
5.2.1 Planning a New Domain for the WebAccess Agent
The considerations involved in planning a domain for the WebAccess Agent are much the same as planning any other domain. In preparation, review “Planning a New Domain”, then print and fill out the “Domain Worksheet” in “Domains” in the GroupWise 7 Administration Guide.
novdocx (en) 11 July 2008
Keep in mind the following cluster-specific details:
When you specify the location for the domain directory on the Domain Worksheet, include the
shared volume where you want the domain directory to reside.
Do not concern yourself with the GroupWise agent information on the Domain Worksheet. You
can stop with item 10. You will plan the MTA installation later.
When you have completed the Domain Worksheet, transfer the key information from the Domain Worksheet to the WebAccess Clustering Worksheet.
WEBACCESS CLUSTERING WORKSHEET
Under Item 1: Shared Volume for WebAccess Agent, transfer the domain location from the Domain Worksheet to the WebAccess Clustering Worksheet.
Under Item 2: WebAccess Agent Domain Name, transfer the domain name and database directory from the Domain Worksheet to the WebAccess Clustering Worksheet.
5.2.2 Deciding Whether to Cluster-Enable the WebAccess Agent Volume
You should plan to cluster-enable the shared volume where the WebAccess Agent domain will reside. For a review of the benefits of cluster-enabling volumes, see Section 2.6, “Deciding Whether
to Cluster-Enable the Shared Volumes Used by GroupWise,” on page 27, which describes the issues
in the context of planning MTA and POA installations.
WEBACCESS CLUSTERING WORKSHEET
Under Item 1: Shared Volume for WebAccess Agent, mark Yes under Cluster Enabled?.
90 GroupWise 7 Interoperability Guide
Cluster-enabling relies on successful short name resolution throughout your system. Review
Section 2.7, “Ensuring Successful Name Resolution for GroupWise Volumes,” on page 29, which
describes the issues in the context of planning MTA and POA installations.
5.2.3 Determining an Appropriate Failover Path for the WebAccess Agent Volume
As with the MTA and the POA, you need to decide which nodes in the cluster are appropriate locations where the WebAccess Agent volume could fail over. For a review of failover paths, see
“Determining Appropriate Failover Paths for the Agents” on page 33, which describes the issues in
the context of planning MTA and POA installations.
WEBACCESS CLUSTERING WORKSHEET
Under Item 4: WebAccess Agent Failover Path, list the nodes that you want to have in the WebAccess Agent volume failover path.
5.2.4 Planning a Secondary IP Address and Cluster-Unique
novdocx (en) 11 July 2008
Port Numbers for the WebAccess Agent and Its MTA
As with the MTA and the POA, the WebAccess Agent needs a secondary IP address and cluster­unique port numbers. As part of planning to install the MTA and POA, you should already have determined the secondary IP address and cluster-unique port numbers for the WebAccess Agent and its MTA as you filled out the “IP Address Worksheet” on page 40. If you do not have a filled-out copy of this worksheet for your system, print it now and fill in current system information.
WEBACCESS CLUSTERING WORKSHEET
Under Item 6: MTA Network Information, transfer the MTA secondary IP address and cluster-unique port numbers from the WebAccess section the IP Address Worksheet to the WebAccess Clustering Worksheet.
Under Item 1: Shared Volume for WebAccess Agent, copy the MTA secondary IP address under Cluster Volume IP Address as well, because they are the same.
Under Item 8: WebAccess Agent Network Information, transfer the WebAccess Agent secondary IP address (the same as for its MTA) and the cluster-unique WebAccess Agent port number from the WebAccess section of the IP Address Worksheet to the WebAccess Clustering Worksheet.
5.2.5 Deciding Where to Install the WebAccess Agent and Its MTA
As with the MTA and the POA, you can choose to install the WebAccess Agent and its MTA to the sys:\system directory of each node or to a vol:\system directory on the WebAccess Agent volume. For a discussion of these alternatives, see “Deciding Where to Install the Agent Software”
on page 34, which describes the issues in the context of planning MTA and POA installations. If you
only have one WebAccess Agent for your GroupWise system with several nodes in its failover path, it is an easy choice.
Implementing WebAccess in a NetWare Cluster 91
WEBACCESS CLUSTERING WORKSHEET
Under Item 5: MTA Installation Location and Item 7: WebAccess Agent Installation Location, mark whether you will install the WebAccess Agent and its MTA to sys:\system on each node in the cluster or to a vol:\system directory on the WebAccess Agent volume. Also specify where the MTA startup file will be stored.
5.2.6 Deciding Whether to Run the WebAccess Agent and Its MTA in Protected Memory
As with the MTA and the POA, you can choose whether to run the WebAccess Agent in protected memory. For a review of the benefits of protected memory, see “Deciding Whether to Run the
Agents in Protected Memory” on page 36, which describes the issues in the context of planning
MTA and POA installations.
You might think that protected memory is not necessary if you have only one WebAccess Agent for your GroupWise system because it could never fail over to a node where another WebAccess Agent was running. However, because the WebAccess Agent in a cluster is installed into its own domain with its own MTA, this MTA could fail over to a node where another MTA was already running. Therefore, it is safest to load the WebAccess Agent and its MTA into protected memory. Load each agent into its own memory space and mark each memory space as restartable.
novdocx (en) 11 July 2008
WEBACCESS CLUSTERING WORKSHEET
Under Item 8: Load WebAccess Agent and Its MTA in Protected Memory?, mark whether you need to run the WebAccess Agent and its MTA in protected memory. If you do, provide a protected memory address space name for each agent.
5.2.7 Planning the MTA Installation
Follow the instructions in “Planning the NetWare Agent Installation” on page 37, then return to this point. After you follow the instructions, you will have a filled-out NetWare Agent Worksheet to use when you install the MTA.
IMPORTANT: Do not install the NetWare MTA until you are instructed to do so in Section 5.3,
“Setting Up WebAccess in a Cluster,” on page 93.
5.2.8 Planning the WebAccess Installation
Aside from the cluster-specific issues discussed in the preceding sections, the considerations involved in planning to install WebAccess are the same in a clustering environment as for any other environment. Review “Planning GroupWise WebAccess”, then print and fill out the “GroupWise
WebAccess Installation Worksheet” in “Installing GroupWise WebAccess” in the GroupWise 7
Installation Guide. When you set up WebAccess in a cluster, you install the WebAccess Agent and
the WebAccess Application in two separate steps:
“Planning the WebAccess Agent Installation” on page 93
“Planning the WebAccess Application Installation” on page 93
92 GroupWise 7 Interoperability Guide
IMPORTANT: Do not install the WebAccess software until you are instructed to do so in
Section 5.3, “Setting Up WebAccess in a Cluster,” on page 93.
Planning the WebAccess Agent Installation
For the WebAccess Agent, fill out items 2 through 12 on the GroupWise WebAccess Installation Worksheet, taking into account the following cluster-specific issues:
WEBACCESS INSTALLATION WORKSHEET
Under Item 2: Installation Directory, take into account your decision recorded on the WebAccess Clustering Worksheet (Item 7: WebAccess Agent Installation Location).
Under Item 3: Server Address, transfer the IP address and port number from the WebAccess Clustering Worksheet (Item 8: WebAccess Agent Network Information) filled out in “Planning a
Secondary IP Address and Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 91.
Under Item 4: Enable Clustering Support?, mark Yes . This causes the WebAccess Installation program to customize the WebAccess files for clustering.
novdocx (en) 11 July 2008
Under Item 5: Domain Directory Path, transfer the domain directory from the Domain Worksheet you filled out in “Planning a New Domain for the WebAccess Agent” on page 90.
Planning the WebAccess Application Installation
The WebAccess Application can be installed on a clustered or non-clustered Web server. How to set up and manage a clustered Web server is beyond the scope of the GroupWise documentation. For WebAccess Application planning information, see “Determining the WebAccess and WebPublisher
Applications’ Configuration” in “Installing GroupWise WebAccess” in the GroupWise 7 Installation
Guide.

5.3 Setting Up WebAccess in a Cluster

You should already have reviewed Section 5.2, “Planning WebAccess in a Cluster,” on page 89 and filled out the Section 5.5, “WebAccess Clustering Worksheet,” on page 103. You are now ready to complete the following tasks to set up the WebAccess Agent in a clustering environment:
Section 5.3.1, “Cluster-Enabling a Shared Volume for Use with the WebAccess Agent,” on
page 93
Section 5.3.2, “Creating a Domain for the WebAccess Agent,” on page 94
Section 5.3.3, “Installing the MTA for the WebAccess Agent Domain,” on page 94
Section 5.3.4, “Installing and Configuring the WebAccess Agent in a Cluster,” on page 94
Section 5.3.5, “Testing Your Clustered WebAccess Installation,” on page 100
5.3.1 Cluster-Enabling a Shared Volume for Use with the WebAccess Agent
1 Complete the cluster-enabling steps in the applicable section of cluster documentation for your
version of NetWare, as listed in Chapter 1, “Introduction to GroupWise 7 and Novell Cluster
Services on NetWare,” on page 21.
Implementing WebAccess in a NetWare Cluster 93
The WebAccess Clustering Worksheet provides the volume to cluster-enable, the cluster­enabled volume IP address, and the failover path for the WebAccess volume.
For a review of the new Novell eDirectory shared volume, see Section 2.6, “Deciding Whether to Cluster-Enable the Shared Volumes
Used by GroupWise,” on page 27.
If you have installed the latest version of ConsoleOne® and the Novell Cluster Services snap­in, you can rename the cluster-related objects in case your DNS name server cannot resolve object names that include the underscore (_) character.
2 To ensure successful short name resolution, add entries for the WebAccess Agent virtual server
to support your preferred methods of short name resolution, as described in “Configuring Short
Name Resolution” on page 44.
3 Continue with Creating a Domain for the WebAccess Agent.
TM
objects that are created when you cluster-enable a
5.3.2 Creating a Domain for the WebAccess Agent
The WebAccess Agent domain will be a secondary domain. To create it, follow the instructions in
Section 3.3, “Creating a New Secondary Domain in a Cluster,” on page 48, taking your information
from the WebAccess Clustering Worksheet, rather than the System Clustering Worksheet, then return to this point.
novdocx (en) 11 July 2008
Do not create any post offices in the WebAccess Agent domain.
Continue with Installing the MTA for the WebAccess Agent Domain.
5.3.3 Installing the MTA for the WebAccess Agent Domain
The MTA for the WebAccess Agent domain can be installed just like any other MTA in your clustered GroupWise system. Follow the instructions in “Installing the Agent Software in a Cluster”
on page 51, then return to this point.
You do not need to edit the MTA startup file. You do not need to modify the Volume Resource properties until after you have installed the WebAccess Agent.
Continue with Installing and Configuring the WebAccess Agent in a Cluster.
5.3.4 Installing and Configuring the WebAccess Agent in a Cluster
After you have created a domain for the WebAccess Agent and installed the MTA for that domain, you are ready to install and configure the WebAccess Agent.
“Installing the WebAccess Agent Software in a Cluster” on page 95
“Configuring the WebAccess Agent Volume Resource to Load and Unload the WebAccess
Agent and Its MTA” on page 96
94 GroupWise 7 Interoperability Guide
Installing the WebAccess Agent Software in a Cluster
The WebAccess Agent is the component of your WebAccess installation that accesses post offices and libraries to retrieve information for WebAccess client users.
1 Map a drive to the WebAccess Agent volume (WebAccess Clustering Worksheet item 1) where
the WebAccess domain is located.
The WebAccess Agent volume name will be cluster_volume. For assistance with mapping a drive to a cluster-enabled volume, see “Configuring Short Name Resolution” on page 44.
2 If you selected vol:\system on WebAccess Agent volume as the WebAccess Agent
installation location (WebAccess Clustering Worksheet item 7), create the vol:\system directory on the WebAccess Agent volume accessed in Step 1.
or
if you selected sys:\system on each node, decide which node you will install the WebAccess agent to first, then map a drive to its sys:\system directory.
3 Start the WebAccess Installation program and install the NetWare WebAccess Agent, following
Step 1 through Step 5 provided in “Installing the WebAccess Agent” in “Installing GroupWise
WebAccess” in the GroupWise 7 Installation Guide. Keep in mind the following cluster-
specific details:
novdocx (en) 11 July 2008
In the Components dialog box, select only GroupWise WebAccess Agent.
Do not install the WebAccess Application at this time.
Use items 2 through 12 on the GroupWise WebAccess Installation Worksheet that you
filled out in “Planning the WebAccess Installation” on page 92 to fill in the fields during the WebAccess Agent installation process.
In the Network Address dialog box, select Configure GroupWise Agents for Clustering.
In the Installation Path dialog box, be sure to browse through the drive you mapped to the
location you chose in Step 2 above.
In the Gateway Directory dialog box, be sure to browse to the domain directory through
the drive you mapped in Step 1 above.
In the Start Applications dialog box, deselect Start the GroupWise WebAccess Agent.
The WebAccess Installation program creates the strtweb.ncf and stopweb.ncf
files, which include the load and unload commands for the WebAccess Agent. You use this information later when you create the load and unload scripts for the WebAccess Volume Resource object.
4 If you need to install the WebAccess Agent to sys:\system on multiple nodes in the cluster,
repeat Step 4, mapping new drives as needed.
5 Make sure you have completed all the WebAccess Agent tasks described in “NetWare and
Windows: Setting Up GroupWise WebAccess” in “Installing GroupWise WebAccess” in the
GroupWise 7 Installation Guide, but do not start the WebAccess Agent at this time.
6 Continue with Configuring the WebAccess Agent Volume Resource to Load and Unload the
WebAccess Agent and Its MTA.
Implementing WebAccess in a NetWare Cluster 95
Configuring the WebAccess Agent Volume Resource to Load and Unload the WebAccess Agent and Its MTA
novdocx (en) 11 July 2008
The properties of the Volume Resource object define how the WebAccess Agent volume functions
TM
within the cluster, how NLM
programs are loaded and unloaded, and how failover and failback
situations are handled. Complete the following tasks for the WebAccess Agent volume:
“Modifying the Volume Resource Load Script for the WebAccess Agent” on page 96
“Modifying the Volume Resource Unload Script for the WebAccess Agent” on page 98
“Setting the Failover Path and Policies for the WebAccess Agent” on page 99
“Installing and Configuring the WebAccess Application in a Cluster” on page 100
Modifying the Volume Resource Load Script for the WebAccess Agent
The volume resource load script executes whenever the WebAccess Agent volume comes online.
To set up the load script:
1 In ConsoleOne
®
, browse to and select the Cluster object.
If necessary, click View > Conso le View to display its contents.
2 Right-click the Volume Resource object (volume_SERVER), then click Properties > Load to
display the default volume resource load script for the WebAccess Agent volume.
The next step assumes that this is the first time you have edited the load script. If other GroupWise agents are already running from this volume, some of the modifications have already been made.
3 Make the following changes to the default load script:
Remove the trustmig command. It is not necessary to migrate trustees for the
WebAccess Agent volume. Removing this line helps the load script to execute faster.
On NetWare 5.1, if you are using SLP as a short name resolution method, as described in
“Configuring Short Name Resolution” on page 44, add the cvsbind add command for
the WebAccess Agent volume to the load script.
cvsbind add cluster_volume_SERVER IP_address
If you selected vol:\system on WebAccess Agent volume as the installation location
(WebAccess Clustering Worksheet items 5 and 7), add a search add command to add the new vol:\system directory to the server search path.
search add volume:\system
If you selected sys:\system on each node as the installation location (WebAccess
Clustering Worksheet items 5 and 7) but you are storing the MTA startup file on the
WebAccess Agent volume, add that location to the server search path.
If you marked No under Load WebAccess Agent and Its MTA in Protected Memory?
(WebAccess Clustering Worksheet item 9), add the following abend recovery options:
set auto restart after abend = 2 set auto restart after abend delay time = 0 set auto restart down timeout = 60 set developer option = off
These settings provide the best possible handling of GroupWise databases in the event that an abend should occur within the cluster.
96 GroupWise 7 Interoperability Guide
Transfer the MTA load command from the grpwise.ncf file located in the
vol:\system directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text into the load script page. Then delete or rename the grpwise.ncf file to avoid future confusion.
load volume:\system\gwmta.nlm @domain.mta
Add a delay so that the MTA is fully loaded before the WebAccess Agent starts to load:
load delay delay 10
The length of the delay varies from system to system; ten seconds is a good starting place.
Transfer the WebAccess Agent load command from the strtweb.ncf file located in
the vol:\system directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text into the load script page.
load volume:\system\gwinter.nlm /ph=volume:\domain\wpgate\webac70a /user=username /PASSWORD=password
If you marked Yes under Load WebAccess Agent and Its MTA in Protected Memory?
(WebAccess Clustering Worksheet item 9), add the address space parameter to the load commands to specify the protected address space where the WebAccess Agent and its MTA will run. Add a protection restart command for the address space name.
novdocx (en) 11 July 2008
load address space=addr_space_name volume:\system\gwmta.nlm @domain.mta load address space=addr_space_name
volume:\system\gwinter.nlm
/ph=volume:\domain\wpgate\webac70a /user=username /password=password protection restart addr_space_name
The result would look similar to the following example:
Implementing WebAccess in a NetWare Cluster 97
NOTE: The set commands are needed only when the MTA and the WebAccess Agent are not running in protected memory. The address space parameters are needed in the load commands only when the MTA and the WebAccess Agent are running in protected memory.
4 Click Apply to save the load script.
5 If necessary, click OK to confirm that you must offline and then online the volume resource in
order for the changes to take effect.
6 Continue with Modifying the Volume Resource Unload Script for the WebAccess Agent.
Modifying the Volume Resource Unload Script for the WebAccess Agent
The volume resource unload script executes whenever the WebAccess Agent volume goes offline. Programs should be unloaded in the reverse order of how they were loaded. This ensures that supporting programs are not unloaded before programs that rely on them in order to function properly.
To set up the unload script:
1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER),
click Unload to display the default volume resource unload script.
The next step assumes that this is the first time you have edited the unload script. If other GroupWise agents are already running from this volume, some of the modifications have already been made.
2 Make the following changes to the default unload script:
novdocx (en) 11 July 2008
If you marked Yes under Load WebAccess Agent and Its MTA in Protected Memory?
(WebAccess Clustering Worksheet item 9), add an unload address space command and an unload kill address space command to ensure that the address space is completely cleaned up.
unload address space=addr_space_name unload kill address space=addr_space_name
If your system seems to be trying to kill the address space before the WebAccess Agent and its MTA have been completely unloaded, resulting in the agents hanging in the unloading state, set a delay of several seconds before issuing the unload kill address space command to allow the WebAccess Agent and its MTA adequate time to unload completely. The length of the delay varies from system to system; ten seconds is a good starting place.
unload address space=addr_space_name delay 10 unload kill address space=addr_space_name
If you marked No under Load WebAccess Agent and Its MTA in Protected Memory?
(WebAccess Clustering Worksheet items 9), create an unload command parallel to each load command that you placed in the load script.
unload gwinter.nlm unload gwmta.nlm
On NetWare 5.1, if you are using SLP as a short name resolution method, add the
cvsbind del command for the WebAccess Agent volume to the unload script.
98 GroupWise 7 Interoperability Guide
cvsbind del cluster_volume_SERVER ip_address
Remove the trustmig command just like you did in the load script.
The result would look similar to the following example:
novdocx (en) 11 July 2008
3 Click Apply to save the unload script.
4 If necessary, click OK to confirm that you must offline and then online the volume resource in
order for the changes to take effect.
5 Continue with Setting the Failover Path and Policies for the WebAccess Agent.
Setting the Failover Path and Policies for the WebAccess Agent
To modify the failover path and policies for the WebAccess Agent volume resource:
1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER),
click Nodes to display the default failover path for the WebAccess Agent volume resource.
2 Arrange the nodes in the cluster into the desired failover path for the WebAccess Agent volume
(WebAccess Clustering Worksheet item 4).
3 Click Apply to save the failover path.
4 Click Policies to display the default start, failover, and failback policies.
Implementing WebAccess in a NetWare Cluster 99
The default policy settings are often appropriate. By default, a volume resource:
Fails over automatically if the node it is running on fails
Starts automatically on the next node in its failover path
Continues running at its failover location, even after its most preferred node is again
available
If you are considering changing these defaults, see the section about failover and failback mode modes in the clustering documentation for your version of NetWare, as listed in Chapter 1,
“Introduction to GroupWise 7 and Novell Cluster Services on NetWare,” on page 21.
5 Click OK when you are finished editing the WebAccess Agent volume resource properties.
6 Continue with “Installing and Configuring the WebAccess Agent in a Cluster” on page 94.
novdocx (en) 11 July 2008
Installing and Configuring the WebAccess Application in a Cluster
If you have clustered your Web server, you must install the WebAccess Application on each node where the Web server is installed, as described in “Installing the WebAccess Application and
WebPublisher Application” in “Installing GroupWise WebAccess” in the GroupWise 7 Installation
Guide.
5.3.5 Testing Your Clustered WebAccess Installation
Remember that the WebAccess Agent volume resource and the WebAccess Application on your Web server are separate and could fail over to different nodes at different times.
To thoroughly test your WebAccess installation:
1 Make sure the initial combination of WebAccess Agent volume resource and the WebAccess
Application installed on your Web server is functioning properly.
2 Migrate the WebAccess Agent volume resource to each node on its failover path, making sure
it functions with your Web server.
3 If your Web server is clustered, migrate the Web server cluster resource to a different node,
migrate the WebAccess Agent volume resource to each node in the Web server cluster resource failover path, then make sure each combination works.
4 Repeat Step 3 for each Web server cluster resource.
100 GroupWise 7 Interoperability Guide
Loading...