1

HCL Domino 12.0.X System Admin Fundamentals

A. Examining the HCL Domino Architecture

1. Client and Server Architectural Components

The architecture representation on how Domino Server and HCL Notes client are connected in a
network Infrastructure. See figure A-1.

Figure A-1: Server & Client Architecture

2. Domino Organizational Architecture

The architecture representation on how HCL Notes users are interrelated in a Domino infrastructure.
a. Domino Domain
A Domino domain is a group of Domino servers that share the same Domino Directory.
As the control and administration center for Domino servers in a domain, the Domino
Directory contains, among other documents, a Server document for each server and a Person
document for each Notes user.
b. Organization (O)
It is a hierarchical naming scheme that defines the name of every
Domino Server and Notes User.
 2

c. Organization Unit (Ou)

This part of the name identifies where in the organizational hierarchy a server and
users fits. Allowed up to 4 levels only.
d. Country (C)
This part of the name identifies in which country an entity exists. Optional
only.
e. Notes Named Network
A Notes named network is a group of Notes servers that share a common protocol and
have the same Notes network name in their Server documents in the Public Address
Book. The servers in a Notes named network may or may not be in the same physical
location.
f. Domino Server and Users
Entities in the Organization.

Figure A-2: Domino Domain Architecture

e. g.
Finance User1/Finance/Accounting/Honda – User name
Finance_Server1/Finance/Accounting/Honda – Server Name

3. What is a Domino Server?

An HCL server product that provides enterprise-grade e-mail, collaboration
capabilities, and a custom application platform. Domino began life as HCL Notes
Server, the server component of HCL client-server messaging technology. It can be
used as an application server for HCL Notes applications and/or as a web
Server. It also has a built-in database system in the format of NSF. Its directory
services can be used for authentication purposes as well. Domino can be hosted in
multiple OS platforms such as Windows, Linux, OS/400 and DOCKER Containers.

4. What is HCL Notes Client?

An easy-to-use, desktop client for social business that delivers the people and business
applications that help you get work done fast.

a. Provides an easy-to-use, single point of access to everything you need to get your
 3
work done quickly, including business applications, email, calendars, feeds, and
more.
b. Let’s you tailor your work environment with widgets that bring social communities
that are important to your job, both within the enterprise and across the Internet,
right into your peripheral view.
c. Enables you to work with people right at the point of context with social tools
weaved into the work experience, allowing you to pivot to the tool you need, such as
business cards, presence awareness, instant messaging, and more.
d. Offers advanced replication technology to enable you to work with
Email and applications even when disconnected from the network.

5. HCL Domino Designer

A highly productive application development environment that benefits cost conscious
IT departments by enabling the rapid development and deployment of scalable and
security-rich collaborative or workflow-driven business applications. Developers can
integrate assets from across IT systems and provide application access through many
different types of clients and devices.

6. HCL Domino Administrator

The HCL® Domino® Administrator is the administration client for HCL® Notes®
and Domino. You can use the Domino Administrator to perform most administration
tasks. You can administer the Domino system using the local Domino Administrator or
using the HCL Domino Web Administrator.

Figure A-3: HCL Domino Administrator Install Wizard Custom Setup Dialog

Using the HCL Notes full client installer make sure to select “HCL Domino Administrator” in
the Custom Setup dialog during setup to install Domino Administrator.

7. Server Document
The document that contains the default configuration of the Domino Server regarding
security, running tasks, network configuration and etc. . It is being created
automatically during the setup and configuration of the first domino server and also
 4
during registration of additional domino servers. See sample server document in figure
A-5.

Figure A-5: Sample Server Document

8. HCL Domino Server Types

-HCL Domino Messaging Server (messaging only)
Combines full support for the latest Internet mail standards with HCL Domino's
industry-leading messaging, calendar and scheduling, discussion database and reference
database capabilities - all in one manageable and reliable package. Lotus Domino
Messaging Server also includes support for HCL Domino partitioning (running more
than one instance of HCL Domino on the same machine using one copy of the HCL
Domino code).
Total Software license was determined by the total no. of Client Access Licenses for
each user registered in the Domino Directory.

-HCLDomino Utility Server (applications only)

HCL Domino Utility Server licenses support unrestricted access to non-mail
applications by Web browser users, whether or not the application requires
authentication. Access from a HCL Notes client is allowed.

- HCL Domino Enterprise Server (both messaging and applications)

Provides all the functions of the HCL Domino Messaging Server, plus support for
custom intranet and Internet applications. The applications may be developed in house
using HCL Domino Designer or acquired from an Independent Software Vendor. HCL
Domino Enterprise Server includes support for HCL Domino clustering, which allows
data to be replicated in real time across a cluster of servers. This capability lets you
balance server loads and take advantage of automatic failover when a server is
unavailable.
 5
Total software license was determined by the total no. of Client Access Licenses
registered in the Domino Directory.

9. External Add-in Software

Domino Server can also host different add-in products to extend its e-mail and application
capabilities.

a. HCL Traveler
A push email technology that provides access to email, calendar, and contacts - from
your favourite mobile device. Keep your users connected and productive with full-
featured e-mail for Smartphones and tablets, while adhering to your important
corporate policies and safeguarding sensitive corporate data.

b. HCL Sametime
Software that delivers unified, real-time communication and collaboration services—
from enterprise instant messaging and online meetings to telephony and video
conferencing. So you can improve and accelerate how work gets done in a social
business. And reduce travel and telephony expenses.

c. HCL Nomad on Domino

Access mail and applications using internet browser without re-development of code
just like access all database using the HCL Notes Client.

B. Perform Basic Domino Admin Tasks

1. User Maintenance

a. Register a User

Step 1. Under the Domino Administrator client, People & Groups Tab, expand Tools
section then People sub section select Register option. See image below.
 6
Step 2. The Choose a Certifier dialog will appear. Just select the Domino server the user
will be registered and locate also the certifier ID to be use for registering the user in the
Organization.Click “OK” button to continue. See image below.

Step 3. Enter the the Notes Certifier password as indicated below then press “OK” button.

Step 4. Enter User information as show below then click “Password Options” button
 7
Step 5. Under the password options dialog, you can increase the Password Quality Scale
and then don’t forget to select the “Set internet password” check box to allow Notes client
and internet password to the same. Click the “OK” button to continue. See image below

Step 6. Click in “Mail” tab. Just accept the defaults if no adjustments is required. See
image below.
 8
Step 7. Click in “Address” tab, Enter internet addres and internet domain
As shown below.

Step 8. Under the “ID Info” tab make sure to set the “Certificate expiration date” (the
expiration where the user will neeed to be certified to allow access again), “License type”
to “International” and check the “In file” checkbox option (to backup user id file in the file
system). See image below.
 9
Step 9. After entering all the required information, click the “Check” button to enter the
user being registered in the registration que. Click on “RegisterAll” or “Register” to
complete the registration process. See image below.

Step 10. Under the dialog window, click on the “OK” button to complete the registration
process.

Step 11. As you can see in the image below, under the People view, the new user has been
registered
 10
b. Rename a User

Step 1. Under the “People and Group” tab > “People” section on the left pane, select the
user to be renamed then . expand the “Tools” section > “People” subsection in the right
pane then click “Rename” option. See image below.

Step 2. Under the “Rename selected Notes People” dialog, click “Change Common
Name” button and also set the no. of days the previous name will be honored on the
system.

Step 3. Under the “Choose a Certifier” dialog, delect the certifier id to initiate the rename
process then click “OK” button.

Step 4. Enter password for the certifier ID then click the “OK” button.
 11
Step 5. Adjust the user access expiration date if necessary or just click the “OK” button to
continue. See image below.

Step 6. Rename the target user as show below then click the “OK” button to complete the
process.

Step 7. As you can see in the image below the rename process was successful. Click on
“OK” button to continue.

Note: An administration request process task will run every hour to process fully
the rename request or you can send a “tell adminp process all” command on the
domino console to rename the target person in the address book immediately.
 12
c. Delete a User

Step 1. Select the target user in the address book then expand the Tools > People section clicking
the “Delete” option.

Step 2. Accept the default below then click the “OK” button to complete the process.

d. Reset User Password

Step 1. Under the “People” view, select the target user then expand “Tools” > “ID Vaults” section
select the “Reset Password” option.
 13
Step 2. Under the “Reset User’s Password” dialog, you can modify the “How to notify”
field either in person or via e-mail. Set new password as show below then click “Reset
Password” button to continue.

Step 3. Click the “OK” button to complete the process.

Note:
 Both the HCL Notes user password and Internet password will be
changed.
 Wait for atleast two (2) minutes for the new password to take effect then
try authenticating the user.
 ID vault must be configured first before performing this procedure.

2. Group Maintenance

a. Group Creation

Step 1. Under the “Group” view select “Add Group” button. See image below.
 14
Step 2. Enter “Group Name” then click the inverted triangle Icon to add members as
shown below.

Step 3. Select the users to be included in the group then click “Add” button as shown
below.

Step 4. As you can see after clicking the “Add” button, all selected names has been entered
to the “Names” field. Just click the “OK” button to add them to the group.
 15
Step 5. As you can see the selected users has been added to the “Members” field. Click
“Save & Close” button to complete the process. See image below.

Step 6. As you can see the group created has been added to the “Group” view.

b. Deleting Group

Step 1. Under the “Group” view, select the target group to be deleted then under the
“Tools” pane > Groups subsection select “Delete” option.
 16
Step 2. Under the Group dialog select the “Delete groups from this Domino Diretory
immediately” option then press “OK” button to complete the processs.

3. Current Server Configuration

a. Basic Tab – Defines the basic information of the Domino Server. Mostly all fields here is
being accepted as a default except modifying the “Maximum fault limits” field and “Mail
Fault notification to” field to notify the administrator that the server has been shutdown
unexpectedly because of a fault or illegal operation.

b. Security Tab – Controls the following security settings

 Administrator Access
 Agent Execution Permissions
 Server Access
 Tight Security Settings
 Internet Authentication
 17

c. Ports Tab – Controls the connections of all Domino Services from and to the Domino
Server.

d. Server Tasks Tab – Controls the operation of all Server tasks from Administration
Process, Agent Manager and other processes.
 18
e. Internet Protocols Tab – Controls all Internet services related settings to access the
Domino server over the internet.

f. Transaction Logging Tab – Controls how the Domino Server performs auto recovery of
corrupted database server.

4. Server to Server Communication

a. What is Domino Replication?

Replication is at the heart of the distributed nature of Domino and Notes. This unique
feature is often imitated, but never duplicated, and it's helped to put Notes head-and-
shoulders above the groupware crowd.

Replication is easily understood when you compare it to the traditional file copy process,
which is an all-or-nothing operation. For example, imagine you have a discussion database
on Server A that also needs to exist on Server B. To accomplish this task, you copy the
database from Server A to Server B, and you're done. You have a problem, however, once
users start adding documents to either copy of the database -- they're no longer in sync.
You could re-copy the database from Server A to Server B, but that would wipe out all of
the changes made to the database on Server B. So, how do we maintain a single database
in multiple locations in a synchronized fashion? The answer is replication.

b. Components of the Replication Process

Something as powerful as replication might conjure up images of a complex series of
server tasks working hard to maintain database synchronization. Surprisingly enough,
 19
replication occurs with just one server task. While you can have multiple instances of this
one server task running, you really only need one. After this one server task, you're left
with the pieces that help control and schedule replication. Here's a quick list:

 The Replicator server task: This task appears on the server console as
REPLICATOR, and does the work of synchronizing a source database with its
replicas. By default, one instance of this task is loaded when the server is
started; however, you can add setting to the NOTES.INI file (REPLICATORS=
n), or use a server console command (LOAD REPLICA) to enable multiple
replicators.
This feature allows a server to replicate its databases with more than one server
at a time. For example, if a server has REPLICATORS=2 set in the
NOTES.INI, then it can replicate its databases with two servers simultaneously.
If, however, you enable two replicators, and the server only needs to replicate
with one other server, then only one replicator is used. The other Replicator
task remains idle.

 Connection documents: These documents are in the Public Address Book, and
allow you to schedule replication between two servers (an exact time or a
range of time). Along with controlling the replication schedule, a Connection
document also controls which databases replicate and the type of replication
they use. The following is a list of the different types of replication:

PULL-PUSH: Server A contacts Server B and PULLS all new and

modified information. Once Server A completes the pulling process,
Server A PUSHES all of its new and modified information to Server B.
The Replicator task on Server A does all of the work.

PULL-PULL: Over Local Area Network (LAN) connections, Server

A contacts Server B and PULLS all new and modified information.
Then, Server B PULLS all new and modified information from Server
A. With this type of replication, both servers "share" the work of
replication. Over modem connections, however, Server A and Server B
PULL simultaneously. This approach helps maximize the usage of the
low bandwidth connection.

PUSH-ONLY: Server A contacts Server B and PUSHES all new and

modified information to Server B. The Replicator task on Server A
does all the work in this one-way operation. With this replication type,
nothing new or modified on Server B is pulled or pushed to Server A.

PULL-ONLY: Server A contacts Server B and PULLS all new and

modified information from Server B. The Replicator task on Server A
does all the work in this one-way operation.
With this replication type, nothing new or modified on Server
A is pulled or pushed to Server B.

See Image Below.

 20

c. Exploring Replication Connection Documents – This allows Administrators to control

the replication communication between Domino Servers.

Step 1. Access “Configuration” tab > Connections > “Connections View” as shown in the
image below. Click the selected connection to view its settings.

Step 2. The image below show the connection between Source Server to Destination
Server. Click on “Replication/Routing” tab to continue.
 21
Step 3. To Start communication between the Source and Target server make sure the
“Replication Task” field is set to “Enabled” and select “Files/Directory paths to replicate”
field to the values of target database to sync with the destination server. See image below.

Step 3. Under the “Schedule” tab set the following fields below to enable and manage the
schedule of synchronization of database between servers. Save the document when all was
set.See image below.

C . Domino Applications Administration

1. The Object Store

Lotus Notes and Domino use the Notes Storage Facility (NSF)
Database to store e-mails, appointments, tasks, contacts, notes, etc.

2. Components of HCL Domino Applications

A major new enhancement in HCL Notes® is the support for composite
applications, a key element within HCL's service oriented architecture (SOA) and
contextual collaboration strategy. Using HCL Domino® Designer, developers can
extend Notes applications to be Notes components in composite applications. A
composite application can include any combination of Notes components or
Eclipse components. The ability to combine multiple technologies into a single
application provides significant business value: It enables companies to protect
and extend their existing assets with increasing degrees of flexibility, and to
 22
respond quickly and cost effectively to their emerging business requirements,
with applications that are significantly easier to assemble than alternative
application development environments.
There are also new capabilities:

- Vertical document preview panes

- Email threading

- Additional daily and weekly calendar groupings

- Contact cards

- Applications
Domino applications enable people to share, collect, track, and organize
information, using Lotus Notes® or the Web. Using HCL Domino Designer,
developers can create applications to meet a variety of business needs, including:

 Workflow applications that route information.

 Tracking applications that monitor processes, projects, performance, or

tasks.
 Collaboration applications that create a forum for discussion and
collaboration.

 Data integration applications that work with relational databases and

transactional systems.

 Dynamic applications that produce content based on, for example, user
name, user profile, access rights, or time of day.

 Localization and Management applications that use Domino Global

WorkBench to translate LHCL Domino databases and Web sites.

Additionally, HCL Domino Designer can create HCL Notes components to be

used in a larger composite application.

- Databases
All Notes applications contain one or more databases. You create a database to use
as the container for the data, logic, and design elements in your application.
Design elements include:

 Framesets
 Pages
 Forms
 Views
 Folders
 Agents
 Web Services
 Outlines
 Shared Resources
 Composite Application Components
 Navigators
 23

3. Database Types
-NSF (Notes Storage Facility) – Represents all active applications or database that
reside in the Domino Server. e.g. names.nsf, admin4.nsf
-NTF (Notes Template File) – Represents an application template which active
database in the domino server inherits its design including program flow. e.g.
mail85.ntf,pubnames.ntf and admin4.ntf
-BOX – Represents the main mailbox database use by the Domino Server to route e-
mail within the Domino Server and to the internet.
e.g. mail.box

