Microsoft KB Archive/254346

= XFOR: GroupWise Architecture (Part 2): Message Flow and Glossary =

Article ID: 254346

Article Last Modified on 2/21/2007

-

APPLIES TO


 * Microsoft Exchange 2000 Server Standard Edition
 * Microsoft Exchange Server 5.5 Standard Edition

-



This article was previously published under Q254346



SUMMARY
This Microsoft Knowledge Base article is the second in a series of three Knowledge Base articles that provide a summary of the basic architecture of Novell GroupWise 5.5. This article describes GroupWise message flow and offers a method of troubleshooting message flow. A glossary of GroupWise terms and Exchange Server equivalents is provided at the end of this article.

235362 GroupWise Architecture (Part 1): Domain and Post Office Architecture

Introduction

GroupWise Domain Architecture

Domain Hierarchy

Directory Structure and Replication

Domain Directory Structure

GroupWise Post Office Architecture

Post Office Directory Structure

Message Store Architecture

254346 GroupWise Architecture (Part 2): Message Flow and Glossary

254353 GroupWise Architecture (Part 3): API Gateway



GroupWise Message Flow
One of the most useful skills in troubleshooting GroupWise problems is knowing how GroupWise message flow works. The following sections and scenarios describe message flow sufficiently that nearly all else can be extrapolated.

Basic Message Flow Concepts
A few basic concepts underlie the entire message flow architecture in GroupWise:  Directories are named from the perspective of the message transfer agent (MTA), which was originally called the "WordPerfect Connection Server" (WPCS). As such, all Wpcsin directories are input queues for the MTA, and all Wpcsout directories are output queues for the MTA.  Priority queues directories are nearly all the same, with any differences being in the first two directories: Wpcsin (or Wpcsout\ ) \0             Time sensitive messages (for example, busy searches) \1             Administrative messages (for example, agent restart requests) \2             High priority messages \3             High priority statuses \4             Normal priority messages \5             Normal priority statuses \6             Low priority messages \7             Low priority statuses Because of this fact, a lot can be known about a message by simply noting its location: Postoff\Wpcsout\Ofs\5\3e528411.a19 is a normal priority status that is waiting to be processed by the Post Office Agent (POA). Its presence implies that:  A normal priority message was sent by a user on this post office, and this is a status returning to update the original message. -and-

 The POA has not yet processed this status. If the status lingers long enough in this directory, you might assume that either the POA is not running properly, or that the message is corrupted in some way. 

Delivery to a Local Recipient
In this scenario, UserA on PostOffice1 sends a message with an attachment to UserB and UserC on the same post office. This scenario assumes a TCP/IP (client/server) connection, although a UNC or Mapped (Direct) connection is virtually the same.
 * 1) UserA sends the message. UserA's GroupWise client transmits the message to the POA for PostOffice1.
 * 2) The POA writes the attachment file to Postoff\Offiles\Fd01d\83fe2651.01d.
 * 3) The POA writes the message text and message header information to a message record in Postoff\Ofmsg\Msg15.db (which is UserA's assigned message database), and writes a pointer to the attachment file in the Offiles directory.
 * 4) The POA writes a pointer to the message in the Sent Items folder of UserA's user database (Postoff\Ofuser\User3vr.db).
 * 5) The POA writes a pointer to message in the Inbox folder of UserB's and UserC's message databases (Postoff\Ofuser\User87g.db and User2dd.db respectively).
 * 6) The POA updates the message record with a "Delivered" status.
 * 7) If UserB and UserC are online, the POA notifies them by communicating with their GroupWise client software.
 * 8) UserB sees the notification, opens the message, and reads it. UserB's client software communicates this fact to the POA, which updates the message record with an "Opened" status for UserB.
 * 9) UserC deletes the message without reading it. UserC's client software communicates this fact to the POA, which updates the message record with a "Deleted" status for UserC.
 * 10) UserA can open the message properties in the Sent Items folder and see that the message was successfully delivered to both users, and that UserB read the message, while UserC deleted the message without reading it.

For additional information, see the Novell online documentation for GroupWise at the following Novell Web site:

http://www.novell.com/groupwise/administration/gw55/us/tbook301.html

Delivery to a Different Post Office, Same Domain
In the following scenario, UserA on PostOffice1 sends a normal priority message to UserD on PostOffice2. Both post offices are in the same domain. This scenario assumes that the MTA and POA are configured to communicate with each other by means of TCP/IP, although communication by means of UNC is very similar as far as movement through the directories is concerned.
 * 1) UserA sends a message to UserD. UserA's GroupWise client transmits the message to the POA for PostOffice1.
 * 2) The POA for PostOffice1 writes any attachments to the Offiles directories, writes a message record in Msg15.db (which is UserA's assigned message database), updates the message record with a pointer to attachments in the Offiles directories, and then writes a pointer to the message in UserA's user database (User3vr.db)
 * 3) The POA for PostOffice1 writes the entire message, in encrypted message transfer form, to Postoff\Wpcsin\4.
 * 4) The POA transmits the message to the MTA for the domain. After the MTA has fully received the message, the POA deletes the message from the Wpcsin\4 directory.
 * 5) The MTA for the domain receives the message and writes it to the Wpdomain\Mslocal\Gwinprog\4 directory while it communicates with the POA for PostOffice2.
 * 6) The MTA for the domain communicates with the POA for PostOffice2, and then transmits the message. When the POA for PostOffice2 has successfully received the message, the MTA deletes the message from Gwinprog\4.
 * 7) The POA for PostOffice2 performs local delivery the same as described in the "Delivery to a Local Recipient" section. (If MTA to POA communication is configured for UNC links, the MTA writes the message to the Postoff\Wpcsout\Ofs\4 directory on PostOffice2, where the POA picks it up and then performs local delivery.)
 * 8) The POA for PostOffice2 generates a "Delivered" status for the message, and then transmits it to the MTA.
 * 9) The MTA writes the status to Wpdomain\Mslocal\Gwinprog\5 while the MTA communicates with the POA on PostOffice1.
 * 10) The POA on PostOffice1 receives the status from the MTA, and updates the original message record with a "Delivered" status for UserD.

For additional information about this process, see the Novell online documentation for GroupWise at the following Novell Web site:

http://www.novell.com/groupwise/administration/gw55/us/tbook311.html

Delivery to a Post Office in a Different Domain
In this scenario, UserA on PostOffice1 in Domain1 sends a high priority message to UserF on PostOffice3 in Domain2. This scenario assumes that the link between domains is configured to be a direct TCP/IP link.
 * 1) UserA sends a message. UserA's GroupWise client transmits the message to the POA on PostOffice1, where the POA performs the initial steps of local delivery as described in the "Delivery to a Local Recipient" section, steps 2 through 4.
 * 2) The POA for PostOffice1 writes an encrypted message transfer file to its local Postoff\Wpcsin\2 directory ("2" because this is a high priority message), and then communicates with the MTA for Domain1.
 * 3) The MTA for Domain1 receives the message, and then writes it to Wpdomain\Mslocal\Gwinprog\2 directory. After the MTA successfully receives the message, the POA for PostOffice1 deletes the message from the Postoff\Wpcsin\2 directory on PostOffice1.
 * 4) The MTA for Domain1 communicates with the MTA for Domain2, and then transmits the message. The MTA for Domain2 writes the message to its local Wpdomain\Mslocal\Gwinprog\2 directory. After the message is successfully transferred, the MTA for Domain1 deletes the message from its local Gwinprog\2 directory.
 * 5) The MTA in Domain2 communicates with the POA for PostOffice3, and then transmits the message. After the message is successfully delivered, the MTA for Domain2 deletes the message from its local Gwinprog\2 directory.
 * 6) The POA for PostOffice3 performs local message delivery as described in the "Delivery to a Local Recipient" section, steps 2 through 5, and then generates a "Delivered" status.
 * 7) The "Delivered" status is transmitted to the MTA for Domain2, which temporarily queues the message to its local Wpdomain\Mslocal\Gwinprog\3 directory ("3" because it's a high priority status).
 * 8) The MTA for Domain2 transmits the status to the MTA for Domain1, which delivers it to the POA for PostOffice1, which updates the original message record with a "Delivered" status for UserF.

For additional information about this process, see the Novell online documentation for GroupWise at the following Novell Web site:

http://www.novell.com/groupwise/administration/gw55/us/tbook321.html

Troubleshooting GroupWise Message Flow
Because GroupWise writes the message transfer file to disk at every hop, you can isolate a message transfer problem by stopping and starting individual agents along the way and verifying that the message is being delivered where it should. Because GroupWise logging is not always self-revealing, this is sometimes the only method for troubleshooting message flow.

For example, if UserA's high priority message to UserF (as described in the "Delivery to a Post Office in a Different Domain" section) is not delivered, to troubleshoot that problem you can:
 * 1) Check the logs for all agents along the way. "Verbose" logging is the most helpful level of logging when you troubleshoot GroupWise message flow problems because "Normal" logging yields too little information, and "Diagnostic" logging yields too much information, most of which is of little value.
 * 2) Stop the MTA for Domain1. Have UserA send the message. Verify that a new message is written to the Postoff\Wpcsin\2 directory ("2" for High Priority messages) on PostOffice1. If no new message is written there, the problem may be with either the client software or the POA for PostOffice1. If the message appears there, proceed to the next step.
 * 3) Stop the MTA for Domain2, and start the MTA for Domain1. Verify that the message appears in Domain1's Wpdomain\Mslocal\Gwinprog\2 directory, and that the message is deleted from the PostOffice1's Postoff\Wpcsin\2 directory. The message file may be in Domain1's Wpdomain\Mslocal\Mshold\Domxxxx\2 directory, which is where messages that are delayed are stored. If so, proceed to the next step. If not, the problem may be with the MTA for Domain1.
 * 4) Stop the POA for PostOffice3 in Domain2, and start the MTA for Domain2. Verify that the message appears in Domain2's Wpdomain\Mslocal\Gwinprog\2 directory, or in the Wpdomain\Mslocal\Mshold\Posxxxx\2 directory.

And so on, until you isolate the negligent agent.

For additional information and more troubleshooting strategies, see the Novell online documentation for GroupWise at the following Novell Web site:

http://www.novell.com/groupwise/administration/gw55/us/gwtroubl.html

This is the end of Part 2. A glossary of GroupWise terms follows.

Part 3 describes the GroupWise API Gateway and offers detailed troubleshooting suggestions:

254353 GroupWise Architecture (Part 3): API Gateway

The following is a collection of GroupWise terms and their Exchange Server equivalents.

Keywords: kbinfo KB254346

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.