Novell Home

GroupWise 5.x Best Practices Guide

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 12 Jan 2000
 

Current version: GroupWise 5.x

Introduction

This guide is intended to serve as a set of considerations and guidelines for GroupWise administrators, and is provided to you under the conditions set forth in the disclaimer. It is not a comprehensive instruction set, and it is not intended to replace product manuals. Administrators using this guide should consult product documentation, Technical Information Documents, and on-line help for further instruction regarding each of the bulleted guidelines below.

We recognize that administrators are often restricted in the changes they make to their GroupWise Systems. Some of the practices outlined below may be difficult or cost-ineffective to implement, depending on the state of the existing GroupWise system. Use these guidelines where possible in expanding systems or creating new systems, but temper their application with your experience and knowledge of your organization's unique computing environment.

For Small Business Suite administrators, you won't need to pay much attention to the sections that describe how to set up and manage large systems. However, if your network expands and you find yourself upgrading to full-blown NetWare, you should study the sections on NDS Configuration, Post Office Sizing and Configuration, and Domain Sizing and Configuration. Remember that if you set things up wisely on your small system now, it will save you a lot of grief when it comes time to expand. For example, if you follow the guidelines outlined in the section on Internet Addressing, and take the time to establish smart naming conventions so that you always assign GroupWise IDs that are unique system-wide, your users will always have unique Internet addresses, even if you have to move them to different post offices.

Contents

System Design

Post Office Sizing and Configuration

For more information on sizing and configuring post offices, refer to the August, 1999 Novell AppNotes,
and to the GroupWise Sizing Recommendations TID (#10016883).

  • Assign between 500 and 700 mailboxes to each post office.
    There is some controversy over the ideal size of a GroupWise Post Office, and it stems from the fact that no two post offices are the same. It has been our experience that while some organizations have successfully implemented 1000-mailbox or larger post offices, performance is consistently better for smaller numbers of mailboxes.

    Post offices with heavy message flow, or where users are accessing GroupWise for full collaboration (calendars, task lists, shared folders, document management, etc.) demand more resources than post offices where GroupWise is only used for e-mail.

    Often a very large post office will perform well for an extended period before performance "mysteriously" begins to degrade. This is typically a function of increased exploitation of the product's features by its users. Adhering to the 500 to 700 mailbox guideline should ensure that users have the room to grow into the full collaboration GroupWise offers.

  • Assign no more than one GroupWise post office to each file server.
    Again, there is controversy over this issue. The principle behind this guideline is simple: a single POA can favor client/server threads over indexing or message handling threads. Multiple POAs cannot. They cannot "talk" with each other to announce that they have pending client/server requests, and other tasks should be suspended for a while.

    Many customers run successfully with more than one post office on a single file server, but some experience problems. As previously mentioned, this depends largely on the degree to which users are employing GroupWise as a full collaboration tool.

  • Configure every post office for Client/Server Only access mode.
    The GroupWise Information Store is reliable only if users have no file system rights to it. In Direct Access mode, users must have file system rights, and a GPF or cold-reboot can result in incomplete transactions and damage to database files.

    Windows 95 and 98 allow for "write-behind caching" to enhance responsiveness of the Windows interface. This feature, enabled by default, will always introduce some level of corruption in GroupWise store files if users run in Direct Access mode.

  • Dedicate a server volume (e.g. MAIL) for the post office on the file server.
    Separating applications and data from the SYS volume on NetWare servers is generally a good idea. Should the MAIL volume fill up for one reason or another, SYS operations (Directory Services, most notably) will continue. Performance will still suffer, but TTS will not shut down.

  • For large post offices (400 or more users), dedicate the server to GroupWise.
    E-mail has evolved from a nice utility to have to a mission critical application. Novell encourages customers to treat it as such. Deliver other applications and services from separate hardware.

  • Tune the POA and the NetWare server according to the "GroupWise Sizing Recommendations" document. (TID # 10016883)
    This document is the result of extensive experience with "real world" post offices. The tuning parameters provided in this document have been proven to improve GroupWise agent performance.

  • On large systems, create one POA for ngwnameserver redirection.
    If you have more than 2,000 users, then there is some likelihood that at least a hundred of them will need to use redirection to find their post office in the morning. Dedicating a lightweight server to the task of ngwnameserver redirection prevents another post office from suffering a performance hit every morning as users log on. An existing Post Office can provide the home directory for the ngwnameserver POA, but the agent should be run on separate hardware.

    The benefits of this configuration increase on larger systems (10,000+ users). Note that for organizations using a local DNS for each site, the DNS ngwnameserver entry should point to a local POA, not one across a WAN link.

Domain Sizing and Configuration

For more information on sizing and configuring post offices, refer to the August, 1999 Novell AppNotes, and to the GroupWise Sizing Recommendations TID (#10016883).

  • Assign less than 20 full-size post offices per domain.
    If we assume that a well-configured MTA can sustain throughput of 100,000 messages per day, and we also assume that each user sends and receives 10 messages per day, then twenty 500-mailbox post offices will generate 100,000 messages.

    This guideline assumes that all post offices are linked to the domain with Message Transfer ports and IP addresses. If UNC links are used then a domain should support no more than six full-size (500-mailbox) post offices.

  • Link all LAN domains mesh-style with IP addresses.
    Mesh-style linking is somewhat tedious to configure, but on a single, switched LAN it provides the most efficient transfer of data. Indirect, hub-style linking can seriously burden the hub domain, and presents a single-point-of failure as well.

  • Link all post offices to their domains with Message Transfer ports and IP addresses.
    IP connectivity between domains and post offices prevents the MTA from polling each post office directory in turn. This polling can severely impact performance, and poses serious problems if there are post offices over WAN connections.

    Exceptions may be made when the post office and domain are on the same file server.

  • Link to and between WAN domains indirectly through a single WAN Connection domain.
    While mesh-style connectivity should be the rule on the LAN, it poses serious problems for domains across WAN connections. TCP connections may time out, and throughput may be erratic. Establishing a domain for routing at each WAN connection prevents these problems by bringing the "store-and-forward" aspect of communication up to the application level where time-outs are not an issue.

    It may be profitable to create a post office in each of several small remote offices. In this situation a single domain should be able to server many small post offices across WAN links - provided all post offices are linked via IP.

  • Create a separate Routing domain for GWIA, defined as Default Routing Domain.
    The GWIA is easily the highest-traffic gateway on the average GroupWise system. As such, it should have its own, dedicated MTA. If Internet Addressing has been enabled (see below) this domain and MTA should be defined as the Default Routing Domain. In this way all mail sent to internet addresses on other systems will pass through this domain, whether for direct MTA connectivity, or for translation and transfer through the GWIA.

    The GWIA and the MTA for the Default Routing Domain should be loaded on the same server where the domain directory resides.

  • Separate domains for other gateways, depending on traffic.
    The Async, Exchange, Notes, and other gateways may merit their own domain or domains, based on the amount of traffic.

    Gateways providing alternative mailbox access gateways (Async, WebAccess, and GWIA POP3/IMAP) should be as close to the users' home post offices as possible. In a large, distributed environment you may choose to configure more than one each of these gateways, and place them accordingly.

Internet Addressing

For more information about Internet Addressing, refer to the Internet Addressing Summary TID (#2942047) on the Novell Support Connection, and the Internet Addressing Guide in the Online Documentation.

  • Enable Internet Addressing, but only after considering all points below.
    We do recommend enabling Internet Addressing. Future releases of GroupWise will leverage this feature heavily. In fact much of the GroupWise 5.5 Enhancement Pack depends on Internet Addressing.

    Issues with Internet Addressing are given very high priority at Novell. If customers have difficulties with this feature, Novell is completely committed to resolving those problems.

  • Set the Preferred Address Format to userID@IDomain.
    The User.PO.Domain and User.PO Preferred Addressing Format options will prove to be somewhat problematic for moved users. The First.Last and Last.First options will be problematic for large organizations where full-name uniqueness cannot be guaranteed (even small organizations may have two users with the same full names).

    Note that mail may still be addressed in the First.Last or Last.First format, and it will be delivered correctly provided there is no ambiguity. The Preferred Addressing Format only affects the "reply-to" field seen by Internet recipients.

  • Establish naming conventions for GroupWise userIDs such that each userID is unique system-wide.
    This recommendation may be tedious to implement, but the benefits are obvious: Users system-wide will have unique Internet addresses, and those addresses will continue to work correctly even after users are moved between post offices.

    GroupWise does offer many alternatives to system-wide unique userIDs. Gateway aliases, User-level IDomains, Nicknames, and Post Office Aliases may all be used, but their use typically increases workload for the system administrator.

  • Ensure that Post Office names are unique from user given names or surnames.
    Any message addressed in First.Last@IDomain or Last.First@IDomain format will first be parsed as if it were in UserID.PostOffice@IDomain format. If there are Post Offices with the same names as given or surnames, then First.Last and Last.First messages will not be delivered to users with those names.

  • Ensure that the Routing Domain that owns the default GWIA does not own any 4.x post offices.
    Any GroupWise 4.x users sharing a Domain with the GWIA will lose the ability to reply to Internet messages.

  • Do not attempt to disable Internet Addressing.
    The cost of this is simply too high. All personal address books and Frequent Contacts will become suspect and will need to be deleted. All addressing rules for Internet e-mail (any rule with a colon, an @ sign, and a period in it) will be disabled.

    If you experience difficulties with Internet Addressing, contact Novell Technical Support. We will assist you in resolving your problems without disabling Internet Addressing.

MTA to MTA Direct Connectivity

For more information, refer to the Connectivity Guide in the Online Documentation, and see TIDs 2949744 and 2941929 on the Support Connection.

  • Ensure that all MTA-Direct-enabled MTAs are able to communicate on high-numbered ports.
    When an MTA finds a GWMTP record in DNS, it will commit to using GWMTP connectivity to send to that system. If it cannot open the connection, however, messages destined for that system will remain in the MTA hold directory until the connection is opened successfully. They will not be forwarded through the GWIA.

  • If settings for the Routing Domain must be changed, make the changes in DNS first, and then wait out the DNS "time to live" before actually changing the settings for the MTA.
    This guideline pertains to the same issue described above. If another system's Routing Domain finds GWMTP records for your MTA in DNS, it will commit to GWMTP connectivity at that address. If you have already moved the MTA to another address, messages bound for your system may end up in hold directories forever.

Indexing

For more information on indexing, refer to the GroupWise 5.5 Library Indexing Process TID (#2921069).

  • Enabling QuickFinder Indexing on the POA.
    It is recommended that QF be enabled on every Post Office, even if DMS is not used on the Post Office, so that user finds don't cause high utilization on the host server.

  • Dedicated Indexers
    When using document management, it is recommended that dedicated indexers be setup for each post office with a library. Details on how to setup dedicated indexers and the various customizations can be found in TID 2921069.

Software Installation and Patching

Installation and Patching

For more information, refer to the Minimum Patch List, and TID 2952614 on the Novell Support Connection.

Software Distribution Directories

  • Create a master software distribution directory, containing a fully patched and installable GroupWise CD.
    No post offices should be assigned to use this Software Distribution Directory (SDD). This will allow the system administrator to update this directory without inadvertently triggering the Client Auto-update procedure.

  • Burn a copy of the master software distribution directory to CD for backup purposes.
    A fully patched and installable GroupWise 5.5 CD may prove to be extremely handy, whether for restoration of SDDs, or for creation of new ones at remote sites.

  • Place Software Distribution Directories on application servers rather than mail servers.
    This will simplify server licensing, backup procedures, and application delivery. Be sure to grant users sufficient access (read, file scan) to the client subdirectory, allowing them to run setup at will.

Administration Upgrades

  • Apply administration upgrades and patches to every server where GroupWise administration is run.
    This helps ensure that only the latest GroupWise Administrator Snap-ins are used. Some patches may be defeated if old administration software is used.

Server Upgrades

  • If possible, test new agent software on a lab server that is configured exactly like your production servers.
    A good test system is invaluable. Novell does test software thoroughly before shipping it, but cannot test all possible configurations. Your test system offers you an added layer of defense against defects or incompatibilities Novell has missed.

  • Pilot new agent software on one domain and post office for a week or more.
    This will allow you to continue your testing without committing to the new software on all servers. It will provide you with an accurate idea of how the new software will work on the rest of your production system.

  • Client Upgrades

    • Use ZENworks to distribute GroupWise Client updates to all LAN users.
      ZEN is a far more powerful tool for software distribution than the auto-update tools included with the GroupWise Client. When you create application objects for GroupWise you may choose include customized registry entries with the address of the ngwnameserver POA.

    • Always keep the GroupWise Client code up-to-date.
      Many performance and stability issues are patched in both the Client and POA engine libraries. Old versions of the GroupWise client may defeat the purpose of a current POA patch. Some features available in the GroupWise Enhancement Pack require that the Client and Agents be running the new code.

    • Notify end-users in advance of any GroupWise Client updates.
      This is common courtesy.

    • Avoid dependency on the GroupWise Auto-Update process.
      As mentioned above, ZENworks (and NAL) are much better tools than the GroupWise Auto-Update. If the Auto-Update must be used, edit setup.cfg to simplify the update process.

    Novell Directory Services (NDS) Configuration

    Object Placement

    • Place Domain, Post Office, Distribution List and Library objects in the same partitions as their users.
      This is not critical, but does decrease WAN traffic for NDS User Sync. It also tends to make the creation of Organizational Roles simpler. See Trustee Assignments.

    • Where possible, put users in the same container in the same post office or post offices.
      This will make administration simpler and more intuitive. It is not critical.

    • Place Resource objects in the same containers as their users.
      Again, this is not critical. Object placement should follow your scheme for administering the network. These guidelines allow for an intuitive administration scheme, but are not the only solution.

    Trustee Assignments

    • Create Organizational Roles for GroupWise administrators.
      Administration of complex trustee assignments is greatly simplified if you use Organizational Roles. Different roles should be created for different types of administrators. Data-center personnel responsible for updating telephone numbers should not have the same roles as administrators responsible for MTA Link Configuration.

    • Restrict rights to the NGW: Domain Description attribute.
      This will prevent administrators from executing System Operations (like changing the Internet Addressing settings, or editing a time zone). Assign this right only to administrators who are authorized to perform system-wide operations.

    • Allow GroupWise Administrator to automatically grant users the necessary file system and NDS rights.
      This preference is set from System Operations, and will ensure that the client can find the POA using NDS.

    • Enable NDS Synchronization for each MTA, and assign each MTA to perform NDS sync for its own domain.

    Client Administration

    Client Options

    • Lock Cleanup Options to "Manual Delete and Archive".
      This will force users to choose which items they wish to store in their GroupWise Archives, preventing unnecessary expansion of archive directories.

      Cleanup should be performed via Scheduled Maintenance, and should be done in accordance with your E-mail Policy (see below).

    • Lock the Archive path to the network USERS volume.
      Lock the path to a drive letter that is map-rooted to the user's home directory, so that the setting will correctly apply to all users. It may also be wise to place space restrictions on users to discourage abuse of the archive.

      With archives on the network the administrator has the ability to back up user archives, and can run maintenance on them without visiting user workstations. Do not store GroupWise archives on the MAIL volume.

    Training

    • Provide basic GroupWise training for end-users.
      GroupWise is an extremely powerful collaborative tool. If users only use it for e-mail they are not likely to be as productive. A little bit of education on calendaring, resource scheduling, proxying, and the use of shared and Find Results folders will go a long way towards helping users get the most out of the GroupWise Client.

    • Provide copies of Novell's GroupWise 5.5 End Users Guide, (from Novell Press and IDG Books WorldWide, ISBN #0-7645-4552-3) for your users to check out.
      This book is an excellent resource for users, but it is unlikely that any of your users will go out and buy it for themselves. As an inexpensive alternative, direct users to the online End-User's Guide, and to the manuals, cheat sheets, and quickstart cards available on the GroupWise Cool Solutions site.

    • Provide basic GroupWise Administration Training for System Operators.
      In many companies, the people responsible for day-to-day adds, deletes and modifications of GroupWise accounts are not the Network/NDS administrators. Due to GroupWise integration with NDS, it is recommended that these types of administrators receive basic NDS and GroupWise training. It is also recommended that all network administrators receive basic GroupWise training.

    E-mail Policy

    Create an e-mail policy at your organization that establishes the points below. Be sure to run it through your organization's legal arm to ensure propriety.

    • E-mail on the organization's servers is the property of the organization, and the disposition of such is at the sole discretion of management.
      With this policy in place, your e-mail administration team has the liberty to clean up mailboxes without the fear of legal reprisals from disgruntled employees. This sort of policy statement may not be applicable in university or research environments, however.

    • E-mail may not be used for spamming (inside or outside the company), virus alerts, chain letters, and junk mail (e.g. "kittens for sale").
      These types of communication are a waste of time and money - especially virus alerts, which seem to be valid, but which only serve to excite and annoy.

    • E-mail should not be used for the wide distribution of large attachments.
      Make your users familiar with the alternatives, such as sending URLs instead of AVI files they downloaded from the Web. Use the Document Management System instead of trying to track document changes through e-mail.

    • Authorized users may send to large groups for official communications.
      Establish an official channel for virus alerts. Give your users some confidence in the fact that you are going to be more likely to have the latest information on a virus than they are.

    • E-mail may be used for communication with family members and friends.
      Your policy should state that time spent using e-mail for personal purposes should be kept to a reasonable minimum during business hours.

    • E-mail will be purged from the corporate system after 180 days.
      Keeping mailboxes lean will improve system performance. As established under Client Options above, users may archive their mail, but should be aware of disk space limitations in their archive directories.

    System Maintenance

    Scheduled Maintenance

    • Check and Fix the structure of the information store nightly
      Create an event (and enable it on each POA) that checks the structure of User, Message, and Document databases each evening during the week. Schedule this operation to run before the nightly backup.

    • Check and Fix the contents of the information store weekly
      Create an event (and enable it on each POA) that checks the structure and contents of User, Message, and Document databases over the weekend. Schedule this operation to run following the Friday night backup. Review the log files Monday morning to determine the health of your message stores.

    • Document Management
      If you are using document libraries, you may wish to run archive/delete documents, delete activity logs or other maintenance routines. For information on these options refer to TID 2949669 on the Novell Support Connection.

    Backup

    • Back up the GroupWise Information Store nightly.
      The information store is everything under the post office directory. This includes the OFUSER, OFMSG, OFFILES, OFWORK and GWDMS directory structures.

      Whatever backup strategy you currently use, consider that many GroupWise database files remain open continuously, and may even be in use (written to) during your backup. Your strategy should allow for the capture of these open files. One solution is to use Open File Manager by St. Bernard Software, in conjunction with your current backup agent. For a list of supported agents, visit St. Bernard Software online.

    • Back up each domain database nightly.
      Domain databases are part of the administration system, and if damaged can be rebuilt from the primary domain database. If, however, changes made to a domain database have not been replicated to the primary yet, a simple rebuild may result in the loss of those administrative records (user objects, distribution lists, etc.) Having a recent backup to synchronize these records will make the rebuild more complete.

    • Manually back up the Primary domain database prior to and immediately following any major system changes.
      If you are merging systems, adding large numbers of users, or making other dramatic changes, use the DBCopy tool to capture the domain database before and after the changes have been made. This will make it possible for you to back out if necessary.

    Restoration

    • One or more servers should be on standby to receive restored backup tapes.
      This will allow for restoration of data without requiring the live system overwritten. This will prove to be especially useful if old e-mail is subpoenaed.

    • Backup tapes should be restored periodically.
      This will serve as a spot-check of tape viability, and will help the administration team establish time frames and procedures for disaster recovery plans.

    Document Management

    For more information, refer to the Document Management Services Guide in the Online Documentation, and see TID 2915907 on the Novell Support Connection.

    Library Placement and Configuration

    • Establish libraries on the same post offices as the users who will be using them.
      Performance will be better if users do not need to search for or retrieve documents across the network. In most organizations there are only a few users actively creating documents. The additional disk space required for a library on each post office should not cause problems.

    • Avoid using centralized libraries, except for company-wide documents, like ISO procedures.
      Centralized libraries force find operations from users on other post offices to use the Live Interactive Request system. This will increase agent and network traffic. Exceptions may be made for libraries containing organization-wide documents. If you have centralized libraries, they should exist on their own post office (no users).

    • Dedicate a server for QuickFinder Indexing on heavy-use libraries and post offices.
      The indexing process is CPU-intensive, and may impact Client/Server performance on post offices of even moderate size. A dedicated indexing station can be a workstation-class machine, but should have a fast network interface, and should be on the same LAN segment as the post office.

      In some cases it may be necessary to put two network interfaces in the post office file server, and run the indexing station on a dedicated segment. This will prevent the indexing process from competing with Client/Server requests at on the network, but is typically not required.

    End-User Guidelines

    • Use Find Results folders instead of creating large numbers of Document References.
      A hierarchical system of folders with document references in them defeats the purpose of full-text indexing. True collaboration and document management requires live updates of folder contents. Only Find Results folders offer this.

    • Enable Application Integrations.
      Accessing documents is simpler when Integrations are enabled. If at any time a document needs to be saved outside of the GroupWise system, users should select Actions|Checkout.

    Disclaimer

    Novell, Inc. makes no representations or warranties with respect to the contents or use of this document, 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 obligation to notify any person or entity of such changes.


    Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

    © 2014 Novell