Lotus Notes and Domino was created by Ray Ozzie in 1989. But Lotus was purchased by IBM in 1991.

The physical location of a NoteID is specified in its RRV (Record Relocation Vector).

When a file or Document is deleted, Domino keeps a deletion stub so that it knows not to replace that file from a replica.

MAIL.BOX: Messages in a mail box fall into 3 basic states: Pending, Held, and Dead.

Pending - a message which is in the pending state is waiting to be transferred or delivered.

Held - Held mail represents mail which fails to be delivered or transferred and would normally result in a Non-Delivery report
being sent to the originator. By turning the feature on, any mail which would normally be returned as a Non-Delivery would
be 'held' instead of being returned. This provides administrators with a chance to fix any problems which would have caused
the Non-Delivery report to be sent and then release the held mail. The icon which appears next to mail in the 'Held' state is:

Dead - Dead mail represents mail which fails to be delivered to the intended recipient AND whose resulting Non-Delivery
report fails to be delivered to the originator of the message. A message in the 'Dead' state lists the recipient as the originator of
the message and the intended recipients as the list of people the originator of the message first sent it to. The icon which
appears next to mail in the 'Dead' state is:

Domino Server Tasks: A few lines in NOTES.INI define which server tasks are started when the server starts up, and also
which scheduled tasks are to run at various times during the day.

The Server Tasks= line lists the tasks to start as the server starts up. The scheduled tasks are listed in the
ServerTasksAt0= to ServerTasksAt23= lines. These specifications use the 24-hour clock, where 0 is midnight and
23 is 11:00 P.M.

Another option for scheduling tasks is the Program document in the Domino Directory

By default, the following tasks are configured to start, depending on how the server has been configured:

• When the Quick and Easy Configuration setup option is selected, the tasks set to start at startup are
Router, Replica, Update, AMgr, AdminP, CalConn, Event, Sched, Stats, and Maps. Then
other tasks are added depending on which other client audience options are selected. When the Advanced
Configuration setup option is selected, the tasks set to start at startup are AdminP, AMgr, Update,
Replica, Router, and Maps. Other tasks, such as CalConn, Event, Sched, and Stat, are
optionally added if selected. Other tasks are added if they are selected by name.

AdminP
The Administration Process automates many administration tasks. This task has the following commands
available to modify its behavior while it is running:
tell adminp process all
Instructs the admin process to process all new and modified immediate/interval/daily/delayed requests.
tell adminp process daily
Instructs the admin process to process all new and modified daily requests.
tell adminp process delayed
Instructs the admin process to process all new and modified delayed requests.
tell adminp process interval
Instructs the admin process to process all immediate and interval requests.
tell adminp process new
Instructs the admin process to process all new requests.
tell adminp process people
Instructs the admin process to process all new and modified requests to update Person records within the
Domino Directory.
tell adminp process time
Instructs the admin process to process all new and modified requests to delete mail files that become
unlinked.
tell adminp show databases
Lists the databases that an administration server manages, and also lists databases that do not have an
administration server configured.

AMgr
The Agent Manager runs scheduled and triggered agents in Domino databases. This task has the following
commands available to modify its behavior while it is running:
tell amgr pause
Pauses the agent manager service, so no new agents can be scheduled for execution on the server.
tell amgr resume
Resumes the agent manager service, so new agents can be scheduled for execution on the server.
tell amgr schedule
Displays the scheduled agents that are to run today, and also the database in which they reside.
tell amgr status
Displays the status of the agent manager, and also configuration information of the agent manager from
the server document in the Domino Directory.

Agent Manager (Amgr) Examples: 1. If a user is moved and certified by a new hierarchy, then that too is considered renaming.
So enabling an agent which sends the email notification to user about name changes.
The rename tasks are:
v Change a Notes user’s common name
v Notify a user of a change to private design elements during a name change
v Rename a Web user
v Move a user name in the new hierarchy
v Upgrade a user name from flat to hierarchical
Notifying users of changes to private design elements during a name change
You can enable an agent that sends to the user an e-mail message notifying the user of a name change
and containing links to databases in which the user created or modified design elements such as a folder
or view. To update the private design elements with the user’s new name, the user must then open the
database via the database links in the e-mail notification. This update to the user name allows the user to
maintain access to their own private design elements. Enable the Mail Notification agent from within the
administration requests database (ADMIN4.NSF).
Note: The AdminP Mail Notification agent runs only on Domino Release 5.05 or more recent servers and
sends e-mail to Notes Release 5.05 or more recent clients.
1. From the Domino Administrator, click Server - Analyses.
2. Click Administration Requests (7).
3. Locate the administration request to rename the user and then open the request.
4. Choose Actions - Enable/Disable User Notification. The agent is enabled and automatically sends to
the user an e-mail message containing links to databases in which the user created or modified design
elements such as a folder or view.
5. Click OK.
Troubleshooting name changes
The public key in the Person document must match the one on the user ID. If a public key has been
changed or corrupted in some way, you see this message in the Administration Requests database: ″The
name to act on was not found in the Address Book.″

When you initiate a user’s name change, the user may be prompted to accept or reject the name change.
If the user rejects the name change, an administration request is generated that requires you to either
accept the user name reverting to the original name or reject the name reverting to the original user
name. The user is prompted if the user has selected the ″Ask your approval before name changes″ option
on the Notes Name Changes dialog box.

If the expiration date for the name change is reached and the user has not responded, an administration
request is issued asking you to accept a request to retract the name change. You can then either accept
the request to retract the name change, or you can reject that request. If you accept the name change
retraction, the administration request for rejecting a name change are generated.

You can also move a user to another Organization, however to do so, your Domino Directory must
contain cross-certificates between the Organizations involved.

Notes workstations and Domino servers use the Notes remote procedure call (NRPC) protocol running over the LAN’s
network protocol to communicate with other Domino servers.
Other client systems, such as Web browsers, Internet mail clients, wireless application protocol (WAP)
devices, and personal information management (PIM) devices, can also communicate with Domino
servers.
Isolated LANs can be connected by WANs. A WAN is either a continuous connection -- such as a
Frame-relay, leased telephone line, or digital subscriber line (DSL) -- or a dialup connection over a modem
or Integrated Services Digital Network (ISDN) line.

The foundation for communication between Notes workstations and Domino servers or between two Domino servers is the
Notes remote procedure call (NRPC) service.

If the network connection fails while the Domino server is writing to a database on the file server or
shared NAS server, the database can become corrupted.

NRPC service uses a combination of the Notes Name Service and DNS to resolve server names to
network addresses.

To configure server partitions to share the same IP address and the same NIC, you use port mapping.
With port mapping, you assign a unique TCP port number to each server partition and designate one
Partition to perform port mapping. The port-mapping partition listens on port 1352 and redirects Notes
and Domino connection requests to the other partitions.

Default port for NRPC: By default, all NRPC connections use TCP port 1352. Because the Internet
Assigned Number Authority (IANA) assigned Lotus Domino this port number, non-Domino applications
do not usually compete for this port.
Do not change the default NRPC port unless:
v You can use a NAT or PAT firewall system to redirect a remote system’s connection attempt.
v You are using Domino port mapping.
v You create a Connection document that contains the reassigned port number.
To change the default NRPC port number, use the NOTES.INI setting TCPIPportname_TCPIPAddress and
enter a value available on the system that runs the Domino server. TCP ports with numbers less than
5000 are reserved for application vendors. You may use any number from 1024 through 5000, as long as
you don’t install a new application that requires that number.
Note: When setting the NOTES.INI variables for port mapping, do not include a zone in a port mapped
address. The zone is only valid locally.
Default ports for Internet services: You may occasionally need to change the number of the TCP or SSL
port assigned to an Internet service. Lotus Domino uses these default ports for Internet services:
Service Default TCP port Default SSL port
POP3 110 995
IMAP 143 993
LDAP 389 636
SMTP inbound 25 465
SMTP outbound 25 465
HTTP 80 443
IIOP 63148 63149
Server Controller N/A 2050

