//
you're reading...
Domino

So I moved a user to a new server, now all the Unread Marks are screwed up, what happened?

Senario:

A user is moved to a new Domino Mail server. The user’s home mail server is now set and we redirect the workstation to the new server. Now the user sees a lot more unread documents than they had seen on the old server.

This typically happens after the “Replicate Unread Marks” is enabled.

I think I have an answer on what is going on. This is stemming from the first initial introduction of Replicate Unread Marks as a database properties object. The following is from the technote (http://www-1.ibm.com/support/docview.wss?uid=swg21140018) The enhanced unread functionality introduced in Notes/Domino 6.0.3 and 6.5. Essentially Unread marks are now controlled via the Unread Activity Log. This log is used to update the Unread table. Unfortunately according the technote the document updates only happen to this Unread Activity Table once it is activated; “The feature will not log the status of pre-existing documents…”

From the Technote mentioned above:

Basics:
An Unread Activity Log is kept which is then used to update the Unread Table (The design of the Unread Table has not changed; it is still used to denote Unread documents.). Both the log and the table are stored in the database. The log contains time stamp information that is used to determine the latest unread status for a document. When a user marks a note read or unread, a new entry will be added to the end of the activity log. The activity log is played back when a database is opened or F9 is pressed while in a view. The feature will only have an effect on the unread status of documents after it has been enabled (The feature will not log the status of pre-existing documents until they have been marked as unread or read after enabling the feature.). The feature requires using the ODS (On Disk Structure) of 43.

For efficiency and performance, this feature is best suited to applications with few users, such as mail databases. While it will function in applications that are used by many users and experience high activity, a performance impact is likely.

The functionality is designed to work with iNotes as well as standard Notes mail. Unread mark updates that occur on pre-6.0.3/6.5 Notes/Domino servers and clients will not be integrated into the Unread Activity Log.

Unread Activity Log Playback (which updates the Unread Table):
During the playback, the Unread Table is brought up to date with the activity log.
Playback starts from the oldest modified log entry since playback. During playback, the sequence number in the log entry is compared with the sequence number of the note in the database. If the note has been deleted, or the sequence number of the note is later than the sequence number of the entry, then the activity is ignored. Otherwise, the NoteID is either added or removed from the Unread Table. The playback of the log is optimized by the use of a pointer that indicates the oldest log entry added since the last replay. The log will be purged of entries older than the replication time limit (replication cutoff time).

Note: For optimization, the log is sorted from the last entry to the first entry. ”

As a result then databases are moved to a new server the unread table (on this server) is updated according to the Unread Activity Log to reflect the pre enablement documents as unread.

To resolve this requires significant user interaction. There two ways to resolve this. Further down in the technote it reads:

The first is to select the old server icon on the workspace, hold the shift key down and select the second icon. Next click Edit in the menu, select Unread Marks, and choose the Exchange Unread Marks option.

The second is harder.

“If you already have had the unread replication functionality enabled:
Synchronize the replicas by updating the unread/read status of all the documents in the database to write them to the Unread Activity Log. This involves toggling the documents’ unread status to the opposite status. Then, toggle documents a second time back to the original state.

Steps:
1. Create two folders, Group1 and Group2.
2. Go to the All Documents view.
3. From the menu, select: Edit -> Select All.
4. If using a mail based design, click the Action Bar -> Folder -> Move to Folder ->
select Group1 -> Add. For other designs, drag the document collection to the Group1 folder in the left pane.
5. Switch into the Group1 folder.
6. From the menu, select View -> Show -> Unread Only. Only the unread documents should appear.
7. From the menu, select Edit -> Select All.
8. If using a mail-based design, click the Action Bar: Folder -> Move to Folder -> select Group2 -> Move. For other designs, drag the document collection to the Group2 folder in the left pane.
9. From the menu, select View -> Show -> Unread Only. The read documents should re-appear.
10. From the menu, select Edit -> Select All.
11. From the menu, select Edit -> Unread Marks -> Selected Unread.
12. From the menu, select Edit -> Select All.
13. From the menu, select Edit -> Unread Marks -> Selected Read.
14. From the menu, select Actions -> Folder Options -> Remove folder.
15. Switch to the Group2 folder.
16. From the menu, select Edit -> Select All.
17. From the menu, select Edit -> Unread Marks -> Selected Read.
18. From the menu, select Edit -> Select All.
19. From the menu, select Edit -> Unread Marks -> Selected Unread.
20. From the menu, select Actions -> Folder Options -> Remove folder.”

The drawback is that neither of these can be completed programatically.

There is another way to prevent this. I’ve seen this very regularly with AIX and Sun Solaris, but if the files are FTP’d from the originial server to the new server, the unread table is still orginial and not rebuilt from the Unread Activity Log.

What is interesting is that if the user is renamed before this move, the unread table is updated with the new name for ALL emails, thus updating the Unread Activity Log with these older entries. When the replica is created on the target server, the unread activity log is sent to the new server with the updated entries for the new name, and the Unread Table matches.

Advertisements

About pwhiltz

I am a Domino Administrator and Developer who has been working with IBM Domino solutions since 1997. I work for an Enterprise Email Migration company and am delving into the realm of Microsoft Exchange now.

Discussion

4 thoughts on “So I moved a user to a new server, now all the Unread Marks are screwed up, what happened?

  1. Have a look at the INI parm ADMINP_EXCHANGE_ALL_UNREAD_MARKS

    Posted by Michael | August 25, 2011, 6:48 pm
  2. Check if your servers have ADMINP_EXCHANGE_ALL_UNREAD_MARKS=1 in the notes.ini and read http://www.ibm.com/support/docview.wss?uid=swg21245043
    This should solve your problem for future moves.

    Posted by Christian Brandlehner | August 30, 2011, 3:42 am
  3. Thank you all for the tip on the ADMINP_EXCHANGE_ALL_UNREAD_MARKS. According to the 7.0.2 Fix list this is what it states:

    “SPR# BSPR67HN6W – Using a server based, Notes.ini variable (ADMINP_EXCHANGE_ALL_UNREAD_MARKS = 1), this fix will allow the exchange of unread marks when the Administration Process based replication is used to create and populate a replica between servers. Please note that the amount of time to perform the initial replication by the administration process will increase due to the additional work required to exchange all the unread marks”

    However this is applicable to only those instances when you use the Administrative Process to create the initial replica on the target server. In my case and those of my colleagues at Binary Tree, we often create replica stubs via a Lotus API call. This is why we see this as a problem. The Administrative process works great when you do this within a single domain. What about doing this across domains? Now right now I cannot validate that this works across domains as I am away from my lab at a customer site.

    I would need to validate first if creating replicas across domains works, secondly does this parameter work across domains? I’ve done a lot of work in the past consolidating Domino infrastructures and had to move users first then rename them. If you execute a user rename first, you don’t encounter this issue. Why?

    Well when the AdminP processs “Rename Person in Unread List” runs, it will mark all read messages as read with the new name. This updates the Unread Activity Log with the entries for the new name. However when we move users to their own domain then issue renames we see issues.

    As for my colleagues we see unread mark issues in Migrations to Exchange online. We typically replicate mail files to staging servers close to the migration workstations and execute a migration from there. What causes the problem is that due to the issues we see defined by the Technote, the unread marks don’t update correctly on the Staging server (different Domain) and as a result we see a customer dissatisfaction with the solution.

    Thanks again.

    Posted by pwhiltz | August 31, 2011, 12:11 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: