SOLVED

Inadvertently hard deleted a mailbox?

Copper Contributor

Greetings kind folks,

 

The initial objective was to activate a litigation hold on a mailbox, but since the mailbox was in a softdeleted state, I went this way:

 

https://technet.microsoft.com/en-us/library/mt761731(v=exchg.150).aspx

 

 

I ended up successfully enabling an in-place hold, and only moments later did I realize that what I really wanted was a litigation hold (looking retrospectively, I should have just kept the in-place hold as it was and go about my business ), so I went ahead and canceled the in-place hold and deleted the mailbox search. 

 

The sad reality is that now the mailbox seems to be neither softdeleted or inactive...just nowhere to be found.

 

I now realize that I should have just kept it simple by reactivating the account, and subsequently the mailbox would become active again and it would just be necessary to enable the litigation hold. ( Set-Mailbox %emailaddress% -LitigationHoldEnabled $true)

 

Should I register a ticket with Microsoft?

 

If I export a list of all the inactive and softdeleted mailboxes on my tenant, will somehow the affected mailbox show up to be "orphaned" somehow?

 

Any ideias are welcome, many thanks to anyone who can share their opinion on this.

20 Replies
Unless you had a preservation policy set then I would immediately get a ticket in to Microsoft to see about getting that mailbox pulled.

I also thought that would be my only resort. Thanks!

Quick update: turns out MS support was quite useless in this matter. They told me to follow a scripted guide and quite simply if the mailbox was not found in a softdeleted state there was nothing they could do.

May this serve as a hard learned lesson for me, and a heads up for anyone who is reading this in the future..

best response confirmed by Ivan Barros (Copper Contributor)
Solution

Unfortunately, once you released the hold that was keeping your mailbox in an inactive state, you made it eligible for hard deletion (permanent and irrecoverable removal). It's impossible for Microsoft support to say when a mailbox will disappear because that depends on background processes running on the mailbox server where the active copy of the database holding the mailbox is. I am afraid you are toast. Or rather, your mailbox has made its way to the great byte wastebasket in the sky...

Thanks Tony.

It´s heartbreaking information for me, but still a much appreciated insight.

 

Best regards.

I recommend setting up a preservation policy, so that e-mail stays regardless of deleting users etc. I got mine set for 7 years or what not and is kind of a CYA.

Yes I briefly researched on that subject upon reading your reply, appreciated.

How would those policies differ from an inactive mailboxes approach?

What´s your hands-on experience on this?

 

Thanks!

Simple.

 

Preservation policies (https://support.office.com/en-us/article/overview-of-preservation-policies-9c3b1d52-40ce-4ba3-a520-9...) or retention policies (https://support.office.com/en-us/article/overview-of-retention-policies-5e377752-700d-4870-9b6d-12bf...) help organizations keep information for a defined period (for example, "keep all messages in these mailboxes for seven years").

 

I don't think they would have helped here because policies only apply to licensed mailboxes. Once you make a mailbox inactive by placing a hold on it before deleting its account, you remove the need for the mailbox to be licensed. 

It should still retain the mailbox regardless, long as the account was licensed at some point when it created preservation. So the hold would have taken place after the policy was already on the mailbox so it should have still been preserved unless force deleted.

... Only if a preservation lock is in place.

 

The vast majority of retention policies do not use preservation locks. In fact, you can only set a preservation lock through PowerShell.

Well I know the mailboxes don't require a license to keep the preservation going, because I use this for off-boarding preservation, however if a Hold overwrites then removes this I don't know any better to that one for sure, but I wouldn't think it would? Something I guess I could test out. If that is the case and you know, then I'll take your word for it :).

If you have a hold in force because an Office 365 retention policy is active on a mailbox and you delete the owning account, then the messages won't be removed because the mailbox is made inactive. Maybe that's what you're thinking.

 

Let's not talk about preservation policies in any case -- the name is "retention policies." Two types exist inside the service. Office 365 retention policies apply to mailboxes, sites, and OneDrive accounts - and Teams (in their own policies - https://www.petri.com/teams-supports-office-365-retention-policies). Mailbox retention policies only exist for mailboxes. The big difference between the two is that Office 365 retention policies apply an in-place hold to keep data for a set period.

 

To see what holds exist for inactive mailboxes, use the command:

PS C:\temp> get-mailbox -InactiveMailboxOnly | ft displayname, inplaceholds

DisplayName                                  InPlaceHolds
-----------                                  ------------
Holly Holt                                   {}
Emma Robinson                                {}
Mobile Table                                 {}
Frank Clonan                                 {}
James Gangley                                {mbx29550d04cffd42109bdd94cc56c65041:2}
Jodie Smith (Program Manager)                {}
Rob Young                                    {d9eb7052cc0f4200b6a1ad0d6f2171ed...}
Mary Smith (Customer Support)                {}
Ed Banti                                     {skp748f77b020124e6e8304e66021fb297b:3}
Jack Healy                                   {}
Legal Discovery                              {}
Luka Abrus (Sales)                           {}
Eoin Redmond                                 {}
Tom Perham                                   {UniH4001d1c2-9438-4e46-9d14-80207a8099e9}
David Keane (Inactive - under in-place hold) {UniH4001d1c2-9438-4e46-9d14-80207a8099e9}
Donald Vickers                               {}
Office 365 for IT Pros eBook Feedback        {}
David Pelton (Sales)                         {UniH4001d1c2-9438-4e46-9d14-80207a8099e9...}
Michael Van Horenbeeck (Book Author)         {UniH4001d1c2-9438-4e46-9d14-80207a8099e9}
Michael Harty                                {}
Journal Mailbox                              {}
Jill Smith                                   {d9eb7052cc0f4200b6a1ad0d6f2171ed...}
Dylan Webb                                   {}
Steve Smith                                  {UniH4001d1c2-9438-4e46-9d14-80207a8099e9}
Sanjay Ramaswamy                             {UniH96ac23b0-0fe9-45a3-b070-0966d8418afd}
Sonoma Conference Room                       {}
Andrew Higginbotham (Author)                 {}
Brian Jones                                  {UniH1f53db1f-bb22-4748-bdad-192ff63e41c2}
Conor Redmond                                {}

These are "non-org-wide retention policies. Others can exist org-wide.. The holds prefixed with mbx in this output are org-wide mailbox holds.

 

PS C:\temp> Get-OrganizationConfig | Select -ExpandProperty InPlaceHolds
grp29550d04cffd42109bdd94cc56c65041:2
mbx15382841af9f497c83f9efe73e51888d:1
mbx9696959111f74ecda8a40aef97edd2c2:1
mbx703105e3b8804a1093bb5cb777638ea8:1
grp703105e3b8804a1093bb5cb777638ea8:1
mbxc1e2d6f1785d4bf8a7746a26e58e5f66:1
grpc1e2d6f1785d4bf8a7746a26e58e5f66:1
mbxf6a1654abdba4712a43c354e28a4d56c:2
grpf6a1654abdba4712a43c354e28a4d56c:2
makes sense. Thanks for the enlightenment!

Not blowing my own trumpet or anything, but Chapter 19 of "Office 365 for IT Pros" explains in detail how to interpret the holds that exist on a mailbox (including inactive mailboxes) so that you can trace back and find out what retention policy or in-place hold (set by an eDiscovery case) exists for any mailbox.

 

Office 365 for IT Pros

I must confess I was already aware of your trumpet.

Was also seriously considering it´s purchase in the near future, this wouldn´t probably happened if I previously had access to it.

Well, as to seriously considering my trumpet, like any book you can say that information is freely available on the web. We would say that a book is a curated collection of information gathered from many sources, including the results of our own investigations. As such, it doesn't exist on the internet. We also keep the material up to date, which is kind of important when it comes to Office 365 and the way that it changes on an ongoing basis. We calculate that the total cost of the book is around 24 minutes of a consultant's daily charge (at $1,000/day). We think that you'll get a lot more out of the book than you can get from 24 minutes of a consultant's time, especially when that person is unlikely to be able to cover all of Office 365...

UPDATE!

 

After re-licensing the user, the mailbox came back to life!

I´m still astonished on this (I had really given up hope), but it seems somehow the mailbox information was kept either on the cloud, or on the onprem exchange server.

It´s a hybrid enviroment, I forgot to mention that! A crucial piece of information, it seems?

 

Regards!

 

 

I think you've just illustrated the problems of trying to debug problems in a forum like this. Without being able to run PowerShell inside your tenant, it's hard to form a full picture of what's going on.

 

Deleted mailboxes are kept in a soft-deleted state for 30 days. During this time they can be automatically reattached to an account if you assign that account an Exchange Online license. It looks as if the mailbox was not deleted recently, so it was available to be reattached (GUIDs connect the mailbox to the account). It's kind of interesting that Microsoft support wasn't able to find this.

But you said you checked -softdelete flag for mailbox? Anyway. That’s good to hear!
1 best response

Accepted Solutions
best response confirmed by Ivan Barros (Copper Contributor)
Solution

Unfortunately, once you released the hold that was keeping your mailbox in an inactive state, you made it eligible for hard deletion (permanent and irrecoverable removal). It's impossible for Microsoft support to say when a mailbox will disappear because that depends on background processes running on the mailbox server where the active copy of the database holding the mailbox is. I am afraid you are toast. Or rather, your mailbox has made its way to the great byte wastebasket in the sky...

View solution in original post