We are working towards streamlining the audit log search experience of our customers by deprecating four older cmdlets in favor of a single, more powerful cmdlet: Search-UnifiedAuditLog.

[UPDATE 4/18: We are writing to inform you that the AdminAuditLog & MailboxAuditLog changes that was scheduled for April 30th has been postponed until further notice. We apologize for any inconvenience this may cause you and we appreciate your patience and understanding]

[ Update 6/26]

Further details related to Admin Audit log Cmdlets Found here :

 https://aka.ms/AdminAuditCmdletBlog 

Dear customers, 

We are writing to inform you about an upcoming change that will affect the way you access and manage your Exchange Online audit logs. Starting from April 30, 2024, we will be deprecating the following four cmdlets in the Exchange Online V3 module: 

\n
• Search-AdminAuditLog 
\n
• Search-MailboxAuditLog 
\n
• New-AdminAuditLogSearch 
\n
• New-MailboxAuditLogSearch 
\n

These cmdlets will no longer be available for use after this date, and you will need to switch to a Search-UnifiedAuditLog cmdlet or Microsoft Purview portal to access your audit logs. 

Why are we deprecating these cmdlets? 

We are working towards streamlining the audit log search experience of our customers by deprecating four older cmdlets in favor of a single, more powerful cmdlet: Search-UnifiedAuditLog. This cmdlet has been in use for a long time and offers several advantages, including: 

\n
• Support for a wider variety of record types. 
\n
• More filtering options to refine your search. 
\n
• A range of output formats to suit your needs. 
\n

To make things simpler and more efficient, it’s recommended to use Search-UnifiedAuditLog from now on. You can learn more about this cmdlet and its usage here: Search-UnifiedAuditLog (ExchangePowerShell) | Microsoft Learn 

What do you need to do if you are using the deprecated cmdlets? 

If you are currently using any or all the above-mentioned cmdlets, you will need to take the following actions before April 30, 2024: 

For Search-AdminAuditLog, you will need to replace it with Search-UnifiedAuditLog in your scripts or commands. To get the same results as Search-AdminAuditLog, you will need to set the RecordType parameter to ExchangeAdmin. For example, if you want to search for all Exchange admin actions in the last 30 days, you can use the following command: 

Search-UnifiedAuditLog -RecordType ExchangeAdmin -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) 

For Search-MailboxAuditLog, you may also replace it with Search-UnifiedAuditLog. You can use the Exchange Online PowerShell V2 module to query the unified audit log for Exchange-related events. The cmdlet allows you to filter the results by record type, date range, user, and operation. For example, if you want to search for all Exchange mailbox actions in the last 30 days, you can use the following command:  
Search-UnifiedAuditLog -RecordType ExchangeItem -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) 

You can also export the results to a CSV file for further analysis. To use the cmdlet, you need to have the View-Only Audit Logs or Audit Logs role assigned. You can learn more about the cmdlet here: Search-UnifiedAuditLog.  

For New-MailboxAuditLogSearch and New-AdminAuditLogSearch you will need to use the Microsoft Purview portal to download your audit log report. The portal allows you to specify the criteria for your audit log search, such as date range, record type, user, and action. You can also choose to receive the report by email or download it directly from the portal. You can access the portal here: Microsoft Purview 

We are also working on a new Audit Search API using Microsoft Graph which is expected to become available in Public Preview by February 2024. This will allow our customers to programmatically access the new async Audit Search experience, which also provides improved reliability and search completeness. 

Note on default enablement of Auditing based on SKU:

To use the Search-UnifiedAuditLog command, auditing needs to be enabled for your tenant. Auditing is by default only enabled for the following SKUs: 

\n
• A1/A3/A5/Edu 
\n
• O365E1/E3/E5 
\n
• Defender 
\n

If you are using any different SKU, you will need to enable the Auditing manually by following the steps as mentioned here: https://learn.microsoft.com/en-us/purview/audit-log-enable-disable. Please note To ensure you have access to the last 90 days of logs once the cmdlets are deprecated, it’s crucial to enable auditing before January 31st. If you enable auditing after this date, you’ll only have access to logs from the day you activate it and onwards.     

We are here to help 

We understand that this change may cause some inconvenience or disruption to your workflows, and we apologize for any inconvenience this may cause. We are committed to providing you with the best tools and services to manage your Exchange Online environment, and we appreciate your understanding and cooperation. 

If you have any questions or feedback about this change, please feel free to contact us through our support channels or post a comment on this blog post. We are always happy to hear from you and assist you in any way we can. 

Sincerely, 

The Exchange Online Team 

[UPDATE 4/18: We are writing to inform you that the AdminAuditLog & MailboxAuditLog changes that was scheduled for April 30th has been postponed until further notice. We apologize for any inconvenience this may cause you and we appreciate your patience and understanding]

[ Update 6/26]

Further details related to Admin Audit log Cmdlets Found here :

 https://aka.ms/AdminAuditCmdletBlog 

Dear customers, 

We are writing to inform you about an upcoming change that will affect the way you access and manage your Exchange Online audit logs. Starting from April 30, 2024, we will be deprecating the following four cmdlets in the Exchange Online V3 module: 

\n
• Search-AdminAuditLog 
\n
• Search-MailboxAuditLog 
\n
• New-AdminAuditLogSearch 
\n
• New-MailboxAuditLogSearch 
\n

These cmdlets will no longer be available for use after this date, and you will need to switch to a Search-UnifiedAuditLog cmdlet or Microsoft Purview portal to access your audit logs. 

Why are we deprecating these cmdlets? 

We are working towards streamlining the audit log search experience of our customers by deprecating four older cmdlets in favor of a single, more powerful cmdlet: Search-UnifiedAuditLog. This cmdlet has been in use for a long time and offers several advantages, including: 

\n
• Support for a wider variety of record types. 
\n
• More filtering options to refine your search. 
\n
• A range of output formats to suit your needs. 
\n

To make things simpler and more efficient, it’s recommended to use Search-UnifiedAuditLog from now on. You can learn more about this cmdlet and its usage here: Search-UnifiedAuditLog (ExchangePowerShell) | Microsoft Learn 

What do you need to do if you are using the deprecated cmdlets? 

If you are currently using any or all the above-mentioned cmdlets, you will need to take the following actions before April 30, 2024: 

For Search-AdminAuditLog, you will need to replace it with Search-UnifiedAuditLog in your scripts or commands. To get the same results as Search-AdminAuditLog, you will need to set the RecordType parameter to ExchangeAdmin. For example, if you want to search for all Exchange admin actions in the last 30 days, you can use the following command: 

Search-UnifiedAuditLog -RecordType ExchangeAdmin -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) 

For Search-MailboxAuditLog, you may also replace it with Search-UnifiedAuditLog. You can use the Exchange Online PowerShell V2 module to query the unified audit log for Exchange-related events. The cmdlet allows you to filter the results by record type, date range, user, and operation. For example, if you want to search for all Exchange mailbox actions in the last 30 days, you can use the following command:  
Search-UnifiedAuditLog -RecordType ExchangeItem -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) 

You can also export the results to a CSV file for further analysis. To use the cmdlet, you need to have the View-Only Audit Logs or Audit Logs role assigned. You can learn more about the cmdlet here: Search-UnifiedAuditLog.  

For New-MailboxAuditLogSearch and New-AdminAuditLogSearch you will need to use the Microsoft Purview portal to download your audit log report. The portal allows you to specify the criteria for your audit log search, such as date range, record type, user, and action. You can also choose to receive the report by email or download it directly from the portal. You can access the portal here: Microsoft Purview 

We are also working on a new Audit Search API using Microsoft Graph which is expected to become available in Public Preview by February 2024. This will allow our customers to programmatically access the new async Audit Search experience, which also provides improved reliability and search completeness. 

