Important Announcement: Deprecation of AdminAuditLog and MailboxAuditLog Cmdlets

[ColbyBoone]

[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: 

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

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: 

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

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: 

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

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 

[RaksChauhan]

We rely on the Search-MailboxAuditLog alot as its much better for reporting/audit logs on Shared Mailbox activity as they are not licences mailboxes versus the GUI-based Audit Search. We get values for the logged on user and the actions they perform against the Shared Mailbox. Can you recommend the best way to continue to achieve this using Search-MailboxAuditLog?

[JeremyTBradshaw]

Reposted in Exchange hub for visibility.  Updated comments to remove my complaint.  Should be fine with this change.

[Xavier_P1150]

Hi,

We use Search-MailboxAuditLog to audit shared mailboxes. Search-UnifiedAuditLog doesn't seem to be able to do this. What do you suggest as an alternative via PS script?

[wharts245]

...

[Deleted]

Hi @ColbyBoone,

I've had instances with customers where "change user license" wasn't recorded at all and neither Search-UnifiedAuditLog cmdlet nor Microsoft Purview portal returned the activity. May I know if this cmdlet returns all events/activities made/performed by MS system/administrators?

Is there any scenario where certain activity can't be audited and consequently can't be returned by these tools?

[MrPNutts_o365]

I just lost a long comment due to a problem with this site, so I'll summarize it as the unified log doesn't return all the details and events compared to Search-MailboxAuditLog. Losing that level of detail is going to significantly reduce the ability to troubleshoot.

[DATX]

@ColbyBoone , we do business email compromise investigations for small businesses. In the past if the UAL was off we could still grab mailbox logs and admin audit logs. After this change goes through, if UAL is off, would we have none of that data available? 

That would be hugely consequential for victims to understand what attackers did in their environment and be able to understand any legal implications. Would like to understand what would be available and how to get it, in instances where UAL is off.

[JSC-HFT]

Been using this code provided by Microsoft years with great success.  UnifiedAudit log seraching does not provide this level of detail.  Bad move by Microsoft:

How to use mailbox audit logs in Microsoft 365 - Microsoft 365 | Microsoft Learn

[JeremyTBradshaw]

Will be excited to hear the responses about the valid issues raised here so far.  It seems I wasn't alone about noticing quite a difference between especially the mailbox audit logs vs universal audit logs.  Surely we can have the new way improved to match and exceed the quality of the old way!

[M365_forensics]

This is a giant L if not implemented properly. As it stands there is a complete lack of crossover between AAL and MAL entries when compared to the UAL in certain instances. For example, the UAL does not track inbox rule creation on delegates in the same way that the AAL does and losing the indications this logging provides could have some pretty major consequences.

The biggest issue here is of course that you (Microsoft) only turn the UAL on by default for certain licensing levels meaning that if an admin does not enable it at the creation of the tenant then forensic teams would be SOL on any form of logging aside from message traces which is unacceptable. You (again, Microsoft) all just made a big show of expanding in-depth logging capabilities across all tenants because it was acknowledged that forensic data should be more open and available and now we are going 2 steps backwards with this change by potentially cutting off access to all logging if a setting (which you could enable by default for all tenants) is not turned on.

[Dean_Gross]

Is any work being done to add more administrative actions to the audit log, i.e., create and delete label policies and auto-labeling policies for sensitivity labels is not tracked. In general, everything an admin can do in a portal should be recorded.

[BEC4n6]

@ColbyBoone The negative consequences of this change are substantial. Forensic investigators will lose a lot of insight into malicious activity that happened during a compromise. This will impact the ability to appropriately alert people who have been victimized as a result of a Business Email Compromise so that they can take appropriate steps to protect themselves.  This reduced visibility into logging will ultimately perpetuate a threat actor's ability to continue to cause harm. Microsoft is aiding and abetting cybercrime by making this change. 

Why does the UAL have to be manually enabled by the end user? Auto-enablement shouldn't be a difficult thing to do. Manual enablement of basic forensic and security features is disingenuous product design choice. 

[GeogAlthaus]

HI

As documented in Manage mailbox auditing | Microsoft Learn I can increase the retention period and use Search-MailboxAuditLog to search for records older than 90 days.
What is the impact of thos deprecation to this scenario? Do you need a Premium License to search for older records?
And what is the AuditLogAgeLimit Parameter on Set-Mailbox realy configure with this deprecation in mind? 

[wharts245]

AuditLogAgeLimit Parameter on Set-Mailbox is only relevant for non E5 licensed objects as far as i can tell.

[ColbyBoone]

@RaksChauhan We appreciate your feedback! You accomplish this with Search-UnifiedAuditlog by using a Free-Text search. Data in UAL is the same as the data inside Mailbox. No difference is being made in the ingestion of the data based on license.  

A way to search shared mailbox activity using UAL cmdlet is displayed in the following documentation https://learn.microsoft.com/en-us/purview/audit-troubleshooting-scenarios#search-for-mailbox-activit...  

[ACE_Maloof]

@ColbyBoone, do you intend to address the concerns with logging availability now being completely determined by whether or not the UAL is turned on? Will this specific data for the MALs and AAL be available regardless of ingestion being turned on for sign-in data and other events, or will the UAL need to be turned on now in order for MAL and AAL activity to record?

A straight answer seems very simple.

[ColbyBoone]

@Xaiver_P1150 Thank you for your comment! To answer your question regarding PS Script the following documentation can be followed: https://learn.microsoft.com/en-us/purview/audit-troubleshooting-scenarios#search-for-mailbox-activit...  

[ColbyBoone]

@DATX Yes, customers will need to enable auditing. There is a separate section in documentation which covers what would be available as part of the mailbox auditing, when enabled: Manage mailbox auditing | Microsoft Learn 

[ColbyBoone]

@BEC4n6 Thank you for your comment and highlighting ways to improve the customer experience. Unified Audit is enabled by default for E3 and E5 tenants which represents a significant portion. While evaluating the above comment in the meantime of future improvements if a customer does not have auditing enabled or has manually disabled this in the past, we encourage them to enable auditing to be able to generate Audit logs and retrieve them using the Search-UnifiedAuditLog cmdlet. 

[DATX]

@ColbyBoone - does that mean everyone without E3/E5 has to explicitly turn the UAL on?  

MS should run some stats on what % of tenants do not have UAL turned on and understand the vast majority of SMBs do not administer their own tenants and only have defaults configured. Some transparency on which licenses do/don't have UAL on by default would be helpful.

This isn't even about a security feature, auditing/logging should be standard functionality; MS Cloud hit $110B last year. At the very least they could notify those who do not have UAL turned on that they do not and they should.

[JeremyTBradshaw]

Turning on the UAL is an exam question on at least 3 different MS exams.  At this point it's part of the curriculum.  They could change it, but people not knowing, didn't do their studies.

[JSC-HFT]

@ColbyBoone can Microsoft provide updated script that accomplishes the same thing from here:  How to use mailbox audit logs in Microsoft 365 - Microsoft 365 | Microsoft Learn

This script is so useful and been using it for years.

[WernerMuc]

I export Exchange audit logs every week so that I can still track changes after 90 days. In order to have the Exchange admin audit logs more human readable I utilize the script "Get-SimpleAuditLogReport.ps1". This script is provided and recommended by Microsoft:

Parsing the Admin Audit Logs with PowerShell - Microsoft Community Hub

Get-SimpleAuditLogReport - Microsoft - CSS-Exchange

Will there be an update to this script so it's working with the new cmdlet Search-UnifiedAuditLog too?

Is there a similar script for the new cmdlet Search-UnifiedAuditLog as the output is not readily human readable?

[PhillipPino]

How do you target a mailbox (or 2) to search using Search-UnifiedAuditlog?  

[chadmando]

The level of detail is still included in the Unified Audit Log results, it is just harder to find.  This is an example of how to get the level of detail your are used to with Search-MailboxAuditLog.  https://www.powershellrecipes.com/recipes/policy-and-compliance/extract-auditdata-from-unified-audit...

[DATX]

@chadmando that only applies to folks that have UAL turned on though right?  There are thousands of smaller M365 clients that don't, and the data isn't available when needed (but is in the MAL/AAL).

I think the point many of us are trying to make is that the logs that are about to be deprecated provided value for these cybercrime victims and the go-forward plan ignores that angle. If universal enabling of UAL for all tenants came alongside, it would be a welcome change.

[chadmando]

@DATX I thought that audit logging was enabled by default? https://learn.microsoft.com/en-us/purview/audit-log-enable-disable

If not, then I agree it should be turned on upon creation of a new tenant.  Most small businesses that use M365 won't have the savvy to enable audit logging.  

[Jean_Paul_Nkundabose]

Hi @ColbyBoone,

I've had instances with customers where "change user license" wasn't recorded at all and neither Search-UnifiedAuditLog cmdlet nor Microsoft Purview portal returned the activity. May I know if this cmdlet returns all events/activities made/performed by MS system/administrators?

Is there any scenario where certain activity can't be audited and consequently can't be returned by these tools?

[GeogAlthaus]

Hi @ColbyBoone 
What does this mean for non Purview licenced customer. How long will the retetion perid me?

Regards Georg

[Rob_R]

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.

[Vivek]

@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.

[Forrest_H]

@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.

[ACE_Maloof]

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”.

[ToniDB]

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

[Nagarajan26]

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?

[JeremyTBradshaw]

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.

[William_Holmes]

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.   

[JeremyTBradshaw]

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?

[Matt_S095]

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?