How does Purview/data lifecycle management on Mailboxes work for deleted mailboxes?
I have an inkling that it more or less keeps the Mailbox in the Recoverable Items set//folder/dimension, but I don't want to guess. We do not have a license for Purview, I just have discovered that we have policies in here setup and forgotten about (or migrated Compliance and Security, and forgotten about). I say this because I don't fully understand Purview (because I don't want to use it, and we don't have it), yet I have a 'keep forever' policy set on ALL Exchange Mailboxes, but it doesn't actually prevent me from Deleting them. Reading this and this doc, the word 'mailbox' appears 54 times. I have responsibilities and a life, but I did manage to find out when MAIL is deleted from Deleted Items, it goes to 'recoverable items' - a folder that exists in (somewhere). What I don't know is what happens if the entire Mailbox is deleted. I have archiving turned off. I notice that there is a separate 'inactive mailbox' article. I genuinely do not have the time or patience to read these massive docs, or the 100 other docs they link to, for a platform way outside my scale, that I don't intend on using. Anyone know? I need to understand how this works before I get approval on removing it.
Email Retention Policy Editing and Deletion Mechanism is Broken and Unpredictable - Purview
We experienced a critical failure in how Microsoft Purview retention policies behave when mistakes happen: A retention policy was mistakenly created that automatically deletes emails older than 14 days, and it was accidentally applied to all mailboxes. Once the error was discovered, we tried to disable or delete the policy — but it was locked and completely uneditable. For days, it was impossible to make any changes to the policy — no disable, no scope edit, no deletion. Eventually, after Microsoft made some backend change, we saw the policy move into "PendingDeletion" state — still without any way to confirm whether it's active or being enforced. Using PowerShell, we finally managed to force-remove the policy via Remove-RetentionCompliancePolicy -Force. The policy no longer appears in any list — but some mailboxes still show the 14-day retention tag, and emails are still being deleted. Other mailboxes seem unaffected — completely inconsistent behavior. Start-ManagedFolderAssistant doesn't reliably refresh mailbox state. Some users update, others don’t. The LastProcessedTime is often empty. There's no logging or status information per mailbox, so admins have no visibility into whether a policy was applied, processed, or reverted. Even worse: some users are still receiving the now-deleted policy as if it were being applied freshly, long after deletion. This suggests that Microsoft may be asynchronously processing a cached sequence of updates, executing actions even if the current policy no longer exists. That’s deeply problematic and can cause serious, silent data loss across the organization. There’s also been no meaningful support from Microsoft. They did call us yesterday, but were unable to provide any useful information. All we were told is that they're "waiting to see what happens with the pending deletion state," which clearly shows they have no real insight into the system’s behavior or recovery process. We’re essentially on our own, hoping the system will eventually correct itself. What Microsoft must improve: Admins need a way to immediately stop or reverse a policy across all mailboxes. There must be clear visibility into what policy is active per mailbox. A status dashboard for policy enforcement would prevent blind troubleshooting. The system must log and expose retention actions on a per-mailbox level. PendingDeletion must actually mean the policy is not being enforced anymore. Right now, compliance policies behave like a black box, and once something goes wrong, admins have no way out. This is not acceptable for production environments.
Search-UnifiedAuditlogs For Mailbox - Problems
Introduction Like many, I have been faced with an audit search problem on mailboxes. I finally found a solution by searching deeply into the web. In this post I will provide you with Microsoft's documentation, I have tested everything, and it finally works. I also have comments to Microsoft, directly to the product group (with a case Microsoft) but also by the technet article feedback feature. Technical Content We assume that you have all necessary permissions and role to run audit logs search. For Regular mailboxes: if you have no results via GUI, It is possible that in the time interval there is no result. It may happen that the audit is blocked on the mailbox despite the fact that the feature is active. You may use the command Search-UnifiedAuditLog with the following parameters: UsersIds : email address Operations : event to be search (Exchange Mailbox Activites) Search-UnifiedAuditLog -UserIds <MailboxIdentity> -Operations MoveToDeletedItems, SoftDelete, HardDelete -StartDate "01/01/2025" -EndDate "15/01/2025" Unfortunately, no results appear with powershell. Here, you can find the documentation that describe the symptom and how to resolve it. Even when [mailbox auditing on by default](https://learn.microsoft.com/en-us/purview/audit-mailboxes) is turned on for your organization, you might notice that mailbox audit events for some users aren't found in audit log searches by using the Microsoft Purview portal or the compliance portal, the **Search-UnifiedAuditLog** cmdlet, or the Office 365 Management Activity API. The reason for this is that mailbox audit events is returned only for users with E5 licenses when you use one of the previous methods to search the unified audit log. You must run the following command within Exchange Online : Set-Mailbox -Identity <MailboxIdentity> -AuditEnabled $false And then : Set-Mailbox -Identity <MailboxIdentity> -AuditEnabled $true Now you can search within the GUI or with powershell and you will have some results. For Shared Mailboxes: To search audit logs for a SharedMailbox, you must use the following command, with the parameter *FreeText.* Search-UnifiedAuditLog -StartDate "08/01/2025" -EndDate "11/01/2025" -FreeText (Get-Mailbox -identity <MailboxIdentity>).ExchangeGuid -Operations MoveToDeletedItems` Here you can find the article that describes the FreeText parameters, and also decscribes that GUI is not working for SharedMailboxes. Also, using the **User** dropdown list in the audit log search tool or the **Search-UnifiedAuditLog -UserIds** won't return results for activities performed in a shared mailbox. If there are no results and you are sure that there should be, then the same manipulation as described above will have to be done. Disable and then reactivate the audit on the mailbox: Set-Mailbox -Identity <SharedMailboxIdentity> -AuditEnabled:$false Set-Mailbox -Identity <SharedMailboxIdentity> -AuditEnabled:$true Run again the Search-UnifiedAuditLog command. Now you will find results. Conclusion I assume that the "Users" text box in the interface corresponds to the parameter "UserIds" in the cmdlet. And there is no match for the "FreeText" parameter. You can find other articles in my GitHub about Purview https://github.com/trisdev75/MicrosoftPurview
