Hierarchical Moves

Thursday 26th May, 2005
I've got a major internal project going on right now, in fact many...

One of them is to move my entire user base into a new OU, we're adding in a departmental OU that has been historically overlooked. It all sounds so simple doesn't it? Fred Bloggs/UK/Org becomes Fred Bloggs/Department/UK/Org. All good in principle, but in practice very different.

One submits a "user move in hierarchy" request, it all goes ahead and processes. The user's Notes client auto-accepts the new name (R6) and then all the email and I mean ALL the email goes unread. Absolutely f***ing useless.

Alas, we check adminp...there's a sub-process "Rename person in unread list". We wait...all excited. It processes...we're still excited. It's finished...they're all still unread.

This is now halting my entire project. There is no way in hell I can possibly break every user's unread marks just weeks after a server migration did just the same. It's consistent, it's reproducable and I have never, ever seen it work.

In my opinion, unread marks are the worst problem ever experienced in the Notes client. It's the most visible to users, they all depend on  them and they break all the time. User rename...unread marks break. Change Server...broken. Change OU...no chance. Cluster failover...if you're lucky.

I know I'm not alone, I used to work in Lotus Customer Support, I used to receive these problems and point them to technotes and SPRs that, basically, said sorry but they don't always work.

Enough is enough, I need your help. If you have problems with unread marks, please post a comment here. It's time we logged calls with Lotus and got this recognised as a major issue. As far as I can tell, this has not and will not be addressed in R7. We need it fixed...don't we?

  1. 1) Scott Joyner Said: (26/05/2005 22:50:22 GMT) Gravatar Image
    Hierarchical Moves

    I agree. Unread marks are entirely unreliable. We've been on Notes since 3.0 and there's always something breaking them. However, we are going through an /O change and so far no unread mark problems. Plenty of other problems, though. (But that's another discussion).

  2. 2) Stephan H. Wissel Said: (27/05/2005 12:27:11 GMT) Gravatar Image
    Hierarchical Moves

    You might want to check the Sandbox. There was some wrapper code to access the unread flags in LotusScript via the C Api. While it can't offer a solution to avoid the problem it could limit the impact.

    Have an agent retrieve all unread marks, do the move put them back...

    ;-) stw

  3. 3) Eric Parsons Said: (09/06/2005 19:17:07 GMT) Gravatar Image
    Hierarchical Moves

    I couldn't agree more. Got worse with clustered servers trying to keep the buggers synchronized. Haven't had the OU move issue though.

    I have a flowchart on my wall describing the process. Generally will quiet anyone wanting to know why this is happening to them. Amazing it works as all.

  4. 4) Chris Whisonant Said: (09/06/2005 20:55:36 GMT) Gravatar Image
    Hierarchical Moves

    @3 - Eric, do you have that flowchart in electronic format?

    @Unread Marks:

    Well, considering the archtecture:

    { Link }

    I am surprised it's not worse. But they supposedly made some 6.0.3 and 6.5 enhancements which I'm reading now:

    { Link }

    I just switched over to my cluster replica as well as my local replica. In both the unread marks are highly inconsistent. I've never had a name change, /O change, etc... But from reading this change doc for 6.5, it may be that I've just never enabled the "Replicate Unread Marks" (DUH!!!). We just got a cluster server in February, so I'm rather new at the whole cluster thing. I'm going to enable that and see if it helps out.

  5. 5) Dave Harris Said: (10/06/2005 08:04:29 GMT) Gravatar Image
    Hierarchical Moves

    Ben,

    This isn't a solution, but a possible workaround.

    Prior to starting the Name move requests, would it be possible to uncheck the "Mark modified documents as unread" database property.

    Then AdminP does its stuff updating all the Names fields, then you can reset the property back.

    Obviously user modified documents would also be left untouched, but...

    Probably need testing first of course, and very tiresome for you (though I'm sure you can work out a way to set those properties en masse), but surely much better than all the support calls

    HTH

    Dave

  6. 6) Ben Rose Said: (10/06/2005 08:18:50 GMT) Gravatar Image
    Hierarchical Moves

    Dave,

    Interesting thought. Looking on my test R6 environment here at home the setting is actually "Do NOT mark modified documents as unread" and, in the standard mail template, the default for this is on.

    I'll double check in my work environment to confirm this is the same, but I expect so.

    My problem here is that the new user name simply hasn't ready those documents...hence they're unread.

  7. 7) Chris Whisonant Said: (10/06/2005 14:28:31 GMT) Gravatar Image
    Hierarchical Moves

    @6 - Exactly, BUT the system SHOULD be able to fix that after a rename or /O change. (Hence our beef with unread marks...)

  8. 8) Chris Whisonant Said: (10/06/2005 14:46:00 GMT) Gravatar Image
    Hierarchical Moves

    UPDATE: After enabling the "Replicate Unread Marks", I went to my cluster mail file and marked all my docs as read. There were 3 unread docs in my actual mail file. After marking everything read on cluster, after about 10 minutes my actual mail file was updated. I marked those 3 docs back to unread and after a bit my cluster is reflecting that change properly. Will be keeping an eye on this.

  9. 9) Perry Hiltz Said: (10/06/2005 16:17:44 GMT) Gravatar Image
    Hierarchical Moves

    Unread marks are a pain. As we regularly migrate users between O and OU certifiers, we have found that for the most part, a bit of upfront work to ensure that things are in place helps tremendously. We have an agent that reviews the user's mail files before we begin our rename or move to new certifier. We validate that the user's name is in the mail file, that the user's home mail server is in the ACL of the mail file, that the user's home mail server is the administrative server of the mail file in the ACL, and that the user's old name is listed in the calendar profile owner field. I have had only one client have a problem with Unread marks and it was widespread. In my professional opinion, this was an environmental issue and not a client related issue. Feel free to contact me with questions.

  10. 10) Dovid Said: (10/06/2005 18:59:55 GMT) Gravatar Image
    Hierarchical Moves

    @8 -- you can only prove this works if you use two workstations, one pitning at primary replica, one pointing at cluster backup replica.

    Why?

    Because thw rokstation maintaina s asort of "unread mark transaction log," and will replay transactions to each replica as it is opened. So, open your mail file on server A, make unread changed, then switch to a local replica or another copy on a different server or the same server (clustered or not clustered), and the same changes should be applied immediately, as long as you are using the same workstation, even without replication.

    I once jokingly told one of our admins that we could solve our cluster unread problems by forcing failover from A to B then B to A on alternating days. The client unread log would fix everything.

Add Comment
 
Subject:
   
Name:
E-mail:
Web Site:
 
Comment:  (No HTML - Links will be converted if prefixed http://)
 
Remember Me?