Search-Mailbox is no longer available in Exchange Online

After being away for a while (attending the Microsoft MVP Summit in Seattle and some additional traveling), I come bearing sad news. The beloved Search-Mailbox cmdlet, easily one of my favorite bits of code in Exchange, is no longer available in any of my Microsoft 365 tenants. A sad day 🙁

Microsoft did warn us about this. Few times actually, though the community managed to change their mind when they initially tried to remove the cmdlet few years back. In a Message Center post dated Jan 4th, another announcement was made, with end of March 2024 being positioned as the deadline. As with any previous attempts to remove the cmdlet, the feedback received from the MVP community on said message center post was overwhelmingly negative, with many of us pointing various scenarios for which the Search-Mailbox cmdlet was the only viable option for. Unfortunately, Microsoft only sees the cmdlet as useful for eDiscovery it seems, and insists that suitable replacements exists.

It is true that the Search-Mailbox cmdlet is dated and hasn’t been updated in years, thus it does not address many of the improvements made on the eDiscovery/Compliance search front within Microsoft 365. One such example is the ability to scope a search to just items within a given folder, also known as targeted collection. Still, any Exchange admin will tell you that use of the cmdlet goes way beyond the eDiscovery scenario, but for some reason, Microsoft seems to completely ignore any talk on additional use cases. Of which there are quite a few. Here are some of the most common ones, for me:

• Cleaning up mailboxes – Nothing beats the Search-Mailbox cmdlet when it comes to performing bulk deletion operations against mailbox items. Bear in mind, there can be many different reasons why bulk delete is needed, and not necessarily limited to incident response. Microsoft’s proposed replacement here is the New-ComplianceSearchAction cmdlet, which remains limited to processing maximum of 10 items per run. A Roadmap item was recently published, informing us about a planned increase of said limit to 100… which is still peanuts.
  
  Yes, there are other methods to use for such scenarios, such as EWS-based or Graph-based script. With EWS being on a deprecation path and the Graph still not offering any meaningful way to list all mailboxes, I would argue those are not as viable as you might think. Not to mention they require some dev experience, whereas almost everyone can run a simple cmdlet.
• Cleaning up Recoverable Items – Technically part of the above scenario, targeting only the content of the RecoverableItems subtree. You’d be surprised how often people run into troubles with overflowing “dumpster”. The Search-Mailbox cmdlet is the only method that allows you to limit the operation(s) to just the RecoverableItems subtree, by means of using the –SearchDumpsterOnly switch. All “replacements” will include the entire content of the mailbox (unless you go over the trouble of scoping targeted collection). More importantly, given the size and number of items usually found within the RecoverableItems subtree, there is no adequate replacement here!
  
  In all fairness, some scenarios might be addressable by the set of *-RecoverableItems cmdlets, which got introduced a while back. Some, not all.To finish up on the RecoverableItems scenarios, the Search-Mailbox cmdlet is the only method that allows you to also exclude content from said subtree, by means of using the SearchDumpster:$false switch.
• Target items in the main mailbox only – again on a similar note, there are handful of scenarios enabled thanks to the –DoNotIncludeArchive switch. Microsoft 365 eDiscovery (including the premium version), does not allow you to do this.
• Copy items between mailboxes – fast (runs server side), easy to use (!) and robust method to copy items between mailboxes. Remember when Discovery mailboxes were a thing? Remember Microsoft turning deaf ears on repeated prompts to bring similar functionality to M365 eDiscovery? Lack of proper replacement is also one of the major reasons why some organizations still have substantial PST usage, as customers are forced to use the eDiscovery export functionality or do manual export via Outlook to address such scenarios.
• Preview operations – Thanks to the –LogOnly and –LogLevel parameters, the Search-Mailbox cmdlet is the only method we have within the service to answer questions such as “has userX read this email”, “where did my emails disappeared to”, “how many items are received from specific sender or within a specific timeframe”, and more. Even better, some of these questions can be addressed by using the –EstimateResultOnly switch, which in most cases is near instantaneous!
• Synchronous operations – speaking of instantaneous results, Search-Mailbox might not have received any performance improvements, but is still more than adequate thanks to the simple fact that it runs synchronously. No need to wait for a request to be scheduled, then picked up, then executed, then run more cmdlets to get the output or perform additional actions. It’s all included in a single package!

I am sure there are other use cases that I neglected to reflect upon above. As I am use Microsoft had its own reasons to insist on deprecating the cmdlet. But at the same time I do feel like this decision was most certainly not driven by desire to make customer’s life easier, not by a longshot. Oh well.