Basic GroupWise Concepts for Support Professionals

Articles and Tips: article

MIKE LEE
GroupWare SWAT Engineer
Technical Services Division

01 Jan 1996

This AppNote provides an introduction to GroupWise for both novice and experienced support professionals. It explores the relationships between the major components of GroupWise systems (domains, post offices, gateways, mailboxes, and so on). It also includes detailed explanations and diagrams showing how messages are routed and delivered through a GroupWise system.

This information is excerpted from The GroupWare Support Professional's Guide, a collection of technical documents created by the GroupWare Support SWAT Team. The Professional's Guide is available from the GroupWare Support Remote Document Server (send Internet mail to public@novell.com for RDS instructions) and on the World Wide Web at http://www.novell.com.

Introduction
Overview of E-mail Fundamentals
GroupWise Post Office Concepts
GroupWise Message Server Concepts
Message Delivery Within a Single Post Office
Message Delivery Between Post Offices

Introduction

The core competency you need as a GroupWise integrator and troubleshooter is the ability to trace and predict the flow of message traffic through your system. For message flow to make sense, you must understand the architecture and directory structures used by GroupWise. If you know how messages are generated and where they are supposed to go to next, you will be able to quickly localize and identify communication breakdowns and trouble spots.

This AppNote discusses three introductory topics that are essential to understanding and troubleshooting GroupWise systems:

How GroupWise is logically organized into administrative domains, post offices and gateways.
How GroupWise domains, post offices and gateways are physically structured.
How message traffic moves between domains, post offices and gateways.

After reading this AppNote, you will have an understanding of GroupWise architecture that is more sophisticated than that possessed by most working administrators. The intent of this AppNote is not to discuss the details of day-to-day administration and configuration, but rather to help you understand how GroupWise works from a "big picture" perspective.

Note: More detailed information about designing andadministering GroupWise systems is contained in TheGroupWare Support Professional's Guide from which thisAppNote is excerpted (see the title page of this AppNote foravailability information).

General computer literacy and familiarity with basic networking concepts is assumed in this AppNote. Previous experience with GroupWise is not required. Reading this AppNote before installing GroupWise for the first time will help you make better decisions about how to configure your system.

Overview of E-mail Fundamentals

Conceptually, there are five essential components of every E-mail system:

Message Stores
Message Transport Agents
User Agents
Administrative Agents
Directory Services

The table in Figure 1 tells how each of these components is implemented in GroupWise and what function each performs.

Figure 1: Like every E-mail system, GroupWise is comprised of five fundamental components.

This conceptual component:	Is implemented in GroupWise as the:	And performs this function:
Message Store	Post Office	Messages sent between users are saved and organized for reading. Most often, messages are stored on a file server's hard disk which is accessible simultaneously by many users. Large E-mail systems almost always have multiple message stores, especially when users are communicating across long distances.
Message Transport Agent (MTA)	Server Programs (Message Server, Post Office Server, Administration Server, and various Gateway Servers)	Message Transport Agent programs are the mail carriers for the system, and are responsible for routing and delivering mail between and to message stores.
User Agent	GroupWise Clients forDOS, Windows, UNIX, and Macintosh	The user agent is a program run by users to read messages from the message store. Some message stores are readable by more than a single client application. For example, there are dozens of SMTP (Internet) mail readers that can all read standard SMTP message stores.
Administrative Agent	Admin program	Typical administrative tasks include granting and restricting user access to the system and definingMTA routing paths between message stores.
Directory Services	Domain and Post Officedatabases (WPDOMAIN.DB and WPHOST.DB files)	Directory Services are usually implemented as a database containing messaging system configuration and addressing information. The primary job of most Administrative Agents is to manipulate and update the contents of theDirectory. User Agents also rely on Directory Services for many functions. The Directory may validate client requests for access to the messaging system, and provides other services such as "point and click" addressing to other users (Directory Services are presented in the GroupWise client as the addressbook feature).

Message Store Formats

E-mail system message stores may be divided into two categories:

File-based systems
Database systems

In a file-based system, each message is stored as a separate file. In a database system, many messages are held together in database files. GroupWise is a hybrid system: small and medium-sized messages are stored in efficient databases, but very large messages and large files attached to messages are stored in separate files to prevent message databases from becoming enormous. Office 3.1, the previous major version of GroupWise, was a completely file-based system.

Front-End Services vs. Back-End Services

End users interact with the mail system completely through the client software. Client software is the "front end" of a messaging system. When they choose Send, they know that "somehow" their message gets transmitted to the intended recipient. The "somehow" that delivers messages is the "back end" (see Figure 2).

