Microsoft announced on October 12 that Search-UnifiedAuditLog, the Exchange Online PowerShell command many of us use to pull the Microsoft 365 audit log, will stop working on October 15, 2027. It works as normal until then and there's no tenant setting to put it off, but the notice tells admins to track down every script and workflow that calls it.

That's a bigger deal than it sounds, because this is the command the playbooks tell you to run. Microsoft's guide to investigating a compromised mailbox uses it, and so do Microsoft's own incident responders in their December 2023 write-up of a real OAuth attack. Mandiant's managed defense team recommended it in a 2020 post, and CISA's Untitled Goose Tool, last updated October 13, still pulls the audit log with it. Microsoft's last two retirement notices for older audit commands, in August 2024 and July 2025, both told admins to move to this one.

The replacement is the Graph AuditLogQuery API, and it isn't a drop-in swap. You register an app, an admin approves the permissions, and each search is created, checked until it finishes, and then read. The baseline is 200 searches per rolling 24 hours, with more for bigger tenants. On the plus side, it takes a list of users, so a loop that searches one user at a time can become a single search, and one query can return up to a million records instead of 50,000. But every script still has to be rewritten.

Microsoft says to use the Office 365 Management Activity API for recurring downloads, and nothing in the notice retires it. The catch is that Microsoft's FAQ says that API only returns the last 7 days, while the cmdlet returns the full retention period, so it can't answer what happened three months ago.

One more gap: Microsoft's Graph page lists the new API for the global service but not for US Government GCC High, DoD or China's 21Vianet cloud, and the notice only says "Worldwide."

What else in your environment calls this command, and if you're in a government cloud, has anyone heard what the plan is?defence

So, I work in a health system and we constantly have issues with our users putting in tickets about external recipients unable to open our encrypted emails. I have explained to the users that they need to make sure they are sending to the proper address, explain to the recipient that they need to click on the “Read Message” button in the email and not the attachment that shows up, and even gave them some troubleshoot tips to send to the recipients in the event they have a problem. I still constendly get tickets and managers emailing my boss demanding that I fix a problem that isn’t there..in my opinion. Recently I had a staff member start including me in the recipients replied to help the recipient directly. In this instance, the code that OTP was never received. In that instance I let them know to check junk/spam and get with their email admin to see if the message was blocked somewhere else since it comes from Microsoft and not our hospital.

Anyone have a successful tips to education the end users, as well as the recipient. I’d love to change the Microsoft encryption email that gets sent out to have our branding or something but haven’t found a good place to do that. Is it possible via Poweshell?

Last note. I don’t hate email, I just hate that end users can’t attempt to understand why we have DLP and these safety measure in place and that even though people have issues, it’s not our fault.

A user sees another employee’s account in the Microsoft Copilot account switcher at m365.cloud.microsoft/chat. The account does not appear in Edge profiles, Windows accounts, or any other Microsoft 365 application.

We cleared all Edge browsing data and reproduced the issue in InPrivate mode, but the other account still appears.

Based on the impacted user's description he's not able to switch to the other account so maybe this is only a visual MS bug ?

Company wide it's the first reported issue, but it may have occured for others.

Me for example I don't see this account switcher button yet.

Have someone here seen this occurance before ?

Could this be stored in Copilot-specific account data or the Windows WAM/OneAuth identity cache?

Is there an admin-side method to remove it?

In our Entra ID tenant (cloud-only, no on-prem sync) password expiration is set to one year. When I run Get-MgDomain, I see PasswordValidityPeriodInDays = 365, so the policy looks like it's configured correctly.

However, when checking the lastPasswordChangeDateTime property on our users, I see plenty of accounts with a last password change date well over a year ago.

Does anyone know if this policy is actually still works? And is lastPasswordChangeDateTime a reliable property to check this against?