After selecting your NetMail system but before the installation, review the configuration requirements associated with your messaging system The following sections review the configuration requirements for each NetMail system:
For a single server network, your initial NetMail installation is your complete messaging system.
Although a single server tree is very simple in its configuration, on NetWare, this system is capable of providing efficient messaging services for 250,000 to 350,000 users.
For a practical example of this configuration, see Single-Server Network .
You can automatically create your messaging server's agents during NetMail installation, or you can manually create those agents after installation using WebAdmin. In either case, plan the agent services you want to provide to your users.
For an overview of each agent's function, see NetMail Agents. For a detailed explanation of each agent's configuration options, see NetMail Configuration.
To minimize messaging server reaction time and ensure high system performance, the messaging server requires fast access (ideally, local access) to its corresponding Message Server object and the User objects within its assigned contexts (that is, those User objects with a mailbox directory on the server).
Because the entire Directory tree resides on a single machine, the messaging server automatically has local access to the Messaging Server object and all User objects in the tree. Therefore, no additional Directory configuration is necessary.
In a single messaging server system, a dedicated messaging server is integrated with an organization's existing multiple-server, Directory-based network. This configuration is common in business and education environments because it is capable of handling a considerable volume of messaging traffic and it allows you to leverage objects that already exist in eDirectory.
Like the single server network, your initial NetMail installation is your complete messaging system.
For a practical example of this configuration, see Single Messaging Server LAN .
During a standard NetMail installation, you can automatically create your messaging server's agents or you can manually create those agents after installation using WebAdmin. In either case, plan the agent services you want to provide to your users.
For an overview of each agent's function, see NetMail Agents. For a detailed explanation of each agent's configuration options, see NetMail Configuration.
To minimize messaging server reaction time and ensure high system performance, the messaging server requires fast access (ideally, local access) to its corresponding Message Server object and the User objects within its assigned contexts (that is, those User objects with a mailbox directory on the server).
Because multiple servers exist on the network, the messaging server does not automatically have local access to its Messaging Server object, the Internet Services container, or the messaging system's User objects.
To give the messaging server local access to the Messaging Server object, the Internet Services container, and all User objects that belong to the messaging system:
By default, the root partition contains the Internet Services container. However, to avoid replicating the entire root partition on the messaging server, create a separate partition for the Internet Services container.
In this system, multiple messaging servers are in use, but each messaging server is assigned to a different domain and functions as an independent messaging system.
For a practical example of this configuration, see Multiple Standalone Messaging Server LAN .
In configuring a multiple standalone message server LAN, you must do the following:
Each of these steps is discussed in the following sections.
When you install NetMail on your first messaging server, the eDirectory schema is extended to include objects specific to NetMail. This is the only time you need to extend the schema.
Therefore, before installing NetMail on additional messaging servers, allow time for the schema extensions to synchronize throughout the entire tree. Then, when installing NetMail on subsequent servers, select only Novell NetMail Files in the list of installation options. This option installs the NetMail program files to the server but does not re-extend the schema.
Do not select Configure Server for NetMail because this option automatically creates the Messaging Server object in the Internet Services container. To provide an intuitive distribution of objects in a Multiple Standalone Messaging Server LAN, you typically want to create each Messaging Server object in the container associated with its User objects.
For further information on NetMail installation options and installing NetMail, see Installing NetMail 3.5.
After installing the NetMail files on each messaging server, you need to create the servers' associated Messaging Server objects.
Create each Messaging Server object in the same container as its users. Standalone messaging servers are typically created in the containers associated with their User objects for the following reasons:
For more information, see Messaging Server .
By default, messaging servers search the tree for the Internet Services container and its associated Messaging Server objects. This enables multiple messaging servers to function as a single, integrated system.
In standalone messaging systems, however, messaging servers do not interact with each other. Instead, each messaging server functions as an independent messaging system, exclusively providing all NetMail services to the users within its assigned contexts.
To prevent messaging servers from searching the tree for Internet Services and its associated Messaging Server objects, disable Distributed Processing in the Messaging Server object Identification page. For more information on this option, see the Distributed Processing property in Configuring the Messaging Server.
Because standalone messaging servers function independently of each other, they must have all the NetMail agents required for a self-contained messaging system.
At a minimum, each messaging server must have the following agents:
Additional agents depend on the services you want to provide to your users.
The NMAP, SMTP, POP, IMAP, Modular Web Agent, AutoReply, Rule, Proxy, Alias, AntiSpam, AntiVirus, List, and Connection Manager agents must run locally on standalone messaging servers.
If you run the Address Book Agent on a standalone messaging server, it returns only local users in address book queries. To provide a system-wide address book, you can run the Address Book Agent on a central distributed messaging server and configure the local e-mail clients to access the distributed Address Book Agent as an LDAP server.
For an overview of each agent's function, see NetMail Agents. For a detailed explanation of each agent's configuration options, see NetMail Configuration.
To minimize messaging server reaction time and ensure high system performance, each standalone messaging server requires fast access (ideally, local access) to its corresponding Message Server object and the User objects within its assigned contexts (that is, those User objects with a mailbox directory on the server).
Because multiple servers exist on the network, each messaging server does not automatically have local access to its corresponding Messaging Server object or the User objects in its assigned contexts.
To give each standalone messaging server local access to its associated Messaging Server object and assigned User objects, create a read/write replica for each standalone message server of the partition containing its Messaging Server object and assigned User objects.
A multiple distributed messaging server LAN is a common ISP, ASP, or multi-LAN configuration. Because of the volume of messages handled by the messaging system, performance requirements, or the local distribution of the network, NetMail components are distributed over several messaging servers.
In such environments, you can configure two or more messaging servers to work together as a single, integrated system. In this way, messaging system functions are distributed across multiple servers to provide load balancing, fault tolerance, and speed. For a review of agent distribution strategies, see Creating and Configuring NetMail Agents.
For a practical example of this configuration, see Multiple Distributed Messaging Server LAN .
In configuring a multiple distributed message server LAN, you must do the following:
Each of these steps is discussed in the following sections.
When you install NetMail on your first messaging server, the eDirectory schema is extended to include objects specific to NetMail. This is the only time you need to extend the schema.
Therefore, before installing NetMail on additional messaging servers, allow time for the schema extensions to synchronize throughout the entire tree. Then, when installing NetMail on subsequent servers, select only Novell NetMail Files in the list of installation options. This option installs the NetMail program files to the server but does not re-extend the schema.
NOTE: You can also select Configure Server for NetMail if you want to create your Messaging Server objects during the installation.
After installing the NetMail files on each messaging server, you need to create each server's associated Messaging Server object.
Typically, distributed messaging servers are created in the Internet Services container because distributed messaging servers search the tree for that container and its associated Messaging Server objects. Looking for other messaging servers in Internet Services enables distributed servers to share agents and message processing functions.
It is possible, however, to create a Messaging Server object outside the Internet Services container and have it function in distributed mode if you create an Alias object for it within Internet Services. Alias objects enable distributed messaging servers to locate and interact with messaging servers outside the Internet Services container in the same way they interact with messaging servers inside the Internet Services container. For more information, see Messaging Server .
NOTE: You cannot create Alias objects in WebAdmin; therefore, you must use another administrative tool, such as iManager, to create the Alias object in the Internet Services container.
In planning your distributed messaging system, you need to decide which agent services you want to provide to your users and how to distribute those agents.
In part, agent distribution depends on the server resources required for any given service and its volume of usage. Another point to consider in agent distribution is fault tolerance. Identify your most critical services and distribute those agents accordingly. Finally, in planning agent distribution, you must consider the message path. The message path is where a message goes from the time it enters the message system to the time it is delivered to a user's mailbox. In distributed messaging systems with multiple NMAP Agents, you must carefully plan agent distribution so a message is not reprocessed by the same agents on its way from the queue server to the message store.
For a complete discussion on these issues, see Agent Distribution in Distributed Environments.
To minimize messaging server reaction time and ensure high system performance, distributed messaging servers require fast access (ideally, local access) to their corresponding Message Server objects and the Internet Services container. Servers running the NMAP Agent require fast access (ideally, local access) to all User objects in the messaging system.
Because multiple servers exist on the network, each messaging server does not automatically have local access to its corresponding Messaging Server object or the Internet Services container. Moreover, each NMAP server does not automatically have local access to all the User objects in the messaging system.
To give every messaging server local access to its associated Messaging Server object and the Internet Services container, create a read/write replica on each messaging server of a partition containing the Internet Services container. (Internet Services contains all distributed Messaging Server objects.) By default, the root partition contains the Internet Services container. However, to avoid replicating the entire root partition on the messaging server, create a separate partition for the Internet Services container.
To give each NMAP server local access to all User objects in the messaging system, create a read/write replica on each NMAP server of all partitions containing User objects that belong to the messaging system.
A multiple messaging server WAN typifies government and enterprise messaging systems. In these environments, the messaging system is geographically dispersed. The physical distance between messaging servers introduces a new set of configuration requirements. To support this system, messaging servers must be able to work together without generating unnecessary network traffic across the slow WAN connections.
In designing WAN messaging systems, first consider what kind of links you have between offices. For locations that connect to the central office or the central messaging server over fast links, follow the configuration guidelines for a multiple distributed messaging server LAN. (See Multiple Distributed Messaging Server LAN.) However, locations that connect to the central office over slow links must use a different strategy.
In slow-link WAN environments, it doesn't make sense to replicate both the Internet Services and User object partitions on every messaging server. Although this configuration optimizes performance in LAN environments, replicating multiple partitions across slow links can jam the connection and slow the network to a crawl.
Another concern in slow-link environments is preventing messaging servers in remote offices from searching the Directory tree for the Internet Services container and User objects that are not replicated to the remote location. Searching the tree over a slow link not only increases network traffic, but it can compromise the functionality of the system. If the eDirectory query times out before it is able to receive the needed information, NetMail continues to query other replicas until your server resources are exhausted.
One way of addressing these concerns is to locate all messaging servers at the central office. This configuration requires users in remote locations to access messaging servers across the WAN. Though functional, this option does not provide optimal performance. Users in remote locations experience slow service as they wait to send and download mail over the slow link.
A better solution is to provide standalone messaging servers at each remote location. Network traffic is reduced because all messaging operations take place on the local standalone server and, because the standalone messaging server is in the users' local environment, users experience faster service when using their e-mail clients.
NOTE: Actual message delivery time does not change for messages that traverse the WAN.
For a practical example of this configuration, see Multiple Messaging Server WAN .
In configuring a multiple standalone message server WAN, you must do the following:
Each of these steps is discussed in the following sections.
WAN environments are heterogeneous messaging systems. While slow-link offices require standalone messaging systems, the WAN still needs at least one distributed messaging server to maintain a replica of the complete messaging system and to route messages between standalone systems. Furthermore, offices that connect to the central office over fast links can support distributed messaging servers.
In deploying a WAN-based messaging system, deploy your distributed messaging servers before the standalone messaging servers. Depending on message traffic volume, performance requirements, and network distribution, you might only need a single distributed messaging server for your central office. In this case, follow the configuration guidelines for a single messaging server LAN. (See Single Messaging Server LAN.)
If your central office requires multiple distributed messaging servers, or if you are deploying distributed messaging servers in offices with fast links, follow the configuration guidelines for multiple distributed messaging server LANs. (See Multiple Distributed Messaging Server LAN.)
After installing NetMail on your distributed messaging servers, install NetMail on your remote servers.
At the time you installed NetMail on your first distributed messaging server, the eDirectory schema was extended to include objects specific to NetMail. This is the only time you need to extend the schema.
Therefore, before installing NetMail on remote messaging servers, allow time for the schema extensions to synchronize throughout the entire tree. (This can take some time in WAN environments.) Then, when installing NetMail, select only Novell NetMail Files in the list of installation options. This option installs the NetMail program files to the server but does not re-extend the schema.
Do not select Configure Server for NetMail. This option automatically creates the Messaging Server object in the Internet Services container. In creating a multiple messaging server WAN, you must create each standalone Messaging Server object in the same container as its users.
After you install NetMail on each remote messaging server, you need to create the servers' associated Messaging Server objects. Create each Messaging Server object in the same container as its users.
Standalone messaging servers are typically created in the containers associated with their User objects for the following reasons:
When you create each Messaging Server object, type the messaging system's domain name in the Messaging Server object's Official Domain field. For more information, see Messaging Server .
By default, messaging servers search the tree for the Internet Services container and its associated Messaging Server objects. This enables multiple messaging servers to function as a single, integrated system.
In standalone messaging systems, however, messaging servers do not interact with each other. Instead, each messaging server functions as an independent messaging system, exclusively providing all NetMail services to the users within its assigned contexts.
To prevent messaging servers from searching the tree for Internet Services and its associated Messaging Server objects, disable Distributed Processing in the Messaging Server object Identification page. For more information on this option, see the Distributed Processing property in Configuring the Messaging Server.
Because standalone messaging servers function independently of each other, they must have all the NetMail agents required for a self-contained messaging system.
At a minimum, each messaging server must have the following agents:
Additional agents depend on the services you want to provide to your users.
The NMAP, SMTP, POP, IMAP, Modular Web Agent, AutoReply, Rule, Proxy, Alias, AntiSpam, AntiVirus, List, and Connection Manager agents must run locally on standalone messaging servers.
If you run the Address Book Agent on a standalone messaging server, it returns only local users in address book queries. To provide a system-wide address book, you can run the Address Book Agent on a distributed messaging server and configure the local e-mail clients to access the distributed Address Book Agent as an LDAP server.
For an overview of each agent's function, see NetMail Agents. For a detailed explanation of each agent's configuration options, see NetMail Configuration.
When a messaging server's distributed functionality is turned off, it is essentially isolated from the rest of the messaging system. Users can send and receive messages from users in their local environment, or they can send and receive messages over the Internet. However, they cannot send messages to or receive messages from colleagues in other offices within their messaging system's domain.
To enable users in remote locations to send messages to users in other offices, you must configure each remote, standalone messaging server to forward local undeliverable messages. Local undeliverable messages are messages that are addressed to the messaging system's domain, but whose recipients are not in the current NMAP Agent's assigned contexts. When the NMAP Agent receives one of these messages, it recognizes that the message belongs to its messaging system domain, but it cannot find the recipient in its assigned context. The message, therefore, is undeliverable in the local messaging system.
Configuring the NMAP Agent to forward local undeliverable messages enables the remote messaging server to forward messages that belong to the messaging system's domain but are not locally deliverable. Messages are forwarded via the SMTP Agent to another messaging server, which can then route the message for delivery.
In WAN environments, you must configure the NMAP Agent on each remote, standalone messaging server to forward local undeliverable messages to the central distributed messaging server. For more information, see the Forward Local Undeliverable Messages property in Configuring the NMAP Agent .
With the Forward Local Undeliverable Messages option configured for each remote NMAP Agent, the remote messaging servers can send messages to the central messaging system. However, there remains the problem of enabling each remote messaging server to receive messages from the central messaging system.
With the current configuration, the central distributed messaging server still cannot send messages to remote messaging servers because distributed messaging servers only look in the Internet Services container for other Messaging Server objects. If a Messaging Server object does not exist in the Internet Services container, the distributed messaging servers cannot find it.
To enable the central distributed messaging server to route messages to remote messaging servers, each remote messaging server must have a corresponding Alias object in the Internet Services container.
NOTE: You cannot create Alias objects in WebAdmin; therefore, you must use another administrative tool, such as iManager, to create the Alias object in the Internet Services container.
With the Forward Local Undeliverable Messages option configured on every remote messaging server and with each Messaging Server object (both distributed and standalone) represented in the Internet Services container, the messaging system is now fully functional.
To summarize:
To minimize messaging server reaction time and ensure high system performance, distributed messaging servers require fast access (ideally, local access) to their corresponding Message Server objects and the Internet Services container. Servers running the NMAP Agent require fast access (ideally, local access) to all User objects in the messaging system. Standalone messaging servers require fast access (ideally, local access) to their corresponding Message Server object and the User objects within their assigned contexts (that is, those User objects with a mailbox directory on the server).
Because WAN systems are geographically dispersed, the remote, standalone messaging servers do not automatically have fast access to their associated Messaging Server object or the User objects in their assigned contexts. To give each remote, standalone messaging server local access to its Messaging Server object and assigned User objects, create a read/write replica for each remote, standalone messaging server of the partition containing the Messaging Server object and its associated User objects.
To give every distributed messaging server local access to its associated Messaging Server object and the Internet Services container, create a read/write replica on each messaging server of a partition containing the Internet Services container. (Internet Services contains all distributed Messaging Server objects.) By default, the root partition contains the Internet Services container. However, to avoid replicating the entire root partition on the messaging server, create a separate partition for the Internet Services container.
To give each distributed NMAP server local access to all User objects in the messaging system, create a read/write replica on each NMAP server of all partitions containing User objects that belong to the messaging system.