How to deal with users leaving the Organization
Published Feb 17 2006 01:09 PM 28.3K Views

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

20 Comments
Not applicable
Another method: if you're wanting to archive email from someone who was a key employee and want to free up database space is to Exmerge that mailbox to a PST and dump it to a CD or DVD or Tape.
Not applicable
Some things to consider;

1. Often the Team or Manager of the person that has left the company will want to be able to reply to emails sent to them.

2. Does your company require any special HR or Legal approval before you grant access or delete a mailbox perm?

3. Was the Terminated User really just going on Medical Leave, Military Leave, Admin Leave, Maturity Leave, etc?
Perhaps they will be coming back soon and want to access their old email.

Not tech related stuff but can be very important and makes the mailbox removal process more complicated.
Not applicable
Another idea...instead of disabling the account and setting the MSExchangeMasterAccountSID attribute, we just disable logon for all hours. So, the account can't be logged into at any time, but mailflow still works.
Not applicable
how do you handle re-occuring meetings that a person who has left the company organized? when the mailbox is deleted - does it clean up all of this additional bits of data, reoccuring meeting rooms booked, delegates to other calendars, etc?
Not applicable
Great article for those who didnt know how to address some of these.
Not applicable
I almost missed the weekend, but gladly I made it on time&amp;nbsp;;-)

Rivals Take Aim at RIM
Microsoft...
Not applicable
One way we do on my organization, is to remove all permissions and groups from the user, and on logon to (in account options) only permit that the user connects on the fron-end server.
So he can get his email only by web or in the front-end server.
This situation is when the end of job is friendly by both parties.
So the user can check his email more one month..
Not applicable
You also have the possibility to export mailbox data to a PST and transfer departed user's addresses to someone else (someone taking over the user's job for example). Just don't forget to have the legacyExchangeDN of the original user added as a secondary to his successor.

This is easily scriptable 8)
Not applicable
Here's another method - use a real nearline archive so you can stack the email for that user on some cheap storage but provision access to search a full-text index for it; like VERITAS Enterprise Vault, now from Symantec.

** Disclaimer, yes I work for Symantec, and I have also used this solution as a customer and I really believe it is a great way for Exchange Admins. ***
Not applicable
In Response to the question by Kristina on dealing with users that have organized reoccuring meetings.

    When the user is removed it will end up ophaning the original meeting.  So it is best to remove all reoccuring meetings from the organizers calendar and send updates that they have been removed prior to deleting the mailbox.

Also it was brought to my attention that I should mention something about users leaving the company under less than amiacable terms.  

If that is ever the case please make sure that you purge all rules for that user after they leave the company.  Otherwise they could have setup a rule to forward all of their email to an external address.

-Matthew Byrd

Not applicable
Also, instead of disabling the account, we use the "Account Expires" option. Mail still flows, no 9548 errors, plus it gives us a date when the account was disabled.
Not applicable
Why is Symantec allowed to spam on here but others aren't?

What you describe is acheiveable already through PST archival, previously mentioned.
Not applicable
indy,

As a general rule, we do not delete comments, even if they mention a 3rd party solution (if it pertains to the subject discussed). It's a tough call - balancing the content on the blog without becoming an advertising billboard... if a comment is a link for some product, or is a "comment spam" - I'll delete it, sure. Please use the Suggestions link if you'd like to discuss this more so we can take it "offline". :)
Not applicable
Question is particular to mail rentetion and our 90 day deletion policy. We noticed that if the mail is moved around it will never get deleted by teh policy thus circumventing the policy. Is it possible to create a policy that is based on mail create date vs. last modify date?

Thanks,
Charles Morin
Not applicable
Hi Charles,

I am assuming that you are talking about Mailbox Retention Policies.

The behavior you describe is the expected behavior.  In Exchange 2k and Exchange 2k3 we will not remove an item with mailbox retention if its modified date is within the retention range.  If you have users that are clearly moving their mail from folder to folder in order to "avoid" the retetion policy this is and HR matter (not following company policy) and should be addressed as such.

There is some tuning that can be done to this behavior but that article is not publicly avalible and will require you to open a support incident or have a premier contact.

-Matt

Not applicable
I actually sent a query to you guys regarding this matter. Maybe this blog is in reponse to that ...

However, the issue of how to deal with mail being delivered when the account is disabled has not been addressed! Stating the following doesn't help much:

  "The following article tells you how to set this value"

I think that any Exchange admin should know this info already or cn find it as indicated. However the problem isn't how to fix the problem when you're notified about it, it is how to determine when it has happened.

In any organisation of a certain size or larger the Exchange admin is probably a different person to the one who disabled the user account. That doesn't even consider the fact that maybe it is an automated system that when HR mark the employee as left the organisation the account is disabled. What about accounts being disabled due to a policy for extended leave or even disabled by over eager admins by mistake?

So you get the situation of corporate email working fine. Important info flowing into users mail ok. User is disabled (for any reason). Mail stops flowing. Time passes. Sometime much later event log entry found/admin notified of bounce message/process informs admin of disabled account. Knowledge base article followed to enable mail to flow into disabled user's mailbox.

Why can't it be a global setting to say on/off "Mail flows to disabled account mailboxes"?

What solution do you propose for determining when the account is disabled and automatically setting the MSExchangeMasterAccountSID value?

-Kevin
Not applicable
Cuando un empleado deja la empresa, siempre hay complicaciones referentes a que hacer con sus mensajes de correo electr&#243;nico. Unas recomendaciones del equipo de Exchange.
Not applicable
Hi Kevin,

In response to your comments the proper way to resolve this issue currently is to ensure that what ever person or script in your environment is disabling users follows the steps as outlined in http://support.microsoft.com/kb/278966
to ensure that the account is properly disable both from and Exchange and Windows stand point.  Yes this adds addtional over head to the process.  But currently we have no other solution avalible that will ensure that users are disable in a manner that Exchange does not complain about.

The only other options that I can offer is a utility called Nomas.  You will need to contact Microsoft Support in order to get the utility but it will read your domain and correct any and all users that are in this condition.

The following link can provide you with more inforamtion:
http://support.microsoft.com/kb/555410/en-us

-Matt
Not applicable
I think this entry was a great cover combined with the nomas and AAA.  Today I had something weird happen and thought this would be the place to post it.  When a user leaves the company we set their e-mail to forward to their manager and we then hide the mailbox from the GAL and then run the nomas tool to resolve the MSExchangeMasterAccountSID error.  Well today I needed to update a meeting that had a terminated employee so I removed her from the meeting and set the update out.  Well of course it updated meeting can to me because her e-mail is being forwarded to me.  Well without me having to do anything, it removed my entry off my calendar because it saw a cancel meeting request which was for her.  What a great bug!  Any ideas?
Not applicable
Hi Robert,

That is quite an interesting result.  But if both you and the disabled employe were in the same meeting then I am not very suprised at this outcome.  You have to remember that outlooks deals with things by IDs and not by names, subjects, or other variables.  So if your outlook was configured to automatically deal with meeting requests and this person was a member of the same meeting; then as far as outlook is concerned your recieved a meeting cancelation notice with the same ID as an existing meeting ... thus it was processed.

I would say that this behavior is by design.

-Matt
Version history
Last update:
‎Jul 01 2019 03:11 PM
Updated by: