Most Exchange admins remember the day they learned the difference between disabling a mailbox, and removing a mailbox. The vast majority learn that lesson the hard way.
To clarify for those of you who are yet to experience this particular scenario, Exchange offers two ways to “get rid of” a mailbox; disabling it, and removing/deleting it. Presented with those two options, inexperienced admins tend to choose remove/delete, because naturally they want to delete the mailbox. At face value, “disabling” sounds more like disabling a user account (i.e. it still exists, but can’t be logged on to).
It catches people out all the time, like this latest victim on Reddit:
I’ve written about this before, and regularly tweet the tip to try and educate the community and minimize the number of victims in the future. I’m not the only one; there’s blog posts in the top results on Google going back to 2008 about this.
It was only this week that I realized that Microsoft isn’t exactly helping with this issue at the moment. I tend to do my administration in PowerShell, so if I were to make the mistake of trying to remove a mailbox (by running Remove-Mailbox), I get a warning that describes what is about to happen. It’s then quite fairly my own fault for ignoring the warning and proceeding with deleting the mailbox and the Active Directory user object.
I almost never do it in the Exchange Admin Center, so when I tried it this week I was surprised to find two things. First, the visible option is the destructive one, deleting the mailbox and AD user object. The less destructive option, of merely removing the mail attributes from the user and marking the mailbox for deletion, is hidden under a menu.
The second is the lack of warning that appears.
Yes, that is a warning asking if you really want to continue. Of course you want to continue, it’s not like the warning is giving you any reason to reconsider your actions. Unlike the PowerShell cmdlet, which tells you exactly what’s about to happen.
Removing the mailbox “mailbox name” will remove the Active Directory user object and mark the mailbox and the archive (if present) in the database for removal.
There’s an obvious solution to this mess, which is by now a 10 year old problem (since the release of Exchange 2007).
- Add the same warning to the EAC dialog as is displayed in PowerShell
- Change the buttons in the EAC so the non-destructive action is visible, and the destructive action is hidden in the menu
Now if you happen to find yourself learning this lesson the hard way, all is not lost. Don’t panic and start troubleblasting, as some people do (taking risky actions such as rolling back a domain controller to a previous backup).
If you’ve got the Active Directory recycle bin enabled (which you should, unless you have a specific reason not to), you can recover the deleted user. Even if you don’t, you can quickly recreate the user account and then reconnect the disabled mailbox to the new user. It won’t be entirely perfect (there’ll be extra steps like re-adding them to groups, re-assigning permissions they previously had, and fixing the X500 address issue), but at least you haven’t lost any data.
In the meantime, we’ll be adding a test to Exchange Analyzer to check whether the recycle bin is enabled, and whether your databases have a suitable retention period configured so that mistakes can be undone.
Exchange is stored in configuration partition and not application partition.
This would cause the mailbox deletion to delete associated user in AD.
Why do people disable their mailbox but keep number active
Couldn’t agree more! Hopefully in Exchange 2016 (haven’t tried it out yet) they fix this.
Regarding AD restores: I always enable AD Recycle Bin when I discover it is not enabled. I can’t think of any reason not to. Saved my skin once or twice and if enabled, it would have saved David Moore a lot of time. Far easier than doing an AD Authoritative Restore.
Regarding the PS cmdlets: I want PS to be powerful. I want the GUI for common administrative tasks and PS for advanced tasks. When I want to delete a whole OU with thousands of users and mailboxes, after a migration or company split or for whatever any reason, I just want to be able to. Besides, in the Linux world it is exactly the same. You can run commands that can wipe entire drives if not careful. (I am a Microsoft man btw)
In my opinion it makes pure common sense to NEVER EVER run code in production that is neither tested nor understood. Doing otherwise is poor system administration.
I think the confusion started with the change of languge used from Exchange 2003 to exchange 2007. The process now known as disable-mailbox was in exchange 2003 known as ‘delete mailbox’
I couldn’t agree more, I had a customer that deleted 50 users before they understood what was being done, we had restore active directory and and that was a problem as well as active directory was replicated and the replication just kept deleting the users off.
I agree with your sentiment. I offer one way to keep from getting bit:
1) Create a new role that is patterned after “Mail Recipient Creation” but prohibits mailbox deletion and the deletion of MailUsers.
2) Create a new rolegroup that is patterned after “Organization Management”. In this rolegroup, remove this role: “Mail Recipient Creation” and add the role you created in 1) above.
3) Remove all your admins from the “Organization Management” rolegroup.
4) Add all your admins to the new rolegroup specified in 2) above.
Now, the EAC UI will not allow your admins to delete mailboxes (or MailUsers). Also, your admins will not be able to use the remove-mailbox cmdlet in Powershell either.
At our shop, our admins are not supposed to “create mailboxes” either; we only “enable” them. So, in our shop, we removed the ability to “create” mailboxes as well as “delete” them. The technique is the same.
Yep. Been there, familiar feeling. It was extremely embarrassing when I asked the admin, “Hey, I logged on last nigh, now I can’t. Did you change my password?” – only to remember that the night before at midnight, tired and in a rush, I “removed” my test mailbox as opposed to “disable” it. The embarrassment was even greater given that I’m a long-running Exchange certified professional.
Remove-Mailbox should do exactly that: remove the “mailbox”. Not the AD account. Epic failure on the part who named the cmdlets.
I want to go one step further: EAC should NEVER delete an AD user object. There should be only the option, to “delete” (disable) the mailbox without any further action with the AD object itself. Deleting the mailbox and the AD object should be only possible via powershell (like many other potentially harmful operations).
Couldn’t agree more, and in full agreement with Peter Nagel above. However I wouldn’t allow this via (Exchange) PS either. Problem with PS is many ‘admins’ are just copy/pasting commands found online without looking through what the command will do or, in an alarming number of cases, actually understand what is in the pasted command-line…
Agree, it doesn’t seem appropriate or necessary for Exchange to be able to delete an AD user from the UI. It is easy enough to add ADUC to the server if necessary.
Hear, hear! If we are in a console specifically dedicated to managing Exchange and Exchange mailboxes — “Delete” should only delete the mailbox!
I may be wrong, but I really don’t think Microsoft developers have ever actually worked in day-to-day operations (nor spent much time talking to the folks who do).