Figure 2: The front end of the messaging system is the client application, while the back end delivers the messages.

The back end may consist of dozens or even hundreds of different Administrative Agents and Message Transport Agent (MTA) programs running on computers scattered all over the world.

Messages hop from one MTA to another until they reach their final destination. If the delivery chain from MTA to MTA is ever broken, the system has two choices: (1) to throw away messages that are temporarily undeliverable, or (2) to use a store and forward scheme.

Store and Forward

Store and forward messaging systems take into account the possibility that a link in the MTA delivery chain may get broken. In this case, messages in transit are stored until the link once again becomes available.

Suppose a store and forward MTA program receives a message, but is temporarily unable to transmit the message to the next hop. Perhaps phone lines are down, or a file server has crashed. Or the administrator may have even designed the system so that certain links are up only at certain times of the day to save on connect charges.

In these cases, the MTA stores messages on a local disk until the link comes back up. The MTA will usually check periodically to see if the link has been restored yet, and as soon as it is, the message goes on its way as if there had never been a problem. GroupWise is a store and forward system.

Gateways

Users of dissimilar E-mail systems often need to communicate with each other, and gateways allow them to do this. A gateway is an MTA that not only routes and delivers messages, but has the added capability of translating a message between two different message store formats.

If a GroupWise user needs to send a message to someone on the Internet, for example, the message must be translated from GroupWise's proprietary message store format into the plain text format used by Internet (SMTP) mail. When an Internet user wants to send a reply back to the GroupWise user, the message must be translated back into GroupWise format before it can be read by the GroupWise client.

At this writing, Novell has 11 gateways that allow GroupWise users to communicate transparently with other messaging systems, including:

Banyan Intelligent Messaging (IM)
cc:Mail
DEC Message Router
Lotus Notes
Message Handling Service (MHS)
OfficeVision/VM
SMTP (Internet)
SNADS
VMS Mail
X.25
X.400

Gateways are also available for connecting GroupWise with fax servers, pagers, and the Telephone Access Server (TAS). An Async Gateway uses asynchronous (modem) communication to connect GroupWise Remote clients, and an API Gateway provides an interface to the GroupWise system for third-party and corporate developers to interact with GroupWise.

Administrative Domains

Messaging systems that have multiple message stores that are all administered together are often called "administrative domains." GroupWise domains can be hierarchically organized: one domain (called the primary domain) can administer several post offices and even other domains (called secondary domains).

Each GroupWise domain may contain many message stores (post offices). Each secondary domain has its own administrator who administers that domain only. The primary domain administrator is a kind of "super administrator" who can administer the primary domain and any secondary domain as desired. Thus, very large systems can be centrally administered when convenient, and locally administered when convenient, without having to alter the architecture of the system.

Summary of E-Mail Concepts

Figure 3 is a conceptual diagram of an E-mail system showing the MTA system in the middle, connecting users and message stores together. The MTA system may consist of several message server programs and gateways.

Figure 3: Conceptual diagram of an E-mail system showing the interaction between the MTA system, message stores, and clients.

The client software sends messages into the MTA system, which routes and delivers messages to their final destinations. Administrative utilities are used to manage the whole system, and define the specific routes and features of the MTA system. The information that configures and defines the system is kept in databases or other files that form the Directory Services component of the messaging system.

GroupWise Post Office Concepts

This section introduces the basic concepts and features of a GroupWise post office. The post office has four fundamental features:

The Post Office Address Book
Message Store Directories and Files
Client Directories and Files
Message Queue Directories

A GroupWise post office exists as a directory structure, usually on a network file server. Figure 4 shows the subdirectory structure of a typical post office,located in the O:\POST directory.

Figure 4: Directory structure of a typical GroupWise post office.

Many of the directories shown here have subdirectories that are used to organize and manage the work they do. These subdirectories will be discussed later, but are omitted now to simplify the diagram.

The Post Office Address Book

The WPHOST.DB file is a database that contains a list of all the users in the system, both on this post office and on others. The Address Book can even contain addresses of non-GroupWise users that exist in foreign domains. The Address Book provides Directory Services to all the users on the post office.

When users access the Address Book feature in the client, the screen they see is generated by reading the WPHOST.DB file. The Address Book not only makes it easy for users to "point and click" to send to other users, but also performs other important user validation and configuration functions. WPHOST.DB is the heart of each post office. If this file is missing or severely damaged, users cannot access messages in the post office until it is repaired or restored.

Note: Even if WPHOST.DB is lost in its entirety, you need notpanic. It can be restored in its entirety with the Rebuildfunction in the GroupWise Administration program.

