GroupWise Design

From MicroFocusInternationalWiki
Jump to: navigation, search



This guide serves as a set of considerations and guidelines for Novell GroupWise administrators. 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 (TIDs), and online help for further instruction regarding each of the guidelines offered here.

This guide is based on the GroupWise 6.5 Best Practises Guide and is intended to carry out the promise of being the living document spoken of during the introduction. Being part of the Novell wiki, you can play a part in modifying this content with your experiences.

We recognize that administrators are often restricted in the changes they may make to their GroupWise Systems. Depending on the state of the existing Novell GroupWise system, some of the practices outlined in this document may be difficult or cost-ineffective to implement.

Use these guidelines wherever possible in expanding systems or creating new systems, but temper their application with your experience and knowledge of your organization's unique computing environment.

Please also refer to the GroupWise Documentation.

You may also refer to the many Novell partners for more information, tools, and services.


  • In order to keep this guide up to date, we need to assume that you're running the latest version of GroupWise - which is currently version 7.0.x. If you are running older versions of GroupWise, much of the principles will be the same, but the details may be different.

System Requirements

The base system requirements are provided in the product documentation.

Additional Requirement Considerations

Post Office Agent

The amount of memory required for the POA is influenced by many factors, including the following:

  • Number of client/server connections being supported
  • Number of active client connections vs. idle connections
  • Number of TCP handler threads
  • Number of message handler threads
  • Number of database maintenance threads

TODO: Provide a worksheet or at least an example showing how much each of these factors affect the requirements.

Message Transfer Agent

The amount of memory required for the MTA is influenced by many factors, including the following:

  • Number of post offices and domains
  • Volume of message traffic between post offices and domains
  • Volume of large messages (for example, large attachments, remote updates, and so on)
  • TCP/IP or mapped/UNC links between MTAs

TODO: Provide a worksheet or at least an example showing how much each of these factors affect the requirements.



Internet Agent


API Gateway


OS Platform Considerations

While GroupWise is currently supported on Windows, SLES and OES(linux) - it is recommended to use SLES or OES(linux) as the platform if at all possible.

If you're using NetWare for GW8 or earlier, consider using this tuning NCF for your dedicated GroupWise servers.

System Design

Domain Sizing and Configuration

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:

  1. Carefully consider the number of post offices per 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
  2. 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.
  3. The primary domain should not own any post offices, gateways, or users.
  4. The MTA should be loaded on the same server as the domain it services.
  5. 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.
  6. The primary domain should not be used as a routing domain.
  7. 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.
  8. If a messaging hub domain is used, it should have a dedicated server.
  9. A messaging hub domain can service 60+ links depending on LAN/WAN traffic, speed and protocol (TCP/IP) used.
  10. Secondary domains should be created based on topology with a goal to minimize network traffic.
  11. All high-traffic gateways should be assigned to a dedicated gateway secondary domain and placed on a dedicated server.
  12. Additional domains for Internet traffic (primarily GWIA and Web Access) can be placed at WAN/LAN hub locations to reduce the time/cost for message delivery and network bandwidth. Other high-traffic gateways (e.g. the Lotus Notes gateway and the Microsoft Exchange gateways) may also require their own domain and file server.
  13. Create a separate domain for GWIA. The GWIA is easily the highest-traffic gateway on the average GroupWise system. All mail sent to Internet addresses on other systems will pass through this domain. For larger systems, this requires that the GWIA have its own, dedicated domain. The GWIA and the MTA for this domain should be loaded on the same server where the GWIA domain directory resides.
  14. Sometimes it is cheaper to access Web Access and Remote Async gateway connections locally, rather than by using an 800 line. In this case, placing a domain in the remote location allows the gateway to run local to the users reducing the cost of long distance and 800 numbers.
  15. Other considerations would include the use of dial-up routing where link scheduling could reduce costs and external synchronization with other GroupWise systems where there is a high volume of administrative traffic. This guideline assumes that all post offices are TCP-IP 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-sized (500-mailbox online connected, 2500 caching mode connected) post offices.
  16. 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 system.
  17. As a rule of thumb, Novell does not recommend running a domain and post office on the same server.


LAN Domains

Link all LAN domains via IP in a mesh configuration. On a switched LAN, mesh-style linking 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.

