A lot of thought goes into provisioning and maintaining employees' mailboxes, but little thought typically goes into what to do with those mailboxes after their owners leave the company. Your initial thought might be to delete such mailboxes, but that might not be the best plan—at least not right away. For example, in some cases, immediately hiding the mailbox might be advantageous; in other cases, leaving the mailbox visible but preventing it from receiving new messages might be the best approach.
Maintaining a former employee's mailbox is a good idea for many reasons. The mailbox might contain important messages and documents, so deleting it could erase quotes or proposals related to active projects or important messages that haven't been opened. If the employee organized recurring meetings, associated resources such as conference rooms and equipment are probably reserved for specific time slots. You can't simply transfer the Exchange schedule objects that define the meeting times and resources to another employee; whoever assumes responsibility for the meeting must send new meeting invitations. And most organizations use some type of direct booking or automated resource scheduling, so if the new organizer wants to continue to hold a meeting at the originally scheduled time and use the same resources, the original meeting must first be canceled. If you delete the mailbox, you won't be able to send meeting cancellation notices. In addition, when an employee leaves, you need to let that employee's contacts know that he or she has left the company and tell them who's assuming the employee's responsibilities. Not conveying this information can cause customer- or public-relations problems. Finally, what you decide to do with the mailbox affects system resources.
Nine Exchange configurations and options can help you balance functionality, system stability, and resources when you close out mailboxes. You probably won't use all these configurations when you close out a mailbox. More likely, you'll initially apply a few of them to every mailbox and use some combination of the others as needed to decommission mailboxes over time.
1. Disable, Don't Delete
You need to decide how long to keep closed-out mailboxes online. The version of Exchange you run and how long other people need to access the mailbox content, especially calendars, will factor into your decision. If you run Exchange 2000 Server or later, deleting the Active Directory (AD) account automatically flags the mailbox for deletion and keeps it in the Exchange Store for a period of time referred to as the mailbox recovery window. By default, the mailbox remains in the Store for 30 days after you delete the AD account, but you can change this interval. Although the mailbox is in the Store, it isn't accessible, and you'll need to consider this fact when you determine standard procedures for closing out AD accounts. If other people need to access the mailbox, you'll need to use the Mailbox Recovery Center to disable, not delete, the AD account. As long as the mailbox recovery window hasn't closed, you can still reactivate the account by reassociating it with a new AD account. (For more information about how to reassociate the account, see the Microsoft articles "How to recover or to restore a single mailbox in Exchange Server 2003" at http://support.microsoft.com/?kbid=823176 and "How to Recover or Restore a Single Mailbox in Exchange 2000 Server" at http://support.microsoft.com/?kbid=813337.) This process provides a safety mechanism or buffer for the inevitable last-minute requests to access mailboxes.
Although you can recover a mailbox by reassociating it with a new AD account in Exchange 2000 and later, I recommend that you don't immediately delete the AD account. Microsoft has simplified the process of reassociating a mailbox with a new AD account, but it's still easier to disable the account first, then return later to delete it. I suggest disabling the AD account for 60 days and, when that time is up, deleting the account using the default mailbox recovery window of 30 days. This approach provides ease of access while the organization transitions from the loss of the employee but lets you eventually reclaim the resources. If you want a simple mechanism to keep track of which accounts you need to revisit for deletion, create 12 organizational units (OUs) in AD, one for each month. When you disable an account, move it to the OU for the month in which the account should be deleted. On the last day of each month, delete all accounts in the month's OU. For example, if you disable an account in March and you want to keep the account disabled for 60 days, drag the account to May's OU. Then, on the last day of May, delete all the accounts in that OU. This approach lets you accommodate special situations in which mailboxes need to be kept online longer than the standard window but prevents them from remaining online indefinitely.
If you're running Exchange Server 5.5, deleting the domain account and deleting the mailbox are independent operations. When you delete the domain account, the mailbox remains fully active in the Information Store (IS); you must use the Exchange Server Administrator program to delete it. When you delete the domain account, the mailbox's primary account no longer exists. But any other account that had mailbox permissions can continue to access its content. In addition, Exchange 5.5 doesn't have a recovery window that you can use to reactivate the mailbox after you delete it. If you delete an Exchange 5.5 mailbox, then want to recover its contents, you'll have to restore the entire IS to a recovery server. I generally recommend a 60-day recovery window for Exchange 5.5 environments.
I also use a trick for revisiting Exchange 5.5 mailboxes. Although it isn't as simple as using the AD OUs, it isn't too time-consuming and can even be automated. Create 12 disabled domain accounts, one for each month (e.g., DELEXCH-JAN, DELEXCH-FEB). After you delete the original user's domain account, replace the mailbox's primary Windows NT account with the disabled domain account that represents the month during which you want to delete the mailbox. At the end of each month, you can export the account directory to a .csv file. Search for the accounts that have that month's DELEXCH account set as the primary NT account, then use a .csv file import to delete those mailboxes.
2. Hide the Mailbox and Review Access
Users won't always need immediate access to a closed-out mailbox. If that's the case, hide the mailbox to give the perception that you've deleted the account and to prevent users from using the Global Address List (GAL) to send messages to the account. Hiding the mailbox also makes it a little more difficult for users who have access rights to open it. For example, after you hide a mailbox, users can no longer use the GAL or the automatic name resolution in Outlook to find and open the mailbox by clicking File, Open, Other User's Folder. The hidden mailbox can still be accessed, but doing so requires special knowledge that most users don't have. (Opening a hidden mailbox requires providing the mailbox's distinguished directory name in the /o=organization/ou=Administrative Group or Site/cn=container/cn=mailbox format.) The Microsoft article "XCLN: Mailing to Recipients Hidden from the Address Book" at http://support.microsoft.com/?kbid=142781 describes how to email a hidden recipient; the same concepts apply to the File, Open, Other User's Folder feature.
You should also review delegation assignments and access permissions on the mailbox folders to determine which users might still have access. Consult your security policy to determine whether to remove the permissions. Some organizations leave the decision to the former employee's supervisor; others opt to remove all permissions and regrant access on an as-needed basis.
3. Turn Off Rules
If the former employee configured any rules, disable them. Doing so safeguards against rules that perform functions such as forwarding messages outside your organization. A disgruntled employee might also have maliciously created a rule that, for example, purposely induces a mail loop or message storm. Disabling all rules can save you a lot of grief.
4. Configure Out of Office Notifications
The Out of Office function is probably the best way to communicate that an employee is no longer with the company. It can convey information about why the person left as well as provide new contact information. Out of Office notifications are also useful because they're generated only once for each sender. You might want to develop a standard message for Out of Office notifications that you implement for departed users. If you don't define a standard message, you should have someone review Out of Office messages that employees might have configured before they departed.
5. Change the SMTP Address
Changing an employee's SMTP address has several benefits. First, if you leave the SMTP address intact, the mailbox will continue to accumulate messages that are sent to the address and those messages will occupy storage space. Second, business-related email from outside your organization probably deserves a response, but if your Exchange system doesn't allow Out of Office messages to the Internet, Out of Office notifications won't reach external senders. Mail that's successfully delivered but isn't read can create the perception that your company is unresponsive. If you change the SMTP address, external parties who use the original address will receive a nondelivery notification, which doesn't give them any details about why the address is no longer active but at least lets them know that the mailbox is no longer accepting messages.
Unlike earlier releases, Exchange 2000 and later won't let you remove the SMTP address to prevent Internet mail delivery because the SMTP address is a primary message-routing component. But, like earlier releases, Exchange 2000 and later let you change the SMTP address that's designated as the primary address. Defining a new primary SMTP address maintains internal routing but effectively blocks message reception to the old address. When you change the primary address, make sure that you clear the Automatically update e-mail addresses based on recipient policy option, which is located on the Email Addresses property page of the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in. If you don't clear this option, the Recipient Update Service (RUS) will eventually recreate the address you just removed.
6. Disassociate DLs
If you're concerned about storage space and don't want the account to receive messages, I recommend removing the account from distribution list (DL) memberships. But if you use dynamic DLs, completely stopping mail delivery can be difficult.
Dynamic DLs use a Lightweight Directory Access Protocol (LDAP) query to determine which mailboxes receive messages. If you want to stop delivery to a mailbox that would typically be a member of the dynamic DL, you'd need to define the LDAP query to exclude disabled mailboxes. I'm not aware of any way to do this that's based on the AD account's disabled state, so you'd need to add some type of flag to the disabled account and modify the dynamic DL's LDAP query to check for that flag. For example, if the dynamic DL's query selects members according to the Department field, you'd need to add a second condition to exclude objects from the list as Figure 1 shows. In this example, when DISUSER is added to the Notes field of an AD account, the object is excluded from the dynamic DL; otherwise, it's included. Unless your environment makes heavy use of dynamic DLs or those DLs typically receive large messages, trying to stop delivery via dynamic DLs usually isn't worth the effort.
7. Stop All Mail
To prevent the mailbox from accumulating new messages, assign an empty DL as the alternate recipient for the mailbox. You can use the Active Directory Users and Computers snap-in to define a forwarding address from the account's Exchange General tab. In Exchange 5.5 environments, you can use the mailbox's Delivery Options tab to define an alternate recipient address. Create a DL that has no members (NULL-DELIVERY, as Figure 2 shows), and use Delivery Options to assign it. This alternate recipient address prevents mail from accumulating in the mailbox because the Message Transfer Agent (MTA) discards messages that are sent to empty DLs.
Two other frequently used techniques involve using the Active Directory Users and Computers snap-in's Exchange tabs to set the account's receive quotas and delivery restrictions so that the MTA can't deliver messages to the mailbox unless the sender is authorized. When someone sends a message to the mailbox, the message is returned with a nondelivery report (NDR), as Figure 3 shows. These two options prevent the account from using additional storage and let senders know that the message wasn't delivered, but they have some drawbacks. The NDR doesn't convey the reason the account no longer accepts mail. Furthermore, because these techniques don't route messages to the mailbox, Out of Office notifications won't work with them.
8. Save the Mailbox Contents
Eventually you'll need to delete the mailbox from the Exchange Store. But before you do, I recommend that you use the ExMerge program that's in the Microsoft Exchange Server Resource Kit to save the contents of the mailbox to a .pst file, which provides one more level of recoverability if you need to access the mailbox contents later. The .pst file also covers you if you're required to preserve email as an official record.
9. Deal with Legacy Delivery
When you finally remove the mailbox from the Exchange server (or sooner, if you remove the primary SMTP address), you might find that message transport resources incur increased traffic. That traffic increase occurs because the system has to generate and deliver an NDR email message in response to every message someone sends to the legacy SMTP address. If you're running Exchange Server 2003, configuring recipient filtering is a simple and easy way to block messages sent to legacy addresses over the Internet.
Using the MMC Exchange System Manager (ESM) snap-in, open Global Settings, Message Delivery. On the Recipient Filtering tab, select Filter recipients who are not in the directory. For each SMTP virtual server that you want to accept inbound SMTP mail, click Advanced on the General tab, click Edit to display the IP Identification options, then select Recipient Filtering. Click OK, then stop and restart the SMTP virtual server. The next time someone sends an email message to the legacy address, the SMTP virtual server will query AD to check the address. When it finds the address, the recipient is accepted; if it doesn't find the address, the recipient is rejected.
Figure 4 shows an SMTP session that uses recipient filtering. As you can see, the server found the Jacob address in AD and accepted that message with a 250 2.1.5 response code. But the server didn't find the George and Jonas addresses and returned different SMTP response codes that reflect why the message was rejected. However, recipient filtering can be risky. An attacker can exploit the response codes during a directory-harvesting attack to learn which accounts are in your AD.
Two other options achieve similar results without exposing you to a directory-harvesting attack. First, you can specify individual addresses on the Recipient Filtering property page. When the SMTP virtual server processes a recipient address, it checks this list and rejects any matching addresses with a 550 5.7.1 response code, as Figure 4 shows. Second, you can add the legacy SMTP address as an alias for the NULL-DELIVERY empty DL. When a message is addressed, the list expansion doesn't yield any members and the MTA drops the message. Because the address is valid, the sender receives a response code indicating that the address was accepted, so an NDR isn't generated. This solution also works for Exchange 5.5 environments, which don't have recipient-filtering capabilities. When you use the NULL-DELIVERY aliasing technique, however, you can add only a finite number of aliases. In an AD environment, this number is about 800. If you have a lot of legacy addresses, when you reach the maximum you'll need to create additional empty DLs.
I prefer the NULL-DELIVERY option because attackers can't use it to gather information about your environment. In addition, if you ever want to reuse the legacy address, recipient filtering can cause delivery problems that can be difficult to track down. For example, if you add [email protected] to recipient filtering and sometime later you hire someone with the same name and create a bill.smith account, the RUS will stamp the account with the [email protected] address. Because of the recipient filter, this account won't be able to receive any Internet mail, and troubleshooting might not quickly identify the recipient filter as the culprit. If you add [email protected] as an alias, the RUS can't use it for the new account and will instead create a [email protected] address for the account. Because these techniques require quite a bit of work to administer, you'll probably want to use recipient filtering or NULL-DELIVERY aliasing only for the most problematic and extreme cases.
Tradeoffs and Balance
When an employee leaves the company, you have to consider many email-related concerns. On one hand, you don't want to keep a mailbox online if someone else can use its storage resources. On the other hand, you might want to keep the mailbox online to access content and easily notify people that the account holder has left the company. But you don't want the mailbox to use additional resources as it accumulates new mail or the system bounces a lot of undeliverable mail. I hope I've given you a few ideas about how you can accommodate all these concerns to meet business needs while keeping your Exchange servers running smoothly.
