If you manage Microsoft Exchange—whether on-premises, hybrid, or Exchange Online—PowerShell is not optional. The Exchange Admin Center (EAC) is useful for day-to-day tasks, but it exposes only a fraction of Exchange’s real capability. Anything at scale, anything repeatable, anything requiring precision inevitably leads back to PowerShell.
In my own experience, Exchange PowerShell is often where you actually understand what the platform is doing. It exposes configuration in a transparent way, allows bulk changes safely (if you know what you’re doing), and becomes invaluable when troubleshooting production issues under pressure.
This article focuses on Exchange PowerShell fundamentals—not just syntax, but how and why these concepts matter in real-world administration.
What Is Exchange PowerShell?
Exchange PowerShell is built on Windows PowerShell (and now PowerShell Core in Exchange Online) and provides thousands of Exchange-specific cmdlets. These cmdlets allow administrators to:
- Automate administrative tasks
- Query configuration and status at scale
- Troubleshoot complex issues
- Perform bulk changes safely and consistently
Exchange PowerShell exists in two main forms:
- Exchange Management Shell (EMS) – for on-premises Exchange
- Exchange Online PowerShell – for Microsoft 365 tenants
While the cmdlets are similar, there are important differences that experienced admins need to understand.
Understanding the Verb–Noun Cmdlet Structure
All PowerShell cmdlets follow a Verb-Noun naming convention. This consistency is intentional and becomes extremely powerful once you learn to leverage it.
Common Exchange verbs include:
- Get – Retrieve information
- Set – Modify existing objects
- New – Create new objects
- Remove – Delete objects
- Enable / Disable – Toggle features
- Start / Stop – Control processes
Examples:
Get-MailboxSet-CASMailboxNew-MailboxRemove-Mailbox
Once you understand the noun (Mailbox, User, Database, Connector), discovering new functionality becomes significantly easier.
Discovering Cmdlets with Get-Command
One of the most underrated tools in Exchange PowerShell is Get-Command.
When you don’t remember the exact cmdlet—or you’re exploring unfamiliar functionality—this command is invaluable.
Get-Command *Mailbox*
This returns every Exchange cmdlet containing “Mailbox”, allowing you to discover functionality you may not have known existed.
In real environments, this is far faster than Googling, and it avoids outdated blog posts that reference deprecated cmdlets.
Learning Safely with Get-Help (and Why You Should Always Use It)
Before running any unfamiliar cmdlet in production, you should use Get-Help.
Get-Help Get-Mailbox
This provides:
- Description of what the cmdlet does
- Required and optional parameters
- Examples (often excellent ones)
Adding -Detailed or -Examples makes it even more useful:
Get-Help Set-Mailbox -Examples
In real-world administration, Get-Help prevents mistakes that GUIs silently protect you from—especially when modifying user access or transport settings.
The Pipeline: PowerShell’s Greatest Strength
The pipeline (|) allows objects—not text—to flow from one cmdlet to another. This is where PowerShell truly separates itself from traditional scripting.
Example:
Get-Service | Where-Object {$_.Status -eq "Running"}
What’s happening:
Get-Servicereturns service objects- The pipeline passes each object to
Where-Object $_represents the current object in the pipeline
This object-based model allows precise filtering, transformation, and automation.
Understanding the Special Variable $_
The $_ variable represents the current object being processed in the pipeline.
Example:
Get-Mailbox | Where-Object {$_.RecipientTypeDetails -eq "UserMailbox"}
Here:
- Each mailbox object is evaluated
- Properties are accessed directly
- Only matching objects are passed forward
Once you truly understand $_, PowerShell becomes dramatically more powerful and readable.
Filtering Data Correctly: Server-Side vs Client-Side
One of the most common mistakes I see—even among experienced admins—is inefficient filtering.
Client-side filtering (slower):
Get-Mailbox | Where-Object {$_.DisplayName -like "*Brown*"}
Server-side filtering (faster and recommended):
Get-Mailbox -Filter "DisplayName -like '*Brown*'"
Server-side filtering reduces load on Exchange and runs significantly faster in large environments. This matters when you’re working with tens of thousands of objects.
Quotation Marks: Single vs Double (Yes, It Matters)
- Single quotes (‘ ‘) – literal strings
- Double quotes (” “) – allow variable expansion
Example:
$User = "JBrown"
Get-Mailbox "$User"
Using single quotes here would break the command. Understanding this distinction avoids subtle and frustrating bugs.
Accessing Event Logs via PowerShell
PowerShell allows quick access to Exchange-related events, which is extremely useful during incident response.
Get-EventLog Application | Where-Object {$_.Source -like "*Exchange*"}
While modern environments increasingly rely on centralized logging, this remains useful for quick local diagnostics.
Exporting Data: Objects to Files
PowerShell excels at exporting structured data.
Get-Service | ConvertTo-Csv | Out-File "C:\Temp\Services.csv"
In Exchange environments, this is commonly used for:
- Mailbox reporting
- Permission audits
- License reviews
- Compliance documentation
Logging Exchange PowerShell Activity (On-Prem)
Exchange can log PowerShell commands that modify objects—critical for auditing and troubleshooting.
Set-ItemProperty HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.Exchange.Management.PowerShell.Admin `
-Name LogPipelineExecutionDetails -Value 1
This has saved me more than once when tracking down who changed what in shared admin environments.
Practical Mailbox Management Examples
Check Mailbox Database Status
Get-MailboxDatabase -Status | Format-Table Name, Server, Mounted
This is one of the first commands I run when users report widespread access issues.
Move a Mailbox
Get-Mailbox JBrown | Move-Mailbox -TargetDatabase "Users"
In real-world migrations, this command is often wrapped in scripts to handle batches, logging, and error handling.
Disable Outlook Web Access
Set-CASMailbox [email protected] -OWAEnabled $false
A common security requirement in regulated environments.
Stopping a Running Command
Sometimes you make a mistake. Or a command takes far longer than expected.
Press:
CTRL + C
This works in PowerShell, CMD, and Exchange Management Shell.
Connecting to Exchange Online (Modern Approach)
Older connection methods using basic authentication are now deprecated. Modern Exchange Online PowerShell uses the ExchangeOnlineManagement module.
Connect-ExchangeOnline -UserPrincipalName [email protected]
This supports:
- MFA
- Modern authentication
- Conditional access
If you’re still using legacy connection scripts, updating them should be a priority.
Real-World Advice from the Field
After years of administering Exchange, here’s what consistently matters:
- Always test commands with
-WhatIfwhen available - Prefer server-side filtering
- Document scripts that modify production data
- Never blindly copy commands from the internet
- Treat Exchange PowerShell as production infrastructure—not a toy
PowerShell is incredibly powerful, but that power cuts both ways.
Conclusion
Exchange PowerShell is not just an administrative interface—it is the true control surface of Microsoft Exchange. Mastering its fundamentals allows IT professionals to work faster, safer, and with far greater confidence.
The administrators who truly understand Exchange PowerShell are the ones who handle outages calmly, automate repetitive work effectively, and gain the trust of their organisations.
If you invest time in learning these fundamentals properly, the return is enormous.
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.