Message Transfer Ports

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.

Routing Domains

Establish hub domains at WAN links. 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.

Note: Novell GroupWise agent communication (MTA to MTA and POA to MTA) has been enhanced to reduce the negative effect of slow or unreliable WAN links on messaging traffic.

Post Office Sizing and Configuration

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 Consulting or a qualified partner for an in-depth analysis of your messaging needs.

General Factors

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.
User Performace 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+

Messaging Utilization


Heavy mail users are those who use nearly all of the features of Novell GroupWise 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 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 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 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:

LAN/WAN Speed & 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 Services, 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 or 7 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. However, the larger number of mailboxes needs to be balanced with the maintenance requirements listed above.

One area that users in Caching or Remote mode may see a performance drop is that of searches against large email databases or email databases that change a lot. This is because the GroupWise client only indexes 1,000 messages each time it is started. This means for users with very large numbers of messages or for users that are able to operate for many days/weeks without closing down GroupWise by the use of suspend on their desktop or portable the indexes may never be fully up to date. If the indexes are not full up to date the search process will use what index it has and then scan the contents of the messages not held in the index.

Another consequence of the index system is that it builds the index in 'historic' order so that older messages are returned by a search first. For most users this will not be a problem, but for users with very large email accounts they will notice the return order as the search will return the most recent messages last.

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 Configuration Best Practises

Only allow Client/Server access to the POA

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 the message store. Some Windows systems allow for write-behind caching to enhance responsiveness of the Windows interface. This feature will always introduce some level of corruption into the GroupWise message store if users run in Direct Access mode.

Setup a dedicated GroupWise Server

For non-clustered GroupWise post offices, assign no more than one GroupWise post office to each file server.

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.

The principle behind this guideline is simple: a single POA can favor client/server threads over indexing or message handling threads, whereas multiple POAs cannot. Multiple POAs cannot "talk" with each other to announce that they have pending client/server requests and that other tasks should be suspended for a while. Many customers run successful systems with more than one post office on a single file server - many others do not. The success or failure of running multiple post offices on a single server depends on the degree to which users are using Novell GroupWise as a full collaboration tool.

For large non-clustered post offices (400 or more users in Online mode or over 2,000 users in Caching mode), dedicate the server to GroupWise. For smaller environments (i.e. 25 to 150 users), you can locate the GroupWise components on a server that is used for other functions.

Setup a dedicated MAIL volume

For non-clustered post offices, dedicate a server volume (e.g., MAIL) for the post office on that file server.

Separating applications and data from the SYS volume on NetWare servers is generally a good idea. If the mail volume fills up for example, SYS operations (Directory Services, most notably) will continue. Performance will still suffer, but TTS will not shut down.

Use caching mode

Whenever possible, configure every client in Caching mode.

The Caching mode provides increased client performance due to the local storage of a mirror image of the user's live mailbox: folders, address book, calendar information, and all other information. Only changes are synchronized in the background.

The initial priming of this caching will be a heavy load for the POA; it is recommended to monitor this for load and to perform it during off-peak hours if possible. The priming is handled via client/server threads. A limit can be set on the POA of the percentage of the processor utilization for priming the caching. The default limit is 20% of the available client/server threads.

Once the client is operating in Caching mode, the POA only has to provide new information to the client, run the rules, and monitor the state of the live databases and other activities. The GroupWise client has an option to "Repair Mailbox" in Caching and Remote mode, executing a local copy of GWCheck installed in the GroupWise client directory.

One situation where caching mode may not be desirable is for heavy document management users.

Tune the POA

Tune the POA and the NetWare server according to the GroupWise Sizing Recommendations document. This document is the result of extensive experience with real world post offices. The tuning parameters provided in this document improve GroupWise agent performance.

Redirect ngwnameserver

Set your DNS up to redirect ngwnameserver to at least one Post Office, ideally the one that will have the least amount of online users attached to it.

On large systems, create a dedicated POA for ngwnameserver redirection. If you have more than 2,000 users, it is likely 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 (i.e. 10,000+ users). Note that for organizations using a local DNS for each site, the DNS ngwnameserver entry should point to a local POA and not to one across a WAN link.

Document Management

For more information, refer to the Libraries and Documents Guide in the online documentation and see TID 10066600 - Planning a GW DMS System.