Server Types:
v Domino Utility Server -- Installs a Domino server that provides application services only, with
support for Domino clusters. The Domino Utility Server removes client access license
requirements. Note that it does NOT include support for messaging services. See full licensing text
for details.
v Domino Messaging Server -- Installs a Domino server that provides messaging services. Note that
it does NOT include support for application services or Domino clusters.
v Domino Enterprise Server -- Installs a Domino server that provides both messaging and
application services, with support for Domino clusters

The Certification Log (certlog.nsf)

When you set up the first Domino server in a domain, the Server Setup program creates the Certification
Log. If you delete the log, you can recreate it, but be aware that the new log will not contain the
information it previously stored.
The Certification log records information related to recertification and name changes. When you add
servers and users to Domino, the Certification Log maintains a record of how you registered them. For
each registered server and user, the Certification Log stores a document containing the following
information:
v Name and license type
v Date of certification and expiration
v Name, license type, and ID number of the certifier ID used to create or recertify the ID

Create a replica of the Certification Log on every server that is a registration server and on every server
that stores a Domino Directory that is used for user management -- for example, renaming and
recertifying users. If the server whose Domino Directory replica you are using does not have a
Certification Log, user-management actions will fail.

Server registration
Before you install and set up additional servers, you must register them. In effect, registering a server
adds the server to the system. The server registration process creates a Server document for the server in
the Domino Directory and creates a server ID. After registering and installing a server, you use the Server
Setup program to obtain a copy of the Domino Directory for the new server and to set up the server to
run particular services and tasks -- for example, the HTTP service, the Mail Router, and so on.

When you register a server, Domino does the following:

v Creates a server ID for the new server and certifies it with the certifier ID
v Creates a Server document for the new server in the Domino Directory
v Encrypts and attaches the server ID to the Server document and saves the ID on a disk or in a file on
the server
v Adds the server name to the LocalDomainServers group in the Domino Directory
v Creates an entry for the new server in the Certification Log (CERTLOG.NSF)

How a server connects to another server

A connecting server uses the following steps to determine how to connect to a destination server. As soon
as the connecting server successfully connects to the destination, it stops searching for additional
connection methods.
1. The connecting server tries to connect using the same method it used the last time it made a
successful connection to the destination server. Note these two exceptions:
v If the server never connected to the destination server, the server searches for a path (consisting of
a network port and any passthru servers) to the destination server.
v If the server has connected previously, but the connection now fails, the server conducts a new path
search if it is the first attempt of the day.
2. The connecting server checks to see if it already has a WAN port connection to the destination server.
3. The server examines normal-priority Connection documents in the Domino Directory for information
on what path to use to connect to the destination server. A normal-priority Connection document is
one that has Normal selected in the ″Usage priority″ field. If multiple normal-priority Connection
documents exist for the same destination server, the server chooses the Connection document to use
based on the type of connection in the following order:

v Local Area Network

v Network Dialup
v Notes Direct Dialup
v Passthru server
v Hunt group of passthru servers
Note: A server that uses a passthru connection to reach the destination server must first be able to
connect to the passthru server. To provide information on how to connect to the passthru server,
you may have to create an additional Connection document.
4. The connecting server checks information stored in memory about other servers in the server’s Notes
named network. It uses this information to define a path to the destination server. The server reads
this information from Server documents in its local Domino Directory.
5. If the connecting server’s local Domino Directory does not contain information about the destination
server, it tries to connect directly to the destination server on the LAN by using the server common
name as its address.
6. The connecting server checks the low-priority Connection documents. A low-priority Connection
document is one that has Low selected in the ″Usage priority″ field.
7. If the connecting server still cannot find a path to the destination server, it issues a message that a
connection is not possible.
Note: For workstations connecting to servers, the search logic is the same except that the workstation
tries to use the passthru server listed as default in the Location document to make the connection if Steps
1 through 5 fail. If the Location document does not define a default passthru server and the workstation
is already connected to a server over a Notes Direct Dialup connection, the workstation uses that server
as a passthru to reach the destination server.
To display information about how a server makes a connection, open the Miscellaneous Events view in
the log file (LOG.NSF). To change the amount of information Domino records about connections in the
log file, change the log level

Replication and server topology

As the number of Domino servers on your network increases, so does the amount of replication required
to distribute information across the network. Because replication uses memory and processing time, plan
how servers connect to perform replication. If you allow servers to replicate at random, so that a given
server replicates a single database with multiple servers, or perhaps replicates different databases with
different servers, servers can become so overloaded with replication requests that it interferes with their
ability to respond to client requests.
To provide for efficient replication, consider setting up some servers as dedicated replication servers.
Using dedicated servers to handle replication greatly reduces the amount of work that database servers
have to devote to replication, because the database servers have to replicate with the replication servers
only, instead of having to replicate with every server that maintains a copy of a given database. To
control replication, you create Connection documents that specify which servers to replicate with and
when.
How you connect servers for replication depends on many factors, including the layout of physical
network and the size of your organization, as well as the extent to which you want to re-use existing
Connection documents created for mail routing. There are several different configurations, or topologies,
you can use to control how replication occurs between servers:
v Hub-and-spoke
v Peer-to-peer
v Ring
Choose the replication strategy that provides the most efficient replication performance. In many cases,
you’ll use different topologies in different parts of the network.

Using a hub-and-spoke topology to manage replication

A hub-and-spoke topology is generally the most common and efficient replication topology in larger
organizations, because it minimizes network traffic. Hub-and-spoke replication establishes one central
server as the hub, which schedules and initiates all replication with all of the other servers, or spokes.
The spokes update the hub server by replication (and mail routing), and the hub in turn updates each
spoke. Hub servers replicate with each other or with master hub servers in organizations that use more
than one hub. In short, the hub server acts as the traffic manager of the system, overseeing system
resources, ensuring that replication takes place with each spoke in an orderly way, and guaranteeing that
all changes are replicated to all spoke servers.
To set up replication in a hub-and-spoke system, you create one Connection document for each
hub-and-spoke connection. To ensure that the replication task on the hub, rather than the spokes, assumes
most of the work always, in each Connection document specify the hub server as the source server, the
spoke server as the destination server, and pull-push as the replication method.
A hub-and-spoke topology can be especially useful at large, multiple-server sites or in a centralized office
that needs to connect via phone or leased lines to smaller, regional offices. If you have a large site, you
can use a combination of topologies -- for example, two hub-and-spoke arrangements and one
peer-to-peer arrangement between the two hub servers.
The major drawback of hub-and-spoke topology is that it is vulnerable to single point of failure if the
hub is not working. Deploying a backup server that replicates the hub and can quickly be reconfigured
into a hub server if the primary hub goes down can alleviate this shortcoming.
Benefits of a hub-and-spoke topology
1. Install multiple protocols on hub servers to enable communication in a Domino system that uses more
than one protocol. This places hub servers in multiple Notes named networks, another source of
efficiency. Hub servers can connect multiple Notes named networks, where a single hub server and its
spoke servers often make up one Notes named network.
2. Bridge parts of a network -- for example, a LAN and a WAN.
3. Centralize administration of the Domino Directory, standardize database ACLs, and limit access to the
hub. You can designate the hub with Manager access and the spokes with Reader access so that you
make those changes on one replica on the hub to synchronize the spokes.
4. Designate hubs by role -- for example, replication hubs and mail hubs.
5. Place server programs such as message transfer agents on hubs to make them easily accessible.
6. Connect remote sites with a hub server.
7. Minimize network traffic and maximize network efficiency.
8. Centralize data backup at the hub. By backing up databases on the hub only, you conserve resources
on spoke servers.
9. Improve server load balancing. However, network traffic increases on the hub LAN segment. If you
have more than 25 servers per hub, establish tiers of hubs. If a hub goes down, replication for that
hub and its spokes is disabled until the hub is repaired or replaced.
Note: Do not use hub-and-spoke replication for databases larger than 100MB that have replicas on less
than four servers. Instead, schedule replication for these databases to occur separately from other
replications.
Using a peer-to-peer topology to manage replication
In a peer-to-peer topology, replication is less centralized than in a hub-and-spoke configuration, with
every server being connected to every other server. Because peer-to-peer replication quickly disseminates
changes to all servers, it is often the best choice for use in small organizations, or for sharing databases
locally among a few servers. However, it can be inefficient when a database resides on more than a few
servers.
In a peer-to-peer topology, the potential for replication problems decreases, because only two servers
communicate for each replication and no hub or intermediary servers are involved. However,
peer-to-peer replication requires many Connection documents, increases administration since you must
avoid overlap in replication schedules, and prevents you from standardizing ACL requirements.
Functions of Domino servers:
Servers that provide Notes and/or browser users with access to applications
v Hub servers that handle communication between servers that are geographically distant
v Web servers that provide browser users with access to Web applications
v Servers that manage messaging services
v Directory servers that provide users and servers with information about how to communicate with
other users and servers
v Passthru servers that provide users and servers with access to a single server that provides access to
other servers
v Domain Search servers that provide users with the ability to perform searches across all servers in a
Domino domain
v Clustered servers that provide users with constant access to data and provide load-balancing and
failover
v Partitioned servers that run multiple instances of the Domino server on a single computer
v Firewall servers that provide Notes users with access to internal Domino services and protect internal
servers from outside users
v xSP servers that provide users with Internet access to a specific set of Domino applications