4. Required Server Applications

Here are some required applications in the basic operation of the
Domino Server:
-Domino Directory (names.nsf)
Referred also as the public address book in older releases. Contains important
configuration needed in the proper operation of the Domino Server.

-Administration Request DB (admin4.nsf)

Use by the Administration Request task to manage and monitor Administrator
operations with regards to user rename, recertification, replica creation and etc.

-Busytime.nsf
It holds a summary of the entries from individual calendars sufficient to
provide a response to scheduling enquiries about users' availability for
meetings etc. If the database is missing, it can be easily created once you
restart the server.

-Domino Log DB (log.nsf)

It reports all server activity and provides detailed information about databases
and users on the server. The log file is created automatically when you start a
server for the first time.

-Catalog DB (catalog.nsf)
Besides allowing users to see what databases are on a particular server, catalogs
provide useful information about databases. For each database in a view, a
Database Entry document provides information such as file name, replica ID,
design template, database activity, replication, full-text index, and ACL, as well
as buttons that let users browse the database or add it to their bookmarks. In
addition, the document displays a link to the database's Policy (About This
Database) document, which, for Database users are not authorized to access,
they can view by sending an e-mail request to the database manager.

-Events DB (events4.nsf)
Provides you with a set of tools to provide information when problems occur.

5. HCL Domino Directory

The Domino Directory, which some previous releases referred to as the Public Address
Book or Name and Address Book, 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. These
documents contain detailed information about each user and server.
 24
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.

You can also create a Domino Directory manually from the PUBNAMES.NTF template
and use it as a secondary directory to store, for example, entries for your Internet users.

To optimize its performance, the Domino Directory has these database properties enabled
by default:

"Document table bitmap optimization" to improve the performance of small view

updates -- for example, updates of the Connections view.
"Don't maintain unread marks" to improve database
performance and reduce the size of the database.

Figure B-1: Domino Directory

Some Components of the Domino Directory:

-People View - Contains the list of all users registered in the
Domino Server.
-Groups View - Contains the list of all groups created in the
Domino Server.
-Configuration View – Contains the list of settings for connectivity, mail
routing and program execution of the Domino Server.
-Messaging View - Contains the list of settings with respect to routing of E-
mail to other servers and delivery configuration of existing users.
-Replication View – Contains settings for replication schedules to other
servers.
-Directory View – Contains information regarding directory configuration
settings for directory assistance, extended directory catalog and
internet sites document.
 25
-Policies View - Contains setting for Policies being implemented to Lotus
Notes users.
-Web View - Contains additional web configurations settings
in setting up HTTP services.
-Clusters View – Contains a list of Domino Clusters being implemented in the
Notes Domain.
-Security View – Contains a list of security certificates which enable Lotus
Notes Users and other Domino Servers to authenticate with the Domino Server.
Also contains ID Vault Configuration.
-Miscellaneous View – Contains information regarding default legal holidays
and Lotus licenses.

6. HCL Domino Domains

-One Domain, One Organization

The setup of this domain involves creating only one Domino domain and registering all
servers and users in one Domino Directory. This scenario is the most common and the
easiest to manage.

-Multiple Domains, One Organization

The setup of this domain is common when a large company has multiple independent
business units. All servers and users are members of the same organization, and each
business unit administers its own Domino Directory.

-One Domain, Multiple Organizations

The setup of this domain is common when multiple companies work closely together
yet want to retain individual corporate identities.

-Multiple Domains, Multiple Organizations

This scenario often occurs when one company acquires another.

7. Basic Domino Admin Applications Administration

a. File (NSF) Access Control Management
Manage Security access in a particular Database.

Step 1. Using the Domino Admin client access the “Files” tab. Selet the target
database.
Allows management of security access within a database (NSF) file.

Step 1. Access the Domino Admin Client then

 26
Step 2. Click on “Add” button to add user and group access to the selected database.

Step 3. Click the Person icon to access list of users.

Step 4. Select the person or group that you want to give access to then click “Add” button.
 27
Step 5. Select the person you added from the list then on the right side set User Type and set
access control. Click the “OK’ button to finish.

b. File (NSF) New Replica Creation

Step 1. In the “Files” Tab select the target database for replication then do a right mouse click,
select “New” option then “Replica
 28
Step 2. If you can’t find the target Domino Server to create a replica of the target database,
select other then click “Add” button.

Step 3. Under the name field type or lookup the target server for the replica of the database to
be created. Click “OK” button to continue.

Step 4. Make sure to check the “Exchange Unread marks on replication” option then
click on “OK” to finish.
 29
c. File (NSF) Other maintenance tasks

Domino Console Important commands

To access the domino console see image below

1. Repair corrupted database file enter “load updall <name of db.nsf> -R” where “name of
db.nsf” represents the database name. Mostly to repair user access problem “load updall
names.nsf –R” resolves it.

2. Show remaining messages in the outbound que – “tell router sh que”

3. Show users accessing the server – “show user”

4. Show running tasks – “show tasks”

5. Execute admin process immediately - “Tell adminp process all”

6. Restart the Domino server – “Restart server”

D. Policies

Policy Implementation
There are two primary considerations when implementing policy documents: what the settings
are and which users the settings apply to. First, you need to determine all the configuration
settings to be applied to the Lotus Notes client. Once you have identified these settings, your
second task is figuring out how to apply the settings to the user community. You need to
determine which users or groups of users should be assigned a particular policy, which
subsequently contains a number of configuration settings known as settings documents.

Policy-based system administration is a way to centrally define, organize, and manage the
policy-related information and settings stored in the Domino Directory. This article looks at
policy hierarchies, tools and examples of using policies.

In previous Domino/Notes releases, creating and managing a standard environment for all your
users usually involved maintaining a set of written corporate policies. (An example of a policy
might be a specific security configuration you want every Notes user to follow, covering things
such as minimum password length and certificate expiration dates.) You would then use these
policies to guide you as you entered settings for users throughout your site. If you were
anything less than 100 percent familiar with every single setting, sooner or later you'd probably
end up making some small, but crucial data entry error, one requiring hours or possibly days to
correct. Perhaps you might identify with the plight of the administrator registering 1,000 users
with the wrong Internet address format, resulting in hours spent editing each Person document
 30
containing the offending information. Those of you who know your way around LotusScript (or
are on friendly terms with someone who does) might be able to create an agent to distribute at
least some of this policy information corporate-wide. But wouldn't it be great if right out of the
box, Domino gave you an automated way of enforcing such standards accurately and easily?

If you think so, you're in luck. Domino 8.5.x helps you solve the problem of applying and
managing standard corporate policies by providing a new
technology called policy-based system administration. This feature gives
you a way to centrally define, organize, and manage user settings throughout your organization.
All information required for policy-based system administration is stored in your Domino
Directory, giving you a single place to control administration activity, from user setup to mail
archiving.

What is policy-based system administration?

In broad functional terms, policy-based system administration is exactly what its name implies-
a way for you as a Domino administrator to
manage and apply corporate policies for your employees. These corporate policies define the
way Domino enforces user settings, which ensures that your established corporate standards
and practices control how your technology works (and not the other way around).

In Domino , you enforce corporate policies through individual Policy documents and Settings
documents in the Domino Directory. To create a
policy, you use a Policy document to specify which Settings documents to include.

A Policy document (see the following screen for an example) defines a set of corporate
information you want to apply to your users. It does this by specifying which Settings
documents to include in the policy. Each Settings document contains detailed information
applicable to a specific area of Domino administration, for example archiving or security. This
information defines user settings for that area. See figure G-1.

Figure G-1: Policy document for Acme Corporation

You can consider policy-based system administration as a way to create and apply rules within
your user community. The Settings documents contain the rules; the Policy document
organizes these rules. So when you create a Policy document, you have a single place to list
these rules. You can then apply the rules to establish and enforce administrative standards by
distributing them throughout your organization. And to change an existing policy, all you need
to do is edit the Policy document
and/or one or more Settings documents. No more running around to each
user's computer, making the same change over and over-you can now do this all centrally.

You can use policy-based system administration to manage five major areas of Domino
administration: archiving, desktop, setup, registration, and security:
 31
Policy area Major features Description
Archiving Server-to-server Archive settings control mail file
archiving archiving. These settings
Server-to-local determine whether or not to
archiving allow archiving, and if you do
Folder-based allow archiving, whether or not to
archiving allow Notes users to set their
own private archiving criteria.
Desktop Welcome page Desktop settings control the
Deployment user's desktop environment.
Bookmarks They are applied to a user's client
management configuration during
Client upgrades authentication whenever a
change to the policy occurs.
Setup Browser Setup settings help configure a
Proxy new Notes client. They are used
Applet security only once, during the initial Notes
Preferences client setup to populate the
user's Location document and
bookmarks.
Registration Mail template Registration settings predefine
Password the User Registration options, if
length/quality your policies are in place before
Internet address you register users.
format
Certificate
expiration
Security Password Security settings establish the
expiration administration ECLs and define
ECL management password management options,
Password length including synchronization of
Internet and Notes passwords.

Creating a Policy document

To create a Policy document, you must have at least Author access to the Domino
Directory, and you must be assigned to the PolicyCreator role. Then, from the Domino
Administrator:

a. Click the People & Groups tab and open the Policies view.
b. Click Add Policy.
c. In the Basics section, enter a name for the policy. If you are creating an explicit
policy, enter a unique name. If you are creating an organizational policy, enter a
name in one of the following formats:
 For Organizations: */<organization>
 For Organizational Units: */<organizational unit>/<organization>
 For hosted organizations: */<hosted organization>
g. For hosted organizations to indicate all hosted organizations in the Domino
Directory: *
h. Choose Explicit or Organizational as the policy type. Choose Explicit to create a
policy that you assign to specific users and groups. Choose Organizational to create
 32
a policy to assign to all users in an Organization or Organizational Unit (OU). (See
the Organizational and explicit policies section for more information.)
i. Optionally, enter a short description of the policy.
j. To create a child Policy document at this time, click Create Child. This creates a
new Policy document that includes the name of the parent policy. You can save this
new child Policy document and return to it at a later time. When you close this
document you return to the parent Policy document.
k. In the Setting Type section, select the Settings documents (registration, setup,
archiving, desktop, and security) you want to apply to this policy. These can be
existing Settings documents you created earlier, or you can create new Settings
documents on-the-fly by clicking New and completing the Settings document form.
l. Save and close the new Policy document.

Creating a Settings document

To create Settings documents, you must have at least Editor access to the Domino Directory
and you must be assigned to the PolicyCreator role. You can create Settings documents
when you create a Policy document, or you can create Settings documents by opening the
Domino Administrator and following these steps:

a. Select the People & Groups tab and open the Settings view.
b. Click Add Settings.
c. Select the type of Settings document you want to create
(registration, setup, archiving, desktop, or security).
d. Complete the fields appropriate to the settings type, and then save and close the
document.

Organizational and explicit policies

You can assign policies to individuals within your company two different ways,
organizationally and explicitly.

Organizational policies apply settings to users or groups based on your organizational

structure. An organizational policy affects all users in a naming hierarchy (*/Acme,
*/Sales/Acme, and so on) and can apply to either an Organization or Organizational Unit
(OU). Organizational policies distribute settings to the broadest group of users, when the
settings follow organizational lines. For example, to apply settings to
all users in Sales/Acme, create an organizational policy named
*/Sales/Acme. Any user registered using the Sales/Acme certifier automatically receives
the settings in this organizational policy. Organizational policies can be considered
wildcards and are usually the most effective method to distribute and maintain settings that
apply to all users in a specific Organization or OU.

Explicit policies assign settings to people and groups across different organizations. An
explicit policy is assigned in the Person document and applies to a group of users when an
Organization or OU does not exist to define the group. Explicit policies are most
appropriate for
 33

environments without an organizational hierarchy or when you need to assign common

settings to a group that spans multiple organizations. For example, suppose your company
includes contractors as
temporary employees working in many different OUs. You want your
contractors to inherit some settings from the applicable organizational policy such as
*/Sales/Acme. But you also want certain settings to apply only to contractors. For
instance, you can set their certificates to expire after six months. To do this, you can
create an explicit policy called /Contractors that applies only to them. (You can assign
explicit policies with the Assign Policy tool.)

When deciding which type of policies to use, consider the following suggestions:

Use organizational policies to apply settings to groups in accordance with your

existing naming hierarchy.
Use explicit policies when groups to whom you want to apply
settings don't match your Organization or OU structure. Above all, feel free to
use both types of policies within your company-indeed, we expect this will be
common practice.

Note: Both explicit and organizational policies can be configured as

exception policies. An exception policy explicitly exempts a specific
individual or group from one or more of your standard policy settings. For
example, your executives may need to bypass certain settings. Exception
policies are powerful because they override all other settings (including
enforced settings) that may apply to the exempted persons. But in practice, you
should be careful not to overuse exception
policies. Too many exemptions might decentralize the administration
of these settings and therefore, could defeat the entire philosophy of policy-
based system administration.

Once created, organizational policies are automatically assigned to users, based on the
certifier. Explicit policies, on the other hand, must be assigned manually. You can assign
explicit policies during user registration, in the Person document, or by using the Assign
Policy
tool. It's best to create organizational policies prior to user
registration; the best time to assign explicit policies is during user
registration. If you don't create your policies before you register users, you can't apply
registration policy settings. Applying policies at registration time also ensures that setup
policy settings are available when the registered users perform Notes client setup.

Because organizational and explicit policies are hierarchical, inheritance and enforcement
automatically fit into a parent-child relationship. This model gives you the ability to define
corporate-wide standards inherited by Organizational Units while allowing for the
 34

occasional exception. Just imagine, you can have an archiving policy in which your end
users have no control, some control, or complete control of where and how their mail
files are archived.

What makes up a policy?

If you are familiar with other aspects of Notes and Domino administration, administering
policies will probably be relatively painless. All policy information is stored on the server
in the public Domino Directory. That last sentence may spark a few questions, such as, "If
policies reside in the public Domino Directory, how are they enforced when my users
aren't connected?" Good question-with an interesting answer. When a user authenticates
with the home mail
server, a process called dynamic configuration runs locally and caches
all policy information for that user. This ensures that while the user is
disconnected, all policies are still enforced. This also means users who remain
disconnected for an extended period will not receive any changes to policies until they
reconnect and authenticate with their home servers.

As stated previously, a policy consists of a collection of Settings documents, organized

within one high-level Policy document containing a single set of fields filled with the
appropriate settings. Let's look at this through a simple diagram:

Figure G-2: Relationship between a Policy & its settings documents.

In this illustration, the top-level Policy document represents the policy you want to
enforce in your organization. The subordinate Settings documents (for archive,
registration, desktop, and
setup) contain the settings information that apply to this policy. You can think of these
Setting documents as buckets of information containing settings that in previous releases
had to be entered through many different places within the Domino and Notes user
interface. The Policy document dips into these buckets to derive the settings needed to
apply to the appropriate users and groups.

Knowing the relationship between Policy documents and Settings documents is crucial to
understanding two important features of policy-based administration: policy hierarchies
and effective policies.
 35
Policy hierarchies
Let's forget about Domino 6 and policy-based system administration for a moment and
consider a typical large corporation. This company has rules that apply to all employees
and rules that apply to some departments and not others. Some workgroups within those
departments have their own rules, with some members exempt. And there are rules for
particular types of employees, for example, contractors and managers. This may sound
complex, but policy-based system administration can make sense of it all through policy
hierarchies.

Parent and child policies

You construct a policy hierarchy by establishing parent-child relationships between
policies. When you create a Policy document, you can also create one or more child
documents for it. The original
policy is then considered the child policy's parent. Through the parent-
child relationship, you create a hierarchy of policies to apply across your entire
corporation. In such a hierarchy, Policy documents build the relationship, and Settings
documents determine the value of the fields based on their position in the hierarchy. Using
either inheritance or enforcement at the field level, you can refine settings for the
requirements of individual Organizational Units while maintaining control of certain
standards that must be enforced across the company.

