|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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).
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 2012 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 the Connection Server (CS). Hence, the directory name wpcsin for the MTA input queue. Some naming conventions were originally preserved for backward compatibility.
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 2012 Administration Guide.
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 2012 Administration Guide.
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 2012 Administration Guide.
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.
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 2012 Administration Guide.
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 2012 Administration Guide.
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.
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.
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.
The wpgate subdirectory in the domain contains a subdirectory for use by the GWIA, which was originally a gateway.
All other GroupWise gateways are legacy products and are not support in GroupWise 2012.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The priority 2 subdirectory of the css input queue (wpcsout\css) in the domain is for non-priority requests.
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 2012 Troubleshooting 2: Solutions to Common Problems.
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.
The wpdomain.db file in the domain is the domain database. It contains all administrative information for the domain.
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 2012, 8, 7, 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 2012, 8, 7, 6.x, and 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.
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 in the GroupWise software image.
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.
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 in the GroupWise software image.
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.
The gwdom.dc file in the domain is the data dictionary for creating and rebuilding GroupWise 2012, 8, 7, 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 2012, 8, 7, 6.x, and5.x secondary domains. The original gwdom.dc file is located in the domain directory of the software distribution directory or in the GroupWise software image.
The gwpo.dc file in the domain is the data dictionary for creating and rebuilding GroupWise 2012 8, 7, 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 2012, 8, 7, 6.x, and 5.x post offices in that domain. The original gwpo.dc file is located in the domain directory of the software distribution directory or in the GroupWise software image.
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 2012 Administration Guide.
The uid.run file in the domain records the non-root user that is authorized to run the MTA for the domain. See Running the Linux GroupWise Agents as a Non-root User
in Installing GroupWise Agents
in the GroupWise 2012 Installation Guide.
The ncpChecked file in the domain shows that cross-protocol locks are enabled. See Configuring the OES Linux Server for NCP Access from Windows
in System
in the GroupWise 2012 Administration Guide.