Library Placement and Configuration

Library Placement

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.

Documents may be stored either under the post office library directory or in a separate location known as a document storage area. Carefully plan out the location of your document storage areas. Do not store documents from different libraries in the same document storage area.

After you begin using GroupWise libraries, ensure that you are performing regular backups of your library and document storage areas. It is also important that you back up the NGWGUARD.DB. You never want to recreate the NGWGUARD.DB if you have libraries under that post office.

QuickFinder Indexing

Dedicate a server for QuickFinder Indexing 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 it should have a fast network interface and should be on the same LAN segment as the post office. Consult TID 10066601 - GroupWise QuickFinder Indexing.

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 on the network.

The majority of information in this section has been taken from TID 10066601 - GroupWise QuickFinder Indexing. Due to age of this TID it focussed on the CPU load caused by the index process and the impact that this can have on the overall performance of the server. With the improvements with processor performance over the last 5 years and the ability of GroupWise to use the mult-processor environments provided by Windows and Linux the bottleneck has moved more to the I/O caused by the QuickFinder process. Currently the index files are held within the Post Office directory structure and so all I/O has historically taken place to the same disks that hold the Post Office, which for large systems has resulted in a trade off between the index system and servicing client requests. With the ability of GroupWise to operate on a Linux platform it is now possible to map the index directory to a different disk set by the use of Linux's ability to mount additional file systems within the overall file tree.

End-User Guidelines

Use the 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.

Set default sharing rights to allow all users to view the documents you create.

Most documents are created so that others can read them. Setting these rights ahead of time saves work. If a document needs to be secured, default rights can always be revoked when the document is created (or at any time thereafter).

Fault Tolerance and Availability

For maximum fault tolerance and availability, install the post office in a Novell Cluster Services environment.

Installing Novell GroupWise in a Novell Cluster Services environment will provide the maximum failover with reliable service to GroupWise users. Proper configuration of the Novell Cluster Services system and correct configuration of GroupWise to leverage Novell Cluster Services are essential.

These enhancements are available with Novell GroupWise to increase utilization of Novell Cluster Services:

  1. New abend option in the core OS to flush GW DB. This option is available with NetWare 5.1 SP3. Use the following two switches:
    2. AUTO RESTART DOWN TIMEOUT= 180 (Default)
  2. With NetWare 5.1 SP3 and higher, GroupWise agents will auto-detect if they are running on a cluster.
  3. Better client reconnect logic; 8908 errors that occurred in previous versions should not appear in the GroupWise client connected to a GroupWise post office in a cluster, resulting in more tolerance of failover.

Internet Addressing

Novell recommends enabling Internet Addressing (IA). Enable IA on your GroupWise system after considering all points below. For more information about Internet Addressing, read the Internet-Style Addressing Guide in the Online Documentation.

Naming Conventions for GroupWise Objects

Establish naming conventions for Novell GroupWise objects such that each object 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.

Novell GroupWise does offer many alternatives to system-wide unique user IDs. Gateway aliases, user-level IDomains, nicknames, and post office aliases may all be used, but their use typically increases workload for the system administrator.

Domains, post offices, gateways, resource lists, distribution lists, libraries, and other GroupWise objects (except for user IDs) generally are made unique by adding numerals to the name, such as PO1. User IDs are generally made unique by adding a middle initial or a portion of the first or last name, such as JASMITH and JSMITH.

Note: 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.

Preferred Address Format

Novell recommends setting the preferred address format to userID@IDomain. This is the easiest way to ensure uniqueness and to match the most common Internet e-mail address format used in different organizations. The User.PO.Domain and User.PO preferred addressing format options will prove to be somewhat problematic for moved users. If you select the First.Last and Last.First options, then you will need to make sure these components are unique; if not, aliases or some other method will need to be used to assure uniqueness. GroupWise 6.5 adds the FLast (First initial, Last name) for a possible e-mail address format.

Note that mail may still be addressed in the First.Last (i.e. john.smith) or Last.First (i.e. smith.john), or Flast (i.e. jsmith) 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.

Internet Addressing and External System Synchronization

If you are synchronizing with external Novell GroupWise systems, make sure both systems have Internet addressing enabled. If your system is synchronizing domains with external systems that do not have Internet Addressing enabled, Internet Addressing will be enabled on the external system.

