Planning a New Post Office

This section provides the information you need in order to decide when, where, and how to create a new post office. The Post Office Worksheet lists all the information you need as you set up your post office. You should print the worksheet and fill it out as you complete the tasks listed below.

After you have completed the tasks and filled out the Post Office Worksheet, you are ready to continue with Setting Up the New Post Office.


Determining When to Add a Post Office

After you have your basic GroupWise system up and running, you might need to expand it. How do you know when you should add a post office? The answer to this depends on your company organization, the number of users on your network, and the physical limitations of your network servers.


Physical Organization

If your network spans several sites, you might want to create post offices (if not domains) at each physical location. This reduces the demands on long distance network links.


Logical Organization

Processing messages within a post office is faster and typically generates less network traffic than messages traveling between different post offices. As you expand GroupWise, you might find it useful to add post offices in order to group users who frequently send mail to each other.

Grouping users into post offices, based upon company organization or job function, makes administrative tasks, such as creating distribution lists, limiting Address Book visibility, and distributing shared folders, easier. For example, some employees might work in corporate functions like accounting and human resources. Other employees might be involved in sales and marketing and frequently attend meetings together, requiring frequent busy searches. Some areas, for example the production floor, might not need a workstation or user account for each individual.


Number of Users

Although a GroupWise post office can support more than 10,000 users, you should consider adding a post office when an existing post office has more than about 1000 to 2500 users and you expect it to keep growing. There are several reasons for this:

  • It minimizes the impact if you have a problem with a server.
  • It keeps the time required to perform post office and mailbox maintenance activities including backups from becoming excessive.
  • It allows room to grow while maintaining best performance.

Therefore, a good post office size is about 1000 to 2500 users and include all of the resources (such as equipment, company cars, and conference rooms) and distribution lists they might need.


Demand on the POA

The POA is a very flexible component of your GroupWise system. Many aspects of its functioning are configurable, to meet the particular needs of the post office it services, no matter what the size. In addition, you can choose to run multiple POAs for the same post office, in order to specialize its functioning, as described in:

As a result, the choice is up to you whether you prefer a single, large post office, perhaps with multiple POAs, or multiple smaller post offices, each with its own POA.


Selecting the Domain That the Post Office Will Belong To

A post office is associated with a specific domain, even though it might reside in a different organizational unit in the Novell® eDirectoryTM tree. If you have just one domain, the new post office will belong to it. If you want to create a new domain as well as a new post office, see Creating a New Domain.

In a multiple post office system, the domain organizes post offices into a logical grouping for addressing and routing purposes. Each user in the domain has a GroupWise address that consists of the user's GroupWise ID, the post office name, the GroupWise domain name, and optionally, an Internet domain name.

Domains function as the main administration units for the GroupWise system. Post office information is stored in the domain database, as well as in the post office database. Changes are distributed to each post office database from the domain.

WORKSHEET

Under Item 3: GroupWise Domain, specify the GroupWise domain that the new post office will belong to.

The items in the worksheet are listed in the order you enter them when setting up your post office. This planning section does not follow the same order as the worksheet, but all worksheet items are covered.


Determining the Context for the Post Office Object

The eDirectory context of the Post Office object determines how you administer the post office. The post office can be created in any organization or organizational unit as long as it is in the same tree as the domain. The following diagrams provide some examples of how domains can be placed in the eDirectory tree:

WORKSHEET

Under Item 1: eDirectory Container, specify the name of the eDirectory container where you want to create the new post office.


GroupWise Objects Reflect Physical Locations

The GroupWise system below focuses on the physical layout of the company. Because most mail traffic is generated by users in the same location, the mail traffic across the WAN is minimized. An organizational unit was created for each site. A domain and post office were created under each organizational unit, corresponding to the city. The sites can be administered centrally or at each site. Administrator rights can be assigned at the domain level.


A GroupWise system following the physical layout of the company


GroupWise Objects Reflect Company Organization

The following GroupWise system focuses on departmental organization, as does the eDirectory tree. GroupWise domains and post offices parallel eDirectory organizational units, placing the domains and post offices within the organizational units containing the users that belong to them.


A GroupWise system following the departmental organization of the company


GroupWise Objects Are Grouped with Servers

Because domains and post offices have directory structures on network servers, you could also choose to place the Domain and Post Office objects in the same context as the servers where the directories reside, as shown in the following example.


A GroupWise system with the domains and post offices grouped with the servers


GroupWise Objects Are Located in a Separate GroupWise Container

Domains and post offices can also be created in their own organizational unit. Administratively, this approach makes it easier to restrict a GroupWise administrator's object and property rights to GroupWise objects only.


Groupwise objects located in their own organizational unit


Choosing the Post Office Name

The post office must be given a unique name. The name is used for addressing and routing purposes within GroupWise, and might appear in the GroupWise Address Book.

The post office name can reflect a location, organization, department, and so on. For example, you might want the domain name to be the location (for example, Provo) while the post office name is one of the company's departments (for example, Research). Name the new post office carefully. After it is created, the name cannot be changed.

The post office name can consist of one or more words. Use underscores (_) rather than spaces as separators between words to facilitate addressing across the Internet. Do not use any of the following invalid characters in the post office name:

ASCII characters 0-13

Comma ,

Asterisk *

Double quote "

At sign @

Extended characters

Braces { }

Parentheses ( )

Colon :

Period .

WORKSHEET

Under Item 2: Post Office Name, specify the post office name.

Under Item 9: Post Office Description, provide a description for the post office to help you identify its function in the system.


Deciding Where to Create the Post Office Directory

Logically, the Post Office object resides in eDirectory and is administered through ConsoleOne®. Physically, the post office has a directory structure for databases, message queues, and other files. The post office directory structure can be created on NetWare® servers (NetWare 6.x, NetWare 5.x, NetWare 4.2, or NetWare 3.12), Linux servers (SUSE Standard or Enterprise Server 8, Red Hat* Enterprise Linux 3 ES or AS), or Windows servers (Windows 2000 or Windows NT). The server where you create the post office directory structure can be in the same tree as the Post Office object or in another tree.

Databases and directories in the post office are updated as messages are sent. Because the POA typically makes these updates, we recommend that you place the post office directory on a server that can be easily accessed by the POA and, depending on configuration, the MTA. Users typically need a TCP/IP connection to the POA in order to access their mailboxes.

When you are planning the post office directory location and which users will belong to the post office, consider the following:

Choose an empty directory for the new post office. If you want, the directory can reflect the name of the post office, for example research for the Research post office. On NetWare, use a maximum of 8 characters in the directory name. On Linux, use only lowercase characters in the directory name.

Choose the name and path carefully. After the post office directory is created, it is difficult to rename it. If the directory you specify does not exist, it is created when you create the post office. Do not create the post office directory under another domain or post office directory.

WORKSHEET

Under Item 4: Post Office Database Location, specify the full path for the post office directory.

Under Item 10: Network Type, record the network type in use at that location.


Deciding Where to Install the Agent Software

You must run a new instance of the POA for each new post office. To review the functions of the POA for the post office, see Role of the Post Office Agent. For complete installation instructions and system requirements, see "Installing GroupWise Agents" in the GroupWise 6.5 Installation Guide.

When planning the installation of the POA, you need to consider how the new post office links to its domain. For an overview of link configuration, see Managing the Links between Domains and Post Offices.

The POA requires direct network access (mapped drive or file system mount) to the post office directory. Consider the following alternatives when selecting a location for the POA:

WORKSHEET

Under Item 12: Agent Location, indicate whether you plan to run the POA on the same server where the post office directory is located, or on a different server.

Under Item 13: Agent Platform, specify the platform where the POA will run (NetWare, Linux, or Windows).


POA Access to the New Post Office: Local vs. Remote

Running the POA locally on the same server where the post office resides simplifies network connections (no login is required), reduces network traffic, and protects database integrity. In the following diagram, the agent software is installed on the same server where the domain and post office reside.


Agent software on the same machine with the domain and post office

Running the POA on a remote server allows you to place the heaviest processing load on your highest performing server. In the following diagram, the agent software is installed on a different server from where the domains and post offices reside.


Agent software on a different machine than the domain and post office

When you run the POA on a different server from where its directory structure and databases are located, you need to provide adequate access.

  • If the NetWare® POA needs direct network access to another NetWare server where the post office is located, you must add the /dn switch or the /user and /password switches to the POA startup file to provide authentication information. Username and password information can also be provided in the Remote File Server Settings box of the Post Office Settings page in ConsoleOne.
  • If the Linux POA needs direct network access to another Linux server, you must mount the file system where the post office is located before you start the Linux POA.
  • If the Windows POA needs direct network access to another Windows server where the post office is located, you must map a drive to the other server before you start the Windows POA.


MTA Access to the New Post Office: Mapped and UNC Links vs. TCP/IP Links

If a domain includes multiple post offices, the new post office will probably reside on different server from where the domain is located. If you plan to use mapped or UNC links between the domain and the new post office, the MTA requires the same access to the post office directory as it requires to the domain directory.


MTA access using mapped or UNC links
  • If the NetWare MTA needs direct network access to a new post office on another NetWare server, you must add the /dn switch or the /user and /password switches to the MTA startup file to provide authentication information.
  • If the Windows MTA needs direct network access to a new post office on another Windows server, you must map a drive to the post office directory before you start the MTA.

NOTE:  The Linux MTA requires TCP/IP links to the POA.

To avoid these direct network access requirements between the MTA and a new post office, you can use TCP/IP links between the domain and the new post office.


MTA access using TCP/IP links

When using TCP/IP links, the MTA does not write message files into message queues in the post office directory structure. Instead, the MTA communicates the information to the POA by way of TCP/IP and then the POA uses its direct network access to write the information.


Cross-Platform Issues

In most cases, it is most efficient if you match the POA platform with the network operating system where the post office resides. For example, if you create a new post office on a NetWare server, use the NetWare POA.

If you decide not to run the POA on the same platform as the post office, the POA must still have direct network access to the post office directory so that it can write to user databases (userxxx.db) and message databases (msgnn.db). For example, you could set up the new post office on a NetWare server and run the Windows POA on an Windows server to service it.


A domain on a NetWare server and the MTA on an NT/2000 server

However, the NetWare POA could not service a post office located on an Windows server because Windows does not support the required cross-platform connection.

If you are using mapped or UNC links to the new post office, the MTA must also have direct network access to the post office directory so that it can write message files into the post office message queues. You could, for example, run the agents on an Windows server while domains and post offices were located on NetWare servers.


Agents on an NT/2000 machine and domains and post offices on a NetWare server

Again, the opposite combination of NetWare agents servicing domains and post offices on Windows servers is not an option because Windows does not support the required cross-platform connection.

To avoid these cross-platform access issues, use TCP/IP links between a domain and its post offices.

For more detailed information, see Cross-Platform Issues between Domains and Post Offices.


Deciding How to Link the New Post Office

When you create a new post office, you have the opportunity to choose the type of link to use between the new post office and its domain. Based on issues discussed in the preceding section, you might decide to set up a TCP/IP link between the new post office and its domain.

WORKSHEET

Under Item 14: Link to Domain, indicate the type of link you plan to set up between the new post office and its domain.


Selecting the Post Office Language

The post office language determines how times, dates, and numbers are displayed in the GroupWise client and determines the sorting rules for items in the GroupWise Address Book.

The post office defaults to the same language as its domain unless you specify otherwise. For example, if you set the domain and post office language to English-US, all time, date, and numbers are formatted according to English-US standards, and the Address Book items are sorted according to English-US sort order rules. This is true even if some users on the post office are running non-English GroupWise clients such as German or Japanese. Their client interface and Help files would be in German or Japanese, but the Address Book sort order would be according to English-US standards. Time, date, and number formats for the non-English clients defaults to the workstation language. Status tracking information depends on the language of the POA for the post office.

WORKSHEET

Under Item 5: Post Office Language, specify the post office language.


Selecting the Post Office Time Zone

When a message is sent from a user in one time zone to a user in another time zone, GroupWise adjusts the message's time so that it is correct for the recipient's time zone. For example, if a user in New York (GMT -05:00, Eastern Time) schedules a user in Los Angeles (GMT -08:00, Pacific Time) for a conference call at 4:00 p.m. Eastern Time, the appointment is scheduled in the Los Angeles user's calendar at 1:00 p.m. Pacific Time.

The domain time zone becomes the default time zone for each post office in the domain.

WORKSHEET

Under Item 6: Time Zone, specify the time zone for the new post office.


Selecting a Software Distribution Directory

A software distribution directory was created when your GroupWise system was initially set up. The software distribution directory contains files that users need in order to set up the GroupWise Windows or Cross-Platform client on their workstations. Additional software distribution directories might have been created since that time to accommodate users in various locations.

You can select the most convenient software distribution directory for the new post office.

WORKSHEET

Under Item 7: Software Distribution Directory, specify the name of the software distribution directory from which users in the new post office will install the GroupWise client software on their Windows, Linux, or Macintosh workstations.


Selecting a Post Office Security Level

Post office security settings affect two types of GroupWise users:

After a user sets a GroupWise password on his or her mailbox, the post office security level no longer applies. The user is always prompted for the password unless the administrator has set certain client options in ConsoleOne to prevent the password prompt, as described in Managing GroupWise Passwords.

In the absence of passwords on users' mailboxes, the post office security level takes effect. By default, a new post office is created with low security. In a low security post office, mailboxes are completely unprotected. Without a password, any user's mailbox could be accessed by another user who knows how to use the @u-userID startup switch.

By increasing the post office security level to high, you provide protection to GroupWise mailboxes through other types of passwords. In a high security post office, you can choose between eDirectory authentication and LDAP authentication:

WORKSHEET

Under Item 11: Post Office Security Level, mark the security level for the post office. If you choose high security, indicate the type of authentication you plan to use.


Deciding if You Want to Create a Library for the New Post Office

If you anticipate that users on this post office will require document management services, you can create a library at the same time you create the post office. The library will be created with all of the default library options including Store Documents at Post Office. Using a document storage area is preferable to storing documents at the post office because a document storage area can be moved. You should appropriately configure the library immediately after it is created, before users begin to store documents there. See Libraries and Documents.

WORKSHEET

Under Item 8: Create Library, indicate whether or not you want to immediately create a library for the new post office. You can always add a library to the post office at a later time.