I often share real world examples of problems or scenarios that you might encounter with Microsoft Exchange Server, and how to avoid or resolve them.
In this article I want to share one such example that happened to me under a specific set of conditions.
The scenario begins with a mailbox migration project, in which I encountered a very large mailbox. The mailbox was too large to move without risking filling up the transaction log volume on the destination server. So I tracked down an owner of the mailbox to discuss options for removing some of the older items.
As it turns out they didn’t really need to keep any of the items in that mailbox that were older than about 30 days. So more than 2 years and 300,000 items in there were not required. We agreed to delete everything older than 6 months, just to be safe.
Side Note – keep an eye on your “large mailboxes” reports and you’ll often find these generic mailboxes that get set up as a place to catch copies of email “just in case” it is needed some time in the future. Often it isn’t.
So my next task was to delete the email content that was no longer needed. I considered using the Exchange 2007 Export-Mailbox cmdlet for this task, but decided to just use Outlook instead since I was already planning to use Outlook to take a look at some of the items before I deleted them.
I logged into a Citrix desktop, launched Outlook, and added the mailbox as a secondary mailbox. I had decided to use Outlook in a Citrix desktop because I expected it to hang for long periods of time as it enumerated or deleted the thousands of items I would be handling, and wanted to keep using Outlook on my laptop as normal.
So over the course of about two days in between other daily tasks I performed Outlook searches based on date ranges, and deleted the items in blocks of about 10,000 messages at a time. It is important to note at this stage that I was using Advanced Find to search the secondary mailbox.
After doing a search based on received date (ie, I started with the oldest mail and worked my way forward month by month) I would then select all the email that appeared in the results and delete them.
When you delete an email from a secondary mailbox it often gets moved to your own mailbox’s Deleted Items. However when you delete an email from a secondary mailbox via an Advanced Find dialog, it often goes into the Deleted Items of the secondary mailbox.
I say “often” because in at least one test the mail went to the Deleted Items of the primary mailbox, but in every other test it went to the secondary mailbox. It may be that Outlook behaves inconsistently in this situation, or that one test was different in some way that I can’t recall now.
As I said earlier I deleted around 2 years worth of unwanted email from the mailbox, in blocks of about 10,000 messages. When I had deleted everything up to the cut off date I’d agreed to with the mailbox owner I went ahead and simply emptied the Deleted Items of the secondary mailbox.
Job done. My plan was to wait for the deleted items to purge from the database itself overnight and then schedule a time to move what was now a much smaller mailbox.
A relevant bit of information at this point is that all of the email I deleted from the mailbox, and then emptied from the Deleted Items, was actually unread email. Nobody ever read these emails, they were there “just in case”.
That fact sprang immediately into my mind when about an hour later I was speaking with an external party who had received an email from our server that read something like this:
Subject: Not read: [subject line of original email]
From: [the large mailbox I’d been cleaning up]
Date: [right about the same time I emptied the Deleted Items]
I quickly learned that the person I was speaking to, when they originally sent their email to our server, had requested a read receipt.
The email had sat in the mailbox for several months unread, and then I came along and deleted it. The Exchange Server then honoured the receipt request, and sent the original sender the “Not read” message.
I had just deleted slightly over 150,000 email messages from that mailbox. How many of them had requested read receipts?
I ran message tracking log searches of the Hub Transport servers and got my first answer – a lot.
I dumped the log data to a file and filtered it a few different ways to discover that:
- About 24,368 “Not read” read receipts had been generated (based on unique message ID)
- They had gone out to about 1200 unique external email addresses
The horse had well and truly bolted on this one, and my team leader started calling and emailing different customer service teams to give them a heads up in case they received calls from confused people about a sudden burst of “Not read” emails. Meanwhile I started digging into the technical side of things to try and find out what had gone wrong, and more importantly how we could avoid this happening again.
After quite a bit of testing here is what I have determined so far.
When permanently deleting an unread item by emptying the Deleted Items of a secondary mailbox Outlook 2003, even if configured to prompt for sending of read receipts, will not warn or prompt the user and a “Not read” message will be generated to the original sender.
When permanently deleting an unread item by emptying the Deleted Items of a secondary mailbox Outlook 2007, if configured to prompt for sending of read receipts, will display a dialog box asking if the receipt should be sent.
If Outlook 2007 is configured to never prompt, and to always send read receipts, a receipt will be generated to the original sender as with Outlook 2003.
If Outlook 2007 is configured to never send a response, then no receipt is generated to the original sender.
Exchange Management Shell
So what about if I had gone with my original thought to use the Export-Mailbox cmdlet to do the job? It certainly would have taken less time to delete all of the email, but what about the “Not read” receipts?
As it turns out, according to my testing, the Export-Mailbox cmdlet will in fact cause a “Not read” receipt to be generated if it deletes an item that is unread and for which the original sender requested a read receipt.
So had I gone with my original thought it would have had the same outcome as the manual process I used instead.
In fact the only scenario in which the receipts would not have been generated is if I had used Outlook 2007 (our Citrix desktops still run Outlook 2003 unfortunately) and had first checked that the tracking options were set to “Never send a response”.
I’m curious whether the receipts would have been generated if I had used Export-Mailbox to export to PST first, and then simply deleted the PST file. That is something I still need to test.
I also have not tested Outlook 2010 though I suspect it will be the same as Outlook 2007.
The lessons I took away from this incident were:
- Watch for creation of these types of “just in case” mailboxes that aren’t actually required
- When they are required, make sure a maintenance routine is in place to manage their size
- If using Outlook to delete bulk unread items, check first that read receipts are turned off in the tracking options