Optimizing Exchange Online PowerShell in 2026: Faster, Smarter, and Ready for Microsoft Graph

Microsoft is using a new Exchange Team blog post to push admins toward a more modern, efficient way of managing Exchange Online with PowerShell, focusing on tuning core PowerShell performance, adopting the latest Exchange Online module, and preparing for a future built on the Microsoft Graph PowerShell SDK. The guidance targets busy Microsoft 365 admins who run large-scale scripts and automation and need better speed, reliability, and resource usage when talking to Exchange Online.​

Why Exchange Online PowerShell Needs Optimizing

As Exchange Online environments grow, so do the scripts that manage them—bulk mailbox changes, compliance policies, reporting, and automation pipelines can easily hammer both client and service if they are not optimized. Microsoft’s latest guidance emphasizes that performance tuning is no longer “nice to have”: poorly written scripts can slow down management tasks, hit throttling limits, and consume excessive memory on admin workstations or automation hosts. The blog frames optimization as a mix of three layers: Windows PowerShell itself, common Microsoft 365 module practices, and Exchange Online–specific tweaks.​

Step 1: Tune Core PowerShell for Better Performance

The first set of recommendations is about getting the PowerShell engine itself into a good state before connecting to any Microsoft 365 services. Microsoft reiterates that admins should run the latest supported PowerShell version for both security and performance, with Windows PowerShell 5.1 still built into supported Windows releases and PowerShell 7 available as a separate, regularly updated install. The post also reminds admins they can disable telemetry by setting the POWERSHELL_TELEMETRY_OPTOUT environment variable if they do not want PowerShell usage data collected, which can be important for locked-down or regulated environments.

$env:POWERSHELL_TELEMETRY_OPTOUT = "true"

Keeping PowerShell updated matters because newer versions deliver runtime and module-loading improvements that make remote connections and parallel workloads more efficient. For PowerShell 7, Microsoft points to official upgrade guidance, positioning 7.x as the preferred shell for cross-platform automation and modern features like ForEach-Object -Parallel that directly affect script speed in Exchange Online scenarios.​

Step 2: Best Practices for All M365 PowerShell Modules

Microsoft then zooms out to shared guidance that applies across Exchange Online, SharePoint, Teams, and Security & Compliance PowerShell modules. The core message is straightforward: stay on the latest module versions and establish a predictable update cadence, testing updates on admin workstations or management servers before rolling them into production automation. For serverless or managed environments like Azure Functions, Microsoft highlights features such as Managed Dependencies to keep modules auto-updated with minimal manual effort.

Script smarter, not harder…

• Parallel Processing:
  • Leverage ForEach-Object -Parallel (in PowerShell 7+) or background jobs to perform bulk operations faster.

• Use -ResultSize to return only the necessary data. This is especially beneficial when querying many objects.

Get-EXOMailbox -ResultSize 100

This example retrieves only the first 100 mailboxes (rather than default of 1,000), reducing resources and time to execute.

• Prioritize service-side filtering when available. Not all filters are created equal. Understanding how, or more importantly, where filtering is done when using different methods can have a substantial impact on performance.
  • Experienced PowerShell users know about pipelining with Where-Object to filter data. This is one example of client-side filtering.
  • Most cmdlets available in the various M365 PowerShell modules support the -Filter parameter. This leverages service-side (a.k.a. server-side) filtering.

Get-EXOMailbox -Filter "Department -eq 'Sales'"

This example limits results to mailboxes for the sales department and leverages service-side filtering to ensure only the data we want is returned to the client.​

Authentication is another key pillar: the advice is to use service principals or app-only authentication (sometimes called app-based) for automation rather than interactive logons. For Exchange Online and Security & Compliance, Microsoft already documents app-only patterns that improve reliability and remove MFA prompts from scheduled jobs. The same concept applies across Microsoft 365—each workload has its own app-only configuration, but the benefits are consistent: non-interactive auth, fewer brittle stored credentials, and cleaner security posture.​

Step 3: Script Smarter with Parallelism and Filtering

The blog’s “script smarter, not harder” section is aimed squarely at admins who still run large sequential loops and download far more data than needed. With PowerShell 7, commands like ForEach-Object -Parallel allow bulk operations—such as updating mailbox attributes or processing large user sets—to be spread across parallel runspaces, dramatically reducing execution time compared to a simple foreach loop. Where PowerShell 7 is not available, traditional background jobs can offer some of the same benefits, though with more manual orchestration.​

