Novell GROUPWISE 7 TROUBLESHOOTING

Novell
GroupWise®

7

Setember 29, 2006

www.novell.com

TROUBLESHOOTING 3: MESSAGE

FLOW AND DIRECTORY STRUCTURE

Legal Notices

Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and
specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose.
Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time,
without obligation to notify any person or entity of such revisions or changes.

Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims
any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc.
reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to
notify any person or entity of such changes.

Any products or technical information provided under this Agreement may be subject to U.S. export controls and the
trade laws of other countries. You agree to comply with all export control regulations and to obtain any required
licenses or classification to export, re-export, or import deliverables. You agree not to export or re-export to entities
on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export
laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses.
See the Novell International Trade Services Web page (http://www.novell.com/info/exports/) for more information
on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export
approvals.

Copyright © 1993-2006 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied,
stored on a retrieval system, or transmitted without the express written consent of the publisher.

Novell, Inc. has intellectual property rights relating to technology embodied in the product that is described in this
document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S.
patents listed on the Novell Legal Patents Web page (http://www.novell.com/company/legal/patents/) and one or
more additional patents or pending patent applications in the U.S. and in other countries.

Novell, Inc.
404 Wyman Street, Suite 500
Waltham, MA 02451
U.S.A.
www.novell.com

Online Documentation: To access the online documentation for this and other Novell products, and to get

updates, see the Novell Documentation Web site (http://www.novell.com/documentation).

Novell Trademarks

For Novell trademarks, see the Novell Trademark and Service Mark list (http://www.novell.com/company/legal/

trademarks/tmlist.html).

Third-Party Materials

All third-party trademarks are the property of their respective owners.

Contents

About This Guide 9

Part I Message Flow Diagrams 11

1 Message Delivery in the Local Post Office 13

1.1 Online Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2 Caching Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3 Remote Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Message Delivery to a Different Post Office 19

2.1 TCP/IP Link Open: Transfer between Post Offices Successful . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 TCP/IP Link Closed: Transfer between Post Offices Delayed . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Message Delivery to a Different Domain 27

3.1 TCP/IP Link Open: Transfer between Domains Successful . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 TCP/IP Link Closed: Transfer between Domains Delayed . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Message Delivery to and from the Internet 35

4.1 TCP/IP Link: Outbound Transfer to the Internet Successful . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 TCP/IP Link: Outbound Transfer to the Internet Delayed or Unsuccessful . . . . . . . . . . . . . . . 38

4.3 Mapped/UNC Link: Outbound Transfer to the Internet Successful . . . . . . . . . . . . . . . . . . . . . 41

4.4 Mapped/UNC Link: Outbound Transfer to the Internet Delayed or Unsuccessful . . . . . . . . . . 43

4.5 TCP/IP Link: Inbound Transfer from the Internet Successful. . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.6 Mapped/UNC Link: Inbound Transfer from the Internet Successful . . . . . . . . . . . . . . . . . . . . 49

5 Message Delivery through a Modem Connection 51

5.1 “Hit the Road” Process in Online Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2 Modem Link through the Async Gateway in Remote Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Administrative Database Update 59

Part II Directory Structure Diagrams 61

7 Message Transfer/Storage Directories 63

7.1 Domain Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.1.1 domain directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.1.2 wpcsin directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.1.3 wptools directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.1.4 wpgate directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.1.5 wpcsout directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.1.6 mtaname file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Contents 5

7.1.7 wpdomain.db file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.1.8 wpdomain.dc file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.1.9 wphost.dc file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.1.10 gwdom.dc file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.1.11 gwpo.dc file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.1.12 viewcopy.log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.2 Post Office Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.2.1 post_office directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.2.2 wpcsin directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.2.3 gwdms directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.2.4 ofmsg directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.2.5 ofuser directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.2.6 offiles directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.2.7 ofviews directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.2.8 ofwork directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.2.9 ofdirect directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.2.10 oftemp directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.2.11 wpcsout directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.2.12 wphost.db file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.2.13 gwpo.dc file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.2.14 ngwguard.db file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.2.15 ngwguard.dc file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2.16 ngwguard.fbk file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2.17 ngwguard.rfl file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2.18 ngwcheck.db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.3 MTA Local Queue Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.3.1 mslocal directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.3.2 msglog directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.3.3 gwinprog directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.3.4 mshold directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.3.5 domainms directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.3.6 postx directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.3.7 gatewayx directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.3.8 domainx directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.3.9 0-7 directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.3.10 mtaname files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.3.11 gwvsscan directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.3.12 mtaconv directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.4 Internet Agent Queue Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.4.1 domain\wpgate\gwia directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7.4.2 gwia directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.5 WebAccess Agent Queue Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.5.1 domain\wpgate\webac70a directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.5.2 000.prc directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.5.3 wpcsin directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.5.4 wpcsout directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

7.5.5 gwhold directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.5.6 gwprob directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.5.7 template directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.5.8 commgr.cfg file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.5.9 comint.cfg file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.5.10 mimetype.cfg file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.5.11 gwac.db file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.5.12 gwac.dc file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.6 Caching Mailbox Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.6.1 \novell\groupwise\gwxxxxxx directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.6.2 rofdata directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.6.3 wpcsin directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5

6 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

7.6.4 wpcsout\ofs directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.6.5 wpgwsend directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.6.6 wpgwrecv directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.6.7 remoten.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.7 Remote Mailbox Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.7.1 remote_mailbox directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.7.2 rofdata directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.7.3 wpcsin directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.7.4 wpcsout\ofs directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

7.7.5 wpgwsend directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

7.7.6 wpgwrecv directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7.7.7 remoten.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

8 Agent Installation Directories 107

8.1 GroupWise Agent Installation (POA and MTA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

8.1.1 NetWare Installation Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

8.1.2 Linux Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

8.1.3 Windows Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

8.2 Internet Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

8.2.1 NetWare Installation Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

8.2.2 Linux Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

8.2.3 Windows Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

8.3 WebAccess Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

8.3.1 NetWare Installation Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

8.3.2 Linux Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

8.3.3 Windows Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

8.3.4 Document Viewer Agent Working Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

8.4 Monitor Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

8.4.1 Linux Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

8.4.2 Windows Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.5 Apache/Tomcat Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

8.5.1 NetWare Installation Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

8.5.2 Linux Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

9 Software Distribution Directory 155

9.1 NetWare/Windows Software Distribution Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

9.1.1 \grpwise\software directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

9.1.2 agents directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

9.1.3 domain directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

9.1.4 po directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

9.1.5 client directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

9.1.6 gwcheck directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

9.1.7 ofviews directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

9.1.8 ppforms directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

9.1.9 uwl directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

9.1.10 admin directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

9.1.11 internet directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

9.1.12 license directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

9.1.13 common directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

9.1.14 docs directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

9.2 Linux Software Distribution Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

9.2.1 /opt/novell/groupwise/software directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

9.2.2 agents directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

9.2.3 domain directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

9.2.4 po directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

7

9.2.5 client directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

9.2.6 ofviews directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

9.2.7 admin directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

9.2.8 internet directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

9.2.9 license directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

9.2.10 docs directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

9.2.11 gwinst directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

10 GroupWise Client Installation Directories 173

10.1 Windows Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

10.1.1 c:\novell\groupwise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

10.1.2 grpwise.exe file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

10.1.3 gwtip.exe file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

10.1.4 notify.exe file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

10.1.5 addrbook.exe file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

10.1.6 htrsetup.exe file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

10.1.7 gwimpexe.exe file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

10.1.8 gwmailto.exe file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

10.1.9 gwreload.exe file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

10.1.10 gwsync.exe file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

10.1.11 pdaconnect.exe file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

10.1.12 ngwguard.dc file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

10.1.13 wprof.dc file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

10.1.14 *.dll files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

10.1.15 *.ocx files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

10.1.16 *.flt files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

10.1.17 *.chm files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

10.1.18 gwcheck directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

10.1.19 ofviews directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

10.1.20 ppforms directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

10.2 Cross-Platform Client on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

10.2.1 /opt/novell/groupwise/client directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

10.2.2 bin directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

10.2.3 lib directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

10.2.4 jre directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

10.2.5 logs directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

10.3 Cross-Platform Client on Macintosh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

10.3.1 /Applications/GroupWise.app directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

10.3.2 Contents directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

10.3.3 MacOS directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

10.3.4 Resources directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

10.3.5 lib directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

10.3.6 Java directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Part III Documentation Updates 181

A June 15, 2006 (GroupWise 7 SP1) 183

8 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

About This Guide

This Novell® GroupWise® Troubleshooting 3 Guide provides diagrams to help you understand the
structure and functioning of your GroupWise system. The guide is divided into the following
sections:

 “Message Flow Diagrams” on page 11

 “Directory Structure Diagrams” on page 61

Other sources of troubleshooting assistance include:

 Novell Support (http://www.novell.com/support)

 Novell Support Knowledgebase (http://www.novell.com/support/supportcentral)

 GroupWise 7 Support Forums (http://support.novell.com/forums/2gw.html)

 Novell GroupWise Support Community (http://www.novell.com/support/

browse.do?WidgetName=BROWSE_PRODUCT&BROWSE_PRODUCT.TaxoName=SG_S
upportGoals&NodeType=leaf&NodeName=GroupWise&TaxoName=SG_SupportGoals&BR
OWSE_PRODUCT.isProductTaxonomy=true&BROWSE_PRODUCT.NodeId=SG_GROUP
WISE_1_1&BROWSE_PRODUCT.NodeType=leaf&BROWSE_PRODUCT.thisPageUrl=%
2Fproduct%2Fproducts.do&NodeId=SG_GROUPWISE_1_1&id=m1&AppContext=AC_Site
Central)

 GroupWise Cool Solutions (http://www.novell.com/coolsolutions/gwmag/index.html)

Audience

This guide is intended for network administrators who install and administer GroupWise..

Feedback

We want to hear your comments and suggestions about this manual and the other documentation
included with this product. Please use the User Comments feature at the bottom of each page of the
online documentation, or go to www.novell.com/documentation/feedback.html and enter your
comments there.

Documentation Updates

For the most recent version of GroupWise 7 Troubleshooting 3: Message Flow and Directory
Structure, visit the GroupWise 7 Documentation Web site (http://www.novell.com/documentation/

gw7).

Additional Documentation

For additional GroupWise documentation, see the following guides at the GroupWise 7

Documentation Web site (http://www.novell.com/documentation/gw7):

 Installation Guide

 Administration Guide

 Multi-System Administration Guide

About This Guide

9

 Interoperability Guide

 Troubleshooting 1: Error Messages

 Troubleshooting 2: Solutions to Common Problems

 GroupWise Client User Guides

 GroupWise Client Frequently Asked Questions (FAQ)

Documentation Conventions

In Novell documentation, a greater-than symbol (>) is used to separate actions within a step and
items in a cross-reference path.

A trademark symbol (

TM

, ®, etc.) denotes a Novell trademark. An asterisk denotes a third-party

trademark.

When a single pathname can be written with a backslash for some platforms or a forward slash for
other platforms, the pathname is presented with a backslash. Users of platforms that require a
forward slash, such as Linux*, should use forward slashes as required by your software.

When a startup switch can be written with a forward slash for some platforms or a double hyphen for
other platforms, the startup switch is presented with a forward slash. Users of platforms that require
a double hyphen, such as Linux, should use double hyphens as required by your software.

10 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

I

Message Flow Diagrams

This part of Troubleshooting 3: Message Flow and Directory Structure helps you understand how

®

messages travel between GroupWise

users and how administrative updates to GroupWise

databases occur.

 Chapter 1, “Message Delivery in the Local Post Office,” on page 13

 Chapter 2, “Message Delivery to a Different Post Office,” on page 19

 Chapter 3, “Message Delivery to a Different Domain,” on page 27

 Chapter 4, “Message Delivery to and from the Internet,” on page 35

 Chapter 5, “Message Delivery through a Modem Connection,” on page 51

 Chapter 6, “Administrative Database Update,” on page 59

Message Flow DiagramsI11

12 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

1

Message Delivery in the Local Post Office

The GroupWise® 7 client always uses client/server access to the post office but it can interact with
the POA for the post office in different ways. For a review, see “Using Different GroupWise Modes

(Online, Caching, and Remote)” in “Getting Started” in the GroupWise 7 Windows Client User

Guide.

 Section 1.1, “Online Mode,” on page 13

 Section 1.2, “Caching Mode,” on page 15

 Section 1.3, “Remote Mode,” on page 18

1.1 Online Mode

This message flow diagram illustrates how a GroupWise message travels from one user to another in
the local post office when the client and POA communicate by way of TCP/IP and the users are
accessing their Online mailboxes.

Figure 1-1 Message Flow in Online Mode

10

1

2

a

9

3

POA

4

7

8

5

6

b

1

b

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

0-7

ofs

0-7

Table 1-1 Message Flow in Online Mode Stages

Stage Icon Description

The user sends a message to recipients in the same post office. The

Sender

access mode setting for the post office is Client/Server Only.

Message Delivery in the Local Post Office

13

Stage Icon Description

The GroupWise client communicates with the POA by way of TCP/IP.
Sender’s
GroupWise
Client

The POA receives the message from the GroupWise client and
POA for Local
Post Office

performs the following actions for the sender:

 Adds the message to the message database (msgnnn.db)

assigned to the sender.

 Creates a pointer in the sender’s user database (userxxx.db)

so the message appears in the sender’s mailbox as a sent item.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates

pointers from the message to its attachments. (For database
efficiency, messages and distribution lists larger than 2 KB are
also handled as attachments.)

The POA also performs the following actions for the recipient:

 Creates a pointer in each recipient’s user database

(userxxx.db) to the message in the message database
(msgnnn.db) so the new message appears in the recipient’s
mailbox.

 Updates the message in the message database (msgnnn.db)

with a Delivered status for each recipient.

POA for Local
Post Office

Recipient’s
GroupWise
Client

Recipient

Recipient’s
GroupWise Client

POA for Local
Post Office

POA for Local
Post Office

Sender

The POA communicates to the GroupWise client by way of TCP/IP that

a new message has arrived.

The Notify component of the recipient’s GroupWise client notifies the

recipient that a new message has arrived.

Each recipient opens the message in the GroupWise client.

Each recipient’s GroupWise client communicates the Opened status to

the POA by way of TCP/IP.

The POA receives the Opened status from the GroupWise client and

updates the message in the message database with the Opened

status for each recipient who opens the message.

The POA communicate the Opened status to the sender’s GroupWise

client by way of TCP/IP.

When the sender checks the sent items in his or her mailbox in the

GroupWise client, the message displays a status of Delivered for each

recipient (and possibly Opened as well if the recipient has opened the

message).

14 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

1.2 Caching Mode

This message flow diagram illustrates how a GroupWise message travels from one user to another in
the local post office when the users are accessing their Caching mailboxes.

Figure 1-2 Message Flow in Caching Mode

14

16

1

2

Table 1-2 Message Flow in Caching Mode Stages

Stage Icon Description

a

13

3

15

rofdata

msg.db
user.db

wprof.db

wpcsin

l

4

POA

b

6

12

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

0-7

0-7

11

5

10 7

8

9

b

rofdata

msg.db
user.db

wprof.db

wpcsin

l

Sender

The user sends a message to recipients in the same post office. The
user is in Caching mode.

Message Delivery in the Local Post Office 15

Stage Icon Description

The GroupWise client updates the sender’s Caching mailbox
Sender’s
GroupWise
Client

(\novell\groupwise\gwxxxxxxx\rofdata) by performing the

following actions:

 Adds the message to the message database

(rofdata\msg.db) in the Caching mailbox. This database is
local equivalent of the msgnnn.db database in the post office.

 Creates a pointer in the sender’s user database

(rofdata\user.db) in the Caching mailbox so the message
appears in the sender’s mailbox as a sent item. This database is
the local equivalent of the userxxx.db database in the post
office.

 Places attachments larger than 2 KB in the rofdata

subdirectory in the Caching mailbox and creates pointers from
the message to its attachments. (For database efficiency,
messages and distribution lists larger than 2 KB are also handled
as attachments.) There is no local equivalent to the offiles
subdirectory in the post office, so attachments are placed directly
in the rofdata subdirectory in the Caching mailbox.

 Places a copy of the message in the rofdata\wpcsin\1

priority subdirectory to await the next connection to the POA.

In Caching mode, sending a message always initiates an immediate
Sender’s
GroupWise
Client

connection with the POA in order to send the message. The

GroupWise client communicates the message to the POA and deletes

the copy in the rofdata\wpcsin\1 priority subdirectory when the

POA has processed the message.

POA for Local
Post Office

The POA receives the message from the GroupWise client and

performs the following actions for the sender to update the sender’s

Online mailbox:

 Adds the message to the message database (msgnnn.db)

assigned to the sender in the post office.

 Creates a pointer in the sender’s user database (userxxx.db) in

the post office.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories in the post

office and creates pointers from the message to its attachments.
(For database efficiency, messages and distribution lists larger
than 2 KB are also handled as attachments.)

The POA also performs the following actions for the recipients to

update their Online mailboxes:

 Creates a pointer in each recipient’s user database

(userxxx.db) to the message in the message database
(msgnnn.db) in the post office so that the new message appears
in each recipient’s mailbox.

 Updates the message in the message database (msgnnn.db) in

the post office with a Delivered status for the recipients.

16 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

Because the recipients are also in Caching mode, they do not receive
POA for Local
Post Office

POA for Local
Post Office

Recipient’s
GroupWise
Client

immediate notification that a new message has arrived in their Online

mailboxes. Based on the Send/Retrieve All Marked Accounts Every nn

Minutes option under Accounts > Account Options > General, each

recipient’s GroupWise client sends a request to the POA for items that

have arrived in the recipient’s Online mailbox since the last connection

with the POA.

The POA responds by sending information to update each recipient’s

Caching mailbox and communicates to the GroupWise client that a

new message has arrived.

Each recipient’s GroupWise client updates the recipient’s Caching

mailbox by performing the following actions:

 Adds the message to the message database

(rofdata\msg.db) in the recipient’s Caching mailbox.

 Creates a pointer in the recipient’s user database

(rofdata\user.db) to the message in the message database
(rofdata\msg.db) so the new message appears in the
recipient’s Caching mailbox.

The Notify component of each recipient’s GroupWise client notifies the
Recipient’s
GroupWise
Client

recipient that a new message has arrived.

Recipient

Recipient’s
GroupWise Client

Recipient’s
GroupWise Client

POA for Local
Post Office

Recipient’s
GroupWise Client

POA for Local
Post Office

Each recipient opens the message in the GroupWise client.

Each recipient’s GroupWise client generates an Opened status and

places it in the rofdata\wpcsin\1 priority subdirectory to await the

next connection with the POA.

When each recipient sends a message or the time specified by the

Send/Receive All Marked Accounts Every nn Minutes option has

elapsed, each recipient’s GroupWise client connects with the POA and

communicates the Opened status to the POA, along with any other

data that needs to be uploaded to the recipient’s Online mailbox.

The POA receives the Opened status from the GroupWise client and

updates the message in the sender’s message database with the

Opened status.

Because the sender is in Caching mode, the sender does not

immediately receive the Opened status. Based on the sender’s actions

and caching schedule, the sender’s GroupWise client eventually sends

a request to the POA for items that have arrived in the sender’s Online

mailbox since the last synchronization of the Caching mailbox.

The POA responds by sending information to update the sender’s

Caching mailbox and communicates the Opened status to the sender’s

GroupWise client.

Message Delivery in the Local Post Office 17

Stage Icon Description

The sender’s GroupWise client updates the sender’s Caching mailbox
Recipient’s
GroupWise Client

by performing the following action:

 Updates the message in the message database

(rofdata\msg.db) with a Delivered and Opened status for
each recipient.

When the sender checks the sent items in his or her mailbox in the
Sender

GroupWise client, the message displays a status of Delivered and

Opened for each recipient.

1.3 Remote Mode

Before you can use Remote mode, you must create a Remote mailbox on your computer and have a
connection to your master GroupWise system. See Chapter 5, “Message Delivery through a Modem

Connection,” on page 51.

18 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

2

Message Delivery to a Different Post Office

The MTA handles message transfer between post offices.

 Section 2.1, “TCP/IP Link Open: Transfer between Post Offices Successful,” on page 19

 Section 2.2, “TCP/IP Link Closed: Transfer between Post Offices Delayed,” on page 22

The message flow diagrams in GroupWise 7 Troubleshooting 3: Message Flow and Directory
Structure focus on TCP/IP links because they are the most common and convenient (unless you

have a post office and a domain on the same server). For diagrams that include mapped/UNC links,
see GroupWise 6.5 Troubleshooting 3: Message Flow and Directory Structure. For an explanation
of link types and link protocols, see “Understanding Link Configuration” in “Domains” in the

GroupWise 7 Administration Guide.

2.1 TCP/IP Link Open: Transfer between Post Offices Successful

This message flow diagram illustrates how a GroupWise® message travels from one user to another
between post offices in the same domain when the TCP/IP link between the post office and the
domain is open.

2

Figure 2-1 Message Flow When the TCP/IP Link is Open

1

17

16

2

a

3

POAa

a

4

15

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

0-7

0-7

MTA

5

mslocal

14

gwinprog

mshold

wpcsin

0-7

wpcsout

ads

4

13

0-7

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domainx

0-7

0-7

10

9

POAb

b

8

7

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

11

b

0-7

0-7

12

6

Message Delivery to a Different Post Office

19

Table 2-1 Message Flow When the TCP/IP Link is Open Stages

Stage Icon Description

Sender

Sender’s
GroupWise
Client

POA for
Sender’s
Post Office

The user sends a message to recipients in a different post office in the same
domain.

In this diagram, the access mode setting in the local post office is Client/
Server Only.

The GroupWise client communicates the message to the POA by way of
TCP/IP.

The POA receives the message from the GroupWise client and performs the
following actions for the sender:

 Adds the message to the message database (msgnnn.db) assigned to

the sender.

 Creates a pointer in the sender’s user database (userxxx.db) so the

message appears in the sender’s mailbox as a sent item.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates pointers

from the message to its attachments. (For database efficiency,
messages and distribution lists larger than 2 KB are also handled as
attachments.)

 Creates a copy of the message in the appropriate priority 0-7

subdirectory of the MTA input queue in the sender’s post office, in case
the TCP/IP link to the MTA is currently closed.

POA for
Sender’s
Post Office

MTA for
Local Domain

MTA for
Local Domain

The POA then communicates the message to the MTA by way of TCP/IP,
and deletes the copy in the MTA input queue because the TCP/IP transfer to
the MTA was successful.

To see what happens if the TCP/IP link to the MTA is closed, see

Section 2.2, “TCP/IP Link Closed: Transfer between Post Offices Delayed,”
on page 22.

The MTA receives the message and places it into the MTA “in progress”
(gwinprog) queue.

The MTA then communicates the message to the POA in the recipient’s post
office by way of TCP/IP. When the transmission is successful, the MTA
deletes the message from the MTA “in progress” queue.

If the TCP/IP link to the recipient’s post office is closed, the message is
placed in the closed post office’s holding queue in the MTA’s mslocal
directory for later transfer. The resulting message flow is parallel to what
occurs when a domain is closed. See Section 3.2, “TCP/IP Link Closed:

Transfer between Domains Delayed,” on page 31 for a similar message flow

that illustrates how messages to closed locations are handled.

20 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

POA for
Recipient’s
Post Office

POA for Local
Post Office

When the POA receives the new message from the MTA, it places it into the
MTA output queue in the post office (wpcsout\ofs\0-7) on behalf of the
MTA. Then, the POA for the recipient’s post office performs the following
actions:

 Adds the message to the message database (msgnnn.db)

corresponding to the one assigned to the sender.

 Creates a pointer in the recipient’s user database (userxxx.db) so

the new message appears in the recipient’s mailbox and updates the
notification information in the user database so the recipient can be
notified of the message.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates pointers
from the message to its attachments. (For database efficiency,
messages and distribution lists larger than 2 KB are also handled as
attachments.)

 Creates a Delivered status message in the appropriate priority 0-7

subdirectory of the MTA input queue in the recipient’s post office. It
also communicates the Delivered status message directly to the MTA
by way of TCP/IP. When that transmission is successful, the copy in
the MTA input queue is deleted.

The POA communicates to the GroupWise client by way of TCP/IP that a
new message has arrived.

Recipient’s
GroupWise
Client

Recipient

Recipient’s
GroupWise
Client

POA for
Recipient’s
Post Office

MTA for
Local Domain

MTA for
Local Domain

POA in
Sender’s
Post Office

The Notify component of the recipient’s GroupWise client notifies the
recipient that a new message has arrived.

Each recipient opens the message in the GroupWise client.

Each recipient’s GroupWise client communicates the Opened status
message to the POA by way of TCP/IP.

The POA for the recipient’s post office communicates the status message to
the MTA by way of TCP/IP.

The MTA places the status message into the MTA “in progress” (gwinprog)
queue.

The MTA communicates the status message to the POA for the sender’s
post office by way of TCP/IP.

The POA for the sender’s post office updates the sender’s message
database (msgnnn.db) with the Delivered status information (and possibly
Opened as well if the recipient has opened the message).

Message Delivery to a Different Post Office 21

Stage Icon Description

POA for Local

The POA communicates the status to the sender’s GroupWise client by way
of TCP/IP.

Post Office

Sender

When the sender checks the sent items in his or her mailbox in the
GroupWise client, the message displays a status of Delivered for each
recipient (and possibly Opened as well if the recipient has opened the
message).

2.2 TCP/IP Link Closed: Transfer between Post Offices Delayed

This message flow diagram illustrates how a GroupWise message travels from one user to another
between post offices in the same domain when the TCP/IP link between the post office and the
domain is closed.

Figure 2-2 Message Flow When the TCP/IP Link is Closed

wpcsin

1

17

16

2

a

3

POAa

a

15

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

4

0-7

0-7

MTA

5

mslocal

14

0-7

wpcsout

ads

4

13

gwinprog

0-7

mshold

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domainx

0-7

0-7

10

9

POAb

b

8

7

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

11

b

0-7

0-7

12

6

22 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Table 2-2 Message Flow When the TCP/IP Link is Closed Stages

Stage Icon Description

Sender

Sender’s
GroupWise
Client

POA for
Sender’s
Post Office

The user sends a message to recipients in a different post office in the same
domain.

In this diagram, the access mode setting in the local post office is Client/
Server Only.

The GroupWise client communicates the message to the POA by way of
TCP/IP.

The POA receives the message from the GroupWise client and performs the
following actions for the sender:

 Adds the message to the message database (msgnnn.db) assigned

to the sender.

 Creates a pointer in the sender’s user database (userxxx.db) so the

message appears in the sender’s mailbox as a sent item.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates

pointers from the message to its attachments. (For database efficiency,
messages and distribution lists larger than 2 KB are also handled as
attachments.)

 Creates a copy of the message in the appropriate priority 0-7

subdirectory of the MTA input queue in the sender’s post office, in case
the TCP/IP link to the MTA is currently closed.

POA for
Sender’s
Post Office

MTA for
Local Domain

MTA for
Local Domain

The POA then attempts to communicate the message to the MTA by way of
TCP/IP, but the MTA does not respond. The POA leaves the copy of the
message in the MTA input queue and periodically attempts to contact the
MTA. When the MTA responds again, the POA communicates the message
and deletes the copy in the MTA input queue after the TCP/IP transmission
to the MTA is successful.

The MTA receives the message and places it into the MTA “in progress”
(gwinprog) queue.

The MTA then communicates the message to the POA in the recipient’s post
office by way of TCP/IP. When the transmission is successful, the MTA
deletes the message from the MTA “in progress” (gwinprog) queue.

If the TCP/IP link to the recipient’s post office is closed, the message is
placed in the closed post office’s holding queue in the MTA’s mslocal
directory for later transfer. The resulting message flow is parallel to what
occurs when a domain is closed. For a similar message flow that illustrates
how messages to closed locations are handled, see Section 3.2, “TCP/IP

Link Closed: Transfer between Domains Delayed,” on page 31.

Message Delivery to a Different Post Office 23

Stage Icon Description

POA for
Recipient’s
Post Office

POA for Local
Post Office

Recipient’s
GroupWise
Client

When it receives the new message, the POA for the recipient’s post office
performs the following actions:

 Adds the message to the message database (msgnnn.db)

corresponding to the one assigned to the sender.

 Creates a pointer in the recipient’s user database (userxxx.db) so

the new message appears in the recipient’s mailbox and updates the
notification information in the user database so the recipient can be
notified of the message.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates
pointers from the message to its attachments. (For database efficiency,
messages and distribution lists larger than 2 KB are also handled as
attachments.)

 Creates a Delivered status message in the appropriate priority 0-7

subdirectory of the MTA input queue in the recipient’s post office. It
also communicates the Delivered status message directly to the MTA
by way of TCP/IP and when that transmission is successful, the copy in
the MTA input queue is deleted.

The POA communicates to the GroupWise client by way of TCP/IP that a
new message has arrived.

The Notify component of the recipient’s GroupWise client notifies the
recipient that a new message has arrived.

Recipient

Recipient’s
GroupWise
Client

POA for
Recipient’s
Post Office

MTA for
Local Domain

MTA for
Local Domain

POA in
Sender’s
Post Office

Each recipient opens the message in the GroupWise client.

Each recipient’s GroupWise client communicates the Opened status
message to the POA by way of TCP/IP.

The POA for the recipient’s post office communicates the status message to
the MTA by way of TCP/IP.

The MTA places the status message into the MTA “in progress” (gwinprog)
queue.

The MTA communicates the status message to the POA for the sender’s
post office by way of TCP/IP.

The POA for the sender’s post office updates the sender’s message
database (msgnnn.db) with the Delivered status information (and possibly
Opened as well if the recipient has opened the message).

24 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

POA for Local
Post Office

Sender

The POA communicates the Opened status to the sender’s GroupWise
client by way of TCP/IP.

When the sender checks the sent items in his or her mailbox in the
GroupWise client, the message displays a status of Delivered for each
recipient (and possibly Opened as well if the recipient has opened the
message).

Message Delivery to a Different Post Office 25

26 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

3

Message Delivery to a Different Domain

The MTA handles message transfer between domains.

 Section 3.1, “TCP/IP Link Open: Transfer between Domains Successful,” on page 27

 Section 3.2, “TCP/IP Link Closed: Transfer between Domains Delayed,” on page 31

The message flow diagrams in GroupWise 7 Troubleshooting 3: Message Flow and Directory
Structure focus on TCP/IP links because they are the most common and convenient (unless you

have two domains on the same server). For diagrams that include mapped/UNC links, see

GroupWise 6.5 Troubleshooting 3: Message Flow and Directory Structure. For an explanation of

link types and link protocols, see “Understanding Link Configuration” in “Domains” in the

GroupWise 7 Administration Guide.

3.1 TCP/IP Link Open: Transfer between Domains Successful

This message flow diagram illustrates how a GroupWise® message travels from one user to another
when the domains are connected by a TCP/IP link and the link is open.

Figure 3-1 Message Flow When the TCP/IP Link is Open

3

wpcsin

1

21

20

2

a

3

POAa

a

4

19

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

MTAa

mslocal

18

0-7

0-7

0-7

wpcsout

ads

45

17

gwinprog

0-7

mshold

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domainx

0-7

0-7

7 15

6 16

MTAb

mslocal

wpcsin

0-7

wpcsout

ads

4

gwinprog

0-7

mshold

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domainx

0-7

0-7

12

11

POAb

b

10

9

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

13

b

0-7

0-7

14

8

Message Delivery to a Different Domain

27

Table 3-1 Message Flow When the TCP/IP Link is Open Stages

Stage Icon Description

Sender

Sender’s
GroupWise
Client

POA for
Sender’s
Post Office

POA for
Sender’s
Post Office

The user sends a message to recipients in a post office in a different domain.

In this diagram, the access mode setting for the local post office is Client/Server
Only.

The GroupWise client communicates the message to the POA by way of TCP/
IP.

The POA receives the message from the GroupWise client and performs the
following actions for the sender:

 Adds the message to the message database (msgnnn.db) assigned to

the sender.

 Creates a pointer in the sender’s user database (userxxx.db) so the

message appears in the sender’s mailbox as a sent item.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates pointers

from the message to its attachments. (For database efficiency, messages
and distribution lists larger than 2 KB are also handled as attachments.)

 Creates a copy of the message in the appropriate priority 0-7

subdirectory of the MTA input queue in the sender’s post office, in case
the TCP/IP link to the MTA is currently closed.

The POA then communicates the message to the MTA for the sender’s domain
by way of TCP/IP, and deletes the copy in the MTA input queue because the
TCP/IP transfer to the MTA was successful.

To see what would happen if the TCP/IP link to the MTA is closed, see

Section 2.2, “TCP/IP Link Closed: Transfer between Post Offices Delayed,” on
page 22.

MTA for
Sender’s
Domain

MTA for
Sender’s
Domain

MTA for
Recipient’s
Domain

MTA for
Recipient’s
Domain

The MTA for the sender’s domain receives the message and places it into the
MTA “in progress” (gwinprog) queue.

The MTA for the sender’s domain then communicates the message to the MTA
for the recipient’s domain by way of TCP/IP.

If the TCP/IP link to the recipient’s domain is closed, the message is placed in
the closed domain’s holding queue in the MTA’s mslocal directory for later
transfer. See Section 3.2, “TCP/IP Link Closed: Transfer between Domains

Delayed,” on page 31.

The MTA for the recipient’s domain receives the message and places it into the
MTA “in progress” (gwinprog) queue.

The MTA for the recipient’s domain then communicates the message to the
POA in the recipient’s post office by way of TCP/IP.

28 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

POA for
Recipient’s
Post Office

POA for
Recipient’s
Post Office

Recipient’s
GroupWise
Client

When it receives the new message, the POA for the recipient’s post office
performs the following actions:

 Adds the message to the message database (msgnnn.db) corresponding

to the one assigned to the sender.

 Creates a pointer in the recipient’s user database (userxxx.db) so the

new message appears in the recipient’s mailbox and updates the
notification information in the user database so the recipient can be
notified of the message.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates pointers
from the message to its attachments. (For database efficiency, messages
and distribution lists larger than 2 KB are also handled as attachments.)

 Creates a Delivered status message in the appropriate priority 0-7

subdirectory of the MTA input queue in the recipient’s post office. It also
communicates the Delivered status message directly to the MTA by way
of TCP/IP and when that transmission is successful, the copy in the MTA
input queue is deleted.

The POA for the recipient’s post office communicates to the GroupWise client
by way of TCP/IP that a new message has arrived.

The Notify component of the recipient’s GroupWise client notifies the recipient
that a new message has arrived.

Recipient

Recipient’s
GroupWise
Client

POA for
Recipient’s
Post Office

MTA for
Recipient’s
Domain

MTA for
Recipient’s
Domain

MTA for
Sender’s
Domain

Each recipient opens the message in the GroupWise client.

Each recipient’s GroupWise client communicates the Opened status message
to the POA by way of TCP/IP.

The POA for the recipient’s post office communicates the status message to
the MTA for the recipient’s domain by way of TCP/IP.

The MTA for the recipient’s domain places the status message into the MTA “in
progress” (gwinprog) queue.

The MTA for the recipient’s domain communicates the status message to the
MTA for the sender’s domain by way of TCP/IP.

The MTA for the sender’s domain places the status message into the MTA “in
progress” (gwinprog) queue.

Message Delivery to a Different Domain 29

Stage Icon Description

MTA for

The MTA for the sender’s domain communicates the status message to the

POA for the sender’s post office by way of TCP/IP.
Sender’s
Domain

POA for
Sender’s

The POA for the sender’s post office updates the sender’s message database

(msgnnn.db) with the Delivered status information (and possibly Opened as

well if the recipient has opened the message).
Post Office

POA for

The POA for the sender’s post office communicates the status to the sender’s

GroupWise client by way of TCP/IP.
Sender’s
Post Office

Sender

When the sender checks the sent items in his or her mailbox in the GroupWise

client, the message displays a status of Delivered for each recipient (and

possibly Opened as well if the recipient has opened the message).

3.2 TCP/IP Link Closed: Transfer between Domains Delayed

This message flow diagram illustrates how a GroupWise message travels from one user to another
when the domains are connected by a TCP/IP link and the link is closed.

Figure 3-2 Message Flow When the TCP/IP Link is Closed

wpcsin

1

21

20

2

a

3

POAa

a

4

19

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

MTAa

mslocal

18

0-7

0-7

0-7

wpcsout

ads

45

17

gwinprog

0-7

mshold

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domainx

0-7

0-7

7 15

16

6

MTAb

mslocal

wpcsin

0-7

wpcsout

ads

4

gwinprog

0-7

mshold

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domainx

0-7

0-7

12

11

POAb

b

10

9

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

13

b

0-7

0-7

14

8

30 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Table 3-2 Message Flow When the TCP/IP Link is Closed Stages

Stage Icon Description

Sender

Sender’s
GroupWise
Client

POA for
Sender’s
Post Office

POA for
Sender’s
Post Office

The user sends a message to recipients in a post office in a different domain.

In this diagram, the access mode setting for the local post office is Client/
Server Only.

The GroupWise client communicates the message to the POA by way of TCP/
IP.

The POA receives the message from the GroupWise client and performs the
following actions for the sender:

 Adds the message to the message database (msgnnn.db) assigned to

the sender.

 Creates a pointer in the sender’s user database (userxxx.db) so the

message appears in the sender’s mailbox as a sent item.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates pointers

from the message to its attachments. (For database efficiency,
messages and distribution lists larger than 2 KB are also handled as
attachments.)

 Creates a copy of the message in the appropriate priority 0-7

subdirectory of the MTA input queue in the sender’s post office, in case
the TCP/IP link to the MTA is currently closed.

The POA then communicates the message to the MTA for the sender’s
domain by way of TCP/IP, and deletes the copy in the MTA input queue
because the TCP/IP transfer to the MTA was successful.

To see what would happen if the TCP/IP link to the MTA is closed, see

Section 2.2, “TCP/IP Link Closed: Transfer between Post Offices Delayed,” on
page 22.

MTA for
Sender’s
Domain

MTA for
Sender’s
Domain

MTA for
Recipient’s
Domain

The MTA for the sender’s domain receives the message and places it into the
MTA “in progress” (gwinprog) queue.

The MTA for the sender’s domain then attempts to communicate the message
to the MTA for the recipient’s domain by way of TCP/IP, but the recipient MTA
does not respond. Therefore, the MTA stores the message in its holding
queue for the recipient’s domain in the mshold directory.

When the MTA in the recipient’s domain responds again, the MTA for the
sender’s domain transfers the delayed message from the domain holding
queue to the MTA in the recipient’s domain by way of TCP/IP.

The MTA for the recipient’s domain receives the message and places it into
the MTA “in progress” (gwinprog) queue.

Message Delivery to a Different Domain 31

Stage Icon Description

MTA for
Recipient’s
Domain

POA for
Recipient’s
Post Office

POA for
Recipient’s
Post Office

The MTA for the recipient’s domain then communicates the message to the

POA in the recipient’s post office by way of TCP/IP.

When it receives the new message, the POA for the recipient’s post office

performs the following actions:

 Adds the message to the message database (msgnnn.db)

corresponding to the one assigned to the sender.

 Creates a pointer in the recipient’s user database (userxxx.db) so the

new message appears in the recipient’s mailbox and updates the
notification information in the user database so the recipient can be
notified of the message.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates pointers
from the message to its attachments. (For database efficiency,
messages and distribution lists larger than 2 KB are also handled as
attachments.)

 Creates a Delivered status message in the appropriate priority 0-7

subdirectory of the MTA input queue in the recipient’s post office. It also
communicates the Delivered status message directly to the MTA by way
of TCP/IP and when that transmission is successful, the copy the MTA
input queue is deleted.

The POA for the recipient’s post office communicates to the GroupWise client

by way of TCP/IP that a new message has arrived.

Recipient’s
GroupWise
Client

Recipient

Recipient’s
GroupWise
Client

POA for
Recipient’s
Post Office

MTA for
Recipient’s
Domain

MTA for
Recipient’s
Domain

The Notify component of the recipient’s GroupWise client notifies the recipient
that a new message has arrived.

Each recipient opens the message in the GroupWise client.

Each recipient’s GroupWise client communicates the Opened status message
to the POA by way of TCP/IP.

The POA for the recipient’s post office communicates the status message to
the MTA for the recipient’s domain by way of TCP/IP.

The MTA for the recipient’s domain places the status message into the “in
progress” (gwinprog) queue.

The MTA for the recipient’s domain communicates the status message to the
MTA for the sender’s domain by way of TCP/IP.

32 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

MTA for
Sender’s
Domain

MTA for
Sender’s
Domain

POA for
Sender’s
Post Office

POA for
Sender’s
Post Office

Sender

The MTA for the sender’s domain places the status message into the MTA “in
progress” (gwinprog) queue.

The MTA for the sender’s domain communicates the status message to the
POA for the sender’s post office by way of TCP/IP.

The POA for the sender’s post office updates the sender’s message database
(msgnnn.db) with the Delivered status information (and possibly Opened as
well if the recipient has opened the message).

The POA for the sender’s post office communicates the status to the sender’s
GroupWise client by way of TCP/IP.

When the sender checks the sent items in his or her mailbox in the GroupWise
client, the message displays a status of Delivered for each recipient (and
possibly Opened as well if the recipient has opened the message).

Message Delivery to a Different Domain 33

34 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

4

Message Delivery to and from the Internet

 Section 4.1, “TCP/IP Link: Outbound Transfer to the Internet Successful,” on page 35

 Section 4.2, “TCP/IP Link: Outbound Transfer to the Internet Delayed or Unsuccessful,” on

page 38

 Section 4.3, “Mapped/UNC Link: Outbound Transfer to the Internet Successful,” on page 41

 Section 4.4, “Mapped/UNC Link: Outbound Transfer to the Internet Delayed or Unsuccessful,”

on page 43

 Section 4.5, “TCP/IP Link: Inbound Transfer from the Internet Successful,” on page 47

 Section 4.6, “Mapped/UNC Link: Inbound Transfer from the Internet Successful,” on page 49

4.1 TCP/IP Link: Outbound Transfer to the Internet Successful

This message flow diagram shows how outbound messages travel through the GroupWise®
directory structure to the Internet when there is a TCP/IP link between the MTA and the Internet
Agent and when the Internet Agent can communicate successfully with the Internet host to which
the message is addressed.

4

Figure 4-1 Message Flow When the TCP/IP Link is Open

1

17

16

2

a

3

POA

a

4

15

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

0-7

0-7

MTA

5

mslocal

14

gwinprog

mshold

7

4

13

0-7

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domains

0-7

GWIA

12

8

Destination

Host

6

wpcsin

0-7

wpcsout

ads

0-7

wpgate

gwia

wpcsout

gwid

0-7

send
result
defer
wpcsin

0-7

9

Internet

10

11

Message Delivery to and from the Internet

35

Table 4-1 Message Flow When the TCP/IP Link is Open Stages

Stage Icon Description

Sender

Sender’s
GroupWise
Client

POA for
Sender’s
Post Office

The user sends a message to recipients across the Internet by providing their
Internet addresses.

In this diagram, the access mode setting for the local post office is Client/
Server Only.

The GroupWise client communicates the message to the POA by way of TCP/
IP.

The POA receives the message from the GroupWise client and performs the
following actions for the sender:

 Adds the message to the message database (msgnnn.db) assigned to

the sender.

 Creates a pointer in the sender’s user database (userxxx.db) so the

message appears in the sender’s mailbox as a sent item.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates pointers

from the message to its attachments. (For database efficiency,
messages and distribution lists larger than 2 KB are also handled as
attachments.)

 Creates a copy of the message in the appropriate priority 0-7

subdirectory of the MTA input queue in the sender’s post office, in case
the TCP/IP link to the MTA is currently closed.

POA for
Sender’s
Post Office

MTA for
Sender’s
Domain

MTA for
Sender’s
Domain

MTA for
Sender’s
Domain

Internet
Agent for
Sender’s
Domain

The POA then communicates the message to the MTA for the sender’s
domain by way of TCP/IP, and deletes the copy in the MTA input queue
because the TCP/IP transfer to the MTA was successful.

The MTA for the sender’s domain receives the message and places it into the
MTA “in progress” (gwinprog) queue.

The MTA determines that the message must be sent out across the Internet.
Because there is a TCP/IP link between the MTA and the Internet Agent, the
MTA creates a copy of the message in the appropriate priority 0-7
subdirectory of the Internet Agent hold queue
(mslocal\mshold\gatewayx\0-7), in case the TCP/IP link to the Internet
Agent is currently closed.

The MTA then communicates the message to the Internet Agent for the
sender’s domain by way of TCP/IP, and deletes the copy in the Internet Agent
holding queue because the TCP/IP transfer to the Internet Agent was
successful.

The Internet Agent receives the message and places it into the MTA output
queue (wpcsout\gwid\0-7) on behalf of the MTA. The MTA output queue is
the Internet Agent input queue.

36 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

The Internet Agent scans its input queues according to the Idle Sleep Duration
Internet
Agent for
Sender’s
Domain

setting on the Gateway Time Settings page of the Internet Agent object in

ConsoleOne

from the wpcsout\gwid\0-7 directory and converts it.

The Internet Agent encodes the message in MIME format with the appropriate

encoding scheme.

When the message file is built, the Internet Agent saves it with S as the first

character of the filename and places the message file in the

domain\wpgate\gwia\send directory for processing.

While the Internet Agent is processing the message file in the send directory, it
Internet
Agent for
Sender’s

changes the first character of the filename to P. When processing is

completed, the Internet Agent sends the message to the destination host

across the Internet.
Domain

If the Internet Agent receives a 250 OK SMTP reply code from the destination
Internet
Agent for
Sender’s

Internet host, it places a Transferred status message into the input queue of

the MTA for the sender’s domain in case the TCP/IP link to the Internet Agent

is currently closed.
Domain

The Internet Agent then communicates the Transferred status message to the
Internet
Agent for

MTA for the sender’s domain by way of TCP/IP, and deletes the copy in the

MTA input queue because the TCP/IP transfer to the MTA was successful.
Sender’s
Domain

®

. The Internet Agent picks up the file in binary-encrypted format

MTA for
Sender’s
Domain

MTA for
Sender’s
Domain

POA for
Sender’s
Post Office

POA for
Sender’s
Post Office

Sender

The MTA for the sender’s domain receives the Transferred status message

and places it into the MTA “in progress” (gwinprog) queue for processing.

The MTA for the sender’s domain communicates the Transferred status

message to the POA for the sender’s post office by way of TCP/IP.

The POA for the sender’s post office updates the sender’s message database

(msgnnn.db) with the Transferred status information.

The POA for the sender’s post office communicates the Transferred status to

the sender’s GroupWise client by way of TCP/IP.

When the sender checks the sent items in his or her mailbox in the GroupWise

client, the message displays the Transferred status because the Internet

Agent was able to sent it successfully.

Message Delivery to and from the Internet 37

4.2 TCP/IP Link: Outbound Transfer to the Internet Delayed or Unsuccessful

This message flow diagram shows how outbound messages travel through the GroupWise directory
structure to the Internet when there is a TCP/IP link between the MTA and the Internet Agent and
when the Internet Agent cannot communicate successfully with the Internet host to which the
message is addressed.

Figure 4-2 Message Flow When the TCP/IP Link is Closed

1

20

19

2

a

Table 4-2 Message Flow When the TCP/IP Link is Closed Stages

3

4 15

POA

a

18

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

0-7

0-7

5

17

MTA

mslocal

gwinprog

mshold

7

16

0-7

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domains

0-7

GWIA

8

Destination

Host

6

wpcsin

0-7

wpcsout

ads

0-7

wpgate

gwia

wpcsout

gwid

0-7

send

13

result

defer

wpcsin

0-7

9

11

12

14

Internet

10

Stage Icon Description

Sender

The user sends a message to recipients across the Internet by providing their
Internet addresses.

In this diagram, the access mode setting for the local post office is Client/
Server Only.

Sender’s

The GroupWise client communicates the message to the POA by way of TCP/

IP.
GroupWise
Client

38 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

POA for
Sender’s
Post Office

POA for
Sender’s
Post Office

MTA for
Sender’s
Domain

MTA for
Sender’s
Domain

The POA receives the message from the GroupWise client and performs the
following actions for the sender:

 Adds the message to the message database (msgnnn.db) assigned to

the sender.

 Creates a pointer in the sender’s user database (userxxx.db) so the

message appears in the sender’s mailbox as a sent item.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates pointers

from the message to its attachments. (For database efficiency,
messages and distribution lists larger than 2 KB are also handled as
attachments.)

 Creates a copy of the message in the appropriate priority 0-7

subdirectory of the MTA input queue in the sender’s post office, in case
the TCP/IP link to the MTA is currently closed.

The POA then communicates the message to the MTA for the sender’s
domain by way of TCP/IP, and deletes the copy in the MTA input queue
because the TCP/IP transfer to the MTA was successful.

The MTA for the sender’s domain receives the message and places it into the
MTA “in progress” (gwinprog) queue.

The MTA determines that the message must be sent out across the Internet.
Because there is a TCP/IP link between the MTA and the Internet Agent, the
MTA creates a copy of the message in the appropriate priority 0-7
subdirectory of the Internet Agent hold queue
(mslocal\mshold\gatewayx\0-7), in case the TCP/IP link to the Internet
Agent is currently closed.

MTA for
Sender’s
Domain

Internet
Agent for
Sender’s
Domain

Internet
Agent for
Sender’s
Domain

The MTA then communicates the message to the Internet Agent for the
sender’s domain by way of TCP/IP, and deletes the copy in the Internet Agent
holding queue because the TCP/IP transfer to the Internet Agent was
successful.

The Internet Agent receives the message and places it into the MTA output
queue (wpcsout\gwid\0-7) on behalf of the MTA. The MTA output queue is
the Internet Agent input queue.

The Internet Agent scans its input queues according to the Idle Sleep Duration
setting on the Gateway Time Settings page of the Internet Agent object in
ConsoleOne. The Internet Agent picks up the file in binary-encrypted format
from the wpcsout\gwid\0-7 directory and converts it.

The Internet Agent encodes the message in MIME format with the appropriate
encoding scheme.

When the message file is built, the Internet Agent saves it with S as the first
character of the filename and places the message file in the

domain\wpgate\gwia\send directory for processing.

Message Delivery to and from the Internet 39

Stage Icon Description

While the Internet Agent is processing the message file in the send directory, it
Internet
Agent for
Sender’s

changes the first character of the filename to P. When processing is

completed, the Internet Agent sends the message to the destination host

across the Internet.
Domain

If the Internet Agent does not receive a 250 OK SMTP reply code from the
Internet
Agent for
Sender’s
Domain

destination Internet host, the Internet Agent renames the P*.* message file

back to S*.* and creates a file named R*.* that records the SMTP reply

codes (error messages) in the wpgate\gwia\result directory. After the

Internet Agent completes the communication with the destination host, it

moves the S*.* message file from the send directory to the result directory

along with the corresponding R*.* file.

The Internet Agent analyzes the files in the result directory, comparing the
Internet
Agent for
Sender’s
Domain

SMTP reply codes in the R*.* file.

If the R*.* file has a temporary transmission error (meaning it has a 400-level

SMTP reply code such as 450 Host Down), the Internet Agent moves the

S*.* message file to the defer directory. Continue with Stage

If the R*.* file has a fatal error (meaning it has a 500-level SMTP reply code

such as 550 Host Unknown), the Internet Agent deletes the S*.* file because

it is undeliverable. Skip to Stage

Based on the Intervals to the Retry a Deferred Message setting on the SMTP/
Internet
Agent for
Sender’s

MIME Settings property page of the Internet Agent object in ConsoleOne, the

Internet Agent requeues the S *.* message file back into the send directory

for reprocessing.
Domain

Internet
Agent for
Sender’s
Domain

Internet
Agent for
Sender’s
Domain

MTA for
Sender’s
Domain

MTA for
Sender’s
Domain

After an S*.* message receives 400-level SMTP reply codes until the

Maximum Number of Hours to Retry a Deferred Message setting is reached,

or if a message receives 500-level SMTP reply codes, the Internet Agent

deletes all related schedule files from the defer directory because the

message is undeliverable. The Internet Agent then creates an Undeliverable

status message in the MTA input queue (wpgate\gwia\wpcsin\0-7) in

case the TCP/IP link to the MTA is currently closed.

The Internet Agent then communicates the Transferred status message to the

MTA for the sender’s domain by way of TCP/IP, and deletes the copy in the

MTA input queue because the TCP/IP transfer to the MTA was successful.

The MTA for the sender’s domain receives the Transferred status message

and places it into the MTA “in progress” (gwinprog) queue for processing.

The MTA for the sender’s domain communicates the Transferred status

message to the POA for the sender’s post office by way of TCP/IP.

40 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

POA for

The POA for the sender’s post office updates the sender’s message database

(msgnnn.db) with the Transferred status information.
Sender’s
Post Office

The POA for the sender’s post office communicates the Transferred status to
POA for

the sender’s GroupWise client by way of TCP/IP.
Sender’s
Post Office

When the sender checks the sent items in his or her mailbox in the GroupWise
Sender

client, the message displays the Transferred status because the Internet

Agent was able to send it successfully.

4.3 Mapped/UNC Link: Outbound Transfer to the Internet Successful

This message flow diagram shows how outbound messages travel through the GroupWise directory
structure to the Internet when there is a mapped/UNC link between the MTA and the Internet Agent
and when the Internet Agent can communicate successfully with the Internet host to which the
message is addressed.

Figure 4-3 Message Flow When the Mapped Link is Open

1

14

POA

a

4

12

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

0-7

0-7

13

2

a

3

MTA

5

mslocal

11

gwinprog

0-7

mshold

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domains

0-7

10

6

GWIA

wpcsin

0-7

wpcsout

ads

wpgate

gwia

wpcsout

send
result
defer
wpcsin

0-7

gwid

0-7

0-7

Destination

Host

Internet

7

8

9

Message Delivery to and from the Internet 41

Table 4-3 Message Flow When the Mapped Link is Open Stages

Stage Icon Description

Sender

Sender’s
GroupWise
Client

POA for
Sender’s
Post Office

The user sends a message to recipients across the Internet by providing their
Internet addresses.

In this diagram, the access mode setting for the local post office is Client/
Server Only.

The GroupWise client communicates the message to the POA by way of TCP/
IP.

The POA receives the message from the GroupWise client and performs the
following actions for the sender:

 Adds the message to the message database (msgnnn.db) assigned to

the sender.

 Creates a pointer in the sender’s user database (userxxx.db) so the

message appears in the sender’s mailbox as a sent item.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates pointers

from the message to its attachments. (For database efficiency,
messages and distribution lists larger than 2 KB are also handled as
attachments.)

 Creates a copy of the message in the appropriate priority 0-7

subdirectory of the MTA input queue in the sender’s post office, in case
the TCP/IP link to the MTA is currently closed.

POA for
Sender’s
Post Office

MTA for
Sender’s
Domain

MTA for
Sender’s
Domain

Internet
Agent for
Sender’s
Domain

The POA then communicates the message to the MTA for the sender’s
domain by way of TCP/IP, and deletes the copy in the MTA input queue
because the TCP/IP transfer to the MTA was successful.

The MTA for the sender’s domain receives the message and places it into the
MTA “in progress” (gwinprog) queue.

The MTA determines that the message must be sent out across the Internet.
Because there is a mapped/UNC link between the MTA and the Internet
Agent, the MTA places the message in its output queue in the Internet Agent’s
gateway directory (domain\wpgate\gwia\wpcsout\gwid\0-7).

The Internet Agent scans its input queues according to the Idle Sleep Duration
setting on the Gateway Time Settings page of the Internet Agent object in
ConsoleOne. The Internet Agent picks up the file in binary-encrypted format
from the wpcsout\gwid\0-7 directory and converts it.

The Internet Agent encodes the message in MIME format with the appropriate
encoding scheme.

When the message file is built, the Internet Agent saves it with S as the first
character of the filename and places the message file in the

domain\wpgate\gwia\send directory for processing.

42 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

Internet
Agent for
Sender’s
Domain

Internet
Agent for
Sender’s
Domain

MTA for
Sender’s
Domain

MTA for
Sender’s
Domain

POA for
Sender’s
Post Office

While the Internet Agent is processing the message file in the send directory, it

changes the first character of the filename to P. When processing is

completed, the Internet Agent sends the message to the destination host

across the Internet.

If the Internet Agent receives a 250 OK SMTP reply code from the destination

Internet host, it places a Transferred status message into the input queue of

the MTA for the sender’s domain.

Because of its mapped/UNC link with the Internet Agent, the MTA regularly

scans its input queue in the Internet Agent’s gateway directory based on the

Scan Cycle setting on the Agent Settings page of the MTA object in

ConsoleOne. It picks up the Transferred status messages and transfers them

to its “in progress“ (gwinprog) directory for processing.

The MTA for the sender’s domain communicates the Transferred status

messages to the POA for the sender’s post office by way of TCP/IP.

The POA for the sender’s post office updates the sender’s message database

(msgnnn.db) with the Transferred status information.

POA for
Sender’s
Post Office

Sender

The POA for the sender’s post office communicates the Transferred status to

the sender’s GroupWise client by way of TCP/IP.

When the sender checks the sent items in his or her mailbox in the GroupWise

client, the message displays the Transferred status because the Internet

Agent was able to sent it successfully.

4.4 Mapped/UNC Link: Outbound Transfer to the Internet Delayed or Unsuccessful

This message flow diagram shows how outbound messages travel through the GroupWise directory
structure to the Internet when there is a mapped/UNC link between the MTA and the Internet Agent

Message Delivery to and from the Internet 43

and when the Internet Agent cannot communicate successfully with the Internet host to which the
message is addressed.

Figure 4-4 Message Flow When the Mapped Link is Closed

1

17

POA

a

4

15

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

0-7

0-7

16

2

a

Table 4-4 Message Flow When the Mapped Link is Closed Stages

3

MTA

5

mslocal

14

gwinprog

0-7

mshold

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domains

0-7

6

13

GWIA

11

wpcsin

0-7

wpcsout

ads

wpgate

gwia

wpcsout

send

result

defer

wpcsin

0-7

gwid

0-7

0-7

Destination

Host

Internet

8

7

9

10

12

Stage Icon Description

Sender

The user sends a message to recipients across the Internet by providing their
Internet addresses.

In this diagram, the access mode setting for the local post office is Client/
Server Only.

Sender’s

The GroupWise client communicates the message to the POA by way of TCP/

IP.
GroupWise
Client

44 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

POA for
Sender’s
Post Office

POA for
Sender’s
Post Office

MTA for
Sender’s
Domain

MTA for
Sender’s
Domain

The POA receives the message from the GroupWise client and performs the
following actions for the sender:

 Adds the message to the message database (msgnnn.db) assigned to

the sender.

 Creates a pointer in the sender’s user database (userxxx.db) so the

message appears in the sender’s mailbox as a sent item.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates pointers

from the message to its attachments. (For database efficiency,
messages and distribution lists larger than 2 KB are also handled as
attachments.)

 Creates a copy of the message in the appropriate priority 0-7

subdirectory of the MTA input queue in the sender’s post office, in case
the TCP/IP link to the MTA is currently closed.

The POA then communicates the message to the MTA for the sender’s
domain by way of TCP/IP, and deletes the copy in the MTA input queue
because the TCP/IP transfer to the MTA was successful.

The MTA for the sender’s domain receives the message and places it into the
MTA “in progress” (gwinprog) queue.

The MTA determines that the message must be sent out across the Internet.
Because there is a mapped/UNC link between the MTA and the Internet
Agent, the MTA places the message in its output queue in the Internet Agent’s
gateway directory (domain\wpgate\gwia\wpcsout\gwid\0-7).

Internet
Agent for
Sender’s
Domain

Internet
Agent for
Sender’s
Domain

Internet
Agent for
Sender’s
Domain

The Internet Agent scans its input queues according to the Idle Sleep Duration
setting on the Gateway Time Settings page of the Internet Agent object in
ConsoleOne. The Internet Agent picks up the file in binary-encrypted format
from the wpcsout\gwid\0-7 directory and converts it.

The Internet Agent encodes the message in MIME format with the appropriate
encoding scheme.

When the message file is built, the Internet Agent saves it with S as the first
character of the filename and places the message file in the

domain\wpgate\gwia\send directory for processing.

While the Internet Agent is processing the message file in the send directory, it
changes the first character of the filename to P. When processing is
completed, the Internet Agent sends the message to the destination host
across the Internet.

If the Internet Agent does not receive a 250 OK SMTP reply code from the
destination Internet host, the Internet Agent renames the P*.* message file
back to S*.* and creates a file named R*.* that records the SMTP reply
codes (error messages) in the wpgate\gwia\result directory. After the
Internet Agent completes the communication with the destination host, it
moves the S*.* message file from the send directory to the result directory
along with the corresponding R*.* file.

Message Delivery to and from the Internet 45

Stage Icon Description

The Internet Agent analyzes the files in the result directory, comparing the
Internet
Agent for
Sender’s
Domain

SMTP reply codes in the R*.* file.

If the R*.* file has a temporary transmission error (meaning it has a 400-level

SMTP reply code such as 450 Host Down), the Internet Agent moves the

S*.* message file to the defer directory. Continue with Stage

If the R*.* file has a fatal error (meaning it has a 500-level SMTP reply code

such as 550 Host Unknown), the Internet Agent deletes the S*.* file because

it is undeliverable. Skip to Stage

Based on the Intervals to the Retry a Deferred Message setting on the SMTP/
Internet
Agent for
Sender’s

MIME Settings property page of the Internet Agent object in ConsoleOne, the

Internet Agent requeues the S *.* message file back into the send directory

for reprocessing.
Domain

After an S*.* message receives 400-level SMTP reply codes until the
Internet
Agent for
Sender’s
Domain

Maximum Number of Hours to Retry a Deferred Message setting is reached,

or if a message receives 500-level SMTP reply codes, the Internet Agent

deletes all related schedule files from the defer directory because the

message is undeliverable. The Internet Agent then creates an Undeliverable

status message for the MTA to pick up and return to the sender.

Because of its mapped/UNC link with the Internet Agent, the MTA scans its
MTA for
Sender’s
Domain

input queue in the Internet Agent’s gateway directory based on the Scan Cycle

setting on the Agent Settings page of the MTA object in ConsoleOne. The

MTA picks up the Undeliverable status messages and transfers them to its “in

progress“ (gwinprog) directory for processing.

MTA for
Sender’s
Domain

POA for
Sender’s
Post Office

POA for
Sender’s
Post Office

Sender

The MTA for the sender’s domain communicates the Transferred status

messages to the POA for the sender’s post office by way of TCP/IP.

The POA for the sender’s post office updates the sender’s message database

(msgnnn.db) with the Transferred status information.

The POA for the sender’s post office communicates the Transferred status to

the sender’s GroupWise client by way of TCP/IP.

When the sender checks the sent items in his or her mailbox in the GroupWise

client, the message displays the Transferred status because the Internet

Agent was able to send it successfully.

46 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

4.5 TCP/IP Link: Inbound Transfer from the Internet Successful

This message flow diagram illustrates how inbound message flow from the Internet through the
GroupWise directory structure to the GroupWise recipient. The link between the Internet Agent and
the MTA for the recipient’s domain is a TCP/IP link.

Figure 4-5 Message Flow in From the Internet

1

GWIA

2

3

wpgate

gwia

wpcsout

recieve
wpcsin

0-7

Destination

Host

Internet

Table 4-5 Message Flow in From the Internet Stages

Stage Actor Action

MTA

mslocal

4

gwinprog

0-7

mshold

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domains

0-7

9

8

7

POA

b

5

6

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

0-7

0-7

b

Internet
Agent for
Recipient’s
Domain

Internet
Agent for
Recipient’s
Domain

An Internet user sends a message to a GroupWise user. The Internet Agent
receives the message from the external Internet host and places the
message file in the wpgate\gwia\receive directory.

The Internet Agent polls the receive directory according to the Idle Sleep

Duration setting on the Gateway Time Settings page of the Internet Agent

object in ConsoleOne. It picks up the message file, converts it to
GroupWise format, and places a copy in the wpgate\gwia\wpcsin\0-7
directory, where 0-7 is one of the priority subdirectories from 0-7. The
Internet Agent puts messages only in the 4 directory, used for normal
priority messages.

Message Delivery to and from the Internet 47

Stage Actor Action

Internet
Agent for
Recipient’s
Domain

MTA for
Recipient’s
Domain

MTA for
Recipient’s
Domain

MTA for
Recipient’s
Domain

POA for
Recipient’s
Post Office

The Internet Agent then communicates the message to the MTA for the

recipient’s domain by way of TCP/IP. When the transmission is successful,

it deletes the copy in the in the wpgate\gwia\wpcsin\0-7 directory.

The MTA for the recipient’s domain receives the message and places it into

the MTA “in progress” (gwinprog) queue.

The MTA determines which post office in the domain the recipient is located

in, then moves the message to that post office’s hold queue

(mslocal\mshold\postx\0-7).

The MTA for the recipient’s domain then communicates the message to the

POA in the recipient’s post office by way of TCP/IP.

When it receives the new message, the POA for the recipient’s post office

performs the following actions:

 Adds the message to the message database (msgnnn.db file)

corresponding to the one assigned to the sender.

 Creates a pointer in the recipient’s user database (userxxx.db file),

so the message appears in the recipient’s Mailbox and updates the
notification information in the user database so the recipient can be
notified of the message.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates

pointers from the message to its attachments. (For database
efficiency, messages and recipient lists larger than 2 KB are also
handled as attachments.)

The Notify component of the recipient’s GroupWise client notifies the
Recipient’s
GroupWise
Client

Recipient

recipient that a new message has arrived.

Each recipient opens the message in the GroupWise client.

48 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

4.6 Mapped/UNC Link: Inbound Transfer from the Internet Successful

This message flow diagram illustrates how inbound message flow from the Internet through the
GroupWise directory structure to the GroupWise recipient. The link between the Internet Agent and
the MTA for the recipient’s domain is a mapped/UNC link.

Figure 4-6 Message Flow in From the Internet

Destination

Host

Internet

1

Table 4-6 Message Flow in From the Internet Stages

Stage Actor Action

2

wpgate

gwia

wpcsout

recieve
wpcsin

0-7

MTA

mslocal

3

gwinprog

0-7

mshold

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domains

0-7

8

7

6

POA

b

4

5

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

0-7

0-7

b

Internet
Agent for
Recipient’s
Domain

Internet
Agent for
Recipient’s
Domain

MTA for
Recipient’s
Domain

An Internet user sends a message to a GroupWise user. The Internet Agent
receives the message from the external Internet host and places the
message file in the wpgate\gwia\receive directory.

The Internet Agent polls the receive directory according to the Idle Sleep

Duration setting on the Gateway Time Settings page of the Internet Agent

object in ConsoleOne. It picks up the message file, converts it to
GroupWise format, and places it in the wpgate\gwia\wpcsin\0-7
directory, where 0-7 is one of the priority subdirectories from 0-7. The
Internet Agent puts messages only in the 4 directory, used for normal
priority messages.

The MTA polls the domain\wpgate\gwia\wpcsin\fd0-7F directory
based on the Scan Cycle setting on the Agent Settings page of the MTA
object in ConsoleOne. It picks up the message file and moves it to its “in
progress” (gwinprog) queue.

Message Delivery to and from the Internet 49

Stage Actor Action

MTA for
Recipient’s
Domain

MTA for
Recipient’s
Domain

POA for
Recipient’s
Post Office

Recipient’s
GroupWise
Client

The MTA determines which post office in the domain the recipient is located

in, then moves the message to that post office’s hold queue

(mslocal\mshold\postx\0-7).

The MTA for the recipient’s domain then communicates the message to the

POA in the recipient’s post office by way of TCP/IP.

When it receives the new message, the POA for the recipient’s post office

performs the following actions:

 Adds the message to the message database (msgnnn.db file)

corresponding to the one assigned to the sender.

 Creates a pointer in the recipient’s user database (userxxx.db file),

so the message appears in the recipient’s Mailbox and updates the
notification information in the user database so the recipient can be
notified of the message.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories and creates

pointers from the message to its attachments. (For database
efficiency, messages and recipient lists larger than 2 KB are also
handled as attachments.)

The Notify component of the recipient’s GroupWise client notifies the

recipient that a new message has arrived.

Recipient

Each recipient opens the message in the GroupWise client.

50 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

5

Message Delivery through a Modem Connection

GroupWise® client users can still access information in their mailboxes even when not connected to
the network by running the GroupWise client in Remote mode.

 Section 5.1, ““Hit the Road” Process in Online Mode,” on page 51

 Section 5.2, “Modem Link through the Async Gateway in Remote Mode,” on page 53

5.1 “Hit the Road” Process in Online Mode

This message flow diagram illustrates how a user who will be away from the network prepares to
access GroupWise from a remote location by downloading mailbox contents.

Figure 5-1 Message Flow for Hit the Road

6

1

5

2

a

rofdata

msg.db
user.db

wprof.db

wpcsin

l

4

POA

3

b

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

0-7

ofs

0-7

5

Table 5-1 Message Flow for Hit the Road Stages

Stage Icon Description

Remote
User

The GroupWise user runs Hit the Road in Online mode in order to request
items from the master mailbox to be downloaded to the Remote mailbox in
preparation for disconnecting from the master GroupWise system. For
example, the user could be preparing a laptop computer for use away from the
network.

Message Delivery through a Modem Connection

51

Stage Icon Description

GroupWise
Client in
Online
Mode

POA for
Remote
User’s
Post Office

POA for
Remote
User’s
Post Office

GroupWise
Client in
Online
Mode

The GroupWise client prompts the user for the location to create the Remote
mailbox and the types of items to download, then it transfers the request to the
POA.

The POA receives the request from the GroupWise client and performs the
following actions:

 Gathers all folders from the GroupWise user’s master mailbox

(msgnnn.db and userxxx.db) so that it has somewhere to put the
items requested by the user.

 Gathers the requested items from the GroupWise user’s master mailbox.

 Gathers any attachments for requested items from the

post_office\offiles\fd0-F6 subdirectories in the GroupWise

user’s post office.

 Gathers any other types of information requested by the GroupWise user,

such as rules, address books, documents, and junk mail lists.

The POA compiles the information into a response file and transfers the
response to the GroupWise client.

The GroupWise client receives the response and performs the following
actions for the GroupWise user:

 Updates the GroupWise Remote message database (msg.db) with any

items requested from the user’s master mailbox.

 Creates pointers in the GroupWise Remote user database (user.db) so

the messages gathered from the master mailbox appear in the user’s
GroupWise mailbox when running in Remote mode.

 Places any requested attachments larger than 2 KB in the rofdata

directory and creates pointers from the message to its attachments. (For
database efficiency, messages and distribution lists larger than 2 KB are
also handled as attachments.)

 Updates the Remote mailbox with any other types of information

requested by the GroupWise user.

The user’s GroupWise Remote mailbox now contains current copies of
requested items from the user’s master mailbox.

Remote
User

The GroupWise client restarts in Remote mode and accesses the new Remote
mailbox. The GroupWise user can now review current GroupWise mail in
Remote mode after the connection to the master GroupWise system is no
longer available.

52 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

5.2 Modem Link through the Async Gateway in Remote Mode

This message flow diagram illustrates how a GroupWise user in Remote mode can access the master
GroupWise system through the GroupWise Async Gateway.

Figure 5-2 Message Flow Through a Modem

1

19

2

rofdata

msg.db
user.db
wprof.db

wpcsin

l

wpcsout

3

ofs

l
wpgwsend
wpgwrecv

4

18

17

wpcsin

wpcsout

wpgate

5

16

0-7

ads

0-7

async

asyxxx

gwin

gwout

wpcsin

wpcsout

7

14

connection-id

cmp

connection-id

cmp

1-3

0-7

1-7

MTA

8 12

mslocal

gwinprog

6

13

15

0-7

mshold

domainms

posta

0-7

postb

0-7

gatewayx

0-7

domains

0-7

11

9

POA

b

10

wpcsin

0-7

ofmsg

msgnnn.db

ofuser

userxxx.db

offiles

fdo-7f

wpcsout

ads

ofs

0-7

0-7

Table 5-2 Message Flow Through a Modem Stages

Stage Icon Description

Remote
User

The GroupWise user, who is working in Remote mode, sends a message to
another GroupWise user or creates a request for items from the master
mailbox. The remote user’s computer is not currently connected to the
network or the user’s master GroupWise system.

Message Delivery through a Modem Connection 53

Stage Icon Description

GroupWise
Client in
Remote
Mode

GroupWise
Client in
Remote
Mode

When the remote GroupWise user sends a message to another GroupWise
user, the GroupWise client performs the following actions in the user’s
Remote mailbox:

 Adds the message to the message database (msg.db) on the user’s

remote computer.

 Creates a pointer in the user database (user.db) so the message

appears as a sent item in the Remote mailbox on the user’s remote
computer.

 Places attachments larger than 2 KB in the rofdata directory and

creates pointers from the message to its attachments on the user’s
remote computer. (For database efficiency, messages and distribution
lists larger than 2 KB are also handled as attachments.)

 Creates a copy of the message in the wpcsin\1 subdirectory of the

GroupWise client’s remote input queue on the user’s remote computer.

When the remote GroupWise user sends a request for items from the
master mailbox to be downloaded to the Remote mailbox, the GroupWise
client places the request in the wpcsin\1 subdirectory of the GroupWise
client’s remote input queue on the user’s remote computer.

When the remote GroupWise user initiates the modem connection, the
GroupWise client polls its input queue (wpcsin\1) and compresses the
outgoing messages and/or requests into a file. If the compressed file totals
over 50 KB, additional compressed files are created.

The GroupWise client moves the compressed message/request files into its
output queue (wpgwsend) directory.

:
GroupWise
Client with
Modem
Connection

Async
Gateway

Async
Gateway

Async
Gateway

MTA for
Remote
User’s
Domain

The GroupWise client dials in to the gateway, logs in, then transmits the
compressed message/request files across the modem connection to the
GroupWise Async Gateway in the GroupWise system where the user’s
master mailbox is located.

The GroupWise Async Gateway receives the message/request files and
places them into it input queue
(wpgate\async\asyxxx\gwin\connection_id\cmp) for processing.

The Async Gateway decompresses the message/request files and moves
them into the subdirectory for the remote user’s connection with the master
GroupWise system.

WIth a TCP/IP link, the Async Gateway transfers the decompressed files to
the MTA for the remote user’s domain in the master GroupWise system.

With a UNC/mapped link, the Async Gateway places the message/request
files into the MTA’s input queue (wpgate\async\wpcsin\1), where the
MTA picks up the files.

The MTA for the remote user’s domain receives the message/request files
and places them into the MTA “in progress” (gwinprog) queue.

54 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

MTA for
Remote
User’s
Domain

POA for
Remote
User’s
Post Office

The MTA for the remote user’s domain then communicates the message/
request files to the POA for the post office where the remote user’s master
mailbox is located.

NOTE: This message flow diagram illustrates only the simplest case where
the recipient is in the same post office as the remote user’s master mailbox.
If the remote user sends a message to a user in any other post office, the
MTA routes the message to the appropriate destination.

When the POA receives a message from the remote user, the POA
performs the following actions to update the remote user’s master mailbox:

 Adds the message to the remote user’s message database

(msgnnn.db) in the Online mailbox.

 Creates a pointer in the recipient’s user database (userxxx.db) in the

Online mailbox so that the new message appears in the recipient’s
mailbox and updates the notification information in the user database
so the recipient can be notified of the message.

 Places attachments larger than 2 KB in one of the

post_office\offiles\fd0-F6 subdirectories in the remote user’s

post office and creates pointers from the message to its attachments.
(For database efficiency, messages and distribution lists larger than 2
KB are also handled as attachments.)

 Creates a Delivered status message in the priority 1 subdirectory of the

remote user’s MTA input queue (wpcsin) in the post office.

POA for
Remote
User’s
Post Office

MTA in
Remote
User’s
Domain

When the POA receives a request for items from the remote user’s master
mailbox, the POA performs the following actions:

 Gathers the requested items from the remote user’s master mailbox

(msgnnn.db).

 Gathers any attachments for requested items from the

post_office\offiles\fd0-F6 subdirectory in the remote user’s
post office.

 Compiles the information into a response file and places it in the

priority 1 subdirectory of the MTA input queue for return to the remote
user.

The POA for the remote user’s post office communicates the Delivered
status for messages and the response file for requests to the MTA for the
remote user’s domain. When the transfer is successful, the copies in the
MTA input queue are deleted.

The MTA for the remote user’s domain places the status/response files into
the MTA “in progress” (gwinprog) queue.

Message Delivery through a Modem Connection 55

Stage Icon Description

MTA in
Remote
User’s
Domain

Async
Gateway

Async
Gateway

Async
Gateway
with Modem
Connection

With a TCP/IP link, the MTA for the remote user’s domain communicates the
status/response files to the Async Gateway in the remote user’s domain.

With a UNC/mapped link, the MTA for the remote user’s domain places the
status/response files into the Async Gateway’s input queue
(wpgate\async\asyxxx\wpcsout\1), where the Async Gateway picks
up the files.

When the MTA in the GroupWise Remote user’s domain detects the
response for the GroupWise Remote user, the MTA picks it up from its post
office input queue and transfers it to its output queue in the Async Gateway
directory under wpgate in the GroupWise Remote user’s domain. The MTA
output queue in the Async Gateway directory is the input queue for the
Async Gateway.

The Async Gateway places the status/response files into the MTA output
queue (wpgate\async\wpcsout\asyxxx\connection_id\1) of the
Async Gateway directory.

If the modem connection to the remote user is still active, the Async
Gateway compresses the status/response files and moves them to the cmp
directory.

If the modem connection is no longer available, the status/response files
wait in the connection_id\1 subdirectory until a new connection is
established by the remote user.

The Async Gateway transmits the status/response files through the modem
connection to the input queue (wpgwrecv) for the GroupWise client on the
user’s remote computer.

GroupWise
Client in
Remote
Mode

GroupWise
Client in
Remote
Mode

The GroupWise client on the remote computer decompresses the status/
response files and places them in its input queue (wpcsout\ofs\1) on the
user’s remote computer.

Taking the items from its input queue, the GroupWise client performs the
following actions to update the Remote mailbox on the user’s remote
computer:

 Updates the message database (msg.db) with any items requested

from the remote user’s master mailbox.

 Creates pointers in the user database (user.db) so the messages

gathered from the master mailbox appear in the Remote mailbox.

 Places any requested attachments larger than 2 KB in the rofdata

directory and creates pointers from the message to its attachments.
(For database efficiency, messages and distribution lists larger than 2
KB are also handled as attachments.)

 Updates the remote Address Book (wprof.db) to synchronize it with

the Address Book in the remote user’s master GroupWise system.

The user’s Remote mailbox now contains current copies of requested items
from the remote user’s master mailbox, plus any messages received in the
user’s master mailbox from other GroupWise users.

56 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Stage Icon Description

Remote
User

The GroupWise user can now review current GroupWise mail when the
modem connection to the master GroupWise system is no longer available.

Message Delivery through a Modem Connection 57

58 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

6

Administrative Database Update

ConsoleOne® and the agents handle database updates throughout the GroupWise® system.

This message flow diagram illustrates how an administrative message, such as a database update
request, passes from ConsoleOne to the agents so that databases are updated throughout the
GroupWise system.

Figure 6-1 Administrative Message Flow through TCP/IP

1

2

MTAb

6

wpdomain.db
wpcsin

0-7

wpcsout

ads

MTAa

3

mslocal

gwinprog

mshold

Table 6-1 Administrative Message Flow through TCP/IP Stages

Stage Actor Action

GroupWise
Administrator

0-7

4

4

0-7

6

domainms

postx

0-7

gatewayx

0-7

domainx

0-7

The administrator uses the GroupWise Administrator snap-in in ConsoleOne
to add, modify, or delete a GroupWise object in a single-domain, single-post
office GroupWise system.

wpcsin

wpcsout

wphost.db

POA

0-7

ads

ofs

0-7

0-7

5

An object could be a GroupWise user, resource, distribution list, post office,
secondary domain, and so on.

Administrative Database Update

59

Stage Actor Action

ConsoleOne

MTA for
Domain

POA for
Post Office

POA for
Post Office

ConsoleOne performs the following actions:

 Updates the domain database (wpdomain.db) to reflect the addition,

modification, or deletion performed in ConsoleOne.

 Creates an administrative message in the priority 2 subdirectory of the

domain’s MTA input queue (wpcsin) to replicate the update.

The MTA for the domain transfers the administrative message to the MTA “in
progress” (gwinprog) queue. From there, the MTA communicates the
administrative message to the POA in the post office by way of TCP/IP. The
administrative message notifies the POA that a GroupWise object has been
added, modified, or deleted.

Historical Note: In earlier versions of GroupWise, this function of the POA was
handled by a separate agent, the Administration Agent (ADA). The ADA no
longer exists in GroupWise.

The POA creates a copy of the administrative message in the priority 2
subdirectory of the administrative input queue (wpcsout\ads) in the post
office. After the update is made successfully, the copy is deleted.

The POA updates the post office database (wphost.db) to reflect the
addition, modification, or deletion performed in ConsoleOne and deletes the
administrative message from its administrative input queue.

60 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

II

Directory Structure Diagrams

II

This part of Troubleshooting 3: Message Flow and Directory Structure helps you understand the
structure of GroupWise
and software installation directories.

 Chapter 7, “Message Transfer/Storage Directories,” on page 63

 Chapter 8, “Agent Installation Directories,” on page 103

 Chapter 9, “Software Distribution Directory,” on page 147

 Chapter 10, “GroupWise Client Installation Directories,” on page 163

®

message transfer/storage directories (such as domains and post offices)

Directory Structure Diagrams

61

62 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

7

Message Transfer/Storage Directories

Message transfer and storage directories are the locations through which messages pass as they
travel from user to user through your GroupWise

 Section 7.1, “Domain Directory,” on page 63

 Section 7.2, “Post Office Directory,” on page 70

 Section 7.3, “MTA Local Queue Directory,” on page 82

 Section 7.4, “Internet Agent Queue Directory,” on page 85

 Section 7.5, “WebAccess Agent Queue Directory,” on page 92

 Section 7.6, “Caching Mailbox Directory,” on page 94

 Section 7.7, “Remote Mailbox Directory,” on page 98

7.1 Domain Directory

domain Domain directory

mslocal MTA local working directory

®

system.

7

wpcsin

0
1
2
3
4
5
6
7

wptools Supporting program directory

wpgate GroupWise gateway directory

wpcsout MTA output queue directory

ads

0
1
2
3
4
5
6
7

MTA input queue directory
Live interactive requests
Other interactive requests
High priority messages
High priority status responses
Normal priority messages
Normal priority status responses
Low priority messages
Low priority status responses

MTA admin thread input queue directory
Restart requests
Directory synchronization requests
Database updates
Reserved; not currently used
Reserved; not currently used
Reserved; not currently used
Reserved; not currently used
Reserved; not currently used

Message Transfer/Storage Directories

63

css

0
1
2
3
4
5
6
7

problem Directory for undeliverable messages

MTA input queue directory for administrative messages
MTA restart requests
Statistics requests
Other non-priority administrative requests
Reserved; not currently used
Reserved; not currently used
Reserved; not currently used
Reserved; not currently used
Reserved; not currently used

mtaname
wpdomain.db
wpdomain.dc
wphost.dc
gwdom.dc
gwpo.dc
viewcopy.log

Domain name identifier
Domain database
Data dictionary for 4.x domain databases
Data dictionary for 4.x post office databases
Data dictionary for 5.x, 6.x, and 7.x domain databases
Data dictionary for 5.x, 6.x, and 7.x post office databases
Log file recording view file updates for post offices

7.1.1 domain directory

Within the GroupWise system, a domain is hierarchically the highest level object. It organizes post
offices into a logical grouping for addressing and routing purposes. Each user in the domain has an
address that consists of the user’s GroupWise user ID, the user’s post office name, and the domain
name (user.post_office.domain). The explicit name is not displayed in the Address Book,
but is stored in the domain database (wpdomain.db).

7.1.2 wpcsin directory

The wpcsin subdirectory in the domain is the MTA input queue in each domain. It contains eight
priority subdirectories to handle different types of message traffic.

 Incoming user messages are queued by priority for routing to recipients’ post offices in the

local domain.

 Incoming status messages are queued by priority for routing to senders’ post offices in the local

domain.

 Outgoing administrative messages are queued for replication to other domains.

 In a routing domain, messages pass through this directory on their way to the next domain.

When a new message arrives, the MTA routes it to the appropriate destination.

For TCP/IP links, the MTA is notified immediately when a message arrives for processing. For
mapped and UNC links, the MTA scans its input queue for messages to process. You can control the
rate at which the MTA scans its input queues. See “Adjusting MTA Polling of Input Queues in the

Domain, Post Offices, and Gateways” in “Optimizing the MTA” in the GroupWise 7 Administration

Guide.

Historical Note: WP Office*, the predecessor of GroupWise, was originally designed by
WordPerfect Corporation* (WPCorp*). The Message Transfer Agent (MTA) was originally named

64 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

the Connection Server (CS). Hence, the directory name wpcsin for the MTA input queue. Some
naming conventions were originally preserved for backward compatibility.

0 directory

The priority 0 subdirectory of the MTA input queue (wpcsin) in the domain is for service requests
that demand an immediate response from the MTA. For example:

 ConsoleOne

®

places restart requests and queue reconfiguration requests here for the MTA and

gateways.

 MTAs for other domains route Busy Search requests through here when users in other domains

check schedules of users in the local domain.

You can increase throughput for the priority 0 subdirectory. See “Adjusting the Number of MTA

Scanner Threads for the Domain and Post Offices” in “Optimizing the MTA” in the GroupWise 7

Administration Guide.

1 directory

The priority 1 subdirectory of the MTA input queue (wpcsin) in the domain is for service requests
of the next highest priority. For example:

 ConsoleOne places directory synchronization requests here for the MTA admin thread.

 ConsoleOne places statistics requests here for the MTA to relay to the message logging module

for processing.

 MTAs for other domains route remote GroupWise client requests through here when remote

GroupWise users do not connect to the post office where their master mailboxes are located.

You can increase throughput for the priority 1 subdirectory. See “Adjusting the Number of MTA

Scanner Threads for the Domain and Post Offices” in “Optimizing the MTA” in the GroupWise 7

Administration Guide.

2 directory

The priority 2 subdirectory of the MTA input queue (wpcsin) in the domain is for high priority
messages. For example:

 MTAs for other domains place incoming high priority user messages here. The local MTA then

routes the messages to recipients’ post offices.

 MTAs for other domains place incoming administrative messages here to replicate database

updates in the local domain.

 The MTA admin thread places outgoing administrative messages here to replicate database

updates to other domains.

You can increase throughput for the priority 2 and 3 subdirectories. See “Adjusting the Number of

MTA Scanner Threads for the Domain and Post Offices” in “Optimizing the MTA” in the

GroupWise 7 Administration Guide.

3 directory

The priority 3 subdirectory of the MTA input queue (wpcsin) in the domain is for high priority
status messages routed back to senders in local post offices.

Message Transfer/Storage Directories 65

For example, MTAs for other domains place status responses to high priority user messages here.
The local MTA then routes the status messages to senders’ post offices, so senders’ mailboxes can
be updated with current message status.

You can increase throughput for the priority 2 and 3 subdirectories. See “Adjusting the Number of

MTA Scanner Threads for the Domain and Post Offices” in “Optimizing the MTA” in the

GroupWise 7 Administration Guide.

4 directory

The priority 4 subdirectory of the MTA input queue (wpcsin) in the domain is for normal priority
user messages routed to recipients in local post offices.

For example, MTAs for other domains place normal priority user messages here. The local MTA
then routes the messages to recipients’ post offices. Most messages in your GroupWise system pass
through the priority 4 subdirectory.

You can increase throughput for the priority 4 subdirectory. See “Adjusting the Number of MTA

Scanner Threads for the Domain and Post Offices” in “Optimizing the MTA” in the GroupWise 7

Administration Guide.

5 directory

The priority 5 subdirectory of the MTA input queue (wpcsin) in the domain is for normal priority
status messages routed back to senders in local post offices.

For example, MTAs for other domains place status responses to normal priority user messages here.
The local MTA then routes the status messages to senders’ post offices, so senders’ mailboxes can
be updated with current message status.

6 directory

The priority 6 subdirectory of the MTA input queue (wpcsin) in the domain is for low priority user
messages routed to recipients in local post offices.

For example, MTAs for other domains place low priority user messages here. The local MTA then
routes the messages to recipients’ post offices.

7 directory

The priority 7 subdirectory of the MTA input queue (wpcsin) in the domain is for low priority
status messages routed back to senders in local post offices.

For example, MTAs for other domains place status responses to low priority user messages here.
The local MTA then routes the status messages to senders’ post offices, so senders’ mailboxes can
be updated with current message status.

7.1.3 wptools directory

The wptools subdirectory in the domain contains programs that support GroupWise
administration.

66 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect
Corporation (WPCorp). Hence, the wp in wptools. Some naming conventions were originally
preserved for backward compatibility.

7.1.4 wpgate directory

The wpgate subdirectory in the domain contains a subdirectory for each GroupWise gateway you
have installed in your GroupWise system. For a list of gateways, see the GroupWise Gateways

Documentation Web site (http://www.novell.com/documentation/gwateways). GroupWise 5.5

gateways can be used with GroupWise 6.x and 7.x.

7.1.5 wpcsout directory

The wpcsout subdirectory in the domain is the MTA output queue in each domain. It contains
subdirectories that function as input queues for the processes to which the MTA delivers messages.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect
Corporation (WPCorp). The Message Transfer Agent (MTA) was originally named the Connection
Server (CS). Hence, the directory name wpcsout for the MTA output queue. Some naming
conventions were originally preserved for backward compatibility.

ads directory

The ads subdirectory of the MTA output queue (wpcsout) in the domain is the input queue for the
MTA admin thread in each domain. It contains priority subdirectories where incoming
administrative messages are queued for processing. When a new administrative message arrives, the
MTA admin thread performs the requested action.

Historical Note: The MTA admin thread was previously part of a separate agent, the Administration
Agent (ADA), which was originally named the Administration Server (ADS). Hence, the directory
name ads. Some naming conventions were originally preserved for backward compatibility.

0 directory

The priority 0 subdirectory of the MTA admin thread input queue (wpcsout\ads) in the domain
is for service requests that demand an immediate response from the MTA admin thread.

For example, when you create or delete a post office in ConsoleOne, a restart request is placed here.
The domain MTA admin thread processes the request and then restarts.

1 directory

The priority 1 subdirectory of the MTA admin thread input queue (wpcsout\ads) in the domain
is for service requests of the next highest priority.

2 directory

The priority 2 subdirectory of the MTA admin thread input queue (wpcsout\ads) in the domain
is for high priority administrative messages. For example:

 The MTA places administrative messages from other domains here. The administrative

messages might instruct the MTA admin thread to add, modify, or delete users, post offices, or
other objects in the domain. The MTA admin thread then processes the messages and makes
the specified updates.

Message Transfer/Storage Directories 67

 When you use the Synchronize utility in ConsoleOne, a synchronization request is placed here.

The MTA admin thread then resends the specified administrative messages to produce the
required database updates.

css directory

The css subdirectory of the MTA output queue (wpcsout) in the domain is processed by a
specialized MTA thread that responds to requests regarding its own configuration. It contains the
eight standard priority subdirectories.

Historical Note: In an earlier version of GroupWise, the Message Transfer Agent (MTA) was called
the Connection Server (CS) and this specialized subprocess was called the Connection Server Server
(css). Some naming conventions were originally preserved for backward compatibility.

0 directory

The priority 0 subdirectory of the CSS input queue (wpcsout\css) in the domain is for service
requests that demand an immediate response from the MTA.

For example, when you restart the MTA at the MTA agent console or in ConsoleOne, a restart
request is placed here. The MTA processes the request and restarts.

1 directory

The priority 1 subdirectory of the CSS input queue (wpcsout\css) in the domain is for service
requests of the next highest priority.

For example, each time the statistics are updated on the MTA agent console, a statistics request is
placed here. The MTA then gathers the statistics and displays them on the MTA agent console.

2 directory

The priority 2 subdirectory of the css input queue (wpcsout\css) in the domain is for non­priority requests.

problem directory

The problem subdirectory of the MTA output queue (wpcsout) in the domain is where the MTA
places message files that cannot be delivered because they are damaged in some way. Message files
in the problem directory must be handled by the GroupWise administrator. See “Message Is

Dropped in the problem Directory in the Domain” in GroupWise 7 Troubleshooting 2: Solutions to

Common Problems.

7.1.6 mtaname file

The mtaname file in the domain provides the domain name associated with the domain directory
structure. This can help you locate the domain information for the directory structure in
ConsoleOne. It can also help you check links between MTAs.

7.1.7 wpdomain.db file

The wpdomain.db file in the domain is the domain database. It contains all administrative
information for the domain.

68 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

In the primary domain, the wpdomain.db file contains all administrative information for your
entire GroupWise system (all its domains, post offices, users, and so on). Because the
wpdomain.db file in the primary domain is so crucial, you should back it up regularly and keep it
secure. (You can re-create your entire GroupWise system from the primary domain wpdomain.db
file; however, if the primary domain wpdomain.db file becomes unusable, you can no longer
make administrative updates to your GroupWise system.)

In a secondary domain, the wpdomain.db file contains administrative information about that
secondary domain only.

In GroupWise 7.x, 6.x, and 5.x domains, the data dictionary for the wpdomain.db file is the

gwdom.dc file. In GroupWise 4.x domains, the data dictionary is the wpdomain.dc file. As a

result, wpdomain.db files have different structures (schemas) depending on whether they were
created for 7.x/6.x/5.x or 4.x domains.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect
Corporation (WPCorp). Hence, the wp in wpdomain.db. Some naming conventions were
originally preserved for backward compatibility.

7.1.8 wpdomain.dc file

The wpdomain.dc file in the domain is the data dictionary for rebuilding GroupWise 4.x domain
databases (wpdomain.db files) in secondary domains.

If the wpdomain.dc file is missing from the primary domain, you cannot rebuild GroupWise 4.x
secondary domains. The original wpdomain.dc file is located in the domain subdirectory of the
software distribution directory or on the GroupWise Administrator CD.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect
Corporation (WPCorp). Hence, the wp in wpdomain.dc. Some naming conventions were
originally preserved for backward compatibility.

7.1.9 wphost.dc file

The wphost.dc file in the domain is the data dictionary for rebuilding GroupWise 4.x post office
databases (wphost.db files).

If the wphost.dc file is missing from a domain, you cannot rebuild GroupWise 4.x post offices in
that domain. The original wphost.dc file is located in the domain directory of the software
distribution directory or on the GroupWise Administrator CD.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect
Corporation (WPCorp). Post offices were originally called hosts. Hence, the name wphost.dc.
Some naming conventions were originally preserved for backward compatibility.

7.1.10 gwdom.dc file

The gwdom.dc file in the domain is the data dictionary for creating and rebuilding GroupWise 7.x,

6.x, and 5.x domain databases (wpdomain.db files) in secondary domains.

If the gwdom.dc file is missing from the primary domain, you cannot create or rebuild GroupWise

7.x/6.x/5.x secondary domains. The original gwdom.dc file is located in the domain directory of
the software distribution directory or on the GroupWise distribution media.

Message Transfer/Storage Directories 69

7.1.11 gwpo.dc file

The gwpo.dc file in the domain is the data dictionary for creating and rebuilding GroupWise 7.x,

6.x, and 5.x post office databases (wphost.db files).

If the gwpo.dc file is missing from a domain, you cannot create or rebuild GroupWise 7.x/6/x/5.x
post offices in that domain. The original gwpo.dc file is located in the domain directory of the
software distribution directory or on the GroupWise distribution media.

7.1.12 viewcopy.log file

The viewcopy.log file in the domain is created by the GroupWise Installation program if you
update the Windows client software and the Installation program is unable to copy the view files to
any post offices in the domain. You can manually update the view files later, as described in
“Refreshing the Client View Files in the Post Office” in “Post Offices” in the GroupWise 7

Administration Guide.

7.2 Post Office Directory

post_office Post office directory

wpcsin

0
1
2
3

4

5
6
7

gwdms

dmsh.db

lib0001-ff

dmxxnn01-ff.db
index
archive
docs

fd00-ff

ofmsg

msgnnn.db
ngwdfr.db

guardbak

MTA input queue direct
Live interactive requests
Other interactive requests
High priority messages
High priority status responses
Normal priority messages
Normal priority status responses
Low priority messages
Low priority status responses

Document Management Services directory
Shared Document Management Services database

Library directories
Document databases

TM

QuickFinder
Archive directory for library
Large document directory for library
Subdirectories for documents

Message database directory
As many as 255 message databases
Deferred message database
Backup guardian database

index for library

ofuser

userxxx.db
puxxxxx.db

index

User database directory
User databases (one per user)
Databases for shared folders
QuickFinder index for messages

70 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

offiles

fd0-f6

ofviews GroupWise client view files

Attachment store directory
Subdirectories for attachments

ofwork

ofdirect

oftemp GroupWise temporary files

wpcsout MTA output queue directory

ofs

0
1
2
3
4
5
6
7

defer
mmddpoa.nnn
wprof50.db

ads

0

1

2

3

4

5

6

7

GroupWise working directory
Remote direct connection directory

POA input queue directory
Live interactive requests
Other interactive requests
High priority messages
High priority status responses
Normal priority messages
Normal priority status responses
Low priority messages
Low priority status responses
Directory to temporarily store deferred messages
POA log files
Downloadable system Address Book

POA admin thread input queue directory
Restart requests
Directory synchronization requests
Database updates
Reserved; not currently used
Reserved; not currently used
Reserved; not currently used
Reserved; not currently used
Reserved; not currently used

chk

0-3

defer

problem Directory for undeliverable messages

wphost.db
gwpo.dc

ngwguard.db

ngwguard.dc
ngwguard.fbk
ngwguard.rfl
ngwcheck.db

GWCheck working directory
GWCheck priority subdirectories
GWCheck subdirectory for deferred database maintenance

requests

Post office database
Data dictionary for GroupWise 7.x/6.x/5.x post office databases
Guardian database
Data dictionary for databases
Guardian database backup
Guardian database roll forward log
GWCheck control database

7.2.1 post_office directory

Conceptually, a post office contains mailboxes for a set of network users. The users on the post
office send and receive messages through their mailboxes.

Message Transfer/Storage Directories 71

Physically, a post office is a directory structure on a network file server. The directory structure
contains subdirectories and databases that store messages and the information used to distribute the
messages.

7.2.2 wpcsin directory

The wpcsin subdirectory in the post office is the MTA input queue in each post office. It contains
eight priority subdirectories to handle different types of message traffic.

 Outgoing user messages are queued by priority for routing to recipients in other post offices.

 Outgoing status messages are queued by priority for routing back to senders’ post offices.

 Outgoing Busy Search requests are queued for routing to other post offices so users’ schedules

can be checked.

 Remote GroupWise client requests are queued for routing to remote GroupWise users’ master

mailboxes.

When a new message arrives, the MTA routes it to the appropriate destination.

For mapped and UNC links, the MTA scans its input queue for messages to process. You can
control the rate at which the MTA scans its input queues. See “Adjusting MTA Polling of Input

Queues in the Domain, Post Offices, and Gateways” in “Optimizing the MTA” in the GroupWise 7

Administration Guide.

For TCP/IP links, the POA passes messages to the MTA via TCP/IP. A copy is kept in the MTA
input queue until the POA has successfully transferred the message.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect
Corporation (WPCorp). The Message Transfer Agent (MTA) was originally named the Connection
Server (CS). Hence, the directory name wpcsin for the MTA input queue. Some naming
conventions were originally preserved for backward compatibility.

0 directory

The priority 0 subdirectory of the MTA input queue (wpcsin) in the post office is for service
requests that demand an immediate response from the MTA.

For example, the GroupWise client places Busy Search requests here. The MTA then routes the
requests to the appropriate post offices, so users’ schedules can be checked.

You can increase throughput for the priority 0 subdirectory. See “Adjusting the Number of MTA

Scanner Threads for the Domain and Post Offices” in “Optimizing the MTA” in the GroupWise 7

Administration Guide.

1 directory

The priority 1 subdirectory of the MTA input queue (wpcsin) in the post office is for service
requests of the next highest priority. For example:

 Remote with a direct connection places requests here for routing to remote GroupWise users’

master mailboxes.

 The POA places outgoing status messages to remote GroupWise users here for routing to the

Async Gateway.

72 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

You can increase throughput for the priority 1 subdirectory. See “Adjusting the Number of MTA

Scanner Threads for the Domain and Post Offices” in “Optimizing the MTA” in the GroupWise 7

Administration Guide.

2 directory

The priority 2 subdirectory of the MTA input queue (wpcsin) in the post office is for high priority
user messages routed to recipients in other post offices, domains, or systems.

For example, the GroupWise client places high priority user messages here. The MTA then routes
the messages to the appropriate destinations.

You can increase throughput for the priority 2 and 3 subdirectories. See “Adjusting the Number of

MTA Scanner Threads for the Domain and Post Offices” in “Optimizing the MTA” in the

GroupWise 7 Administration Guide.

3 directory

The priority 3 subdirectory of the MTA input queue (wpcsin) in the post office is for high priority
status messages routed back to senders in other post offices, domains, or systems.

For example, the GroupWise client and local POA place status responses to high priority user
messages here. The MTA then routes the status messages to the appropriate post offices, so senders’
mailboxes can be updated with current message status.

You can increase throughput for the priority 2 and 3 subdirectories. See “Adjusting the Number of

MTA Scanner Threads for the Domain and Post Offices” in “Optimizing the MTA” in the

GroupWise 7 Administration Guide.

4 directory

The priority 4 subdirectory of the MTA input queue (wpcsin) in the post office is for normal
priority user messages routed to recipients in other post offices, domains, or systems.

For example, the GroupWise client places normal priority user messages here. The MTA then routes
the messages to the appropriate destinations. Most messages in your GroupWise system pass
through the priority 4 subdirectory.

You can increase throughput for the priority 4 subdirectory. See “Adjusting the Number of MTA

Scanner Threads for the Domain and Post Offices” in “Optimizing the MTA” in the GroupWise 7

Administration Guide.

5 directory

The priority 5

subdirectory of the MTA input queue (wpcsin) in the post office is for normal

priority status messages routed back to senders in other post offices, domains, or systems.

For example, the GroupWise client and local POA place status responses to normal priority user
messages here. The MTA then routes the status messages to the appropriate post offices, so senders’
mailboxes can be updated with current message status.

6 directory

The priority 6 subdirectory of the MTA input queue (wpcsin) in the post office is for low priority
user messages routed to recipients in other post offices, domains, or systems.

Message Transfer/Storage Directories 73

For example, the GroupWise client places low priority user messages here. The MTA then routes
the messages to the appropriate destinations.

7 directory

The priority 7 subdirectory of the MTA input queue (wpcsin) in the post office is for low priority
status messages routed back to senders in other post offices, domains, or systems.

For example, the GroupWise client and local POA place status responses to low priority user
messages here. The MTA then routes the status messages to the appropriate post offices, so senders’
mailboxes can be updated with current message status.

7.2.3 gwdms directory

The gwdms subdirectory in the post office is the Document Management Services (DMS) directory
in each post office. It contains the document libraries associated with the post office.

dmsh.db file

The dmsh.db file in the document management subdirectory (gwdms) in the post office is a
database shared by all libraries in the post office. It contains a list of all available libraries and
lookup tables for each library.

lib0001-ff directories

The lib0001-ff subdirectories in the gwdms subdirectory in the post office contain the libraries
for the post office, with one library per directory. You can create a maximum of 256 libraries in a
post office.

dmxxnn01-ff.db files

The dmxxnn01-ff.db files in the library subdirectories (lib0001-ff) in the post office are
databases for library and document information.

The nn in the filenames represents the partition number, which is generated by a hashing algorithm
to guarantee uniqueness.

The 01-ff in the filenames represents the library number, matching the number on the library
directory in which the database is found.

dmsdnn01-ff.db file
The dmsdnn01-ff.db file in each library holds system data for the library, such as library

configuration information.

dmddnn01-ff.db file
The dmddnn01-ff.db file in each library holds document data for the library. Document data is

the document property information for documents in the library.

dmdlnn01-ff.db file
The dmdlnn01-ff.db file in each library holds document logging data for the library.

Document logging data records all activities performed on documents in the library.

74 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

index directory

The index subdirectories in the library subdirectories (lib0001-ff) in the post office contain
the QuickFinder index for the documents contained in the library.

archive directory

The archive subdirectories in the library subdirectories (lib0001-ff) in the post office contain
an array of subdirectories for holding archived documents. The subdirectories are numbered
sequentially. When the first archive subdirectory reaches its maximum allowable size, archived
documents are stored in the next sequential directory, and so on.

docs directory

The docs subdirectories in the library subdirectories (lib0001-ff) in the post office contain an
array of subdirectories for storing documents.

fd0-ff directories
The fd0-ff subdirectories in the docs subdirectory in the post office store documents that are

equal to or greater than 2 KB in size. The 0-ff variable represents hexadecimal number 0 through ff,
so the subdirectories are named fd0 through fdff. The document databases (dmxxnn01-ff.db
files) contain pointers to documents stored in the subdirectories of the docs directory.

7.2.4 ofmsg directory

The ofmsg subdirectory in the post office contains as many as 255 databases where messages are
stored. It serves as centralized storage for all users in the post office. A message must be stored only
once to be delivered to any number of users in the same post office.

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation (WPCorp),
was named WP Office. Hence, the of in ofmsg. Some naming conventions were originally
preserved for backward compatibility.

msgnnn.db file

The msgnnn.db files in the ofmsg subdirectory in the post office are the message databases
where users’ messages smaller than 2 KB are stored. To increase database efficiency, messages,
attachments, and recipient lists equal to or greater than 2 KB are stored outside the msgnn.db files
in an array of subdirectories in the offiles directory. After the 2 KB limit is reached, only
pointers are stored in the message databases.

The nnn variable in the database names is a three-digit number from 0 to 254. A hashing algorithm
takes each user’s GroupWise file ID (FID) to derive which database the user’s outgoing mail is
assigned to. The contents of the messages databases are encrypted so the text of message can only be
read through GroupWise.

Multiple users are assigned to the same message database. You can use GWCheck to determine
which database a specific user has been assigned to. See “GroupWise Check” in “Standalone

Database Maintenance Programs” in the GroupWise 7 Administration Guide.

ngwdfr.db file

The ngwdfr.db file in the ofmsg subdirectory in the post office holds deferred messages that
users have specified for delivery at a later time. When users delay delivery on messages, the

Message Transfer/Storage Directories 75

messages are transferred to the receiving post office and held in the ngwdfr.db file until the delay
expires.

Historical Note: Earlier versions of GroupWise handled deferred messages through the ofpend
directory in the post office.

guardbak directory

The guardbak subdirectory in the ofmsg subdirectory in the post office holds a backup copy of
the ngwguard.fbk file.

7.2.5 ofuser directory

The ofuser subdirectory in the post office contains a separate database (mailbox) for each
GroupWise user.

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation (WPCorp),
was named WP Office. Hence, the of in ofuser. Some naming conventions were originally
preserved for backward compatibility.

userxxx.db file

The userxxx.db files in the ofuser subdirectory in the post office are user databases where the
contents of users’ mailboxes are stored, as displayed in the GroupWise client In addition, each user
database contains:

 Some personal GroupWise client program settings

 Personal appointments

 Personal groups

 Personal notes

 Rules

Personal client settings that remain the same regardless of what workstation a user logs in to are
stored in the user database. Personal client settings that are customized for a particular workstation
are stored in the Windows* registry.

The xxx variable in the database names is each user’s GroupWise file ID (FID).

puxxxxx.db file

The puxxxxx.db files in the ofuser subdirectory in the post office are databases for replicated
items such as shared folders. These databases prevent conflicts between user names of shared items
from users in other post offices and user names in the local post office.

index directory

The index subdirectory in the ofuser subdirectory in the post office contains the QuickFinder
index for users’ messages stored in the post office.

76 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

7.2.6 offiles directory

The offiles subdirectory in the post office contains subdirectories for messages, attachments,
and recipient lists that are equal to or greater than 2 KB in size. These larger messages, attachments,
and recipient lists are stored outside the actual message databases in the ofmsg directory to increase
database efficiency.

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation (WPCorp),
was named WP Office. Hence, the of in offiles. Some naming conventions were originally
preserved for backward compatibility.

fd0-f6 directories

The fd0-f6 subdirectories in the offiles subdirectory in the post office store messages,
attachments, and recipient lists that are equal to or greater than 2 KB in size. The nn variable
represents hexadecimal number 0 through f6, so the subdirectories are named fd0 through fdf6.
The message databases (msgnnn.db files) contain pointers to messages, attachments, and recipient
lists stored in the subdirectories of offiles.

7.2.7 ofviews directory

The ofviews subdirectory in the post office contains subdirectories for GroupWise client
platforms. Within the platform-specific subdirectories (for example, win) are view (*.vew) files
that create the various views displayed in the GroupWise client.

The gwviewxx.ini and ofviewxx.ini files configure the standard views on the menus where
users select views. The gwviewxx.ini file configures GroupWise 7.x, 6.x, and 5.5 standard
views. The ofviewxx.ini file configures standard views from earlier versions of GroupWise.

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation (WPCorp),
was named WP Office. Hence, the of in ofviews. Some naming conventions were originally
preserved for backward compatibility.

7.2.8 ofwork directory

The ofwork subdirectory in the post office is a working directory for requests from the GroupWise
client in Remote mode.

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation (WPCorp),
was named WP Office. Hence, the of in ofwork. Some naming conventions were originally
preserved for backward compatibility.

7.2.9 ofdirect directory

The ofdirect subdirectory in the working directory (ofwork) in the post office is used by the
GroupWise client in Remote mode for direct connections when the network is available.

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation (WPCorp),
was named WP Office. Hence, the of in ofdirect. Some naming conventions were originally
preserved for backward compatibility.

Message Transfer/Storage Directories 77

7.2.10 oftemp directory

The oftemp subdirectory in the post office holds various temporary files such as the MIME files
created during access by IMAP e-mail clients.

7.2.11 wpcsout directory

The wpcsout subdirectory in the post office is the MTA output queue in each post office. It
contains subdirectories which function as input queues for the other agents to which the MTA
delivers messages.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect
Corporation (WPCorp). The Message Transfer Agent (MTA) was originally named the Connection
Server (CS). Hence, the directory name wpcsout for the MTA output queue. Some naming
conventions were originally preserved for backward compatibility.

ofs directory

The ofs subdirectory of the mta output queue (wpcsout) in the post office is the POA input queue
in each post office. It contains eight priority subdirectories to handle different types of message
traffic.

 Incoming user messages are queued by priority for delivery to recipients’ mailboxes in the

local post office.

 Incoming status messages are queued by priority for delivery to senders’ mailboxes in the local

post office.

 Incoming Busy Search requests are queued for the POA to check users’ schedules in the local

post office.

The POA scans these priority subdirectories regularly. When a new message arrives, the POA
processes the messages and performs the required actions.

0 directory

The priority 0 subdirectory of the POA input queue (wpcsout\ofs) in the post office is for
service requests that demand an immediate response from the POA.

For example, the MTA places Busy Search requests here so the POA can check recipients’
schedules and quickly return the schedule information to the sender.

1 directory

The priority 1 subdirectory of the POA input queue (wpcsout\ofs) in the post office is for
service requests of the next highest priority.

For example, the MTA places requests from remote GroupWise users for items in their master
mailboxes here. The POA then processes the messages and returns the requested items.

2 directory

The priority 2 subdirectory of the POA input queue (wpcsout\ofs) in the post office is for high
priority user messages being delivered to recipients in the local post office.

78 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

For example, the MTA places high priority user messages here. The POA then updates the message
databases and recipients’ mailboxes.

3 directory

The priority 3 subdirectory of the POA input queue (wpcsout\ofs) in the post office is for high
priority status messages coming back to senders in the local post office.

For example, the MTA places status responses to high priority user messages here. The POA then
updates the message databases and senders’ mailboxes with current message status.

4 directory

The priority 4 subdirectory of the POA input queue (wpcsout\ofs) in the post office is for
normal priority user messages being delivered to recipients in the local post office.

For example, the MTA places normal priority user messages here. The POA then updates the
message databases and recipients’ mailboxes. Most messages in your GroupWise system pass
through the priority 4 subdirectory.

5 directory

The priority 5 subdirectory of the POA input queue (wpcsout\ofs) in the post office is for
normal priority status messages coming back to senders in the local post office.

For example, the MTA places status responses to normal priority user messages here. The POA then
updates the message databases and senders’ mailboxes with current message status.

6 directory

The priority 6 subdirectory of the POA input queue (wpcsout\ofs) in the post office is for low
priority user messages being delivered to recipients in the local post office.

For example, the MTA places low priority messages here. The POA then updates the message
databases and recipients’ mailboxes.

7 directory

The priority 7 subdirectory of the POA input queue (wpcsout\ofs) in the post office is for low
priority status messages coming back to senders in the local post office.

For example, the MTA places status responses to low priority user messages here. The POA then
updates the message databases and senders’ mailboxes with current message status.

defer directory

The defer subdirectory of the POA input queue (wpcsout\ofs) in the post office is used to
temporarily store deferred messages when the ngwdfr.db database is locked. This might occur if
backup software has locked the ngwdfr.db database. After the ngwdfr.db database is available
again, deferred messages are written to the ngwdfr.db database as usual.

mmddpoa.nnn files

The mmddpoa.nnn files are POA log files. The POA creates log files to inform you of its
processing and any problems it encounters. By default, these log files are created in the

Message Transfer/Storage Directories 79

wpcsout\ofs directory. You can change the location if needed. See “Using POA Log Files” in

“Post Office Agent” in the GroupWise 7 Administration Guide guide.

The first two digits of the filename represent the month, the next two digits represent the day of the
month, and the next three characters indicate what program created the log. The three-digit
extension is a sequence number for multiple log files created on the same day. For example,
0518poa.002 is the second POA log file created on May 18.

wprof50.db file

The wprof50.db file in the wpcsout\ofs directory is the downloadable system Address Book
for Remote client users. By default, it is automatically re-created once a day to keep it up to date.
See “Performing Nightly User Upkeep” in “Post Office Agent” in the GroupWise 7 Administration

Guide guide.

ads directory

The ads subdirectory of the MTA output queue (wpcsout) in the post office is the input queue for
the POA admin thread in each post office. It contains priority subdirectories where administrative
messages are queued for processing.

Historical Note: The POA admin thread was previously part of a separate agent, the Administration
Agent (ADA), which was originally named the Administration Server (ADS). Hence, the directory
name ads. Some naming conventions were originally preserved for backward compatibility.

0 directory

The priority 0 subdirectory of the POA admin thread input queue (wpcsout\ads) in the post

office is for service requests that demand an immediate response from the POA admin thread.

1 directory

The priority 1 subdirectory of the POA admin thread input queue (wpcsout\ads) in the post

office is for service requests of the next highest priority.

For example, a directory synchronization request that could not be performed when the POA admin
thread received it in its domain input queue would be placed here in the post office for later
processing.

2 directory

The priority 2 subdirectory of the POA admin thread input queue (wpcsout\ads) in the post

office is for high priority administrative messages.

For example, a database update request that could not be performed when the POA admin thread
received it in its domain input queue would be placed here in the post office for later processing.

chk directory

The chk subdirectory of the MTA output queue (wpcsout) in the post office is the working
directory where the multithreaded GWCheck process keeps temporary files during database
maintenance and where it tracks the activities of its various threads. The defer subdirectory is used
when the ngwcheck.db database is locked, for example, by a backup program.

80 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

problem directory

The problem subdirectory of the MTA output queue (wpcsout) in the post office is a holding
area for damaged message files. Problem files are marked with an extension indicating which
GroupWise agent placed each file in the problem directory.

You should check this directory periodically for problem files, resolve the problem, then place the
files back into the appropriate queue for continued processing. For assistance, see “Message Is

Dropped in the problem Directory in the Post Office” in “Strategies for Message Delivery
Problems” in the GroupWise 7 Troubleshooting 2: Solutions to Common Problems.

7.2.12 wphost.db file

The wphost.db file in the post office is the post office database. It contains all administrative
information for the post office. It also contains the Address Book for the post office.

In GroupWise 7.x, 6.x, and 5.x post offices, the data dictionary for the wphost.db file is the

gwpo.dc file. In GroupWise 4.x post offices, the data dictionary is the wphost.dc file. As a

result, wphost.db files have different structures (schemas) depending on whether they were
created for GroupWise 7.x/6.x/5.x or 4.x post offices.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect
Corporation (WPCorp). Post offices were originally called hosts. Hence, the name wphost.db.
Some naming conventions were originally preserved for backward compatibility.

7.2.13 gwpo.dc file

The gwpo.dc file in the post office is the data dictionary for creating and rebuilding GroupWise

7.x, 6.x, and 5.x post office databases (wphost.db files).

If the gwpo.dc file is missing from a post office and its domain, you cannot create or rebuild
GroupWise 7.x/6.x/5.x post offices in that domain. The original gwpo.dc file is located in the

domain directory of the software distribution directory or on the GroupWise Administrator CD.

7.2.14 ngwguard.db file

The ngwguard.db file in the post office is the guardian database. See “Information Stored in the

Post Office” in “Post Office Agent” in the GroupWise 7 Administration Guide.

7.2.15 ngwguard.dc file

The ngwguard.dc file in the post office is the data dictionary for building the following databases
in the post office:

 ngwguard.db (guardian database)

 dmxxnn01-ff.db (document management databases)

 msgnnn.db (message databases)

 userxxx.db (user databases)

 puxxxxx.db (databases for replicated items like shared folders)

Message Transfer/Storage Directories 81

7.2.16 ngwguard.fbk file

The ngwguard.fbk file in the post office is a “fall back” copy of the ngwguard.db file. If the
ngwguard.db file becomes damaged, the ngwguard.fbk file, along with the ngsguard.rfl

file, can be used to rebuild a valid, current ngwguard.db file. The ngwguard.fbk file is so
important that an additional copy of it is kept in the ofmsg\guardbak subdirectory in case the
copy in the post office directory is inadvertently deleted. See “Guardian Databases” in “Databases”
in the GroupWise 7 Administration Guide.

7.2.17 ngwguard.rfl file

The ngwguard.rfl file in the post office is a roll-forward transaction log of every database
transaction that has taken place since the last copy of the ngwguard.fbk file was created. See
“Guardian Databases” in “Databases” in the GroupWise 7 Administration Guide.

7.2.18 ngwcheck.db

The ngwcheck.db file in the post office is the database that controls GWCheck’s multithreaded
processing. It contains job and task records that are used to synchronize and summarize GWCheck
requests as they progress.

7.3 MTA Local Queue Directory

mslocal

mmddxxx.nn

msglog

mmddmsg.nn

gwinprog

0-7

mshold MTA holding directory

domainms

0-7

mtaname

postx

0-7

mtaname

gatewayx

0-7

mtaname

domainx

0-7

mtaname

MTA local working directory
MTA log files

Message logging directory
Message logging files

MTA "in progress" queue directory
Priority subdirectories

Processing directory for MTA
Priority subdirectories
Location identifier

Holding directories for post offices
Priority subdirectories
Location identifier

Holding directories for gateways
Priority subdirectories
Location identifier

Holding directories for other domains
Priority subdirectories
Location identifier

gwvsscan Working directory for third-party virus scanning programs

mtaconv Work area for 5.x to 4.x conversion

82 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

7.3.1 mslocal directory

The mslocal directory is the MTA local working directory. The /work startup switch of the MTA
specifies the location of the mslocal directory. It must be located on the hard disk of the server
where the MTA runs so it is always accessible. Adequate disk space must be available to hold
messages going to destinations that are temporarily closed.

Typical locations for the mslocal directory include:

 sys:\system on a NetWare

 c:\ on a Windows server

To move t h e mslocal directory, stop the MTA, the copy the mslocal directory, along with all of
its subdirectories, to the new location. Then restart the MTA and specify the new location using the

/work startup switch.

Historical Note: In earlier versions of GroupWise, the Message Transfer Agent (MTA) was called
the Message Server (MS). Hence, the ms in mslocal. Some naming conventions were originally
preserved for backward compatibility.

mmddxxx.nnn files

The mmddxxx.nnn file are MTA log files. The MTA creates log files to inform you of its
processing and any problems it encounters. By default, these log files are created in the mslocal
directory. You can change the location if needed. See “Using MTA Log Files” in “Message Transfer

Agent” in the GroupWise 7 Administration Guide.

®

server

The first two digits of the filename represent the month; the next two digits represent the day of the
month; the next three characters indicate what program created the log. The three-digit extension is
a sequence number for multiple log files created on the same day. For example, 0518mta.002 is
the second MTA log file created on May 18.

Historical Note: In earlier versions of GroupWise, the Message Transfer Agent (MTA) was called
the Message Server (MS). Hence, the ms indicator representing the MTA. Some naming
conventions were originally preserved for backward compatibility.

7.3.2 msglog directory

The msglog subdirectory contains message logging files. It is created when you turn on message
logging. The MTA receiver threads log messages as they arrive so the MTA worker threads can
process messages without having to scan the MTA input queues to look for work.

The resources used for message logging are configurable. See “Optimizing the Routing Queue” in
“Optimizing the MTA” in the GroupWise 7 Administration Guide.

More detailed message logging by the MTA is also available, but is turned off by default. See
“Enabling MTA Message Logging” in “Configuring the MTA” in the GroupWise 7 Administration

Guide.

mmddmsg.nnn files

The mmddmsg.nnn files in the message logging subdirectory (msglog) in the MTA local

directory are used by the MTA to track messages in its “in progress” queue.

Message Transfer/Storage Directories 83

The first two digits of the filename represent the month; the next two digits represent the day of the
month. The three-digit extension is a sequence number for multiple files created on the same day.
For example, 0518msg.002 is the second message logging file created on May 18.

7.3.3 gwinprog directory

The gwinprog subdirectory is the MTA “in progress” queue. It contains eight priority
subdirectories parallel to those found in wpcsin. All messages for recipients in the domain pass
through gwinprog, no matter whether they arrived by way of TCP/IP or by way of message files
deposited into the MTA input queue by a POA or another MTA.

The resources used to process the “in progress” queue are configurable. See “Optimizing the

Routing Queue” in “Optimizing the MTA” in the GroupWise 7 Administration Guide.

7.3.4 mshold directory

The mshold subdirectory is a holding queue for messages addressed to domains, post offices, or
gateways that are currently closed.

A location might be closed because its server is down or because the MTA is unable to communicate
with it for any other reason. When a closed location is again open, the MTA moves messages from
the holding queue back into the normal message flow.

Historical Note: In earlier versions of GroupWise, the Message Transfer Agent (MTA) was called
the Message Server (MS). Hence, the ms in mshold. Some naming conventions were originally
preserved for backward compatibility.

7.3.5 domainms directory

The domainms subdirectory in the holding directory (mshold) is used for internal processing by
the MTA. It does not contain any files a GroupWise administrator needs to access.

Historical Note: In earlier versions of GroupWise, the Message Transfer Agent (MTA) was called
the Message Server (MS). Hence, the ms in domainms. Some naming conventions were originally
preserved for backward compatibility.

7.3.6 postx directories

The postx subdirectories in the holding directory (mshold) represent post offices in the domain.
If a post office is closed, the MTA routes messages for that post office into its holding queue in
mshold. When the post office is open, the MTA moves the messages from the holding queue back
into the regular message flow. For more information, see “Message Delivery to a Different Post

Office” on page 19.

The name of the holding queue for each post office consists of the first three characters of the post
office name, followed by four hashed characters to ensure uniqueness.

7.3.7 gatewayx directories

The gatewayx subdirectories in the holding directory (mshold) represent gateways in the
domain. If a gateway is closed, the MTA routes messages for that gateway into its holding queue in

84 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

mshold. When the gateway is open, the MTA moves the messages from the holding queue back
into the regular message flow through the gateway.

The name of the holding queue for each gateway consists of the first three characters of the gateway
name, followed by four hashed characters to ensure uniqueness.

7.3.8 domainx directories

The domainx subdirectories in the holding directory (mshold) represent domains to which the
current domain has a direct link. If a domain is closed, the MTA routes messages for that domain
into its holding queue in mshold. When the domain is open, the MTA moves the messages from
the holding queue back into the regular message flow. For more information, see “Message Delivery

to a Different Domain” on page 27.

The name of the holding queue for each domain consists of the first three characters of the domain
name, followed by four hashed characters to ensure uniqueness.

7.3.9 0-7 directories

The priority 0-7 subdirectories in each holding queue in the mshold subdirectory correspond to
the priority 0-7 subdirectories located in each domain, post office, or gateway. See the following
directory structures for more information about its priority 0-7 subdirectories:

 Section 7.1, “Domain Directory,” on page 63

 Section 7.2, “Post Office Directory,” on page 70

7.3.10 mtaname files

The mtaname files in the closed location holding queues provide the name associated with the
domain, post office, or gateway holding queue. They can help you check links between MTAs in
ConsoleOne without going to the MTA agent console to determine the location name. To associate a
location name with its holding queue directory from the MTA agent console, click Configuration
Status > select the location > click Details.

7.3.11 gwvsscan directory

The gwvsscan subdirectory is the working directory where third-party virus scanning programs
that snap in to the MTA can perform their processing.

7.3.12 mtaconv directory

The mtaconv subdirectory is the working directory where the MTA converts GroupWise 7.x, 6.x,
and 5.x messages to 4.x format for transfer to a GroupWise 4.x system. After the conversion is
finished, this directory should be empty.

7.4 Internet Agent Queue Directory

The following directories and files are found under the \domain\wpgate\ structure for the
Internet Agent after the software has been installed and the Internet Agent has processed messages.

Message Transfer/Storage Directories 85

domain\wpgate\gwia GroupWise Internet Agent home directory

000.prc
cmd
gwwork

mmddlog.nnn
acct
set
stat
proc
pulse.tmp

wpcsin

0-7

wpcsout

gwixxxx

0-7

problem

gwhold

qfiles

gwprob Hold directory for damaged inbound messages

gwchars Directory for character conversion tables

save Directory for old configuration files from reinstalls or upgrades

Internet Agent message processing directory
Not currently used
Hold directory for temporary files used during processing
Log files
Accounting file
Settings file for screen colors, log levels, and so on
Statistics file for Internet Agent operation
Process lock file indicating that the Internet Agent is running
Temporary file to verify Internet Agent operation

MTA input queue directory
Message priority subdirectories

MTA output queue
System-defined directory
Message priority subdirectories
Hold directory for damaged outbound messages

Message hold directory
Delayed delivery hold directory

gwia.cfg
route.cfg
gwauth.cfg
mimetype.cfg
exepath.cfg
frgnames.cfg
xspam.cfg

gwac.db
gwac.dc

preamble.txt

preamble.all

blocked.txt
statusxx.xml

gwia SMTP service (daemon) home directory

send
receive
result

defer

work

Internet Agent configuration file for startup switches
Route configuration file to customize routing
Host authentication configuration file
MIME encoding configuration file for various file types
Configuration file pointing ConsoleOne to the gwia.cfg file
Foreign domain name configuration file
Anti-spam configuration file

Access control database
Database dictionary file used to create the access control database

Message for recipients who lack a MIME-compliant mail reader
Preamble message in various languages

List of blocked Internet sites
File for customizing status messages

Outbound hold directory for converting messages into Internet format
Incoming hold directory for converting messages into GroupWise format
Send and result files to confirm transmission

Hold directory for re-queued and deferred messages
Schedule files for SMTP service operations on deferred messages

86 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

dsnhold Delivery Status Notification (DSN) hold directory

7.4.1 domain\wpgate\gwia directory

The domain\wpgate\gwia directory is the GroupWise Internet Agent home directory where
Internet Agent configuration files and queue directories are located. The name is established when
you install the Internet Agent. The default is wpgate\gwia in the domain directory. You can
change the location using the /home startup switch in the Internet Agent configuration file
(gwia.cfg).

000.prc directory

The Internet Agent uses the 000.prc directory to process messages.

gwwork directory

The gwwork directory stores temporary files created by the Internet Agent as it converts and builds
messages for transfer across the Internet.

mmddlog.nnn file

The mmddlog.nnn files hold error and status messages about the functioning of the Internet
Agent. The Internet Agent creates a log file each day with a unique name, where mm is the month,
dd is the day, and nnn is a sequential number indicating the sequence of log files in a single day. For
more information log files, see “Using Internet Agent Log Files” in “Internet Agent” in the

GroupWise 7 Administration Guide.

acct file

The acct file contains information about the messages the Internet Agent sends each day. It is e­mailed to the accounts each day at midnight. For more information about the accounting files, see
“Tracking Internet Traffic with Accounting Data” in “Internet Agent” in the GroupWise 7

Administration Guide.

set file

The set file stores Internet Agent console settings such as color, log settings, and so on. For more
information, see “Using the Internet Agent Server Console”.

stat file

The stat file stores statistics about the Internet Agent’s functioning. For information about the
statistics provided by the Internet Agent, see “Statistics” in “Internet Agent” in the GroupWise 7

Administration Guide.

proc file

The proc file is the lock file for the Internet Agent process. The proc file is opened and locked
when the Internet Agent starts. This prevents multiple Internet Agents from being started for the
same domain.

Message Transfer/Storage Directories 87

pulse.tmp file

The pulse.tmp file is re-created by the Internet Agent every time it completes a cycle (after an
idle loop). If you are not at the Internet Agent console but need to know if the Internet Agent is
running, you can delete the pulse.tmp file. If the Internet Agent is running, it re-creates the file.

wpcsin directory

For a mapped/UNC link, the Internet Agent places inbound messages in one of the wpcsin priority
subdirectories (0-7). Most messages go in the 4 directory, although some administrative and status
messages might go in other directories. The Message Transfer Agent retrieves the messages and
delivers them to the proper destinations.

For a TCP/IP link, the Internet Agent and the MTA communicate by way of TCP/IP rather than by
transferring message files. For a comparison, see Chapter 4, “Message Delivery to and from the

Internet,” on page 35.

wpcsout directory

For a mapped/UNC link, the wpcsout directory is the MTA output queue as well as being the
Internet Agent input queue.

For a TCP/IP link, the Internet Agent and the MTA communicate by way of TCP/IP rather than by
transferring message files. For a comparison, see Chapter 4, “Message Delivery to and from the

Internet,” on page 35.

gwixxxx directory

The gwixxxx directory is a system-defined directory, where gwi represents the first three letters of
the Internet Agent object name as defined during installation and displayed in ConsoleOne, and xxxx
is a randomly-generated string. Here, the Message Transfer Agent places outbound messages in the
appropriate 0-7 priority subdirectory for the Internet Agent to retrieve and process.

problem directory

The problem directory holds messages that the MTA cannot process.

You should check this directory periodically for problem files, resolve the problem, then place the
files back into the appropriate queue for continued processing. For assistance, see “Message Is

Dropped in the problem Directory in the Domain” in “Strategies for Message Delivery Problems” in

the GroupWise 7 Troubleshooting 2: Solutions to Common Problems.

gwhold directory

The gwhold directory holds messages that are scheduled for delayed delivery.

qfiles directory

The qfiles directory holds messages that cannot be sent during the current Send/Receive cycle.
The messages are queued to this directory until the next cycle.

The delayed delivery messages waiting in the qfiles directory remain in encrypted format until
the Internet Agent transfers them to the send directory for processing by the SMTP service.

88 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

gwprob directory

The Internet Agent uses the gwprob directory for messages it cannot process. These are usually
messages that have been damaged during transmission or that contain incorrectly formed MIME
data.

These messages cannot be recovered. You can delete them to conserve disk space.

gwchars directory

This directory contains conversion tables that the Internet Agent uses to convert message
attachments between character sets.

save directory

If you reinstall or upgrade the Internet Agent, your old configuration files are copied to the save
directory as a backup. If you reinstall or upgrade repeatedly, the files are overwritten each time.

gwia.cfg file

The gwia.cfg file is the Internet Agent configuration file that contains startup switches. Some
switches are set during installation. You can set others as needed. For more information, see “Using

Internet Agent Startup Switches” in “Internet Agent” in the GroupWise 7 Administration Guide.

NetWare: The NetWare Internet Agent uses the gwia.cfg file created in sys:\system during

installation. The gwia.cfg file under the domain is just a boilerplate file with no
switches set during installation.

Linux: The Linux Internet Agent uses the gwia.cfg file created in /opt/novell/

groupwise/agents/share during installation. The gwia.cfg file under the domain

is just a boilerplate file with no switches set during installation.

Windows: Only the Windows Internet Agent actually uses the gwia.cfg file under the domain.

route.cfg file

The route.cfg file enables you to customize routing for specific hosts. For more information, see
“Using a Route Configuration File” in “Internet Agent” in the GroupWise 7 Administration Guide.

gwauth.cfg file

The gwauth.cfg file enables the Internet Agent to log in to SMTP hosts that require
authentication. For more information, see “SMTP Host Authentication” in “Internet Agent” in the

GroupWise 7 Administration Guide.

mimetype.cfg file

The mimetype.cfg file enables you to customize MIME content-type mappings for various
attachment types. For more information, see “Customizing MIME Content-Type Mappings” in
“Internet Agent” in the GroupWise 7 Administration Guide

Message Transfer/Storage Directories 89

exepath.cfg file

The exepath.cfg file is used by ConsoleOne to locate the gwia.cfg file. This enables

®

ConsoleOne to write any configuration setting changes to the gwia.cfg file or update Novell

TM

eDirectory

with any changes from the file. The file must contain the path to the gwia.cfg file in
the sys:\system directory on NetWare, the /opt/novell/groupwise/agents/share
directory on Linux, or the domain\wpgate\gwia directory on Windows.

frgnames.cfg file

The frgnames.cfg file lets you list more Internet domain names than can fit in the Foreign ID
field on the Identification page of the Internet Agent object in ConsoleOne. For more information,
see “Configuring How the Internet Agent Handles E-Mail Addresses” in “Internet Agent” in the

GroupWise 7 Administration Guide.

xspam.cfg file

The xspam.cfg file lists “X” header fields that your anti-spam service writes to the MIME header,
along with the values that flag the message as spam. The Internet Agent examines the MIME header
for any field listed in the xspam.cfg file. When a match occurs, the message is marked for
handling by the GroupWise client Junk Mail Handling feature. For more information, see
“Customized Spam Identification” in “Internet Agent” in the GroupWise 7 Administration Guide.

gwac.db file

The gwac.db file is the access control database that stores information about the classes of service
you have created. For more information, see “Maintaining the Access Control Database” in
“Internet Agent” in the GroupWise 7 Administration Guide.

gwac.dc file

The gwac.dc file is the data dictionary file from which the gwac.db is created.

preamble.txt file

The preamble.txt file is an ASCII text file that is automatically included with any MIME
multipart message and is displayed when the message recipient lacks a MIME-compliant mail
reader. For more information, see “Customizing MIME Preamble Text” in “Internet Agent” in the

GroupWise 7 Administration Guide.

preamble.all file

The preamble.all file contains the preamble text in multiple languages. For more information,
see “Customizing MIME Preamble Text” in “Internet Agent” in the GroupWise 7 Administration

Guide.

blocked.txt file

The blocked.txt file contains a list of Internet sites that you have added to the Prevent
Messages From list for your default class of service in ConsoleOne. For more information, see
“Controlling User Access to the Internet” in “Internet Agent” in the GroupWise 7 Administration

Guide.

90 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

statusxx.xml file

The statusxx.xml file enables you to customize the messages that users receive regarding
message delivery status. For more information, see “Customizing Delivery Status Notifications” in
“Internet Agent” in the GroupWise 7 Administration Guide.

7.4.2 gwia directory

The gwia directory is the SMTP service (daemon) home directory where messages are converted
between GroupWise format and Internet format. On NetWare and Linux, the default location is
wpgate/gwia, the same as the Internet Agent home directory. On Windows, the default location
is the Internet Agent installation directory. You can change the location using the /dhome startup
switch in the Internet Agent configuration file (gwia.cfg).

send directory

The Internet Agent SMTP service places outbound messages in the send directory after they have
been converted out of GroupWise format into SMTP format. The SMTP service polls the send
directory and sends any messages to the destination SMTP host.

receive directory

The Internet Agent SMTP service places inbound messages in the receive directory, converts
them into GroupWise format, and then passes them to the Message Transfer Agent by placing them
in the wpcsin directory.

result directory

When the Internet Agent SMTP service processes the message, it builds a file, r*.*, in the
result directory that contains several lines of comments and SMTP reply codes, which might

indicate possible errors or confirm correct transmission. After the Internet Agent SMTP service has
completed the transmission with the destination host, it moves another file, s*.* from the send
directory to the result directory. The filenames for both files are identical, except for the first
letter, which is either “s” or “r”. The s*.* file is the converted message file. The SMTP service
looks at the “s” and “r” files in the result directory and compares the conversation. If the r*.*
file contains the correct (250 OK) SMTP reply codes, the SMTP service deletes the file and sends a
transferred status message to the user’s Sent Items folder in the GroupWise client.

defer directory

The defer directory holds messages that are deferred and re-queued according to the Retry
Schedule. If the Internet Agent SMTP service receives a temporary error, such as Host Down, it
places the message in the defer directory for a specified time, then transfers the file to the send
directory for another attempt at sending to the Internet. For more information, see “Configuring

Basic SMTP/MIME Settings” in “Internet Agent” in the GroupWise 7 Administration Guide.

dsnhold directory

The dsnhold directory stores header information for inbound messages that request delivery status
notifications. For more information, see “Using Extended SMTP (ESMTP) Options” in “Internet

Agent” in the

GroupWise 7 Administration Guide.

Message Transfer/Storage Directories 91

7.5 WebAccess Agent Queue Directory

The following directories and files are found under the \domain\wpgate\ structure for the
WebAccess Agent after the software has been installed and the WebAccess Agent has processed
messages.

domain\wpgate\webac70a GroupWise WebAccess Agent home directory

000.prc
gwwork

mmddweb.nnn

wpcsin

0-7

wpcsout

webxxxx

0-7

problem

gwhold
gwprob

template Directory for templates for viewing documents

commgr.cfg
comint.cfg
mimetype.cfg

gwac.db
gwac.dc

WebAccess Agent log file processing directory
Hold directory for temporary files used during processing
WebAccess Agent log files

MTA input queue directory
Message priority subdirectories

MTA output queue
System-defined directory for the WebAccess Agent
Message priority subdirectories
Hold directory for damaged outbound messages

Hold directory for delayed delivery messages
Hold directory for damaged inbound messages

Communications Manager configuration file
Communications initialization configuration file
MIME encoding configuration file for various file types

Access control database
Database dictionary file used to create the gwac.db file

7.5.1 domain\wpgate\webac70a directory

The domain\wpgate\webac70a directory is the WebAccess Agent home directory where
WebAccess Agent configuration files and queue directories are located. The name is established
when you install the WebAccess Agent. The default is wpgate\webac70a in the domain
directory. You can change the location using the /home startup switch in the WebAccess Agent
configuration file (webac70a.waa in the WebAccess Agent installation directory).

7.5.2 000.prc directory

The NetWare and Windows WebAccess Agents use the 000.prc directory to store log files.

On Linux, the 000.prc directory is located under /var/log.

mmddlog.nnn file

The mmddlog.nnn files hold error and status messages about the functioning of the WebAccess
Agent. The WebAccess Agent creates a log file each day with a unique name, where mm is the
month, dd is the day, and nnn is a sequential number indicating the sequence of log files in a single
day. For more information about log files, see “Controlling WebAccess Agent Logging” in
“WebAccess” in the GroupWise 7 Administration Guide.

92 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

7.5.3 wpcsin directory

No longer used. The WebAccess Agent and the MTA communicate by way of TCP/IP and do not
need queue directories.

7.5.4 wpcsout directory

No longer used.

7.5.5 gwhold directory

No longer used.

7.5.6 gwprob directory

No longer used.

7.5.7 template directory

The template directory holds the HTML templates used for viewing documents in HTML
format.

7.5.8 commgr.cfg file

The commgr.cfg file in the WebAccess Agent queue directory contains information for
communication between the WebAccess Agent and the WebAccess Application, including the IP
address and port where the WebAccess Agent is running, the number of threads that are running,
and the encryption key for the WebAccess Agent. This communications information is gathered
during installation. For more information, see “Configuring the GroupWise Service Provider” in
“WebAccess” in the GroupWise 7 Administration Guide.

As part of the installation process, the commgr.cfg file is automatically copied to the Web server
installation (sys:\novell\webaccess on NetWare, /opt/novell/groupwise/

webaccess on Linux, and c:\novell\webaccess on Windows). The copies are

synchronized automatically by the WebAccess Application. The commgr.cfg file is also copied to
the webpublisher subdirectory on the Web server.

7.5.9 comint.cfg file

The comint.cfg file in the WebAccess Agent queue directory is read by the WebAccess Agent
on startup. It contains the same communications information as the commgr.cfg file and is
synchronized with it automatically.

7.5.10 mimetype.cfg file

The mimetype.cfg file enables you to customize MIME content-type mappings for various
attachment types. The WebAccess Agent handles this just as the Internet Agent does. For more
information, see “Customizing MIME Content-Type Mappings” in “Internet Agent” in the

GroupWise 7 Administration Guide

Message Transfer/Storage Directories 93

7.5.11 gwac.db file

The gwac.db file is the access control database that stores information about the classes of service
you have created. For more information, see “Maintaining the Access Database” in “WebAccess” in
the GroupWise 7 Administration Guide.

7.5.12 gwac.dc file

The gwac.dc file is the data dictionary file from which the gwac.db is created.

7.6 Caching Mailbox Directory

\novell\groupwise\gwxxxxxx GroupWise Caching mailbox

rofdata Caching mailbox database directory

msg.db
user.db
wprof.db
wprof.dc

ngwguard.db
ngwguard.dc
ngwguard.rfl
ngwguard.fbk

puxxxxx.db Database for shared folders

ngwcheck.db
gwcheckn.log

gwdms

dmsh.db
dmxxnn01-FF.db

docs
index

index QuickFinder index for messages in the Caching mailbox

wpcsin

0-7

wpcsout\ofs

0-7

Cached message database
Cached user database
Cached Address Book
Data dictionary for cached Address Book

Guardian database
Data dictionary for guardian database
Guardian database roll forward log
Guardian database “fall back” file

GroupWise Check database
Log file created by the Repair Mailbox feature

Document Management Services directory
Shared DMS database
Document databases
Subdirectory for documents in the Caching mailbox
QuickFinder index for documents in the Caching mailbox

Input queue for the Caching mailbox
Priority subdirectories

Output queue for the Caching mailbox
Priority subdirectories

wpgwsend
wpgwrecv

remoten.log Connection log

Output queue to the Online mailbox
Input queue from the Online mailbox

94 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

7.6.1 \novell\groupwise\gwxxxxxx directory

Your GroupWise Caching mailbox is a directory structure that functions similarly to a post office.
Like a post office, it contains databases and input/output queues. It is created in the directory where
the GroupWise client is installed, which is typically \novell\groupwise.

The same directory structure is used for a Caching mailbox as for a Remote mailbox. However, a
Caching mailbox is a complete copy of your Online mailbox, but you can restrict what gets
downloaded into your Remote mailbox.

7.6.2 rofdata directory

The rofdata directory contains the databases accessed by the GroupWise Windows client when
running in Caching mode. The databases in rofdata are similar to the databases found in post
offices. For comparison, see Section 7.2, “Post Office Directory,” on page 70.

Historical Note: An earlier version of the GroupWise client Remote mode, designed by WordPerfect
Corporation (WPCorp), was named WP Office Remote. Hence, the rof in rofdata. Some
naming conventions were originally preserved for backward compatibility.

msg.db file

The msg.db file is the cached equivalent of the msgnnn.db files in the ofmsg directory in your
post office. The msg.db file contains copies of messages from your Online mailbox.

user.db file

The user.db file is the cached equivalent of the userxxx.db files in the ofuser directory in
your post office.

wprof.db file

The wprof.db file contains the cached version of the GroupWise Address Book.

Historical Note: An earlier version of the GroupWise client Remote mode, designed by WordPerfect
Corporation (WPCorp), was named WP Office Remote. Hence, the wprof in wprof.db. Some
naming conventions have been preserved for backward compatibility.

wprof.dc file

The wprof.dc file is the data dictionary for the cached Address Book (wprof.db).

Historical Note: An earlier version of the GroupWise client Remote mode, designed by WordPerfect
Corporation (WPCorp), was named WP Office Remote. Hence, the wprof in wprof.dc. Some
naming conventions have been preserved for backward compatibility.

ngwguard.db file

The ngwguard.db file is the guardian database for your Caching mailbox. It is parallel in function
to the ngwguard.db file in the post office.

Message Transfer/Storage Directories 95

ngwguard.dc file

The ngwguard.dc file is the data dictionary for building the databases in the GroupWise Caching
mailbox. It is parallel in function to the ngwguard.dc file in the post office.

ngwguard.rfl file

The ngwguard.rfl file is a roll-forward transaction log of every database transaction that has
taken place since the last copy of the ngwguard.fbk file was created. It is parallel in function to
the ngwguard.rfl file in the post office.

ngwguard.fbk

The ngwguard.fbk file “fall back” copy of the ngwguard.db file. It is parallel in function to
the ngwguard.fbk file in the post office.

puxxxxx.db files

The puxxxxx.db files are databases for replicated items such as shared folders. These databases
prevent conflicts between user names of shared items from users in other post offices and user
names in your own post office. They are parallel to the puxxxxx.db files in the post office.

ngwcheck.db file

The ngwcheck.db file tracks GroupWise Check threads and the databases being checked. In the
GroupWise client, GroupWise Check is run using Tools > Repair Mailbox.

gwcheckn.log

The gwcheckn.log file records any errors that occurred during mailbox repair. For assistance
with GroupWise Check errors, see “GroupWise Check Error Codes” in “Administration Error

Messages” in the GroupWise 7 Troubleshooting 1: Error Messages.

gwdms directory

The gwdms directory is the Document Management Services directory. It contains information
about the libraries in your GroupWise system. It has the same structure as the gwdms subdirectory
in the post office.

dmsh.db file

The dmsh.db file is a database shared by all libraries that contains a list of all available libraries
and lookup tables for each library.

dmxxnn01-FF.db files

The dmxxnn01-FF.db files are databases for library and document information. They are parallel
to the dmxxnn01-FF.db files in the post office.

docs directory

The docs directory holds cached copies of the documents in your Online mailbox.

96 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

index directory

The index directory under the gwdms directory contains the QuickFinder index for the documents
in your Caching mailbox.

index directory

The index directory under the rofdata directory contains the QuickFinder index for the
messages in your Caching mailbox.

7.6.3 wpcsin directory

The wpcsin subdirectory is the input queue for the connection that transfers messages to your
GroupWise system for delivery. Messages from the GroupWise client in Caching mode are
processed through the priority 1 subdirectory of wpcsin.

When you send a message in Caching mode, the GroupWise client connects to your GroupWise
system. It polls the wpcsin\1 directory and compresses any outgoing messages, requests, or both
into a file. If the compressed file totals over 50 KB, additional compressed files are created. The
GroupWise client then moves the compressed files into the wpgwsend directory.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect
Corporation (WPCorp). The Message Transfer Agent (MTA) was originally named the Connection
Server (CS). Hence, the directory name wpcsin for the input queue, although the MTA is not
involved in processing messages in your Caching mailbox. Some naming conventions were
originally preserved for backward compatibility.

0-7 directories

The priority 0-7 subdirectories in the connection input queue (wpcsin) parallel those found in the

wpcsin directory in your post office.

7.6.4 wpcsout\ofs directory

The wpcsout\ofs directory is the output queue for the connection that transfers messages from
your Online mailbox. Messages from your GroupWise system are processed through the priority 1
subdirectory of wpcsout\ofs.

The GroupWise client scans the wpcsout\ofs\1 subdirectory and updates the user.db and

msg.db files with the information received from your Online mailbox.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect
Corporation (WPCorp). The Message Transfer Agent (MTA) was originally named the Connection
Server (CS). Hence, the directory names wpcsin and ofs for the input queue, though the MTA is
not involved in processing messages in your Remote mailbox. Some naming conventions were
originally preserved for backward compatibility.

0-7 directories

The priority 0-7 subdirectories in the connection output queue (wpcsout\ofs) parallel those
found in the ofs directory in your post office.

Message Transfer/Storage Directories 97

7.6.5 wpgwsend directory

The wpgwsend directory holds compressed files that contain outgoing messages, requests, or both.
When a connection to your GroupWise system is established, the GroupWise client uploads the files
to your Online mailbox.

Historical Note: WP Office Remote, the predecessor of the GroupWise client Remote mode, was
originally designed by WordPerfect Corporation (WPCorp). Hence, the name wpgwsend. Some
naming conventions were originally preserved for backward compatibility.

7.6.6 wpgwrecv directory

The wpgwrecv directory holds compressed files that contain messages or other information that
have been received from your Online mailbox. The GroupWise client decompresses the files and
places the message files into the wpcsout\ofs\1 directory.

Historical Note: WP Office Remote, the predecessor of the GroupWise client Remote mode, was
originally designed by WordPerfect Corporation (WPCorp). Hence, the name wpgwrecv. Some
naming conventions were originally preserved for backward compatibility.

7.6.7 remoten.log

The remoten.log files are saved versions of the connection logs you can view in the GroupWise
client by clicking Accounts > Connection Log. These log files can be useful for troubleshooting
problems with your connection to your Online mailbox.

7.7 Remote Mailbox Directory

remote_mailbox GroupWise mailbox on a remote computer

rofdata

msg.db
user.db
wprof.db
wprof.dc

ngwguard.db
ngwguard.dc
ngwguard.rfl
ngwguard.fbk

puxxxxx.db Database for shared folders

ngwcheck.db
gwcheckn.log

gwdms

dmsh.db
dmxxnn01-FF.db

docs
index

Remote database directory
Remote message database
Remote user database
Remote Address Book
Data dictionary for Remote Address Book

Remote guardian database
Data dictionary for Remote guardian database
Guardian database roll forward log
Guardian database “fall back” file

GroupWise Check database
Log file created by the Repair Mailbox feature

Document Management Services directory
Shared DMS database
Document databases
Subdirectory for documents in the Remote mailbox
QuickFinder index for Remote mailbox

98 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure

index QuickFinder index for messages in the Remote mailbox

wpcsin

0-7

wpcsout\ofs

0-7

wpgwsend
wpgwrecv

remoten.log Remote connection log

Input queue for the GroupWise client in Remote mode
Priority subdirectories

Output queue for the GroupWise client in Remote mode
Priority subdirectories

Output queue to master mailbox
Input queue from master mailbox

7.7.1 remote_mailbox directory

The GroupWise remote mailbox is a directory structure that functions similarly to a post office. Like
a post office, it contains databases and input/output queues.

7.7.2 rofdata directory

The rofdata subdirectory in the remote mailbox directory contains the databases accessed by the
GroupWise client in Remote mode. The databases in rofdata are similar to the databases found in
post offices.

Historical Note: An earlier version of the GroupWise client Remote mode, designed by WordPerfect
Corporation (WPCorp), was named WP Office Remote. Hence, the rof in rofdata. Some
naming conventions were originally preserved for backward compatibility.

msg.db file

The msg.db file in the remote data directory (rofdata) in the remote mailbox directory is the
remote equivalent of the msgnnn.db files in the ofmsg directory in the post office where your
master mailbox is located. The msg.db file contains messages you have downloaded from your
master mailbox.

user.db file

The user.db file in the remote data directory (rofdata) in the remote mailbox directory is the
remote equivalent of the userxxx.db files in the ofuser directory in the post office where your
master mailbox is located. The user.db file contains user information you have downloaded from
your master mailbox.

wprof.db file

The wprof.db file in the remote data directory (rofdata) in the Remote mailbox directory
contains the remote version of the GroupWise Address Book if you have downloaded it.

Historical Note: An earlier version of the GroupWise client Remote mode, designed by WordPerfect
Corporation (WPCorp), was named WP Office Remote. Hence, the wprof in wprof.db. Some
naming conventions have been preserved for backward compatibility.

Message Transfer/Storage Directories 99

wprof.dc file

The wprof.dc file in the remote data directory (rofdata) in the Remote mailbox directory is the
data dictionary for the remote Address Book (wprof.db).

Historical Note: An earlier version of the GroupWise client Remote mode, designed by WordPerfect
Corporation (WPCorp), was named WP Office Remote. Hence, the wprof in wprof.dc. Some
naming conventions have been preserved for backward compatibility.

ngwguard.db file

The ngwguard.db file in the remote data directory (rofdata) in the Remote mailbox directory
is the guardian database for the remote GroupWise mailbox. It is parallel in function to the

ngwguard.db file in the post office.

ngwguard.dc file

The ngwguard.dc file in the remote data directory (rofdata) in the Remote mailbox directory
is the data dictionary for building the databases in the remote GroupWise mailbox. It is parallel in
function to the ngwguard.dc file in the post office.

ngwguard.rfl file

The ngwguard.rfl file is a roll-forward transaction log of every database transaction that has
taken place since the last copy of the ngwguard.fbk file was created. It is parallel in function to
the ngwguard.rfl file in the post office.

ngwguard.fbk

The ngwguard.fbk file “fall back” copy of the ngwguard.db file. It is parallel in function to
the ngwguard.fbk file in the post office.

puxxxxx.db files

The puxxxxx.db files in the remote data directory (rofdata) in the Remote mailbox directory
are databases for replicated items such as shared folders. These databases prevent conflicts between
user names of shared items from users in other post offices and user names in the Remote user’s post
office. They are parallel to the puxxxxx.db files in the post office.

ngwcheck.db file

The ngwcheck.db file tracks GroupWise Check threads and the databases being checked. In
Remote mode in the GroupWise client, GroupWise Check is run using Tools > Repair Mailbox.

gwcheckn.log

The gwcheckn.log file records any errors that occurred during Remote mailbox repair. For
assistance with GroupWise Check errors, see “GroupWise Check Error Codes

” in “Administration

Error Messages” in the GroupWise 7 Troubleshooting 1: Error Messages.

100 GroupWise 7 Troubleshooting 3: Message Flow and Directory Structure