Designing A Robust GroupWise System

From MicroFocusInternationalWiki
Jump to: navigation, search
GroupWise 7 Best Practices Wiki
GroupWise 7 Best Practices
Designing A Robust GroupWise System
Maintaining a Healthy GroupWise System
Keeping Your GroupWise System Secure
Deploying a New GroupWise System
Active GroupWise Partners
Moving GroupWise Users
Tools for Troubleshooting

GroupWise Architecture and Design Considerations

Domains and MTAs

Domain Considerations

There is no limitation to the number of Domains contained in a System. However, Novell Technical Services recommends as few as possible to limit the amount of admin traffic on the network. Synchronization traffic increases as the number of domains increases.

The exact number of domains in any GroupWise System needs to be determined on an individual basis by considering the following:

  • In all but the smallest of GroupWise systems, the primary domain should not own any post offices, gateways, or users.
  • The primary domain should not be used as a routing domain.
  • The primary domain should have a direct TCP/IP link to all secondary domains where possible. This ensures that administration traffic is isolated from message delivery routes. It also ensures that administration changes are replicated as quickly as possible throughout the system.
  • Even the smallest of GroupWise systems should have at least one secondary domain for disaster recovery.
  • Secondary domains should be created based on topology with a goal to minimize network traffic.
  • Post Offices should be assigned to a Secondary domain (Not Primary Domains)
  • Carefully consider the number of post offices per secondary domain, keeping these three objectives in mind:
  1. Minimize the number of rebuilds that you may need to perform from a single domain
  2. Avoid single points of failure
  3. Minimize the MTA workload
  • You should assign no more than 20 full-size post offices per domain. Assuming that a well-configured MTA can sustain throughput of 100,000 messages per day and each user sends and receives 10 messages per day, then twenty 500 mailbox post offices will generate 100,000 messages.
  • Each GroupWise Gateway should be assigned to its own Secondary domain on its own dedicated server.
  • GroupWise Gateways should run on the same server that host's it's owning domain.
  • Messaging hub domains (a centralized domain for routing messages) should be used at WAN to LAN connection points and service the remote domains that come through these points.
  • If a messaging hub domain is used, it should have a dedicated server.
  • A messaging hub domain can service 60+ links depending on LAN/WAN traffic, speed and protocol (TCP/IP) used.
  • Novell recommends clustering domains. The fault tolerance provided by clustering domains will provide maximum uptime for message routing between the domains in the Novell GroupWise 6.5 system.

Message Transfer Agent (MTA)

  • The MTA should be loaded on the same server as the domain it services.

Post Offices and POAs

Post Office Considerations

General Factors
  • With any messaging system, there are general characteristics of the overall network environment, such as backup and restore times, that come into play when sizing the information store. A primary consideration when sizing a GroupWise post office is the messaging habits of the user base (i.e., messaging utilization and client access mode). The correct sizing of GroupWise post offices also depends on several other factors, such as the overall GroupWise mailbox size, message database size, and size and number of attachments in the information store.
  • Note: The sizing recommendations in this guide are general guidelines based on many years of experience with many different environments. These are not exact recommendations for sizing GroupWise post offices in a particular environment. For the most accurate sizing possible, we recommend engaging Novell ConsultingSM or a qualified partner for an in-depth analysis of your messaging needs.
  • There are several general factors that affect the performance of a messaging system. Backup, restore, maintenance, and perceived performance of the messaging client are useful scaling factors. Addressing these factors is important to different components of a network.
Factors Description
Backup Backup engine, target service agents, and device.
Restore Restore engine, target service agents, and device.
Maintenance Database maintenance application: mode, location (client vs. server), and server utilization.
Software Distribution Directories 1.4 GB for all GroupWise components
User Performance Messaging client access mode to post office, server utilization, network traffic, and client workstation speed.

  • Once these factors are taken into consideration, you can start to generalize the sizing of the number of mailboxes in a GroupWise post office. The following table shows approximate numbers of mailboxes in a single post office; based on messaging utilization, access mode, and sizing information.
Messaging Utilisation Mailbox Access Mode
Online Caching WebAccess/Wireless, IMAP4/POP3
Heavy 700 - 1,000 2,500 - 4,000 n/a
Medium 1,000 - 1,500 4,000 - 5,000 n/a
Light 1,500 - 2,500 5,000+ 5,000+

Note MPRESTON - Numbers above brought from 6.5 BPG, Need to verify.
  • Messaging Utilization
Heavy: Heavy mail users are those who use nearly all of the features of Novell GroupWise 7 and rely on messaging for a large percentage of their day-to-day productivity. Numbers of messages sent and received are also high for heavy users. Typically, heavy users send 25 messages and receive 100 messages per day and have total mailbox sizes in excess of 300 MB.
Medium: Medium mail users rely on Novell GroupWise for communication via e-mail messages and managing their time with calendar events but do not use all of the features of GroupWise such as Proxy or Discussions. Typically, medium users send 10 messages and receive about 25 messages per day and have total mailbox sizes of up to 200 MB.
Light: Light users send and receive few e-mail messages each day, with limited use of attachments and almost no calendaring activity. These users will send an average of 25 messages per week and will have an average mailbox size of less than 50 MB.
  • Mailbox Access Modes
Since the online mode still relies on the POA to deliver 100% of the content to the GroupWise 6.5 client, the guidelines for previous versions of GroupWise apply. Experience shows that while some organizations have successfully implemented 1,000 mailbox or larger post offices, performance is consistently better for smaller numbers of mailboxes.
Post offices with heavy message flow, or where users are using Novell 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 have excellent performance for an extended period before performance mysteriously begins to degrade. This is typically a function of increased user employment of the Novell GroupWise product. Adhering to the online-mode mailbox guideline of keeping mailboxes within the range of 700 to 1,000 should ensure that your users have the room to grow into the full collaboration GroupWise offers.
Novell recommends that the number of active online-mode users per post office does not exceed the range of 700 to 1,000. With the assumption that on average only 60% to 70% of users will be logged in and using mail at any given time, GroupWise could easily support a post office of 1,000+ total users.
Here are some things to consider when deciding on an acceptable number:
Consideration Description
LAN/WAN Speed and Topology The slower the network, and the more hops a packet has to make, the slower the performance will be.
Clean-Up Policies Without standard clean-up policies implemented, there is no way to control the size of the GroupWise databases or the user's mailbox. As the databases get larger, maintenance routines and client display will take longer. In addition, as the number of messages the POA must query for Finds and/or indexing increases, the POA slows down.
Number and Size of Attachments The average user is expected to have a certain number and size of attachments. In Novell Technical ServicesSM, the post office has less than 300 users due to the size of attachments each user has; these include large databases and core dumps mailed from customers. Novell Technical Services needed to reduce the number of users on a post office to provide adequate disk space.
Backup and Restore Backup and restore can be an issue as the number users and messages increase. This issue requires that situation- specific decisions be made. Solutions will include limiting the number of users per post office, adding more disk space, implementing an e-mail policy, restricting the size of attachments, limiting the number of messages, or billing the user when limits are exceeded.
Caching / Remote
Since the Caching and Remote modes rely on the Novell GroupWise 6.5 client acting upon a local disk store, the load on the POA is greatly reduced, while the performance of the client is greatly increased.
While keeping in mind the other factors involved in correctly sizing GroupWise post offices (such as GWCheck times, Backup, Restore, etc.), typical post offices that were previously sized to 500 to 700 mailboxes can now be potentially increased by a factor of about three (3) to five (5) using Caching mode. This would equate to a potential post office size with continued client performance of 2,800 to 3,500 mailboxes.
WebAccess/Wireless, POP3/IMAP4
WebAccess / Wireless
Based on the assumption that a percentage of total users will access the system concurrently with these clients, a GroupWise post office with the majority (if not all) of the mailboxes being accessed with these clients can be larger (in terms of number of mailboxes) than one with the majority of online client access mailboxes.
A deskless client user will have messaging habits and practices similar to those of a light e-mail user as defined above (see Messaging Utilization). The features of the deskless clients, however, may appeal to all levels and types of users.
Important: Since these clients rely on the POA to supply 100% of the content to the WebAccess gateway, the performance of the POA is critical.
Since these clients are limited to e-mail information only, post offices with a majority of POP3 or IMAP4 clients can hold many more mailboxes; and since they will be smaller in size, they will operate more like the light mail users. Note that the POA has to deliver 100% of the content to the GWIA for delivery to the POP3/IMAP4 clients.
Additional factors
Multiple E-mail Accounts: POP3 and IMAP4

Multiple e-mail accounts can cause a post office store to grow quickly in size; the mailbox size limits available in GroupWise can help manage this. Additionally, the administrator can limit who has the ability to access multiple accounts from the GroupWise client.

Once messages are in the message store, the mailbox access mode (listed above) will be used to read messages.


Internet news group information can also add to the size of the message store. In turn, this will add to the GWCheck, backup, and restore times. The mailbox size limits available in GroupWise can help manage this. Additionally, the administrator can limit who has the ability to access news groups from the GroupWise client.

Once the NNTP messages are in the message store, the mailbox access mode (listed above) will be used to read messages.

Post Office Agent (POA)

