Knowledge Base

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

Article ID: 235362

Article Last Modified on 2/27/2007

APPLIES TO

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

This article was previously published under Q235362

SUMMARY

This is the first in a series of three Microsoft Knowledge Base articles on Novell GroupWise architecture. This article defines and describes a GroupWise domain and a GroupWise post office. Basic concepts of system organization are also discussed. The article focuses attention on GroupWise 5.5, although nearly all concepts apply to GroupWise 5.2 as well. Part 2 describes GroupWise message flow, and offers a strategy for troubleshooting message flow problems. Part 2 also includes a Glossary. Part 3 describes the GroupWise API Gateway in enough detail that Microsoft support professionals can troubleshoot and solve the majority of cases that involve the API Gateway.

To competently support migration from and connectivity to a foreign messaging system (such as Novell GroupWise, Lotus cc:Mail, or even Microsoft Mail), support professionals must have at least a modest understanding of the foreign system. An understanding of the basic concepts of architecture, system organization, file and folder structure, message store technology, and most importantly, message flow, are required for a Microsoft support professional to swiftly and professionally assist customers in configuring and troubleshooting their software. Although the Novell on-line documentation for GroupWise is outstanding, this series of articles proposes to make learning the fundamental concepts simpler. The articles not only summarize fundamental principles of GroupWise architecture, but they are also hyper-linked for quick reference. Readers can swiftly jump to the very sections they need to read.

Additional information about Novell GroupWise can be found in the online documentation at Novell's Web site:

http://www.novell.com/documentation/lg/gw55/index.html

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

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

GroupWise Message Flow

Basic Message Flow Concepts
Delivery to a Local Recipient
Delivery to a Different Post Office, Same Domain
Delivery to a Post Office in a Different Domain
Troubleshooting GroupWise Message Flow

Glossary

254353 GroupWise Architecture (Part 3): API Gateway

Introduction to the GroupWise API Gateway

How It Works in Brief

API Gateway Directory Structure
Message Flow

Mail Message from GroupWise to Foreign System (Outbound)
Mail Message from Foreign System to GroupWise (Inbound)
Message Flow for Directory Operations

API Header File Format
Troubleshooting the API Gateway

MORE INFORMATION

Introduction

GroupWise is a hierarchical, single-instance store, store-and-forward e-mail system. "Hierarchical" means that the directory structure is based on a hierarchy of masters and slaves. "Single-instance store" means that GroupWise uses a database technology which creates only a single instance of a message to multiple users on a post office. Finally, "store-and-forward" means that GroupWise delivers messages through the system by moving the mail from one file folder to another until it reaches its final destination.

GroupWise Domain Architecture

Domain Hierarchy

GroupWise organizes post offices into domains, and domains into a system. Directory replication between all servers and all domains is automatic, but cannot occur between systems without special configuration. One domain in the system is designated as the "primary" domain, which makes it the "master" within the system with full privileges to administer all objects in any domain. All other domains are called "secondary" domains. Secondary domain administrators have privileges to manage objects within their domain only. All system administration is done from the domain; none of it is done from the post office.

Directory Structure and Replication

In GroupWise 5.x, the directory is integrated with Novell Directory Services (NDS), though not fully so. NDS is the master directory, and all changes must be made through NDS. However, GroupWise maintains its own directory separate and distinct from NDS. Changes are made to the GroupWise 5.x system using NetWare Administrator (NWAdmin or NWAdmn32) and a GroupWise administration snap-in module that gets added during the installation of GroupWise 5.x.

NOTE: NetWare Administrator is much like Microsoft Management Console (MMC) in that it is a single location for administering the entire NetWare system. Like MMC, NetWare Administrator is extensible, allowing third parties to integrate snap-in dynamic-link libraries (DLLs) that add functionality to NetWare Administrator.

Objects in a GroupWise System

These include:

