HCL Domino Daily — Daily Technical Picks
A bilingual daily HCL Domino publication — fresh ecosystem news and technical deep-dives, every day.
Latest Posts
- Domino Server Mail Rules: Catching Mail Before It Reaches the Inbox
Some messages you don't want landing in a user's inbox at all — block ones with a certain attachment, divert mail to a departed account, keep a copy of a category for the record. You don't need an agent for this: Domino's server mail rules apply while the message is still in MAIL.BOX, as the router handles it. This piece covers where you set them (the Configuration Settings document's Router/SMTP → Restrictions and Controls → Rules), when they run (as the message lands in MAIL.BOX, each message evaluated once — unlike the client-side rules in a user's mailbox), how conditions work (contains/is operators, no wildcards, AND/OR, case-insensitive), the six actions (Journal to keep a copy, Move to database to quarantine, Don't accept to reject outright, Don't deliver to silently delete or send an NDR, Change routing state to HOLD, Stop processing to skip later rules), and two things to know: Domino doesn't notify the sender or recipient by default, and mail rules are not an anti-virus solution.
2026.10.28 - Domino Out of Office: Why to Use the Service, Not the Agent
A user sets an out-of-office auto-reply, comes back and forgets to turn it off so the system keeps replying, or the replies always lag — which of these you get depends on which Out of Office type your server runs: Service or Agent. This piece covers how the two differ (the Service runs inside the mail router, so replies are instantaneous, failover is supported, delegation is integrated with calendar management, it disables itself when the period ends, and it allows periods shorter than a day; the Agent runs on a schedule four times a day by default, must be disabled manually, delegation isn't calendar-integrated, and its minimum period is a day), where you set it (the Server Configuration document's Router/SMTP → Advanced → Control, defaulting to Agent), why you should use the Service today, and two operations: seeing who's out via the Out of Office column on the Files tab, and listing mailboxes with an active Service via Tell router O.
2026.10.27 - Domino Cluster Failover: No Replica, No Failover
A Domino server goes down, or gets overloaded, and users barely notice — that's a cluster doing failover and workload balancing. But failover isn't magic: its hard prerequisite is that another cluster server holds a replica of the database — no replica, nothing to fail over to. This piece covers how the cluster components work together: each server's Cluster Manager probes the others for availability and load and finds membership by watching the Domino Directory's ClusterName; cldbdir.nsf (a replica on every server, one document per database and replica); the event-driven, near-real-time Cluster Replicator (checks about every 15 seconds, replicates only among cluster members, while the regular REPLICA task handles replication outside the cluster); how failover works (the Cluster Manager builds a list of servers holding a replica, sorts it by availability, and sends it to the Notes client, largely transparent to the user); how workload balancing uses an availability threshold to mark a server BUSY and route requests to other replicas; and the Internet Cluster Manager (ICM) for HTTP clients.
2026.10.26 - Policies: Push Settings to Every Notes Client From One Place
To apply one setting — a password rule, a mail quota, a desktop feature toggle, an ECL — to every Notes user at once instead of machine by machine, you use a policy. This piece explains how Domino policies work: the two assignment types (organizational policies apply automatically based on the OU used at registration; explicit policies are assigned by hand to individuals or groups); the policy settings document types (registration / desktop / mail / security / archive, plus the deprecated setup that merged into desktop); what the effective policy is — the settings a user actually gets, dynamically computed at execution time from OU-level, explicit (including groups), and inherited parent-policy values; the crucial How to Apply modes (Don't set value / Set initial value / Set value whenever modified / Set value and prevent changes = locked), which decide whether users can change a value; and how an exception policy lets specific users override otherwise-mandatory settings.
2026.10.25 - DDM: Domino's Built-in Proactive Monitoring
Server trouble is usually 'the users complain first, then you find out.' DDM (Domino Domain Monitoring) is Domino's built-in, proactive-leaning monitoring: it runs probes on a schedule to check the health of databases, the directory, messaging, the operating system, replication, security, the server, and the web, records events into ddm.nsf, and gives you a top-down, feature-oriented view of the whole domain in the Domino Administrator — often with a probable cause and suggested corrective actions. This piece covers what a probe is (and that its configuration documents live in EVENTS4.NSF and take effect immediately), how ddm.nsf stores events, how the collection hierarchy lets one collection server consolidate the whole domain (the collection interval is a fixed 5 minutes), the difference between enhanced and simple events, and how an event handler notifies you — by logging, mail, running an agent, running a program, sending console commands, or an SNMP trap — when an event fires.
2026.10.24 - How Domino Web Login and Multi-Server SSO Work
A user logs into Domino in a browser and then clicks around without logging in again — that's session-based authentication: the server issues a token, puts it in a cookie, and the browser carries it on every request. Letting a user log into one server and reach several others (SSO) relies on a Web SSO Configuration document in the Domino Directory holding a shared secret key. This piece covers how basic and session authentication differ, single-server cookies vs multi-server SSO, that the Web SSO Configuration document must replicate to every participating server, the hard conditions that make SSO fail (the DNS domain must start with a period, URLs must use the FQDN, cookies can't cross TCP/IP domains, only Domino servers can be listed, and all SSO servers must use the same Internet-access method), an easy trap — enabling Internet Sites in the Server document automatically disables an existing SSO configuration — and the caveats for sharing LTPA with WebSphere (importing WebSphere keys removes the idle-timeout option, and the LTPA realm must match).
2026.10.23 - Where Domino Reads Its Web Config: Internet Sites or the Server Document
You change a Domino web setting and nothing happens — often it's not a wrong value, it's the wrong place: Domino's Internet-protocol configuration comes from two sources, the older Server document (Web Server Configurations / virtual servers) and the newer Internet Site documents (stored in the Domino Directory and managed centrally). Which one a server reads is decided by one switch on the Server document's Basics tab. This piece covers how the two models switch, which protocols an Internet Site document configures (Web/IMAP/POP3/SMTP Inbound/LDAP/IIOP), why edits don't need a restart, an easy-to-hit all-or-nothing rule (if one protocol on a server uses Internet Sites, all protocols must), what the Web Site document's Basics/Configuration/Domino Web Engine/Security tabs each control, which settings (TCP/IP port, SSL port, server access) always stay in the Server document, and how to confirm from the HTTP startup message which source the server is actually using.
2026.10.22 - Why Your Scheduled Agent Doesn't Run — or Runs Late
You schedule an agent to run hourly, and it doesn't run, runs late, or gets killed mid-run — usually it's not the agent that's broken, it's the Agent Manager (AMgr) server task's settings governing it. This piece covers how AMgr schedules: the Server document's daytime/nighttime windows (default day 8AM–8PM, night 8PM–8AM) and the most common trap — if the two periods leave a gap, AMgr doesn't run scheduled agents during it; Max concurrent agents (1–10, default day 1 / night 2) and Max LotusScript/Java execution time (default day 10 min, night 15 min — over it, the agent is terminated and logged in the Agent Log); why document/mail triggers aren't instant (AMgr_DocUpdateEventDelay, AMgr_DocUpdateAgentMinInterval default 30 min, and other notes.ini throttles); what 'Agent scheduling is paused' means; and using Tell Amgr Schedule / Tell Amgr Status from the console to see whether it was even scheduled. Ends with a step-by-step checklist for a scheduled agent that won't run.
2026.10.21 - How a Message Routes Through Domino: It All Goes Through mail.box
A user clicks Send — where does the message actually go? In Domino, every message first lands in a database called mail.box, and the Router task reads the recipients one by one and decides 'deliver locally' or 'transfer to the next server.' This piece lays out the chain: what mail.box is (and why one server can run several mail1.box/mail2.box), how the Router periodically checks it and consults its routing table, the two transfer protocols (default Notes routing / NRPC moving the message hop-by-hop into the next server's mail.box, and SMTP using DNS MX, port 25, MIME only, off by default and enabled on the Router/SMTP tab of the Configuration Settings document), how the message is delivered into the recipient's home-server mail file; and finally the two kinds of message stuck in mail.box — dead (stop-sign: can be neither delivered nor returned to the sender) and held (red exclamation: held by a mail rule or quota) — what causes each and how to handle them.
2026.10.20