Determining When to Add a New Domain

How do you know when you should add a domain? The answer to this depends on your administration policies and on physical and logical network organization.

Although a single domain can contain as many post offices and users as you want to add, there are some conditions that indicate the need for a new domain:

• Administrative Convenience: To spread out the administrative workload, you can create one or more new domains with their own administrators. Each new domain can be managed by a different administrator as long as each administrator has sufficient rights to connect to it and write to the domain directory.

• Remote Sites: If communication between servers is slow, or if you have remote sites, you can add a new domain to minimize mail traffic between the servers. For example, if you have locations in three separate cities, you might have an organization that represents each location. You could then create a domain in each organization. You could administer all of the domains from one location or you could assign a different administrator for each one.

• Demand on the MTA: Each domain has its own MTA that routes messages between post offices within its domain. If your current domain has many post offices that are placing a heavy workload on the MTA, you might want to create another domain to handle additional post offices.

• Multiple eDirectory Trees: All of the objects that are logically subordinate to a GroupWise domain must be in the same Novell^® eDirectory^TM tree as the domain. If you have users in other eDirectory trees that need GroupWise accounts, you must create secondary domains and post offices in each tree.

Deciding Who Will Administer the New Domain

Any user who is an Admin equivalent can administer GroupWise. We recommend that whoever creates the new domain should be an Admin equivalent so that he or she has the necessary rights to create objects and directories. You can then assign a different user as a domain administrator and limit rights to other objects if necessary. For more information, see GroupWise Administrator Rights.

Depending upon the size, complexity, and layout of your eDirectory tree, you might choose a centralized administration model with one person administering both eDirectory and GroupWise, or you might choose a distributed administration model with the administration workload shared by two or more individuals. With a distributed administration model, each administrator obtains rights to the GroupWise objects and directory structures over which he or she has jurisdiction. If you want to restrict access to some network operations or to certain domains, you can limit access rights to domains the user should not administer.

The user assigned as the administrator must be able to create or modify objects in the domain and will receive an e-mail message whenever an agent encounters a problem. You can designate yourself, one or more other users, or a distribution list as an administrator.

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

Planning Post Offices in the New Domain

Before adding the new domain, you should plan the post offices that you want to belong to the domain. You should consider the following issues when planning post offices.

• 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: Grouping users who frequently send messages to each other is faster and generates less network traffic than if messages travel between different post offices and domains.

• Number of Users: A typical post office can serve from 1000 to 2500 users, depending on its configuration. Larger post offices are possible, but grouping similar users might be preferable.

• Demand on the POA: Each post office has at least one POA that delivers messages to users' mailboxes and performs other post office maintenance tasks. It is possible to run multiple POAs, located on different servers, for the same post office, or you might prefer to create multiple post offices.

For more details, see Planning a New Post Office .

Determining the Context for the Domain Object

When deciding where to place the new Domain object in the eDirectory tree, you should consider how you can most easily administer GroupWise and how the domain and its associated post offices fit into the logical organization of your eDirectory tree.

Domains and their associated objects, including Post Offices, Users, Resources, and Distribution Lists, must be located in the same eDirectory tree. If you have multiple trees, you must create a separate domain in each tree. The domains can all belong to the same GroupWise system.

You can place the domain in any context in an eDirectory tree. The following diagrams provide some examples of how domains can be placed in the eDirectory tree:

• GroupWise Objects Reflect Physical Locations
• GroupWise Objects Reflect Company Organization
• GroupWise Objects Are Grouped with Servers
• GroupWise Objects Are Located in a Separate GroupWise Container

GroupWise Objects Reflect Physical Locations

The GroupWise system below focuses on the physical layout of the company. Because most mail traffic is probably 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 was 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.

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 will belong to them.

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 will reside, as shown in the following example.

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. For information about GroupWise Administrator rights, see Deciding Who Will Administer the New Domain.

Choosing the Domain Name

The domain requires a unique name. The name is used as the Domain object's name in eDirectory. It is also used for addressing and routing purposes within GroupWise, and might appear in the GroupWise Address Book.

The domain name can reflect a location, company name or branch name, or some other element that makes sense for your organization. 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 domain carefully. After it is created, the name cannot be changed.

The domain 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 domain name:

Deciding Where to Create the Domain Directory

Logically, the Domain object resides in eDirectory and is administered through ConsoleOne^®. Physically, the domain has a directory structure for databases, message queues, and other files. The domain 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 domain directory structure can be in the same tree as the Domain object or in another tree.

Many different configurations are possible. When deciding where to create the domain directory, you should consider the following.

• Domain Directory Space Requirements: The domain directory requires less than 10 MB of free disk space. However, this requirement could increase as your system grows.

• Network Access by the MTA: If the MTA is not installed on the same server with the domain directory, the MTA must have direct network access (mapped drive or file system mount) to the domain directory and, depending on link configuration, to the post office directories. This issue is discussed in detail in Deciding Where to Install the Agent Software.

• Security from User Access: Users never need access to the domain directory so you should create it in a location you can easily secure; otherwise, you could have files inadvertently moved or deleted.

Choose an empty directory for the new domain. If you want, the directory can reflect the name of the domain, for example, res_dev for the Research and Development domain. On NetWare and Windows, 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 domain directory is created, it is difficult to rename it. If the directory you specify does not exist, it will be created when you create the domain. Do not create the domain directory under another domain or post office directory.

Deciding Where to Install the Agent Software

You must run a new instance of the MTA for each new domain. To review the functions of the MTA for the domain, see Role of the Message Transfer 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 MTA, you need to consider how the new domain links to existing domains and how the new domain will link to its post offices. For an overview of link configuration, see Managing the Links between Domains and Post Offices.

The MTA requires direct network access to the domain directory and, depending on the link configuration, to each post office directory. Consider the following alternatives when selecting a location for the MTA relative to the domain and its post offices:

• MTA Access to the New Domain: Local vs. Remote
• MTA Access to New Post Offices: Mapped and UNC Links vs. TCP/IP Links
• Cross-Platform Access Issues

MTA Access to the New Domain: Local vs. Remote

Running the MTA locally on the same server where the domain and post offices reside 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.

Running the MTA 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.

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

• If the NetWare^® MTA needs direct network access to 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 Linux MTA needs direct network access to another Linux server, you must mount the file system where the domain is located before you start the Linux MTA.
• If the Windows MTA needs direct network access to another Windows server, you must map a drive to the other server before you start the Windows MTA.

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

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

• If the NetWare MTA needs access to a 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 access to a post office on another Windows server, you must map a drive to the other server before you start the Windows MTA.

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

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

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 Access Issues

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

If you decide not to run the MTA on the same platform as the domain, the MTA must still have direct network access to the domain directory so that it can write to the domain database (wpdomain.db). For example, you could set up the new domain on a NetWare server and run the Windows MTA on an Windows server to service it.

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

If you are using mapped or UNC links to post offices, the MTA must also have direct network access to the post office directories so that it can write messages 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.

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 Domain

Domain links tell the MTAs how to route messages between domains. Properly configured links optimize message flow throughout your GroupWise system. For a review of link types, see Domain-to-Domain Links.

When you create the new domain, you link it to one existing domain. By default, this link is a direct link using TCP/IP as the link protocol, which means the new domain's MTA communicates with the existing domain's MTA through TCP/IP. If desired, you can configure the direct link to use a UNC path as the link protocol, which means the new domain's MTA transfers information to and from the existing domain by accessing the existing domain's directory

After you create the new domain, you can configure links to additional domains as needed. See Using the Link Configuration Tool.

Selecting the Domain Language

The domain 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.

Selecting the Domain 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.