Post Office Message Store Directories and Files

The post office's message store is implemented in three directories, OFUSER, OFMSG and OFFILES. The table in Figure 5 explains the purpose of each of these message store directories.

Figure 5: Purpose of the GroupWise message store directories.

Directory	Purpose
OFUSER	Holds user databases (also called user mailboxes.) Each user has a database in this directory named USERxxx.DB. The xxx corresponds to three unique letters assigned to identify files in the post office that belong to a specific user. These letters are assignedby the Admin program when the user is first created. The user's mailbox doesn't actually contain messages--it only has the titles of messages. Messages themselves are stored in the OFMSGdirectory.
OFMSG	There are usually 25 message databases in this directory, numbered MSG0.DB through MSG24.DB.
Note: There may be additional databases along with the standard 25 if your GroupWise system connects to an Office 3.1 system.

Because GroupWise post offices can support so many users (almost 50,000 per post office), the message load is balanced out across many database files rather than storing all messages in one huge database. It is still not uncommon for a single message database on a large post office to reach 200 MB or more in size.

All messages and attachments stored in the post office are encrypted at all times (except when they are being displayed in the client). For added security, even messages in transit are encrypted.

How GroupWise Messages Are Stored and Retrieved

Figure 6 shows in more detail what happens when a user reads a message. The table in Figure 7 refers back to Figure 6 to further explain the process that occurs when a user reads a message from the client.

Figure 6: The process that occurs when a user reads a message.

Figure 7: What happens when a user reads a message.

Logical Action	Physical Action
1	User selects a message titlein the client.	When the user chooses a message for reading, the client application looks in the user's USERxxx.DB for a pointer associated with the message that tells it wherethe message is actually stored.
2	Client program finds themessage text in a message database.	The client software uses the pointer information to access the right message database (MSGnn.DB) in the OFMSGdirectory.
3	Client program also looksup file attachments, if any, from information in the message database record.	If the message was large or had large files attached to it, a pointer in the message record is used by the clientto locate the actual message or attachment file(s) in the OFFILES directory.
4	Client program displays themessage and any attachments.	The client loads the message into memory and displays it along with the names of any attachments. When the user chooses to read an attachment, the attachment is loadedfor viewing or opened in an associated application.

You may be asking yourself why GroupWise uses so many different databases for each user's messages, rather than simply storing them in a single database. Some of the more important reasons are:

It saves significant amounts of disk storage space. Suppose I send a single message to 100 other users who share my post office. If the message were stored in each user's mailbox, then my message would have to be duplicated 100 times in 100 mailboxes. Instead, GroupWise puts a single copy of the message in a message database, and every user's mailbox has a pointer to the one copy of the message.
It prevents user mailboxes from becoming very large, thus slowing client performance. The entire mailbox must be scanned by the client on startup in order to display the headings of all the items in the mailbox. Message databases do tend to become very large (200 megabytes or more is common), but this does not significantly affect client performance since clients access very few items from the message database at any given time.
Even if a user's mailbox is deleted or otherwise damaged, themessages are still safe. Most of the contents of a user's mailbox can be re-created through the OFCHECK utility, just as postoffice databases can be rebuilt through Admin.
Offloading large messages and attachments from the message databases to the OFFILES directories helps to keep the message databases efficient. Users often send very large attachments through GroupWise, and the OFFILES directories ensure that GroupWise won't have to create monstrous message database entries to store such files.

Client Directories and Files

The number of client directories you will have in your post office depends on which client platforms you decide to use. DOS, Windows and Macintosh client applications are stored in OFDOS40, OFWIN40, and OFMAC40 respectively.

Workstation setup programs for various clients are found at the root of the post office (in the same directory as the WPHOST.DB file). For example, SETUPWIN.EXE is used to set up the Windows client on workstations, and can even be used to install a full copy of the client software on a workstation.

The OFVIEWS and OFNOTIFY directories are shared by all the clients.

The OFVIEWS directory contains Views for each client. Views define the appearance of screens and messages within the client. Views can be customized with the View Designer for each graphical client. The View Designer is like a paint program, and allows you to position text, insert bitmaps, and otherwise customize the way your messages appear when sent to others.
The OFNOTIFY directory contains notification files which are used to pop up appointment alarms and new message notifications as desired by the user. The name of each user's Notify database is NOTxxx.FIL, where xxx stands for theuser's FID (File ID) assigned by Admin when the user was created.

Post Office Queue Directories

GroupWise stores messages in transit between MTA programs in queue directories. Recall that GroupWise was described as a "store and forward" system. Messages hop from one queue directory to another in the system until they are finally delivered. MTA programs read messages they find in queue directories, and either deliver them to message stores or move them to another queue for another MTA to process. To track traffic flow through the system is to track the progress of a message file from queue directory to queue directory.

You will always see WPCSIN and WPCSOUT directories paired together in each post office, gateway and domain directory. These are the most important queue directories in a GroupWise system. (The role of these two directories is discussed in detail later under the heading "How MTA Processes Use Queue Directories.")

The OFWORK directory is a special purpose queue directory found only in post offices (not in gateway or administrative domain structures). It is used to process direct connect Remote Client requests and for delayed message delivery. See the Client and Administration manuals for more detail about the GroupWise Remote Client and GroupWise's ability to automatically delay delivery of messages.

Understanding the details of how message queue directories are used requires that you understand the role of each GroupWise MTA program. This subject will be taken up in "GroupWise Message Server Concepts" below.

Summary of Post Office Concepts

Each GroupWise post office has an address book which consists of the file WPHOST.DB and which provides Directory Services to the post office. Post offices also contain client software in platform-specific application directories that allow users to read their own messages from the message store directories. Message queue directories hold messages waiting for an MTA to route them to other post offices or deliver them to their recipients.

Note: Theoretically, a single GroupWise post office can servicenearly 50,000 users. Limitations on the number of users perpost office will usually depend on how many concurrentlogins your file server can support, how much disk space isavailable, and what platforms you choose for your MessageServer system. Post offices with a thousand users are notuncommon.

DOS-based server programs are relatively slow, comparedto OS/2-, UNIX- or NLM-based message servers. If you useDOS message servers, your post office should grow nolarger than about 250 users. If you use high performancemessage servers, it may be practical to have thousands ofusers on a single post office.

GroupWise Message Server Concepts

Every messaging system must have an MTA (Message Transport Agent) to handle routing and delivery of messages. The MTA is a program, or a set of programs, that watch the system for new messages to be generated. When a new message appears, the MTA goes into action to route and deliver it.

In GroupWise, there are five MTA processes. The actual executable filenames of each process will differ by platform. For example, the Post Office Server for DOS is called OFS.EXE; for OS/2 it is OFSOS2.EXE, and for NetWare, NGWOFS.NLM.

The table in Figure 8 lists each GroupWise MTA program type. The abbreviation in parentheses below the name is how most GroupWise administrators commonly refer to each MTA process.

The OFS, ADS and gateway servers can be considered delivery servers, while MS is the routing server. MS never begins or finishes a message transaction--it just keeps the message hopping from queue directory to queue directory until it is time to hand off the message to one of the other processes for final delivery.

These are the general roles of each component in message generation and delivery:

The client or Admin programs create messages.
MS routes messages.
OFS, ADS or a gateway server delivers messages.

Note that some messages are created by server processes. For example, OFS may generate a status message or a gateway may generate statistical reports and mail them to an administrator's mailbox.

Figure 8: Role of the various types of GroupWise Message Transport Agents.