Microsoft also reminds admins to limit result sets and filter at the service whenever possible. Using parameters like -ResultSize on Get-EXOMailbox or similar cmdlets helps avoid pulling thousands of objects when only a subset is required, cutting network traffic and processing overhead. Even more important is preferring server-side filtering (-Filter) over client-side Where-Object, because server-side filters are evaluated in the service, so only matching objects are returned, which is especially impactful at tenant scale.​

Step 4: Use the Exchange Online PowerShell V3 Module

The article then drills into Exchange Online specifics, championing the current Exchange Online PowerShell module (EXO V3+) as the baseline for modern scripting. This module uses REST-based cmdlets rather than older remote PowerShell (RPS) connections and includes exclusive Get-EXO* cmdlets optimized for better performance and resilience. Microsoft’s own documentation shows that REST-backed cmdlets avoid the overhead of setting up PowerShell runspaces, leading to substantially higher throughput when fetching or updating large numbers of mailboxes.​

A table in the official docs compares legacy remote cmdlets, Get-EXO* cmdlets, and REST API cmdlets across security, performance, reliability, and functionality, with remote PowerShell clearly marked as least secure and least reliable. REST-based cmdlets match the old cmdlets for parameter coverage while bringing built-in retry logic and better handling of throttling, which is essential for long-running scripts at scale. Microsoft also links to earlier guidance on reducing memory consumption in EXO V3, including tips like skipping cmdlet help loading and limiting which cmdlets are brought into each session.

Memory and Reliability Tips for EXO V3

The memory-consumption guidance Microsoft calls out remains highly relevant for admins who run recurring management scripts or automation in constrained environments. One of the biggest wins is using -SkipLoadingCmdletHelp on Connect-ExchangeOnline, which prevents the module from loading its full help package into memory—significantly reducing footprint for non-interactive tasks. Another recommendation is to load only the cmdlets actually needed by passing specific names via -CommandName, rather than loading hundreds of cmdlets for scripts that only call a handful.​

In scenarios where many connections are created and torn down, Microsoft has also suggested running new Exchange Online connections in fresh PowerShell processes, so cached data and accumulated memory use are reset cleanly. This aligns with EXO V3’s overall design philosophy of trading the brittle, long-lived RPS sessions for more stateless, REST-backed calls that are easier to scale and more robust in the face of transient errors or throttling.​

Microsoft Graph PowerShell SDK

The blog closes by pointing toward Microsoft Graph PowerShell SDK as the future of Microsoft 365 automation, including Exchange Online. Graph SDK modules are modular and cross-platform and use modern authentication, giving admins a consistent, API-first way to script across Entra ID, Exchange, SharePoint, Teams, Planner, and more. Microsoft has already announced retirement of other Graph tooling such as the Graph CLI, explicitly recommending the Graph PowerShell SDK as the preferred replacement for new automation investments.​

For admins who are already comfortable with workload-specific modules, Graph can feel like a big conceptual jump, but Microsoft is investing in updated documentation and training paths, including “Getting started” guides and in-depth coverage in resources like the second edition of Automating Microsoft 365 with PowerShell. The key reassurance from the blog is that the same optimization principles—modern PowerShell, app-only authentication, parallel processing, and service-side filtering—apply directly when using the Graph PowerShell SDK, so skills learned for EXO V3 carry forward.​

What This Means for Exchange Online Admins

For Exchange Online admins, the takeaway is clear: staying on legacy remote PowerShell cmdlets and old scripting patterns leaves performance, reliability, and security on the table. Moving to EXO V3 REST cmdlets, trimming memory usage, and leaning into PowerShell 7 parallelism and server-side filtering can deliver immediate benefits in daily management and large-scale automation. At the same time, starting to experiment with the Microsoft Graph PowerShell SDK prepares organizations for Microsoft’s long-term direction, where Graph becomes the primary surface for Microsoft 365 automation.

The following table compares the benefits of REST API cmdlets to unavailable remote PowerShell cmdlets and the exclusive Get-EXO* cmdlets in the EXO V3 module