Planning
Use this topic as an overview of planning task.
- Roadmap for deploying Domino® servers
  Use this as a tool when planning how to integrate HCL Domino® into your existing environment.
- Planning server-to-server connections
  Servers must connect to each other to exchange data, for example to replicate databases and exchange mail. You can create connections between servers across a local area network (LAN) or wide area network (WAN), by using a pass-through server (a server that acts as an intermediary server between a client and its destination), or over the Internet. Create a Server Connection document whenever you need to establish any new or additional server connections. You can modify this document when necessary.
- Planning directory services
  HCL Domino® provides a range of directory service features.
- Planning a mail routing topology
  HCL Domino® offers you considerable flexibility in configuring your mail system infrastructure, allowing you to use HCL Notes® routing, SMTP routing, or both, for internal and external messages.
  - Connection topologies for mail routing
    Network mail routing occurs across a mix of hub-and-spoke and peer-to-peer connections.
  - Clients accessing the Domino® server
    Users who have mail files on the HCL Domino® server can use either the HCL Notes® client or an Internet mail client to access their mail.
- Planning a cluster
  When planning a cluster, it is important to consider the performance and ability of your hardware. The cluster must have enough CPU power, memory, and disk space to handle the cluster traffic and the number of databases and replicas required.
- Planning the TCP/IP network
  The default TCP/IP configuration for an HCL Domino® server is one IP address that is globally bound, meaning that the server listens for connections at the IP addresses of all NICs on the computer. Global binding works as long as the computer does not have more than one IP address offering a service over the same assigned TCP port.
- Messaging overview
  The HCL Domino® mail system has three basic components: Domino mail servers, Domino mail files, and mail clients. The Domino mail server is the backbone of an organization's messaging infrastructure, acting both as an Internet mail server and an HCL Notes® mail server. Domino provides standards-based Internet messaging through its support of the Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), Internet Message Access Protocol (IMAP), and Multipurpose Internet Mail Extensions (MIME). At the same time, Domino supports Notes mail through the use of Notes routing protocols -- Notes remote procedure calls (NRPC) -- and the Notes rich text message format.
- Planning your Notes® client deployment
  Use the references listed here to plan for, install, upgrade to, and configure the HCL Notes® client.
- Planning security
  An important aspect of planning security for your Domino® environment is understanding the tasks and features involved with securing each type of resource.

Connection topologies for mail routing

Network mail routing occurs across a mix of hub-and-spoke and peer-to-peer connections.

In a hub-and-spoke topology, mail traffic passes between a central hub server and multiple spoke servers; no mail is exchanged directly among the spokes. A hub-and-spoke topology is suited to handling a high volume of mail across a large organization. In a peer-to-peer topology, on the other hand, every server connects to every other server.

In larger networks, create an HCL Domino® server cluster to act as the mail hub and specify the cluster as the destination in connection documents originating from spoke servers.
When connecting Domino® domains, designate one server in each domain to connect to other domains. In larger networks, make this connecting server part of a Domino® cluster to provide failover.
When connecting domains across a wide-area network (WAN), ensure that the connection documents match the physical network path of the WAN. For example, in a network where multiple WAN connections originate from a central site (hub-to-spoke design), create connection documents that follow this same design, with Connection documents between the hub server or server cluster and each spoke server, and vice-versa.
When setting up a connection from a spoke server to a clustered hub, specify the name of the cluster as the destination server in connection documents.
Establish a single connection document to define routing from a hub server to each spoke server by creating a server group that includes each spoke server as a member and specifying this group as the destination server in the connection document from the hub server. For example, create a group MailSpokes and add the servers Mail1/renovations, Mail2/renovations, SalesMail/renovations, and HRMail/renovations to this group. Then create a connection document from the hub server that lists MailSpokes as the destination server.
Note: You cannot use a wildcard character (*) to represent part of the source server's name in a Connection document that is used to define routing from all spoke servers in a domain to a central hub server or server cluster.