Not Exchange 2010, but 2007: the IS on one of our mailbox server was crashing within five minutes of it starting up. Sometime it would take a few hours, other times the minimum of five minutes (don't know why it would be five minutes actually, but it was never shorter than that).
Anyway, fast forward to almost a week of PSS investigations and they finally found the cause, which was a recursive search folder bug which, having got to some arbitrary depth, caused the IS to crash. This seems similar to your problem. At the time, we applied a hotfix to resolve the issue and were told it would be included in the following rollup. This was April 2009, I can't remember if we were on SP2 by that point. Richard From: bounce-9480148-8066...@lyris.sunbelt-software.com [mailto:bounce-9480148-8066...@lyris.sunbelt-software.com] On Behalf Of Wright, Seth - wrightst Sent: 26 January 2012 20:33 To: MS-Exchange Admin Issues Subject: E2010SP1 Max Folder Depth / Max Folder Path Length? Hello all, We had a helpdesk frontliner trigger an interesting...phenomenon...in Exchange yesterday. I don't have the full details, but I was told he was trying to copy a calendar folder from his Live@edu mailbox into his on-premise Exchange mailbox (Outlook 2010; he had both mailboxes in separate Exchange-type accounts). For whatever reason, the copy failed, and he went to do something else. When he went back to Outlook a minute or two later, instead of the process actually "failing" he now had 232 (I counted) Calendar-type folders. These folders were in one single hierarchy, like so: /Calendar /Calendar/Work /Calendar/Work/Calendar /Calendar/Work/Calendar/Work And so on, until the final "Calendar" folder was 232 levels deep, with a path length of 1,622 characters. The "Calendar" folders had zero items in them, while I think the "Work" folders had maybe six items each. Anyway, said student tried to delete the folder structure in Outlook but couldn't. (I don't know what error it gave him there.) He then tried to delete the structure in OWA, but it didn't work there, either; it kept giving a "permission denied" message. (I theorize that OWA didn't know *why* it couldn't delete the folder, so it defaulted to "you must not have permission". But I could be way off-base.) So, they called me. I loaded up the mailbox in Outlook, saw it fail, so I went to MFCMapi and tried to delete it there. However, every time I tried, the mailbox would disappear for a few seconds, come back with a MAPI_PARTIAL_FAILURE (that's not quite correct, but I didn't write it down yesterday), and not actually delete anything. I then decided to export his mailbox as a PST and exclude the /Calendar/Work/* folders in order to reimport into a "clean" mailbox. As I'm running "Get-MailboxExportRequestStatistics", in a slow loop, the cmdlet errors out with an error similar to "Cannot get statistics for request because the database is dismounted on the mailbox server." Uhh...what? To make a long story endless, it turns out that something to do with this huge folder structure seems to have been crashing the information store, or at least caused it to dismount the database...and then all the rest of the databases on that server seemed to dismount as well. The "crash" happened multiple times before I killed the export request, and I went back and found out that every time I tried to delete one of the folders using MFCMapi it would also cause the database to dismount-hence why the mailbox "went away" for a few seconds, until the DB was remounted on another DAG member. It was at about this point that the frontliner called back and told me it was okay to just delete his mailbox and restore from backup, which was A-OK by me. So my question to y'all is: has anyone seen that behavior before? Is there a "max folder depth" in Exchange 2010? (I couldn't find one via Google.) A max folder path character count? (Again, I couldn't find one using Google.) And even if there was, is the expected result that "...the database <blah> was stopped" (MSExchangeIS Mailbox Store 9539)? Thanks for any help or cluesticks anyone can provide. Seth Wright James Madison University --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe exchangelist --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe exchangelist