Note: Novell does not recommend and does not support separate systems sharing GWIAs when Internet addressing is enabled.

Disabling Internet Addressing

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 ampersand (@), and a period in it) will be disabled.

GroupWise Monitoring


GroupWise Monitor is an agent that tracks agents in your Novell GroupWise system.

Monitor can be configured to alert the administrator if agents are not responding, have large backed-up queues, and so forth.

Monitor communicates with the agents in one of two ways:

XML over HTTP (primary method) This method uses the http server built in to each of the GroupWise agents.
SNMP (secondary method) This method uses the SNMP variables published by each of the GroupWise agents.


You may set thresholds based on any of the variables exported by the agents. You define the state the agent will be in if the threshold is exceeded. To give you more granularity, you can define your own state: for example, "MTA backed up" or "POA overloaded."

You will want to set the thresholds to meet your needs.

Below is a sample of the thresholds used by Novell found in the Monitor.XML file:

<THRESHOLD var="mtaClosedPostOffices" operator=">=" value="1" state="Post office link down" /> 
<THRESHOLD var="mtaClosedGateways" operator=">=" value="1" state="Gateway link down" /> 
<THRESHOLD var="mtaClosedDomains" operator=">=" value="1" state="Domain link down" /> 
<THRESHOLD var="mtaAvailDiskSpace" operator="<=" value="100" state="Critically low on disk space" /> 
<THRESHOLD var="mtaAvailDiskSpace" operator="<=" value="400" state="Disk space below 400 MB" /> 
<THRESHOLD var="mtaOtherQCount" operator=">=" value="500" state="Messages backed up (>500)" /> 
<THRESHOLD var="mtaINetQCount" operator=">=" value="500" state="Messages backed up (>500)" /> 
<THRESHOLD var="mtaINetQCount" operator=">=" value="100" state="Messages backed up (>100)" /> 
<THRESHOLD var="mtaClosedDomains" operator=">=" value="10" state="Domain links down" /> 
<THRESHOLD var="mtaOldestQMsg" operator=">=" value="320000" state="Messages queued (>60) min." /> 
<THRESHOLD var="mtaOtherQCount" operator=">=" value="100" state="Messages backed up (>100)" /> 
<THRESHOLD var="mtaOtherQCount" operator=">=" value="500" state="Messages backed up (>500)" /> 
<THRESHOLD var="mtaINetQCount" operator=">=" value="500" state="Messages backed up (>500)" /> 
<THRESHOLD var="mtaINetQCount" operator=">=" value="1000" state="Messages backed up (>1000)" /> 
<THRESHOLD var="mtaOtherQCount" operator=">=" value="1000" state="Messages backed up (>1000)" /> 
<THRESHOLD var="mtaOldestQMsg" operator=">=" value="640000" state="Messages queued (>120) min." /> 
<THRESHOLD var="poaNormalQueues" operator=">=" value="100" state="Messages backed up (>100)" /> 
<THRESHOLD var="poaPriorityQueues" operator=">=" value="100" state="Messages backed up (>100)" />
<THRESHOLD var="poaAvailDiskSpace" operator="<=" value="400" state="Disk space below 400 MB" /> 
<THRESHOLD var="poaAvailDiskSpace" operator="<=" value="100" state="Critically low on disk space" /> 
<THRESHOLD var="poaNormalQueues" operator=">=" value="1000" state="Messages backed up (>1000)" /> 
<THRESHOLD var="poaNormalQueues" operator=">=" value="500" state="Messages backed up (>500)" /> 
<THRESHOLD var="poaPriorityQueues" operator=">=" value="500" state="Messages backed up (>500)" /> 
<THRESHOLD var="poaPriorityQueues" operator=">=" value="1000" state="Messages backed up (>1000)" /> 
<THRESHOLD var="poaDBStatusNumber" operator="=" value="1" state="MTA Router not processing" /> 
<THRESHOLD var="poaDBStatusNumber" operator=">=" value="1" state="Admin database is corrupt" /> 
<THRESHOLD var="gwiaQueueWpcsin" operator=">=" value="500" state="Messages backed up (>500)" /> 
<THRESHOLD var="gwiaQueueWpcsout" operator=">=" value="500" state="Messages backed up (>500)" /> 
<THRESHOLD var="gwiaQueueWpcsout" operator=">=" value="100" state="Messages backed up (>100)" /> 
<THRESHOLD var="gwiaQueueWpcsin" operator=">=" value="100" state="Messages backed up (>100)" /> 
<THRESHOLD var="gwiasmtpQueueReceive" operator=">=" value="100" state="Messages backed up (>100)" /> 
<THRESHOLD var="gwiasmtpQueueSend" operator=">=" value="100" state="Messages backed up (>100)" /> 
<THRESHOLD var="gwiasmtpQueueSend" operator=">=" value="500" state="Messages backed up (>500)" /> 
<THRESHOLD var="gwiasmtpQueueReceive" operator=">=" value="500" state="Messages backed up (>500)" /> 
<THRESHOLD var="gwiaQueueGwprob" operator=">=" value="10" state="Problem queue backed up" /> 
<THRESHOLD var="gwiasmtpdThreadsAvailSend" operator="<" value="1" state="No threads available" /> 
<THRESHOLD var="gwiasmtpdThreadsAvailReceive" operator="<" value="1" state="No threads available" /> 
<THRESHOLD var="gwiaQueueWpcsout" operator=">=" value="1000" state="Messages backed up (>1000)" /> 
<THRESHOLD var="gwiaQueueWpcsin" operator=">=" value="1000" state="Messages backed up (>1000)" /> 
<THRESHOLD var="gwiasmtpQueueSend" operator=">=" value="1000" state="Messages backed up (>1000)" /> 
<THRESHOLD var="gwiasmtpQueueDefer" operator=">=" value="1000" state="Defer Queue Backed up >1000" /> 
<THRESHOLD var="gwiasmtpQueueDefer" operator=">=" value="1500" state="Defer Queue > 1500" /> 
<THRESHOLD var="gwiasmtpQueueReceive" operator=">=" value="100" state="Messages backed up (>100)" /> 
<THRESHOLD var="gwiasmtpQueueReceive" operator=">=" value="1000" state="Messages backed up (>1000)" /> 
<THRESHOLD var="gwiaNumMessages" operator=">=" value="1000" state="Messages backed up (>1000)" /> 
<THRESHOLD var="gwiaNumMessages" operator=">=" value="500" state="Messages backed up (>500)" /> 
<THRESHOLD var="gwiaNumMessages" operator=">=" value="100" state="Messages backed up (>100)" /> 

When you start Monitor, you will be prompted for the http user ID and password for each agent. You can avoid entering the user ID and password for each agent by loading Monitor with the /httpuser and /httppassword switches. As each agent loads, GroupWise Monitor will use this default ID and password.

For more information, please refer to the monitor guide in the online documentation.

eDirectory Configuration

Object Placement

Use these steps for object placement:

  1. Place domain, distribution list, resource, and library objects in the same partitions as their administrators. This is not critical, but does decrease the WAN traffic generated for an NDS User Sync. It also tends to make the creation of Organizational Roles simpler.
  2. Place the post office in the same partitions and container as their users. Since all eDirectory users with a GroupWise mailbox authenticate to their post office, placing the post office object in the same container / partition will lower WAN traffic and GroupWise startup times. It also make administration simpler and more intuitive.
  3. 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

Use the following steps for trustee assignments:

  1. 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.
  2. 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.
  3. Enable NDS User Synchronization for each MTA and assign each MTA to perform NDS sync for its own domain. Do this instead of using a single MTA to scan for NDS changes for multiple domains, which could increase traffic on the network and within eDirectory. For larger organizations with dedicated DS servers, additional MTAs can be created and loaded to provide NDS user sync in a more efficient manner. The MTA on these servers will be associated with all domains in the system for NDS user sync, and the NDS partitions on these servers can be scanned for changes.
  4. 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.


  1. Review with a view on Identity Management and how it changes NDS user sync
  2. Provide detail on typical roles and file & DS trustee assignment requirements for each role

NDS Groups and Roles in the Address Book

Use NDS groups and role objects as addressable commodities in the GroupWise address book. This will lower redundancy for the administrators.

WebAccess and Wireless


