A user leaving the organization is something that all our customers have to find a method of dealing with. There is no official guidance on the best way to deal with this because it varies depending on the circumstances that you are in. But, since folks keep asking me about the best way to deal with this issue, I thought I would take the time to put up some recommendations and talk about some common scenarios.
There are two primary questions you have to ask when trying to figure out the best way to do this for your organization. First do you want the mailbox to continue receiving email after the person leaves? Second how long do you want to retain the mailbox? Basically the first one is a Yes, No question and the second can be broken down into either a short time period < 30 days or a long time period > 30 days. What we end up with then is four common scenarios we need to deal with.
With Mailflow, Either Short or Long Retention
If you are going to allow email to continue to flow to the mailbox during the retention period then the time of retention is not relevant to our options. This gets us down to only three scenarios we will need to cover.
In this case since the mailbox will still be receiving email we can just leave it in its current physical location. We will want to disable the account in AD so that the user can no longer use the account/mailbox. Also I would recommend moving these accounts to their own OU structure so that you can keep better track of them.
The only gotcha in this scenario is that you need to properly set the MSExchangeMasterAccountSID value otherwise you will end up with 9548 warnings in your application log and NDRs when you send email to the user you just disabled. The following article tells you how to set this value:
319047 You receive a non-delivery report when you send a message to a disabled account
http://support.microsoft.com/default.aspx?scid=kb;EN-US;319047
You will need to develop your own process to track these users and how long they have before you delete their accounts and set their Mailboxes to purge.
In this scenario you can also configure the account to deliver all email to another mailbox or configure another user to access this mailbox. This will assist in transitioning a user's responsibilities over to a new person or group. The best way to do this is thru AD using one of the following articles:
281926 How to configure a mailbox to forward mail to a mail-enabled contact
http://support.microsoft.com/default.aspx?scid=kb;EN-US;281926
268754 How to Assign Users or Groups Full Access to Other User Mailboxes
http://support.microsoft.com/default.aspx?scid=kb;EN-US;268754
Without Mail Flow, Short Retention
This is actually this most simple situation to deal with. In this case the default mailbox retention on information stores is 30 days so if we simply delete the mailbox thru AD. This will prevent the mailbox from receiving email and the mailbox will purge automatically within 30 days. Once the mailbox has been removed from the account you can disable the account until you are ready to delete it from AD.
If at any point during the 30 days you do decide that you need access to the email you can simply reconnect the mailbox to the previous account or any existing account (without a mailbox) this will allow you access to the old email.
274343 How to Recover a Deleted Mailbox in Exchange
http://support.microsoft.com/default.aspx?scid=kb;EN-US;274343
Users sending email to this mailbox will receive an NDR stating that the user does not exist at the organization.
Without Mail Flow, Long Retention
This case crops up most after a customer has already used the first scenario for 30 days or so. After all you don't want to lose a valuable piece of email because the sender got an NDR that the mailbox did not exist.
The recommendation that I make to customers who need to do this is to dedicate a storage group to the long term retention of these mailboxes. This is done because with long term data retention we don't need fast disk we just need a good bit of disk space. So what to do is setup a storage group and place it on a basic disk array with plenty of storage. I would still place the log files on another volume, maybe one shared with another storage group (assuming we are going to be doing our moves at night).
Now we configure the mailbox retention on this database to the value we desire for our environment. We move the mailbox to be retained to this server and then delete the mailbox from AD. This concentrates all of our mailboxes to be retained in one location where we can back them up and manage them and does not incur their space or backup overhead on the other databases.
Conclusion
Once you break things down the actions to take are quite simple and easy to implement. My only other recommendation with this is to make sure your retention and deletion policies are clearly stated and documented to your internal customers. This will help prevent that phone call of "We need to get mail XYZ from user Bob's mailbox but he left the company 2 months ago, do you still have that?"
- Matthew Byrd
