The following types of information are stored in the post office:
All databases in the post office should be backed up regularly. How often you back up GroupWise databases depends on the reliability of your network and hardware. See Section 31.2, Backing Up a Post Office.
The post office database (wphost.db) contains all administrative information for the post office, including a copy of the GroupWise Address Book. This information is necessary for users to send messages to others in the GroupWise system.
GroupWise messages are made up of three parts:
Message Header: The message header contains addressing information including the sender’s address, recipient’s address, message priority, status level, and a pointer that links the header to the message body.
Message Body: The message body contains the message text in an encrypted format and a distribution list containing user IDs of the sender and recipients.
File Attachments (optional): File attachments can be any type of file that is attached to the message.
The message store consists of directories and databases that hold messages. The message store is shared by all members of the post office so only one copy of a message and its attachments is stored in the post office, no matter how many members of the post office receive the message. This makes the system more efficient in terms of message processing, speed, and storage space.
All information in the message store is encrypted to prevent unauthorized access.
The message store contains the following components:
Each member of the post office has a personal database (userxxx.db) which represents the user’s mailbox. The user database contains the following:
Message header information
Pointers to messages
Personal address books
Junk Mail lists
When a member of another post office shares a folder with one or more members of the local post office, a “prime user” database (puxxxxx.db) is created to store the shared information. The “prime user” is the owner of the shared information.
Local user databases and prime user databases are stored in the ofuser directory in the post office.
Each member of the post office is arbitrarily assigned to a message database (msgnnn.db) where the body portions of messages are stored. Many users in a post office share a single message database. There can be as many as 255 message databases (numbered 0 through 254) in a post office. Message databases are stored in the ofmsg directory in the post office.
Historical Note: Prior to GroupWise 7, the POA created a maximum of 25 message databases per post office. The current maximum of 255 message databases speeds up message delivery and minimizes user impact if a database is damaged.
Outgoing messages from local senders are stored in the message database assigned to each sender. Incoming messages from users in other post offices are stored in the message database that corresponds to the message database assigned to the sender in his or her own post office. In each case, only one copy of the message is stored in the post office, no matter how many members of the post office it is addressed to.
The attachments directory (offiles) contains subdirectories that store file attachments, message text, and distribution lists that exceed 2 KB. Items of this size are stored more efficiently as files than as database records. The message database contains a pointer to where each item is found.
The guardian database (ngwguard.db) serves as the master copy of the data dictionary information for the following subordinate databases in the post office:
User databases (userxxx.db)
Message databases (msgnnn.db)
Prime user databases (puxxxxx.db)
Library databases (dmsh.db and dmxxnn01-FF.db)
The guardian database is vital to GroupWise functioning. Therefore, the POA has an automated back-up and roll-forward process to protect it. The POA keeps a known good copy of the guardian database called ngwguard.fbk. Whenever it modifies the ngwguard.db file, the POA also records the transaction in the roll-forward transaction log called ngwguard.rfl. If the POA detects damage to the ngwguard.db file on startup or during a write transaction, it goes back to the ngwguard.fbk file (the “fall back” copy) and applies the transactions recorded in the ngwguard.rfl file to create a new, valid and up-to-date ngwguard.db.
In addition to the POA back-up and roll-forward process, you should still back up the ngwguard.db, ngwguard.fbk, and ngwguard.rfl files regularly to protect against media failure. Without a valid ngwguard.db file, you cannot access your e-mail. With current ngwguard.fbk and ngwguard.rfl files, a valid ngwguard.db file can be rebuilt should the need arise.
The ngwguard.dc file is the structural template for building the guardian database and its subordinate databases. Also called a dictionary file, the ngwguard.dc file contains schema information, such as data types and record indexes. If this dictionary file is missing, no additional databases can be created in the post office.
Each post office contains agent input/output queues where messages are deposited and picked up for processing by the POA and the MTA. The MTA transfers messages into and out of the post office, while the POA handles message delivery.
For illustrations of the processes presented below, see GroupWise 8 Troubleshooting 3: Message Flow and Directory Structure.
The MTA output queue in each post office is the post_office\wpcsout directory.
If the MTA has a mapped or UNC link to the post office, the MTA writes user messages directly into its output queue, which requires write access to the post office. If the MTA has a TCP/IP link to the post office, the MTA transfers user messages to the POA by way of TCP/IP. The POA then stores the messages in the MTA output queue on behalf of the MTA, so the MTA does not need write access to the post office.
The post_office\wpcsout\ofs subdirectory is where the MTA transfers user messages for delivery by the POA to users’ mailboxes in the local post office.
The MTA post_office\wpcsout\ads subdirectory is where the MTA transfers administrative messages instructing the POA admin thread to update the post office database (wphost.db).
The POA input queue in each post office is the post_office\wpcsout directory, which is the same as the MTA output queue.
The post_office\wpcsout\ofs subdirectory is where the POA picks up user messages deposited there by the MTA and updates the local message store, so users receive their messages.
The post_office\wpcsout\ads subdirectory is where the POA admin thread picks up administrative messages deposited there by the MTA and updates the post office database (wphost.db).
The POA output queue (post_office\wpcsin) is where the POA deposits user messages for the MTA to transfer to other domains and post offices.
Historical Note: In earlier versions of GroupWise, the GroupWise client wrote user messages to the POA output queue when using direct access to the post office. In GroupWise 6.x and later, client/server access to the post office is the preferred method.
The MTA input queue in each post office (post_office\wpcsin) is the same as the POA output queue. The MTA picks up user messages deposited there by the POA and transfers them to other domains and post offices.
For a mapped or UNC link between the domain and post office, the MTA requires read/write access rights to its input/output queues in the post office. For a TCP/IP link, no access rights are required because messages are communicated to the MTA by way of TCP/IP.
A library is a collection of documents and document properties stored in a database system that can be managed and searched. You do not need to set up libraries unless you are using GroupWise Document Management Services (DMS). See Section VII, Libraries and Documents.
The databases for managing libraries are stored in the gwdms directory and its subdirectories in the post office.
The dmsh.db file is a database shared by all libraries in the post office. It contains information about where each library in the post office is located.
Each library has its own subdirectory in the gwdms directory. In each library directory, the dmxxnn01-FF.db files contain information specific to that library, such as document properties and what users have rights to access the library.
The actual documents in a library are not kept in the library databases. They are kept in a document storage area, which consists of a series of directories for storing document files. Documents are encrypted and stored in BLOBs (binary large objects) to make document management easier. A document, its versions, and related objects are stored together in the same BLOB.
A document storage area might be located in the post office directory structure, or in some other location where more storage space is available. If it is located in the post office, the document storage area can never be moved. Therefore, storing documents in the post office directory structure is not usually recommended. If it is stored outside the post office, a document storage area can be moved when additional disk space is required.