Note on default enablement of Auditing based on SKU:

To use the Search-UnifiedAuditLog command, auditing needs to be enabled for your tenant. Auditing is by default only enabled for the following SKUs: 

\n
• A1/A3/A5/Edu 
\n
• O365E1/E3/E5 
\n
• Defender 
\n

If you are using any different SKU, you will need to enable the Auditing manually by following the steps as mentioned here: https://learn.microsoft.com/en-us/purview/audit-log-enable-disable. Please note To ensure you have access to the last 90 days of logs once the cmdlets are deprecated, it’s crucial to enable auditing before January 31st. If you enable auditing after this date, you’ll only have access to logs from the day you activate it and onwards.     

We are here to help 

We understand that this change may cause some inconvenience or disruption to your workflows, and we apologize for any inconvenience this may cause. We are committed to providing you with the best tools and services to manage your Exchange Online environment, and we appreciate your understanding and cooperation. 

If you have any questions or feedback about this change, please feel free to contact us through our support channels or post a comment on this blog post. We are always happy to hear from you and assist you in any way we can. 

Sincerely, 

The Exchange Online Team 

We are working towards streamlining the audit log search experience of our customers by deprecating four older cmdlets in favor of a single, more powerful cmdlet: Search-UnifiedAuditLog.

Hi all,

Regarding the auditing of Audit Logs being turned on/off, (found at the bottom of this page), are we able to perform a similar command using Search-UnifiedAuditLog?

Sorry to hijack these comments but would like to ask the crowd here if they noticed these two phenomenon about Search-MailboxAuditLog, particularly in my case for Shared mailboxes, but I'm not sure that has any bearing on the issue.

1.) When you use Recover Deleted Items (i.e., items are in the RecoverableItems\\Deletions folder), the audited Operation is \"HardDelete\".  My assumption is that anything that leaves Deletions is expected to have gone to RecoverableItems\\Purges, which is an oversight of the Recover Deleted Items feature which moves the item(s) out of Deletions and back into the user-visible original location or Deleted Items folder.

2.) When a FullAccess-granted user (via AutoMapped mailbox in Outlook) drags an item from one folder to another (i.e., what we would think is a Move), the audited operation is \"SoftDelete\".  In this case, it's not the same as a true \"SoftDelete\", which is what always happens when an item is deleted by the user, since the deleted item has to leave that Shared mailbox and go into the user's own Deleted Items folder (hence the audited operation in that case is not what we might expect, MoveToDeletedItems).  In this case the item is not in any mailbox's Deleted Items folder, nor Deletions, it is in the drag destination folder.  I thought this odd audit behavior might be masking that dragging is a copy then delete original, but I can't seem to prove this.

Anybody else ever observe this?

Hello,

I feel compelled to provide you feedback. This, now postponed, change is completely unwelcomed.   I am sure that you that there is some over-all plan driven by those interested IT from the security only perspective that the Search-UnifiedAuditLog is attempting to address.  However, when trying to verify what is happening it is simply not a replacement.  Its performance is way below par.  

Running the following Search command:

(Search-UnifiedAuditLog -RecordType ExchangeItem -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -HighCompleteness -UserIds email address removed for privacy reasons).AuditData | ConvertFrom-Json

Took over 20 minutes to complete in my Office 365 Tenant and returned a grand total of two records.

The simple inclusion of the HighCompleteness switch speaks volumes.  Under what circumstances would I not want a complete picture of the audit actions in a mailbox.

By Contrast: 

(Search-MailboxAuditLog email address removed for privacy reasons -ShowDetails -StartDate ([DateTime]::UtcNow).AddDays(-1) -EndDate ([DateTime]::UtcNow)

Returned 587 records in about 10 seconds.  

The Search-UnifiedAuditLog command did not help me in any way resolve the issue I was investigating.  On the other hand, the Search-MailboxAuditLog command returned a complete picture of what was occurring in the mailbox which rapidly led to the solution. 

While change is inevitable, I think is beyond important that such change does not further obfuscate information that our engineering and support teams need to do their jobs effectively.   

I had the luxury of using Search-MailboxAuditLog today when it was seemingly mission impossible to prove the storyline using Search-UnifiedAuditLog (or even worse, the Audit section of  Compliance/Security.microsoft.com sites).  Will miss it very much, everyone should get their usages in before it finally goes away at the end of this month.

EDIT: Nevermind, I just noticed the update from April 18 saying this has been postponed!  Thank you thank you thank you.

I am encountering a discrepancy in the data retrieved from the Search-UnifiedAuditLog and Search-AdminAuditLog cmdlets in Microsoft 365. Despite using the same parameters, the Search-UnifiedAuditLog cmdlet is returning incomplete data compared to the Search-AdminAuditLog cmdlet. Could you please give me any solution?

I've been using the script Run-MailboxAuditLogSearcher.ps1 and the Search-MailboxAuditlog command for several years and have had great results identifying activity for my users.  

I have been using the Purview GUI for a couple of months, trying to become familiar with it.  One thing I have notices is instead of basing the search on a particular MAILBOX, the key is for userID.  \"The UserIds parameter filters the log entries by the account (UserPrincipalName) of the user who performed the action. For example, email address removed for privacy reasons\"  as quoted from    https://learn.microsoft.com/en-us/powershell/module/exchange/search-unifiedauditlog?view=exchange-ps .  In my role, we are much more frequently asked to identify WHO performed a function in a mailbox than IN WHAT MAILBOX a user performed a function.  I'm still comparing the results from Search-MailboxAuditLog to results from Search-UnifiedAuditLog.  I can understand why keying on user could be more important when searching for bad behavior on any platform by a specific user account, but for identifying \"what happened in this mailbox where 20+ people have access?\" it is not helpful at all.  

Please, if anyone has worked in the new search more than me and knows how to specify mailbox instead of user, let me know

At this point I think we can expect no real answers to most of the important questions that can’t be handled by their sock puppet account just citing a help article that loosely pertains to what we asked for.

This is a massively flawed decision which will leave many SMB customers in the dark pertaining to any sort of data breach or incident which they might experience in the future.

Microsoft as a company and the team that manages the admin side of things should be ashamed by this decision. You hold the keys to the kingdom that is your product and you’ve chosen to say “let them eat cake”.

Vivek   Can you advise if this Audit Log command will work on a Resource Mailbox?  I read in some of the Microsoft articles that this command did not work for those types of objects.
I have tried submitting Searches in the Unified Audit 3 times now and get no results.  I have no idea on how to get any indication about if the Account I have assigned the access to is even using the ApplicationImpersonation, ResoureceImpersonation or Delegated Access.

Rob_R , we would like to clarify that the MailboxAuditLog and AdminAuditLog cmdlets have not been deprecated yet. The deprecation is scheduled for post April 30th, as mentioned in the blog post. Currently, we have only updated the message that appears when you run these cmdlets. If you encounter any scenarios that you are unable to find in the Search-UnifiedAuditLog, please feel free to raise a support ticket, and our team will provide you with the necessary assistance.

If these cmdlets are not to be deprecated until April 30, 2024 then why is it that the search-mailboxauditlog cmdlet already doesn't work? The returned results indicate that the cmdlet will be deprecated on April 30 and provides a link to this very article. 

I've been experimenting with the both the Audit tool in the compliance portal and the search-unifiedauditlog cmdlet but neither is producing results that help resolve issues about who has taken action on which messages within an employee or shared mailbox. I have to say that the documentation for using the new cmdlet lacks depth and decent examples related to searching mailboxes. I've also noticed that most of the linked articles related to auditing still indicate the search-mailboxaudidlog cmdlet - which as previously stated already doesn't work.