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 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. For more information, see Native GroupWise Encryption.
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:
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 (msgnn.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 25 message databases in a post office. Message databases are stored in the ofmsg directory in the post office.
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 a reference for the following subordinate databases in the post office:
The guardian database stores information that is common among all databases, thus eliminating duplication of information. The subordinate databases reference information stored in the guardian database. The benefits of the guardian database include the following:
Single Reference Point: The guardian database stores information for each post office. Instead of storing the dictionary information in multiple dictionary databases, it is stored once in the guardian database.
Increased Performance: When the information in the guardian database is accessed, it is written to cache memory. Each subsequent request can be handled with information already available in cache memory, which is faster than disk access.
Tracking Attachments and Documents: When an attachment or document becomes orphaned (loses pointers to the message or profile), the guardian database is used to re-locate the origination of the attachment or document.
GroupWise Remote Client Management: When a user starts the GroupWise client in Remote mode, a local guardian database is created on the user's workstation to store information similar to the guardian database in the remote user's post office in the GroupWise system.
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 regularly 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, you can rebuild a valid ngwguard.db file should the need arise. See Backing Up a Post Office.
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 extension information, such as administrator-defined fields, 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 "Message Delivery to a Different Post Office" and "Message Delivery to a Different Domain" in GroupWise 6.5 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, 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 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, document storage areas can be moved when additional disk space is required.