Hierarchical naming for servers and users

Hierarchical naming is the cornerstone of Domino security; therefore planning it is a critical task.
Hierarchical names provide unique identifiers for servers and users in a company. When you register
new servers and users, the hierarchical names drive their certification, or their level of access to the
system, and control whether users and servers in different organizations and organizational units can
communicate with each another.
A hierarchical name scheme uses a tree structure that reflects the actual structure of a company.

Partitioned servers
Using Domino server partitioning, you can run multiple instances of the Domino server on a single
computer. By doing so, you reduce hardware expenses and minimize the number of computers to
administer because, instead of purchasing multiple small computers to run Domino servers that might
not take advantage of the resources available to them, you can purchase a single, more powerful
computer and run multiple instances of the Domino server on that single machine.
On a Domino partitioned server, all partitions share the same Domino program directory, and thus share
one set of Domino executable files. However, each partition has its own Domino data directory and
NOTES.INI file; thus each has its own copy of the Domino Directory and other administrative databases.
If one partition shuts down, the others continue to run. If a partition encounters a fatal error, Domino’s
fault recovery feature restarts only that partition, not the entire computer

Partitioned servers can provide the scalability you need while also providing security. As your system
grows, you can migrate users from a partition to a separate server. A partitioned server can also be a
member of a cluster if you require high availability of databases. Security for a partitioned server is the
same as for a single server.
When you set up a partitioned server, you must run the same version of Domino on each partition.
However, if the server runs on UNIX®, there is an alternative means to run multiple instances of Domino
on the server: on UNIX, you can run different versions of Domino on a single computer, each version
with its own program directory. You can even run multiple instances of each version by installing it as a
Domino partitioned server.
Deciding whether to use partitioned servers
Whether or not to use partitioned servers depends, in part, on how you set up Domino domains. A
partitioned server is most useful when the partitions are in different Domino domains. For example,
using a partitioned server, you can dedicate different Domino domains to different customers or set up
multiple Web sites. A partitioned server with partitions all in the same Domino domain often uses more
computer resources and disk space than a single server that runs multiple services.
When making the decision to use partitioned servers, remember that it is easier to administer a single
server than it is to administer multiple partitions.

Deciding how many partitions to have

How many partitions you can install without noticeably diminishing performance depends on the power
of the computer and the operating system the computer uses. For optimal performance, partition
multiprocessor computers that have at least one, and preferably two, processors for each partition that
you install on the computer.

Certifier IDs and certificates

Certifier IDs and certificates form the basis of Domino security. In order to place servers and users correctly within the
organization’s hierarchical name scheme, we create a certifier ID for each branch on the name tree. We use the certifiers
during server and user registration to ″stamp″ each server ID and user
ID with a certificate that defines where each belongs in the organization. Servers and users who belong to
the same name tree can communicate with each other; servers and users who belong to different name
trees need a cross-certificate to communicate with each other.
Note: You can register servers and users without stamping each server ID and user ID if you have
migrated the certifier to a Domino server-based certification authority (CA).

There are two types of certifier IDs: organization and organizational unit.
You can create up to four levels of organizational unit certifiers.

Each time you create a certifier ID, Domino creates a certifier ID file and a Certifier document. The ID file
contains the ID that you use to register servers and users. The Certifier document serves as a record of
the certifier ID and stores, among other things, its hierarchical name, the name of the certifier ID that
issued it, and the names of certificates associated with it.

Advanced Domino services

These Domino services, which are necessary for the proper operation of the Domino infrastructure, are
enabled by default when you set up a Domino server:
v Database Replicator
v Mail Router
v Agent Manager
v Administration Process
v Calendar Connector
v Schedule Manager
v DOLS (Domino Off-Line Services)

User Registration Queue (USERREG.NSF) : This database contains information on users pending registration. When you
exit the Register Person dialog box, you can save all users pending registration and register them later. When you access the
dialog box again, the User Registration Queue automatically opens to display all users pending registration.

You can also register users by importing them from a text file or migrating them from a foreign directory.

An administrator can be designated as a Registration

Authority (RA) for the server-based certification authority (CA). You can now assign to the administrator
responsible for user registration, the role of RA. This allows one administrator to register users with
certificates issued by the server-based certification authority.

Registering users
You can use any of these methods to register Notes users:
v Basic user registration
v Advanced user registration
v Text file registration
v Registration settings
v Migration tools (for people using an external mail system or directory) registration : The following list details the types of
users you can migrate into Notes:
* Microsoft Exchange
* LDIF (from an LDAP directory)
* LDAP
* Windows 2000/Windows 2003
* Active Directory
v Basic user registration from the Web Administrator
v Advanced user registration from the Web Administrator

whether you need to import users from a foreign mail system or directory, and whether your
user settings are in a text file.

Moving a user’s mail file and roaming files from the Domino
Administrator
You may need to move mail files when you need more space on a server or when users change jobs.
When a mail file is moved, the Administration Process first moves it to a new server, then issues a
request to delete the old mail file from its original mail server. You must approve this mail file deletion.
The Administration Process also changes the information in the ″Mail file name″ and ″Mail server″ fields
in the user’s Location document.
To move only a mail file
1. To move a user’s mail files, you must have:
v Editor access with Create documents role, or Author access with the UserModifier role in the
Domino Directory
2. From the Domino Administrator or Web Administrator, click the People & Groups tab.
3. Click People and select the person whose mail file you are moving.
4. Click Move to Another server.
5. Choose a destination server to which you are moving the mail file. If the destination server you
choose is a clustered server, it appears ″checked″ in the Additional mail server field on this dialog
box.
6. (Optional) Enter a new directory to which the mail file should be moved. You can accept the default
of mail\.
7. (Optional) Click Link to Object Store if you are using shared mail and want to link the mail file to
the object store.
8. (Optional) Choose one of theses:
v From the Domino Administrator, click Remove all mail replicas if the server is in a cluster and
you want all mail replicas to be deleted.
v From the Web Administrator, click Delete old replicas if the server is in a cluster and you want to
delete mail file replicas from a cluster.
9. If you are working with clustered servers, you can selected additional servers in the cluster to which
the mail database can be moved. To select additional servers, click the check box next to the server
name in the Additional mail server field.
10. Click OK.
11. Click Close.
To approve the mail file deletion
When the mail file is on the new mail server, you must approve the mail file deletion in the
Administration Requests database (ADMIN4.NSF).
1. From the Domino Administrator or the Web Administrator, click Server - Analysis - Administration
Requests (7).
2. Choose the Pending Administrator Approval view.
3. Locate the Approve mail file deletion request and open that request.
4. Click ″Edit Document.″ Review the request.
5. Click ″Approve Mail File Deletion.″
6. Click Save and Close.

How license tracking works

