Microsoft is deprecating Basic Auth for Exchange Online PowerShell, causing old scripts using `New-PSSession` to fail. Learn why this is happening and discover three solutions, from a quick fix to a permanent, future-proof rewrite.

That 3 AM Alert: Why Your Exchange Online Scripts Are Suddenly Failing

I still remember the pager alert. It was 3:17 AM on a Tuesday. The on-call engineer was stumped. Our automated user offboarding script, a trusty PowerShell workhorse that had run flawlessly for years, was suddenly throwing a wall of red text. The error? “Access is denied.” Panic starts to set in. Did someone revoke the service account’s permissions? Is it a Conditional Access policy gone rogue? Nope. After a frantic hour of troubleshooting, we found the culprit: a silent, background change by Microsoft that finally caught up to us. And I’m willing to bet it’s about to catch up to you, too.

So, What’s Actually Happening Here? The “Why” Behind the Pain

Let’s get straight to it. Microsoft is killing Basic Authentication for Exchange Online. This is a good thing for security, but it’s a nightmare for legacy automation. For years, we all connected to Exchange Online using a method that looked something like this:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameChecking

That -Authentication Basic part is the ticking time bomb. It’s being phased out, and when it’s gone for your tenant, any script using this method will simply stop working. The new way forward is Modern Authentication via the ExchangeOnlineManagement v3 module, which uses REST API calls under the hood instead of the old Remote PowerShell (RPS) protocol.

The Fixes: From Duct Tape to a New Engine

You’ve got options, ranging from a quick patch to get you through the day to a proper, long-term solution. Let’s walk through them.

Solution 1: The ‘Get Me Through the Night’ Quick Fix

This is the fastest way to get your scripts running again. The idea is to install the new module and use the new connection cmdlet, but let Microsoft’s backward-compatibility magic handle the rest. It’s a bit of a hack, but it works in a pinch.

1. Install the new module: Open PowerShell as an Administrator and run this. You only need to do this once.

   Install-Module -Name ExchangeOnlineManagement -Force

2. Update your script’s connection block: Replace your entire New-PSSession block with a single, modern line.

   # The old way is now commented out or deleted
   # $Session = New-PSSession ...
   # Import-PSSession $Session ...
   
   # The new, simple way
   Connect-ExchangeOnline

For most simple scripts, this just works. The Connect-ExchangeOnline cmdlet will pop a modern auth window for you to sign in, and it creates a temporary, backward-compatible session. Your old Get-Mailbox and Set-Mailbox commands will likely function as they did before.

Warning: This is a temporary fix. You’re still relying on the old Remote PowerShell protocol in the background. It’s slower and will eventually be fully deprecated. Use this to stop the bleeding, but plan to implement the permanent fix.

Solution 2: The ‘Do It Right’ Permanent Fix

This is the solution you should be aiming for. It involves not only changing how you connect but also updating your scripts to use the new, faster, REST-API-backed cmdlets. These are typically prefixed with “EXO” (e.g., Get-EXOMailbox).

Why bother? They are significantly faster and more reliable, especially when pulling large datasets. A Get-Mailbox that used to take 10 minutes might now take 30 seconds with Get-EXOMailbox.

Here’s how you’d refactor a simple script:

# Connect using old PSSession
Import-PSSession ...

# Get data
$mailboxes = Get-Mailbox -ResultSize Unlimited

# Process
foreach ($mbx in $mailboxes) {
    # do something...
}

# Install module if needed
# Install-Module ExchangeOnlineManagement

# Connect the modern way
Connect-ExchangeOnline

# Get data with new EXO cmdlet
$mailboxes = Get-EXOMailbox -ResultSize Unlimited

# Process (the logic stays the same!)
foreach ($mbx in $mailboxes) {
    # do something...
}

The core logic of your script doesn’t change, but you’re switching out the data-gathering cmdlets. This is the future-proof path.

Solution 3: The ‘I Have No Choice’ Nuclear Option

Okay, so you have a monstrous, 2000-line script that was written by an intern five years ago. It’s got complex, nested logic, and rewriting it all to use the new EXO cmdlets would take weeks. You’re stuck. We’ve all been there.

For this scenario, there’s an escape hatch: the -UseRPSSession switch. This forces the modern Connect-ExchangeOnline cmdlet to create a full, old-school Remote PowerShell session, just like Import-PSSession did. It gives you access to all the old cmdlets, not just the ones with EXO equivalents.

# This connects using modern auth, but gives you an old-style session
Connect-ExchangeOnline -UseRPSSession

# Now your entire old script should work as-is, with no changes needed to cmdlets.
Get-MessageTrace -StartDate "10/25/2023" -EndDate "10/26/2023"

Darian’s Pro Tip: Treat the -UseRPSSession switch like a deal with the devil. It will save you today, but you’re inheriting all the performance and reliability problems of the old protocol. Microsoft has made it clear this is a compatibility feature, not a long-term solution. Use it to buy yourself time to properly rewrite the script (Solution 2), and document it as technical debt.

So there you have it. Don’t let that 3 AM alert catch you off guard. Get ahead of this, audit your scripts, and start updating your connection methods. Your future, well-rested self will thank you.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions