Domino Directory Cataloger (dircat) does not replicate updates

In a large organisation I found that a domino directory catalog consolidating about 5 large domino directories did not have all documents replicating and was completely out of sync….

There are a variety of reason why directory catalogues are used. For most organisations it is simply to have a consolidated directory from multiple domino directories to then have and easy global mail list in your mailTo address drop down box, or for directory assistance on servers, others orgs have more complicated reasons.

As part of a Notes to Exchange migrations there are a bunch of requirements for the documents in Notes to facilitate coexistence. This can often lead to manipulating a firms objects extensively. Organisations often do not like you doing this, especially the big ones with app’s (potentially legacy) embedded into their ecosystems which rely on certain parts of the person document for things like authentication.

Therefore, one of the clear solutions is to consolidate the domino directory(ies) into a dircat and make the changes there; leaving the source directly mostly lonesome.

For coexistence this is great if your running on a single server, as the dircat can run and then a manipulation agent can merrily customise the documents to its hearts content. Unfortunately, this methodology does not always work when you have to replicate a dircat directory to other servers, and when you have rogue admins. (orgs never have those, right?)

Let me first say that a dircat produces a carbon copy of the source document. So if you compare the source and destination document UNID and Sequence number they will be a perfect match. Obviously the NoteID is different as always.

If you need help sleeping, this article goes in-depth into these concepts. http://www-01.ibm.com/support/docview.wss?uid=swg27002668

Believe it or not this creates a challenge if you have to customise the variety of documents in the domino directory to meet the needs of migration and coexistence.

So this is how the documents go out of sync….

First of all lets call the sequence number for a document x. “x” currently matches both the source NAB and dircat document.

If your manipulation agent or administrator comes along and modifies the document in the dircat directory, this has now increased the sequence number (x+1). This is fine in itself, but the nightmare begins when something “else” comes along and modified the same document, thus the sequence number is now twofold higher than the original source document. (x+2)

The challenge here, is that this second modification of the document has caused future replication to break with other replica’s. It is true that the changes (the x+2 ones) will fully replicate to all other replicas of the dircat, but if the source document is now modified, we have a new base sequence number of x+1. Then, when the manipulation agent runs it makes this document have a sequence number of x+2, our sequence numbers now perfectly match all the other dircat replica’s. Therefore the document never updates with the other databases as replication compares the sequence numbers, it matches, so it ignores the change. Date/time of changes are ignored.

This image might be a better way of explaining.

How do you avoid this problem?

1) only have PUSH replication from your dircat server to the other replicas

2) change the ACL so not even admins can modify documents to avoid accidental changes.

3) code your manipulation agent so it categorically cannot modify documents twice.