Users: Native GroupWise recipients (mailboxes). In GroupWise 5.x, users are NetWare users with associated GroupWise accounts. All administration of users is done through separate pages in the properties of a NetWare user object.
External entities: Similar in concept to "custom recipients" in Exchange.
Resources: A resource is a unique mailbox that represents either a place (for example, a conference room), or a resource (for example, an overhead projector). Each resource has an owner that has full proxy permissions to the resource mailbox.
Distribution Lists: Groups of users, for easy addressing.
Libraries: A document store in a GroupWise post office. GroupWise has built-in document management functionality, and the library is where all documents are stored for easy search and retrieval. The Microsoft equivalent is Microsoft SharePoint Portal Server 2001.
Post Offices: The central store for messages, documents, and client communication. Users connect to post offices. They do not connect to domains.
Domains: At one level, the domain is the central focus for administration of the directory and for message delivery both within and outside of the domain. Administrators connect to domains. They do not connect to post offices. At a higher level, a domain is merely a logical collection of post offices, similar in concept to the Exchange site.
Agents: The entities responsible for server-side functions, specifically, the message transfer agent (MTA), the post office agent (POA), and the administration agent (ADA). The MTA and ADA are domain objects. The POA is a post office object. In GroupWise 5.5, all ADA functions are combined into the MTA and POA so that the ADA is completely eliminated.
Gateways: Connectors to both native and foreign systems. GroupWise has many gateways which run on many platforms, some of which are: Async, X.25, X.400, SMTP (called the GroupWise Internet Access agent, or GWIA, in GroupWise 5.x), Web Access, OVVM, SNADS, MHS, Lotus Notes, Lotus cc:Mail, Microsoft Mail, Microsoft Exchange, FAX, Telephone Access, and a generic API gateway.

GroupWise Addressing

The address of every object in the system is known by its domain name, post office name, and user ID (equivalent to Alias). A fully qualified GroupWise address is in the following format:

domain.postoffice.userid

How GroupWise Replicates Directory Information

When a GroupWise object is created, modified, or deleted in NetWare Administrator, the change is written first to NDS.
In GroupWise 5.0 to 5.2, the ADA monitors activity in NDS and when it detects a change to a GroupWise object, it:
1. Makes changes to the local GroupWise domain database.
2. Then replicates that change to all the post offices within the local domain.
3. And finally replicates the change to all other domains that it is directly connected to.
If the local domain is a secondary domain, the change is written to the local database, but it is flagged as "unsafe" until the change can be written and accepted by the primary domain database.
GroupWise 5.5 performs directory replication the same way, only it is the MTA that monitors NDS for changes to GroupWise objects. All ADA functions are combined into the MTA and POA in GroupWise 5.5.

Back to Top

Domain Directory Structure

A GroupWise domain is identified by a set of databases and folders. In other words, "A domain IS where the domain database (Wpdomain.db) is." The implications here are that there can be multiple domains on a single server. The same holds true for post offices. The directory store (or "Address Book") for the domain is a database named Wpdomain.db. It is typically found in a folder called Wpdomain, although the root folder of the domain can be named virtually anything.

NOTE: Because GroupWise includes both Microsoft Windows NT Server and Novell NetWare NLM agents, a complex GroupWise system can be built out of a single NetWare server and many servers running Windows NT. The only component that must be on a NetWare server is the primary domain and the MTA for that domain. Because the MTA replicates changes to all post offices and domains that it knows about, there is no reason why those post offices and domains can't be on Windows NT servers. That means that secondary domains and post offices can be entirely located on computers running Windows NT, and that the GroupWise agent software for Windows NT can be run to service those domains and post offices. Furthermore, a single NDS tree can accommodate many GroupWise 5.x systems, so long as each GroupWise system is in its own unique container.

The directory structure of a GroupWise domain is as follows:

\WPDOMAIN               Root folder for Domain
    wphost.dc           Dictionary file for GroupWise 4.x post offices
    wpdomain.dc         Dictionary file for GroupWise 4.x domains
    gwdom.dc            Dictionary file for GroupWise 5.x domains
    gwpo.dc             Dictionary file for GroupWise 5.x post offices
    wpdomain.db         Domain database (the directory store)
   \MSLOCAL             MTA local folder (advanced messaging functions)
      \GWINPROG         Priority queues for messages in transit
      \MSHOLD           MTA holding folder for delayed messages
         \DOMAINMS      Local MTA holding queues (priority folders)
         \DOMxxxx       Holding queue for an adjacent domain
         \GATxxxx       Holding queue for a local gateway
         \POSxxxx       Holding queue for a local post office
   \WPCS                Legacy domain MTA software folder
   \WPOFFICE            Legacy client software distribution point
   \WPTOOLS             Legacy domain admin tools folder
   \WPCSIN              MTA input priority queues (from other domains)
      \0                Live interactive requests
      \1                Other interactive requests
      \2                High priority messages
      \3                High priority statuses
      \4                Normal priority messages
      \5                Normal priority statuses
      \6                Low priority messages
      \7                Low priority statuses
   \WPCSOUT             MTA output queues (to local domain agents)
      \ADS              Priority queues for local directory store updates
         \<0 .. 7>
      \CSS              Priority queues for MTA administration messages
         \<0 .. 7>
      \PROBLEM          Dead messages queue
   \WPGATE              Gateways local to this domain

Additional Notes About the Domain Folder

The Mslocal\Mshold folder holds messages that are delayed because the next delivery agent is unable to receive the message. The folder names take the first three letters of the name of the adjacent entity, as defined in NetWare Administrator, plus four unique characters "xxxx". For example, a post office named ACMEPO1 would have a folder name like "ACM3F41". An adjacent domain named NAMERICA might have a folder name like "NAM88B4". And a local gateway named GWIA might have a folder name like "GWI5FF2".
GroupWise clients do not run from the domain's Wpoffice folder. This was once the point of software distribution, a method of simplifying client software upgrades. The GroupWise software distribution folder is now defined as part of the installation of the GroupWise software, and can be located anywhere on the network.
You may have noticed the number of "legacy" folders, as well as the less-than-obvious names for some components. For example, nearly every folder seems to be named "WP.." instead of "GW..". There's a history to this naming structure. Before Novell acquired GroupWise from WordPerfect, Corp., the product was called "WP Office." In WP Office, the MTA component was called the Connection Server (CS). The ADA component was the Administration Server (ADS), and the POA component was called the Office Server (OFS). The name of the product changed from "WP Office" to "Novell GroupWise" between the 4.0 and 4.1 revisions, responding not only to the change in company ownership, but also the industry shift to call bundled business applications "Office".
The "Priority queues" directory structure pervades all of the GroupWise messaging system and will be discussed in greater depth later in Part 2 of this series.
For more details on GroupWise directory structure, see the Novell online documentation for GroupWise at the following Web site:

http://www.novell.com/documentation/lg/gw55/index.html?page=/documentation/lg/gw55/gw55pods/data/a4cdgvq.html

GroupWise Post Office Architecture

Whereas the GroupWise domain is the center for administration and message flow throughout the domain, the GroupWise post office is the center for user messaging and groupware activities (such as calendaring and scheduling, document creation and management, and workflow creation and management). The post office database is almost an exact copy of the domain database, but it is a read-only copy. No system administration can be performed against the post office database. On the other hand, no messaging occurs directly at the domain, only at the post office. GroupWise is unique in this total separation of system administration from messaging functionality. Most other messaging systems allow full system administration to be performed against the same server that stores the messages.

Post Office Directory Structure

Like the GroupWise domain, the GroupWise post office is defined by the set of files and folders which make up the post office. The directory store (or "Address Book") is called the post office database. The file name is Wphost.db. There is no commonly used name for the post office root folder like there is for the domain.

The directory structure of a GroupWise post office is as follows:

\POSTOFF                Post office root folder
    gwpo.dc             Dictionary file for post office database
    ngwguard.db         Guardian database
    ngwguard.dc         Dictionary file for guardian database
    ngwguard.fbk        Backup of guardian database
    ngwguard.rfl        Roll forward file for guardian database recovery
    wphost.db           Post office database (the directory store)
   \GWDMS               Document management root folder
   \OFFILES             Root folder for message attachments
      \F
      \FD0
      \FD1
        .               248 folders (the bulk of the message store)
        .
        .
      \FDF6
   \OFMSG               Root folder for message databases
       msg0.db
       msg1.db
        .
        .               Up to 25 message databases
        .
       msg24.db
   \OFUSER              Root folder for user databases
       userfid.db       User database for a single user
       pufid.db         User database for shared folders (public folders)
   \OFVIEWS             View templates for client software
   \OFWORK              Temporary working folders
   \WPCSIN              MTA input priority queues
      <\0 .. \7>
   \WPCSOUT             MTA output priority queues
      \ADS              Input queues for directory store updates
         <\0 .. \7>
      \OFS              Input queues for local messages and statuses
         <\0 .. \7>
      \PROBLEM          Dead messages folder

Additional Notes About the Post Office Directory Structure:

The Guardian database performs many functions, but its primary function is to ensure the integrity of the entire message store. As such, GroupWise 5.x goes to great lengths to protect this database, building in multiple backups, a roll forward transaction log, and frequent error checking. In short, GroupWise 5.x will not function properly without it. For details on the Guardian database, see the following Web site:

http://www.novell.com/documentation/lg/gw55/index.html?page=/documentation/lg/gw55/gw55agt/data/huden0jh.html
The templates for viewing GroupWise messages, which are contained in the Ofviews folder, are required by the client software for proper functioning. These view files are similar in concept to Outlook Forms. In GroupWise 4.x, a utility for creating personalized views came standard with every installation.
GroupWise encrypts all messages during both the message transfer process and the message storage process. The encryption algorithm is proprietary and very secure.

Message Store Architecture

GroupWise employs a single-instance message store, just as any modern e-mail system does, but its implementation is unique: It is a combination of databases, folders, and files that all work together to store e-mail on the post office. Whereas Exchange has a single file for all user mailboxes and all user e-mail on a server (Priv.edb) and another single file for all public folder content (Pub.edb), GroupWise employs dozens of databases for messages and hundreds of databases for users. In Microsoft Mail, user mailbags, messages, and attachments are all stored in separate folders. GroupWise is the same in many ways.

User Databases:

Each GroupWise user has his or her own database. The database stores pointers to messages in the message databases, as well as all user preferences.
The user database file name is in the format:

UserFID.db

where the FID is a unique user file ID. You can determine a user's file ID by viewing GroupWise account properties for the user in NetWare Administrator.
All user databases are stored in the Postoff\Ofuser folder.
User databases are only created when they are first accessed, either by a user logging on for the first time, or by the user receiving a message for the first time. In other words, there may be 25 users on a post office, but until a message is sent to all 25 users, there will not be 25 user databases in Postoff\Ofuser.

Message Databases:

GroupWise may have up to 25 message databases. Message databases store messages that are 2 KB in size or less. The message databases also store pointers to attachments in the attachments folders.
The message database file name is in the format MSGnn.db, where nn represents a number between 0 and 24.
All message databases are stored in the Postoff\Ofmsg folder.
As with user databases, message databases are not created until they are first needed.
Each user in the post office is assigned a message database, and all messages that the user sends are stored in that assigned message database. Inbound messages from other post offices are written to the message database corresponding to that user's assigned message database on the originating post office.

Attachments Directories:

GroupWise stores all file attachments, and any messages, headers, or distribution lists that exceed 2 KB in size in a series of folders called the "attachment folders." Novell says that it does this to enhance performance of the message databases.
The attachment folders are all found under Postoff\Offiles. In GroupWise 4.x there are about 16 of these subfolders. In GroupWise 5.x, there are hundreds.
Attachment files are given a random file name and are fully encrypted with GroupWise proprietary encryption technology.
The bulk of the GroupWise message store is stored in the attachments folders.

Shared Folders:

Shared folders are the rough equivalent of public folders in Exchange. They store pointers to messages just as user databases do. The difference is in the way the shared folders are managed by the system.
A shared folder database file name is in the format PUxxxxx.db, where xxxxx is a unique identifier.
Shared folders are all stored in the Postoff\Ofuser folder.

Additional Notes About the GroupWise Message Store:

As with Microsoft Exchange Server 5.5, the Novell GroupWise 5.x message store has no limit on its maximum size. However, experience has shown that when GroupWise message databases get to be several gigabytes in size, they tend to become very unwieldy and prone to corruption. The Guardian database goes a long way toward preventing and correcting logical corruption, but it does not prevent physical corruption of the database.
Novell GroupWise includes a feature-rich database maintenance utility with a clean graphical interface that can be run from NetWare Administrator. It is called "GroupWise Mailbox/Library Maintenance," and it allows administrators to check and fix a wide variety of problems with the message store. Its focus can be as narrow as a single user or as broad as the entire post office. It is a very effective tool for fixing problems.
Novell's philosophy of disaster planning and recovery is to primarily provide powerful tools for recreating individual databases that have been accidentally deleted (the GroupWise Mailbox/Library Maintenance tool), and secondarily provide tools that will allow administrators to back up the message store. Novell offers a backup utility designed specifically for backing up GroupWise called Gwbackup. It will back up the GroupWise post office while users are using it, but it must lock each database while it is backing it up. This is not a "true" on-line backup, but because the GroupWise message store is a huge collection of databases and files in many folders, this does not tend to be much of a problem. However, because GroupWise database technology does not employ transaction logging, if a disaster occurs that requires administrators to restore from backup, the best that can be hoped for is to restore all data to the point of the last backup. All data written to the message store since the last backup will be lost.

This is the end of Part 1. In Part 2, GroupWise message flow is discussed in some detail. A glossary also is provided:
'