Event ID 2243, cannotlist message - dtrace contains nothing
Created: 22 Aug 2012 | Updated: 16 Nov 2012 | 5 comments
This issue has been solved. See solution.
Hello (again).
I found out that a users mailbox can't be archived with EV 9 because of EventID 2243. Asking Google, this can happen when a folder wihtin the mailbox contains an "illegal" character.
Could not scan user mailbox /o=....../ou=...../cn=Recipients/cn= ..... cannot list messages
I tired to run a dtrace on "Mailbox Archiving issues (Exchange)" and "Mailbox Administration Tasks (Exchange)" to find the folder(s) with the illegal characters.
But when the dtrace was running and the archiving was started for the mailbox, no dtrace log was build.
Anyone have in idea to get a dtrace result regarding this issue ?
Thank you !
SK
Discussion Filed Under:
Comments 5 Comments • Jump to latest comment
After you set the dtrace...did try and do a Run Now and peform a manual run for the affected mailbox? Could you describe how you did a archive run for the mailbox? You should only need to dtrace "Mailbox Archiving issues (Exchange)". When you do a run now...check in MSMQ to see if there's any get pushed to the A3 for that mailbox archiving task queue and see if the if there is anything is in there. you should see it in there for a very short period of time then it should disappear (i.e. get processed).
Anyway, dtrace should at least conatin something, is it completely blank other than the few lines of normal stuff?
what commands did you use to set the dtrace?
Andy Becker | Authorized Symantec Consultant | Trace3 | Symantec National Partner | www.trace3.com
Hi and thanks for the replies.
- I activated the dtrace via the Admin Console (Advanced features).
- Then I did a "Run now" on the selected mailbox, seeing the event 2243 immediatly in the eventlog.
this time I get dtrace log and Google says to look for the hexcode 0x800B0001 and for "Using folder pathname to open folder [?Misc?Foldertest]". The hexcode I found ,but the message not.
This is what the logfile contains about it:
6640] (ArchiveTask) <8820> EV:H CFolderHelper::GetFolderSettingsForManualOperationEx - HRXEX fn trace : Error 0x800b0001, ..\AgentsCommon\FolderHelper.cpp [lines {1689,1794,1815,1856,1887,1856,1887,1856,1887,1856}], built Mar 14 10:54:45 2011.
366196 13:25:41.991 [6640] (ArchiveTask) <8820> EV:M CFolderHelper::GFSFMO() - Error 0x800B0001|Internal:CFolderHelper::GetFolderSettingsForManualOperationEx ..\AgentsCommon\FolderHelper.cpp [lines {1689,1794,1815,1856,1887,1856,1887,1856,1887,1856}], built Mar 14 10:54:45 2011
366197 13:25:41.991 [6640] (ArchiveTask) <8820> EV:M CFolderHelper::CreateArchiveFolderHierarchy Call to GetFolderSettingsForManualOperation returned [0x800B0001]
366198 13:25:41.991 [6640] (ArchiveTask) <8820> EV:M CFolderHelper::CreateArchiveFolderHierarchy - Exit [0x800B0001]
366199 13:25:41.991 [6640] (ArchiveTask) <8820> EV:M CArchivingAgent::processChunkOfMessages - Call to CreateArchiveFolderHierarchy Failed [0x800B0001]
366200 13:25:41.991 [6640] (ArchiveTask) <8820> EV~E Event ID: 2243 Could not scan user mailbox /o=..../ou=.... /cn=Recipients/cn=......, cannot list messages |
366201 13:25:41.991 [6640] (ArchiveTask) <8820> EV:M {CArchivingAgent::processMessages:#5533} Could not scan [user mailbox] [/o=..../ou=..... ..../cn=Recipients/cn=.......]. This problem is commonly fixed on the next scan. Cannot list messages: [0x800b0001] [(null)]
366202 13:25:41.991 [6640] (ArchiveTask) <8820> EV:L :CArchivingAgent::ProcessFolders() |Exiting routine |
Thanks fpr your support.
SK
Hello.
I finally found the folder(s) with the illegal charaters in the dtrace log. The trick is not to search for
"Using folder pathname to open folder [?Misc?Foldertest]"
but just for "Using folder pathname to open folder"
After renaming the folders in the users mailbox, archiving for this mailbox works.
best regards,
SK
Awesome work on this. I was reading through the thread and going to chime in with how to track it down. SInce you worked it out, can you flag your posting as the solution to prevent unnecessary resouces from reviewing this thread to try to help. This helps to ensure those participating in the forums can use their time wisely.
I would also say for anyone having this error... you should start a Case with SYMC so they can track it and it "SHOULD" get sent up as a defect as we should not just fail when we hit something Exchange can deal with. May not be possible.,...but if they are not made aware they will never fix it.
THanks again for posting the solution and hopefully thanks in advanced for marking it as the solution to the thread!!
Would you like to reply?
Login or Register to post your comment.