The POA is the second level of message flow and it has direct access to the WPHOST.DB. The POA delivers messages to users’ mailboxes, connects users to their post offices in client/server access mode, updates post office databases, indexes messages and documents, and performs other post office-related tasks. You must run at least one POA for each post office. Among its roles are:

  • Performs indexing tasks for document management.
  • Performs scheduled maintenance on databases in the post office.
  • Monitors and manages disk space usage in the post office.
  • Restricts the size of messages that users can send outside the post office.
  • Primes users’ mailboxes for Caching mode.
  • Performs nightly user upkeep so users do not need to wait while the GroupWise client performs it; also creates a downloadable version of the system Address Book for Remote and Caching users.
  • Provides LDAP authentication and LDAP server pooling.
  • Prevents unauthorized access to the post office.
  • Tracks the GroupWise client software in use in the post office.
  • Automatically detects and repairs invalid information in user databases (userxxx.db) and message databases (msgnnn.db) for the local post office by using an efficient multi-threaded process..
  • Automatically detects and repairs invalid information in the post office database (wphost.db).
  • Automatically detects and repairs damage to the guardian database (ngwguard.db) in the post office.
  • Updates the post office database whenever GroupWise users, resources, post offices, or other GroupWise objects are added, modified, or deleted.
  • Replicates shared folders between post offices.
  • Executes GroupWise client rules.
  • Processes requests from GroupWise Remote users.
Post Office Agent Settings
All Platforms
Please refer to Section 36.1.2, Configuring the POA in ConsoleOne for more information.
POA Identification Page
Platform - Choose the appropriate platform. (Example, Linux should be chosen for POAs running on a Linux platform.)
POA Agent Settings Page
Setting Default Recommendations and Notes
Message File Processing ALL You can leave this setting at ALL unless you would like to run a separate POA for QuickFinder Indexing, SOAP, etc.
Message Handler Threads 6 Best Practice recommendation for this setting is 10.

If the POA is configured for message file processing, it starts the number of threads specified by the Message Handler Threads option. Message handler threads deliver messages to users mailboxes. The default number of message handler threads is 8; valid values range from 1 to 30.

The more message threads the POA uses, the faster it can process messages. However, the more threads the POA uses, the fewer resources are available to other processes running on the server.

Please refer to Adjusting the Number of POA Threads for Message File Processing for additional information.

Enable TCP/IP For Client Server Enabled Leave this enabled if you want the POA to accept C/S connections from users.
TCP Handler Threads (AKA C/S Threads) 6 (10 starting with GW 7 SP3) The valid values for this setting range from 1 to 99. However, we recommend that you do not set this to more than 30 following the method detailed in the paragraph below. To respond to occasional heavy loads, the POA can increase the number of TCP handler threads above the specified amount if CPU utilization is below the threshold established by the CPU Utilization setting. (The default is 85 percent.) When the POA rereads its configuration information, the number of TCP handler threads drops back within the configured limit.

For Post Offices with 200 or more users, we recommend setting the number of TCP Handler Threads to 20, then monitor thread usage with the C/S Handler Threads link on the Status page of the POA Web console. If you see that some of the threads always have a count of 0 (zero), meaning they are never used, you can decrease the number of TCP handler threads accordingly.

Setting the number of TCP Handler Threads too high will result in slower performance.

Max Physical Connections 1024  ?
Max App Connections 2048  ?
Enable Caching Enabled Database Caching should be enabled.
CPU Utilization (NetWare) 85 percent  ?
Delay Time (NetWare) 100 milliseconds  ?
Max Thread Usage for Priming and Moves 20 percent  ?
Enable IMAP  ?  ?
Max IMAP Threads 50  ?
Enable SOAP  ?  ?
Max SOAP Threads 20  ?
Disable Administration Task Processing Disabled (unchecked) For post offices with a single POA, this setting should be left at its default (unchecked). However, for specialized POAs, i.e. QuickFinder Indexing, or IMAP, enable this setting to prevent more than one POA from processing administrative tasks.
Enable SNMP Enabled  ?

Network Address Page
Setting Recommendations and Notes
TCP/IP Address  ?
Proxy Server Address  ?
Bind Exclusively to TCP/IP Address  ?
Message Transfer  ?
Local Intranet Client/Server  ?
Internet Proxy Client/Server  ?

QuickFinder Page
Maintenance Page
POA Log Settings Page
POA Scheduled Events Page
POA SSL Settings Page
Post Office Settings Page
Post Office Client Access Settings Page
Post Office Security Page

NetWare Platform

Linux Platform
Post Office Agent Server Settings
All Platforms

Benefits of SLES and OES for Running GroupWise

More stable
More scalable
Works with the latest hardware
It's where Novell is headed


Clustering on OES
Clustering on SLES10
Clustering on NetWare 6.5

Hardware requirements

User account management