Yesterday afternoon, while troubleshooting an unrelated issue, I noticed that the Application Event Log on one of my Exchange 2010 Mailbox Servers was filling up with errors like this:
Unexpected error “DOC_TOO_HUGE: There are not enough resources to process the document or row” occurred while indexing document.
What? This was a new one on me. And, in a supreme act of lameness, the error does not give the name of the mailbox with the problematic message. Or the folder within that mailbox. Just hex values for various MAPI properties. Poo.
Naturally, I turned to the Font of All Knowledge and Wisdom: Google! Google wasn’t very helpful at first. There was nothing really helpful in Microsoft’s official documentation or in the blogosphere. But I did manage to stumble across a handful of forum posts (such as this one, which was the most helpful), but none really explained what was involved very clearly. Here, I am attempting to rectify that.
It seems that in SP1 Rollup 5, Microsoft added a limit to the number of attachments in a message that the content indexer would attempt to tackle. If the indexer encounters more than 32 attachments on a message, the 9875 event shown above gets thrown. The trick, of course, is to translate those hex MAPI properties to something readable to track down the problematic message. That is where ExFolders comes in.
If you are an Exchange 2010 admin and don’t have ExFolders, what the heck are you waiting for? Go get it now! It is basically pfDAVadmin, rewritten to get around the fact that Ex2010 does not support WebDAV. It is very handy, as you will now see.
Once you have fired up ExFolders, go to the File menu and select Connect. (Much of the interface is the same as pfDAVadmin.) Make sure “Database” is checked, use the second “Select…” button to select the database mentioned in the event log entry, and click “OK.”
Leaving the root of the mailbox database selected (“Mailboxes”), click on the “Tools” menu and select “Export Folder Properties”. In the resulting window, choose “Selected folder and subfolders” and input a path and filename in the “Output file:” field, such as “C:\FolderID.txt”, then scroll down to the “ptagPID: 0x67480014” field and check it. Click “OK.”
What you have just done is instructed ExFolders to generate a text file listing EVERY FOLDER IN EVERY MAILBOX of the database you are looking at. The beauty here, is that the list includes each folder’s folderID (or “FID”) property tag. If you look back at the original Event Log entry, note the item that says “Folder ID”. That is the string you’ll want to search in the output file to tell you which folder in which mailbox is having the problem, including the path to the folder.
Okay, you are halfway there. Now to figure out which MESSAGE in that folder is causing the indexer to choke! Back to ExFolders.
Expand the list of mailboxes under (of all places) “Mailboxes” in the left-hand navigation panel, and find the listing of the problematic mailbox and navigate down to the relevant folder. (It will be somewhere under “Top of Information Store”.) With that folder selected, open the Tools menu and select “Export Item Properties” and specify an output file (such as “C:\MessageID.txt”).
Now, before we go on, we are going to have to do something a little different than last time. The property we are needing isn’t on the list under “Properties to Export,” so we will need to add it. In the text box at the bottom of this window, type in (without the quotes) “ptagMID : 0x674A0014” and click “Add property to list” and click “OK”.
What we have just instructed ExFolders to do is generate a text file containing a list of all items in the folder in question. The list will contain, along with the path and name of each item and a bunch of other metadata, the MessageID (or MID) of each item. Look for the “Message ID” listed in the event log message, and that will tell you which message the indexer is choking on.
In our case, the message was entitled “failure notice” and was from the mailer daemon external to our Exchange system. In fact, there were a lot of messages like that in the Inbox in question. A LOT. With more constantly coming in. As it turns out, the problematic mailbox has a mailbox rule sending a copy of each incoming message to an address external to the Exchange system. And that address went away. So the mailbox was filling with bounces, each containing as an attachment the previous bounce, which had its own attachment, etc. No wonder the poor indexer was confused…..