For example, if you want all users to use the same Internet mail name format, set that
value in the Registration Settings document for the
top-level parent policy. After you do this, you don't have to change or reenter it in
subsequent child policies. You instead just instruct the child policy to inherit this value
from its parent. However, if your organization includes a group of international users for
whom this setting is a problem, you can create an explicit policy that applies only
to this group. The combination of explicit and organizational policies together provide the
control and the flexibility you need.

Inherited and enforced policy settings

A major feature of a hierarchical policy structure is the ability to inherit and enforce
settings. Inherited settings are derived from another Setting document. Enforced settings
are set in a parent Setting
document and are automatically inherited by all child documents. This setting cannot be
overridden in any child document. This lets you enter a setting in a single place and then
populate it throughout your corporate structure-while still allowing other settings to be set
within
each Organizational Unit. Note, however, that exception policies
overrride enforced settings. This is another reason you should use exception policies
sparingly.

Policies inherit and enforce all settings at the field level. Two checkboxes are provided for
each field that can be inherited or enforced. The following screen shows how each field in
the Archive Settings document can either inherit its value from its parent or enforce a
setting to all of its children:
 36
Figure G-3: Archive Settings

Effective policies
In a hierarchical policy structure, settings that apply to a particular group or user may not
be from a single Policy document. Instead, policy information may be derived from
multiple documents, based upon inherited and enforced settings (or even exception policies
if they're used). This derived set comprises the user's effective policy.
The effective policy consists of policy settings dynamically calculated at the time of
execution. The field values in an effective policy may originate from many different
Settings documents. Each hierarchical level can have an associated policy, so users may
have a combination of policy settings that include the values set at their OU level, and
those inherited from a parent policy. The resolution of these settings, stepping up through
the organizational hierarchy, creates the effective policy for each user.

In the end, it's the user's effective policy that determines which settings apply. So even
though the effective policy doesn't actually exist in the same sense a Policy document
does, it's nevertheless among the most crucial concepts you need to fully understand how
policy-based administration works.

Because the effective policy settings are derived at execution time, it may not always be
obvious what effect changing a value of a policy setting will produce. The Policy Synopsis
report shows the policy from which each of the effective settings is derived. This helps you
better understand the settings of individual policies, Setting documents, and effective
policies; and how they relate and affect each other.

Tools for policy-based system administration

With every new technology, however beneficial, there's usually at least some additional
level of complexity. While extremely flexible by
nature, policies can also be somewhat unfamiliar territory to the
uninitiated. And let's face it, with the way many large, global companies are structured
today (national, international, local, remote, IT, HR, and so on) a well-defined policy
structure can be more than a little complex to create and maintain. To help make sense of
all this, Domino 6 provides three useful tools for effective policy-based system
administration: Assign Policy, View Policy, and Policy Synopsis.
 37

Assign Policy
The Assign Policy tool gives you the ability to assign explicit policies. With this tool,
you can assign an explicit policy to a user or group, or you can change the explicit
policy assignment. The Assign Policy tool lets you make changes to multiple users or
groups, by associating an explicit policy with a person or group. When you change the
explicit policy for a user or group, Assign Policy gives you the option of viewing how
the change impacts the effective policy for that user or group.

For example, let's suppose your company has a group in the Domino Directory called
Executives. Imagine the group contains high-level managers and VPs from different
organizations and OUs within the company. Your corporate policy states that all
executives must follow a strict mail archiving policy. Here's an example of a few of the
people in the Executives group:

Sandy Beech/Sales/Acme
Lee Smith/Acme
Fran Jones/Development/Acme

In this example, each person has a different organizational policy for archiving their
mail:

User Organizational mail policy

Sandy Beech *
*/Acme
*/Sales/Acme
Lee Smith *
*/Acme
Fran Jones *
*/Acme
*/Development/Acme

So you create a new explicit policy called /Executives and make it an exception policy.
You then use the Assign Policy tool to assign the policy to each member in the
Executives group:

a. From the Domino Administrator, click the People & Groups tab.
b. Open the People view and select the users to whom you want to assign policies, or
open the Groups view and select the groups to which you want to assign policies.
c. From the Tools pane, click People or Groups (depending on your selection in the
previous step), and then select Assign Policy.
d. Complete the Assign Policy Options dialog box appropriately.
 38
Figure G-4. Assign Policy Options dialog box

e. Optionally, click the View Policy Synopsis button to see the new effective policy
for the group or users to which you are assigning this policy.
f. In the Choose Organizational Policy dialog box, select the
Organizational policy you want to combine with the explicit policy to create the new
effective policy.

After the Assign Policy tool populates the explicit policy field in each Person
document in the Domino Directory, the inheritance tree for the users above now looks
like this:

User Organizational mail policy

Sandy Beech *
*/Acme
*/Sales/Acme
/Executives
Lee Smith *
*/Acme
/Executives
Fran Jones *
*/Acme
*/Development/Acme
/Executives

View Policy
The View Policy tool lets you view your policy hierarchy and the relationships
between policies and policy Settings documents. You can also view the effective policy
for a selected user or group.

The View Policy tool has two views, which you access from the Configuration tab of
the Domino Administrator. The By Hierarchy view shows the hierarchy of policies, and
the settings associated with each one in the hierarchy. Use this view to display all
policies, see details of
a policy, or see which policies are assigned to a particular user or group. Here is an
example of the By Hierarchy view:
 39
Figure G-5: By Hierarchy view

The By Settings view shows policy Settings documents for each administrative area and
the Policy documents that use each Settings document. Use this view to see where each
setting is used and how a change to the setting affects other policies. Here's an example of
the By Settings view:

Figure G-6: By Settings view

 40
Policy Synopsis
With all this talk about effective policies with inherited and enforced settings, you may be
asking yourself, "How can I keep track of where setting information is coming from, so I can
be sure the right people receive the right settings?" We've anticipated this concern. Domino
8.5.x includes a tool called Policy Synopsis that helps you figure out which settings fields
come from which level in the hierarchy.

The Policy Synopsis tool determines the effective policy governing a selected individual and
then creates a report that lists the policies and settings that apply to that user. Reports appear in
a database called Policy Synopsis Results (polcysyn.nsf). You can create two types of reports,
Summary and Detailed. Summary reports display the policy hierarchy, listing both the
organizational and explicit Policy documents used to derive the effective policy settings for
the specified user. Detailed reports include everything in the Summary, plus actual settings in
the effective policy.

To use the Policy Synopsis tool:

a. From the Domino Administrator, click the People & Groups tab.
b. Select the People view.
c. From the Tools pane, select Policy Synopsis.
d. Complete the Policy Synopsis dialog box.
e. Click Results Database to define the server location and file name of the Policy
Synopsis Results database.
f. Click OK. When the Results database opens, double-click the
report to read it.

Let's take a look at what a section from a sample Policy Synopsis for a
person might look like:

Policy Synopsis - Generated at 11:17:33 AM on 01/19/2002

Effective Policy for: Sandy Beech/Sales/Acme
Derived from the following policies:

*
*/Acme
*/Sales
Archive Settings:
NoArc = 0 from Company Wide assigned in policy * NoPrivArc = 0 from
Company Wide assigned in policy * ArcLoc = 2 from Acme Org assigned in
policy */Acme ArcSrcChcs = 2 from Acme Org assigned in policy */Acme
ArcLocChcs = 2 from Acme Org assigned in policy */Acme ArchSrcServer does
not have a value set
ServerName = bbalfe4/DNA from Sales Archive Settings assigned
in policy */Sales/Acme
 41

This synopsis was run prior to assigning any explicit policy to show the effect of different
values inherited from difference policies within the ancestor hierarchy.

Examples of using policies

Here are a few simple examples of policy-based system administration tasks that might have
been difficult and/or tedious to perform in previous releases. By no means do these examples
represent everything you can do with policy-based system administration-we're just whetting
your appetite.

Creating a corporate policy

Imagine you're the Domino administrator for Acme Corporation. Policy-based system
administration greatly simplifies one of your
major headaches-ensuring that all your employees are set up the right way, without having to
rely on each user to select the exact options and preferences appropriate for them. So the first
thing you do is create an organizational Policy document called */Acme. This organizational
policy applies to all users in your company unless you specifically choose otherwise. The
*/Acme Policy document serves as a container for the Setting documents that control
registration, setup, archiving, user desktops, and security.

Figure G-7: Policy document for Acme Corporation

Registration settings
Acme Corporation has numerous company policies. Among other things, to ensure customers can easily
send email to your employees, all users must have the same Internet mail address format. Employees
are to use Lotus Notes as their default mail system. And you want to enforce a standard password
quality and certificate expiration date
across the corporation. To do this, create a Registration Settings document (let's call it
Acme_Default_Registration), and enter all this information into it. You select the mail template to use,
and specify that certificates expire after 24 months. You can then choose Acme_Default_Registration as
the Registration Settings document for
*/Acme. This means that by default, the information in
Acme_Default_Registration applies to all Acme employees at registration time.
 42
Figure G-8. Registration Settings for Acme_Default_Registration

But as with most companies, Acme has exceptions to every rule. For example, your on-
the-go, multinational Sales force needs its own mail template. Further, Sales members are
roaming users and require a different Internet mail address format. No problem-just create
an organizational policy for your Sales OU called */Sales/Acme. Then create a
Registration Settings document called, for instance, Sales_Registration; and enter the
registration information appropriate to the Sales group. These settings will apply whenever
you register a user with the Sales/Acme certifier.

Figure G-9: Registration Settings for Sales Registration

So far so good. But here's a twist: Acme corporate policy calls for certificates for all
contractors to expire after 6 months, not 24. However, these contractors are spread
throughout your OUs. You can't create an organizational policy that covers all contractors.
Instead, create an explicit policy, which you can name /Contractors.
 43
Figure G-10: Policy document for Contractors

Then create a new Registration Settings document for the /Contractors policy called, for
example, Contractor_Settings. Enter the 6-month certificate expiration setting and any
other information that applies to your contractors.

Figure G-11: Registration Settings for Contractor Settings

To have these settings applied to contractors at registration time, open the contractor's
Person document and type /Contractors in the
Assigned Policy field.

Setup and desktop configuration

Now that you've gotten registration settings squared away, you can turn your attention to user
setup, including enforcing a standard desktop for all your users. For example, you need to
control user and location preferences, which up to now have been in the hands of each
individual user-with sometimes unpredictable results. You also want the same initial set of
databases and bookmarks for each user along with the same Welcome page. Perhaps most
importantly, each user must have the same initial ECL settings for security.

By now, you've probably caught on: policies make all this much easier to implement than in
previous releases. No more trusting your users to select all the right preferences. No more days
spent visiting one user
at a time to verify that everything's set up correctly. Instead, just
create Setup and Desktop settings documents for your */Acme policy, and fill in this
information. These settings will then apply to all users in your corporation. And as mentioned,
you can handle exceptions to these rules using organizational and/or explicit policy documents.
 44
Figure G-12: Setup Settings for Acme_Default_Setup