When License Tracking is turned on, client usage is tracked on each server and the data is temporarily
stored in the file LICENSE.NCF. When a user authenticates with a server using the Notes client, HTTP,
IMAP, POP3, SMTP, or the LDAP protocol, the user’s full canonical name, protocol, and time and date of
access are collected. Once each day (at midnight) , an administration request sends to the administration
process, information regarding new users and information regarding users who have not accessed the
server within the last 30 days. The administration process running on the administration server processes
the request.
The Domino User License Tracking database is created and resides on the administration server, not on
all servers. The database is not created as soon as the License Tracking feature is enabled; instead, it is
created when the administration process processes the first administration request to update the database.
The administration process creates a new User License document in the Domino User License Tracking
database (USERLICENSES.NSF) for each new user reported in the administration request. Documents are
updated with the new time and date for those users who already have a document in the Domino User
License Tracking database. If a user does not access any servers in the Domino domain for one full year,
the corresponding User License document is deleted from the Domino User License Tracking database.
Daily updates to the database enable you to review this information at any time to obtain an up-to-date
report on the number of client licenses that you have available for use.
Note: If a user is deleted from the Domino Directory, the corresponding document in the Domino User
License Tracking database is deleted. If a user is renamed, the corresponding document is also renamed
Accordingly
Enabling or disabling license tracking
Use this procedure to either enable or disable License Tracking.
1. From the Domino administrator, click the Configuration tab.
2. Choose Server - Configurations.
3. Select the server and click Edit Configuration.
4. On the Basics tab, in the License Tracking field, click Disabled or Enabled according to what you want
to do.
5. Click Save and Close.

Replication: Keep in mind that two replicas will contain slightly different content between replications. If users need
access to the most up-to-date information in a database, you can create replicas on clustered servers and then set up replication
in clusters. In a cluster, all replicas are always identical because each change immediately replicates to other servers in the
cluster.
Because replication transfers only changes to a database, the network traffic, server time, and connection costs are kept to a
minimum. During scheduled replication, by default, the initiating server first pulls changes from the destination server and
then pushes changes to the destination server. As an alternative, you can schedule replication so that the initiating server and
destination server each pull changes or so that the initiating server pulls changes only or pushes changes only.
How server-to-server replication works
For server-to-server replication, the Replicator on one server calls another Domino server at scheduled
times. By default, the Replicator is loaded at server startup.
To schedule replication between servers, the servers must be able to connect to each other in order to
update replicas. You may need to create Connection documents to enable server connections, depending
on your server topology.
Because replication transfers only changes to a database, the network traffic, server time, and connection costs are kept to a
minimum.
During scheduled replication, by default, the initiating server first pulls changes from the destination
server and then pushes changes to the destination server.

Steps: 1. Replication schedule settings in a Connection document take effect.

2. The Replicator constructs a list of local files to replicate and asks the remote server to find those that
have a match with the list of local files.
3. When the Replicator finds a match, it looks at the replication history to find the last time the replicas
replicated. The Replicator uses the history in the local database which is the destination database
when ″pulling″ and is the source database when ″pushing.″

For replication to occur properly, you must assign servers the appropriate access in the database ACL.

Remove documents not modified in the last x days: The number of days specified here, known as the
purge interval, controls when Domino purges deletion stubs from a database.
Deletion stubs are markers that remain from deleted documents so that Domino knows to delete documents in other replicas of
the database. Because deletion stubs take up disk space, Domino regularly removes deletion stubs that are at least as old as the
value specified. It checks for deletion stubs that require removal at 1/3 of the purge interval. For example, assuming the
default value, 90 days, when a user opens a database, Domino checks if it has been at least 30 days since it removed deletion
stubs, and if so it removes any deletion stubs that are at least 90 days old. The Updall task, which runs by default at 2:00 AM,
also removes deletion stubs.
You can shorten the purge interval, if you want, but be sure to replicate more frequently than the purge
interval; otherwise, deleted documents can be replicated back to the replica.
Optionally, you can select the check box to remove documents in the replica that haven’t changed within
the purge interval. If you select the check box, when Domino removes deletion stubs it also removes
documents that haven’t changed within the specified number of days. These documents are purged,
meaning no deletion stubs remain for the documents, so the documents aren’t deleted in other replicas.

Receive summary and 40KB of rich text only: If you select this setting, Domino prevents large
attachments from replicating and shortens the documents that this replica receives. The shortened
documents contain only a document summary that includes basic information, such as the author and
subject, and the first 40K of rich text.
When users open a shortened document, they see ″(TRUNCATED)″ in the document title. To view the
entire document, users open it and choose Actions - Retrieve Entire Document.

Replication priority doesn’t apply to replicas on a cluster of servers. Cluster replication occurs whenever
a change occurs, not according to schedules in Connection documents.
Note: A database that doesn’t replicate should have at least one server in its ACL to serve as the
administration server for the database. This allows the Administration Process on a server to update
names in the ACL when names in the organization change.

Note: Do not use the server’s common name when replicating servers. Only the server’s full hierarchical
name should be used during server-to-server replication. This applies to all instances of server-to-server
replication.

By default, Domino uses Pull-Push as the replication direction. However, you can specify a different
replication direction.
v Pull-Push, the default replication direction, is a two-way process in which the calling server pulls
updates from the answering server and then pushes its own updates to the answering server. Using
Pull-Push, the replicator task on the calling server performs all the work.
v Pull-Pull is a two-way process in which two servers exchange updates. Using Pull-Pull, two replicators
-- one on the calling server and one on the answering server -- share the work of replication.
v Push-only is a one-way process in which the calling server pushes updates to the answering server.
One-way replication always takes less time than two-way replication.
v Pull-only is a one-way process in which the calling server pulls updates from the answering server.
One-way replication always takes less time than two-way replication.

When you force immediate server-to-server replication, you can initiate replication in one or in both directions.

The calendar and scheduling features use the Schedule Manager (Sched task), the Calendar Connector
(Calconn task), and the Free Time system (a combination of Sched, Calconn, and nnotes tasks) to operate.
When you install Domino on a server (any server except a directory server), the Sched and Calconn tasks
are automatically added to the server’s NOTES.INI file. When you start the server for the first time, the
Schedule Manager creates a Free Time database (BUSYTIME.NSF for non-clustered mail servers and
CLUBUSY.NSF for clustered mail servers) and creates an entry in the database for each user who has
filled out a Calendar Profile and whose mail file is on that server or on one of the clustered servers.

When users invite other users to meetings, the Free Time system performs the free-time lookups. The Free Time system also
searches for and returns information on the availability of resources. If the lookup involves searching in Free Time systems on
different servers or scheduling applications, the Calendar Connector sends out the queries. When users schedule appointments
in their calendars and reserve resources, the Schedule Manager task collects and updates that information in the Free Time
database.
By default, the Schedule Manager has access to the Free Time database, so you do not have to define the
ACL for this database.

For clustered mail servers, the Schedule Manager creates the clustered Free Time database
(CLUBUSY.NSF) the first time a server starts.

The effective policy for a user is a set of derived policy settings that are dynamically calculated at the
time of execution.

In addition to organizational policies, users may also have explicit policies assigned to them. In that case,
the order of resolution is that all organization policy settings are resolved first, then any explicit policy
settings are resolved.

Domain Search
Notes and Web users can use Domain Search to search an entire Domino domain for database
documents, files, and attachments that match a search query.

To support Domain Search, you need to designate a Domino server as the indexing server, which builds a
domain wide index that all Domain Search queries run against. In order for the indexing server to build
the index, you must first create a Domain Catalog on the server -- a database that controls which
databases and file systems get indexed.

It is best to set up the Domain Catalog on the same server that indexes the Domino domain. If you have
a very large number of databases to catalog, you can decrease network traffic by running the Catalog task
nightly on all servers. That way, when the Catalog task runs on the server that contains the Domain
Catalog, the Domain Catalog uses pull replication from the local catalogs rather than spiders every
database.

The Domain Catalog, a database that uses the CATALOG.NTF template, controls which databases and file
systems get indexed for Domain Search. Even if your organization is not implementing Domain Search,
the Domain Catalog is a useful administrative tool for such tasks as keeping track of the location of
database replicas.
You create the Domain Catalog by enabling the Catalog task on the server that will index the Domino
domain.
The Administration Process : The Administration Process is a program that automates many routine administrative
tasks.

The Administration Process automates these tasks:

v Name management tasks, such as rename person, rename group, delete person, delete group, delete
server name, recertify users, and store Internet certificate.
v Mail file management tasks, such as delete mail file and move mail file.
v Server document-management tasks, such as store CPU count, store platform, and place network
protocol information in Server document.
v Roaming user management, such as roaming user setup, move roaming users to other servers, upgrade
a nonroaming user to roaming status, and downgrade roaming user to nonroaming status.
v User mail file management tasks, such as performing Access Control List (ACL) changes and enabling
agents. For example, the ″Out of Office″ agent is enabled and disabled by Notes client users.
v Person document management tasks, such as storing the user’s Notes version and client platform
information.
v Replica management tasks, such as create replica, move replica, or delete all replicas of a database.

Administration servers
Administration servers control how the Administration Process does its work. You specify an
administration server for the Domino Directory and for specific databases. By default, the first Lotus
Domino server you set up in a domain is the administration server for the Domino Directory. The
administration server for the Domino Directory maintains the Domino Directory’s ACL, performs deletion
and name change operations in that Domino Directory, and these changes are replicated to other servers
in the domain. If you have multiple directories in your domain -- not replicas of other domain’s
directories, but more than one of your own -- you can specify an administration server for each of the
directories in your domain. Do not specify an administration server in your domain for a replica of
another domain’s Domino Directory.

The Administration Requests database

The Administration Requests database (ADMIN4.NSF) is created on the administration server for the
Domino Directory when that server starts for the first time. Requests for work to be done by the
Administration Process are stored in the Administration Requests database.

Every server in the domain stores a replica of the Administration Requests database and
the Domino Directory.

The Certification Log

To use the Administration Process to perform name changes and recertifications, the Certification Log
(CERTLOG.NSF) must reside on the server that stores the Domino Directory in which you will initiate
the name change or recertification. If the Certification Log exists on another server, move the Certification
Log to the server containing the Domino Directory on which you are initiating the name change or
recertification. The Certification Log contains a permanent record of how you register servers and users, including information
about the certifier ID. The Certification Log also contains messages that describe the results of recertification requests that the
Administration Process is processing.

If the domain has only a few servers, consider using one administration server for both the Domino
Directory and for other databases.

A second option involves using a dedicated registration server as the administration server for the
Domino Directory. You limit this server’s responsibility to the processing of Domino Directory changes.
You can then use other servers, such as database hubs, for processing ACL changes to other databases. To
do so, specify the database hub as the administration server for those databases. You can divide the
responsibility for database ACL changes among several administration servers; but, you must make sure
that when there are multiple replicas of a database in the domain, you assign an administration server for
only one replica

Using a server that contains mail and other databases as the administration server for the Domino
Directory is possible, but is not recommended for performance reasons.

Always run the most recent version of Lotus Domino 7 on the administration server of the Domino
Directory and the extended administration servers, so that you can use all of the newest Administration
Process features.

The Administration Process uses administration servers to manage administrative changes that apply to
databases.

Verifying that the Administration Process is set up correctly

After you set up the administration server and the Administration Process, verify that both are running
correctly.
1. From the Domino Administrator, click Server - Analyses - Administration Requests(7).
2. Open the ″All Requests by Action″ view.
3. Verify that the request ″Put server’s Notes build number into Server record″ appears in the view.
4. Sixty minutes after the Administration Process begins running, open the Administration Requests
database again and open the response Log document for the request.
Note: Log documents are listed directly beneath the request that the document pertains to. The
heading Administration Request - Log appears at the top of each Log document.
5. Review the information in the response Log document to ensure that the request has run.
6. Complete the procedure, ″Setting up ACLs for the Administration Process.″

When a server locates and then attempts to process a name-management or

group-management administration request, the server checks for the replica ID. If there is no replica ID
stored in the Administration Request document, the administration server for NAMES.NSF processes the
request.
If a replica ID is located, the server attempts to open the database. If it is successful, the server checks the
ACL to determine whether it is the administration server for that directory. If so, the server processes the
request. If it is not the administration server for that directory, the server leaves the request to be
processed by the appropriate administration server. If the server is unable to open the database, it ignores
the request.

Processing administration requests across domains

You set up Cross-domain Configuration documents to enable a server in one domain to mail
administration requests to a server in another domain. Set up the Cross-domain Configuration document
after you specify an administration server for the Domino Directory in each domain. The Administration
Process for the Domino Directory must be set up on a server in each domain. Cross-domain processing
works only when the administration server of the Domino Directory is a Lotus Domino Release 5 or more
recent server.
These tasks can be processed across domains:
v Delete person in Domino Directory
v Delete server in Domino Directory
v Rename server in Domino Directory -- that is, upgrade the server name from flat to hierarchical
v Rename person in Domino Directory
v Create replica
v Get replica information for deletion -- This request is generated when you delete a database and its
replicas

v Create the necessary cross-certificate documents in the Domino Directory. Requests going to another
domain require cross certificates between the two domains.
v Create a Connection document in the Domino Directory allowing a server in one domain to connect to
a server in another domain. Each domain must have a Connection document.
v Create one or more Cross-domain Configuration documents in the administration requests database for
each domain from which you will import administration requests and to which you will export
administration requests.
v Set up an administration server for the outbound domain to allow processing of the outbound
requests.

The Administration Requests database contains Cross-domain Configuration documents that specify how
domains exchange and process administration requests. When you configure a Cross-domain
Configuration document, you designate the trusted entities, which are persons, servers, or certifiers.

Benefits of cross-domain processing

Cross-domain processing offers these benefits:
1. Processing administration requests across domains can protect the integrity of the data in databases.
For example, if a person is deleted from the directory in one domain, corresponding deletions occur
in the other domains.
2. Access to information is enhanced because a name change is propagated to other domains. For
example, people and servers registered in one domain can also be listed in the directory documents
and database ACLs in another domain. Cross-domain processing allows users and servers to have
access to databases and servers in both domains.
3. Applications are easily distributed because databases are easily replicated from servers in one domain
to servers in other domains. Administrators do not have to install and update applications
individually on all servers.
The Web Administrator uses the Web Administrator database (WEBADMIN.NSF). The first time the
HTTP task starts on a Web server, Domino automatically creates this database in the Domino data
directory. Domino automatically sets up default database security when the Web Administrator database
(WEBADMIN.NSF) is created for the first time.

The Server Controller and the Domino Console

The Server Controller is a Java® based program that controls a Domino server. Starting the Server
Controller starts the Domino server it controls. When a server runs under a Server Controller, you can
send operating system commands (shell commands), Controller commands, and Domino server
commands to the Server Controller.
You can use the Domino Console, a Java-based console, to communicate with a Server Controller. You can
run the Domino Console on any platform except Apple Macintosh. Using the Domino Console, you can
send commands to multiple servers. The Domino Console doesn’t require a Notes ID, only a Domino
Internet name and password

The Domino Console functions strictly as a server console. Consequently, the Domino Console doesn’t
include the full set of Domino administration features that are available through the Domino Administrator and the Web
Administrator, and you can’t use it to open and manage Notes databases.

The files needed to run the Server Controller and to run the Domino Console are provided with Domino
and Notes.

Start the Server Controller using the same command you normally use to start the Domino server but
append the argument -jc. For example, if you run a server on Windows XP from the directory
c:\lotus\domino using a shortcut icon on the Desktop, use the following target for the shortcut:
c:\lotus\domin\nserver.exe –jc

You can minimize a Server Controller window, but do not close or kill the window to stop the Server Controller. Instead, use
the Controller Quit command from a console to stop a Server Controller and the server it controls.

You can run the Domino Console from any machine on which a Domino server or the Domino
Administrator is installed. To use the Domino Console to communicate with a Domino server, the server
must be running under a Server Controller.
Run the following command directly from the program directory, or from a directory path that points
to the program directory:
jconsole
Setting up Domino Active Directory synchronization
When the Domino server is installed on a Windows 2000 server, as an administrator, you typically need
to maintain two separate directories for the same set of people and groups. Maintaining user and group
information involves adding entries to both directories, deleting entries, ensuring that passwords are the
same when users use Notes Single Logon, coordinating group membership in both directories, and
ensuring that user or group settings, such as e-mail addresses and telephone numbers, are identical.

