Wednesday, November 4, 2026

Verse replaces iNotes, BUT Don't delete that iNotes Directory

 FML, I am trying to clean up my personal server, hunting down why my NAB still is looking for my Quickr server, long dead and removed, deleted, and yet, something still hangs on to it.

That will be another story for another time.

Last night, while looking for this server, I found the iNotes folder with the forms9.nsf in it.

Knowing Verse replaced iNotes, I figured this was a relic, the ACL even had my Quickr server in it, somehow.

I did what any good admin would do, I removed the old server name, added the current one, then changed the ACL to no access for Default and Anonymous.

That's when the problems began, later on when I went to check on my email via Verse in Chrome on my laptop.

First it looked like it loaded but said to try again there was a problem.
Try again NEVER works.
But I tried, no dice.

"Could not load recent contacts data, verify network connection and try again"

and similar errors, and now, no emails.

I had to rethink all the NSFs I touched the prior 2 hours and only 2 made any sense to check: traveler.nsf and iNotes\forms9.nsf.

It turns out that Verse may have killed off iNotes, but it is more like how Windows still runs on DOS commands.

Comparing the forms9.nsf to my demo server, I reset Default and anonymous to Reader, and Verse worked again.

WTF HCL?

Looking at the developer tools it seems Verse is relying on the iNotes proxy, which you may have guessed, lives in the forms9.nsf.

For those asking why I didn't ask AI, I did, it only suggested all the things from past technotes about needing my email in my person document.

And, since it is my Production server, which already gets slammed by lots of bad entities from across the Middle East, Russia, and Asia, I couldn't let it poke around.

On the plus side, one less old server reference removed.

I have an AI agent running on my server to find the "hidden" server reference, so far no update.

Tuesday, October 6, 2026

Setting Up Directory Assistance for LDAP in HCL Domino

Setting Up Directory Assistance for LDAP in HCL Domino

Integrating remote LDAP directories into your HCL Domino environment can streamline authentication and directory lookups. Here's a step-by-step guide to setting up directory assistance for an LDAP directory.

Prerequisites

Before diving in, ensure you have:

  • Network Connectivity: Verify that your Domino servers can reach the remote LDAP server. A simple ping test can confirm this.
  • Directory Assistance Database: Create a directory assistance database (da.nsf) from the da.ntf template and replicate it across servers that will utilize it. Each server must have a local replica to use directory assistance. (ibm.com)

Creating a Directory Assistance Document

  1. Access the Domino Administrator:

- Open Domino Administrator. - Navigate to the server that will use the directory assistance database.

  1. Open the Directory Assistance Database:

- Go to the Configuration tab. - Expand Directory > Directory Assistance. - If prompted with Server Error: File does not exist, ensure the server is set up to use the directory assistance database.

  1. Add a New Directory Assistance Document:

- Click Add Directory Assistance.

  1. Configure the Basics Tab:

- Domain Type: Select LDAP. - Domain Name: Assign a unique name different from other Directory Assistance documents. - Company Name: Enter the associated company's name. - Search Order: Define the order in which servers search this directory relative to others. - Make this domain available to: - Notes clients and Internet Authentication/Authorization: For mail addressing and client authentication. - LDAP Clients: To enable LDAP service referrals. - Group Authorization: Choose Yes if you want to search group memberships in this LDAP directory for database access control. - Enabled: Set to Yes.

  1. Configure the LDAP Tab:

- Host Name: Enter the LDAP server's hostname or IP address. - Port: Default is 389 for standard LDAP or 636 for LDAPS. - Optional Authentication Credential for Search: Provide credentials if the LDAP server requires authentication for searches. - Base DN for Search: Specify the base distinguished name (e.g., dc=example,dc=com). - Channel Encryption: Choose Yes if using SSL/TLS. - LDAP Vendor: Select the appropriate vendor (e.g., Active Directory).

  1. Save and Close the document.

Testing the Configuration

After setting up, it's crucial to test the configuration:

  • Verify Connectivity: Use the Verify button in the LDAP configuration section to test the connection. If you encounter errors like LDAP Server is NOT available, ensure the LDAP server is accessible and that network configurations are correct. (developer.ds.hcl-software.com)
  • Monitor the Domino Console: Restart the Domino server or the LDAP task and monitor the console for any error messages related to directory assistance.

Troubleshooting Tips

  • SSL/TLS Issues: If connecting over LDAPS (port 636), ensure that the Domino server trusts the LDAP server's SSL certificate. This might involve importing the certificate into Domino's key ring.
  • Authentication Failures: Double-check the credentials provided in the Optional Authentication Credential for Search field. Ensure they have the necessary permissions to search the LDAP directory.
  • Group Authorization: If group lookups aren't functioning, verify that the Group Authorization setting is enabled and that the LDAP directory contains the expected group structures.

The Outcome

By integrating a remote LDAP directory through directory assistance, your Domino environment can authenticate users and perform directory lookups seamlessly across multiple directories. This setup enhances flexibility and centralizes user management, especially in environments with diverse directory services.