Program	Role
Message Server(MS)	Routes messages between post offices. MS never handles final delivery of a message--it just passes it from queue directory to queue directory. Eventually one of the other servers will takeresponsibility for final delivery of the message. You need only one Message Server process per administrative domain. This single Message Server routes traffic between all post offices and gateways in the domain, and sends outboundtraffic to other GroupWise domains.
Post Office Server(OFS)	Delivers messages within a single post office by writing the messages into message databases (MSGnn.DB files) and usermailboxes (USERxxx.DB files). There is one Post Office Server per post office. OFS delivers messages directly to user mailboxes and message databases. (Contrast OFS to MS: MS never writes to any databases; OFS never routes messages from one WPCSIN directory to another. OFS can put messages only in its own post office's WPCSINdirectory for MS to pick up and route.)
Administrative Server(ADS)	Processes directory synchronization messages throughout an administrative domain.
Connection Server Server (CSS)	Processes administrative messages sent to MS, such as tellingMS to restart itself or to send a statistical report. CSS is not a separate program, but is built into the MS program. Think of CSS as the Admin program's "remotecontrol" for the Message Server.
Gateway Servers(various names)	Translates and forwards GroupWise messages to users of other messaging systems, and translates incoming messages back to GroupWise format. Gateway servers hand off incomingmessages to MS for delivery to GroupWise post offices.

How MTA Processes Use Queue Directories

GroupWise's store and forward architecture is implemented through the queue directories. Messages in transit through the system are copied from one queue directory to another until they reach their final delivery destinations. In essence, the queue directories act as IN and OUT boxes for each MTA process.

The OUT box directory for one MTA program is always the IN box for another. For example, WPCSIN directories are the MS program's IN box. MS scans the WPCSIN directories in every post office and gateway looking for files other server programs have copied there for routing. Thus, WPCSIN is the OUT box for these other servers.

GroupWise servers and clients share access to the same queue directories simultaneously. A client application or OFS might drop a message in a WPCSIN directory for routing. A second later, MS will notice the new file, pick it up, read the addressing information in it, and then move it to the next queue directory along its route.

When MS finds a message file in WPCSIN, it will put the file in one of two places:

In a WPCSOUT directory, where one of the delivery servers (OFS, ADS or a gateway) processes the message.
In a different WPCSIN directory, where another MessageServer continues routing of the message.

Eventually, every message must find its way to a WPCSOUT directory before it can be delivered (see Figure 9).

Figure 9: GroupWise servers and clients share access to the same queue directories.

Message Queue Directory Details

Up to this point, we have not talked about the subdirectories found beneath WPCSIN and WPCSOUT.

Figure 10 shows the subdirectories beneath WPCSIN. The eight directories numbered 0 through 7 are called priority directories because they are used to prioritize and sort messages according to delivery urgency. Some message server programs (such as those on the NLM platform) allow you to override the default priority scheme with command line options, if desired.

Figure 10: Subdirectories beneath the WPCSIN queue directory.

Status messages are messages generated automatically by the system that report back to senders what is going on with their messages. How much status information you get back is configurable in the client. You can request status on when a message has been delivered, opened, or even deleted.

Recall that the only MTA program that processes messages from WPCSIN is MS. All the other server processes (OFS, ADS and gateways) process messages from WPCSOUT. Because several processes can share a single WPCSOUT, there has to be a way of keeping track of which messages belong to which process. Messages are sorted in additional subdirectories dedicated for each process.

Figure 11 shows the subdirectories found below WPCSOUT in a typical post office. The OFS directory and its priority subdirectories are used exclusively by the Post Office Server, while the ADS directory is used exclusively by the Administration Server.

Damaged messages for all servers are placed in PROBLEM, and the message is renamed with an extension identifying the server from which it came. For example, an OFS message originally called 04ABCDEF.AAAthat came from the WPCSOUT\OFS\4 directory might be renamed 04ABCDEF.OFS if it were placed in the PROBLEMdirectory.

Messages found in PROBLEM can be "re-queued" or copied back to their appropriate server queue directory for another attempt at processing. Sometimes an anomaly in the system that prevented delivery the first time will have been taken care of by the time delivery is again attempted. And if a second attempt at delivery is unsuccessful, the server's log screen may be able to tell you the specific reason for the failure.

Figure 11: Subdirectories beneath the WPCSOUT queue directory.

Note: In normal operation, it is likely you will see a few messagessent to PROBLEM every so often. The presence of amessage in PROBLEM does not necessarily mean anythinghas gone wrong with the system. However, if largenumbers of messages are being deposited in PROBLEM, orusers complain about delivery problems, then you havecause for concern.

WPCSOUT directories found in gateway or domain directories may have different subdirectories than those found in post offices. For example, a WPCSOUT\CSS directory will be found in each domain directory for the Connection Server Server. Some gateways may have many different connection ID directories in their WPCSOUT structures to help the gateway keep things straight if it communicates with several different foreign users or systems.

Using GroupWise Without Running a Message Server

If your GroupWise system has only a single post office and you do not use any gateways, it is not necessary to use MTA programs because limited MTA functionality is built right in to the GroupWise Client and Admin applications.

Some of the exact code that is in the Post Office Server program is contained in each client application. The Admin program also has some Administrative Server capability in it. This means the client can deliver messages to other users on the same post office, and the Admin program can update post office address books by itself, for post offices in its own domain. The client can't deliver messages to other post offices, and Admin can't make administrative updates to other domains.

If you configure your GroupWise system in Server Never mode, the client takes over all delivery functions. This means that you can deliver only in a single post office, since the client can't get messages between post offices. If you configure a Server Never system, the post office queue directories are bypassed, and clients write messages directly to each others' mailboxes and message databases.

Server Never mode should be used only for very small post offices. If you have more than 50 users on a post office, a standalone Post Office Server will greatly enhance the delivery speed and responsiveness of the system.

Suppose a user sends a message to all 50 other users on a post office. When a Post Office Server is running, the client puts a single message in the WPCSOUT queue directory instructing OFS to deliver the message to all 50 people by updating each user's mailbox. In Server Never, the client must itself open and update each and every recipient's mailbox. It will probably tie up the client for a minute or so to do this. The problem multiplies if the post office has hundreds of users.

Summary of GroupWise MTA Programs

GroupWise uses four types of programs to route and deliver messages in the system:

The Message Server (MS) routes messages from place to place, but does not actually deliver them.
The Post Office Server (OFS) is responsible for final delivery of messages. Client applications contain OFS functionality, and may sometimes substitute for running a separate OFS delivery program.
Gateway Servers allow GroupWise users to communicate with users of other messaging systems.
The Administration Server (ADS) keeps administrative databases and address books in synch throughout the system. The Admin program has Administration Server capabilities in it, and may sometimes substitute for running a separate ADS program.

The symbols seen in Figure 12 are often used in GroupWise message flow diagrams to represent each kind of server.

Figure 12: Summary of the four types of MTA programs in GroupWise.

Message Delivery Within a Single Post Office

This section will show you how messages are delivered between users who share the same post office in each of the three delivery modes supported by GroupWise.

Before getting into the details of the different ways message delivery can happen, you need to know something about GroupWise delivery modes and application thresholds.

Delivery Modes and Application Thresholds

There are three delivery modes in GroupWise:

Server Never
Server Always
Use Application Thresholds

The purpose of changing delivery modes is to optimize message delivery workload between client applications and server applications. Recall that the client has built-in Post Office Server functionality which allows the client to deliver messages to other users on the same post office. The delivery mode setting tells the client how much help in delivering messages it can expect from the Post Office Server.

The delivery mode setting is stored in the post office address book, and is read by the client software each time it is started.

When you are in Server Never mode, you are telling the client that there is no Post Office Server available, and all delivery work is therefore the client's responsibility.

When you are in Server Always mode, you are telling the client that none of the delivery work is its responsibility. The client is to let the Post Office Server do all the work, and is never even to write to its own mailbox, much less anyone else's. You should note that Server Always is intended only for very high security installations, and is not otherwise recommended because it causes a noticeable performance decrease. In essence, the Server Always flag completely disables the MTA functionality built in to the client.

Use Application Thresholds is the recommended mode to best handle delivery and optimally balance workloads between client applications and server applications. When the threshold is exceeded, the client hands off work to the MTAs. The simple things the client does by itself.

The application threshold is a number that can be set for each domain, post office or even on a user-by-user basis. Suppose the threshold is set to 5. If I send a message to four other users on my post office, my client software will handle all the delivery chores. If I send a message to five users, thus exceeding the threshold, my client will then call on the Post Office Server to assist with delivery.

The default threshold level is 0. This hands off almost all work to the post office server, including updates of personal tasks and appointments, as well as delivery of all messages to other users. This default is a good choice if you are using high performance message servers (such as UNIX, NLM or OS/2). Even on large post offices, these servers seldom get backlogged in their work.

But if you are using a DOS Post Office Server, the server may need more help from the clients to keep up. Setting the threshold to 2 or higher may result in better overall performance. With this setting, the client would not bother OFS to deliver messages addressed to only a single recipient, and would hand off delivery to OFS only for messages addressed to multiple recipients. Delivering a message to a single recipient is as quick for the client as handing it to OFS, but delivering to multiple recipients is a big chore for the client to perform.

Note: The application threshold is set in Admin through the Actions|Options|Environment|Additional menu.

The MTA programs themselves are oblivious to the delivery mode or application threshold settings. The delivery mode settings control when or whether the client drops messages into the queue directories. If a message drops into a queue directory, the MTA just processes it without worrying about why or how the message got there.

Delivery in Server Never Mode

Server Never mode bypasses the use of queue directories and the Post Office Server program by relying on the built-in delivery capabilities of the client software (see Figure 13).

Figure 13: The Server Never delivery process.

Server Never can only work in a single post office system because the client cannot deliver to a different message store (post office). The client does not have MS functionality, and MS is needed to route messages between two post offices.

The table in Figure 14 refers to Figure 13 to explain delivery in Server Never mode.

Figure 14: Single post office delivery in Server Never mode.

Logical Action	Physical Action
1	User A sends a message.	User A clicks Send, and, since there is no external Post Office server, the client's built-in OFS functions takeover to deliver the message.
2	The client program inserts a single copyof the message in a message database.	User A's client software creates a new message record in User A's outgoing message database (MSGnn.DB inthe OFMSG directory).
3	The message appearsin the sender's Out Box.	User A's client software creates an Out Box pointer in its own mailbox database (USERAxx.DB in the OFUSER directory). Now, User A can read the message just sent or check the status of the message (has User B opened it or deleted it?).
4	The client programdelivers the message to User B.	User A's client software accesses User B's mailbox database (USERBxx.DB) in the OFUSER directory, and creates an In Box pointer to the new message.
5	User B sees the message title appearin his In Box.	With the pointer created in USERBxx.DB, the message has been delivered. If User B happens to be in GroupWise at the time of delivery, a new message from User A suddenly appears on his In Box screen.

Message delivery can actually be a little more complicated than in this example. For instance, if notification is being used, User A's client will also write to the OFNOTIFY directory to User B's notification file (NOTbxx.FIL). If the message is large, part of the message will be split off to the OFFILES directory as an attachment file.

But these complications don't change the basic principle of message delivery: a single copy of the message is inserted in a message database, and a pointer to the message is written to both sender and recipient mailboxes. If messages are sent between message stores--between post offices--a copy of the message will be kept in each post office. If the message is sent to someone sharing the same message store, both sender and recipient read the same copy of the message, with the sender seeing the message in the Out Box and the recipient through the In Box.

No matter how big or complex your system gets, message delivery in GroupWise stays essentially this simple; the thing that changes as a system grows is who does the work--the client or an external server program.

In the scenario above, unless an error message appears in the client during the send process, you can be confident that message delivery was successful.

Note: If you try to send a message to a user on a different postoffice while configured as Server Never, the client willreturn an error and refuse to send the message at all. Thiswill occur even if a message server is actually running. Thethreshold setting tells the client what to expect in terms ofMTA availability--it says nothing about actual MTAavailability.

When set to Server Never, the client will refuse to sendsome messages because it doesn't believe a message serveris available. When set to Server Always or Use AppThreshold, the client trusts that a message server isavailable and will drop messages into queue directoriesregardless of whether MTA programs are actually running.

Delivery in Use Application Thresholds Mode

This example deals only with delivery within a single post office. Delivery between post offices will be taken up later. Suppose that User A's post office has a Post Office Server running which is supposed to deliver all messages. This example assumes a delivery mode of Use Application Thresholds and a threshold of 0. (If the threshold were 2 or higher, the delivery process for a message addressed to a single recipient would be the same as in the Server Never delivery example above.)

Figure 15: The Use Application Thesholds delivery process.

The table in Figure 16 refers to Figure 15 to explain delivery in Use Applications Thresholds mode.

Figure 16: Single post office delivery in Use Apps Thresholds mode.

Logical Action	Physical Action
1	User A sends a message to User B.	User A clicks Send. On startup, the client program checked the delivery mode and the application threshold. With the threshold set to 0, the client knows it can count on OFS to help with delivery.
2	The client program inserts a single copyof the message in a message database.	User A's client software creates a new message record in User A's outgoing message database (MSGnn.DB) inthe OFMSG directory.
3	The message appears in thesender's Out Box.	User A's client software creates an outbox pointer in its own mailbox database (USERAxx.DB) in the OFUSER directory. Now, User A can read the message just sent or check the status of the message (has User B opened it or deleted it?). So far, the delivery process is still the same as in Server Never mode.
4	The sender's clienttells the Post Office Server to complete the delivery process.	User A's client software puts a small message in WPCSOUT for OFS to pick up. This is the first point at which delivery differs from Server Never mode. The sender's client has already inserted the actual message into the message database; delivery will consist only ofwriting a message pointer to the recipient's mailbox.
5	OFS delivers the message.	OFS scans the WPCSOUT directory (usually every 30 seconds or so), and notices a new file has been copied there. OFS picks up the file, reads the delivery instructions contained in the file, and delivers the message (writes the pointer) to the recipient's mailbox(USERBxx.DB in the OFUSER directory).

Notice that the process was just the same as the Server Never example all the way up to Step 4. Even with an external server running, the client does the work of creating the message instead of handing the job off to the external server. All that really changed was who writes the pointer to the recipient's mailbox database. So why does the client still do so much of the work when there is an external server available? It's done this way so that an entry will appear immediately in the sender's outbox, rather than appearing only on completion of delivery. And it's more efficient for the client to create the single copy of the message needed in the message database by itself, rather than create a copy of a large message in a queue directory, and then have the server create another copy in the message database.

Delivery in Server Always Mode

Server Always delivery is the simplest of all three modes. Any action taken in the client that requires a change to be made to any database causes a message to be created in the post office's WPCSOUT\OFS\1 directory. From there, the Post Office Server handles everything.

Summary of Message Delivery within a Single Post Office

There are three modes of message delivery in a post office:

The client handles all delivery functions (Server Never).
The server handles all delivery functions (Server Always).
The delivery workload is balanced between the client and server applications (Use Application Thresholds).

Server Never mode is appropriate for small, single post office installations. Server Always is for very high security installations. Use Application Thresholds is the appropriate mode for the majority of GroupWise implementations.

Message Delivery Between Post Offices

Message delivery within a single post office is handled either by the client application or with the assistance of the Post Office Server (OFS). To send messages between two or more post offices, each post office needs its own Post Office Server to handle message delivery, and a Message Server (MS) to route messages between the post offices. The discussion in this section focuses on delivery between post offices in a single domain. Delivery between post offices in different domains is beyond the scope of this AppNote, but it is covered in the full GroupWare Support Professional's Guide (see the title page of this AppNote for availability information). A Post Office Server's "world" is just a single post office. But a Message Server's "world" is an entire domain. A single Message Server routes message traffic between all post offices and gateways in an entire domain. Even if there are 100 post offices, a single Message Server services them all. Whenever mail needs to leave the post office, OFS hands off to MS by placing messages in the post office WPCSIN directory. The WPCSIN directory is each post office's link with the outside world. The client can also put messages in WPCSIN for delivery to other post offices or gateways.

Status Messages

GroupWise supports statuses which tell a sender what is happening with a message: has it been delivered? opened? deleted? Users can configure how much status information they want back when they send a message. Status information is stored in the message database (MSGnn.DB) as part of the message record, and is readable in the client by choosing Message Info. When a message is sent only within a single post office, most status updating is done directly and immediately by the client or OFS. But when a message travels across post offices, status information is sent back to the originating post office as a message like any other mail message, except that the status message is created by OFS, not by the client program. Statusing was omitted from message flow diagrams earlier in this document because it is so simple when a message stays on the originating post office. Things get more interesting when sending status information between post offices.

Delivery Between Two Post Offices in the Same Domain

Suppose you have a domain with two post offices, as in Figure 17. User A belongs to PostOffice 1 while User B belongs to PostOffice 2. User A sends a message to User B. Post Office Servers (shown in Figure 17 as large circles) are running for each post office, and a Message Server (shown as the triangle in the middle of Figure 17) is running to service both post offices in the domain. Figure 17: How messages are delivered between two post offices in the same domain.

Figure 18: Message delivery between two post offices in the same domain.

Logical Action	Physical Action
1	User A sends a message to a user on Post Office 2. The message is inserted in User A's Out Box, and a copy with routinginformation is handed to the Message Server.	User A clicks Send. As in delivery within a post office, the message is first inserted in A's Out Box by putting a copy of the message in a message database. Then a copy of the message is placed in WPCSIN for routing to the other post office by MS. If User A looks right now at the Message Info in his Out Box, the message will show a status of Pending.
2	The Message Server routes the message toPost Office 2.	The Message Server, which is always periodically scanning all WPCSIN directories throughout the domain, notices that a file has been put in WPCSIN in Post Office 1. It checks the address of the file and sees it is destined for a user on PostOffice 2. So MS copies the message to the WPCSOUT directory in Post Office 2, where the other Post Office 2 OFS will see it.
3	Post Office 2's PostOffice Server delivers the message	OFS for PostOffice 2 picks up the message from the WPCSOUT directory and delivers it by writing to boththe message database and the recipient's mailbox database.
4	Post Office 2's Post Office Server generatesa delivery status message to be sent back to Post Office 1.	As OFS delivers the message, it generates a status message confirming successful entry of the message in both User B's mailbox and in the message database. This return status message is placed in PostOffice 2's WPCSIN directory to wait for MS to pick it up and move it to Post Office 1.
5	MS routes the status message back to PostOffice 1.	MS, still scanning all WPCSIN directories throughout the domain, notices the status message in Post Office 2's WPCSIN directory, and moves it over to PostOffice 1's WPCSOUT directory.
6	Post Office 1's Post Office Server updatesthe message status in the sender's Out Box	PostOffice 1's OFS picks up the message from the WPCSOUT directory and updates the message's status information. The next time User A checks the Message Info in the Out Box, the status will havechanged from Pending to Delivered.

Summary of Message Delivery

The examples you have seen up to this point have shown you the fundamentals of message flow in even the largest GroupWise system. We haven't touched yet on multiple domain systems, indirect routing or routing through gateways, but those are all just variations on the same theme. If you clearly understand the principles and diagrams already shown, you will be able to easily trace message traffic through even the most complex systems. When you get down to it, understanding message flow is little more than being able to predict which WPCSIN or WPCSOUT directory a message will land in next.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.