Lotus Domino includes a set of tools to make synchronization between Domino and Active Directory(R) simple and
easy. The Active Directory Domino Upgrade Service (AD DUS) is a tool that you can use with Active Directory
synchronization (ADSync) when you have data in your Active Directory and you have just installed Domino. AD DUS
can optionally be used to migrate all or a set of your Active Directory users. After you’ve done that, you can start using
ADSync to maintain those users in Active Directory and in Domino.

User options are available to register Notes users in Active Directory. In the Domino Administrator’s user registration
interface, there is a ″Windows User Options″ button on the Other panel of the Register Person - New Entry dialog box.
You can select options to register a user in Active Directory at the same time that the user is registered in Domino. This
is essentially the opposite of what ADSync does. Regardless of the tool with which you register a new user in both directories,
you can use ADSync to
synchronize and delete users from both directories. You can also use ADSync to rename users in both
directories.

You must have a properly certified Notes ID and appropriate access to make any changes to a Domino
Directory from Notes or Windows 2000, and have the appropriate rights if you are going to use the
Domino server-defined certification authority (CA) to certify users on Domino. Use a Lotus Notes 6 or
more recent client, and Lotus Domino 6 or more recent server as your registration server.

These directory synchronization features let you keep both the Domino Directory and Active Directory
current without having to update both when either changes. Also, you can manage user and group
information in the Domino Directory and the Active Directory through a single interface of your choice,
either Domino or Windows 2000.

To set up Domino Active Directory synchronization:

* Installed AD & Domino server R6.5 or later i.e. Install, but do not run, the Domino Administrator.
* Open a command prompt. From your Notes install directory, type:
regsvr32 nadsync.dll
A message box appears indicating that registration is complete. This can take up to one minute.
* Run the Domino Administrator and complete the configuration process.
* From the Domino Administrator, create an organizational policy or an explicit policy and a
Registration policy settings document. You must have at least one policy to use with ADSync.
For more information on policies, see the chapter ″Using Policies.″
* From the Start menu, click Programs - Administrative Tools - Active Directory Users and Computers.
Click the Lotus Domino Options folder.
* Right-click Domino Directory synchronization and then choose Options.
* Enter your Notes password.
* Click the Notes Settings tab.
* Click the Notes Server for Registration button and specify a registration server. This is typically the
administration server of the Domino Directory.
* Click OK.
* Close and restart Active Directory Users and Computers to allow these changes to take effect.

During synchronization, ADSync attempts to match the Active Directory object with an entry in the
Domino Directory. If more than one match is found, ADSync prompts you to specify the match from
those that have been located.

Disabling Active Directory synchronization prior to uninstalling the

Domino Administrator
If you have set up and registered Active Directory synchronization, prior to uninstalling the Domino
Administrator, you must unregister Active Directory synchronization.
1. Close the Administrator Client and the Active Directory MMC.
2. From the system prompt, unregister the nadsync.dll library by entering one of these commands:
regsvr32 /u <notes program path>nadsync.dll
OR by entering
cd <notes program path>
regsvr32 /u nadsync.dll
3. Uninstall the Administrator Client.
4. Delete any remaining Notes folders on the file system.
5. Launch regedit and search for all adsync entries. Delete any adsync entries that are found.

Each Domino domain has at least one administration server for the Domino Directory. The administration
server is responsible for carrying out Administration Process requests that automate changes to the
Domino Directory. By default, the first server set up in a domain is the administration server for the
Domino Directory.

Lightweight Directory Access Protocol (LDAP) is a standard Internet protocol for searching and managing
entries in a directory.

The Domino Directory: is a database that Domino creates automatically on every server. The Domino
Directory is a directory of information about users, servers, and groups, as well as custom entries you
may add. Registering users and servers in a domain automatically creates corresponding Person
documents and Server documents in the Domino Directory for the domain.

The Domino Directory is also a tool that administrators use to manage the Domino system. For example,
administrators create documents in the Domino Directory to connect servers for replication or mail
routing, to schedule server tasks, and so on.

When a server runs the LDAP service, the Domino Directory is accessible through the Lightweight
Directory Access Protocol (LDAP).

Typically, a Domino Directory is associated with a Domino domain. When you set up the first server in a
Domino domain, Domino automatically creates the Domino Directory database and gives it the file name
NAMES.NSF. When you add a new server to the domain, Domino automatically creates a replica of the
Domino Directory on the new server.

By default the LDAP task listens for LDAP client requests over TCP/IP port 389, and accepts both
anonymous connections, and connections that bind using name-and-password security. The LDAP service
can also listen for requests over an SSL port, usually port 636.

A directory catalog is an optional directory database that typically contains information aggregated from
multiple Domino Directories. Clients and servers can use a directory catalog to look up mail addresses
and other information about the people, groups, mail-in databases, and resources throughout an
organization, regardless of the number of Domino domains and Domino Directories the organization
uses. A directory catalog includes the type of information that is important for directory services, and
excludes other types of information that are part of a Domino Directory, for example Domino
configuration information, such as information in Connection documents.

There are two types of directory catalogs: condensed Directory Catalogs and Extended Directory
Catalogs.

The access set for a user in an extended ACL can never exceed the access the database ACL, including
the database ACL privileges and roles, allows the user.

Extended ACL : The access set for a user in an extended ACL can never exceed the access the database ACL, including
the database ACL privileges and roles, allows the user. For example, if the database ACL allows a user only Reader access,
you can’t use the extended ACL to allow Write access. Or if a user is omitted from
the database ACL User Creator role, you can’t use the extended ACL to allow the user Create access to
Person documents.

The Lotus Notes client and the Domino mail router (the Router) create and send messages in the format
(MIME or Notes rich text) appropriate for each recipient, as determined from the address format and
settings in the recipient’s Person document. If conversion between formats is necessary, Domino performs
the conversion automatically.
The Router uses information in the Domino Directory to determine where to send messages and what
transfer protocol to use. For messages sent over SMTP, the Router also uses information from the Domain
Name System (DNS).

The Lotus Domino server and Lotus Notes client support both Internet standards and Notes protocols for
message routing, retrieval, and formatting. On the server, the Domino mail router (the Router) can send
and receive messages using the Simple Mail Transfer Protocol (SMTP) and Notes Remote Procedure Calls
(NRPC), or Notes routing. To enable users to retrieve mail, the server supports the Internet access
protocols, IMAP and POP3, as well as NRPC. In addition. the Domino HTTP service interacts with
Domino mail databases to provide mail service for HTTP clients, such as the Domino Web Access client.
Domino sends and stores messages in both MIME format and Notes rich text format, and the Notes client
creates and sends messages in either format.
Mail clients retrieve messages from the server using NRPC, IMAP and POP3. In addition, Web clients,
such as the Domino Web Access client, access mail through the Domino HTTP service. The Notes client
sends and retrieves mail using NRPC, or Internet protocols (SMTP, IMAP and POP3).

Mail access protocols

Domino supports Internet mail access protocols such as IMAP and POP3 and also offers mail access to
Notes clients. IMAP and POP3 clients connect to their respective protocol services to retrieve and send
mail by way of an SMTP server. The Notes client can use Notes protocols to connect to a Domino mail
server to read and send mail, and can also use IMAP or POP3 to access mail on a Domino server or on
non-Domino mail servers -- for example, a UNIX send mail server.

These steps describe how mail routes in a Domino mail system.

1. Using a mail client, a user creates and addresses a mail message to a recipient.
2. The user sends the message.
3. The user’s mail client does one of the following:
v Uses Notes protocols to deposit the message into the MAIL.BOX database on the user’s Domino
mail server.
v Uses SMTP to send the message to the user’s Domino mail server, which must be running the
SMTP listener task. The SMTP listener task deposits the message into MAIL.BOX (Lotus Notes,
IMAP clients, POP3 clients).
v Uses HTTP to send the message to the user’s Domino mail server, which must be running the
HTTP task. The HTTP task deposits the message into MAIL.BOX (Web clients).
4. The Router finds the message in MAIL.BOX and determines where to send the message for each
recipient. The Router checks its routing table to calculate the next ″hop″ for the message on the path
to its recipients and determines the appropriate protocol -- either SMTP or Notes routing -- to transfer
the message.
v Using SMTP routing, the Router connects to the destination server -- the recipient’s mail server, a
relay host, a smart host, or one of the servers in the recipient’s Internet domain -- and transfers the
message.
v Using Notes routing, the Router moves the message to the MAIL.BOX database on the server that
is the next hop in the path to the recipient’s mail server. The Router on that server transfers the
message to the next hop, until the message is deposited in the MAIL.BOX database on the
recipient’s home server.
5. The Router on the recipient’s server finds the message (in MAIL.BOX on a Domino server) and
delivers it to the recipient’s mail file.
6. Using a mail client, the user retrieves the message from the mail file. Depending on the type of mail
client, one of the following protocols is used: Notes remote procedure calls, IMAP, POP3, or HTTP.

Mail routing protocols

When a new message arrives in MAIL.BOX, the Router determines where and how to send the message.
By default, the Router uses Notes routing to transfer mail from one server to another. If the server has
both SMTP and Notes routing enabled for the local Internet domains, the Router chooses the optimal
protocol to use to move the message to its destination. The protocol selection is based on the current
message format, the Domino version of the server that holds the recipient’s mail file, and the format
preference specified in the recipient’s Person document. For example, the Router uses SMTP to route the
MIME copy of a message to a POP3 recipient’s server, and uses Notes protocols to route the Notes rich
text format copy of a message to a Notes recipient’s server.
You can also configure Domino to use SMTP to route mail. SMTP routing can be used instead of, or in
addition to, Notes routing. You can configure a Domino server to use SMTP when transferring mail to
destinations within the local Domino domain only, to external Internet domains, or both.

Messages sent over SMTP are always sent in MIME format.

Notes clients access the Domino Directory using either Notes protocols or Lightweight Directory Access
Protocol (LDAP).

If the recipient’s home server is the current server, the Router will deliver the message. If it
is a different server, the Router consults the routing table to determine the best route, or least-cost path,
for transferring the message to the destination home server and routes the message along that path.

By default, Domino uses Notes Remote Procedure Calls (NRPC) -- also called Notes routing or the Notes
routing protocol -- to transfer mail between servers. Notes routing uses information in the Domino
Directory to determine where to send mail addressed to a given user. Notes routing moves mail from the
sender’s mail server to the recipient’s mail server. The Router for the sender’s server determines the next
server to move the message to -- or in other words, the next ″hop″ on the path to the message’s
destination. Each server uses its routing table to calculate the next hop along the route to the destination
server.

How Notes routing moves a message

When a user sends mail to a recipient with a Notes address -- for example, Jane Doe/Acme -- the Router
picks up a message in MAIL.BOX to determine where to direct the message. The Router first looks in the
Domino Directory for a Person document for the recipient, Jane Doe/Acme. The Person document
contains the name of Jane Doe’s mail server. From this information the Router uses its knowledge of the
network (that is, the routing table) to determine the next stop for the message. How the Router
dispatches the message depends on whether the recipient’s mail file is located:

v On the same server

v On a different server in the same Notes named network: If the sender and recipient don’t share a mail server, the Router
checks the Domino Directory to determine whether the servers are in the same Domino domain.
If the Server document for the destination server is found within the Domino Directory, the Router
checks that document to determine the network information for the server. On the Ports - Notes Network
Ports tab of the Server document, the server is assigned to one or more Notes named networks (NNNs).
A Notes named network is a group of servers in a given Domino domain that share a common protocol
and are connected by a LAN or modem connections.

v On a server in a different Notes named network within the local Domino domain: If the sender’s and recipient’s mail servers
are in the same Domino domain, but don’t share either a mail server or a Notes named network, for transfer to succeed there
must be some connection between the two networks. Connections between Notes named networks can be achieved by two
means:
v Using a ’bridge″ server that is a member of multiple Notes named networks: Two networks in the same domain can
communicate with each other in the absence of a Connection document if any one server is a member of both networks.
Servers that reside in multiple networks can act as a bridge between networks running diverse protocols. For example, if you
have one Notes named network running TCP/IP and another running SPX, you can set up a server that runs both protocols to
be a member of both Notes named networks. This server acts as a bridge between the networks.
When a user in the TCP/IP network sends a message to someone in the SPX network, the Router
transfers the message from MAIL.BOX on the sender’s server to MAIL.BOX on this ″bridge″ server.

v Using a Connection document: A Connection document specifies the sending and

receiving servers, when and how to connect, and what tasks -- such as, replication and mail routing -- to
perform during the connection. The source, or sending, server, and the receiving, or destination, server
named in a Connection document may reside within the same Domino domain, or in different Domino
domains.

v On a server in an external Domino domain

You can create a Connection document between two domains whenever there is a direct physical connection between them.

Overview of routing mail using SMTP

By default, Domino uses the Notes routing protocol to transfer mail between servers. You can configure
Domino to use SMTP to route mail instead of or in addition to using Notes routing.
Message transfer over SMTP routing is performed as a point-to-point exchange between two servers. The
sending SMTP server contacts the receiving SMTP server directly and establishes a two-way transmission
channel with it. To send a message over SMTP:

1. The sending server checks the recipient’s address, which is in the format localpart@domain, and looks
up the domain in the Domain Name System (DNS).
2. DNS returns the Mail Exchanger (MX) record for the domain, indicating the IP address of the servers
in the domain that accept mail over SMTP.
3. The sending server connects to the destination server over TCP/IP, establishes an SMTP connection
on port 25, transfers the message, and closes the connection.

The Domain Name System (DNS) and SMTP mail routing

The Domain Name System (DNS) is a directory used by SMTP to convert a name, such as acme.com, to a
list of servers that can receive connections for that name and to find the IP address of a specific server. By
looking up a destination server’s address in the DNS, the sending server can properly route a message to
a recipient. DNS uses two kinds of records: Mail Exchanger (MX) records and A records. An MX record
maps a domain name to the names of one or more mail hosts. An A record maps a host name to the IP
address of a server.

Mail servers also use other DNS records. For example, servers that receive Internet mail perform a
reverse lookup to a DNS PTR record to determine the host name for a given IP address. Reverse lookups
are useful in verifying the source of a message

To provide users with the ability to work offline and use Sametime, you can integrate Domino Web
Access with Domino Off-Line Services (DOLS) and IBM Lotus Sametime (instant messaging). DOLS
enables users to work offline, disconnected from the network, and provides many replication features that
Notes users expect when working in the Notes client.

An ID file contains:
v The owner’s name. A user ID file may also contain one alternate name. A certifier ID may contain
multiple alternate names.
v A permanent license number. This number indicates that the owner is legal and specifies whether the
owner has a North American or International license to run Domino or Notes.
v At least one Notes certificate from a certifier ID. A Notes certificate is a digital signature added to a
user ID or server ID. This signature, which is generated from the private key of a certifier ID, verifies
that the name of the owner of the ID is correctly associated with a specific public key.
v A private key. Notes uses the private key to sign messages sent by the owner of the private key, to
decrypt messages sent to its owner, and, if the ID belongs to a certifier, to sign certificates.
v (Optional Notes client only) Internet certificates. An Internet certificate is used to secure SSL
connections and encrypt and sign S/MIME mail messages. An Internet certificate is issued by a
Certification Authority (CA) and verifies the identity of the user. The user’s private key associated with
an Internet certificate is stored with that certificate.
v (Optional) One or more secret encryption keys, created and distributed by users to allow other users to
encrypt and decrypt fields in a document.

Certificates
A certificate is a unique digital signature that identifies a user or server. Server and user IDs contain one
or more Notes certificates. In addition, user IDs may contain one or more Internet certificates that identify
users when they use SSL to connect to an Internet server or send a signed S/MIME mail message.
A certificate contains:
v The name of the certifier that issued the certificate.
v The name of the user or server to whom the certificate was issued.
v A public key that is stored in both the Domino Directory and the ID file. Notes uses the public key to
encrypt messages that are sent to the owner of the public key and to validate the ID owner’s signature.
v A digital signature.
v The expiration date of the certificate.

