Novell GroupWise. www.novell.com 6.5 INTEROPERABILITY GUIDE October 31, 2005 Novell. 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. Please refer to 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. Copyright © 2003-2005 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 at 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 GroupWise 6.5 Interoperability Guide October 31, 2005 Online Documentation: To access the online documentation for this and other Novell products, and to get updates, see www.novell.com/documentation. Novell Trademarks ConsoleOne is a registered trademark of Novell, Inc. in the United States and other countries. eDirectory is a trademark of Novell, Inc. GroupWise is a registered trademark of Novell, Inc. in the United States and other countries. NDS is a registered trademark of Novell, Inc. in the United States and other countries. NetWare is a registered trademark of Novell, Inc. in the United States and other countries. NLM is a trademark of Novell, Inc. Novell is a registered trademark of Novell, Inc. in the United States and other countries. Novell Client is a trademark of Novell, Inc. Novell Cluster Services is a trademark of Novell, Inc. QuickFinder is a trademark of Novell, Inc. Third-Party Materials All third-party trademarks are the property of their respective owners. Contents About This Guide 11 Part I Novell Cluster Services 1 Introduction to GroupWise 6.5 and Novell Cluster Services 15 2 Planning GroupWise in a Novell Cluster 17 Meeting Software Version Requirements... 2. 0... a a 18 Upgrading to NetWare 6.x n e so kae aa ae a a a a L ale a apa adi Aani e a a a i aa 18 Updating to NetWare 5.1 Support Pack 3 or Higher .. aoaaa aaa ee 18 Installing, Novell'Glustér Services’. s a sa ede Vass See a es ee A a os Sea Sie A E 19 Planning a New Clustered Domain. .... 2... a ee 20 Planning a New Clustered Post Office... 2... 2... 2 a 21 Planning a New Library fora Clustered Post Office ... aoaaa aa a 21 Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise. ..............+.2+0005 21 Ensuring Successful Name Resolution for GroupWise Volumes... a aoaaa a a 23 Deciding How to Install and Configure the Agents ina Cluster... ..........0..0 000002 eee eee 25 Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents inthe Cluster... ......... 25 Determining Appropriate Failover Paths forthe Agents... ..........-. 0.00000 eee ee ee 27 Deciding Where to Install the Agent Software .. 2... a 28 Deciding Whether to Run the Agents in Protected Memory ........... 0-0. ee ee 30 Planning the NetWare Agent Installation... 2... 2... ee 30 GroupWise Clustering Worksheets. oo wo o d eanan oaa a eE aE a e a a a i ea a a SA 32 System Clustering Worksheet... . aoaaa aaa a 32 IP:Address Worksheet: £ 2 5 gence mo Ba eee ke ee a a ke Bae eee a E ali a 34 Agent Clustering Worksheet .. 1... 2 a 35 3 Setting Up a Domain and Post Office in a Novell Cluster 37 Preparing the Cluster for GroupWise»... 20. 26 2 ee Re a ee Ee aaa AnA 37 Ensuring Required Software Versions . .. aoaaa aaa a a 37 Cluster-Enabling Shared Volumes for Use with GroupWise . . aoaaa aa a a 37 Configuring Short Name Resolution . .. 2... aaa a 38 Setting Up a New GroupWise System in a Cluster. .. oaoa ee 40 Creating a New Secondary Domain in a Cluster. . . ooa aa a a a 42 Creating a New Post Office in a Cluster . .. oaoa aaa a 43 Installing and Configuring the MTA and the POAinaCluster... 2... 2... 0.0. 00. ee 44 Installing the Agent Software ina Cluster... oaoa aa a 45 Editing Clustered Agent Startup Files... . aoaaa aa ee 45 Configuring the GroupWise Volume Resource to Load and Unload the Agents ...................-,4 46 Setting Up New Instances of the Agents without Installing the Agent Software .................., 51 Testing Your Clustered GroupWise System... 2... 2... a 53 Managing Your Clustered GroupWise System. . 2. 2... a 54 Updating GroupWise Objects with Cluster-Specific Descriptions... ... 2.0.2... 0... 00000 ee eee 54 Using NetWare Remote Manager on NetWare 6.x... aoaaa aa a 55 Knowing What to Expect in MTA and POA Failover Situations. ................222.22 00000. 58 What's Next: o co hoe donk ee be ehh Se eee eb ea dy Bo ob kb eed ade ee he 58 Contents 5 Clustering Quick Checklists... is s sde uc paari moi Gea p ee ee eee be 59 GroupWise System Quick Checklist... aoaaa a a 59 Domain Quick: Checklist < 2... foe. we rok ay ee ek ee ee ae ee Se ee Re ee Ee 60 Post Office Quick:Chécklist=.,-.924h ite we aE Bah A ae, A Re ie Red tee aE ee ek ie Ee 61 Implementing the Internet Agent in a Novell Cluster 63 Planning the Internet Agent ina Cluster... 2... aaa a 63 Planning a Domain for the Internet Agent... aoaaa aaa a 64 Deciding Whether to Cluster-Enable the Internet Agent Volume ............ 000000 eee ee es 64 Determining an Appropriate Failover Path for the Internet Agent Volume... ............-..-00004 64 Planning a Secondary IP Address and Cluster-Unique Port Numbers for the Internet Agent and Its MTA... ... 65 Preparing Your Firewall for the Internet Agent... oaoa aaa a a 65 Deciding Where to Install the Internet Agent and Its MTA... aoaaa aaa a 66 Deciding Whether to Run the Internet Agent and Its MTA in Protected Memory .............-..+..-4 66 Planning the MTA Installation... 2. . .s cee ee ee eR be ee ee ee ee 66 Planning the Internet Agent Installation . . . oa aaa a 66 Setting Up the Internet Agent in a Cluster... 2... aaa 67 Cluster-Enabling a Shared Volume for Use with the Internet Agent... aoaaa aa a 67 Creating a Domain for the Internet Agent... 2... a a 68 Installing the MTA for the Internet Agent Domain... . aaa aa a 68 Installing and Configuring the Internet Agent in a Cluster . . . aoaaa a 68 Testing the Clustered Internet Agent .: . < «e cs aoccoeaa a cca ca daada inad arare arka 75 Managing the Internet Agent in a Cluster... 2... ee 76 Updating GroupWise Objects with Cluster-Specific Descriptions . . . aoo aa a a 76 Knowing What to Expect in an Internet Agent Failover Situation . . . aoaaa aaa a 77 Internet Agent Clustering Worksheet . . oaoa aaa a 78 Internet Agent-Quick:Checklist 2... cu eee ta pa toa t ia be a ba Ta aMi hA ee 80 Implementing WebAccess in a Novell Cluster 83 Understanding the WebAccess Components... aooaa aa a a 83 Planning WebAccess in a Cluster... oaoa aaa 83 Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6 .............. 84 Planning a New Domain for the WebAccess Agent... aoaaa a 85 Deciding Whether to Cluster-Enable the WebAccess Agent Volume . . aoaaa a a a a a a a 85 Determining an Appropriate Failover Path for the WebAccess Agent Volume . . aoao a a a 85 Planning a Secondary IP Address and Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA. . . . 86 Deciding Where to Install the WebAccess Agent and Its MTA ........0..0 0.00 0 eee 86 Deciding Whether to Run the WebAccess Agent and Its MTA in Protected Memory. ................ 86 Planning the MTA Installation... 2... a 87 Planning the WebAccess Installation . . . 2... aaa a 87 Setting: Up WebAccess ina Clusteri 0... 2 A e ee ee a ee ee ee ee E a a 88 Cluster-Enabling a Shared Volume for Use with the WebAccess Agent ............. 000000 e ae 88 Creating a Domain for the WebAccess Agent... oaoa oaa a 89 Installing the MTA for the WebAccess Agent Domain... aao a 89 Installing and Configuring the WebAccess Agent in a Cluster... ..... aa 002.002 eee ee ee 89 Installing and Configuring the WebAccess Application in a Cluster... 2... 0... a 20 2000 G 95 Testing Your Clustered WebAccess Installation. . . 2... 96 Managing WebAccess ina Cluster... 2. 2 aaa a 96 Updating GroupWise Objects with Cluster-Specific Descriptions ............ 0.00000 eee ee 96 Knowing What to Expect in WebAccess Failover Situations... . . 2... aa a a 97 Updating the WebAccess Agent Configuration File (commgr.cfg).... 2... eaa a 98 WebAccess Clustering Worksheet .. aoaaa aaa a 99 WebAccess QuickChecklista neust s a u BR et a Be eel me ee om Sed E a A 101 Implementing GroupWise Gateways in a Novell Cluster 103 Monitoring a GroupWise System in a Novell Cluster 105 GroupWise 6.5 Interoperability Guide Backing Up a GroupWise System in a Novell Cluster with the GroupWise TSA 107 Moving an Existing GroupWise 6.5 System into a Novell Cluster 109 Implementing Messenger in a Novell Cluster 111 Planning Your Messenger SysteminaCluster............. a 111 Understanding Your Cluster... 2... 2. ee 111 Planning Messenger Administration ...... 2... 2 a ee 111 Deciding Where to Install the Messenger Agent Software ............... 0000000 eee eee 112 Planning the Messenger Agent Installation. ... 2... a aa 114 Setting Up Your Messenger System in a Cluster... oa aaa a a 114 Installing to Each Node in the Cluster. .. . oaoa oa aa a 2 ee 115 Installing to a Messenger Volume... .. aa oaa aaa ee 115 Messenger Clustering Worksheet .. 2... ee 119 Part II GroupWise DirXML Driver for Novell Identity Manager 11 Identity Manager Warnings in ConsoleOne 123 Recovering a Deleted GroupWise Account... . oaoa a 123 Grafting USerS y aa eu e aga a ataga ap D PO DAEAR ee ee Bape beens Se D E he a a A 123 Converting an External Entity to a User . .. oaoa a 124 Converting a User to an External Entity . . . o.a aa 0.00 2 124 Associating a GroupWise Object with an eDirectory Object . . . o ooa aaa a a a 124 Disassociating a GroupWise Object’s Attributes from an eDirectory Object . . . ooa oaa a a 124 Resolving an Invalid Association. . . . oaoa ee 124 Disabling the DirxXML Warnings ..... 2... 2 a a a a ee 124 Enabling the DirXML Warnings. ..... 2... a a 125 Part Ill GroupWise Customization Tools Part IV Microsoft Clustering Services 12 13 14 Introduction to GroupWise 6.5 and Microsoft Clusters 131 Planning GroupWise in a Microsoft Cluster 133 Setting Up Your Microsoft Cluster... sa ioe n a aea a a a ene i a a E G a o e a E a i e 134 Planning a New Clustered Domain... a. aoaaa aaa a 134 Planning a New Clustered Post Office... aoaaa a 135 Planning a Library for a New Clustered Post Office .... 2... 0... 2. ee 135 Planning GroupWise Resource Groups ... 1... a 136 Planning Shared Administrative Resources .. 2...) 137 Ensuring Successful Name Resolution for GroupWise Resource Groups... ........... 0000+ eee 137 Deciding How to Install and Configure the Agents ina Cluster. . 2... 2... 2... 00. ee ee 139 Planning Cluster-Unique Port Numbers for Agents inthe Cluster .................-0 200004 139 Deciding Where to Install the Agent Software . .. oaao aa a 141 Planning the:Agent'ServiceS: 3.2.06 ge maoa Re ew PR BO oe BO BR a a Bok A 142 Planning the Windows Agent Installation. ... 2... a 143 GroupWise Clustering Worksheets. . 2... 1. aa a a 144 System Clustering Worksheet... . oaoa aa ee 144 Network Address Worksheet... sos e s c ern coece edeni e e E e aa e a E ea E ee E e e o A 146 Agent Clustering Worksheet . . aoaaa aaa a 147 Setting Up a Domain and Post Office in a Microsoft Cluster 149 Preparing the Cluster for GroupWise... 2. e e oroi piba ia E O ee 149 Creating GroupWise Resource Groups. .. 2... a 149 Creating Agent Service Resources. e o aien e roe ala ae E E e a E a e E E oeae ORR EE oe 149 Configuring Short Name Resolution . . aoao a a 150 Setting Up a New GroupWise System in a Cluster. .. 2... 151 Contents 7 15 16 17 Creating a New Secondary Domain in a Cluster ... oaoa aaa L Creating a New Post Office in a Cluster... . . ooa a Installing and Configuring the MTA and the POA in a Cluster. . aaa ee Installing the Agent Software in a Cluster... 2... aa a Editing Clustered Agent Startup Files... aoaaa aa a Setting Up New Instances of the Agents without Installing the Agent Software. . . aoaaa aaa Testing Your Clustered GroupWise System... 2... aa a Managing Your Clustered GroupWise System . .. aoaaa aa a Updating GroupWise Objects with Cluster-Specific Descriptions . . . a aoao aa a a a Knowing What to Expect in MTA and POA Failover Situations ... . aoao a aaa a Whats:Next o oe 258 Sig pore wt e a heel ea ee acetal a e am ror pE TTE a E OA es Implementing the Internet Agent in a Microsoft Cluster Planning the Internet Agent ina Cluster... 2... aaa a a Planning a Domain for the Internet Agent... 2... aaa a Planning the Internet Agent Resource Group... 2. 1. a a Planning Cluster-Unique Port Numbers for the Internet Agent and Its MTA... .............2.00. Preparing Your Firewall for the Internet Agent... oaoa aaa a Deciding Where to Install the Internet Agent and Its MTA... 2... aa aaa a Planning the MTA Installation < ses s eoe e ee. Bk eee e DE Bh Rl eee oe ee ee A Planning the Internet Agent Installation . . . 2... a Setting Up the Internet Agent in a Cluster... 2... aaa Setting Up the Internet Agent Resource Group... 2. 1 a a a Creating a Domain for the Internet Agent... aoaaa aaa a Installing the MTA for the Internet Agent Domain... . 2... a a Installing and Configuring the Internet Agent ina Cluster... ....... 0... 2.00000 2 eee ee ee Testing the Clustered Internet Agent .. aoaaa aa a Managing the Internet Agent in a Cluster... oa aaa aa a Updating GroupWise Objects with Cluster-Specific Descriptions . . . aoao aa a a a Knowing What to Expect in an Internet Agent Failover Situation . . . aoaaa a Internet Agent Clustering Worksheet . . 2. 0. a a Implementing WebAccess in a Microsoft Cluster Understanding the WebAccess Components... aooaa e a Planning WebAccess in a Cluster... aoa aaa a Setting Up Your Web Server in the Microsoft cluster... 2... aaa a Planning a New Domain for the WebAccess Agent... oaoa a a a a Planning the WebAccess Resource Group . . oaoa a a Planning Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA .................-. Deciding Where to Install the WebAccess Agent and Its MTA .. nanana aa a Planning; the:MTA-Installation:.:.. 3. a SA eh Ne ee Sa LR er a a ana a S T ELE Ls Planning the WebAccess Installation .... oaoa oa a a Setting Up WebAccess inaCluster.... oaoa aa a Setting Up the WebAccess Resource Group .. oaoa a a Creating a Domain for the WebAccess Agent... o aoaaa a a Installing the MTA for the WebAccess Agent Domain... aoa oaa e a Installing the WebAccess Agent in a Cluster ............. a Installing and Configuring the WebAccess Application in a Cluster... a. oaoa aaa a a Testing Your Clustered WebAccess Installation... . o.oo a a Managing WebAccess in a Cluster... oaoa aaa a Updating GroupWise Objects with Cluster-Specific Descriptions . . . . oaoa o a a a a a Knowing What to Expect in WebAccess Failover Situations. . . . o. oaoa aa a a a Updating the WebAccess Agent Configuration File (commgr.cfg).... aooaa ea a a WebAccess Clustering Worksheet . . 2... oaoa a a a a Implementing GroupWise Gateways in a Microsoft Cluster GroupWise 6.5 Interoperability Guide 18 Monitoring a GroupWise System in a Microsoft Cluster 19 Backing Up a GroupWise System in a Microsoft Cluster 20 Moving an Existing GroupWise 6.5 System into a Microsoft Cluster 21 Implementing Messenger in a Microsoft Cluster Planning Your Messenger SysteminaCluster............. a Understanding Your Cluster... sc ei seor een ee Planning Messenger Administration .. . aoaaa aaa a Deciding Where to Install the Messenger Agent Software . . oaoa oaa aaa a Planning the Messenger Agent Installation... 2... a Setting Up Your Messenger SysteminaCluster............0. 0000 0 eee ee Installing the Messenger Agents to Each Node inthe Cluster... .......... 2.000.000 02 eae Installing the Messenger Agents toa Shared Disk... 2... 2 a a Messenger Clustering Worksheet . . ii cee ee aa Darau Part V Non-GroupWise Clients 22 Outlook Express 23 Microsoft Outlook 24 Mobile Devices Prerequisites for PDA Connect 1.0. .. a aaa 0.0. ee Downloading Required Software... 2... ee Downloading GroupWise 6.5.3 2... aaa a Downloading GroupWise PDA Connect 1.0... 2... 0.0. 2 a Third=Party Partners: inen $k eo eac en ee ee ee a we ee eee os ek Part VI Unsupported Web Servers 25 Installing WebAccess to Unsupported Web Servers 185 187 189 191 191 191 191 192 193 194 194 194 196 199 201 203 203 203 203 204 204 207 26 Configuring WebAccess to Use a Java Servlet Engine Other Than the Novell Servlet Gateway or Tomcat Serviet Engine 209 Part VII Documentation Updates October:34:2005 «tee A ns oe AE EAE ROR OE a BO OR A ee EP ow E a September 19 2005 (GroupWise 6.5 SP5). 2... aaa a January 315: 2005 tse on ree he SR ce ee eh ar ees as ee He eS E a Lee Bade the November 30, 2004 (GroupWise 6.5SP3). 2... 0. a September 30; 2004 z oe eg Saleh Qo BeOS ee ae RE bh ee Ed ek he ae a RS Séptember:30;: 2003-2 myos een ee a ee See as BAe BOE oe ce SO woes See e ee ee SE Bek eee Y Contents 9 10 GroupWise 6.5 Interoperability Guide About This Guide This Novell® Group Wise® 6.5 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 + “Novell Cluster Services” on page 13 + “GroupWise DirXML Driver for Novell Identity Manager” on page 121 + “GroupWise Customization Tools” on page 127 Third-Party Products + “Microsoft Clustering Services” on page 129 + “Non-GroupWise Clients” on page 197 For information about additional Group Wise-related software from Group Wise partners, see the Group Wise Partners Web site (http://www.novell.com/products/groupwise/partners). Additional Documentation For additional GroupWise documentation, see the following guides at the Novell GroupWise 6.5 documentation Web site (http://www.novell.com/documentation/gw65): ¢ Installation Guide + Administration Guide + Multi-System Administration Guide ¢ Troubleshooting Guides + GroupWise Client User Guides Documentation Updates For the most recent version of the GroupWise 6.5 Interoperability Guide, visit the Novell Group Wise 6.5 documentation Web site (http://www.novell.com/documentation/gw65). Documentation Conventions In Novell documentation, a greater-than symbol (>) is used to separate actions within a step and items within a cross-reference path. A trademark symbol (™, e etc.) denotes a Novell trademark. An asterisk denotes a third-party trademark. About This Guide 11 User Comments 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. 12 GroupWise 6.5 Interoperability Guide Novell Cluster Services Chapter 1, “Introduction to GroupWise 6.5 and Novell Cluster Services,” on page 15 Chapter 2, “Planning GroupWise in a Novell Cluster,” on page 17 Chapter 3, “Setting Up a Domain and Post Office in a Novell Cluster,” on page 37 Chapter 4, “Implementing the Internet Agent in a Novell Cluster,” on page 63 Chapter 5, “Implementing WebAccess in a Novell Cluster,” on page 83 Chapter 6, “Implementing GroupWise Gateways in a Novell Cluster,” on page 103 Chapter 7, “Monitoring a GroupWise System in a Novell Cluster,” on page 105 Chapter 8, “Backing Up a GroupWise System in a Novell Cluster with the GroupWise TSA,” on page 107 Chapter 9, “Moving an Existing GroupWise 6.5 System into a Novell Cluster,” on page 109 Chapter 10, “Implementing Messenger in a Novell Cluster,” on page 111 Novell Cluster Services 13 14 GroupWise 6.5 Interoperability Guide Introduction to GroupWise 6.5 and Novell Cluster Services Before implementing GroupWise® 6.5 with Novell® Cluster Services™, 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://support.novell.com/techcenter/ articles/anal9990501.html) + NetWare 6 Product Documentation: Novell Cluster Services (http://www.novell.com/ documentation/lg/ncs6p/index.html) + NetWare 5.1 Product Documentation: Novell Cluster Services (http://www.novell.com/ documentation/lg/ncs/index.html) 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 two to 32 NetWare® servers configured using Novell Cluster Services so that data storage locations and applications can transfer from one server to another without interrupting their availability to users. 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 would fail over to a secondary node so that users could 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 could be configured to fail over separately to different secondary nodes. 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. Introduction to GroupWise 6.5 and Novell Cluster Services 15 16 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. cluster-enabled shared volume: A shared volume for which a Volume Resource object has been 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 Group Wise. 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/active mode is also recommended when configuring the Netscape* Enterprise Server* for use with GroupWise WebAccess. 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. GroupWise 6.5 Interoperability Guide Planning GroupWise in a Novell Cluster The majority of this part of the GroupWise 6.5 Interoperability Guide (Chapter 2, “Planning Group Wise in a Novell Cluster,” on page 17 through Chapter 8, “Backing Up a Group Wise System ina Novell Cluster with the GroupWise TSA,” on page 107) is designed for those who are creating anew GroupWise® system, or at least new domains and post offices, in the context of Novell® Cluster Services™. If you already have an existing Group Wise 6.5 system and need to configure it to work in a newly installed cluster, see Chapter 9, “Moving an Existing GroupWise 6.5 System into a Novell Cluster,” on page 109. 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 6.5 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 + Anew post office + The GroupWise agents (MTA and POA) During the planning process, component configuration alternatives will be 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 32 lists all the information you will 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: + “Meeting Software Version Requirements” on page 18 + “Installing Novell Cluster Services” on page 19 + “Planning a New Clustered Domain” on page 20 + “Planning a New Clustered Post Office” on page 21 + “Planning a New Library for a Clustered Post Office” on page 21 + “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21 + “Ensuring Successful Name Resolution for GroupWise Volumes” on page 23 ¢ “Deciding How to Install and Configure the Agents in a Cluster” on page 25 + “GroupWise Clustering Worksheets” on page 32 Planning GroupWise in a Novell Cluster 17 After you have completed the tasks and filled out the “System Clustering Worksheet” on page 32, you will be ready to continue with Chapter 3, “Setting Up a Domain and Post Office in a Novell Cluster,” on page 37. Meeting Software Version Requirements Group Wise 6.5 can be clustered on a system that meets the following requirements: + GroupWise 6.5 + NetWare® 6 or NetWare 5.1 with Support Pack 3 or higher 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. As needed, update the servers that will become part of the cluster you are preparing for your GroupWise system. + “Upgrading to NetWare 6.x” on page 18 + “Updating to NetWare 5.1 Support Pack 3 or Higher” on page 18 Upgrading to NetWare 6.x If you are implementing clustering for the first time in your system, you might want to take the opportunity to upgrade to NetWare 6.x at the same time. You can purchase NetWare 6.x at NetWare 6: How to Buy (http://www.novell.com/products/netware/howtobuy.html). Updating to NetWare 5.1 Support Pack 3 or Higher If you are still running NetWare 5.0 or earlier and do not want to upgrade to NetWare 6.x, you must update all nodes in the cluster to NetWare 5.1 in order to run GroupWise in the cluster. You can purchase NetWare 5.1 at shopNovell (http://shop.novell.com). After NetWare 5.1 is installed on all the nodes in the cluster, you must install NetWare 5.1 Support Pack 3 or higher. It includes changes that benefit the combination of NetWare 5.1 and Group Wise 6.5. You can download NetWare 5.1 Support Pack 4 from TID 2961624: NetWare 5.1 Support Pack 4 (http://support.novell.com/servlet/tidfinder/296 1624). Updating to the Latest ConsoleOne Snap-In If you are using NetWare 5.1 with Support Pack 3, it is highly recommended that you download the latest ConsoleOne® snap-in for Novell Cluster Services. It includes changes that enable you to modify cluster-related object names. You can download the latest snap-in, along with the version of ConsoleOne that supports it, from Novell Software Downloads (http://download.novell.com/ sdMain.jsp). 18 GroupWise 6.5 Interoperability Guide Installing Novell Cluster Services Install Novell Cluster Services by following the instructions provided in NetWare Cluster Services Overview and Installation for your version of NetWare: + NetWare 6.x: “Installation and Setup” + NetWare 5.1: “Installation and Setup” 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 Group Wise domains and post offices and install the Group Wise 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. 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. The number of nodes and shared volumes that are available in the cluster will strongly influence 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. + Inalike manner, WebAccess provides user access to GroupWise mailboxes across the Internet through users’ Web browsers. It is another good candidate for clustering. Planning GroupWise in a Novell Cluster 19 + 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. + 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. 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 Group Wise 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 6.5 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 6.5 Administration Guide. 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 Group Wise 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 Group Wise 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. 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 Novell Cluster,” on page 37. 20 GroupWise 6.5 Interoperability Guide 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 Group Wise 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 6.5 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 Novell Cluster,” on page 37. 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 6.5 Administration Guide and filling out the “Basic Library Worksheet” or the “Full- Service Library Worksheet”. 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 Novell Cluster,” on page 37. Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise Cluster-enabling the shared volumes where domains and post offices reside greatly simplifies Group Wise 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 and for the GroupWise software distribution directory so that these locations are always available within Planning GroupWise in a Novell Cluster 21 the cluster. To review the concept of cluster-enabled shared volumes, see the applicable section of Novell Cluster Services Overview and Installation for your version of NetWare: + + NetWare 6.x: “Cluster Enable Pools and Volumes” NetWare 5.1: “Cluster-Enable Volumes ” 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 will always be able to 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 will 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 will always be able to 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. When you cluster-enable a volume, additional eDirectory objects will be created: eDirectory Object Name and Description Object clustername_volumename (default object name) A new Volume object will represent the cluster-enabled volume. It will be 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 would be named gwcluster_gwvol1. clustername_volumename_SERVER (default object name) A new Server object will represent 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 would be named GWCLUSTER_GWVOL1_SERVER. ap volumename_SERVER.clustername (default object name) A new Volume Resource object will store 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 would be 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 22 GroupWise 6.5 Interoperability Guide requirements described in “Meeting Software Version Requirements” on page 18, you will be able to 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. 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 will need to 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. 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. 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™ that is installed on the Windows workstation: Planning GroupWise in a Novell Cluster 23 24 Novell Client for Windows 2000 Properties 2)x) Single Sign-on | Advanced Settings | Advanced Menu Settings | Client | Location Profiles | Advanced Login | Contextless Login | Protocol Preferences | Service Location Select a protocol and component to configure Preferred Network Protocol: = Protocol: m n Protocol component settings- MINDS M Host File MIDNS Z SLP CO DHCP NDS DHCP Settings | Default Capture | Component: Short name resolution methods that pertain to clustering your GroupWise system are discussed below: Short Name Resolution Method eDirectory Hosts Files DNS Description 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. Windows uses the following files when performing short name resolution at the workstation: + Windows NT/2000/XP: \winnt\system32\drivers\etc\hosts + Windows 9.x: \novell\client32\nwhosts 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. 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 support.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, as described in “Updating to the Latest ConsoleOne Snap-In” on page 18, so that you can change cluster-related object names as needed to remove the underscore characters. GroupWise 6.5 Interoperability Guide Short Name Description Resolution Method 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 Novell Cluster,” on page 37. SYSTEM CLUSTERING WORKSHEET Under Item 9: IP Address Resolution Methods, mark which methods you want to implement in order to resolve the locations stored as UNC paths in ConsoleOne into physical network addresses in your system. 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: + “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 25 + “Determining Appropriate Failover Paths for the Agents” on page 27 + “Deciding Where to Install the Agent Software” on page 28 + “Deciding Whether to Run the Agents in Protected Memory” on page 30 + “Planning the NetWare Agent Installation” on page 30 Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster The Group Wise 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 34 to help you plan secondary IP addresses and cluster-unique port numbers for all GroupWise agents. The following filled-out version of the IP Address Worksheet illustrates one way this can be done: Planning GroupWise in a Novell Cluster 25 Domain Information MTA MTA MTA IP Address MTP Port HTTP Port 123.45.67.81 7100 7180 Post Office Information Post Office POA POA POA POA IP Address C/S Port MTP Port HTTP Port | Development | (same as MTA) | as MTA) 677 | maoo Aa Po ee ee ca SS Internet Agent Information Internet oe GWIA MTA MTA Live MTA GWIA aoe le Address MTP Port | Remote Port HTTP Port! HTTP Port GWIA Domain 123.45.67.83 7110 7677 7183 MTA Internet Agent (same as MTA) 9850 (GWIA) WebAccess Information WebAccess Agent | WebAccess MTA MTA WebAccess WebAccess IP Address MTP Port | HTTP Port | Agent Port HTTP Port WebAccess 123.45.67.84 7120 7184 N/A N/A Domain MTA WebAccess (same as MTA) N/A N/A 7205 7205 Agent (same as agent) (GWINTER) This example places the Development post office on the same node and on the same GroupWise volume with the Provol domain; therefore, the Provol 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 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 26 GroupWise 6.5 Interoperability Guide 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 6.5 Administration Guide. IP ADDRESS WORKSHEET Fill out the “IP Address Worksheet” on page 34 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). 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 will be 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 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. Determining Appropriate Failover Paths for the Agents By default, a Group Wise 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. Ifa 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 Group Wise 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 Group Wise client users should never fail over to a node where another very large post office and Planning GroupWise in a Novell Cluster 27 heavily loaded POA reside. If they did, users on both post offices would notice a decrease in responsiveness of the Group Wise 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. Deciding Where to Install the Agent Software 28 When you install the NetWare MTA and POA in a clustering environment, you can choose between two different installation locations: Location Description sys:\system This is the default location provided by the Agent Installation program. Because on each node the agents must be installed on each node where they might need to run during in the cluster a failover situation, you would 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 If you create a vol:\system directory on a GroupWise volume, the agent software on each GroupWise and startup files fail over and back with the domains and post offices that the volume agents service. Unless you have a very small GroupWise system with all domains and post offices on a single GroupWise volume, you will 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 29 ¢ “Disadvantages of a vol:\system Directory on Each GroupWise Volume” on page 29 + “Recommendation” on page 29 GroupWise 6.5 Interoperability Guide 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. + 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. + Ifyou 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 Group Wise 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 Recommendation Installing the agents on a GroupWise volume does have some disadvantages: + GroupWise administrators who are used to the Group Wise 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. Whichever method you choose, be consistent throughout the entire cluster. Either put all the Group Wise 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 Novell Cluster 29 Deciding Whether to Run the Agents in Protected Memory Ona NetWare server, using protected memory allows you to create isolated memory spaces where NLM programs can run without affecting other NLM programs running on the same node. This contributes to the high availability of the cluster. Using protected memory has the following advantages: + 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. ¢ Ifyou use protected memory, you can run the agents in active/active mode, rather than active/ passive mode. 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. 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. If you load the MTA and the POA in different memory spaces, the agent engine (gwenn4.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: We strongly recommend that you run the agents in protected memory, with one agent per memory space, for optimum stability. 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 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 30 GroupWise 6.5 Interoperability Guide 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 6.5 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. Ina 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 28. 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. Under Item 6: Domains and Item 7: Post Offices, refer to the Domain and Post Office Worksheets you filled out during “Planning a New Clustered Domain” on page 20 and “Planning a New Clustered Post Office” on page 21, 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 25. 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 Novell Cluster,” on page 37. Continue with Chapter 3, “Setting Up a Domain and Post Office in a Novell Cluster,” on page 37. Planning GroupWise in a Novell Cluster 31 GroupWise Clustering Worksheets ¢ “System Clustering Worksheet” on page 32 + “IP Address Worksheet” on page 34 + “Agent Clustering Worksheet’ on page 35 System Clustering Worksheet Item 1) Software Version Updates Explanation Mark any updates the nodes in your cluster need in order to meet the system for Cluster: + NetWare 5.1 Support Pack 3 or higher ¢ Latest ConsoleOne Snap-In for Novell Cluster Services 2) eDirectory Tree for Cluster: 3) Cluster Name: Cluster IP Address: 4) Cluster Context: 5) Nodes in Cluster 6) Shared Volumes for GroupWise Administration: Cluster Enabled? + Yes (highly recommended) Cluster volume IP addresses + No GroupWise Administration Snap-ins to ConsoleOne + public directory + Other GroupWise Software Distribution Directory + \grpwise\software directory + Other 32 GroupWise 6.5 Interoperability Guide requirements for a GroupWise system in a cluster. For more information, see “Meeting Software Version Requirements” on page 18. Record the eDirectory tree where you created the new Novell Cluster object when you installed Novell Cluster Services. For more information, see “Installing Novell Cluster Services” on page 19 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 “Installing Novell Cluster Services” on page 19. Record the full context where you created the new NetWare Cluster object. For more information, see “Installing Novell Cluster Services” on page 19. List the nodes that are part of the cluster that you set up for your GroupWise system. For more information, see “Installing Novell Cluster Services” on page 19. 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 “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21. Item 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) 10) Domain Name: Domain Database Location: 11) Post Office Name: Post Office Database Location: 12) Document Storage Area Location: + At the post office + Outside the post office + Separate post office Document Storage Area Access + POA /user startup switch setting + POA /password startup switch setting Explanation Specify the name (c/uster_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 “Planning a New Clustered Post Office” on page 21 and “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21. Specify the name (c/uster_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 “Planning a New Clustered Post Office” on page 21 and “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise’ on page 21. 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 “Ensuring Successful Name Resolution for GroupWise Volumes” on page 23 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 “Planning a New Clustered Domain” on page 20. 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 “Planning a New Clustered Post Office” on page 21. If you need a library for a clustered post office, mark where you want to create its document storage area and provide a directory if necessary. For more information, see “Planning a New Library for a Clustered Post Office” on page 21. Planning GroupWise in a Novell Cluster 33 IP Address Worksheet Domain Information MTA MTA MTA IP Address MTP Port HTTP Port Post Office Information Post Office POA POA POA POA IP Address C/S Port MTP Port HTTP Port Internet Agent Information Internet Agent GWIA MTA MTA MTA GWIA IP Address MTP Port Live Remote Port HTTP Port HTTP Port | GWIA Domain MTA | Domain Ma Internet = a (GWIA) WebAccess Information WebAccess Agent | WebAccess MTA MTA WebAccess Agent WebAccess IP Address MTP Port HTTP Port Port HTTP Port WebAccess N/A N/A Domain MTA WebAccess Agent | (same) N/A N/A (GWINTER) 34 GroupWise 6.5 Interoperability Guide Agent Clustering Worksheet Item 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: 3) Domain Failover Path: 4) MTA Network Information: + MTA IP address + MTA message transfer port + MTA HTTP port 5) Post Office Name: Post Office Location: 6) Post Office Failover Path: 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 Explanation 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 28. Transfer this information from the System Clustering Worksheet (item 10). 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 27. Gather the MTA network address information from the “IP Address Worksheet” on page 34. For more information, see “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 25. Transfer this information from the System Clustering Worksheet (item 11). List other nodes in the cluster where the GroupWise post office and its POA could fail over. For more information, see “Determining Appropriate Failover Paths for the Agents” on page 27. Gather the POA network address information from the “IP Address Worksheet” on page 34. For more information, see “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 25. 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. IMPORTANT: We strongly recommend that you run the agents in protected memory, with one agent per memory space, for optimum stability. For more information, see “Deciding Whether to Run the Agents in Protected Memory” on page 30. Planning GroupWise in a Novell Cluster 35 36 GroupWise 6.5 Interoperability Guide Setting Up a Domain and Post Office in a Novell Cluster You should have already reviewed “Planning GroupWise in a Novell Cluster” on page 17 and filled out the “System Clustering Worksheet” on page 32, the “IP Address Worksheet” on page 34, and the “Agent Clustering Worksheet” on page 35. You are now ready to complete the following tasks to set up GroupWise® in a clustering environment: + “Preparing the Cluster for GroupWise” on page 37 + “Setting Up a New GroupWise System in a Cluster” on page 40 + “Creating a New Secondary Domain in a Cluster” on page 42 + “Creating a New Post Office in a Cluster” on page 43 + “Installing and Configuring the MTA and the POA in a Cluster” on page 44 + “Testing Your Clustered GroupWise System” on page 53 + “Managing Your Clustered GroupWise System” on page 54 + “What’s Next” on page 58 + “Clustering Quick Checklists” on page 59 Preparing the Cluster for GroupWise After you have installed Novell® Cluster Services™, as described in Novell Cluster Services Overview and Installation, complete the following tasks to prepare the cluster for your Group Wise system: + “Ensuring Required Software Versions” on page 37 + “Cluster-Enabling Shared Volumes for Use with GroupWise” on page 37 + “Configuring Short Name Resolution” on page 38 Ensuring Required Software Versions Double-check each node in the cluster to make sure it meets the requirements described in “Meeting Software Version Requirements” on page 18. Cluster-Enabling Shared Volumes for Use with GroupWise To cluster-enable a shared volume for use with Group Wise: 1 Select a System Clustering Worksheet item (6, 7, or 8) where you selected Yes under Cluster Enabled?. Setting Up a Domain and Post Office in a Novell Cluster 37 2 Complete the steps in the applicable section of Novell Cluster Services Overview and Installation for your version of NetWare®: + NetWare 6.x: “Cluster Enable Pools and Volumes” + NetWare 5.1: “Cluster-Enable Volumes ” The System Clustering Worksheet provides the volume to cluster-enable for use the Group Wise, the cluster-enabled volume IP address, and the failover path for the Group Wise volume. For a review of the new Novell eDirectory™ objects that are created when you cluster-enable a shared volume, see “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21. If you have installed the latest version of ConsoleOne® and the Novell Cluster Services snap- in, as described in “Updating to the Latest ConsoleOne Snap-In” on page 18, you will be able to rename the cluster-related objects in case your DNS name server cannot resolve object names that include the underscore (_) character. 3 Repeat Step | 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” on page 38. Configuring Short Name Resolution eDirectory 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): + “eDirectory” on page 38 + “Hosts Files” on page 39 + “DNS” on page 39 + “SLP” on page 40 After configuring your selected short name resolution methods, continue with the task you need to perform: + “Setting Up a New GroupWise System in a Cluster” on page 40 + “Creating a New Secondary Domain in a Cluster” on page 42 + “Creating a New Post Office in a Cluster” on page 43 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 would 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 38 GroupWise 6.5 Interoperability Guide Hosts Files DNS 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. 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 NT/2000: \winnt\system32\drivers\etc\hosts (on the administrator’s workstation only; optional) + Windows 9.x: \novell\client32\nwhosts (on the administrator’s workstation only; optional) The lines you add to a hosts file could look similar to the following example (all on one line, of course): 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. Example: 123.45.67.81 gwcluster gwvoll SERVER.gwcluster.com gwcluster_gwvoll 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. 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: = \\gwvoll_SERVER.gwcluster.com\gwvoll Setting Up a Domain and Post Office in a Novell Cluster 39 SLP Or, if the ConsoleOne workstation is in the same DNS domain as the GroupWise volume: Syntax: map drive: = \\volume_SERVER\volume Example: map m: = \\gwvoll_ SERVER\gwvoll 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. 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://support.novell.com/cgi-bin/search/searchtid.cgi?/2957434.htm). Install CVSBIND according to the instructions included with the download, then determine the server-specific commands you will need to use with CVSBIND. 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 gwvoll SERVER 123.45.67.81 cevsbind del gwcluster gwvoll SERVER 123.45.67.81 Later, in “Modifying the Volume Resource Load Script for the Agents” on page 46 and “Modifying the Volume Resource Unload Script for the Agents” on page 48, you will need to add the cvsbind commands to the load and unload scripts for GroupWise volume resources. Setting Up a New GroupWise System in a Cluster 40 The Group Wise 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 Ifnecessary, map a drive to each GroupWise administration volume (System Clustering Worksheet item 6). 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. GroupWise 6.5 Interoperability Guide 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 38. 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 will be 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 “Setting Up a Basic GroupWise System on NetWare or Windows” in “Installing a Basic GroupWise System” in the GroupWise 6.5 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 Group Wise volume accessed in Step | above. + When you specify the domain directory and post office directory, be sure to browse through the Group Wise 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 during “Deciding How to Install and Configure the Agents in a Cluster” on page 25. The information you provide will be 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 worry about creating users in the post office at this time. + Inthe 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 Group Wise volume. GroupWise System Setup [x] Summa Novell. ry System name: Corporate Tree: CORP_TREE Domain name: Provo Domain context: GroupWise.Provo Domain directory: \GW-CLUSTER_GWVOL_SERVER\ Domain time zone: (GMT-07:00) Mountain Time (US & © Domain language: English - US Post office name: Development Post office context: GroupWWise.Provo Post office directory: \WGW-CLUSTER_GWVOL_SERVER\ Post office time zone: (GMT-07:00) Mountain Time (US &C ~ Ifthe above information is correct, click Next to create your GroupWise system. To correct any information, click Back until you reach the appropriate page. Cancel Fimer 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 45 in “Installing and Configuring the MTA and the POA in a Cluster” on page 44. Setting Up a Domain and Post Office in a Novell Cluster 41 Creating a New Secondary Domain in a Cluster 42 After you have set up the primary domain and initial post office, as described in “Setting Up a New Group Wise System in a Cluster” on page 40, 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 38. 2 Manually create the domain directory (System Clustering Worksheet item 10). This step is not required, but in a clustered environment, Step 5 will be easier if the domain directory already exists. 3 Ifyou selected vol:\system on GroupWise volume as the agent installation location (under Agent Clustering Worksheet item 1), create the vo/:\system directory on the Group Wise volume accessed in Step 1. 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 6.5 Administration Guide. 5 Create the new domain, following the steps provided in “Creating the New Domain” in “Domains” in the GroupWise 6.5 Administration Guide. Keep in mind the following cluster- specific details: + Use the Domain Worksheet you filled out during “Planning a New Clustered Domain” on page 20 to fill in the fields in the Create GroupWise Domain dialog box. + Inthe Domain Database Location field, be sure to browse through the drive you mapped in Step | to the domain directory you created in Step 2 above. + Inthe Link to Domain field, link the new domain to the primary domain of your Group Wise 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 during “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 25 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 6.5 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. 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 6.5 Administration GroupWise 6.5 Interoperability Guide 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 Group Wise 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. Continue with “Creating a New Post Office in a Cluster” on page 43. 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 Group Wise 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 4 If you selected Yes for Post Office on Same Volume as Domain? (under System Clustering Worksheet item 7), map a drive to the GroupWise volume for the domain (System Clustering Worksheet item 7). 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 38. Manually create the post office directory (System Clustering Worksheet item 12). This step is not required, but in a clustered environment, Step 4 will be easier if the post office directory already exists. 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 6.5 Administration Guide. Create the new post office, following the steps provided in “Creating the New Post Office” in “Post Offices” in the GroupWise 6.5 Administration Guide. Keep in mind the following cluster-specific details: + Use the Post Office Worksheet you filled out during “Planning a New Clustered Post Office” on page 21 to fill in the fields in the Create GroupWise Post Office dialog box. + Inthe Post Office Database Location field, be sure to browse through the drive you mapped in Step | to the post office directory you created in Step 2 above. + Ifyou want to create a library at the post office (System Clustering Worksheet item 14), select Create Library. + 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 25 for the secondary IP address and cluster-unique port numbers that you need to specify in order to configure the link. Right-click the new Post Office object, then click Properties. Setting Up a Domain and Post Office in a Novell Cluster 43 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 6.5 Administration Guide. 8 Make sure you are still connected to the domain that owns the new post office. 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 6.5 Administration Guide. Be sure to browse to the database location (under System Clustering Worksheet item 11) through the virtual server that was created when you cluster-enabled the Group Wise 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 Ifyou want to create a library (System Clustering Worksheet item 14) for the clustered post office, follow the steps in “Setting Up a Basic Library” or “Setting Up a Full-Service Library” in “Libraries and Documents” in the GroupWise 6.5 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” on page 44. Installing and Configuring the MTA and the POA in a Cluster 44 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: ¢ “Installing the Agent Software in a Cluster” on page 45 ¢ “Editing Clustered Agent Startup Files” on page 45 + “Configuring the GroupWise Volume Resource to Load and Unload the Agents” on page 46 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 vo/:\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 51 instead of completing the tasks above. GroupWise 6.5 Interoperability Guide Installing the Agent Software in a Cluster To install the MTA and the POA: 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 38. 2 Ifyou selected vol:\system on GroupWise volume as the agent installation location (under Agent Clustering Worksheet item 1), create the vo/:\system directory on the Group Wise 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 6.5 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 during “Planning the NetWare Agent Installation” on page 30 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. + Inthe 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 | 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. 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 Ifyou selected 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” on page 45. 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. Setting Up a Domain and Post Office in a Novell Cluster 45 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: 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. Configuring the GroupWise Volume Resource to Load and Unload the Agents The properties of the Volume Resource object define how the GroupWise volume functions within 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 46 ¢ “Modifying the Volume Resource Unload Script for the Agents” on page 48 ¢ “Setting the Failover Path and Policies for the Agents” on page 49 Modifying the Volume Resource Load Script for the Agents 46 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 > Console 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: GroupWise 6.5 Interoperability Guide + 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 + Ifyou 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. + Ifyou selected 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. + 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 + Ifyou selected 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: Setting Up a Domain and Post Office in a Novell Cluster 47 Properties of GWYOL_SERVER [x] P Address | Load Unload | Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Folé | Cluster Resource Load Script Script nss Jactivate=GWWVOL a mount GYVVOL VOLID=254 cyshind add GVWW-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only NUDP ADD GW-CLUSTER_GWVOL_SERVER 123.45.67.18 add secondary ipaddress 123.45.67.18 search add gwvolisystem SET AUTO RESTART AFTER ABEND = 2 SET AUTO RESTART AFTER ABEND DELAY TIME = 0 SET AUTO RESTART DOWN TIMEOUT = 60 SET DEVELOPER OPTION = OFF LOAD address space=devpoa GYWWVOLASYSTEMIGWWPOA @DEVELOPM.POA protection restart devpoa LOAD address space=provoimta GWVOLASYSTEMIGWMTA @PROVO1.MTA protection restart provotmta al 5 Timeout (secs) |600 Page Options... | OK | Cancel [Can] Help | 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 Ifnecessary, 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” on page 48. Modifying the Volume Resource Unload Script for the Agents 48 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. 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 selected 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. GroupWise 6.5 Interoperability Guide unload address space=addr_space_name load delay.nlm delay 10 unload kill address space=addr_space_name + Ifyou selected 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 volume: \directory\agent.nlm + OnNetWare 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: Properties of GWYOL_SERVER [x] P Address | Load | Ünioad || Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fold || Custer Resource Unload Sri Script unload address space = devpoa a unload address space = provotmta del secondary ipaddress 123.45.67.18 NUDP DEL GW-CLUSTER_GWVOL_SERVER 123.45.67.18 cvshind del GW-CLUSTER_GWWOL_SERVER 123.45.67.18 # NetWare 5.1 only dismount GWVOL force nss forcedeactivate=GWVOL Kil » Timeout (secs) feoo Page Options... | OK Cancel | aoe] Help | 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” on page 49. 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. Setting Up a Domain and Post Office in a Novell Cluster 49 Properties of GWYOL_SERVER cee @ GW-CLUSTER1 GW-CLUSTER2 GW-CLUSTER3 GW-CLUSTER4 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. Properties of GWYOL_SERVER 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 of Novell Cluster Services Overview and Installation for your version of NetWare: + NetWare 6.x: “Set Start, Failover, and Failback Modes” + NetWare 5.1: “Set Start, Failover, and Failback Modes” 5 Click OK when you are finished editing the GroupWise volume resource properties. 6 Continue with “Testing Your Clustered GroupWise System” on page 53. 50 GroupWise 6.5 Interoperability Guide 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 51 e “Modifying Existing Load and Unload Scripts” on page 51 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 vo/:\system directory of a GroupWise volume, the startup files will be 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. 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” on page 51. 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 46 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. If necessary, click View > Console 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: Setting Up a Domain and Post Office in a Novell Cluster 51 52 Properties of GWYOL_SERVER [x] P Address | Load Unload | Policies | Nodes | NDS Rights v | Other | Rights to Files and Fold | Cluster Resource Load Script Script nss Jactivate=GWVOL a mount GYVVOL VOLID=254 cysbind add Gi¥V-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only NUDP ADD GW-CLUSTER_GWVOL_SERVER 123.45.67.18 add secondary ipaddress 123.45.67.18 search add gwvolisystem SET AUTO RESTART AFTER ABEND = 2 SET AUTO RESTART AFTER ABEND DELAY TIME = 0 SET AUTO RESTART DOWN TIMEOUT = 60 SET DEVELOPER OPTION = OFF LOAD address space=devpoa GYVVOLASYSTEMIGWWPOA @DEVELOPM.POA protection restart devpoa LOAD address space=provolmta GW/VOLASYSTEMIGWMTA @PROVO1.MTA protection restart provotmta al » Timeout (secs) [600 Page Options... | OK | Cancel [Cen] Help | 4 Click Apply to save the modified load script. 5 Click Unload 6 Add corresponding unload commands for the new instances of the agents. Properties of GWYOL_SERVER [x] P Address | Load Unload Script unload address space = devpoa a unload address space = provotmta del secondary ipaddress 123.45.67.18 NUDP DEL GW-CLUSTER_GWVOL_SERVER 123.45.67.18 cysbind del GW-CLUSTER_GWWOL_SERVER 123.45.67.18 # NetWare 5.1 only dismount GWVOL force nss forcedeactivate=GWVOL al » Timeout (secs) feoo Page Options... | OK | Cancel [Can] Help | 7 Click Apply to save the modified unload script. 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 Volume Resource 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 “Testing Your Clustered GroupWise System” on page 53. GroupWise 6.5 Interoperability Guide 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. Cluster State | Event Log | HTML Report| PP gw-cluster Epoch 1 Connected GW-CLUSTER1 GW-CLUSTER2 Nodes Available (%) Resources Available ($) 0 20 40 60 80 100 0 20 40 60 80 100 Cluster Resource State Location #Lives | @ GWVOL_SERVER | Offline GW-CLUSTER1 2 | 2 | @ ILVOL_SERVER Running | OW-CLUSTERI | 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. Cluster State | Event Log | HTML Report} p gw-cluster Epoch 1 Connected GW-CLUSTER1 GW-CLUSTER2 | Nodes Available (%) Resources Available (%) 0 20 40 60 80 100 0 20 40 60 80 100 Cluster Resource State Location #Lives | @ GWVOL_SERVER | Running GW-CLUSTER1 2 | @ ILVOL_SERVER Running GW-CLUSTER1 2 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. 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. Setting Up a Domain and Post Office in a Novell Cluster 53 On NetWare 6.x, these actions can also be performed from your Web browser. See “Using NetWare Remote Manager on NetWare 6.x” on page 55. 7 Continue with “Managing Your Clustered GroupWise System” on page 54. Managing Your Clustered GroupWise System After you have set up a basic clustered GroupWise system, you should consider some long-term management issues. + “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 54 + “Using NetWare Remote Manager on NetWare 6.x” on page 55 + “Knowing What to Expect in MTA and POA Failover Situations” on page 58 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 54 + “Recording Cluster-Specific Information for a Post Office and Its POA” on page 54 + “Recording Cluster-Specific Information for a Software Distribution Directory” on page 55 Recording Cluster-Specific Information for a Domain and Its MTA To permanently record important cluster-specific information for the domain: 41 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. Click OK to save the domain description. Select the Domain object to display its contents. Right-click the MTA object, then click Properties. aoa bh Ww 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. This information will appear 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” on page 54. 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. 54 GroupWise 6.5 Interoperability Guide 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. Click OK to save the post office description. Select the Post Office object to display its contents. Right-click the POA object, then click Properties. oa bh Ww 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. This information will appear 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 Ifnecessary, continue with “Recording Cluster-Specific Information for a Software Distribution Directory” on page 55. or Continue with “Knowing What to Expect in MTA and POA Failover Situations” on page 58. 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 Continue with “Knowing What to Expect in MTA and POA Failover Situations” on page 58. Using NetWare Remote Manager on NetWare 6.x On NetWare 6.x, you can use NetWare Remote Manager to manage many aspects of your Group Wise cluster from your Web browser. For instructions on setting up and accessing this useful network administration utility, see the NetWare 6.x NetWare Remote Manager Administration Guide at the Novell Documentation Web site (http://www.novell.com/documentation/index.html). Cluster management features are automatically added to NetWare Remote Manager when you install Novell Cluster Services. After you have accessed NetWare Remote Manager, you might find that many Group Wise cluster management tasks are easier to perform with NetWare Remote Manager than with ConsoleOne. The following sections help you configure and manage the cluster using NetWare Remote Manager: + “Configuring Your Group Wise Cluster” on page 56 + “Managing Your GroupWise Cluster” on page 57 Setting Up a Domain and Post Office in a Novell Cluster 55 Configuring Your GroupWise Cluster On the main NetWare Remote Manager page: 1 In the left frame, scroll down to the Clustering section, then click Cluster Config. NetWare Remote Manager NetWare 6 Server Version 5.60, September 13, 2001 E] = entication (adrin) a: E Acak Novell. Protocol Information = Jove Anlestion © | gustan chsorcomig Information Manage Hardware gw-cluster Cluster Config Processors P Disk / LAN Adapters gw-cluster oleae Node Name Number IP Address Other Resources Manage eDirectory GW.CLUSTER1 0 123.456.78.91 Access Tree Walker Vc sent View eDirectory GW-CLUSTER? | 123.456.78.92 Partitions S NDS iMonitor © Resources —— U ee 4 1. Master _IP_Address Resource ise Server Groups EEE EP 2, GwvoL SERVER Load Group File AREEN Access Other Servers E 3. ILVOL SERVER Managed Server List © 4. iFolder Server Basic File Access a Clustering 3 5, Netscape Enterprise Server pi ement : New Cluster Volume Health Monitors NDPS Broker Health NetWare Usage Usage Information Add Master Resource ponte _ Create New Objects —— = m New Cluster Resource 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 NetWare Remote Manager interface). 2 Click the cluster name to display the Cluster object properties: Cluster Configuration Fields: gw-cluster Revision 261 IP Address 123.456.78.99 Port Number 7023 Quorum Membership 2 Timeout 60 Protocol Tolerance 8 Heartbeat 1 Master Watchdog 1 Slave Watchdog 8 Max Retransmit 30 GIPC Stream Resource Priorities Email Reporting Click a linked item to edit the Cluster object properties. Click your browser’s Back button to return to the Cluster Configuration page. 3 On the Cluster Configuration page, click a server to display the Server object properties: IP Address 123.456.78.99 Node Number 0 Back Delete Click a linked item to edit the Server object properties. Click Back or Delete to perform the specified action. 56 GroupWise 6.5 Interoperability Guide 4 On the Cluster Configuration page, click a GroupWise volume to display the Volume Resource object properties: IP Address 123.456.78.90 Loading Unloading Script Timeout Script Timeout 600 600 Policies 908 No Start Auto FailOver Manual FailBack Disabled Master Quorum Nodes GW-CLUSTER1, GW-CLUSTER2 , GW-CLUSTER3 , GW-CLUSTER4 Back Delete 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 NetWare Remote Manager page: 1 In the left frame, scroll down to the Clustering section, then click Cluster Management. ell NetWare 6 Server Version 5.60, September 13, 2001 NetWare Remote Manager hentication edmi) i: p oA Novell. Other Resources Manage eDirectory Access Tree Walker View eDirector 5 Partitions 5 Begin Refresh | Page Refresh Rate fio seconds | NDS iMonitor DS Trace Use Server Groups Epoch 1 Build Group Load Group File Nodes Access Other Servers Managed Server List l| E A pano pieraecoas GW-CLUSTER1 GW-CLUSTER2 GW-CLUSTERS Clustering Health Monitors Master IP_Address_ Resource Running GW-CLUSTER1 1 10-30-2001 5:32:03 pm NDPS Broker Health GWVOL_ SERVER Running GW-CLUSTER1 4 11-27-2001 1:53:39 pm NetWare Usage ILVOL_SERVER Running GW-CLUSTER1 1 10-30-2001 5:32:03 pm Usage Information Configuration g - Event Log a 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. 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. Setting Up a Domain and Post Office in a Novell Cluster 57 Resource Action for GWVOL_SERVER State Running GW-CLUSTER1 GW-CLUSTER2 = Offline | {GW-CLUSTER3 Migrate GW-CLUSTER4 ¥] 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. Knowing What to Expect in MTA and POA Failover Situations What’s Next 58 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 Group Wise client users who can reconnect to their mailboxes very quickly and probably will not notice if messages to users in other post offices are not delivered immediately. The only time a user would need to restart the Group Wise 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” on page 58. 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 6.5 Administration Guide. ¢ Setting up the Group Wise client software and helping users to get started using it. See “Client” in the GroupWise 6.5 Administration Guide. Also see the GroupWise 6.5 Windows Client User Guide. + Connecting your clustered GroupWise system to the Internet. See Chapter 4, “Implementing the Internet Agent in a Novell Cluster,” on page 63. ¢ Providing access to users’ GroupWise mailboxes from their Web browsers. See Chapter 5, “Implementing WebAccess in a Novell Cluster,” on page 83. + Connecting your clustered Group Wise system to other e-mail systems through GroupWise gateways. See Chapter 6, “Implementing GroupWise Gateways in a Novell Cluster,” on page 103. GroupWise 6.5 Interoperability Guide + Monitoring the status of your clustered GroupWise system from your Web browser. See Chapter 7, “Monitoring a GroupWise System in a Novell Cluster,” on page 105. + Backing up your clustered GroupWise system. See Chapter 8, “Backing Up a GroupWise System in a Novell Cluster with the GroupWise TSA,” on page 107. Clustering Quick Checklists + “GroupWise System Quick Checklist” on page 59 + “Domain Quick Checklist” on page 60 + “Post Office Quick Checklist” on page 61 GroupWise System Quick Checklist Q) Plan your new clustered GroupWise system. See Chapter 2, “Planning GroupWise in a Novell Cluster,” on page 17. Q) Cluster-enable the volumes where GroupWise domains and post offices will reside. See “Cluster-Enabling Shared Volumes for Use with GroupWise” on page 37. Q) Make sure that short name resolution works throughout your network. See “Configuring Short Name Resolution” on page 38. Q) Create the primary domain and initial post office in your new clustered Group Wise system. See “Setting Up a New GroupWise System in a Cluster” on page 40. Q) Set up the agents for the primary domain and the initial post office. See “Installing and Configuring the MTA and the POA in a Cluster” on page 44. Q 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) ¢ Ifyou 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 46. QO) Modify the volume resource unload script(s): + Add the 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 Agents” on page 48. Setting Up a Domain and Post Office in a Novell Cluster 59 Set up the volume failover path(s) and policies. See “Setting the Failover Path and Policies for the Agents” on page 49. Test your new clustered GroupWise system. See “Testing Your Clustered GroupWise System” on page 53. Record cluster-specific information in the properties pages of the GroupWise objects that the information pertains to. See “Managing Your Clustered GroupWise System” on page 54. Domain Quick Checklist 60 m) m) Plan your new clustered domain. See “Planning a New Clustered Domain” on page 20. Cluster-enable the volume where the domain will reside. See “Cluster-Enabling Shared Volumes for Use with GroupWise” on page 37. Make sure that short name resolution for the new domain volume works throughout your network. See “Configuring Short Name Resolution” on page 38. Create the new domain. See “Creating a New Secondary Domain in a Cluster” on page 42. Set up the MTA for the new domain. See “Installing and Configuring the MTA and the POA in a Cluster” on page 44. 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) + Ifyou 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 + Ifyou 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 46. Modify the domain volume resource unload script: + Add the MTA 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 48. Set up the domain volume failover path and policies. See “Setting the Failover Path and Policies for the Agents” on page 49. GroupWise 6.5 Interoperability Guide m) m) Test your new clustered domain. See “Testing Your Clustered GroupWise System” on page 53. Record cluster-specific information in the properties pages of the GroupWise objects that the information pertains to. See “Managing Your Clustered GroupWise System” on page 54. Post Office Quick Checklist m) m) m) Plan your new clustered post office. See “Planning a New Clustered Post Office” on page 21. Cluster-enable the volume where the post office will reside. See “Cluster-Enabling Shared Volumes for Use with GroupWise” on page 37. Make sure that short name resolution for the new post office volume works throughout your network. See “Configuring Short Name Resolution” on page 38. Create the new post office. See “Creating a New Post Office in a Cluster” on page 43. Set up the POA for the new post office. See “Installing and Configuring the MTA and the POA in a Cluster” on page 44. 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 45. 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) + Ifyou 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 + Ifyou 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 46. 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 48. Setting Up a Domain and Post Office in a Novell Cluster 61 Q) Set up the post office volume failover path and policies. See “Setting the Failover Path and Policies for the Agents” on page 49. Q Test your new clustered post office. See “Testing Your Clustered GroupWise System” on page 53. Q) Record cluster-specific information in the properties pages of the GroupWise objects that the information pertains to. See “Managing Your Clustered GroupWise System” on page 54. 62 GroupWise 6.5 Interoperability Guide Implementing the Internet Agent in a Novell Cluster You should already have set up at least a basic GroupWise® system, as described in Chapter 2, “Planning GroupWise in a Novell Cluster,” on page 17 and Chapter 3, “Setting Up a Domain and Post Office in a Novell Cluster,” on page 37. As part of this process, the “System Clustering Worksheet” on page 32 and the “IP Address Worksheet” on page 34 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 will need this information as you implement the Internet Agent in a cluster. + “Planning the Internet Agent in a Cluster” on page 63 ¢ “Setting Up the Internet Agent in a Cluster” on page 67 + “Managing the Internet Agent in a Cluster” on page 76 + “Internet Agent Clustering Worksheet” on page 78 + “Internet Agent Quick Checklist” on page 80 Planning the Internet Agent in a Cluster A main system configuration difference between a GroupWise system in a clustering environment and a Group Wise system in a regular environment is that you need to create a separate domain to house each GroupWise gateway, including the Internet Agent. The “Internet Agent Clustering Worksheet” on page 78 lists all the information you will 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: + “Planning a Domain for the Internet Agent” on page 64 + “Deciding Whether to Cluster-Enable the Internet Agent Volume” on page 64 + “Determining an Appropriate Failover Path for the Internet Agent Volume” on page 64 + “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the Internet Agent and Its MTA” on page 65 + “Preparing Your Firewall for the Internet Agent” on page 65 + “Deciding Where to Install the Internet Agent and Its MTA” on page 66 + “Deciding Whether to Run the Internet Agent and Its MTA in Protected Memory” on page 66 + “Planning the MTA Installation” on page 66 + “Planning the Internet Agent Installation” on page 66 Implementing the Internet Agent in a Novell Cluster 63 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 6.5 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. Under Item 2: Internet Agent Domain Name, transfer the domain name and database directory to the Internet Agent Clustering Worksheet. 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 “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21, 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 “Ensuring Successful Name Resolution for GroupWise Volumes” on page 23, which describes the issues in the context of planning MTA and POA installations. Determining an Appropriate Failover Path for the Internet Agent Volume 64 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 27, which describes the issues in the context of planning MTA and POA installations. 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. GroupWise 6.5 Interoperability Guide 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 34. 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. 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. Preparing Your Firewall for the Internet Agent The Internet Agent will receive 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: Protocol Standard Port IMAP4 143 LDAP 389 POP3 110 SMTP 25 By default, the Internet Agent will send 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. 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 would be 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 75, 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. Implementing the Internet Agent in a Novell Cluster 65 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 28, which describes the issues in the context of planning MTA and POA installations. If you only have one Internet Agent for your Group Wise 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. 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. 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 30, which describes the issues in the context of planning MTA and POA installations. You might think that protected memory would not be necessary if you have only one Internet Agent for your Group Wise system because it could never fail over to anode 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. Planning the MTA Installation Follow the instructions in “Planning the NetWare Agent Installation” on page 30, 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 “Setting Up the Internet Agent in a Cluster” on page 67. Planning the Internet Agent Installation 66 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 “Installing the Internet Agent Software on NetWare or Windows” in “Installing the GroupWise Internet Agent” in the GroupWise 6.5 Installation Guide. You might want to print this section and write down the types GroupWise 6.5 Interoperability Guide 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. IMPORTANT: Do not install the Internet Agent software until you are instructed to do so in “Setting Up the Internet Agent in a Cluster” on page 67. Setting Up the Internet Agent in a Cluster You should already have reviewed “Planning the Internet Agent in a Cluster” on page 63 and filled out the “Internet Agent Clustering Worksheet” on page 78. You are now ready to complete the following tasks to set up the Internet Agent in a clustering environment: + + + + + + “Cluster-Enabling a Shared Volume for Use with the WebAccess Agent” on page 88 “Creating a Domain for the Internet Agent” on page 68 “Installing the MTA for the Internet Agent Domain” on page 68 “Installing and Configuring the Internet Agent in a Cluster” on page 68 “Testing the Clustered Internet Agent” on page 75 “Managing the Internet Agent in a Cluster” on page 76 Cluster-Enabling a Shared Volume for Use with the Internet Agent To cluster-enable the Internet Agent shared volume: 1 Complete the steps in the applicable section of Novell Cluster Services Overview and Installation for your version of NetWare: + NetWare 6.x: “Cluster Enable Pools and Volumes” + NetWare 5.1: “Cluster-Enable Volumes ” 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® eDirectory™ objects that are created when you cluster-enable a shared volume, see “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21. Ifyou have installed the latest version of ConsoleOne® and the Novell Cluster Services snap- in, as described in “Updating to the Latest ConsoleOne Snap-In” on page 18, you will be able to rename the cluster-related objects in case your DNS name server cannot resolve object names that include the underscore (_) character. 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 38. 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 65. 4 Continue with “Creating a Domain for the Internet Agent” on page 68. Implementing the Internet Agent in a Novell Cluster 67 Creating a Domain for the Internet Agent The Internet Agent domain will be a secondary domain. To create it, follow the instructions in “Creating a New Secondary Domain in a Cluster” on page 42, taking your information from the Internet Agent Clustering Worksheet, rather than the System Clustering Worksheet, then return to this point. Do not create any post offices in the Internet Agent domain. Continue with “Installing the MTA for the Internet Agent Domain” on page 68. 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 Group Wise system. Follow the instructions in “Installing the Agent Software in a Cluster” on page 45, 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” on page 68. 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 68 + “Configuring the Internet Agent Volume Resource to Load and Unload the Internet Agent and Its MTA” on page 69 + “Enabling Internet Addressing for Your Clustered GroupWise System” on page 74 + “Verifying GWIA Object Properties” on page 74 Installing the Internet Agent Software in a Cluster 68 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 38. 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 “Installing the Internet Agent Software on NetWare or Windows” in “Installing the GroupWise Internet Agent” in the GroupWise 6.5 Installation Guide. Keep in mind the following cluster-specific details: + Use the notes you made during “Planning the Internet Agent Installation” on page 66 to fill in the fields during the Internet Agent installation process. GroupWise 6.5 Interoperability Guide + Inthe 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. + Inthe 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 will use 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: 4a Repeat Step 3, mapping new drives as needed. 4b If you selected 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 6.5 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” on page 69. 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 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 69 + “Modifying the Volume Resource Unload Script for the Internet Agent” on page 71 ¢ “Setting the Failover Path and Policies for the Internet Agent” on page 72 Modifying the Volume Resource Load Script for the Internet Agent The volume resource load script executes whenever the Internet Agent volume comes online. To set up the load script: 1 In ConsoleOne, browse to and select the Cluster object. If necessary, click View > Console 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 will already have 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. Implementing the Internet Agent in a Novell Cluster 69 + On NetWare 5.1, if you are using SLP as a short name resolution method, as described in “Configuring Short Name Resolution” on page 38, add the cvsbind add command for the Internet Agent volume to the load script. evsbind add cluster volume SERVER IP address + Ifyou 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. search add volume:\system + Ifyou 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. + Ifyou selected 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 + Adda 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. ¢ 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 + Ifyou selected 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: 70 GroupWise 6.5 Interoperability Guide Properties of GWYOL_SERVER [x] P Address | Load | Uniosa | Policies | Nodes | NDS Rights | Other | Rights to Files and Fole (Cians Coad sca Script nss /activate=GWVOL = mount GYVVOL VOLID=254 cysbind add GYV-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only NUDP ADD GWW-CLUSTER_GWYVOL_SERVER 123.45.67.18 add secondary ipaddress 123.45.67.18 search add gwvolisystem SET AUTO RESTART AFTER ABEND = 2 SET AUTO RESTART AFTER ABEND DELAY TIME = 0 SET AUTO RESTART DOWN TIMEOUT = 60 SET DEVELOPER OPTION = OFF LOAD address space=gwia GWVOLASYSTEMIGWMTA @PROVO1.MTA LOAD DELAY, DELAY 10 LOAD address space=gwia GWVOLASYSTEMIGWIA @GWIA.CFG protection restart gwia Ki » Timeout (secs) |600 Page Options... | OK Cancel [Can] Help | 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 Ifnecessary, 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” on page 71. 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. 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 will already have been made. 2 Make the following changes to the default unload script: + Ifyou selected 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 Implementing the Internet Agent in a Novell Cluster 71 72 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. unload address space=addr_space_name delay 10 unload kill address space=addr_space_name + Ifyou selected 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 volume:\system\gwia.nlm unload volume:\system\gwmta.nlm + OnNetWare 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: Properties of GWYOL_SERVER [x] P Address | Load Unload Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fol Script unload address space = gwia á del secondary ipaddress 123.45.67.18 NUDP DEL GW-CLUSTER_GWVOL_SERVER 123.45.67.18 cysbind del GW-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only dismount GWVOL force nss forcedeactivate=GWVOL 4 of Timeout (secs) foo Page Options... | OK | Cancel [Can ] Help | 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 Internet Agent” on page 72. 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. GroupWise 6.5 Interoperability Guide GW-CLUSTER1 ÉP GW-CLUSTER2 ÉP GW-CLUSTER3 ÉP GW-CLUSTER4S 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. Properties of GWYOL_SERYER 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 of Novell Cluster Services Overview and Installation for your version of NetWare: NetWare 6.x: “Set Start, Failover, and Failback Modes” NetWare 5.1: “Set Start, Failover, and Failback Modes” 5 Click OK when you are finished editing the Internet Agent volume resource properties. 6 Continue with “Enabling Internet Addressing for Your Clustered GroupWise System” on page 74. Implementing the Internet Agent in a Novell Cluster 73 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 6.5 Administration Guide, then return to this point. Verifying GWIA Object Properties During installation of the Internet Agent, the GWIA 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 GWIA Object Properties” on page 74 + “Verifying the Reference to the Volume Resource” on page 74 + “Verifying the Reference to the Virtual Server” on page 74 + “Verifying Post Office Links” on page 74 + “Forcing Use of the Internet Agent Secondary IP Address” on page 75 Accessing GWIA Object Properties 1 In ConsoleOne, browse to and select the Internet Agent domain in order to display its contents. 2 Right-click the GWIA object, then click Properties. 3 Continue with “Verifying the Reference to the Volume Resource” on page 74. Verifying the Reference to the Volume Resource In the GWIA 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” on page 74. Verifying the Reference to the Virtual Server In the GWIA object properties pages: 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” on page 74. Verifying Post Office Links In the GWIA object properties pages: 74 GroupWise 6.5 Interoperability Guide 4 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” on page 75. 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 Inthe TCP/IP Address field, provide the secondary IP address (under Internet Agent Clustering Worksheet item 1) for the Internet Agent to use for sending outgoing messages. 3 Click SMTP/MIME, then click Settings. 4 Select Bind to TCIP/IP Address at Connection Time. 5 Click OK. 6 Continue with “Testing the Clustered Internet Agent” on page 75. 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. Cluster State | Event Log | HTML Report} p gw-cluster Epoch 1 Connected GW-CLUSTER1 GW-CLUSTER2 ooo K ooh Tomar eo Mon jpo or po eo ooN fons 0 20 40 60 80 100 Resources Available (%) upita 20 40 60 80 100 F Available (%) Cluster Resource State Location #Lives @ GWVOL_SERVER | Offline GW-CLUSTER1 2 | GW-CLUSTER1 @ ILVOL_SERVER Running | 2 The new Internet Agent volume resource shows Offline in the State column. 2 Click the new Internet Agent volume resource, then click Online. Implementing the Internet Agent in a Novell Cluster 75 Cluster State | Event Log | HTML Report| p gw-cluster Epoch 1 Connected GW-CLUSTER1 GW-CLUSTER2 r Nodes Available (%) > Resources Available (%) fi Ci (jo OCT 0 20 40 6&0 80 100 Cluster Resource State Location #Lives @ GWVOL_SERVER | Running GW-CLUSTER1 2 | @ ILVOL_SERVER Running | GW-CLUSTER1 2 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. 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 NetWare Remote Manager on NetWare 6.x” on page 55. 7 Continue with “Managing the Internet Agent in a Cluster” on page 76. 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. + “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 76 + “Knowing What to Expect in an Internet Agent Failover Situation” on page 77 Updating GroupWise Objects with Cluster-Specific Descriptions 76 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 Group Wise 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 77 + “Recording Cluster-Specific Information about the Internet Agent” on page 77 GroupWise 6.5 Interoperability Guide 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. Click OK to save the Internet Agent domain description. Select the Internet Agent Domain object to display its contents. Right-click the MTA object, then click Properties. og bh GQ 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 will appear 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” on page 77. Recording Cluster-Specific Information about the Internet Agent With the contents of the Internet Agent domain still displayed: 1 Right-click the GWIA object, then click Properties. 2 Click GroupWise, then click Identification. 3 Inthe 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 will appear 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” on page 77. Knowing What to Expect in an Internet Agent Failover Situation The failover behavior of the MTA for the Internet Agent domain will be the same as for an MTA in a regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” on page 58. Failover of the Internet Agent itself is more complex. The various clients (POP3, IMAP4, and LDAP) will 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 Group Wise 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 will be able to 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. Implementing the Internet Agent in a Novell Cluster 77 Internet Agent Clustering Worksheet Item 1) Shared Volume for Internet Agent: Cluster Enabled? + Yes (highly recommended) Cluster volume IP address + No 2) Internet Agent Domain Name: Domain Database Location: 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? 7) Internet Agent Network Information: ¢ Internet Agent IP address + Internet Agent HTTP port Explanation 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 64. 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 64. 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 64. 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 66. Gather the MTA network address information from the Internet Agent section of the “IP Address Worksheet” on page 34. For more information, see “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the Internet Agent and Its MTA” on page 65. 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 66. Gather the Internet Agent network address information from the Internet Agent section of the “IP Address Worksheet” on page 34. For more information, see “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the Internet Agent and Its MTA” on page 65. 78 GroupWise 6.5 Interoperability Guide Item Explanation 8) Load Internet Agent and Its MTA in Protected Memory? + No + Yes Protected address space names: + MTA: ¢ Internet Agent: 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. IMPORTANT: We strongly recommend that you run the Internet Agent and its MTA in protected memory and mark each memory space as restartable. For more information, see “Deciding Whether to Run the Internet Agent and Its MTA in Protected Memory” on page 66. Implementing the Internet Agent in a Novell Cluster 79 Internet Agent Quick Checklist &0 Q) Plan the new clustered Internet Agent, including the new domain required to house the Internet Agent in a clustering environment. See “Planning the Internet Agent in a Cluster” on page 63. Make sure your firewall is configured to accommodate the Internet Agent. See “Preparing Your Firewall for the Internet Agent” on page 65. Cluster-enable the volume where the Internet Agent domain will reside. See “Cluster-Enabling a Shared Volume for Use with the WebAccess Agent” on page 88. Create the new Internet Agent domain. See “Creating a Domain for the Internet Agent” on page 68. Set up the MTA for the new Internet Agent domain. See “Installing the MTA for the Internet Agent Domain” on page 68. Install the Internet Agent. See “Installing the Internet Agent Software in a Cluster” on page 68. 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) + Ifyou 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 69. 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 71. Set up the Internet Agent volume failover path and policies. See “Setting the Failover Path and Policies for the Internet Agent” on page 72. Enable Internet Addressing for the clustered Internet Agent. See “Enabling Internet Addressing for Your Clustered GroupWise System” on page 74. Double-check the cluster-specific GWIA object properties. GroupWise 6.5 Interoperability Guide See “Verifying GWIA Object Properties” on page 74. 0 Test the clustered Internet Agent. See “Testing the Clustered Internet Agent” on page 75. ü Record cluster-specific information in the properties pages of the Group Wise objects associated with the Internet Agent. See “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 76. Implementing the Internet Agent in a Novell Cluster 81 82 GroupWise 6.5 Interoperability Guide Implementing WebAccess in a Novell Cluster You should already have set up at least a basic GroupWise™ system, as described in Chapter 2, “Planning GroupWise in a Novell Cluster,” on page 17 and Chapter 3, “Setting Up a Domain and Post Office in a Novell Cluster,” on page 37. As part of this process, the “System Clustering Worksheet” on page 32 and the “IP Address Worksheet” on page 34 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 will need this information as you implement WebAccess in a cluster. + “Understanding the WebAccess Components” on page 83 + “Planning WebAccess in a Cluster” on page 83 + “Setting Up WebAccess in a Cluster” on page 88 + “Managing WebAccess in a Cluster” on page 96 + “WebAccess Clustering Worksheet” on page 99 + “WebAccess Quick Checklist” on page 101 Understanding the WebAccess Components If you are not familiar with GroupWise WebAccess, review “GroupWise WebAccess Overview” in “Installing GroupWise WebAccess” in the GroupWise 6.5 Installation Guide. As you plan WebAccess in a clustering environment, you must keep in mind that you will plan and set up two WebAccess components: + WebAccess Agent (gwinter.nlm) that will be associated with a GroupWise WebAccess domain + WebAccess Application (a Java* servlet) that will be added to your Web server (Netscape Enterprise Server for NetWare® required on NetWare 6) 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. The “WebAccess Clustering Worksheet” on page 99 lists all the information you will need as you set up the WebAccess Agent and the WebAccess Application in a clustering environment. You should print the worksheet and fill it out as you complete the tasks listed below: + “Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6” on page 84 Implementing WebAccess in a Novell Cluster 83 + “Planning a New Domain for the WebAccess Agent” on page 85 + “Deciding Whether to Cluster-Enable the WebAccess Agent Volume” on page 85 + “Determining an Appropriate Failover Path for the WebAccess Agent Volume” on page 85 + “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 86 + “Deciding Where to Install the WebAccess Agent and Its MTA” on page 86 + “Deciding Whether to Run the WebAccess Agent and Its MTA in Protected Memory” on page 86 + “Planning the MTA Installation” on page 87 + “Planning the WebAccess Installation” on page 87 IMPORTANT: NetWare 6.5 provides Apache and Tomcat instead of the Netscape Enterprise Web Server, which was provided on NetWare 6. However, NetWare 6.5 Support Packs currently cannot update an Apache/ Tomcat installation that is located on cluster-enabled volume. Consequently, clustering WebAccess with Apache and Tomcat is not currently supported by Novell. However, helpful instructions are available from Tay Kratzer at www.taykratzer.com. Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6 Although several Web servers are supported for use with GroupWise WebAccess in a non- clustered environment, only the Netscape Enterprise Server for NetWare is supported in a clustering environment because it is the only currently supported Web server that runs on NetWare 6. In preparation for installing WebAccess in your clustered GroupWise system, install and set up the Netscape Enterprise Server for NetWare, following the instructions in “Configuring NetWare Enterprise Web Server with Novell Cluster Services” in NetWare Cluster Services Resource Configuration Guide. As you set up the Netscape Enterprise Server, record the following key configuration information on the WebAccess Clustering Worksheet: WEBACCESS CLUSTERING WORKSHEET Under Item 10: Physical Web Servers, list the physical NetWare servers where you are installing the Netscape Enterprise Server software. Under Item 11: Netscape Enterprise Server IP Address, record the secondary IP address of the Netscape Enterprise Server cluster resource that you create. Under Item 12: Netscape Enterprise Server Mode, mark whether you have configured the Netscape Enterprise Server to run in active/active or active/passive mode. In active/active mode, the Netscape Enterprise Server runs on multiple nodes simultaneously; this is the recommended mode. Under Item 13: Netscape Enterprise Server Failover Path, list the nodes in the cluster where you want the Netscape Enterprise Server cluster resource to fail over. Under Item 14: Hardware Virtual Server Information, record the dedicated IP address for the Web site and the document root directory. The Netscape Enterprise Server for NetWare does not depend on the functionality of cluster- enabled volumes the way GroupWise does. Because the WebAccess Application will be installed to a subdirectory of the Netscape Enterprise Server installation directory (sys:\novonyx\suitespot\docs\com\novell\webaccess), the WebAccess Application cannot be installed on a cluster-enabled volume. Instead, you will install it to the sys: volume on each node where the Netscape Enterprise Server has been installed. 84 GroupWise 6.5 Interoperability Guide 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 6.5 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 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. 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 “Deciding Whether to Cluster- Enable the Shared Volumes Used by GroupWise” on page 21, 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?. Cluster-enabling relies on successful short name resolution throughout your system. Review “Ensuring Successful Name Resolution for GroupWise Volumes” on page 23, which describes the issues in the context of planning MTA and POA installations. 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 would be 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 27, 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. Implementing WebAccess in a Novell Cluster 85 Planning a Secondary IP Address and Cluster-Unique 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 34. 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. 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 28, 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. 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. Deciding Whether to Run the WebAccess Agent and Its MTA in Protected Memory &6 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 30, which describes the issues in the context of planning MTA and POA installations. You might think that protected memory would not be 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. GroupWise 6.5 Interoperability Guide 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. Planning the MTA Installation Follow the instructions in “Planning the NetWare Agent Installation” on page 30, 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 “Setting Up WebAccess in a Cluster” on page 88. 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 6.5 Installation Guide. When you set up WebAccess in a cluster, you will install the WebAccess Agent and the WebAccess Application in two separate steps: + “Planning the WebAccess Agent Installation” on page 87 + “Planning the WebAccess Application Installation” on page 87 IMPORTANT: Do not install the WebAccess software until you are instructed to do so in “Setting Up WebAccess in a Cluster” on page 88. 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 during “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 86. Under Item 4: Enable Clustering Support?, mark Yes. This will cause the WebAccess Installation program to customize the WebAccess files for clustering. Under Item 5: Domain Directory Path, transfer the domain directory from the Domain Worksheet you filled out during “Planning a New Domain for the WebAccess Agent” on page 85. Planning the WebAccess Application Installation For the WebAccess Application, fill out items 13 through 19 on the GroupWise WebAccess Installation Worksheet, taking into account the following cluster-specific issues: Implementing WebAccess in a Novell Cluster 87 WEBACCESS INSTALLATION WORKSHEET Under Item 13: Web Server Type and Root Directory, mark Netscape Enterprise Server for NetWare if you are using NetWare 6. No other Web server is currently supported for use with GroupWise and Novell® Cluster Services™. The Web server root directory will be sys:\novonyx\suitespot. Under Item 16: Novell Root Directory, do not choose a location on a cluster-enabled volume if you are running the Netscape Enterprise Server in active/active mode; it must be a directory on the sys: volume of the server. If you are using active/passive mode, you can choose a location on a cluster- enabled volume. Just make sure that the Volume Resource load script mounts the volume before starting the Netscape Enterprise Server. Setting Up WebAccess in a Cluster You should already have reviewed “Planning WebAccess in a Cluster” on page 83 and filled out the “WebAccess Clustering Worksheet” on page 99. You are now ready to complete the following tasks to set up the WebAccess Agent in a clustering environment: + + + + + + + “Cluster-Enabling a Shared Volume for Use with the WebAccess Agent” on page 88 “Creating a Domain for the WebAccess Agent” on page 89 “Installing the MTA for the WebAccess Agent Domain” on page 89 “Installing and Configuring the WebAccess Agent in a Cluster” on page 89 “Installing and Configuring the WebAccess Application in a Cluster” on page 95 “Testing Your Clustered WebAccess Installation” on page 96 “Managing WebAccess in a Cluster” on page 96 IMPORTANT: NetWare 6.5 provides Apache and Tomcat instead of the Netscape Enterprise Web Server, which was provided on NetWare 6. However, NetWare 6.5 Support Packs currently cannot update an Apache/ Tomcat installation that is located on cluster-enabled volume. Consequently, clustering WebAccess with Apache and Tomcat is not currently supported by Novell. However, helpful instructions are available from Tay Kratzer at www.taykratzer.com. Cluster-Enabling a Shared Volume for Use with the WebAccess Agent 1 Complete the steps in the applicable section of Novell Cluster Services Overview and Installation for your version of NetWare: + NetWare 6.x: “Cluster Enable Pools and Volumes” + NetWare 5.1: “Cluster-Enable Volumes ” 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™ objects that are created when you cluster-enable a shared volume, see “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21. If you have installed the latest version of ConsoleOne® and the Novell Cluster Services snap- in, as described in “Updating to the Latest ConsoleOne Snap-In” on page 18, you will be able to rename the cluster-related objects in case your DNS name server cannot resolve object names that include the underscore (_) character. GroupWise 6.5 Interoperability Guide 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 38. 3 Continue with “Creating a Domain for the WebAccess Agent” on page 89. Creating a Domain for the WebAccess Agent The WebAccess Agent domain will be a secondary domain. To create it, follow the instructions in “Creating a New Secondary Domain in a Cluster” on page 42, taking your information from the WebAccess Clustering Worksheet, rather than the System Clustering Worksheet, then return to this point. Do not create any post offices in the WebAccess Agent domain. Continue with “Installing the MTA for the WebAccess Agent Domain” on page 89. 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 45, 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” on page 89. 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 89 + “Configuring the WebAccess Agent Volume Resource to Load and Unload the WebAccess Agent and Its MTA” on page 90 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. 41 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 38. 2 Ifyou 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. Implementing WebAccess in a Novell Cluster 89 3 Start the WebAccess Installation program and install the NetWare WebAccess Agent, following Step | through Step 5 provided in “Installing the WebAccess Agent” in “Installing Group Wise WebAccess” in the Group Wise 6.5 Installation Guide. Keep in mind the following cluster-specific details: + Inthe 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 during “Planning the WebAccess Installation” on page 87 to fill in the fields during the WebAccess Agent installation process. + Inthe Network Address dialog box, select Configure GroupWise Agents for Clustering. + Inthe Installation Path dialog box, be sure to browse through the drive you mapped to the location you chose in Step 2 above. + Inthe Gateway Directory dialog box, be sure to browse to the domain directory through the drive you mapped in Step | 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 will 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 “Setting Up GroupWise WebAccess on NetWare or Windows” in “Installing GroupWise WebAccess” in the GroupWise 6.5 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” on page 90. Configuring the WebAccess Agent Volume Resource to Load and Unload the WebAccess Agent and Its MTA 90 The properties of the Volume Resource object define how the WebAccess Agent volume functions 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 90 + “Modifying the Volume Resource Unload Script for the WebAccess Agent” on page 92 ¢ “Setting the Failover Path and Policies for the WebAccess Agent” on page 94 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 > Console 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. GroupWise 6.5 Interoperability Guide The next step assumes that this is the first time you have edited the load script. If other Group Wise agents are already running from this volume, some of the modifications will already have been made. 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 38, 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 selected 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. 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\webac65a /user=username / PASSWORD=password If you selected 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. Implementing WebAccess in a Novell Cluster 91 92 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\webac65a /user=username /password=password protection restart addr_space_ name The result would look similar to the following example: Properties of GWYOL_SERVER [x] P Address | Load Ez | Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fold | Cluster Resource Load Script Script nss Jactivate=GWWVOL = mount GWVOL VOLID=254 cysbind add GiV-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only NUDP ADD GW-CLUSTER_GWVOL_SERVER 123.45.67.18 add secondary ipaddress 123.45.67.18 search add gwvolisystem SET AUTO RESTART AFTER ABEND = 2 SET AUTO RESTART AFTER ABEND DELAY TIME = 0 SET AUTO RESTART DOWN TIMEOUT = 60 SET DEVELOPER OPTION = OFF LOAD address space=webacc GY/VOLIASYSTEMIGWMTA @PROVO1.MTA LOAD DELAY, DELAY 10 LOAD address space=webace GYV/VOLASYSTEMIGWINTER /PH=GWYVOLAPROVOTWPGATEWYEBACBDA protection restart webacc al 5 Timeout (secs) |600 Page Options... | OK | Cancel [Cn] Help | 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” on page 92. 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 Group Wise agents are already running from this volume, some of the modifications will already have been made. 2 Make the following changes to the default unload script: GroupWise 6.5 Interoperability Guide + Ifyou selected 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 + Ifyou selected 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 volume:\system\gwinter.nlm unload volume:\system\gwmta.nlm + OnNetWare 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. 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: Properties of GWYOL_SERVER [x] P Address | Load füh 1 Soriet i Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fold Script unload address space = webacc a del secondary ipaddress 123.45.67.18 NUDP DEL GW-CLUSTER_GWVOL_SERVER 123.45.67.18 cysbind del GWV-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only dismount GWVOL force nss /forcedeactivate=GWWVOL al » Timeout (secs) foo Page Options... | OK Cancel [Can] Help | 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” on page 94. Implementing WebAccess in a Novell Cluster 93 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. Properties of GWYOL_SERVER [x] IP Address | Load | Unload | Policies Nodes TTT] NDS Rights v | Other | Rights to Files andi | luster Resource Preferred Nodes. | Unassigned Assigned GW-CLUSTER1 P GW-CLUSTER2 GW-CLUSTER3 GW-CLUSTER4S Page Options.. | ok | _cancei |[_ Aeey | He | 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. Properties of GWYOL_SERYER [x] P Address | Load | Unload | Policies 77T] Nodes | NDS Rights ~ | Other | Rights to Files and Folders | | Cluster Resource Policies į [P Ignore Quorum rStart Mode @ Manual C Auto ; Failover Mode C Manual © Auto ; Failback Mode C Manual © Auto © Disable Page Options.. | ok | _cancei |[_ Anny | Hel | 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 of Novell Cluster Services Overview and Installation for your version of NetWare: + NetWare 6.x: “Set Start, Failover, and Failback Modes” + NetWare 5.1: “Set Start, Failover, and Failback Modes” 94 GroupWise 6.5 Interoperability Guide 5 Click OK when you are finished editing the WebAccess Agent volume resource properties. 6 Continue with “Installing and Configuring the WebAccess Application in a Cluster” on page 95. Installing and Configuring the WebAccess Application in a Cluster Recall that the WebAccess Agent is the component of your WebAccess installation that accesses post offices and libraries to retrieve information for WebAccess client users. The WebAccess Application provides the link between the WebAccess Agent and the WebAccess clients’ Web browsers. To install the WebAccess Application: 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 38. 2 Map a drive to sys:\system on the first node where you want to install the WebAccess Application (WebAccess Clustering Worksheet item 10). 3 Ifthe node where you are going to install the WebAccess Application is currently running any applications that rely on Java or on the Netscape Enterprise Server, migrate those applications to another node in the cluster. If any GroupWise agents are running on the node, migrate the agents. For assistance with migrating resources, see “Migrate Resources” in “Installation and Setup” in NetWare Cluster Services Overview and Installation. 4 Manually stop the Netscape Enterprise Server and unload Java. nvxwebdn unload java If the WebAccess Installation program detects that the Netscape Enterprise Server and Java are still running, it will attempt to stop them for you. However, the Installation program is not always successful, so performing this step manually is recommended. 5 Start the WebAccess Installation program as you did when you installed the WebAccess Agent (Step 3 on page 90). Keep in mind the following cluster-specific details: + Inthe Components dialog box, select only GroupWise WebAccess Application. + Use items 13 through 19 on the GroupWise WebAccess Installation Worksheet that you filled out during “Planning the WebAccess Installation” on page 87 to fill in the fields during the WebAccess Application installation process. + Inthe Gateway Directory dialog box, be sure to browse to the WebAccess gateway directory (domain\wpgate\webac60a) through the drive you mapped in Step | above. + Inthe Web Server Information dialog box, be sure to browse to the Web server root directory (sys:\novonyx\suitespot) through the drive you mapped in Step 2 above. + Inthe Start Applications dialog box, deselect Restart Web Server. 6 Make sure you have completed all the WebAccess Application tasks described in “Setting Up GroupWise WebAccess on NetWare or Windows” in “Installing GroupWise WebAccess” in the GroupWise 6.5 Installation Guide. 7 Copy the sys:\novonyx\suitespot\docs\com directory from the node where you just installed the WebAccess Application to the document root directory of the hardware virtual server (WebAccess Clustering Worksheet item 13). Implementing WebAccess in a Novell Cluster 95 8 At the server console, manually restart Java and the Netscape Enterprise Server. NetWare 6.x NetWare 5.1 with Tomcat Servlet Gateway with Novell Servlet Gateway tomcat33 nvxwebup load java nvxwebup 9 In the Cluster State View in ConsoleOne, offline and then online the Netscape Enterprise Server cluster resource, as well as any other Web server cluster resources that run on the node to reestablish their secondary IP addresses. 10 Repeat Step 2 through Step 9 for each node in the WebAccess Application failover path (WebAccess Clustering Worksheet item 13). 11 Continue with “Testing Your Clustered WebAccess Installation” on page 96. Testing Your Clustered WebAccess Installation Remember that the WebAccess Agent volume resource and the Netscape Enterprise Server cluster resource are separate resources that 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 Netscape Enterprise Server cluster resource is functioning properly. 2 Migrate the WebAccess Agent volume resource to each node on its failover path, making sure it functions with the initial Netscape Enterprise Server cluster resource. 3 Migrate the Netscape Enterprise Server cluster resource to a different node, migrate the WebAccess Agent volume resource to each node in its failover path, then make sure each combination works. 4 Repeat Step 3 for each Netscape Enterprise Server cluster resource. Managing WebAccess in a Cluster After you have installed WebAccess in a cluster, you should consider some long-term management issues. + “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 96 + “Knowing What to Expect in MTA and POA Failover Situations” on page 58 + “Updating the WebAccess Agent Configuration File (commegr.cfg)” on page 98 Updating GroupWise Objects with Cluster-Specific Descriptions After installing WebAccess 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 Group Wise 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 77 + “Recording Cluster-Specific Information about the Internet Agent” on page 77 96 GroupWise 6.5 Interoperability Guide Recording Cluster-Specific Information about the WebAccess Agent Domain and Its MTA To permanently record important cluster-specific information for the WebAccess Agent domain: 1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 2 In the Description field of the WebAccess Agent domain Identification page, provide a cluster-specific description of the WebAccess Agent domain, including the secondary IP address of its cluster-enabled volume and the cluster-unique port numbers used by its MTA. You might also want to include cluster-specific information about the WebAccess Application, such as the secondary IP address of the Netscape Enterprise Server cluster resource where the WebAccess Application is installed. Click OK to save the WebAccess Agent domain description. Select the WebAccess Agent Domain object to display its contents. Right-click the MTA object, then click Properties. aoa bh Ww In the Description field of the MTA Identification page, record the secondary IP address of the cluster-enabled WebAccess Agent domain volume and the cluster-unique port numbers used by the MTA. This information will appear 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” on page 77. Recording Cluster-Specific Information about the WebAccess Agent With the contents of the WebAccess Agent domain still displayed: 1 Right-click the WEBAC60A object, then click Properties. 2 Click GroupWise, then click Identification. 3 In the Description field, record the secondary IP address of the cluster-enabled WebAccess Agent domain volume and the cluster-unique port numbers used by the WebAccess Agent. This information will appear on the WebAccess Agent console, no matter which node in the cluster it is currently running on. 4 Click OK to save the WebAccess Agent information. 5 Continue with “Knowing What to Expect in MTA and POA Failover Situations” on page 58. Knowing What to Expect in WebAccess Failover Situations The failover behavior of the MTA for the WebAccess Agent domain will be the same as for an MTA in a regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” on page 58. The WebAccess Application caches users’ credentials on the node where it is running. Therefore, if that node fails, or if the WebAccess Application migrates to a different node, the cached credentials are lost. Consequently, the user will need to restart the WebAccess client in order to re- authenticate and re-establish the credentials. If the WebAccess Agent fails over or migrates, the user receives an error message that the WebAccess Agent is no longer available. However, after the WebAccess Agent starts in its new Implementing WebAccess in a Novell Cluster 97 location, the WebAccess Application passes the cached user credentials to the WebAccess Agent and the user reconnects automatically without having to re-authenticate. As with the MTA and the POA, migration of the WebAccess Agent takes longer than failover. However, the WebAccess Agent restarts quickly so that users are able to reconnect quickly. Updating the WebAccess Agent Configuration File (commgr.cfg) 98 As part of installing WebAccess, the WebAccess Agent configuration file (commgr.cfg) is created in the following subdirectory: domain\wpgate\webac60a It is also automatically copied to the following Web server subdirectory: sys:\novell\webaccess If you change WebAccess agent configuration information (for example, if you change its ip address), the information is changed in the following file: domain\wpgate\webac60a\commer.cfg because the domain is on a cluster-enabled volume, and it is changed in the following file: sys:\novell\webaccess\commegr.cfg on the node where the WebAccess Application is currently running. However, the other nodes on the WebAccess Application failover path are not currently available for update. therefore, you must manually copy the updated commegr.cfg file to the sys:\novell\webaccess subdirectory on each node in the WebAccess Application failover path. GroupWise 6.5 Interoperability Guide WebAccess Clustering Worksheet Item 1) Shared Volume for WebAccess Agent: Cluster Enabled? + Yes (highly recommended) Cluster volume IP address + No 2) WebAccess Agent Domain Name: Domain Database Location: 3) WebAccess Agent Failover Path: 4) MTA Installation Location: ¢ vol:\system on WebAccess Agent volume ¢ sys:\system on each node Consolidate multiple MTA startup files on WebAccess Agent volume? 5) MTA Network Information: + MTA IP address + MTA message transfer port + MTA live remote port + MTA HTTP port 6) WebAccess Agent Installation Location: ¢ vol:\system on the WebAccess Agent volume ¢ sys:\system on each node 7) WebAccess Agent Network Information: + WebAccess Agent IP address + WebAccess Agent HTTP port Explanation Specify the name (cluster_volume) of the shared volume where the WebAccess Agent domain will be created. For cluster-enabling, specify the IP addresses of the virtual server (volume_.cluster) to which the cluster-enabled volume is tied. For more information, see “Deciding Whether to Cluster-Enable the WebAccess Agent Volume” on page 85. Specify a unique name for the WebAccess Agent domain. Specify the directory on the WebAccess Agent volume where you want to create the new domain. For more information, see “Planning a New Domain for the WebAccess Agent” on page 85. List other nodes in the cluster where the WebAccess Agent and its MTA could fail over. For more information, see “Determining an Appropriate Failover Path for the WebAccess Agent Volume” on page 85. Mark the location where you will install the MTA software. If necessary, specify the location where you will consolidate multiple MTA startup files on a WebAccess Agent volume. For more information, see “Deciding Where to Install the WebAccess Agent and Its MTA” on page 86. Gather the MTA network address information from the WebAccess section of the “IP Address Worksheet” on page 34. For more information, see “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 86. Mark the location where you will install the WebAccess Agent software. For more information, see “Deciding Where to Install the WebAccess Agent and Its MTA” on page 86. Gather the WebAccess Agent network address information from the WebAccess section of the “IP Address Worksheet” on page 34. For more information, see “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 86. Implementing WebAccess in a Novell Cluster 99 Item 8) Load WebAccess Agent and Its MTA in Protected Memory? + No + Yes Protected address space names: + MTA: + WebAccess: 9) Physical Web Servers: 10) Netscape Enterprise Server IP Address: 11) Netscape Enterprise Server Mode: + Active/active (highly recommended) + Active/passive 12) Netscape Enterprise Server Failover Path: 13) Hardware Virtual Server Information: + Dedicated IP address: + Document root Explanation Mark whether you need to run the WebAccess Agent and its MTA in protected memory. If so, specify a unique address space for each agent. IMPORTANT: We strongly recommend that you run the WebAccess Agent and its MTA in protected memory. For more information, see “Deciding Whether to Run the WebAccess Agent and Its MTA in Protected Memory” on page 86. List the NetWare servers in the cluster where you are installing the Netscape Enterprise Server for use with WebAccess. For more information, see “Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6” on page 84. Record the secondary IP address for the Netscape Enterprise Server cluster resource, shown in the cluster resource load script. For more information, see “Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6” on page 84. Mark whether the Netscape Enterprise Server runs simultaneously on multiple nodes in the cluster (active/active) or whether it runs on only one node at a time (active/ passive). For more information, see “Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6” on page 84. List other nodes in the cluster where the Netscape Enterprise Server can fail over. The WebAccess Application always fails over along with the Netscape Enterprise Server. For more information, see “Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6” on page 84. Record the hardware virtual server information for your shared disk system. For more information, see “Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6” on page 84. 100 GroupWise 6.5 Interoperability Guide WebAccess Quick Checklist Q) Plan the new clustered WebAccess installation, including the new domain required to house m) m) the WebAccess Agent in a clustering environment. See “Planning WebAccess in a Cluster” on page 83. Install and set up the Netscape Enterprise Web Server for NetWare in the cluster. See “Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6” on page 84. Cluster-enable the volume where the WebAccess Agent domain will reside. See “Cluster-Enabling a Shared Volume for Use with the WebAccess Agent” on page 88. Create the new WebAccess Agent domain. See “Creating a Domain for the WebAccess Agent” on page 89. Set up the MTA for the new WebAccess Agent domain. See “Installing the MTA for the WebAccess Agent Domain” on page 89. Install the WebAccess Agent. See “Installing and Configuring the WebAccess Agent in a Cluster” on page 89. Modify the WebAccess 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 WebAccess 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 WebAccess Agent, separating them with a delay command + Ifyou will run the MTA and the WebAccess 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 WebAccess Agent” on page 90. Modify the WebAccess Agent volume resource unload script: + Add the MTA and WebAccess 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 WebAccess Agent” on page 92. Set up the WebAccess Agent volume failover path and policies. See “Setting the Failover Path and Policies for the WebAccess Agent” on page 94. Add the WebAccess Application to each node where the Netscape Enterprise Server is installed. See “Installing and Configuring the WebAccess Application in a Cluster” on page 95. Implementing WebAccess in a Novell Cluster 1041 0 Test the clustered WebAccess Agent. See “Testing Your Clustered WebAccess Installation” on page 96. QO) Record cluster-specific information in the properties pages of the GroupWise objects associated with the WebAccess Agent. See “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 96. 102 GroupWise 6.5 Interoperability Guide Implementing GroupWise Gateways in a Novell Cluster A significant system configuration difference between a GroupWise® system in a clustering environment and a Group Wise system in a regular environment is that you need to create a separate domain to house each GroupWise gateway. The gateway domain should be created on a cluster- enabled volume. This enables the gateway to fail over independently from other GroupWise components. If you have set up the Internet Agent or WebAccess in your clustered GroupWise system, you should already have the skills necessary to set up a GroupWise gateway as well. Group Wise gateways that have not received recent development have not been thoroughly tested in a clustering environment. If you are currently using such GroupWise gateways, you might want to leave them outside of your cluster. Implementing GroupWise Gateways in a Novell Cluster 103 104 GroupWise 6.5 Interoperability Guide Monitoring a GroupWise System in a Novell Cluster Because the GroupWise® 6.5 Monitor currently runs on Windows NT*/2000, rather than NetWare®, you cannot run GroupWise Monitor in a cluster. However, GroupWise Monitor can easily monitor a clustered GroupWise system from a vantage point outside the cluster. When you first install Monitor, it gathers information about agents to monitor from a domain database (wpdomain.db). This provides the secondary IP address of each agent (the IP address associated with the cluster-enabled volume where the agent’s domain or post office resides). When an agent fails over or migrates to a different node, its status in Monitor displays as Not Listening until it is up and running again, at which time its status returns to Normal. Because Monitor must use secondary IP addresses to monitor the agents in a clustered GroupWise system, the Discover Machine and Discover Network options do not work ina cluster. Secondary IP addresses cannot be obtained by examining the network itself. If you need to add agents to monitor, use the Add Agent option and provide the agent’s secondary IP address. For instructions on setting up GroupWise Monitor, see “Installing GroupWise Monitor” in the GroupWise 6.5 Installation Guide. Monitoring a GroupWise System in a Novell Cluster 105 106 GroupWise 6.5 Interoperability Guide Backing Up a GroupWise System in a Novell Cluster with the GroupWise TSA The GroupWise” Target Service Agent (GWTSA) is a Group Wise-specific API that works with compatible backup software to provide reliable backups of a running GroupWise system. The GWTSA can be used in a clustered GroupWise system with appropriate preparation and understanding of how the GWTSA works. For background information on the GWTSA and a list of compatible backup software, see “GroupWise Target Service Agent ” in “Databases” in the GroupWise 6.5 Administration Guide. In a clustering environment, the GWTSA must be installed and loaded on each node from which your backup software backs up any portion of your GroupWise system. To accommodate the variable locations of data to back up from a clustered Group Wise system, the gwtsa.ncf file of each node should be edited to include a /home startup switch for every domain and post office on every cluster-enabled volume that might ever be mounted on that node. Set the /home startup switch to the physical volume name (without the server name), rather than the cluster-enabled volume name, when specifying the location of each domain and post office. For example: Correct: /home-gwvoll:\gwdom Incorrect: /home-gweluster_gwvoll:\gwdom Before your backup software starts backing up your Group Wise system, it calls on the GWTSA to verify the accessibility of each physical volume specified by the /home startup switch. Your backup software then backs up those domains and post offices that are currently accessible to the GWTSA and skips those that are not accessible. The backup runs successfully, even if some locations are not currently mounted on the node where the GWTSA is running. Locations skipped when backups are run from one node will be caught when backups are run from another node where the GWTSA is also running. If the node where the GWTSA is running goes down, the backup will need to be rerun when the node is up again, unless the nodes where the domain and post office volumes failed over are also configured to back them up. There is currently no way to restart a backup from a checkpoint position. By configuring redundant backup jobs on all nodes where domains and post offices could fail over, you can ensure that domains and post offices are always backed up, regardless of the node they are mounted on when the backup takes place. WARNING: You should not install the GWTSA on the cluster-enabled volumes where domains and post offices are located. The GWTSA cannot currently run in protected memory, nor can it run re-entrantly. If multiple GroupWise volumes failed over to the same node, and if that node attempted to start an instance of the GWTSA for each GroupWise volume, only the first instance would run successfully. Subsequent instances of the GWTSA would fail and the domains and post offices specified for backup by those instances would not be available to your backup software. To restore data in a clustering environment, you must run your backup/restore software on the node where the location to restore is currently mounted. Backing Up a GroupWise System in a Novell Cluster with the GroupWise TSA 107 108 GroupWise 6.5 Interoperability Guide Moving an Existing GroupWise 6.5 System into a Novell Cluster If you are adding the high availability benefits of Novell® Cluster Services™ to a GroupWise® 6.5 system that is already up and running, the first step is to install Novell Cluster Services following the instructions in NetWare Cluster Services Overview and Installation for your version of NetWare®: + NetWare 6.x: “Installation and Setup” + NetWare 5.1: “Installation and Setup” You should also review Chapter 1, “Introduction to GroupWise 6.5 and Novell Cluster Services,” on page 15 to help you apply clustering principles and practices to your GroupWise system. You do not need to transfer your entire GroupWise system into the cluster all at once. You could transfer individual post offices where the needs for high availability are greatest. You could transfer a domain and all of its post offices at the same time. You might decide that you don’t need to have all of your GroupWise system running in the cluster. This section provides a checklist to help you get started with moving your Group Wise system into a clustering environment: Q) Decide which shared volumes in your shared disk system you will use for GroupWise administration (ConsoleOne® and the software distribution directory). Q) Decide which shared volumes in your shared disk system you will use for Group Wise domains and post offices. Q Decide which nodes in your storage area network you will have on failover paths for the Group Wise agents. OQ) Review Chapter 2, “Planning Group Wise in a Novell Cluster,” on page 17. Fill out the “System Clustering Worksheet” on page 32 to help you decide which domains and post offices you will move to which shared volumes. QO) Review “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 25 and fill out the “IP Address Worksheet” on page 34 to select secondary IP addresses for cluster-enabled volumes and to specify cluster-specific port numbers for all of your Group Wise agents. Q) Select the first shared volume that will be part of your clustered GroupWise system and cluster-enable it, following the instructions in “Cluster-Enabling Shared Volumes for Use with GroupWise” on page 37 and “Configuring Short Name Resolution” on page 38. QO) Move a domain and/or post office onto the cluster-enabled volume, following the instructions in “Moving a Domain” in “Domains” or “Moving a Post Office” in “Post Offices” in the GroupWise 6.5 Administration Guide. Moving an Existing GroupWise 6.5 System into a Novell Cluster 109 QO) Review “Deciding How to Install and Configure the Agents in a Cluster” on page 25, fill out the “Agent Clustering Worksheet” on page 35, and install the agents as needed for the first clustered domain and/or post office, following the instructions in “Installing and Configuring the MTA and the POA in a Cluster” on page 44. This includes setting up the load and unload scripts for the cluster-enabled volume. Q) Test the first component of your clustered GroupWise system following the instructions in “Testing Your Clustered GroupWise System” on page 53. Q Take care of the cluster management details described in “Managing Your Clustered GroupWise System” on page 54. Q Move more domains and post offices into the cluster as needed. If you have GroupWise libraries, see “Planning a New Library for a Clustered Post Office” on page 21. Q Move GroupWise administration into the cluster as needed. QO) Add other components to your clustered GroupWise system as needed, following the instructions in: + Chapter 4, “Implementing the Internet Agent in a Novell Cluster,” on page 63 + Chapter 5, “Implementing WebAccess in a Novell Cluster,” on page 83. + Chapter 6, “Implementing GroupWise Gateways in a Novell Cluster,” on page 103 + Chapter 7, “Monitoring a GroupWise System in a Novell Cluster,” on page 105 + Chapter 8, “Backing Up a GroupWise System in a Novell Cluster with the Group Wise TSA,” on page 107 110 GroupWise 6.5 Interoperability Guide Implementing Messenger in a Novell Cluster Novell Messenger does not require the existence of a GroupWise® system in the cluster, but presumably one has already been set up as described in Chapter 2, “Planning GroupWise in a Novell Cluster,” on page 17 and Chapter 3, “Setting Up a Domain and Post Office in a Novell Cluster,” on page 37. As part of the process of setting up GroupWise in the cluster, you filled out the “System Clustering Worksheet” on page 32. Some of the information from that worksheet will be helpful as you implement Messenger in your cluster. + “Planning Your Messenger System in a Cluster” on page 111 + “Setting Up Your Messenger System in a Cluster” on page 114 + “Messenger Clustering Worksheet” on page 119 Planning Your Messenger System in a Cluster Because the Messenger agents are not associated with GroupWise domains or post offices, the Messenger agents are easier to implement in a cluster than are the GroupWise agents. The “Messenger Clustering Worksheet” on page 119 lists all the information you will need as you set up the Messenger agents in a clustering environment. You should print the worksheet and fill it out as you complete the tasks listed below: + “Understanding Your Cluster” on page 111 + “Planning Messenger Administration” on page 111 + “Deciding Where to Install the Messenger Agent Software” on page 112 + “Planning the Messenger Agent Installation” on page 114 Understanding Your Cluster Fill out items 1 through 5 on the “Messenger Clustering Worksheet” on page 119 with information about your cluster. This information corresponds to items 1-5 on the “System Clustering Worksheet” on page 32. For background information, see “Meeting Software Version Requirements” on page 18 and “Installing Novell Cluster Services” on page 19. Planning Messenger Administration If you have set up a cluster-enabled shared volume for GroupWise administration, as described in “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21, you can use the same cluster-enabled shared volume for the Messenger administration files. For example, you might have a shared pub: volume with a \public directory where you install the Messenger snap-in to ConsoleOne®. Or you can install the Messenger snap-in on one or more administrator workstations. Implementing Messenger in a Novell Cluster 111 MESSENGER CLUSTERING WORKSHEET Under Item 6: Installation Location for Messenger Administration, mark where you want to install the Messenger snap-in to ConsoleOne. If you plan to install the Messenger snap-in to ConsoleOne on a cluster-enabled shared volume, under Item 7: Shared Volume for Messenger Administration, list the IP address of the shared volume and the directory where you want to install the Messenger snap-in. IMPORTANT: Cluster-enabling relies on successful short name resolution throughout your system. Review “Ensuring Successful Name Resolution for GroupWise Volumes” on page 23, which describes the issues in the context of planning MTA and POA installations for GroupWise. Deciding Where to Install the Messenger Agent Software When you install the NetWare® Messenger agents in a clustering environment, you can choose between two different installation locations: Location Description Each node The sys:\system directory is the default location provided by the Messenger in the cluster Installation program. Shared volume If you create a vol:\system directory on a cluster-enabled shared volume, the agent software and startup files fail over and back along with supporting files such as the Messenger archive. IMPORTANT: Cluster-enabling relies on successful short name resolution throughout your system. Review “Ensuring Successful Name Resolution for GroupWise Volumes” on page 23, which describes the issues in the context of planning MTA and POA installations for GroupWise. You must install to a cluster-enabled shared volume if you do not want a separate Messenger archive to be created on each node where the Archive Agent runs. If you do not want to use a shared volume, you should plan to install the Archive Agent separately outside the cluster. MESSENGER CLUSTERING WORKSHEET Under Item 8: Installation Location for Messenger Agents, mark where you want to install the Messenger agent software. Continue with the planning instructions for the installation location you want to use: ¢ “Each Node in the Cluster” on page 112 + “Shared Volume” on page 113 Each Node in the Cluster Make sure you have filled out item 5 on the Messenger Clustering Worksheet with a complete list of nodes in the cluster. Continue with “Planning the Messenger Agent Installation” on page 114. 112 GroupWise 6.5 Interoperability Guide Shared Volume For convenience throughout the rest of this section, the term "Messenger volume" means "a cluster-enabled shared volume where the Messenger agents are installed." Complete the following planning tasks for the Massager volume: ¢ “Selecting the Messenger Volume” on page 113 + “Determining an Appropriate Failover Path for the Messenger Volume” on page 113 ¢ “Selecting IP Address Resolution Methods for the Messenger Volume” on page 113 Selecting the Messenger Volume If you are not planning to enable archiving, or if you are not anticipating a large Messenger archive, you can use one Messenger volume. If you anticipate archiving a large number of messages so that the Messenger archive grows very large, you might want to have a separate Messenger volume for the Archive Agent and the archive database. The steps in this section cover setting up the Messenger agents on a single Messenger volume. MESSENGER CLUSTERING WORKSHEET Under Item 9: Shared Volume for Messenger Agents, record the name and IP address of the Messenger volume. Determining an Appropriate Failover Path for the Messenger Volume By default, a Messenger 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 the Messenger volume mounted and active. If a Messenger volume’s preferred node fails, the volume fails over to the next node in the failover path. MESSENGER CLUSTERING WORKSHEET Under Item 10: Failover Path for Messenger Volume, list the nodes that you want to have in the Messenger volume failover path. The Messenger agents might need to run on any node that the Messenger volume fails over to. Selecting IP Address Resolution Methods for the Messenger Volume Because you are using a cluster-enabled volume for the Messenger agents, you must ensure that short name resolution is always successful. For background information, see “Ensuring Successful Name Resolution for GroupWise Volumes” on page 23. MESSENGER CLUSTERING WORKSHEET Under Item 11: IP Address Resolution Methods, 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 the physical network address of the Messenger volume. Implementing Messenger in a Novell Cluster 113 Planning the Messenger Agent Installation Aside from the cluster-specific issues discussed in the preceding sections, the considerations involved in planning to install the Messenger agents are the same in a clustering environment as for any other environment. Review “Planning Your Novell Messenger System”, then print and fill out the “Novell Messenger System Worksheet” in “Installing a Novell Messenger System” in the Messenger 1.0 Installation Guide. Transfer the following information from the Messenger Clustering Worksheet to the Messenger System Worksheet: ¢ For Item 3: Installation Path on the Messenger System Worksheet: ¢ If you are installing the Messenger agents to each node in the cluster, use sys:\system. ¢ If you are installing the Messenger agents to a Messenger volume, use volume:\system, where volume is the name of the Messenger volume from Item 9: Shared Volume for Messenger Administration on the Messenger Clustering Worksheet. + Under Item 12: Server Address on the Messenger System Worksheet: ¢ If you are installing the Messenger agents to each node in the cluster, use the cluster IP address from Item 3: Cluster Identification on the Messenger Clustering Worksheet. ¢ Ifyou are installing the Messenger agents to a Messenger volume, specify the Messenger volume IP address from Item 9: Shared Volume for Messenger Agents on the Messenger Clustering Worksheet. + Under Item 13: Configure Agents for Clustering? on the Messenger System Worksheet, mark Yes. This adds the /cluster switch to the agent startup files. The /cluster switch tells the Messenger agents to use the virtual server name of the cluster or the Messenger volume rather than the specific server name in pathnames obtained from agent object properties in Novell® eDirectory™ or from startup switches.This enables the Messenger agents to access the location no matter which node it is currently running on. This applies to the agents’ working directory, queue directory, log file directory, and so on. + Under Item 14: Admin Configuration on the Messenger System Worksheet: ¢ If you are installing the Messenger snap-in to ConsoleOne to an administrator workstation, use the location where ConsoleOne is already installed (typically c:\novell\consoleone\version_number). ¢ If you are installing the Messenger snap-in to ConsoleOne to a shared volume, use volume:\directory, where volume is the name of the Messenger administration volume from Item 7: Shared Volume for Messenger Administration on the Messenger Clustering Worksheet and directory is typically \public. Continue with “Setting Up Your Messenger System in a Cluster” on page 114. Setting Up Your Messenger System in a Cluster 114 You should have already reviewed “Planning Your Messenger System in a Cluster” on page 111 and filled out the “Messenger Clustering Worksheet” on page 119 and the “Novell Messenger System Worksheet” in the Messenger 1.0 Installation Guide. Follow the instructions for the installation location you have chosen: + “Installing to Each Node in the Cluster” on page 115 + “Installing to a Messenger Volume” on page 115 GroupWise 6.5 Interoperability Guide Installing to Each Node in the Cluster There are two methods of installing the Messenger agents to each node in the cluster: + + Run the Messenger Installation program multiple times in order to install the agent software and to create the agent startup files on each node in the cluster. Run the Messenger Installation program, then copy the Messenger agent software and startup files to each node in the cluster. Use whichever method you prefer, following the steps provided in “Starting the Messenger Installation Program” and “Creating Your Messenger System” in “Installing a Novell Messenger System” in the Messenger 1.0 Installation Guide. Make each node in the cluster active to make sure that the Messenger agents start successfully. Installing to a Messenger Volume Complete the following tasks to set up your Messenger system on a Messenger volume: + + + “Preparing the Cluster for Messenger” on page 115 “Running the Messenger Installation Program” on page 115 “Configuring the Messenger Volume Resource to Load and Unload the Messenger Agents” on page 116 “Copying LDAP and QuickFinder Files to Each Node” on page 117 “Testing Your Clustered Messenger System” on page 117 Preparing the Cluster for Messenger Cluster preparation for Messenger is the same as cluster preparation for GroupWise. Review “Preparing the Cluster for GroupWise” on page 37 before running the Messenger installation program. Running the Messenger Installation Program The Messenger Installation program walks you through setting up your Messenger system and installing the Messenger agents. 1 2 If necessary, map a drive to the Messenger administration volume (Messenger Clustering Worksheet item 7). Map a drive to the Messenger volume (Messenger Clustering Worksheet item 9). The Messenger volume name will be cluster _volume. For assistance with mapping a drive to a cluster-enabled volume, see “Configuring Short Name Resolution” on page 38. Run the Messenger Installation program at an administrator workstation to set up your Messenger system, following the steps provided in “Starting the Messenger Installation Program” and “Creating Your Messenger System” in “Installing a Novell Messenger System” in the Messenger 1.0 Installation Guide. Keep in mind the following cluster-specific details: + When you specify the Messenger installation directory, be sure to browse to the location through the Messenger volume accessed in Step 2 above. + When you specify the ConsoleOne directory, be sure to browse to the location through the Messenger administration volume accessed in Step | above. Implementing Messenger in a Novell Cluster 115 + Onthe Start Copying Files page, the server object name should be the virtual server name, not a physical server name. 4 When you have finished creating your Messenger system, continue with “Configuring the Messenger Volume Resource to Load and Unload the Messenger Agents” on page 116. Configuring the Messenger Volume Resource to Load and Unload the Messenger Agents The properties of the Volume Resource object define how the Messenger volume functions within the cluster, how the Messenger agents are loaded and unloaded, and how failover and failback situations are handled. 1 In ConsoleOne, browse to and select the Cluster object. If necessary, click View > Console 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 Messenger volume. The volume resource load script executes whenever the Messenger volume comes online. 3 Add the following lines to the load script: load volume: \novell\nm\ma\nmma.nlm @volume:novel\nm\ma\strtup.ma load volume: \novell\nm\aa\nmaa.nlm @volume:novel\nm\aa\strtup.aa where volume is the name of the Messenger volume (Messenger Clustering Worksheet item 9). For example: load gwmsgr:\novell\nm\ma\nmma.nlm @gwmsgr:novel\nm\ma\strtup.ma load gwmsg:\novell\nm\aa\nmaa.nlm @gwmsgr:novel\nm\aa\strtup.aa 4 Click apply to save the load script. 5 Click Unload. 6 Add the following lines to the unload script: unload nmma.nlm unload nmaa.nlm 7 Click Apply to save the unload script. 8 Click Nodes to display the default failover path for the Messenger volume. 9 Arrange the nodes in the cluster into the desired failover path for the Messenger volume (Messenger Clustering Worksheet item 10). 10 Click Apply to save the failover path. 11 Click Policies to display the default start, failover, and failback policies. By default, a volume resource: + Fails over automatically if the node it is running on fails ¢ Starts automatically on the net node in its failover path + Continues running at its failover location even after its most preferred node is again available 42 Change the policies if necessary, then click OK. 13 Continue with “Copying LDAP and QuickFinder Files to Each Node” on page 117. 116 GroupWise 6.5 Interoperability Guide Copying LDAP and QuickFinder Files to Each Node During installation of the Messenger agents, some files were copied to sys:\system of the node where the Messenger volume was mounted. These files must be copied to sys:\system on each node of the cluster. Copy the following files from the Novell GroupWise Messenger CD to sys:\system on each node in the cluster: \server\nIm\Idap\ldapsdk.nlm \server\nlm\Idap\Idapssl.nlm \server\nlm\ldap\ldapx.nlm \server\nlm\qf\qfind215.nlm If you are running in a language other than English, copy the following files from the CD to sys:\system\nls\language on each node in the cluster: \server\nlm\/anguage\* msg \server\nlm\/anguage\* .hlp where language is a two-letter language code. Continue with “Testing Your Clustered Messenger System” on page 117. Testing Your Clustered Messenger System After you have configured the Messenger volume resource, you can test the load and unload scripts by bringing the Messenger volume online and taking it offline again. 1 In ConsoleOne, select the Cluster object, then click View > Cluster State. Cluster State | Event Log | HTML Report] p gw-cluster Epoch 1 Connected GW-CLUSTER1 GW-CLUSTER2 Nodes Available (%) Resources Available (%) ~; 0 20 40 60 80 100 0 20 40 60 80 100 Cluster Resource State Location #Lives | @ GWVOL_SERVER | Offline GW-CLUSTER1 2 | @ ILVOL_SERVER Running GW-CLUSTER1 2 | The new Messenger volume resource shows Offline in the State column. 2 Click the new Messenger volume resource, then click Online. Cluster State | Event Log | HTML Report| p gw-cluster Epoch 1 Connected GW-CLUSTER1 GW-CLUSTER2 Nodes Available (%) Resources Available ($) 0 20 40 60 80 100 0 20 40 60 80 100 Cluster Resource State Location @ GWVOL_SERVER | Running GW-CLUSTER1 @ ILVOL_SERVER Running GW-CLUSTER1 Implementing Messenger in a Novell Cluster 117 The State column for the volume resource now displays Running. 3 Observe the server console where the Messenger agents are loading to see that they start and run correctly. 4 Click the new Messenger volume resource, then click Offline. The State column for the volume resource returns to Offline. 5 Observe the server console where the Messenger agents are unloading to see that they shut down correctly. 6 Repeat Step 2 whenever you are ready to bring the new Messenger volume resource online permanently. On NetWare 6.x, these actions can also be performed from your Web browser. See “Using NetWare Remote Manager on NetWare 6.x” on page 55. 118 GroupWise 6.5 Interoperability Guide Messenger Clustering Worksheet Item 1) Software Version Updates for Cluster: + Support Pack 3 or higher for NetWare 5.1 + Latest ConsoleOne Snap-In for Novell Cluster Services™ 2) eDirectory Tree for Cluster: 3) Cluster Identification: Cluster Name: Cluster IP Address: 4) Cluster Context: 5) Nodes in Cluster 6) Installation Location for Messenger Administration: + Administrator workstation(s) + Shared volume 7) Shared Volume for Messenger Administration: Cluster Volume IP Address: Installation Location for Messenger Snap-In to ConsoleOne: ¢ /public directory + Other directory 8) Installation Location for Messenger Agents: + Each node in the cluster + Shared volume Explanation Mark any updates that the nodes in your cluster need in order to meet the system requirements for Messenger system in a cluster. To review the background information provided for GroupWise clustering, see “Meeting Software Version Requirements” on page 18. Record the eDirectory tree where you created the Novell Cluster object when you installed Novell Cluster Services. To review the background information provided for GroupWise clustering, see “Installing Novell Cluster Services” on page 19. Record the name of the name of the NetWare Cluster object where your Messenger system will be located. Also record the virtual IP address of the cluster that will remain constant regardless of which node is currently active. To review the background information provided for GroupWise clustering, see “Installing Novell Cluster Services” on page 19. Record the full context where you created the NetWare Cluster object. To review the background information provided for GroupWise clustering, see “Installing Novell Cluster Services” on page 19. List the nodes that are part of the cluster. To review the background information provided for GroupWise clustering, see “Installing Novell Cluster Services” on page 19. Mark the location where you will install the Messenger snap-in to ConsoleOne. For more information, see “Planning Messenger Administration” on page 111. If you plan to install the Messenger snap-in to ConsoleOne on a shared volume, specify the name (cluster_volume) of the shared volume where you will install it. Specify the IP addresses of the virtual server (volume_SERVER.cluster) to which the shared volume is tied. Specify the directory where you will install the Messenger snap-in to ConsoleOne on the shared volume. To review the background information about cluster-enabled volumes provided for GroupWise, see “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21. Mark the location where you will install the Messaging Agent software. For more information, see “Deciding Where to Install the Messenger Agent Software” on page 112. Implementing Messenger in a Novell Cluster 119 Item 9) Shared Volume for Messenger Agents: Cluster volume IP address: 10) Failover Path for Messenger Shared Volume: 11) IP Address Resolution Methods: + eDirectory + hosts file « DNS + SLP (highly recommended) 120 GroupWise 6.5 Interoperability Guide Explanation If you plan to install the Messenger agents on a shared volume, specify the name (cluster_volume) of the shared volume. Specify the IP address of the virtual server (volume_SERVER.cluster) to which the cluster-enabled volume is tied. To review the background information about cluster-enabled volumes provided for GroupWise, see “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21. For more information, see “Selecting the Messenger Volume” on page 113. If you plan to install the Messenger agents on a shared volume, list other nodes in the cluster where the Messenger agents could fail over. For more information, see “Determining an Appropriate Failover Path for the Messenger Volume” on page 113. 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. To review the background information provided for GroupWise, see “Ensuring Successful Name Resolution for GroupWise Volumes” on page 23. GroupWise DirXML Driver for Novell Identity Manager The GroupWise” DirXML® driver for use with Novell® Identity Manager provides data integration between users in Novell eDirectory™ with GroupWise accounts in your GroupWise system. For example, the driver can create e-mail accounts automatically when employees are hired. The driver can also disable an e-mail account when a user is no longer active. This configurable solution gives your the ability to increase productivity and streamline business processes by integrating GroupWise and eDirectory. This guide gives information about certain administrative actions in ConsoleOne® that require you to stop the GroupWise DirXML driver or disable a user’s association: + Chapter 11, “Identity Manager Warnings in ConsoleOne,” on page 123 For additional information, see: + Novell Identity Manager (http://www.novell.com/documentation/dirxml20) ¢ Identity Manager Drivers (http://www.novell.com/documentation/dirxmldrivers) GroupWise DirXML Driver for Novell Identity Manager 121 122 GroupWise 6.5 Interoperability Guide Identity Manager Warnings in ConsoleOne Some GroupWise administrative actions in ConsoleOne require that you stop the GroupWise DirXML driver or disable a user’s association with it before you perform the action and usually restart the GroupWise DirXML driver or re-enable the user’s association when you have completed the action. By default, these activities generate a warning message in ConsoleOne: + + + + “Recovering a Deleted GroupWise Account” on page 123 “Grafting Users” on page 123 “Converting an External Entity to a User” on page 124 “Converting a User to an External Entity” on page 124 “Associating a GroupWise Object with an eDirectory Object” on page 124 “Disassociating a GroupWise Object’s Attributes from an eDirectory Object” on page 124 “Resolving an Invalid Association” on page 124 “Disabling the DirXML Warnings” on page 124 “Enabling the DirXML Warnings” on page 125 Recovering a Deleted GroupWise Account 1 2 3 Grafting Users 1 2 Using the DirXML Management role in Novell iManager, stop the GroupWise DirXML driver. Recover the deleted account, as described in “Recovering Deleted GroupWise Accounts” in “Databases” in the Group Wise 6.5 Administration Guide. Using the DirXML Management role, restart the GroupWise DirXML driver. If you are grafting the users into a different eDirectory tree, on the DirXML tab of each User object in Novell iManager, disable the association with the GroupWise DirXML driver. Using the DirXML Management role in Novell iManager, stop the GroupWise DirXML driver for the tree into which you are grafting the users. Graft the users, as described in “Graft GroupWise Objects” in “Databases” in the GroupWise 6.5 Administration Guide. If you grafted the users into a different eDirectory tree, on the DirXML tab of each User object, enable the association with the GroupWise DirXML driver in the new tree. Using the DirXML Management role, restart the GroupWise DirXML driver for the tree into which you grafted the users. Identity Manager Warnings in ConsoleOne 123 Converting an External Entity to a User 1 Using the DirXML Management role in Novell iManager, stop the GroupWise DirXML driver. 2 Convert the external entity, as described in “Convert External Entity to User” in “System” in the GroupWise 6.5 Administration Guide. 3 Using the DirXML Management role, restart the GroupWise DirXML driver. Converting a User to an External Entity 1 On the DirXML tab of the User object in Novell iManager, disable the association with the GroupWise DirXML driver. 2 Convert the user, as described in “Convert User to External Entity” in “System” in the GroupWise 6.5 Administration Guide. Associating a GroupWise Object with an eDirectory Object 1 Using the DirXML Management role in Novell iManager, stop the GroupWise DirXML driver. 2 Establish the association, as described in “Associate Objects” in “System” in the GroupWise 6.5 Administration Guide. 3 Using the DirXML Management role, restart the GroupWise DirXML driver. Disassociating a GroupWise Object’s Attributes from an eDirectory Object 1 On the DirXML tab of the User object in Novell iManager, disable the association with the GroupWise DirXML driver. 2 Disassociate the objects, as described in “Disassociate GroupWise Attributes” in “System” in the GroupWise 6.5 Administration Guide. 3 On the DirXML tab of the User object, enable the association with the GroupWise DirXx ML driver. Resolving an Invalid Association 1 On the DirXML tab of the User object in Novell iManager, disable the association with the GroupWise DirXML driver. 2 Resolve the invalid association, as described in “Invalid Associations” in “System” in the GroupWise 6.5 Administration Guide. Disabling the DirXML Warnings 1 In ConsoleOne, deselect Display DirXML Warnings in any DirXML warning dialog box. 124 GroupWise 6.5 Interoperability Guide Enabling the DirXML Warnings 1 In ConsoleOne, click Tools > GroupWise System Operations > System Preferences. 2 On the Admin Preferences tab, select Display DirXML Warnings. 3 Click OK. Identity Manager Warnings in ConsoleOne 125 126 GroupWise 6.5 Interoperability Guide GroupWise Customization Tools The GroupWise” Software Developer Kit provides tools for customizing GroupWise to the specific needs of your organization. It includes the following components: + WebAccess Customization: Lets you modify the WebAccess client HTML source files to include your own graphics or company information. You can also enhance the WebAccess client by creating additional calendar views. For more information, see Group Wise WebAccess Customization (http://developer.novell.com/ndk/gwwbacc.htm). + GroupWise Object API: Lets you create your own client application. It provides access to the Address Book, along with documents, mail messages, appointments, tasks, notes, phone messages, and workflow items. GroupWise Object API supports COM Automation, which is an industry standard for interfacing applications and is simple to use with languages such as Delphi*, Visual Basic*, and C++. For more information, see GroupWise Object API (http:// developer.novell.com/ndk/gwobjapi.htm). + GroupWise Administrative Object API: Lets you see, use, and manipulate Group Wise administration information from outside GroupWise. You can use GroupWise Administrative Object API through COM languages, such as Visual Basic, Delphi, and object-oriented languages (such as C++). It also supports COM Automation, which is an industry standard for interfacing applications. For more information, see GroupWise Administrative Object API (http://developer.novell.com/ndk/gwadmin.htm). + GroupWise C3PO: Works with C++, Delphi, or Visual Basic to let you add menu and toolbar items to trigger applications. For example, you can modify the GroupWise client toolbar or define new record types in the GroupWise information store. C3PO™ stands for Custom 3rd- Party Object™. For more information, see GroupWise C3PO (http://developer.novell.com/ ndk/gwe3po.htm). + GroupWise Tokens: Let you manipulate the GroupWise client interface by subscribing to internal token events or by publishing new tokens to the client. It names low-level events, such as "save a file" or "send mail," which allows you to extend GroupWise functionality. While a C3PO lets you extend Group Wise objects and the Object API lets you see and manipulate the Group Wise information store from outside GroupWise, tokens let your solution command the Group Wise client from DLLs and DDE scripts, using the Third-Party Handler. You can also use tokens to create Visual Basic executables that users can run from the client interface. For more information, see GroupWise Tokens (http://developer.novell.com/ndk/gwtoken.htm). + GroupWise MAPI: Uses a set of object-oriented functions that provide messaging capabilities. Messaging Application Programming Interface (MAPI) is used by mail-enabled applications to create, transfer, and store messages, as well as to handle complex addressing information. MAPI objects are data structures that support a set of properties and that comply with the component object model (which requires that objects support one or more interfaces or sets of functions). For more information, see GroupWise MAPI (http:// developer.novell.com/ndk/gwmapi.htm). GroupWise Customization Tools 127 + GroupWise Controls for ActiveX: Lets you embed an Address Book or Name Completion COM Control (OCX) in your Visual Basic, Delphi, and C++ solutions. OCX properties let you customize user access to Address Book contents and control return information for your solution to use. For more information, see GroupWise Controls for ActiveX (http:// developer.novell.com/ndk/gwactive.htm). 128 GroupWise 6.5 Interoperability Guide Microsoft Clustering Services Chapter 12, “Introduction to GroupWise 6.5 and Microsoft Clusters,” on page 131 Chapter 13, “Planning GroupWise in a Microsoft Cluster,” on page 133 Chapter 14, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149 Chapter 15, “Implementing the Internet Agent in a Microsoft Cluster,” on page 161 Chapter 16, “Implementing WebAccess in a Microsoft Cluster,” on page 171 Chapter 17, “Implementing GroupWise Gateways in a Microsoft Cluster,” on page 183 Chapter 18, “Monitoring a GroupWise System in a Microsoft Cluster,” on page 185 Chapter 19, “Backing Up a GroupWise System in a Microsoft Cluster,” on page 187 Chapter 20, “Moving an Existing GroupWise 6.5 System into a Microsoft Cluster,” on page 189 Chapter 21, “Implementing Messenger in a Microsoft Cluster,” on page 191 Microsoft Clustering Services 129 130 GroupWise 6.5 Interoperability Guide Introduction to GroupWise 6.5 and Microsoft Clusters Before implementing GroupWise” 6.5 in a Microsoft* cluster, make sure you have a solid understanding of Microsoft clustering technologies by reviewing the following information resources: + Cluster Technologies Community Center (http://www.microsoft.com/windowsserver2003/ community/centers/clustering/more_resources.asp) + Windows* 2003 Clustering Services (http://www.microsoft.com/windowsserver2003/ technologies/clustering/default.mspx) + Windows 2000 Clustering Technologies (http://www.microsoft.com/windows2000/ technologies/clustering/default.asp) 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 two to eight Windows servers configured so that data storage locations and applications can transfer from one server to another without interrupting their availability to users. node: A clustered server; in other words, a single Windows server that is part of a cluster. active node: A node in the cluster that is actively running programs. An active node makes its resources available in the cluster. passive node: A node in the cluster that is not currently running programs, but is waiting for an active node to fail. A passive node does not make its resources available in the cluster until an active node fails over to it. resource: A data storage location or application. For example, a domain directory and the MTA for the domain are resources. A post office directory and the POA for the post office are resources. resource group: Two or more resources that must fail over together in order to remain functional. For example, for a domain to be functional, the domain directory and its MTA must fail over together. For a post office to be functional, the post office directory and its POA must fail over together physical disk: The physical location where resources are created or installed. For example, a domain or post office directory is created on a physical disk. The agent software is installed on a physical disk. shared disk: A physical disk that can be made active on any node in the cluster. failover: The process of moving resources and resource groups on a shared disk 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 post office resource group would fail over to another node so that users could continue to use GroupWise. Introduction to GroupWise 6.5 and Microsoft Clusters 131 fan-out-failover: The configuration where resources and resource groups from a failed node fail over to different nodes in order to distribute the load from the failed node across multiple nodes in the cluster. For example, if a node runs a resource group consisting of a domain and its MTA, another resource group consisting of a post office and its POA, and a third resource group for WebAccess, each resource group could be configured to fail over separately to different nodes in the cluster. failback: The process of returning resources and resource groups to their original node after the situation causing the failover has been resolved. For example, if a POA and its post office fail over to another node in the cluster, that resource group can be configured to fail back to its original node when the problem is resolved. shared disk system: The hardware housing the physical disks that are shared among the nodes in the cluster. The C: drives in the clustered nodes are not part of the shared disk system. Each C: drive belongs to its own server. storage area network (SAN): The clustered nodes together with their shared disk system and shared physical disks. 132 GroupWise 6.5 Interoperability Guide Planning GroupWise in a Microsoft Cluster The majority of this guide (Chapter 13, “Planning Group Wise in a Microsoft Cluster,” on page 133 through Chapter 19, “Backing Up a GroupWise System in a Microsoft Cluster,” on page 187) is designed for those who are creating a new GroupWise® system, or at least new domains and post offices, in a Microsoft cluster. If you already have an existing Group Wise 6.x system and need to configure it to work in a newly installed cluster, see Chapter 20, “Moving an Existing Group Wise 6.5 System into a Microsoft Cluster,” on page 189. When you implement a new GroupWise system or a new domain or post office in a Microsoft cluster, overall Group Wise system design does not need to change substantially. For a review, see “Installing a Basic GroupWise System” in the GroupWise 6.5 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 Microsoft 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) During the planning process, component configuration alternatives will be explained. For example, you might want the domain and post office together in the same resource group or in separate resource groups. You might want to install the agents to the standard c:\grpwise directory on each node or to manually create a drive:\grpwise directory for each shared disk for domains and post offices so that the agents fail over with the domains and post offices they service. The “System Clustering Worksheet” on page 144 lists all the information you will need as you set up GroupWise in a Microsoft cluster. You should print the worksheet and fill it out as you complete the tasks listed below: ¢ “Setting Up Your Microsoft Cluster” on page 134 + “Planning a New Clustered Domain” on page 134 ¢ “Planning a New Clustered Post Office” on page 135 + “Planning a Library for a New Clustered Post Office” on page 135 + “Planning GroupWise Resource Groups” on page 136 + “Planning Shared Administrative Resources” on page 137 + “Ensuring Successful Name Resolution for GroupWise Resource Groups” on page 137 ¢ “Deciding How to Install and Configure the Agents in a Cluster” on page 139 + “GroupWise Clustering Worksheets” on page 144 After you have completed the tasks and filled out the “System Clustering Worksheet” on page 144, you will be ready to continue with Chapter 14, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149. Planning GroupWise in a Microsoft Cluster 133 Setting Up Your Microsoft Cluster As you set up your Microsoft cluster, record key information about the cluster on the System Clustering Worksheet: SYSTEM CLUSTERING WORKSHEET Under Item 1: Cluster Name, record the name of your Microsoft cluster. Under Item 2: Nodes in Cluster, list the servers that you have added to the cluster. The number of nodes in the cluster will strongly influence 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 the cluster, 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 in a cluster. + Ina like manner, WebAccess provides user access to GroupWise mailboxes across the Internet through users’ Web browsers. It is another good candidate for the cluster. + Domains and their MTAs are less noticeable to GroupWise client 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 Group Wise administrators, although administrators might be more tolerant of a down server than client users are. Critical domains in your GroupWise system are 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. + 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 Group Wise in a cluster. It all depends on the specific needs of your particular GroupWise system and its users. Planning a New Clustered Domain The considerations involved in planning a new domain in a Microsoft cluster are essentially the same as for any other environment. ¢ Primary Domain: If you are setting up a new GroupWise system in a Microsoft cluster, 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 134 GroupWise 6.5 Interoperability Guide 6.5 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 6.5 Administration Guide. 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 disk 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 Group Wise 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 Group Wise System Worksheet or the Domain Worksheet to the System Clustering Worksheet. SYSTEM CLUSTERING WORKSHEET Under Item 7: Domain Name, transfer the domain name and directory to the System Clustering Worksheet. 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 Novell Cluster,” on page 37. Planning a New Clustered Post Office The considerations involved in planning a new post office in a Microsoft cluster are essentially the same as for any other environment. The initial post office in a new GroupWise system is planned on the Basic Group Wise 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 6.5 Administration Guide. When you specify the locations for the post office directories, include the shared disks 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 8: Post Office Name, transfer the post office name and directory to the System Clustering Worksheet. 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 Novell Cluster,” on page 37. Planning a Library for a New Clustered Post Office The considerations involved in planning a library in a Microsoft cluster are essentially the same as for any other environment. You can plan a library for a new clustered post office by following the standard instructions provided in “Creating and Managing Libraries” in the GroupWise 6.5 Administration Guide and filling out the “Basic Library Worksheet” or the “Full-Service Library Worksheet”. Then provide the library information on the System Clustering Worksheet. Planning GroupWise in a Microsoft Cluster 135 SYSTEM CLUSTERING WORKSHEET Under Item 9: Document Storage Area 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 and outside the cluster, specify a user name and password that the POA can use to access the server 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 Novell Cluster,” on page 37. Planning GroupWise Resource Groups Resource groups ensure that resources that depend on each other fail over together. If your Group Wise system is very small (for example, one domain and one post office), you could have a single GroupWise resource group so that your whole Group Wise system would fail over together. More typically, multiple domains and post offices are located throughout your organization, so you would set up a resource group for each domain and post office. A resource group for a domain or post office must include the following types of resources: + Network Name: The virtual name by which the domain or post office resource group will be known on the network, regardless of which node it is active on + IP Address: The virtual IP address that will be associated with the network name, regardless of which node the domain or post office resource group is active on ¢ Physical Disk: The drive letter where the domain or post office directory will be located, used when mapping a drive to the physical disk ¢ File Share: The name of the physical disk, used when mapping a drive to the physical disk + Generic Service: The GroupWise agent, running as a Windows service, that will service the domain or post office For convenience, you might want to name each resource group after the domain or post office it represents. In this documentation, a resource group that could include a domain, a post office, or both, is termed a "GroupWise resource group." Each Group Wise resource group has associated with it a list of possible owners. The possible owners are the nodes to which the resource group could fail over. By default, a resource group is configured to have all nodes in the cluster in its possible owners list, organized in ascending alphanumeric order. Only one node at a time can have a particular GroupWise resource group active. Ifa resource group’s current owner node fails, the resource group fails over to the next node in the possible owners list. You will want to customize the owners list for each GroupWise resource group based on the fan-out-failover principle. When a node fails, its resource groups should not all fail over together to the same node in the cluster. Instead, the resource groups should be distributed across multiple nodes throughout the cluster. This prevents any one node from shouldering the entire processing load typically carried by another node. In addition, some GroupWise resource groups should never have the potential of failing over to the same node. 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. 136 GroupWise 6.5 Interoperability Guide SYSTEM CLUSTERING WORKSHEET Under Item 4: Resource Group for Domain, specify the network name and other required information for the domain resource group. Mark whether you will place the post office in the same resource group with the domain. If you want the post office in a different resource group from where the domain is located, under Item 5: Resource Group for Post Office, specify the network name and other required information for the post office resource group. Planning Shared Administrative Resources Depending on your administrative needs, you might or might not want to set up shared administrative resources. For example, you might want to have a shared disk where you install the GroupWise snap-ins to ConsoleOne® instead of installing them on multiple administrator workstations. You might also have a shared disk where you create the GroupWise software distribution directory. These shared disks could be configured to fail over as part of your clustered environment. SYSTEM CLUSTERING WORKSHEET Under Item 3: Resources for GroupWise Administration, list any shared disks you want to use for GroupWise administration purposes. Ensuring Successful Name Resolution for GroupWise Resource Groups When you establish Group Wise resource groups, you establish network names for the locations of domains and post offices. The network names remain constant no matter which node in the cluster the domain or post office is currently active on. Because you are using virtual network names, not physical locations, 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 name of that domain within your cluster. It is through short name resolution that all GroupWise resource groups are accessed and managed in ConsoleOne. 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™ that is installed on the Windows workstation: Planning GroupWise in a Microsoft Cluster 137 Novell Client for Windows 2000 Properties 2 xi Single Sign-on | DHCP Settings | Default Capture | Advanced Settings | Advanced Menu Settings | Client | Location Profiles | Advanced Login | Contextless Login | Protocol Preferences | Service Location Select a protocol and component to configure Preferred Network Protocol: z Protocol: Component: A Protocol component settings- MINDS M Host File MIDNS Z SLP CO DHCP NDS Short name resolution methods that pertain to your clustered GroupWise system are discussed below: Short Name Description Resolution Method eDirectory You can use Novell 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. Hosts Files Windows uses the following files when performing short name resolution at the workstation: + Windows NT/2000/XP: \winnt\system32\drivers\etc\hosts + Windows 9.x: \novell\client32\nwhosts Using these files at the Windows workstation is not a preferred method for short name resolution (except perhaps for the administrator's workstation). 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 the network names of your GroupWise resource groups into DNS. For short name resolution to work using DNS, the client workstation must either belong to the same DNS zone (such as support.novell.com) as the resource group, or the cluster resource zone must be configured in the client's DNS suffix search path under TCP/IP settings for the workstation. Specific setup instructions for each of these short name resolution methods will be provided in Chapter 14, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149. 138 GroupWise 6.5 Interoperability Guide SYSTEM CLUSTERING WORKSHEET Under Item 6: IP Address Resolution Methods, mark which methods you want to implement in order to resolve the locations stored as UNC paths in ConsoleOne into the network names of the GroupWise resource groups. 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 Windows MTA and POA in your clustered GroupWise system: + “Planning Cluster-Unique Port Numbers for Agents in the Cluster” on page 139 + “Deciding Where to Install the Agent Software” on page 141 + “Planning the Agent Services” on page 142 + “Planning the Windows Agent Installation” on page 143 Planning Cluster-Unique Port Numbers for Agents in the Cluster By default, the GroupWise agents listen on all IP addresses, both primary and secondary, that are bound to the server on their specified port numbers. The primary IP address is the IP address of the physical node. Secondary IP addresses are the IP addresses associated with Group Wise resource groups. Any time there is a possibility of two of the same type of agent running on the same node, it is important that each agent use a cluster-unique port number, even though each agent is using the unique IP address established for each Group Wise resource group. 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 “Network Address Worksheet” on page 146 to help you plan cluster-unique port numbers for all GroupWise agents in your Group Wise system. The following filled-out version of the Network Address Worksheet illustrates one way this can be done: Domain Information MTA MTA MTA IP Address MTP Port HTTP Port 123.45.67.81 7100 7180 Post Office Information Post Office POA POA POA POA IP Address C/S Port MTP Port HTTP Port Development (same as MTA 1677 7101 7181 Manufacturing 123.45.67.82 1678 7102 7182 Planning GroupWise in a Microsoft Cluster 139 Internet Agent Information Internet Agent GWIA MTA MTA Live MTA GWIA IP Address MTP Port Remote Port HTTP Port| HTTP Port GWIA Domain 123.45.67.83 7110 7677 7183 MTA Internet Agent (same as MTA) N/A N/A N/A 9850 (GWIA) WebAccess Information WebAccess Agent | WebAccess MTA MTA WebAccess WebAccess IP Address MTP Port | HTTP Port | Agent Port HTTP Port WebAccess 123.45.67.84 7120 7184 N/A N/A Domain MTA WebAccess (same as MTA) N/A N/A 7205 7205 Agent (same as agent) (GWINTER) This example places the Development post office in the same resource group with the Provol domain; therefore, the Provol MTA and the Development POA use the same IP address. The Manufacturing post office is placed in a different resource group; so the Manufacturing post office has a different IP address. The Internet Agent and the WebAccess Agent each have their own domains and separate resource groups. 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 and specify the IP address of the post office resource group, not the IP address of a specific node. For more information, see “Simplifying Client/Server Access with a GroupWise Name Server” in “Post Office Agent” in the GroupWise 6.5 Administration Guide. NETWORK ADDRESS WORKSHEET Fill out the “Network Address Worksheet’ on page 146 to help you determine resource group IP addresses and cluster-unique port numbers for all GroupWise agents in the cluster. (MTA, POA, Internet Agent, WebAccess Agent). Refer to the IP addresses you planned for the domain and post office resource groups under items 4 and 5 on the System Clustering Worksheet. 140 GroupWise 6.5 Interoperability Guide After you have filled out the Network Address Worksheet, transfer the IP addresses and the cluster- unique port numbers from the Network Address Worksheet to the Agent Clustering Worksheet so that they will be available in the sequence in which you will need them as you set up the GroupWise agents in the cluster. AGENT CLUSTERING WORKSHEET Under Item 4: MTA Network Information, transfer the resource group IP address and cluster-unique port numbers for the MTA from the Network Address Worksheet to the Agent Clustering Worksheet. Under Item 7: POA Network Information, transfer the resource group IP address and cluster-unique port numbers for the POA from the Network Address Worksheet to the Agent Clustering Worksheet. Deciding Where to Install the Agent Software In a Microsoft cluster, the agents must run as Windows services. When you install the Windows MTA and POA, you can choose between two different installation locations: Location Description Each node in the The c:\grpwise directory is the default location provided by the Agent Installation cluster program. Shared disk If you create a drive:\grpwise directory on the same shared disk with the domain or post office directory, the agent software and startup files fail over and back with the domains and post offices that the agents service. Because the agents must be installed as Windows services in a Microsoft cluster, you must initially run the Agent Installation program for each node in the cluster so that the Windows services for the agents get created, regardless of where you are planning to run the agents from. However, for updates, you need to run the Agent Installation program only once if you are running the agents from a shared disk. The following sections can help you choose which installation location would be best for your clustered GroupWise system: e “Advantages of Installing to a Shared Disk” on page 141 ¢ “Disadvantages of Installing to a Shared Disk” on page 142 + “Recommendation” on page 142 Advantages of Installing to a Shared Disk Using a drive:\grpwise directory for each GroupWise shared disk has several advantages: + 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 in the resource group’s possible owners list. This prevents the potential problem of having a domain or post office fail over to a node where a different version of the agent software is installed. + Having the agent startup files on the same node as the domain or post office makes them easy to find. ¢ If you change information in the agent startup files, you only need to change it in one place, not on every node in the resource group’s possible owners list. + If you want to back up the GroupWise data, you can back up the domain and/or post office directories and the agent software from the same shared disk. Planning GroupWise in a Microsoft Cluster 141 Disadvantages of Installing to a Shared Disk Recommendation Installing the agents on the same shared disk with a domain or post office does have some disadvantages: + You must install the agent software each time you create a new domain or post office on a new shared disk. + GroupWise administrators who are used to the Group Wise agents being installed in c:\grpwise 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 c:\grpwise on the active node would not have the desired results if the original agent software was installed to a shared disk. Whichever method you choose, be consistent throughout the entire cluster. Either put all the Group Wise agents on the shared disks with the domains and post offices they service, or put them all in c:\grpwise directories on all nodes. If you put them on shared disks with domains and post offices, make sure there are no agent files in c:\grpwise directories on nodes to confuse the issue at a later time. Even if you choose to install the agents to the c:\grpwise directory of multiple nodes, you can still store the agent startup files on shared disks with the domains and post offices. 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 the shared disk with a domain or post office, or to 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, shared disk, and directory from the System Clustering Worksheet to the Agent Clustering Worksheet. Under Item 5: Post Office Name, transfer the post office name, shared disk, and directory from the System Clustering Worksheet to the Agent Clustering Worksheet. Planning the Agent Services In a Microsoft cluster, the MTA and POA must be set up as service resources. A service resource for a GroupWise agent must include the following information: + Name: The name by which the agent service will be listed in the resource group (for example, MTA Service or POA Service) + Possible Owners: The list of nodes in the cluster to which the Group Wise agent can fail over (the same as the possible owners of the resource group to which the agent service belongs) + Resource Dependencies: Other resources in the resource group that must be online before the GroupWise agent can start on a new node (for example, the Group IP Address resource and the Physical Disk resource where the domain or post office directory is located) 142 GroupWise 6.5 Interoperability Guide AGENT CLUSTERING WORKSHEET Under Item 3: MTA Service Resource, specify the MTA service resource name and list any possible resource dependencies. Under Item 6: POA Service Resource, specify the POA service resource name and list any possible resource dependencies. Planning the Windows Agent Installation Aside from the cluster-specific issues discussed in the preceding sections, the considerations involved in planning to install the GroupWise Windows agents are the same in a Microsoft cluster as in any other environment. Review “Planning the GroupWise Agents”, then print and fill out the “Group Wise Agent Installation Worksheet” in “Installing GroupWise Agents” in the GroupWise 6.5 Installation Guide for each location where you will install the Windows MTA and/or POA. Fill out the Windows 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. Ina Microsoft cluster, a domain or post office and its agent must be located on the same node 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 141. Under Item 8: Installation Options, mark Install as Windows Services. Under Item 6: Domains and Item 7: Post Offices, refer to the Domain and Post Office Worksheets you filled out during “Planning a New Clustered Domain” on page 134 and “Planning a New Clustered Post Office” on page 135, and to the Network Address Worksheet you completed during “Planning Cluster- Unique Port Numbers for Agents in the Cluster” on page 139. IMPORTANT: Do not install the Windows agent software until you are instructed to do so in Chapter 14, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149. Continue with Chapter 14, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149. Planning GroupWise in a Microsoft Cluster 143 GroupWise Clustering Worksheets ¢ “System Clustering Worksheet” on page 144 + “Network Address Worksheet” on page 146 + “Agent Clustering Worksheet” on page 147 System Clustering Worksheet Item 1) Cluster Name: 2) Nodes in Cluster: 3) Resources for GroupWise Administration: ConsoleOne: Shared disk: Possible owners: Software Distribution Directory: Shared disk: Possible owners: 4) Resource Group for Domain: Network name: IP address: Physical disk: File share: MTA service: Possible owners Post Office in Same Resource Group as Domain? + Yes + No 5) Resource Group for Post Office: Network name: IP address: Physical disk: File share: MTA service: Possible owners 144 GroupWise 6.5 Interoperability Guide Explanation Record the name of the name of your Microsoft cluster. For more information, see “Setting Up Your Microsoft Cluster” on page 134. List the servers that are part of the cluster that you set up for your GroupWise system. For more information, see “Setting Up Your Microsoft Cluster” on page 134. List any shared locations that you want to set up for ConsoleOne or the software distribution directory. For more information, see “Planning Shared Administrative Resources” on page 137. Specify the information for the domain resource group. For more information, see “Planning a New Clustered Domain” on page 134. Specify the information for the post office resource group. For more information, see “Planning a New Clustered Post Office” on page 135. Item Explanation 6) IP Address Resolution Methods: Mark the short name address resolution methods you want to implement to ensure that the UNC paths stored in ConsoleOne with network names can ee Oy be successfully resolved into physical network addresses. + hosts file , , ; . For more information, see “Ensuring Successful Name Resolution for * DNS GroupWise Resource Groups” on page 137 7) Domain Name: Specify a unique name for the domain. Specify the directory where you want Domain Directory: to create the new domain. For more information, see “Planning a New Clustered Domain” on page 134. 8) Post Office Name: Specify a unique name for the post office. Specify the directory where you Post Office Directory: want to create the post office. For more information, see “Planning a New Clustered Post Office” on page 135. 9) Document Storage Area Location: If you need a library for a clustered post office, mark where you want to + At the post office create its document storage area and provide a directory if necessary. For more information, see “Planning a Library for a New Clustered Post + Outside the post office Office” on page 135. ¢ Separate post office Document Storage Area Access + POA /user startup switch setting + POA /password startup switch setting Planning GroupWise in a Microsoft Cluster 145 Network Address Worksheet Domain Information MTA MTA MTA IP Address MTP Port HTTP Port Post Office Information Post Office POA POA POA POA IP Address C/S Port MTP Port HTTP Port Internet Agent Information Internet Agent GWIA MTA MTA MTA GWIA IP Address MTP Port Live Remote Port HTTP Port HTTP Port | GWIA Domain MTA | Domain Ma Internet = a (GWIA) WebAccess Information WebAccess Agent | WebAccess MTA MTA WebAccess Agent WebAccess IP Address MTP Port HTTP Port Port HTTP Port WebAccess N/A N/A Domain MTA WebAccess Agent | (same) N/A N/A (GWINTER) 146 GroupWise 6.5 Interoperability Guide Agent Clustering Worksheet Item 1) Agent installation location: ¢ Shared disk with domain or post office + Each node in the cluster Consolidate startup files? 2) Domain Name: Domain Directory: 3) MTA Service Resource: Service name: Possible owners: Resource dependencies: 4) MTA Network Information: MTA IP address: MTA message transfer port: MTA HTTP port: 5) Post Office Name: Post Office Directory: 6) POA Service Resource: Service name: Possible owners: Resource dependencies: 7) POA Network Information: POA IP address POA client/server port POA message transfer port POA HTTP port Explanation Mark the location where you will install the agent software. If necessary, specify the location where you will store agent startup files on the same shared disk with the domain or post office. For more information, see “Deciding Where to Install the Agent Software” on page 141. Transfer this information from the System Clustering Worksheet (item 6). List other nodes in the cluster where the domain resource group could fail over and any resources that must be online before the MTA can start. For more information, see “Planning the Agent Services” on page 142. Gather the MTA network address information from the “Network Address Worksheet” on page 146. For more information, see “Planning Cluster-Unique Port Numbers for Agents in the Cluster” on page 139. Transfer this information from the System Clustering Worksheet (item 7). List other nodes in the cluster where post office resource group could fail over and any resources that must be online before the POA can start. For more information, see “Planning the Agent Services” on page 142. Gather the POA network address information from the “Network Address Worksheet” on page 146. For more information, see “Planning Cluster-Unique Port Numbers for Agents in the Cluster” on page 139. Planning GroupWise in a Microsoft Cluster 147 148 GroupWise 6.5 Interoperability Guide Setting Up a Domain and Post Office ina Microsoft Cluster You should have already reviewed “Planning Group Wise in a Microsoft Cluster” on page 133 and filled out the “System Clustering Worksheet” on page 144, the “Network Address Worksheet” on page 146, and the “Agent Clustering Worksheet” on page 147. You are now ready to complete the following tasks to set up GroupWise® in your Microsoft cluster: + “Preparing the Cluster for GroupWise” on page 149 + “Setting Up a New GroupWise System in a Cluster” on page 151 + “Creating a New Secondary Domain in a Cluster” on page 152 + “Creating a New Post Office in a Cluster” on page 153 + “Installing and Configuring the MTA and the POA in a Cluster” on page 154 + “Testing Your Clustered GroupWise System” on page 156 + “Managing Your Clustered GroupWise System” on page 157 + “What’s Next” on page 159 Preparing the Cluster for GroupWise After you have set up your Microsoft cluster and become familiar with its functioning, as described in Chapter 12, “Introduction to Group Wise 6.5 and Microsoft Clusters,” on page 131, complete the following tasks to prepare the cluster for your GroupWise system: + “Creating GroupWise Resource Groups” on page 149 + “Creating Agent Service Resources” on page 149 + “Configuring Short Name Resolution” on page 150 Creating GroupWise Resource Groups Create the needed domain and post office resource groups in your Microsoft cluster (System Clustering Worksheet items 3 and 4), as planned in “Planning a New Clustered Domain” on page 134 and “Planning a New Clustered Post Office” on page 135. Creating Agent Service Resources Within each Group Wise resource group, create the MTA or POA service resource (Agent Clustering Worksheet items 3 and 6), as planned in “Planning the Agent Services” on page 142. Setting Up a Domain and Post Office in a Microsoft Cluster 149 Configuring Short Name Resolution eDirectory Hosts Files To ensure that Group Wise resource groups are always locatable on the network, configure the short name resolution methods that you want to rely on for your clustered GroupWise system (System Clustering Worksheet item 9), as planned in “Ensuring Successful Name Resolution for GroupWise Resource Groups” on page 137. ¢ “eDirectory” on page 150 + “Hosts Files” on page 150 + “DNS” on page 151 After configuring your selected short name resolution methods, continue with the task you need to perform: + “Setting Up a New GroupWise System in a Cluster” on page 151 + “Creating a New Secondary Domain in a Cluster” on page 152 + “Creating a New Post Office in a Cluster” on page 153 ConsoleOne® will use Novell® eDirectory™ to resolve the UNC path of a domain or post office directory into its network name in the cluster. For example, on the workstation where you run ConsoleOne, you would need to map a drive to the location of a domain directory using the network name of the domain resource group so that ConsoleOne can access the domain database no matter which node in the cluster it is active on. Because each GroupWise resource group has been associated with a network name, you should add lines for the new network names to one or more of the following files as needed: + Windows NT*/2000: \winnt\system32\drivers\etc\hosts (on the administrator’s workstation only; optional) + Windows 9x: \novell\client32\nwhosts (on the administrator’s workstation only; optional) The lines you add to a hosts file could look similar to the following example (all on one line, of course): Syntax: IP_address network_name.context Remember that network_name represents the name of the virtual server that remains unchanged regardless of which node is currently active. Example: 123.45.67.81 gwcluster.novell.com When specifying the lines in the hosts files, use System Clustering Worksheet item 7 or 8 for each IP_address and network_name where a domain or post office resides. Use System Clustering Worksheet item 3 for cluster. Use System Clustering Worksheet item 4 for context. 150 GroupWise 6.5 Interoperability Guide DNS Because each Group Wise resource group has been associated with a virtual network name, you should add all your new network names to DNS. Setting Up a New GroupWise System in a Cluster The Group Wise 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 in the same resource group or in two different resource groups. 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 in the cluster as needed. To set up the primary domain and initial post office for a new Group Wise system in a Microsoft cluster: 1 2 If necessary, map a drive to each GroupWise administration shared disk (System Clustering Worksheet item 3). Map a drive to the shared disk of the domain resource group (System Clustering Worksheet item 6) and, if needed, to the shared disk of the post office resource group (System Clustering Worksheet item 7), where the primary domain and the initial post office for your new GroupWise system will be created. Manually create the domain directory (System Clustering Worksheet item 6) and the post office directory (System Clustering Worksheet item 7). This step is not required, but in a Microsoft cluster, the following step will be easier if the directory already exists. Run the GroupWise Installation Advisor to set up your initial Group Wise system, following the steps provided in “Setting Up a Basic GroupWise System on NetWare or Windows” in “Installing a Basic GroupWise System” in the GroupWise 6.5 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 shared disk accessed in Step | above. + When you specify the domain directory and post office directory, be sure to browse through the shared disk 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 during “Deciding How to Install and Configure the Agents in a Cluster” on page 139. The information you provide will be 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 worry about creating users in the post office at this time. + Inthe Summary dialog box, the domain directory and post office directory that you browsed to should display as UNC paths using the network name of the Group Wise resource group, not the name of a specific node in the cluster. When you have finished creating the primary domain and the initial post office, continue with installing the GroupWise Agents, starting with Step 5 in “Installing the Agent Software in a Cluster” on page 155. The GroupWise Installation Advisor starts the Agent Installation program for you. Setting Up a Domain and Post Office in a Microsoft Cluster 151 Creating a New Secondary Domain in a Cluster After you have set up the primary domain and initial post office, as described in “Setting Up a New Group Wise System in a Cluster” on page 151, you can create additional secondary domains as needed. To create a new secondary domain in a Microsoft cluster: 1 Create a domain resource group for the new domain, as described in “Creating GroupWise Resource Groups” on page 149. 2 Create an MTA service resource for the domain’s MTA, as described in “Creating Agent Service Resources” on page 149. 3 Map a drive to the shared disk of the domain resource group (System Clustering Worksheet item 7) where the new secondary domain will be created. 4 Manually create the domain directory (System Clustering Worksheet item 7). This step is not required, but in a clustered environment, Step 7 will be easier if the domain directory already exists. 5 Ifyou selected the same shared disk with the domain as the agent installation location (Agent Clustering Worksheet item 1), create the drive:\grpwise directory on the drive accessed in Step 3. or If you selected c:\grpwise on each node in the cluster, decide which node you will install the agents to first. 6 In ConsoleOne, connect to the primary domain in your GroupWise system, as described in “Connecting to a Domain” in “Domains” in the GroupWise 6.5 Administration Guide. 7 Create the new domain, following the steps provided in “Creating the New Domain” in “Domains” in the GroupWise 6.5 Administration Guide. Keep in mind the following cluster- specific details: + Use the Domain Worksheet you filled out during “Planning a New Clustered Domain” on page 134 to fill in the fields on the Create GroupWise Domain page. + Inthe Domain Database Location field, be sure to browse through the drive you accessed in Step 3 to the domain directory you created in Step 4 above. + Inthe 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 during “Planning Cluster-Unique Port Numbers for Agents in the Cluster” on page 139 for the resource group IP address and cluster-unique port numbers that you need to specify in order to configure the link. 8 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 6.5 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. 152 GroupWise 6.5 Interoperability Guide 9 10 11 Make sure you are still connected to the primary domain. Rebuild the domain database for the new domain, following the steps provided in “Rebuilding Domain or Post Office Databases” in “Databases” in the GroupWise 6.5 Administration Guide. Be sure to browse to the database location (System Clustering Worksheet item 7) through the shared disk you accessed in Step 3 to the domain directory you created in Step 4 above. 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 secondary domain is not yet running. Continue with “Creating a New Post Office in a Cluster” on page 153. Creating a New Post Office in a Cluster You can create a new post office in the same resource group where its domain is located or in a separate resource group. If the post office and its domain are in the same resource group, they fail over together. If they are in separate resource groups, they fail over separately. To create a new post office in a Microsoft cluster: 1 4 If you selected Yes for Post Office in Same Resource Group as Domain? (under System Clustering Worksheet item 4), map a drive to the shared disk of the domain resource group. or Map a drive to the shared disk of the post office resource group (System Clustering Worksheet item 5). Manually create the post office directory (System Clustering Worksheet item 8). This step is not required, but in a Microsoft cluster, Step 4 will be easier if the post office directory already exists. 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 6.5 Administration Guide. Create the new post office, following the steps provided in “Creating the New Post Office” in “Post Offices” in the GroupWise 6.5 Administration Guide. Keep in mind the following cluster-specific details: + Use the Post Office Worksheet you filled out during “Planning a New Clustered Post Office” on page 135 to fill in the fields on the Create Group Wise Post Office page. + Inthe Post Office Database Location field, be sure to browse through the shared disk you accessed in Step | to the post office directory you created in Step 2 above. + Ifyou want to create a library at the post office (System Clustering Worksheet item 9), select Create Library. + 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 Cluster-Unique Port Numbers for Agents in the Cluster” on page 139 for the resource group IP address and cluster-unique port numbers that you need to specify in order to configure the link. In ConsoleOne, right-click the new Post Office object, then click Properties. Setting Up a Domain and Post Office in a Microsoft Cluster 153 6 Click GroupWise > Post Office Settings, then 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 6.5 Administration Guide. 8 Make sure you are still connected to the domain that owns the new post office. 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 6.5 Administration Guide. Be sure to browse to the database location (System Clustering Worksheet item 7) through the shared disk you accessed in Step | to the post office directory you created in Step 2 above. 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 Ifyou want to create a library (System Clustering Worksheet item 9) for the new clustered post office, follow the steps in “Setting Up a Basic Library” or “Setting Up a Full-Service Library” in “Libraries and Documents” in the GroupWise 6.5 Administration Guide, after you have completely finished setting up the new clustered post office. 11 Continue with “Installing and Configuring the MTA and the POA in a Cluster” on page 154. Installing and Configuring the MTA and the POA in a Cluster 154 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 resource group where you want to install the agent software: + “Installing the Agent Software in a Cluster” on page 155 ¢ “Editing Clustered Agent Startup Files” on page 155 Under some circumstances, the agent software has already been installed in the cluster 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 in a GroupWise resource group where the agent software is already installed in the drive:\grpwise directory for the resource group. ¢ In your GroupWise system, the agent software is already installed to the c:\grpwise directory on each node in the cluster. In these circumstances, follow the instructions in “Setting Up New Instances of the Agents without Installing the Agent Software” on page 156 instead of completing the tasks listed above. GroupWise 6.5 Interoperability Guide Installing the Agent Software in a Cluster To install the MTA and the POA: 1 Map a drive to the shared disk of the domain resource group (Agent Clustering Worksheet item 2) or the post office resource group (Agent Clustering Worksheet item 5). 2 Map a drive to c:\ on the first node in the cluster where you will set up the agents as Windows services (System Clustering Worksheet item 2). 3 Ifyou plan to install the agent software to the shared disk of the domain or post office resource group (under Agent Clustering Worksheet item 1), create the drive:\grpwise directory on the shared disk accessed in Step 1. or If you plan to install the agent software to each node in the cluster, create the c:\grpwise directory on the drive accessed in Step 2. 4 Start the Agent Installation program, following the steps provided in “Installing the Windows Agent Software” in “Installing GroupWise Agents” in the GroupWise 6.5 Installation Guide. 5 Install the Windows agents, keeping in mind the following cluster-specific details: + Use the Windows Agent Clustering Worksheet that you filled out during “Planning the Windows Agent Installation” on page 143 to fill in the fields during the agent installation process. + On the Installation Path page, be sure to browse through the mapped drive to the directory you created in Step 3 above. Be sure that Install as Windows Services is selected. + On the Domains / Post Offices page, 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 | above to the domain directory or the post office directory on the shared disk. + On the Installation Complete page do not select Launch GroupWise Agents Now. 6 Ifyou need to install the agent software to c:\grpwise on each node in the cluster, repeat Step 4 and Step 5, mapping a drive to each node in the cluster. or If you installed the agent software to a shared disk and need only to set up the agents as Windows services on each node, repeat Step 4 and Step 5, mapping drives to new nodes as needed. On the Installation Options page, select only the Install as Windows Services option to speed up the installation process for each node. 7 Ifyou installed the agent software to each node and you selected Yes for Consolidate Startup Files? (under Agent Clustering Worksheet item 1), copy one complete set of agent startup files to the planned location on the shared disk, then delete all agent startup files from the c:\grpwise directories on the nodes to avoid future confusion. 8 Continue with “Editing Clustered Agent Startup Files” on page 155. 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. Setting Up a Domain and Post Office in a Microsoft Cluster 155 Because you mapped a drive to the shared disk of the Group Wise resource group using the physical disk and file share information from the resource group, the setting for the MTA /home startup switch and the POA /home startup switch will always be correct, no matter which node in the cluster the domain and post office are currently active on. One manual modification of POA startup files is required for robust functionality in a Microsoft cluster. Uncomment the /ip startup switch and provide the IP address of the post office resource group (Agent Clustering Worksheet item 7). This information is available to the POA in its eDirectory object properties. However, in some failover situations, the POA reconnects to the MTA more quickly when the information is immediately available to the POA in its startup file. If the POA needs to access a remote document storage area that is outside the cluster, add the /user and /password startup switches (under System Clustering Worksheet item 9) in order to provide a user name and password that the POA can use to access the server 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. Continue with “Testing Your Clustered GroupWise System” on page 156. Setting Up New Instances of the Agents without Installing the Agent Software To set up new instances of the agents without installing the agent software, you simply create 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 drive:\grpwise directory of a shared disk with a domain or post office, the startup files will be located there as well. If the existing agent software is located in the c:\grpwise directory on each node in the cluster, the startup files might be located there, or they might be located on the shared disk with the domain or post office. 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 new instance of 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, using the physical disk and file share provided in the GroupWise resource group. 3 Scroll down through the startup file looking for other active (not commented out) startup switches, then modify them as needed for the new instance of the agent. 4 Save the new startup file. 5 Continue with “Testing Your Clustered GroupWise System” on page 156. Testing Your Clustered GroupWise System After you have configured the GroupWise resource group, you can test the failover and failback functionality by bringing the GroupWise resource group online and taking it offline again. Continue with “Managing Your Clustered GroupWise System” on page 157. 156 GroupWise 6.5 Interoperability Guide Managing Your Clustered GroupWise System After you have set up a basic clustered GroupWise system, you should consider some long-term management issues. + “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 157 + “Knowing What to Expect in MTA and POA Failover Situations” on page 158 Updating GroupWise Objects with Cluster-Specific Descriptions After setting up your clustered Group Wise 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 157 + “Recording Cluster-Specific Information for a Post Office and Its POA” on page 157 + “Recording Cluster-Specific Information for a Software Distribution Directory” on page 158 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 resource group IP address and the cluster-unique port numbers used by its MTA. Click OK to save the domain description. Select the Domain object to display its contents. Right-click the MTA object, then click Properties. oa bh W In the Description field of the MTA Identification page, record the domain resource group IP address and the cluster-unique port numbers used by the MTA. This information will appear 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” on page 157. 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 resource group IP address 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. Setting Up a Domain and Post Office in a Microsoft Cluster 157 5 Right-click the POA object, then click Properties. 6 In the Description field of the POA Identification page, record the post office resource group IP address and the cluster-unique port numbers used by the POA. This information will appear 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 Ifnecessary, continue with “Recording Cluster-Specific Information for a Software Distribution Directory” on page 158. or Continue with “Knowing What to Expect in MTA and POA Failover Situations” on page 158. Recording Cluster-Specific Information for a Software Distribution Directory To permanently record important cluster-specific information about a software distribution directory located on a shared disk: 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 IP address of the cluster resource where the software distribution directory resides. 4 Click OK, then click Close to save the software distribution directory description. 5 Continue with “Knowing What to Expect in MTA and POA Failover Situations” on page 158. Knowing What to Expect in MTA and POA Failover Situations 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 Group Wise client users who can reconnect to their mailboxes very quickly and probably will not notice if messages to users in other post offices are not delivered immediately. The only time a user would need to restart the Group Wise 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, manual 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” on page 58. 158 GroupWise 6.5 Interoperability Guide What’s Next Now that you have at least one GroupWise domain and post office up and running in your Microsoft cluster, you are ready to proceed with the rest of your GroupWise system setup by: + + Adding users to post offices. See “Users” in the Group Wise 6.5 Administration Guide. Setting up the GroupWise client software and helping users to get started using it. See “Client” in the GroupWise 6.5 Administration Guide. Also see the Group Wise 6.5 Windows Client User Guide. Connecting your clustered GroupWise system to the Internet. See Chapter 4, “Implementing the Internet Agent in a Novell Cluster,” on page 63. Providing access to users’ GroupWise mailboxes from their Web browsers. See Chapter 5, “Implementing WebAccess in a Novell Cluster,” on page 83. 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 103. Monitoring the status of your clustered GroupWise system from your Web browser. See Chapter 7, “Monitoring a GroupWise System in a Novell Cluster,” on page 105. Backing up your clustered GroupWise system. See Chapter 8, “Backing Up a GroupWise System in a Novell Cluster with the GroupWise TSA,” on page 107. Setting Up a Domain and Post Office in a Microsoft Cluster 159 160 GroupWise 6.5 Interoperability Guide Implementing the Internet Agent in a Microsoft Cluster You should already have set up at least a basic GroupWise™ system, as described in Chapter 13, “Planning Group Wise in a Microsoft Cluster,” on page 133 and Chapter 14, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149. As part of this process, the “System Clustering Worksheet” on page 144 and the “Network Address Worksheet” on page 146 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 will need this information as you implement the Internet Agent in a cluster. + “Planning the Internet Agent in a Cluster” on page 161 ¢ “Setting Up the Internet Agent in a Cluster” on page 164 + “Managing the Internet Agent in a Cluster” on page 168 + “Internet Agent Clustering Worksheet” on page 170 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. The Internet Agent is faster and more stable when it runs on the same server with its domain. In a cluster, creating a separate domain for the Internet Agent ensures that the Internet Agent and its domain always fail over together. The “Internet Agent Clustering Worksheet” on page 170 lists all the information you will need as you set up the Internet Agent in a Microsoft cluster. You should print the worksheet and fill it out as you complete the tasks listed below: + “Planning a Domain for the Internet Agent” on page 162 + “Planning the Internet Agent Resource Group” on page 162 + “Planning Cluster-Unique Port Numbers for the Internet Agent and Its MTA” on page 162 + “Preparing Your Firewall for the Internet Agent” on page 163 + “Deciding Where to Install the Internet Agent and Its MTA” on page 163 + “Planning the MTA Installation” on page 164 ¢ “Planning the Internet Agent Installation” on page 164 Implementing the Internet Agent in a Microsoft Cluster 161 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 6.5 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 disk where you want the domain directory to be located. + 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: Resource Group for Internet Agent, transfer the disk drive to the Internet Agent Clustering Worksheet. Under Item 2: Internet Agent Domain Name, transfer the domain name and directory to the Internet Agent Clustering Worksheet. Planning the Internet Agent Resource Group The Internet Agent resource group is similar to the GroupWise resource groups you have already set up, as described in “Planning GroupWise Resource Groups” on page 136 and “Creating Group Wise Resource Groups” on page 149. The Internet Agent resource group contains a domain whose only role is to connect the Internet Agent into your clustered GroupWise system. It also contains two agent service resources, one for the MTA that services the domain and one for the Internet Agent. INTERNET AGENT CLUSTERING WORKSHEET Under Item 1: Resource Group for Internet Agent, specify the network name and other required information for the Internet Agent resource group. To ensure successful short name resolution, add entries for the Internet Agent network name to support your preferred methods of short name resolution, as described in “Configuring Short Name Resolution” on page 150. Planning Cluster-Unique Port Numbers for the Internet Agent and Its MTA As with the MTA and the POA, the Internet Agent needs cluster-unique port numbers. As part of planning to install the MTA and POA, you should already have determined the resource group IP address and cluster-unique port numbers for the Internet Agent and its MTA as you filled out the “Network Address Worksheet” on page 146. If you do not have a filled-out copy of this worksheet for your system, print it now and fill in current system information. 162 GroupWise 6.5 Interoperability Guide INTERNET AGENT CLUSTERING WORKSHEET Under Item 5: MTA Network Information, transfer the resource group IP address and cluster-unique port numbers from the Internet Agent section of the Network Address Worksheet to the Internet Agent Clustering Worksheet. Under Item 7: Internet Agent Network Information, transfer the resource group IP address (the same as for its MTA) and the cluster-unique Internet Agent port number from the Internet Agent section of the Network Address Worksheet to the Internet Agent Clustering Worksheet. Preparing Your Firewall for the Internet Agent The Internet Agent will receive incoming messages on the IP address of the Internet Agent resource group. Your firewall configuration must be modified to allow inbound TCP/IP traffic from the Internet to the Internet Agent IP address on the following standard ports: Protocol Standard Port IMAP4 143 LDAP 389 POP3 110 SMTP 25 By default, the Internet Agent will send outgoing messages on the ZP address of the node 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 on the Internet Agent resource group’s possible owners list. If the Internet Agent has a large number of nodes in its possible owners list, 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 IP address of the particular node where the Internet Agent is running. This reduces the amount of modification to your firewall required to set up the Internet Agent. However, if the relay host goes down, all outgoing messages would be delayed. As another alternative, you can configure the Internet Agent to use its resource group 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 75, 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 node and resource group IP addresses when sending and receiving messages. Deciding Where to Install the Internet Agent and Its MTA The default Internet Agent installation directory is c:\grpwise\gwia. As with the MTA and the POA, you can choose to install the Internet Agent and its MTA to each node in the cluster or to the shared disk of the Internet Agent resource group. For a discussion of these alternatives, see “Deciding Where to Install the Agent Software” on page 141, which describes the issues in the Implementing the Internet Agent in a Microsoft Cluster 163 context of planning MTA and POA installations. As with the MTA and POA, the Internet Agent and its MTA must be installed as Windows services. 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 the shared disk of the Internet Agent resource group or to each node in the cluster. If necessary, specify where the MTA startup file and the Internet Agent configuration file (gwia.cfg) will be stored. Planning the MTA Installation Follow the instructions in “Planning the Windows Agent Installation” on page 143 to plan the MTA installation for the Internet Agent domain, then return to this point. After you follow the instructions, you will have a filled-out Windows Agent Worksheet to use when you install the MTA. IMPORTANT: Do not install the Windows MTA until you are instructed to do so in “Setting Up the Internet Agent in a Cluster” on page 164. 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 Microsoft cluster as for any other environment. Review “Installing the Internet Agent Software on NetWare or Windows”, then print and fill out the “GroupWise Internet Agent Installation Worksheet” in “Installing the GroupWise Internet Agent” in the Group Wise 6.5 Installation Guide. You will need this information as you install the Internet Agent in your cluster. IMPORTANT: Do not install the Internet Agent software until you are instructed to do so in “Setting Up the Internet Agent in a Cluster” on page 164. Setting Up the Internet Agent in a Cluster You should already have reviewed “Planning the Internet Agent in a Cluster” on page 161 and filled out the “Internet Agent Clustering Worksheet” on page 170. You are now ready to complete the following tasks to set up the Internet Agent in a Microsoft cluster: + “Setting Up the Internet Agent Resource Group” on page 164 + “Creating a Domain for the Internet Agent” on page 165 + “Installing the MTA for the Internet Agent Domain” on page 165 + “Installing and Configuring the Internet Agent in a Cluster” on page 165 + “Testing the Clustered Internet Agent” on page 168 Setting Up the Internet Agent Resource Group 164 1 Create the Internet Agent resource group and agent services resources (Internet Agent Clustering Worksheet item 1), as planned in “Planning the Internet Agent Resource Group” on page 162. 2 To ensure successful short name resolution, add entries for the Internet Agent network name to support your preferred methods of short name resolution, as described in “Configuring Short Name Resolution” on page 150. GroupWise 6.5 Interoperability Guide 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 163. 4 Continue with “Creating a Domain for the Internet Agent” on page 68. Creating a Domain for the Internet Agent The Internet Agent domain will be a secondary domain. To create it, follow the instructions in “Creating a New Secondary Domain in a Cluster” on page 152, taking your information from the Internet Agent Clustering Worksheet, rather than the System Clustering Worksheet, then return to this point. Do not create any post offices in the Internet Agent domain. Continue with “Installing the MTA for the Internet Agent Domain” on page 165. 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 155, then return to this point. You do not need to edit the MTA startup file. Continue with “Installing and Configuring the Internet Agent in a Cluster” on page 165. 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 and Configuring the Internet Agent in a Cluster” on page 165 ¢ “Enabling Internet Addressing for Your Clustered GroupWise System” on page 166 + “Verifying GWIA Object Properties” on page 166 Installing the Internet Agent Software in a Cluster 1 Map a drive to the shared disk of the Internet Agent resource group (Internet Agent Clustering Worksheet item 1). 2 Map a drive to c:\ on the first node in the cluster where you will set up the Internet Agent as a Windows service (System Clustering Worksheet item 2). 3 Ifyou plan to install the Internet Agent software to the shared disk of the Internet Agent resource group (Internet Agent Clustering Worksheet item 6), create the drive:\grpwise\gwia directory on the shared disk accessed in Step 1. or If you plan to install the Internet Agent software to each node in the cluster, create the c:\grpwise\gwia directory on the drive accessed in Step 2). 4 Start the Internet Agent Installation program, following the steps provided in “Installing the Internet Agent Software on NetWare or Windows” in “Installing the Group Wise Internet Agent” in the GroupWise 6.5 Installation Guide. Implementing the Internet Agent in a Microsoft Cluster 165 5 Install the Windows Internet Agent, keeping in mind the following cluster-specific details: + Use the Windows Internet Agent Clustering Worksheet that you filled out during “Planning the Internet Agent Installation” on page 66 to fill in the fields during the Internet Agent installation process. + On the Installation Path page, be sure to browse through the mapped drive to the directory you created in Step 3 above. Be sure that Run WebAccess Agent as a Windows Service is selected. + On the GroupWise Domain page, be sure to browse through the drive you mapped in Step 1 to the domain directory on the shared disk. + On the Post Installation Task List page, deselect Launch Internet Agent Now so that the Installation program does not start the Internet Agent after installation is complete. 6 Repeat Step 4 and Step 5, mapping a drive to each node in the cluster. Even if you installed the Internet Agent software to a shared disk, you need to repeat the installation process for each node so that the Internet Agent gets set up as a Windows service on each node. 7 Ifyou installed the software to each node in the cluster and you selected Yes for Consolidate Configuration Files? (under Internet Agent Clustering Worksheet item 6), copy the gwia.cfg file to the planned location on the shared disk, then delete it from the c:\grpwise\gwia directory on each node to avoid future confusion. 8 Make sure you have completed all the tasks described in “Installing the GroupWise Internet Agent” in the GroupWise 6.5 Installation Guide. 9 Continue with “Enabling Internet Addressing for Your Clustered GroupWise System” on page 166. 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 6.5 Administration Guide, then continue with “Verifying GWIA Object Properties” on page 166. Verifying GWIA Object Properties During installation of the Internet Agent, the GWIA 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 GWIA Object Properties” on page 166 + “Verifying the Reference to the Network Name for Use by DNS” on page 167 + “Verifying the Reference to the Network Name in Directory Paths” on page 167 ¢ “Verifying Post Office Links” on page 167 + “Forcing Use of the Internet Agent Resource Group IP Address” on page 167 Accessing GWIA Object Properties 4 In ConsoleOne®, browse to and select the Internet Agent domain in order to display its contents. 2 Right-click the GWIA object, then click Properties. 3 Continue with “Verifying the Reference to the Volume Resource” on page 74. 166 GroupWise 6.5 Interoperability Guide Verifying the Reference to the Network Name for Use by DNS In the GWIA 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 network name of the domain resource group, not the name of a node in the cluster. 3 Make changes if necessary. 4 Continue with “Verifying the Reference to the Network Name in Directory Paths” on page 167. Verifying the Reference to the Network Name in Directory Paths In the GWIA object properties pages: 1 Click Server Directories. 2 Verify that the displayed directories match the network name of the domain resource group, not the name of a node in the cluster. 3 Make changes if necessary. 4 Continue with “Verifying Post Office Links” on page 167. Verifying Post Office Links In the GWIA 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 clustered Internet Agent. 3 Verify that the Links column displays the IP addresses of the post office resource groups, not the IP addresses of any nodes in the cluster. 4 Make changes if necessary. 5 Continue with “Forcing Use of the Internet Agent Resource Group IP Address” on page 167. Forcing Use of the Internet Agent Resource Group IP Address If you want the Internet Agent to send outgoing messages on its resource group IP address, rather than using the default the node IP address: 1 Click GroupWise > Network Address. 2 Inthe TCP/IP Address field, provide the resource group IP address (under Internet Agent Clustering Worksheet item 1) for the Internet Agent to use for sending outgoing messages. 3 Click SMTP/MIME, then click Settings. 4 Select Bind to TCIP/IP Address at Connection Time. 5 Click OK. 6 Continue with “Testing the Clustered Internet Agent” on page 168. Implementing the Internet Agent in a Microsoft Cluster 167 Testing the Clustered Internet Agent After you have set up the Internet Agent resource group, you can test it by manually bringing it online and taking it offline again. Continue with “Managing the Internet Agent in a Cluster” on page 168 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. + “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 168 + “Knowing What to Expect in an Internet Agent Failover Situation” on page 169. Updating GroupWise Objects with Cluster-Specific Descriptions 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 Group Wise 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 168 è “Recording Cluster-Specific Information about the Internet Agent” on page 168 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 its resource group IP address and the cluster-unique port numbers used by its MTA. Click OK to save the Internet Agent domain description. Select the Internet Agent Domain object to display its contents. Right-click the MTA object, then click Properties. oa bh Ww In the Description field of the MTA Identification page, record the domain resource group IP address and the cluster-unique port numbers used by the MTA. This information will appear 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” on page 168. Recording Cluster-Specific Information about the Internet Agent With the contents of the Internet Agent domain still displayed: 1 Right-click the GWIA object, then click Properties. 168 GroupWise 6.5 Interoperability Guide 2 Click GroupWise, then click Identification. 3 In the Description field, record the resource group IP address and the cluster-unique port numbers used by the Internet Agent. This information will appear 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” on page 169. Knowing What to Expect in an Internet Agent Failover Situation The failover behavior of the MTA for the Internet Agent domain will be the same as for an MTA in a regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” on page 158. Failover of the Internet Agent itself is more complex. The various e-mail clients (POP3, IMAP4, and LDAP) will receive an error message when the server they were connected to becomes unavailable. Most of the clients do not attempt to reconnect automatically, so the user must exit the e-mail 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 will be able to reconnect quickly. As with the MTA and the POA, manual 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 when you are manually migrating it. Implementing the Internet Agent in a Microsoft Cluster 169 Internet Agent Clustering Worksheet Item 1) Resource Group for Internet Agent: Network name: IP address: Physical disk: File share: MTA service resource: Internet Agent service resource: Possible owners: 2) Internet Agent Domain Name: Domain Directory: 4) MTA Installation Location: ¢ Shared disk of the Internet Agent resource group + Each node in the cluster Consolidate MTA startup files? 5) MTA Network Information: MTA IP address: MTA message transfer port: MTA live remote port: MTA HTTP port 6) Internet Agent Installation Location: ¢ Shared disk in the Internet Agent resource group + Each node in the cluster Consolidate configuration files? 7) Internet Agent Network Information: Internet Agent IP address: Internet Agent HTTP port: Explanation Specify the information for the Internet Agent resource group. For more information, see “Planning the Internet Agent Resource Group” on page 162. Specify a unique name for the Internet Agent domain. Specify the directory on the physical disk that belongs to the Internet Agent resource group where you want to create the new domain. For more information, see “Planning a Domain for the Internet Agent” on page 162. Mark the location where you will install the MTA software. If necessary, specify the location where you will consolidate the MTA startup files from the various nodes where the Internet Agent is installed. For more information, see “Deciding Where to Install the Internet Agent and Its MTA” on page 163. Gather the MTA network address information from the Internet Agent section of the “Network Address Worksheet” on page 146. For more information, see “Planning Cluster-Unique Port Numbers for the Internet Agent and Its MTA” on page 162. Mark the location where you will install the Internet Agent software. If necessary, specify the location on the shared disk of the Internet Agent resource group where you will consolidate the Internet Agent configuration files (gwia.cfg) from the various nodes where it is installed. For more information, see “Deciding Where to Install the Internet Agent and Its MTA” on page 163. Gather the Internet Agent network address information from the Internet Agent section of the “Network Address Worksheet” on page 146. For more information, see “Planning Cluster-Unique Port Numbers for the Internet Agent and Its MTA” on page 162. 170 GroupWise 6.5 Interoperability Guide Implementing WebAccess in a Microsoft Cluster You should already have set up at least a basic GroupWise® system, as described in Chapter 13, “Planning Group Wise in a Microsoft Cluster,” on page 133 and Chapter 14, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149. As part of this process, the “System Clustering Worksheet” on page 144 and the “Network Address Worksheet” on page 146 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 will need this information as you implement WebAccess in a cluster. + “Understanding the WebAccess Components” on page 171 + “Planning WebAccess in a Cluster” on page 171 + “Setting Up WebAccess in a Cluster” on page 175 + “Managing WebAccess in a Cluster” on page 178 + “WebAccess Clustering Worksheet” on page 181 Understanding the WebAccess Components If you are not familiar with GroupWise WebAccess, review “GroupWise WebAccess Overview” in “Installing GroupWise WebAccess” in the GroupWise 6.5 Installation Guide. As you plan WebAccess in a clustering environment, you must keep in mind that you will plan and set up two separate WebAccess components: + WebAccess Agent (gwinter.exe) that will be associated with a GroupWise WebAccess domain + WebAccess Application (a Java* servlet) that will be added to your Web server 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. The WebAccess Agent is faster and more stable when it runs on the same server with its domain. In a cluster, creating a separate domain for the WebAccess Agent ensures that the WebAccess Agent and its domain always fail over together. The “WebAccess Clustering Worksheet” on page 181 lists all the information you will need as you set up the WebAccess Agent and the WebAccess Application in a clustering environment. You should print the worksheet and fill it out as you complete the tasks listed below: + “Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6” on page 84 + “Planning a New Domain for the WebAccess Agent” on page 172 Implementing WebAccess in a Microsoft Cluster 1741 + “Planning the WebAccess Resource Group” on page 173 + “Planning Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 173 + “Deciding Where to Install the WebAccess Agent and Its MTA” on page 173 + “Planning the MTA Installation” on page 174 + “Planning the WebAccess Installation” on page 174 Setting Up Your Web Server in the Microsoft cluster Before you install WebAccess, your Web server must already be set up and running in the cluster. Make sure that it can fail over and fail back successfully. As you set up your Web server, record the following key configuration information on the WebAccess Clustering Worksheet: WEBACCESS CLUSTERING WORKSHEET Under Item 7: Physical Web Servers, list the nodes in the cluster where you are installing the Web server software. Under Item 8: Web Server IP Address, record the secondary IP address of the Web server resource that you create. Under Item 9: Hardware Virtual Server Information, record the dedicated IP address for the Web site and the document root directory. Because the WebAccess Application will be installed to a subdirectory of the Web server installation directory (directory\com\novell\webaccess), the WebAccess Application cannot be installed on a shared disk. Instead, you will install it to each node in the cluster where the Web server has been installed. 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 6.5 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 physical disk in your shared disk system where you want the domain directory to be located. + 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. 172 GroupWise 6.5 Interoperability Guide WEBACCESS CLUSTERING WORKSHEET Under Item 1: Resource Group for WebAccess Agent, transfer the shared disk from the Domain Worksheet to the WebAccess Clustering Worksheet. Under Item 2: WebAccess Agent Domain Name, transfer the domain name and directory from the Domain Worksheet to the WebAccess Clustering Worksheet. Planning the WebAccess Resource Group The WebAccess resource group is similar to the domain and post office resource groups you have already set up, as described in “Planning Group Wise Resource Groups” on page 136 and “Creating GroupWise Resource Groups” on page 149. The WebAccess resource group contains a domain whose only role is to connect the WebAccess Agent into your clustered Group Wise system. It also contains two agent service resources, one for the MTA that services the domain and one for the WebAccess Agent. WEBACCESS CLUSTERING WORKSHEET Under Item 1: Resource Group for WebAccess, specify the network name and other required information for the WebAccess resource group. To ensure successful short name resolution, add entries for the WebAccess network name to support your preferred methods of short name resolution, as described in “Configuring Short Name Resolution” on page 150. Planning Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA As with the MTA and the POA, the WebAccess Agent needs cluster-unique port numbers. As part of planning to install the MTA and POA, you should already have determined the IP address and cluster-unique port numbers for the WebAccess Agent and its MTA as you filled out the “Network Address Worksheet” on page 146. 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 1: Resource Group for WebAccess, transfer the WebAccess resource group IP address. Under Item 4: MTA Network Information, transfer the cluster-unique MTA port numbers from the WebAccess section the Network Address Worksheet to the WebAccess Clustering Worksheet. Under Item 6: WebAccess Agent Network Information, transfer the cluster-unique WebAccess Agent port number from the WebAccess section of the Network Address Worksheet to the WebAccess Clustering Worksheet. 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 each node in the cluster or to the shared disk of the WebAccess resource group. For a discussion of these alternatives, see “Deciding Where to Install the Agent Software” on page 141, which describes the issues in the context of planning MTA and POA installations. Implementing WebAccess in a Microsoft Cluster 173 WEBACCESS CLUSTERING WORKSHEET Under Item 3: MTA Installation Location and Item 5: WebAccess Agent Installation Location, mark whether you will install the WebAccess Agent and its MTA to each node in the cluster or to the shared disk of the WebAccess resource group. Also specify where the MTA startup file will be stored. Planning the MTA Installation Follow the instructions in “Planning the MTA Installation” on page 174, then return to this point. After you follow the instructions, you will have a filled-out Windows Agent Worksheet to use when you install the MTA. IMPORTANT: Do not install the Windows MTA until you are instructed to do so in “Setting Up WebAccess in a Cluster” on page 175. 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 6.5 Installation Guide. When you set up WebAccess in a cluster, you will install the WebAccess Agent and the WebAccess Application in two separate steps: + “Planning the WebAccess Agent Installation” on page 174 + “Planning the WebAccess Application Installation” on page 174 IMPORTANT: Do not install the WebAccess software until you are instructed to do so in “Setting Up WebAccess in a Cluster” on page 175. 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 5: WebAccess Agent Installation Location). Under Item 3: Server Address, transfer the IP address and port number from the WebAccess Clustering Worksheet (Item 6: WebAccess Agent Network Information) filled out during “Planning Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 173. Under Item 5: Domain Directory Path, transfer the domain directory from the Domain Worksheet you filled out during “Planning a New Domain for the WebAccess Agent” on page 172. Planning the WebAccess Application Installation For the WebAccess Application, fill out items 13 through 19 on the GroupWise WebAccess Installation Worksheet, taking into account the following cluster-specific issues: 174 GroupWise 6.5 Interoperability Guide WEBACCESS INSTALLATION WORKSHEET Under Item 13: Web Server Type and Root Directory, mark the Web server you have installed in your cluster and specify the Web server root directory. Under Item 16: Novell Root Directory, specify a directory on the Web server where you want to install the WebAccess Agent configuration file. the default is c:\novell Setting Up WebAccess in a Cluster You should already have reviewed “Planning Group Wise in a Microsoft Cluster” on page 133 and filled out the “WebAccess Clustering Worksheet” on page 181. You are now ready to complete the following tasks to set up the WebAccess Agent in a clustering environment: + “Setting Up the WebAccess Resource Group” on page 175 + “Creating a Domain for the WebAccess Agent” on page 89 ¢ “Installing the MTA for the WebAccess Agent Domain” on page 89 + “Installing and Configuring the WebAccess Agent in a Cluster” on page 89 + “Installing and Configuring the WebAccess Application in a Cluster” on page 95 + “Testing Your Clustered WebAccess Installation” on page 96 + “Managing WebAccess in a Cluster” on page 96 Setting Up the WebAccess Resource Group 1 Create the WebAccess resource group and agent services resources (WebAccess Clustering Worksheet item 1), as planned in “Planning the WebAccess Resource Group” on page 173. 2 To ensure successful short name resolution, add entries for the WebAccess Agent network name to support your preferred methods of short name resolution, as described in “Configuring Short Name Resolution” on page 150. 3 Continue with “Creating a Domain for the WebAccess Agent” on page 175. Creating a Domain for the WebAccess Agent The WebAccess Agent domain will be a secondary domain. To create it, follow the instructions in “Creating a New Secondary Domain in a Cluster” on page 152, taking your information from the WebAccess Clustering Worksheet, rather than the System Clustering Worksheet, then return to this point. Do not create any post offices in the WebAccess Agent domain. Continue with “Installing the MTA for the WebAccess Agent Domain” on page 175. 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 155, then return to this point. You do not need to edit the MTA startup file. Continue with “Installing the WebAccess Agent in a Cluster” on page 176. Implementing WebAccess in a Microsoft Cluster 175 Installing 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. 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 shared disk of the WebAccess resource group (WebAccess Clustering Worksheet item 1). 2 Map a drive to c:\ on the first node in the cluster where you will set up the WebAccess Agent as a Windows service (System Clustering Worksheet item 2). 3 Ifyou plan to install the WebAccess Agent software to the shared disk of the WebAccess resource group (WebAccess Clustering Worksheet item 5), create the drive:\grpwise\webacc directory on the WebAccess shared disk accessed in Step 1. or If you plan to install the WebAccess Agent software to each node in the cluster, create the c:\grpwise\webacc directory on the drive accessed in Step 2. 4 Start the WebAccess Installation program, following the steps provided in “Installing the WebAccess Agent” in “Installing GroupWise WebAccess” in the GroupWise 6.5 Installation Guide. 5 Install the Windows WebAccess Agent, keeping in mind the following cluster-specific details: + On the Components page 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 during “Planning the WebAccess Installation” on page 174 to fill in the fields during the WebAccess Agent installation process. + On the Installation Path page, be sure to browse through the mapped drive to the installation directory you created in Step 3 above. + On the Gateway Directory page, be sure to browse to the domain directory through the drive you mapped in Step | above. + On the Execution Options page, be sure that Run WebAccess Agent as a Windows Service is selected. + On the Start Applications page, deselect Start the GroupWise WebAccess Agent. 6 Repeat Step 4 and Step 5, mapping a drive to each node in the cluster. Even if you installed the WebAccess Agent software to a shared disk, you need to repeat the installation process for each node so that the Internet Agent gets set up as a Windows service on each node. 7 Make sure you have completed all the WebAccess Agent tasks described in “Setting Up GroupWise WebAccess on NetWare or Windows” in “Installing GroupWise WebAccess” in the GroupWise 6.5 Installation Guide, but do not start the WebAccess Agent at this time. 8 Continue with “Installing and Configuring the WebAccess Application in a Cluster” on page 177. 176 GroupWise 6.5 Interoperability Guide Installing and Configuring the WebAccess Application in a Cluster Recall that the WebAccess Agent is the component of your WebAccess installation that accesses post offices and libraries to retrieve information for WebAccess client users. The WebAccess Application provides the link between the WebAccess Agent and the WebAccess clients’ Web browsers. To install the WebAccess Application: 1 Map a drive to the shared disk of the WebAccess resource group (WebAccess Clustering Worksheet item 1) where the WebAccess domain is located. 2 Map adrive to the first Web server node where you want to install the WebAccess Application (WebAccess Clustering Worksheet item 7). 3 Ifthe Web server node where you are going to install the WebAccess Application is currently running any applications that rely on Java or on the Web server, migrate those applications to another node in the cluster. If any GroupWise agents are running on the node, migrate the agents. 4 Stop the Web server. 5 Start the WebAccess Installation program as you did when you installed the WebAccess Agent (Step 5 on page 176). Keep in mind the following cluster-specific details: + On the Components page, select only GroupWise WebAccess Application. + Use items 13 through 19 on the GroupWise WebAccess Installation Worksheet that you filled out during “Planning the WebAccess Installation” on page 174 to fill in the fields during the WebAccess Application installation process. + On the Gateway Directory page, be sure to browse to the WebAccess gateway directory (domain\wpgate\webac60a) through the drive you mapped in Step | above. + On the Web Server Information page be sure to browse to the Web server root directory through the drive you mapped in Step 2 above. + On the Start Applications page, deselect Restart Web Server. 6 Make sure you have completed all the WebAccess Application tasks described in “Setting Up GroupWise WebAccess on NetWare or Windows” in “Installing GroupWise WebAccess” in the GroupWise 6.5 Installation Guide. 7 Copy the directory\docs\com directory from the server where you just installed the WebAccess Application to the document root directory of the Web server (WebAccess Clustering Worksheet item 13). 8 Restart the Web server. 9 Offline and then online the Web server to reestablish its resource group IP address. 10 Repeat Step 2 through Step 9 for each Web server node in the Web server resource group possible owners list (WebAccess Clustering Worksheet item 1). 11 Continue with “Testing Your Clustered WebAccess Installation” on page 177. Testing Your Clustered WebAccess Installation Remember that the WebAccess resource group and the Web server resource group are separate resource groups that could fail over to different nodes at different times. To thoroughly test your WebAccess installation: Implementing WebAccess in a Microsoft Cluster 177 4 5 Make sure the initial combination of WebAccess resource group and Web server resource group is functioning properly. Migrate the WebAccess resource group to each node in its possible owners list, making sure it functions with the initial Web server node. Migrate the Web server to a different node, migrate the WebAccess resource group to each node in its possible owners list, then make sure each combination works. Repeat Step 3 for each Web server resource group. Continue with “Managing WebAccess in a Cluster” on page 178. Managing WebAccess in a Cluster After you have installed WebAccess in a cluster, you should consider some long-term management issues. + + + “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 178 “Knowing What to Expect in WebAccess Failover Situations” on page 179 “Updating the WebAccess Agent Configuration File (commgr.cfg)” on page 179 Updating GroupWise Objects with Cluster-Specific Descriptions After installing WebAccess 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 WebAccess Agent Domain and Its MTA” on page 178 “Recording Cluster-Specific Information about the WebAccess Agent” on page 179 Recording Cluster-Specific Information about the WebAccess Agent Domain and Its MTA To permanently record important cluster-specific information for the WebAccess Agent domain: 1 2 og bh @ In ConsoleOne, browse to and right-click the Domain object, then click Properties. In the Description field of the WebAccess Agent domain Identification page, provide a cluster-specific description of the WebAccess Agent domain, including the resource group IP address and the cluster-unique port numbers used by its MTA. You might also want to include cluster-specific information about the WebAccess Application, such as the resource group IP address of the Web server where the WebAccess Application is installed. Click OK to save the WebAccess domain description. Select the WebAccess Domain object to display its contents. Right-click the MTA object, then click Properties. In the Description field of the MTA Identification page, record the WebAccess resource group IP address and the cluster-unique port numbers used by the MTA. This information will appear on the MTA console, no matter which node in the cluster it is currently running on. 178 GroupWise 6.5 Interoperability Guide 7 Click OK to save the MTA description. 8 Continue with “Recording Cluster-Specific Information about the WebAccess Agent” on page 179. Recording Cluster-Specific Information about the WebAccess Agent With the contents of the WebAccess domain still displayed: 1 Right-click the WEBAC65A object, then click Properties. 2 Click GroupWise > Identification. 3 In the Description field, record the WebAccess resource group IP address and the cluster- unique port numbers used by the WebAccess Agent. This information will appear on the WebAccess Agent console, no matter which node in the cluster it is currently running on. 4 Click OK to save the WebAccess Agent information. 5 Continue with “Knowing What to Expect in WebAccess Failover Situations” on page 179. Knowing What to Expect in WebAccess Failover Situations The failover behavior of the MTA for the WebAccess domain will be the same as for an MTA in a regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” on page 158. The WebAccess Application caches users’ credentials on the node where it is running. Therefore, if that node fails, or if the WebAccess Application migrates to a different node, the cached credentials are lost. Consequently, the user will need to restart the WebAccess client in order to re- authenticate and re-establish the credentials. If the WebAccess Agent fails over or migrates, the user receives an error message that the WebAccess Agent is no longer available. However, after the WebAccess Agent starts in its new location, the WebAccess Application passes the cached user credentials to the WebAccess Agent and the user reconnects automatically without having to re-authenticate. As with the MTA and the POA, migration of the WebAccess Agent takes longer than failover. However, the WebAccess Agent restarts quickly so that users are able to reconnect quickly. Updating the WebAccess Agent Configuration File (commgr.cfg) As part of installing WebAccess, the WebAccess Agent configuration file (commer.cfg) is created in the following subdirectory: domain\wpgate\webac65a It is also automatically copied to the following Web server subdirectory: drive:\novell\webaccess If you change WebAccess agent configuration information (for example, if you change its IP address), the information is changed in the following file: domain\wpgate\webac65a\commer.cfg because the domain is on the shared disk of a resource group, and it is changed in the following file: Implementing WebAccess in a Microsoft Cluster 179 drive:\novell\webaccess\commer.cfg on the node where the WebAccess Application is currently running. However, the other nodes in the Web server possible owners list are not currently available for update. Therefore, you must manually copy the updated commegr.cfg file to the drive:\novell\webaccess subdirectory on each node in the Web serve possible owners list. 180 GroupWise 6.5 Interoperability Guide WebAccess Clustering Worksheet Item 1) Resource Group for WebAccess Agent: Group name: Network name: IP address: Shared disk: Share name: MTA service resource: WebAccess Agent service resource: Possible owners: 2) WebAccess Agent Domain Name: Domain Directory: 3) MTA Installation Location: + Shared disk of WebAccess resource group + Each node in the cluster Consolidate MTA startup files? 4) MTA Network Information: MTA IP address: MTA message transfer port: MTA live remote port: MTA HTTP port: 5) WebAccess Agent Installation Location: + Shared disk of WebAccess resource group + Each node in the cluster 6) WebAccess Agent Network Information: WebAccess Agent IP address: WebAccess Agent HTTP port: 7) Physical Web Servers: Explanation Specify the information for the WebAccess resource group. For more information, see “Planning the WebAccess Resource Group” on page 173. Specify a unique name for the WebAccess Agent domain. Specify the directory on the WebAccess Agent resource group disk where you want to create the new domain. For more information, see “Planning a New Domain for the WebAccess Agent” on page 172. Mark the location where you will install the MTA software. If necessary, specify the location where you will consolidate the MTA startup files on the shared disk of the WebAccess resource group. For more information, see “Deciding Where to Install the WebAccess Agent and Its MTA” on page 173. Gather the MTA network address information from the WebAccess section of the “Network Address Worksheet” on page 146. For more information, see “Planning Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 173. Mark the location where you will install the WebAccess Agent software. For more information, see “Deciding Where to Install the WebAccess Agent and Its MTA” on page 173. Gather the WebAccess Agent network address information from the WebAccess section of the “Network Address Worksheet” on page 146. For more information, see “Planning Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 173. List the servers in the cluster where you are installing the Web server for use with WebAccess. For more information, see “Setting Up Your Web Server in the Microsoft cluster” on page 172. Implementing WebAccess in a Microsoft Cluster 181 Item Explanation 8) Web Server Record the secondary IP address for the Web server in the cluster. IP Address: For more information, see “Setting Up Your Web Server in the Microsoft cluster” on page 172. 9) Hardware Virtual Server Information: Record the hardware virtual server information for your shared disk system. + Dedicated IP address: For more information, see “Setting Up Your Web Server in the Microsoft cluster” on + Document root page 172. 182 GroupWise 6.5 Interoperability Guide Implementing GroupWise Gateways in a Microsoft Cluster A significant system configuration difference between a GroupWise® system in a clustering environment and a Group Wise system in a regular environment is that you need to create a separate domain to house each GroupWise gateway. The gateway domain should be created in its own resource group. This enables the gateway to fail over independently from other GroupWise components. If you have set up the Internet Agent or WebAccess in your clustered GroupWise system, you should already have the skills necessary to set up a GroupWise gateway as well. Group Wise gateways that have not received recent development have not been thoroughly tested in a clustering environment. If you are currently using such GroupWise gateways, you might want to leave them outside of your cluster. Implementing GroupWise Gateways in a Microsoft Cluster 183 184 GroupWise 6.5 Interoperability Guide Monitoring a GroupWise System in a Microsoft Cluster GroupWise® Monitor is similar to WebAccess in that it relies on a Web server for communication with administrators’ Web browsers. Consequently, the setup procedure for GroupWise Monitor in a Microsoft cluster is similar to the setup procedure for WebAccess. If you have set up WebAccess in your clustered GroupWise system, you should already have the skills necessary to set up GroupWise Monitor as well. When you first install Monitor, it gathers information about agents to monitor from a domain database (wpdomain.db). This provides the resource group IP address of each agent. When an agent fails over or migrates to a different node, its status in Monitor displays as Not Listening until it is up and running again, at which time its status returns to Normal. Because Monitor must use resource group IP addresses to monitor the agents in a clustered GroupWise system, the Discover Machine and Discover Network options do not work in a cluster. Resource group IP addresses cannot be obtained by examining the network itself. If you need to add agents to monitor, use the Add Agent option and provide the agent’s resource group IP address. For instructions on setting up GroupWise Monitor, see “Installing GroupWise Monitor” in the GroupWise 6.5 Installation Guide. Monitoring a GroupWise System in a Microsoft Cluster 185 186 GroupWise 6.5 Interoperability Guide Backing Up a GroupWise System in a Microsoft Cluster The issues involved in backing up a GroupWise” system in a Microsoft cluster are the same as in backing up any GroupWise system that is running on Windows. If you want to back up your Group Wise system while it is running, you must use backup software that can back up open files. If your backup software cannot back up open files, then you must stop all GroupWise agents before running the backup and start them again when the backup is finished. This means that Group Wise users cannot be logged into their mailboxes while backups are running. Backing Up a GroupWise System in a Microsoft Cluster 187 188 GroupWise 6.5 Interoperability Guide Moving an Existing GroupWise 6.5 System into a Microsoft Cluster If you are adding the high availability benefits of a Microsoft cluster to a GroupWise” 6.5 system that is already up and running, the first step is to set up the cluster and review Chapter 12, “Introduction to Group Wise 6.5 and Microsoft Clusters,” on page 131 to help you apply clustering principles and practices to your GroupWise system. You do not need to transfer your entire GroupWise system into the cluster all at once. You could transfer individual post offices where the needs for high availability are greatest. You could transfer a domain and all of its post offices at the same time. You might decide that you don’t need to have all of your GroupWise system running in the cluster. This section provides a checklist to help you get started with moving your Group Wise system into a Microsoft cluster: m) m) (E m) Decide which shared disks you will use for GroupWise administration (ConsoleOne® and the software distribution directory). Decide which shared disks you will use for GroupWise domains and post offices. Plan the resource groups for domains and post offices. Review Chapter 13, “Planning GroupWise in a Microsoft Cluster,” on page 133. Fill out the “System Clustering Worksheet” on page 144 to help you decide which domains and post offices you will move to which shared disks. Review “Planning Cluster-Unique Port Numbers for Agents in the Cluster” on page 139 and fill out the “Network Address Worksheet” on page 146 to record resource group IP addresses and to specify cluster-specific port numbers for all of your GroupWise agents. Select the first shared disk that will be part of your clustered GroupWise system and set up the resource group for it, following the instructions in “Creating GroupWise Resource Groups” on page 149 and “Configuring Short Name Resolution” on page 150. Move a domain and/or post office onto the shared disk, following the instructions in “Moving a Domain” in “Domains” or “Moving a Post Office” in “Post Offices” in the GroupWise 6.5 Administration Guide. Review “Deciding How to Install and Configure the Agents in a Cluster” on page 139, fill out the “Agent Clustering Worksheet” on page 147, and install the agents as needed for the first clustered domain and/or post office, following the instructions in “Installing and Configuring the MTA and the POA in a Cluster” on page 154. Test the first component of your clustered GroupWise system following the instructions in “Testing Your Clustered GroupWise System” on page 156. Take care of the cluster management details described in “Managing Your Clustered GroupWise System” on page 157. Moving an Existing GroupWise 6.5 System into a Microsoft Cluster 189 Q Move more domains and post offices into the cluster as needed. If you have GroupWise libraries, see “Planning a Library for a New Clustered Post Office” on page 135. QO) Move GroupWise administration into the cluster as needed. QO) Add other components to your clustered GroupWise system as needed, following the instructions in: + Chapter 15, “Implementing the Internet Agent in a Microsoft Cluster,” on page 161 + Chapter 16, “Implementing WebAccess in a Microsoft Cluster,” on page 171. + Chapter 17, “Implementing GroupWise Gateways in a Microsoft Cluster,” on page 183 ¢ Chapter 18, “Monitoring a GroupWise System in a Microsoft Cluster,” on page 185 + Chapter 19, “Backing Up a GroupWise System in a Microsoft Cluster,” on page 187 190 GroupWise 6.5 Interoperability Guide Implementing Messenger in a Microsoft Cluster Novell® Messenger does not require the existence of a GroupWise® system in your Microsoft cluster, but presumably one has already been set up as described in Chapter 13, “Planning Group Wise in a Microsoft Cluster,” on page 133 and Chapter 14, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149. As part of the process of setting up GroupWise in your cluster, you filled out the “System Clustering Worksheet” on page 144. Some of the information from this worksheet will be helpful as you implement Messenger in your cluster. + “Planning Your Messenger System in a Cluster” on page 191 ¢ “Setting Up Your Messenger System in a Cluster” on page 194 + “Messenger Clustering Worksheet” on page 196 Planning Your Messenger System in a Cluster Because the Messenger agents are not associated with GroupWise domains or post offices, the Messenger agents are easier to implement in a cluster than are the GroupWise agents. The “Messenger Clustering Worksheet” on page 196 lists all the information you will need as you set up the Messenger agents in a clustering environment. You should print the worksheet and fill it out as you complete the tasks listed below: + “Understanding Your Cluster” on page 191 + “Planning Messenger Administration” on page 191 + “Deciding Where to Install the Messenger Agent Software” on page 192 + “Planning the Messenger Agent Installation” on page 193 Understanding Your Cluster Fill out items 1 and 2 on the “Messenger Clustering Worksheet’ on page 196 with information about your cluster. This information corresponds to items 1 and 2 on the “System Clustering Worksheet” on page 144 that you filled out for GroupWise. For background information, see “Setting Up Your Microsoft Cluster” on page 134. Planning Messenger Administration If you have set up a shared disk for GroupWise administration, as described in “Planning Shared Administrative Resources” on page 137, you can use the same shared disk for the Messenger administration files. For example, you might want to have a shared disk where you install the Messenger snap-in to ConsoleOne® instead of installing it to multiple administrator workstations. Implementing Messenger in a Microsoft Cluster 191 MESSENGER CLUSTERING WORKSHEET Under Item 5: Installation Location for Messenger Administration, mark whether you want to install the Messenger snap-in to ConsoleOne to administrator workstations or to a shared disk. If you plan to install the Messenger snap-in to ConsoleOne to a shared disk, under Item 6: Resource for Messenger Administration, list the network name and IP address of the shared disk, the physical disk name and file share for mapping to it, and the nodes in the cluster that it could fail over to. Deciding Where to Install the Messenger Agent Software In a Microsoft cluster, the Messenger agents must run as Windows services. When you install the Windows Messenger Agents, you can choose between two different installation locations: Location Description Each node in the The c:\novell\nm directory is the default installation location provided by the cluster Messenger Installation program. Shared disk If you create a drive:\novell\nm directory on a shared disk, the Messenger agent software and startup files fail over and back along with supporting files such as the Messenger archive. IMPORTANT: You must install to a shared disk if you do not want a separate Messenger archive to be created on each node where the Archive Agent runs. If you do not want to use a shared disk, you should plan to install the Archive Agent separately outside the cluster. Because the Messenger agents must be installed as Windows services in a Microsoft cluster, you must initially run the Messenger Installation program for each node in the cluster so that the Windows services for the agents get created, regardless of where you are planning to run the Messenger agents from. However, for updates, you need to run the Messenger Installation program only once if you are running the Messenger agents from a shared disk. MESSENGER CLUSTERING WORKSHEET Under Item 3: Installation Location for Messenger Agents, mark whether you want to install the Messenger agent software to each node in the cluster or to a shared disk. Continue with the planning instructions for the installation location you want to use: + “Planning the Messenger Agents on Each Node in the Cluster” on page 192 ¢ “Planning the Messenger Agents on a Shared Disk” on page 193 Planning the Messenger Agents on Each Node in the Cluster Make sure you have filled out item 20n the Messenger Clustering Worksheet with a complete list of nodes in the cluster where you need to install the Messenger agents. Continue with “Planning the Messenger Agent Installation” on page 193. 192 GroupWise 6.5 Interoperability Guide Planning the Messenger Agents on a Shared Disk If you do not anticipate a large Messenger archive, you can use one Messenger shared disk. If you anticipate archiving a large number of messages so that the Messenger archive grows very large, you might want to have a separate Messenger shared disk for the Archive Agent and the archive database. The steps in this section cover setting up the Messenger agents on a single shared disk. MESSENGER CLUSTERING WORKSHEET Under Item 4: Resource Group for Messenger Agents, plan the network name and IP address of the resource group, the physical disk and share name for mapping to it, the agent service names, and the nodes in the cluster where the Messenger resource group can fail over. Continue with “Planning the Messenger Agent Installation” on page 193. Planning the Messenger Agent Installation Aside from the cluster-specific issues discussed in the preceding sections, the considerations involved in planning to install the Messenger agents are the same in a clustering environment as for any other environment. Review “Planning Your Novell Messenger System”, then print and fill out the “Novell Messenger System Worksheet” in “Installing a Novell Messenger System” in the Messenger 1.0 Installation Guide. Transfer the following information from the Messenger Clustering Worksheet to the Messenger System Worksheet: ¢ For Item 3: Installation Path on the Messenger System Worksheet: ¢ If you are installing the Messenger agents to each node in the cluster, use c:\novell\nm. ¢ If you are installing the Messenger agents to a shared disk, use drive:\novell\nm where drive is the shared disk from Item 4: Resource Group for Messenger Agents on the Messenger Clustering Worksheet. + Under Item 12: Server Address on the Messenger System Worksheet: + If you are installing the Messenger agents to each node in the cluster, use the cluster IP address from Item 1: Cluster Identification on the Messenger Clustering Worksheet. ¢ If you are installing the Messenger agents to a shared disk, specify the Messenger resource group IP address from Item 4: Resource Group for Messenger Agents on the Messenger Clustering Worksheet. + Under Item 13: Configure Agents for Clustering? on the Messenger System Worksheet, mark No. This applies to the Messenger Agents running with Novell Cluster Services, not in a Microsoft cluster. + Under Item 14: Admin Configuration on the Messenger System Worksheet: + If you are installing the Messenger snap-in to ConsoleOne to an administrator workstation, use the location where ConsoleOne is already installed (typically c:\novell\consoleone\version_number). ¢ If you are installing the Messenger snap-in to ConsoleOne to a shared disk, use drive:\directory, where drive is the shared disk from Item 6: Resource for Messenger Administration on the Messenger Clustering Worksheet and directory is typically c:\novell\consoleone\version_number. Continue with “Setting Up Your Messenger System in a Cluster” on page 194. Implementing Messenger in a Microsoft Cluster 193 Setting Up Your Messenger System in a Cluster You should have already reviewed “Planning Your Messenger System in a Cluster” on page 191 and filled out the “Messenger Clustering Worksheet” on page 196 and the “Novell Messenger System Worksheet” in the Messenger 1.0 Installation Guide. Follow the instructions for the installation location you have chosen: + “Installing the Messenger Agents to Each Node in the Cluster” on page 194 + “Installing the Messenger Agents to a Shared Disk” on page 194 Installing the Messenger Agents to Each Node in the Cluster 1 Follow the steps provided in “Starting the Messenger Installation Program” and “Creating Your Messenger System” in “Installing a Novell Messenger System” in the Messenger 1.0 Installation Guide for each node in the cluster. 2 After you have installed the software to each node in the cluster, if you selected Yes for Consolidate Startup Files? (under Messenger Clustering Worksheet item 3), copy the Messenger agent startup files to the planned location on the shared disk, then delete them from the c:\novell\nm\ma and c:\novell\nm\aa directories on each node to avoid future confusion. 3 Make each node in the cluster active to make sure that the Messenger agents start successfully on each node. 4 Continue setting up your Messenger system following the instructions in “What's Next” in “Installing a Novell Messenger System” in the Messenger 1.0 Installation Guide Installing the Messenger Agents to a Shared Disk Complete the following tasks to set up your Messenger system on a shared disk: + “Setting Up the Messenger Resource Group” on page 194 + “Running the Messenger Installation Program” on page 194 + “Testing the Clustered Messenger Agents” on page 195 Setting Up the Messenger Resource Group 1 Create the Messenger resource group and agent services resources (Messenger Clustering Worksheet item 4), as planned in “Planning the Messenger Agents on Each Node in the Cluster” on page 192. 2 To ensure successful short name resolution, add entries for the Messenger network name to support your preferred methods of short name resolution, as described in “Configuring Short Name Resolution” on page 150. 3 Continue with “Running the Messenger Installation Program” on page 194. Running the Messenger Installation Program 1 Ifnecessary, map a drive to the shared disk for Messenger administration (Messenger Clustering worksheet item 6) where you will install the Messenger snap-ins to ConsoleOne. 2 Map a drive to the shared disk of the Messenger resource group (Messenger Clustering Worksheet item 4) where you will install the Messenger agent software. 194 GroupWise 6.5 Interoperability Guide 3 Map a drive to c:\ on the first node in the cluster (Messenger Clustering Worksheet item 2) where you will set up the Messenger agents as a Windows services. 4 Start the Messenger Installation program, following the steps provided in “Setting Up Your Novell Messenger System” in “Installing a Novell Messenger System” in the Messenger 1.0 Installation Guide. 5 Install the Windows Messenger agents, keeping in mind the following cluster-specific details: + Use the Novell Messenger System Worksheet that you filled out during “Planning the Messenger Agent Installation” on page 114 to fill in the fields during the Messenger installation process. + When you specify the Messenger installation directory, be sure to browse to the location through the drive mapped in Step 2 above. + When you specify the ConsoleOne directory, be sure to browse to the location through the drive mapped in Step | above. + On the Setup Complete page, do not select Launch Agents Now. 6 Repeat Step 4 and Step 5, mapping a drive to each node in the cluster. Initially, you need to repeat the installation process for each node so that the Messenger agents are set up as Windows services on each node. For updates, you need to install only once to the shared disk. 7 Continue with “Testing the Clustered Messenger Agents” on page 195. Testing the Clustered Messenger Agents After you have set up the Messenger agents on a shared disk in your Microsoft cluster, you can test them by manually bringing the Messenger resource group online and taking it offline again. Continue setting up your Messenger system following the instructions in “What's Next” in “Installing a Novell Messenger System” in the Messenger 1.0 Installation Guide Implementing Messenger in a Microsoft Cluster 195 Messenger Clustering Worksheet Item 1) Cluster Identification: Cluster name: Cluster IP address: 2) Nodes in Cluster: 3) Installation Location for Messenger Agents: + Each node in the cluster Consolidate startup files? + Shared disk 4) Resource Group for Messenger Agents Network name: IP address: Physical disk: File share: Messaging Agent service: Archive Agent service: Possible owners: 5) Installation Location for Messenger Administration: + Administrator workstation(s) + Shared disk 6) Resource for Messenger Administration: Network name: IP address: Physical disk: File share: Possible owners: 7) IP Address Resolution Methods: + eDirectory + hosts file + DNS 196 GroupWise 6.5 Interoperability Guide Explanation Record the name and IP address of your Microsoft cluster. For more information, see “Setting Up Your Microsoft Cluster” on page 134. List the servers that are included in your Microsoft cluster. For more information, see “Setting Up Your Microsoft Cluster” on page 134. Mark the location where you will install the Messenger agent software. For more information, see “Deciding Where to Install the Messenger Agent Software” on page 192. If you plan to install the Messenger agent software to a shared disk, provide the information about the shared disk you want to use. For more information, see “Planning the Messenger Agents on a Shared Disk” on page 193. Mark the location where you want to install the Messenger snap-in to ConsoleOne. For more information, see “Planning Messenger Administration” on page 191. If you want to install the Messenger snap-in to ConsoleOne to a shared disk, provide the required information about the shared disk you want to use. For more information, see “Planning Shared Administrative Resources” on page 137. Mark the short name address resolution methods you want to implement to ensure that the UNC paths stored in ConsoleOne with network names can be successfully resolved into physical network addresses. For more information, see “Ensuring Successful Name Resolution for GroupWise Resource Groups” on page 137. Non-GroupWise Clients If your users already have a common POP or IMAP e-mail client that comes with Linux or Windows, they can continue to use it to access their GroupWise® mailboxes. Users of non- Group Wise e-mail clients retain the feature sets of their familiar e-mail clients, but many Group Wise features are not available to such users because they are not offered in POP and IMAP e-mail clients. If your users have a mobile device (Palm* OS or Pocket PC) and want to synchronize it with Group Wise, they can accomplish this by using GroupWise PDA Connect 1.0. In addition, there are several third-party tools available from third-party partners. + Chapter 22, “Outlook Express,” on page 199 ¢ Chapter 23, “Microsoft Outlook,” on page 201 + Chapter 24, “Mobile Devices,” on page 203 Non-GroupWise Clients 197 198 GroupWise 6.5 Interoperability Guide Outlook Express The Group Wise Internet Agent is required in order for users to access their mailboxes using non- Group Wise clients. If you have not already installed the Internet Agent, follow the instructions in the GroupWise 6.5 Installation Guide, available on the GroupWise 6.5 Documentation page (http:/ /www.novell.com/documentation/gw65/index.html). In order for users to access their GroupWise® mailboxes from a third-party e-mail client, they must configure their e-mail clients to access their GroupWise accounts. For example, Outlook Express users would follow steps similar to the following: NOTE: Steps might vary depending on the versions of Windows* and Outlook* Express installed on the workstation. 1 In Outlook Express, click Tools > Accounts > Add > Mail. 2 Follow the prompts and provide personal information until you are prompted for the e-mail server information. Internet Connection Wizard xj E-mail Server Names My incoming mail serverisa |POP3 v| server. Incoming mail (POP3, IMAP or HTTP) server: An SMTP server is the server that is used for your outgoing e-mail. Outgoing mail (SMTP) server: cres | 3 Select POP3 or IMAP as your incoming mail server type. 4 In the Incoming and Outgoing Mail fields, specify the IP address or hostname of your mail server, then click Next. If you do not know your mail server information, contact your GroupWise administrator. It is the IP address or hostname of the server where the Internet Agent for your Group Wise system is running. 5 Continue following the prompts and providing personal information until the new account has been set up in Outlook Express. 6 Click Tools > Accounts. 7 Select the new account you just created, then click Properties > Servers. Outlook Express 199 2 gwmail.net Properties 2) x) General Servers | Connection | Security | Advanced | Server Information My incoming mail server is a server. Incoming mail(POP3}: [awmailnet Dutgoing mail (SMTP): [owman Incoming Mail Server Account name: ltanaka Password: ee o V Remember password T Log on using Secure Password Authentication Outgoing Mail Server IV My server requires authentication Settings 8 Select My Server Requires Authentication, then click OK. The default setting for server authentication is Use Same Settings as My Incoming Mail Server, so you do not need to change any settings. 9 To access your GroupWise mailbox in Outlook Express, click Tools > Send and Receive. 10 Click the IP address or hostname of your mail server. 11 Provide your username and password, then click OK. 200 GroupWise 6.5 Interoperability Guide Microsoft Outlook The GroupWise Internet Agent is required in order for users to access their mailboxes using non- Group Wise clients. If you have not already installed the Internet Agent, follow the instructions in the GroupWise 6.5 Installation Guide, available on the GroupWise 6.5 Documentation page (http:/ /www.novell.com/documentation/gw65/index.html). If your users have been using the Microsoft* Outlook e-mail client that comes with Microsoft Office, they can continue to use POP or IMAP in it to access their GroupWise® mailboxes. In order for users to access their GroupWise mailboxes from Outlook, they must configure Windows to access their GroupWise accounts. For example, Outlook users would follow steps similar to the following. NOTE: Steps might vary depending on the versions of Windows and Outlook installed on the workstation. 1 In the Windows Control Panel, double-click Mail. 2 Click Show Profiles > Add to add a new profile for your Group Wise account. 3 Type a name for the new profile, the click OK. 4 Select Add a New E-Mail Account, then click Next. E-mail Accounts E 2) x) Server Type gA You can choose the type of server your new e-mail acount will work with. > C Microsoft Exchange Server Connect to an Exchange server to read e-mail, access public folders, and share documents. C pops Connect to a POP3 e-mail server to download your e-mail, C IMAP Connect to an IMAP e-mail server to download e-mail and synchronize mailbox folders. C HTTP Connect to an HTTP e-mail server such as Hotmail to download e-mail and synchronize mailbox folders. C Additional Server Types Connect to another workgroup or 3rd-party mail server. Next Cancel | 5 Select POP3 or IMAP as your incoming mail server type, then click Next. Microsoft Outlook 201 zizi Internet E-mail Settings (POP3) sA >ii Each of these settings are required to get your e-mail account working. User Information Server Information Your Name: | Incoming mail server (POP3): E-mail Address; | Outgoing mail server (SMTP): Logon Information Test Settings User Name: LOOO yO After filling out the information on this screen, we recommend you test your account by clicking the button Password: | below, (Requires network connection) IZ Remember password Test Account Settings s T Log on using Secure Password Authentication (SPA) Next Cancel | 6 Provide the e-mail account settings for the type of server you selected. If you do not know your mail server information, contact your GroupWise administrator. It is the IP address or hostname of the server where the Internet Agent for your Group Wise system is running. 7 Click Test Account Settings to make sure that you have provided the information correctly. 8 Click Next, then click Finish. 202 = GroupWise 6.5 Interoperability Guide Mobile Devices If you own a mobile device (Palm OS or Pocket PC), you can synchronize it with GroupWise® using GroupWise PDA Connect 1.0. GroupWise PDA Connect is designed to work on a Windows computer to synchronize data between GroupWise and a PDA device. It is comprised of a synchronization engine and translators, which are used for seamless integration with the data source’s features and data. + “Prerequisites for PDA Connect 1.0” on page 203 + “Downloading Required Software” on page 203 + “Third-Party Partners” on page 204 Prerequisites for PDA Connect 1.0 Before installing GroupWise PDA Connect 1.0: + Ensure that Microsoft* ActiveSync* is installed for the Pocket PC or Palm HotSync* Manager is installed for the Palm OS. ¢ Ensure that GroupWise 6.5.3 is installed. ¢ Ensure that you are not synchronizing anything in Outlook (such as e-mail, calendar, tasks, or notes) in either ActiveSync or PocketMirror*. Downloading Required Software Downloading GroupWise 6.5.3 You can download the required GroupWise Support Pack from the GroupWise 6.5 Product Updates page (http://support.novell.com/filefinder/16963/index.html). The download is available as a self-extracting (.exe) file. 1 In the list of Support Packs, click GroupWise 6.5 Client SP3. 2 Click the filename (gw65sp3c.exe), then follow the instructions to download the file into a temporary directory. 3 Extract the .exe file into a directory at the root of your local drive or to a network server drive that can handle long pathnames. The compressed file contains directory paths that could exceed DOS limits. 4 Click Start > Run > Browse. 5 Select the setup.exe file on the local or network drive. 6 Click OK to run the GroupWise Installation program. Mobile Devices 203 7 Follow the on-screen instructions provided in the GroupWise installation to update the client software. Downloading GroupWise PDA Connect 1.0 Group Wise PDA Connect 1.0 is available for download at the Novell Product Downloads Web site (http://download.novell.com/pages/PublicSearch.jsp). The download is an executable (.exe) file. 1 Select GroupWise as the product, then click Submit Search. Click GroupWise PDA Connect 1.0. Click the filename (setup.exe), then follow the instructions to download the file. Click Start > Run > Browse. Select the setup.exe file on the local or network drive. Click OK to run the GroupWise PDA Connect Installation program. vu Oo GF A WO N Follow the on-screen instructions provided in the GroupWise PDA Connect Installation to install the software. Third-Party Partners Novell partners with several third-party companies for synchronization of mobile devices. A complete list of the third-party partners can be found on the GroupWise Partner Product page (http://www.novell.com/partnerguide/p 10003 1.html). 204 GroupWise 6.5 Interoperability Guide Unsupported Web Servers The GroupWise WebAccess Installation program installs the WebAccess and WebPublisher Applications to the Web servers listed in “WebAccess System Requirements” in “Installing GroupWise WebAccess” in the GroupWise 6.5 Installation Guide. These are the Web servers for which Novell Support provides support. You can manually set up WebAccess to work with other Web servers and servlet engines by completing the following tasks: + Chapter 25, “Installing WebAccess to Unsupported Web Servers,” on page 207 + Chapter 26, “Configuring WebAccess to Use a Java Servlet Engine Other Than the Novell Servlet Gateway or Tomcat Servlet Engine,” on page 209 Unsupported Web Servers 205 206 GroupWise 6.5 Interoperability Guide Installing WebAccess to Unsupported Web Servers If necessary, you can run the WebAccess and WebPublisher Applications on an unsupported Web server as long as the Web server supports a Java servlet engine that is JSDK 2.0 and JDK* 1.1.6 compatible. However, the Installation program does not install the applications to other Web servers, which means you must manually install and configure them. When you run the Installation program, deselect the options to install the WebAccess Application and WebPublisher Application, install the WebAccess Agent, then complete the following steps to install the applications: 1 Unzip webaccess.zip to the root of the network server volume where the Web server resides. The webaccess.zip file and the ZIP files referred to in the next three steps are in the \internet\webacces\other directory of each GroupWise 6.5 Support Pack. 2 Unzip webaccessdocs.zip to the Web server’s document root directory. 3 Unzip webaccessservlets.zip to the servlet root directory. 4 Unzip webaccessjars.zip to a library or jar file directory on the network server (for example, you might want to create a \novell\lib directory), then add the jar files (Idapfilt.jar, Idapjdk jar, njgwap.jar, njweb.jar, spellservlet.jar, xalan.jar, and xerces.jar) to the class path. 5 Modify your Java engine’s servlet properties file to include the settings provided in the sample WebAccess servlets.properties file. The WebAccess servlet.properties file is located in the \internet\webacces\other directory of each Group Wise 6.5 Support Pack. 6 Modify the Templates.path setting in the webacc.cfg and webpub.cfg files, located in the \novell\webaccess and \novell\webpublisher directories, to replace java/servlets with the path to the servlet root directory. 7 Ifyou created the \novell directory structure in the location specified in Step 4 (the root of the volume where the Web server resides), the paths for the following settings in the webacc.cfg and webpub.cfg should already be correct. If not, you need to modify the paths to make them correct from the perspective of the Web server. File.Upload.path Log.path Security. Timeout.path Provider.G WAP.Config.file Provider.LDAP.Config. file (webacc.cfg only) 8 Copy the index.html file to the Web server's document root directory. You can replace your Web server's current default home page with this file, or you can rename the file and link to it from your current default home page. 9 Copy the commer.cfg file, located in the WebAccess gateway home directory (domain\wpgate\webac65a), to the \novell\webaccess directory and the \novell\webpublisher directory. Installing WebAccess to Unsupported Web Servers 207 208 = GroupWise 6.5 Interoperability Guide Configuring WebAccess to Use a Java Servlet Engine Other Than the Novell Servlet Gateway or Tomcat Serviet Engine If you use a Java servlet engine other than the Novell Servlet Gateway or the Tomcat servlet engine, the servlet engine needs to be JSDK 2.0 and JDK 1.1.6 compatible. After you've installed WebAccess, complete the following steps to configure WebAccess to work with the Java servlet engine: 1 Modify the Java servlet engine’s servlet properties file to include the settings provided in the sample WebAccess servlets.properties file. The sample servlets.properties file is located in the \internet\webacces\other directory of each Group Wise 6.5 Support Pack. 2 In the webacc.cfg and webpub.cfg files, modify the Templates.path setting to replace java/ servlets with the path to the servlet root directory. The files are located in the novell\webaccess and novell\webpublisher directories on the root of the server. 3 Add the WebAccess jar files (Idapfilt jar, Idapjdk.jar, njgwap.jar, njweb.jar, spellservlet.jar, xalan.jar, and xerces.jar) to the class path. On a NetWare server, the jar files are located in the java\lib directory. On a Windows server, the files are located in the novell\java\lib directory. Configuring WebAccess to Use a Java Servlet Engine Other Than the Novell Servlet 210 GroupWise 6.5 Interoperability Guide Documentation Updates This section lists updates to the GroupWise 6.5 Interoperability Guide that have been made since the initial release of GroupWise® 6.5. The information will help you to keep current on documentation updates and, in some cases, software updates (such as a Support Pack release). The information is grouped according to the date when the GroupWise 6.5 Interoperability Guide was republished. Within each dated section, the updates are listed by the names of the main table of contents sections. The GroupWise 6.5 Interoperability Guide has been updated on the following dates: + + + + + + “October 31, 2005” on page 211 “September 19 2005 (GroupWise 6.5 SP5)” on page 211 “January 31, 2005” on page 212 “November 30, 2004 (GroupWise 6.5 SP3)” on page 212 “September 30, 2004” on page 212 “September 30, 2003” on page 213 October 31, 2005 Location Change Novell Cluster Services “Deciding Whether to Run Strongly recommended running the agents in protected memory, with the Agents in Protected each agent in a separate memory space. Memory” on page 30 “Deciding Whether to Run Strongly recommended running the Internet Agent as well as its MTA the Internet Agent and Its in protected memory, with each agent in a separate memory space. MTA in Protected Memory” on page 66 September 19 2005 (GroupWise 6.5 SP5) Location Change Identity Manager Documentation Updates 211 Location Change Chapter 11, “Identity Updated the product name from DirXML® to Novell® Identity Manager. Manager Warnings in ConsoleOne,” on page 123 Non-GroupWise Clients Chapter 22, “Outlook Indicated that mail server information must be obtained from your Express,” on page 199 GroupWise administrator. Chapter 23, “Microsoft Updated the instructions for accessing your GroupWise mailbox from Outlook,” on page 201 Microsoft Outlook. Indicated that mail server information must be obtained from your GroupWise administrator. January 31, 2005 Location Change Mobile Devices Chapter 24, “Mobile Added a section for mobile devices. Devices,” on page 203 November 30, 2004 (GroupWise 6.5 SP3) Location Change Unsupported Web Servers “Installing WebAccess to Moved information from the Readme to the Interoperability Guide. Unsupported Web Servers” on page 207 and “Configuring WebAccess to Use a Java Servlet Engine Other Than the Novell Servlet Gateway or Tomcat Servlet Engine” on page 209 September 30, 2004 Location Change Novell Cluster Services “Deciding Whether to Run Corrected the recommendations for placing the Internet Agent into the Internet Agent and Its protected memory. MTA in Protected Memory” on page 66 and “Internet Agent Clustering Worksheet” on page 78 212 GroupWise 6.5 Interoperability Guide Location Change “Planning WebAccess ina Clarified that NetWare® 6.5 provides Apache and Tomcat rather than Cluster” on page 83 and the Netscape Enterprise Web Server for NetWare and that Apache and “Setting Up WebAccess ina Tomcat are not currently supported in a cluster. Cluster” on page 88 “Deciding Whether to Run Corrected the recommendations for placing the WebAccess Agent into the WebAccess Agent and protected memory. Its MTA in Protected Memory” on page 86 and “WebAccess Clustering Worksheet” on page 99 Non-GroupWise Clients “Non-GroupWise Clients” on Added instructions for connecting to a GroupWise system from a non- page 197 GroupWise client, such as Outlook*. September 30, 2003 Location Change Novell Cluster Services “Forcing Use of the Internet Corrected Step 1 with the appropriate ConsoleOne property page. Agent Secondary IP Address” on page 75 and “Forcing Use of the Internet Agent Resource Group IP Address” on page 167 Documentation Updates 213 214 GroupWise 6.5 Interoperability Guide