Periodically over the years, I've run into content problems trying to migrate data to Exchange Online using third-party migration tools--they somehow get stuck, don't like something existing in the destination mailbox (or didn't write it properly in the first place) and you need a clean mailbox to restart the process. You may have other reasons that you want to wipe it, including recycling the ID for another task, terminated employee and want to purge data manually before deleting the mailbox, or you just might be a BOFH.
In any case, it's generally a tedious process, requiring you to either connect to OWA and manually delete folders and messages, remove the Exchange Online license and wait 30 days for the soft deleted mailbox to purge, or connecting an Outlook client, syncing the mailbox, and then deleting everything.
Until now. Because if there's one thing I've learned to do effectively in my life, it's delete things.
To use this script, you'll need:
- Office 365 Tenant (obviously)
- Exchange Web Services API. If you don't have it, the tool will attempt to download and install it automagically. It prefers if it's installed in the default location, but will do a bit of searching if it's not.
- Run Enable-OrganizationCustomization (you'll get a handy error message telling you it hasn't been done)
- ID with the Mailbox Import Export and ApplicationImpersonation roles granted. The script will check to see if your ID has it and grant it, but you'll need to close your Office 365 session and log back in.
If you're asking "Why do I need all of this?" It's simple--Search-Mailbox requires Mailbox Import Export, and EWS requires impersonation. I use both methods because EWS is much faster for getting rid of the folder objects, and then search mailbox is much faster for clearing out the remaining data. If you have a large mailbox and attempt to erase it with only Search-Mailbox, you will be there forever.
After you connect to your Office 365 tenant, the syntax is pretty easy:
.\Wipe-EXOMailbox.ps1 -Identity <emailaddress>
If you haven't run "Enable-OrganizationCustomization" in your tenant, nothing will work. The management roles aren't available until you do, so you should go ahead and run it. I didn't configure it to run automatically, since your organization may require a change control to make edits to your tenant.
If you're clear to run commands in your tenant, you can run Enable-OrganizationCustomization. If you've never run it, here's what it looks like:
Assuming you've passed the first hurdle of having Organization Customization enabled, then the script will check to see if you have the proper role assignments. If you don't, it will try to grant them and prompt you to log back in to your session. You may not have to do it, but I find it a general best practice for success that if you're changing management role group memberships, it's best to log off and log back in so your token can be updated--otherwise, it might not perform as expected.
Now that you've got the right roles assigned, we can continue.
Head on over to the TN gallery to pick up this latest gem.