The execution control list

You use an execution control list (ECL) to set up workstation data security. An ECL protects user
workstations against active content from unknown or suspect sources, and can be configured to limit the
action of any active content that does run on workstations. The ECL determines whether the signer of the
code is allowed to run the code on a given workstation, and defines the access that the code has to
various workstation functions. For example, an ECL can prevent another person’s code from running on a
computer and damaging or erasing data.
″Active content″ includes anything that can be run on a user workstation, including formulas; scripts;
agents; design elements in databases and templates; documents with stored forms, actions, buttons, hot
spots; as well as malicious code (such as viruses and so-called ″Trojan horses″).

There are two kinds of ECLs: the Administration ECL, which resides in the Domino Directory
(NAMES.NSF), and the workstation ECL, which is stored in the user’s Personal Address Book
(NAMES.NSF). The Administration ECL is the template for all workstation ECLs. The workstation ECL is
created when the Notes client is first installed. The Setup program copies the administration ECL from
the Domino Directory to the Notes client to create the workstation ECL.

Hunt Group: A pool of modems which are connected to different phone lines but use a single phone no such that each call that
comes into that no is assigned to next free line in the group.
DNN/NNN: A group of domino servers which shares same protocol and same domino directory with constant connectivity.
IMP Files at clients: notes.ini (Configuration settings), user ID file (User name, password, certificates, Public/Private key,
Internet License), names.nsf (Connection settings, Address book), desktop6.ndk (Workspace/Welcome page settings),
bookmark.nsf (Bookmark icon settings).
IMP IDs at server: server.ID, admin.ID, cert.ID, dolcert.ID
ODS: On Disk Structure (The file system used in Lotus Notes)
R4:
R5: 41
R6: 43

Access level privileges in the ACL

Public and private keys
For all types of encryption, Domino uses public and private keys so that data encrypted by one of the
keys can be decrypted only by the other. The public and private keys are mathematically related and
uniquely identify the user. Both are stored in the ID file. Within the ID file, the public key is stored in a
certificate, but the private key is stored separately from the certificate. The certificate containing the
public key is also stored in the Domino Directory, where it is available to other users.

Domino uses two types of public and private keys -- Notes and Internet. You use the Notes public key to
encrypt fields, documents, databases, and messages sent to other Notes users, while the Notes private
key is used for decryption. Similarly, you use the Internet public key for S/MIME encryption and the
Internet private key for S/MIME decryption.

When you register a user, Domino automatically creates a Notes certificate, which contains the user’s
public keys, and adds it to the ID file and the Domino Directory. The private key is created and stored in
the ID file.

Electronic signatures
Electronic signatures are closely associated with encryption. An electronic signature verifies that the
person who originated the data is the author and that no one has tampered with the data. Users can add
an electronic signature to mail messages and to fields and sections of documents.

How electronic signatures work

Notes signatures
When the sender signs a message with a Notes signature, all fields of the message are signed.
1. Notes generates a ″hash″ of the data -- that is, a number that represents the data -- and then encrypts
the hash with the private key of the author of the data, forming a signature. The hash is also
sometimes called a message digest, and has some necessary special properties:
v It is not possible to guess the original message from looking at the digest.
v Even a small change in the message changes the digest in an unpredictable way, and produces a
completely different value.
2. Notes attaches the signature, the signer’s public key, and the signer’s certificates to the data.
3. When the reader accesses the signed data, Notes verifies that the signer has a common certificate or
common certificate ancestor from a certifier that the reader trusts. If so, Notes attempts to decrypt the
signature using the public key that corresponds to the private key with which the data was signed.
4. If decryption is successful, Notes indicates who signed the message. If decryption is unsuccessful,
Notes indicates that it cannot verify the signature. Unsuccessful decryption and comparison may
indicate that the data has been tampered with.
Domino server-based certification authority
You can set up a Domino certifier that uses a server task, the CA process, to manage and process
certificate requests.

Transaction logging
Domino supports transaction logging for servers that run Domino 5 and later, and for databases that are
in a Domino 5 or later on-disk structure.
Transaction logging captures all the changes made to a database and writes them to a transaction log. The
logged transactions are then written to disk in a batch, either when resources are available or when
scheduled.

The default Domino Directory template (PUBNAMES.NTF) controls the appearance and functionality of
the Domino Directory database (NAMES.NSF).

Calconn: Calendar Connector is a server task which processes requests for free-time information from another server.
Sched: Schedule Manager is a server task which check for Returns meeting times and dates and available invitees.
Amgr: Agent Manager is a server task which runs agent on one or more servers.
The calendar and scheduling features use the Schedule Manager (Sched task), the Calendar Connector (Calconn task), and the
Free Time system (a combination of Sched, Calconn, and nnotes tasks) to operate. When you install Lotus Domino 6 on a
server (any server except a directory server), the Sched and Calconn tasks are automatically added to the server’s NOTES.INI
file. When you start the server for the first time, the Schedule Manager creates a Free Time database (BUSYTIME.NSF for
non-clustered mail servers and CLUBUSY.NSF for clustered mail servers) and creates an entry in the database for each user
who has filled out a Calendar Profile and whose mail file is on that server or on one of the clustered servers.
Policy: is a document which defines a set of default that applies to the users and groups.
Types: 1. Organizational Policy 2. Explicit Policy.
Settings Documents: 1.
Policy Viewer and Policy Synopsis are the tool to check the effective policy governing.
Certifier ID: A file that generates an electronic stamp which indicates the trust relationship.
Encryption: Public Key used for sending and encrypting & Private key used for receiving and decrypting.
Public Key: A key which is used for encryption of messages while they are in transit. It is store in notes ceritificate which are
furthure store in User ID and Domino directory.
Private Key: A key used for decryption. It is stored in User ID.

Domino Cluster: A Domino cluster is a group of two or more servers which provides users
the constant access to data, balances the workload between servers, improves server performance, and maintains performance
when you increase the size of your enterprise.

The servers in a cluster contain replicas of databases which are readily available to users at all times. If a user tries to access a
database on a cluster server that is not available, Domino opens a replica of that database on a different cluster server, if a
replica is available. Domino continuously synchronizes databases so that whichever replica a user opens, the information is
always the same.
Cluster Benefits: 1. Availability of Database: When a hardware or software problem occurs, clustered servers redirect
database open requests to other servers in the cluster to provide users with uninterrupted access to important databases. This
process is called failover.

2. Workload balancing: When users try to access databases on heavily used servers, Domino
can redirect the user requests to other cluster servers that aren’t as busy so that the workload is evenly distributed across the
cluster which leads to faster data access.

3. Scalability: As the number of users you support increases, you can easily add servers to a cluster to keep server performance
high. As your enterprise grows, you can distribute user accounts across clusters and balance the additional workload to
optimize system performance within a cluster.

4. Data synchronization: Cluster replication ensures that all changes, whether to databases or to the cluster membership itself,
are immediately passed to other databases or servers in the cluster. Thus, databases are continuously synchronized to provide
high availability of information.

5. Ease of changing operating systems, hardware, or versions of Domino: When you want to change your hardware, operating
system, or Domino release, you can mark the clustered server as RESTRICTED so that requests to access a database on the
server fail over to other cluster servers that contain replicas.

Clustering requirements:
All servers in a cluster must be connected using a high-speed local area network (LAN) or a high-speed wide area network
(WAN). You can also set up a private LAN for cluster traffic.
All servers in a cluster must use TCP/IP and be on the same Notes named network
All servers in a cluster must be in the same Domino domain and share a common Domino Directory.
Each server in the cluster must have a hierarchical server ID. If any servers have flat IDs, you must convert them to
hierarchical IDs to use them in a cluster.
A server can be a member of only one cluster at a time.
Each server must have adequate disk space to function as a cluster member. Because clusters usually require more database
replicas, servers in clusters require more disk space than unclustered servers.
Each server must have adequate processing power and memory capacity. In general, clustered servers require more computer
power than unclustered servers.