After migrating my users to ODS 43, some of them complained that their Inbox now lists mail messages that they have put/filed into folders in the past. These messages now reappear in their inboxes.
Has someone had a similar experience or even better: is there a way to avoid these anoying experience for users?
Uwe
Subject: Upgrade experience: ODS 41 → ODS 43
Uwe,
Did you follow the upgrade guide directions exactly? There are very specific updall, fixup and compact switches they want you to run before you start the Domino server as D6. I have yet to hear of anyone who followed the upgrade guide having this sort of problem. If you did upgrade properly, I would definitely like to hear it.
Jeff Dayton, PCLP, CLI
Subject: RE: Upgrade experience: ODS 41 → ODS 43
Our company had the same issues, I believe we followed the directions to a ‘T’. I will get with our administrator to find out more information.
Subject: RE: Upgrade experience: ODS 41 → ODS 43
Yes - I tried to follow the upgrade guide exactly and was very surprised to hear about this “Inbox” issue from my users. My own database was also affected. I personally managed to clean up the mess by invensting some time - but I was not expecting this and I was also wondering why this happened. This unexpected behaviour damages the reputation of Notes/Domino and due to the fact that this was a surprise for me and my users, I was wondering if there are more people seeing this.
If someone has a tip for avoiding this, it might help others when they move to ND 6.
Thanks,
Uwe
Subject: RE: Upgrade experience: ODS 41 → ODS 43
Hi there,
same experiences here; but only for like 6 or so of our 300 users on the server.
We followed the instructions rigourously; and wrote an agent afterwards to help clean up the mess.
Gunter.
Subject: RE: Upgrade experience: ODS 41 → ODS 43
Okay - good to hear that I’m not the only person having these problems.
One question:
What did your agent do to clean up the mess?
Is there some information left in the documents to help the user file the reappearing messages back into the folder where he/she filed it originally?
Uwe
Subject: Upgrade experience: ODS 41 → ODS 43
We also ran into this problem yesterday after upgrading our Mailcluster from 5.0.9a to 6.0.1CF1 (Templates are 4.6). The clustermember is still on 5.0.9a. The problem occured with ODS41 and (after upgrading last night) today also with ODS43.
During my tests i found, that after the Serverupgrade all DBs have reset the “replicate all documents modified after”-setting. When i deleted a mailfile on the 6.0.1 Node and made a new replica from the 5.0.9a node i still had corrupted databases. UNLESS i filled the mentinoned setting with a value after creating the replica-stub and BEFORE replicating the documents.
sounds pretty weired. can anybody confirm this behaviour?
Subject: RE: Upgrade experience: ODS 41 → ODS 43
I can’t explain what you are seeing in your situation, but I have written a script that resolves the problem of the reappearing messages in the inboxes of users.
Don’t know if the following steps are the right way to solve this problem correctly, but it worked for me:
load convert -m .nsf
Create a new agent in the mailbox:
Agent Name: Inbox Correction Module
Options: Shared
Runtime Trigger: On event
Target: All selected documents
Put this code into the Initialize Event
Dim session As New NotesSession
Dim db As NotesDatabase
Dim view As NotesView
Dim doc As NotesDocument
Dim maildoc As NotesDocument
Dim rtitem As NotesRichTextItem
Dim agent As NotesAgent
Dim i As Integer
Dim j As Integer
Dim thisAgent As NotesAgent
Dim serverName As NotesName
Dim server As String
Dim countdocs As Integer
Dim dc As NotesDocumentCollection
Set db = session.CurrentDatabase
Set thisAgent = session.Currentagent
Set serverName = session.CreateName(db.server)
Set view = db.GetView("($Inbox)")
If(db.FolderReferencesEnabled) Then
Print "Okay - Folder references are already enabled"
Else
Print "Warning: Folder references are not enabled"
Print "Okay - Now enabling folder references"
db.FolderReferencesEnabled = True
End If
Set maildoc = New NotesDocument( db )
' set the new document's form so it'll be readable as a mail memo
maildoc.Form = "Memo"
' set the new document's subject
server = serverName.Abbreviated
If (server = "") Then
server = "Local"
End If
maildoc.Subject = thisAgent.Name & {, DB: } & db.title & { on Server: } & server & {, Time: } & Format(Now(),"dddd, dd. mmmm yyyy, hh:mm:ss")
' set the new document's body
Set rtitem = New NotesRichTextItem (maildoc, "Body" )
Call rtitem.AppendText ( "Here are the documents we've been working on in your Inbox:" )
Call rtitem.AddNewline(2)
'Disable autoupdate in the view!
If (view.AutoUpdate = True) Then
Print "Disabling the auto update feature of the inbox view..."
view.AutoUpdate = False
End If
Print {Started agent "} & thisAgent.Name & {". Please wait...}
'Set doc = view.GetFirstDocument
Set dc = db.UnprocessedDocuments
If dc.Count = 0 Then
Print "Please select some documents before calling this action."
Exit Sub
End If
For j=1 To dc.Count
Set doc = dc.GetNthDocument(j)
countdocs = countdocs + 1
i = 0
Call rtitem.AppendText ({Subject: "} & doc.Subject(0) & {" from "} & doc.From(0) & {", Note ID: } & doc.noteid)
Call rtitem.AddNewline(1)
'Cycle through all documents and put them in the folder - except for the folder ($Inbox)
Forall FolderReference In doc.FolderReferences
i = i+1
'if (FolderReference <> "($Inbox)") Then
Call rtitem.AppendText ({ - Folder (} & i & {): } & FolderReference & {, Note ID: } & doc.noteid)
Call rtitem.AddNewline(1)
If (FolderReference <> "($Inbox)") Then
Call rtitem.AppendText ({ - - Mail was removed from the Inbox: it was already filed in a folder: "} & FolderReference & {" before...})
Call rtitem.AddNewline(1)
' Because if it was filed before, just remove the doc from the Inbox folder
Call doc.RemoveFromFolder("($Inbox)")
End If
End Forall
Call rtitem.AddNewline(1)
Next
Call rtitem.AddNewline(2)
Call rtitem.AppendText ({Totally processed mail documents: } & countdocs )
Print {eMail was sent to: } & session.UserName
Call maildoc.Send( False, session.Username )
Print "Enabling the auto update feature of the inbox view..."
view.AutoUpdate = True
Print {Ended agent: "} & thisAgent.Name & {". Finished.}
Open the mailbox
Select all messages (Ctrl-A) in the inbox or only a few (e.g. for testing) and invoke the agent/script via the action menu
The script checks for every message in the inbox if this message was already filed in a folder in the database. If the message was filed before, it just removes that message from the inbox folder using the RemoveFromFolder method.
It also reports/logs all what it is doing and sends a message to the user invoking the agent.
Hope this is of help for those facing this problem.
Uwe
P.S. Post your diffs to the code here 
Subject: Inbox Repair fixed strange replication issue
The issue I had was that a user’s mail had messages re-appear in the inbox after a R6 client upgrade. The user diligently repaired the mis-filed messages (deleted and re-filed) in a local replica that sucessfully updated the server replica but NOT a different local replica on a different machine.
All replication settings were verified and the # of documents were the same across all replicas, but one replica still had mail in the inbox that should have been only in a folder.
The ‘buggy’ replica (R601, Win98) was deleted (in Notes) and recreated from the server replica, only to have the exact same problem! I even deleted the local replica from the OS and recreated it from scratch (again), but 300+ messages still appeared in the inbox (and not in their respective folders).
Your agent worked perfectly and was able to repair the ‘buggy’ local replica. THANKS!
Does anyone have a clue as to how the folder references could be broken even after creating a new local replica? a ‘folder cache’ of some kind?
Subject: RE: Upgrade experience: ODS 41 → ODS 43
Hi,Didnt do an upgrade, but migrated some R5 mail databases over to ND6 server.
The first time it run compact, from log.nsf you can see it deleting lots of documents. I think it was deleting the stubs. From discussion, seems like compact -i -c solve the deletions. I do it the second time and it seems that it will stop deleting.
check the link below :
HTH
Subject: RE: Upgrade experience: ODS 41 → ODS 43
great script … unfortunately i couldnt use it, cause there have been many mails in no folder but in the ‘all docs’ view (which results in no folder-ref). i assume this happend when users deleted folders but not the documents.
The Problem did not appear on the 5.0.9a cluster-node, so i wrote a script that compares the inboxes and removes the diffs. it works only with UNIDs so its pretty fast.
if somebody is interested in the code, please drop me a mail and i’ll be happy to provide the source.
Subject: Upgrade experience: ODS 41 → ODS 43
We too have seen this happen for a few users, but most often related to users (myself included) that have local replicas of their mail databases. At some point in switching between local and server based replicas, the “corruption” occurs.
This actually happened to me twice. The second time, I replicated to the local replica, deleted the server based copy, and created a new replica on the server. Still ODS 43, and everything looked fine.
This is, indeed, a strange problem.
Subject: RE: Upgrade experience: ODS 41 → ODS 43
Here are more “strange” details:One user has a replica on another server of his mailbox. This replica is looking fine for him on this server and really messed up on the other server.
Deleting the messed up database on the server and recreating a new replica on the server resulted in a replica with the same “corruption”.
The new database replica was created using the 6.01CF client.
This is indeed a very strange problem. I would appreciate if someone can explain, why one database looks fine while the newly created replica from that database looks messed up.
I would expect the replica on one server to look exactly like the replica on another server.
Any insights or tips on how to resolve this situation?
Looks like an object store problem on a very low level to me…something that needs to be investigated in detail.
Uwe