Plan the number and location of WebAccess gateways. The number and location of WebAccess gateways is determined in part by the number of post offices and users to be serviced by each gateway. Bandwidth of WAN links and geographic location of users should also be considered. WebAccess gateways should be placed close to the users that use them. In a large distributed system, there may be multiple WebAccess gateways.

A single GroupWise 2014 WebAccess application on SLES 11+ can nicely handle 1000 concurrent connections. Note: There are no longer any WebAccess gateways in GroupWise 2012 and later.


Dedicate a web server for the WebAccess gateway. This will provide the maximum performance and ability for growth.

A WebAccess gateway should always run on the same server that holds the domain database in which it exists.

Load Balancing

Load balancing of the WebAccess gateways can be accomplished by specifying gateways at a domain or post office level. This will spread the workload logically over the various gateways in the system. It will also guarantee that the user will go through the gateway that is closest to his or her post office. This configuration is also fault tolerant: if one gateway is down or not responding, it will try to access the post office through another gateway.

Load balancing the Web servers/WebAccess servlets can be accomplished logically based on geographic location or an organizational structure by providing links to various Web servers based on this pre-determined criteria. It can also be done with a DNS round-robin configuration; however, this configuration requires a Layer 4 switch.



Novell does not recommend accelerating the WebAccess gateway using a cache program such as BorderManager or a hardware appliance.

Due to the different ages of TIDs held within Novell's library the above statement is misleading, currently Novell has published TIDs detailing the use of iChain as an accelerator to WebAccess as it provides additional security benefits such as single sign on support which is not offered by the WebAccess application directly.

   [Howto accelerate and single sign on (SSO) to Groupwise 6.5 WebAccess server]
   [Creating an iChain Accelerator for Groupwise WebAccess]

Fault Tolerance

Novell recommends running WebAccess in a clustered environment for fault tolerance. Novell also recommends multiple gateways so that if the default gateway is down, you can still access the post office through another gateway.

Default WebAccess Gateway

Novell recommends setting default WebAccess gateways for domains and/or post offices if multiple gateways exist in a system.

Note: Post office links should always be set to client/server only.


Use these steps for maintenance:

  1. Make sure the most recent code is running on the WebAccess servers. This includes service packs for the operating system (NetWare, NT, etc.), the web server software (NetWare Enterprise Web Server, Apache, IIS, etc.), the servlet engine (Tomcat, Novell Servlet Gateway, etc.), and the GroupWise WebAccess gateway software itself.
  2. Ensure that purge immediate is set on the following directories used for temporary files:
    1. Web Server
    2. SYS:\NOVELL\WEBACCESS ? WebAccess Agent Server
    4. Root of SYS Volume


Formal Training

Novell training partners can provide end-user training and system administrator training. The list of available course is here.

Internal Training

  1. Provide basic Novell 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 help users get the most out of the GroupWise Client.
  2. Provide access to the GroupWise 6 End-User's Guide.
  3. Provide basic GroupWise Administration Training for System Operators. In many companies, the people responsible for day-to-day adds, deletes, and modifications of Novell 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.


Built-in security features

  • TODO: BCEF and what it applies to
  • TODO: Why use SSL?
  • TODO: Certificates
  • TODO: Why GroupWise is less prone to viruses
  • TODO: Authentication

Viruses & Malware

Novell GroupWise is not as susceptible to viruses as other vendors' products; however, as a messaging product, GroupWise can transport viruses. Novell recommends that customers implement virus protection solutions at every entry point of their network. Viruses sent in from Internet messages pose the greatest threat. Many different vendors have made products specifically written to integrate with Novell GroupWise to protect your GroupWise system from virus-laden messages from the Internet. Please refer to the GroupWise Partner Page for additional information.


Partner Products

GroupWise has many partner products that facilitate corporate compliance requirements. Please refer to the GroupWise Partner Page for additional information.

Corporate 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. The following guidelines will help to create a solid e-mail policy.

Policy Notes
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 can clean up mailboxes without fear of legal reprisals from disgruntled employees. This sort of policy statement, however, may not be applicable in university or research environments.
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 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 - send 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.
Only authorized users may send to large groups for official communications. Establish an official channel for virus alerts. Give your users 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. Many view e-mail as a perk they are entitled to use in certain ways. Your policy should, however, 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.

References used to build this document